上次的mmap版虽然速度提高了不少,但还是有扫描感觉。而且看到晕哥的回复:
这个速度本来就慢,
几十kHz,
内核与用户的数据同步毫秒级。
就是说linux不适合干用gpio直接驱动的事情,即使用mmap也一样。
感觉在用户层不可能再提高速度了,可是最近看到一些帖子说mmap是直接内存映射,不涉及内核层和用户层的交互。
又唤起了对mmap的兴趣,仔细研究了一下我的devmem.c文件发现,发现Writebit函数每次都调用mmap和munmap太浪费时间,其实当时就知道这个需要改但由于懒惰没太在意。这次优化后,oled刷新和裸奔应该没区别了。
源码:https://github.com/kekemuyu/f1c100s
离线
以后一些有关gpio的驱动完全可以在用户层做了
离线
也就是说 mmap / munmap 导致 dev 这个命令耗时?
是的,现在改成初始化的时候mmap一次就行了,writebit函数只是操作地址
离线
楼主你这个是128*64 的 OLED吧, 模拟SPI驱动可以做到什么帧率?
帧率怎么测?
离线
我写个测试程序测一下
离线
刷新率很不错了,1000次的整屏刷新只用了12s或者13秒,fps达到了70~80的样子,cpu是默认的408m。裸机没有做实验,理论上估计mmap方式操作gpio速度基本没有损失,因为这个是内存直接映射的寄存器。
请看视频:
离线
更进一步的思考是:mmap是否可以控制其他外设,如果可以的话,驱动层完全可以在用户层实现,对于不会做linux的驱动的提供了另一种添加外设的思路,这种方式的好处是初学者可以不理会linux的驱动模式的做法,完全用裸机的思维就可以添加需要的外设了。下一步是用mmap方式驱动spi,如果可以的话,证明这种思路是可行的。
最近编辑记录 kekemuyu (2020-05-04 16:24:53)
离线
思路挺好的,但是开销也蛮大,408MHz/128/64/70 = 700
写一个bit,700个指令周期
通过i2c/spi驱动写入,数据丢给内核就不用管了,
内核如果丢给了dma,就更好了.
这个只是测试一下刷新的极限,平时不会这样用的。就像smartcar说的,只有需要改变内容时才刷一下。当然你说的这些外设如果能用mmap方式实现就更好了,下一步就是验证这些外设
最近编辑记录 kekemuyu (2020-05-04 16:41:27)
离线