|
本帖最后由 huangxuejia-29212 于 2019-3-10 23:15 编辑 以前陆陆续续在论坛发了一些讨论分享。 由于被拉创业，本来打算尽快完成的文档整理今天终于算做完，但还不完善。 思考再三，还是打包发布。 同时建QQ讨论群：767214262， 欢迎大家加群讨论。众人拾柴火焰高。 我们的目标：做一套能用的开源驱动代码。 /*git hub 代码修改记录： 20190310 增加zbar_develop分支，基于407和OV2640，能解码，效果不理想，待优化 20190227 增加电子纸IL91874驱动芯片驱动。 待优化，电子纸刷新很慢，目前软件都是发送数据就更新了，当现实多行分开的内容时，这样的方案不理想。 后续要修改为：指定显示区域------发送数据到显存--------进行refresh操作，三步式。 */ 为了新来的朋友了解，重新说下过程。 缘由 多年工作，发现很累，经常重新发明轮子。而且很多代码架构不好。 扩展，移植都很难，有时候一点新需求，就要折腾很久。 对于新人学习来说，也是一直要经历老人被坑过的坑。 因此决定抛砖引玉，整理自己多年开发的思路，在github上开源了代码。 硬件设计 为了表现代码设计思路，需要硬件做配合。 例如： 1. OLED，可能接在硬件SPI上，也可能用IO模拟的SPI，也有可能是I2C接口。 2. 1个SPI上皆有多个设备，程序要如何编写驱动？ 3. 同一个SPI接口，当接上不同的设备，例如 OLED或RF24L01，程序要怎么做才能改动很小？ 4. 同一个SPI接口，用于接LCD，今天接OLED，明天换COG LCD，后天换TFT LCD，程序要怎么做，在换LCD时，改动容易？ 找了一遍，没有找到能配合的硬件，只要自己设计了一款。 
如上图，小，接口设计精巧，硬件配置也是经过长期考虑精心选择的。 最主要是，能满足我对代码架构的需求。 软件架构 软件架构是一个很复杂的事情，请看教程文档。 这里，我们只对下面一个框架说明 
这个图示LCD的框架设计 1 SPI分两个概念，控制器和通道。控制器就是CLK、MISO、MOSI。 通道，就是控制器加上片选。为什么这样设计？请看文档说明。 2 对不同的LCD硬件接法抽象，得到一个硬件接口抽象层。 3 驱动层，是不同的LCD驱动芯片的代码。对于多有的驱动，全部符合一个统一的接口。 4经过上面这样设计，一个OLED LCD，原来接在I2C接口上，非常容易就可以将它改到SPI接口。 以前发过一个帖子，大家可以围观：https://www.stmcu.org.cn/module/forum/thread-615814-1-1.html 资料在压缩包中，欢迎下载，github路径在文档中有，需要代码的自己去取。 未来 1. 添加更多驱动。 2. 选更多组件进行分析，例如spifs、littlefs。 3. 尽量在下一个版本添加驱动统一管理模块。 一句话：让我们一起开阔眼界，避免重复发明轮子。 
移植uboot命令行.pdf
(476.46 KB, 下载次数: 79)
|
微信公众号
手机版
2、目的是想将驱动的共性部分合并，但是还不如自己重新写代码。我打个比方，比如说楼主提到过的SPI驱动的屏幕，我之前用过类似的串口的触摸屏，SPI的配置部分是通用的，这个可以用STM32CubeMX来配置，那么接下来问题来了，屏幕之间不同的驱动时序图要怎么合并？就算有几个楼主列出来的型号是可以通用的，如果用户开发用到是别的型号，而选用的型号不符合怎么办？
3、如果定位就是卖开发板，实用性上不如官方的探索板与评估板，这外设还要自己去外接呢。楼主是想要切哪一个细分市场的蛋糕自己要想清楚，即使说不走商业化，开源硬件也是要有自己的独特定位才能够被开发者持续关注并使用的。
这没任何问题，是我疏忽了。
AMetal框架?
对的，感觉不错
可以的