[MENU]菜单开发计划整理

[CkovMk]

菜单无法拷贝不同数据区内存储的数据

完善功能：Status变量：保存状态Flag。
新增功能：新增APP_MENU_PLUGIN插件子模块，第一个插件：CMB分区保存CmBacktrace报错信息、assert报错信息等。第二个插件：LittleRookieChess

修改逻辑：增加二级菜单能调整的有效数字位数（暂时好像做不到）

抽象显示接口
菜单显示方式更改为全缓存
GetW()
GetH()
SetPixel(x, y, value)
Update()

新增菜单全局属性Flag
选项：菜单快速调参开关等

新增类型：version显示类型

新增类型：infoType，显示一段提示语

[CkovMk]

关于菜单存储的一些想法

现在我们主要使用三种存储：Flash、EEPROM和SD卡。其中：只有SD卡有文件系统支持，EEPROM容量较小但可以随机读写，Flash则不可随机写入，必须先擦除再写入。这些特点各异的存储介质使得抽象出一个统一的存储接口十分困难。
目前菜单仅支持Flash存储，采用的策略是惰性缓存。
如果使用SD卡，很显然我们将使用文件存储。虽然使用文件模拟一个块级存储十分容易，但是惰性缓存策略就显得十分臃肿且没有必要。
EEPROM则是可随机读写的块级存储，可以很方便地实现与文件模拟块级存储的兼容。

综上所述，最大的问题出在Flash存储上。一个可能的解决方案是，给Flash也套上文件系统。但是几百KB的Flash空间，真的有必要上文件系统吗？

也许还可以为flash和文件创建不同的接口。但这样维护起来十分不便。

最后，还有一种方案是直接把数据写入内存，不论任何存储介质，都可以一次性将数据写入。这样做的缺点是占用内存较高。现在APP_MENU中的一个数据项会占用32Byte空间，如果128个参数就会占用3KB内存。这个内存开销对于K66其实是可以接受的。但如果考虑到要兼容一些低端单片机，就不能使用这种方案。

[CkovMk]

增加hide属性，在菜单列表内隐藏？
有这个必要吗？

增加一个新的类型 dataType，用于存储大量数据（数组）。但这类数据要如何编辑？

[CkovMk]

关于菜单存储的一些想法

现在我们主要使用三种存储：Flash、EEPROM和SD卡。其中：只有SD卡有文件系统支持，EEPROM容量较小但可以随机读写，Flash则不可随机写入，必须先擦除再写入。这些特点各异的存储介质使得抽象出一个统一的存储接口十分困难。
目前菜单仅支持Flash存储，采用的策略是惰性缓存。
如果使用SD卡，很显然我们将使用文件存储。虽然使用文件模拟一个块级存储十分容易，但是惰性缓存策略就显得十分臃肿且没有必要。
EEPROM则是可随机读写的块级存储，可以很方便地实现与文件模拟块级存储的兼容。

综上所述，最大的问题出在Flash存储上。一个可能的解决方案是，给Flash也套上文件系统。但是几百KB的Flash空间，真的有必要上文件系统吗？

也许还可以为flash和文件创建不同的接口。但这样维护起来十分不便。

最后，还有一种方案是直接把数据写入内存，不论任何存储介质，都可以一次性将数据写入。这样做的缺点是占用内存较高。现在APP_MENU中的一个数据项会占用32Byte空间，如果128个参数就会占用3KB内存。这个内存开销对于K66其实是可以接受的。但如果考虑到要兼容一些低端单片机，就不能使用这种方案。

现在的想法是：

1. 新增一个配置项“GRAIN”，表示每次发送的字节数。该数据必须是"单个菜单项要写入数据"的倍数。每次攒够足够多的数据就发起读取/写入。
2. 地址saveAddr不再对应物理地址，而是成为唯一编号（即使是在global和region区也不能重复），一旦有重复将会报错提示。
3. 当菜单结构变化时，如果saveAddr和nameStr均未变化，则自动匹配。如果saveAddr和nameStr改变，需要用户手动确认。

[CkovMk]

增加可裁剪功能？感觉没太大必要？
完全迁移至C++ API