一、语音芯片应用于智能锁的需求
智能锁的语音播放需求中，有很多需要多国语言合并在一起的需求
其中语音文件数多，并且每个语音文件小的特点
如果使用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"，注意是没有后缀的
- 总结
缺点就是不再支持串口下载语音文件。语音的总空间，如上图，看这里就知道了
所以，客户前期的测试，包含语音播放的效果，通讯功能等等
都可以先用默认的版本，去调试
最后确认得差不多了，可以联系我们换一种方式，提供样品给您做最后的确认和测试。