个中语音文件数多，并且每个语音文件小的特点
如果利用OTP的语音芯片，就很麻烦，由于用户不可烧录，调试也很繁琐
同时大容量的又很贵，以是利用KT148A-sop8的flash型语音芯片便是最优的办理方案
办理KT148A语音芯片运用于智能锁的两个潜在的需求
1、语音文件数量，超过手册给的233的语音地址，如果须要扩展地址，增加到500以上怎么办？
2、客户的语音很多，但是都很小，按照原有的打包办法，非常的占空间，导致空间不足
办理方案2.1 地址超过233的办理方案
==》新增F4指令，详见手册“KT148A语音芯片利用手册_V5.pdf”
F4指令存在的意义，是语音超223的数量之后没有地址可用的问题，以是新增此指令。举例解释：
1、如果指定播放291地址的语音，就发送F4 01 23 【01=0x01 高字节】【23=0x23低字节】
==》个中F4为识别码，01 23 组成为0x123 = 291 ，代表第291条语音播放
2、如果指定播放291个语音，就发送F4 04 98
==》发送F4 04 98，个中04 98 组成位0x498 = 1176 ，代表第1176条语音播放
3、这个F4指令的长度，只能是三个字节【不能多也不能少】，收满F4 01 23之后，急速开始实行播放
4、收到F4指令之后，会自动等待100ms，如果在这个100ms之内收到0x01这样的语音命令，还会连续再等待100ms ，
==》如果收第2个地址数据0x23，就代表收满了= 0x0123，急速实行播放291地址语音
==》超过100ms还没有收到地址数据，则认为这一次通讯失落败，由于只收到0x11
语音地址，不超过233，则不须要利用这条扩展指令。讯问客户，这种操作逻辑，客户可以接管
2.2 改换打包bin文件的办法--工具端这个步骤的处理，须要联系我们来修正，实在也不繁芜，也支持批量烧录
第1步，先把目标文件压缩，将压缩之后的文件发f1a格式，全部拷贝至“audio”文件夹里面
第2步，打开“pRFiles.exe”导入文件，天生“AUDIO.lst”
第3步：双击批处理，天生“dir_story”，把稳是没有后缀的
总结缺陷便是不再支持串口下载语音文件。语音的总空间，如上图，看这里就知道了
以是，客户前期的测试，包含语音播放的效果，通讯功能等等
都可以先用默认的版本，去调试
末了确认得差不多了，可以联系我们换一种办法，供应样品给您做末了的确认和测试。
