https://github.com/bigmagic123/d1-nezha-rtthread 这个是有个兄弟提供的rtthread, 我测试的时候发现经常性的宕机,一直找不到问题,
还找到一个freertos也是运行几分钟就宕机的,有没有能正常用的rtos啊,f133用rtos非常合适啊...难道大家都跑linux?
离线
F133没有非常合适RTOS这一说法吧,普通的RTOS只有线程没有使用MMU来跑进程,稳定性差太多,线程一崩整个系统就崩掉了,白白浪费了这么可贵的MMU。
而支持使用MMU跑进程的RTOS的源码架构都跟Linux的差不多,而RTOS的底层驱动又没Linux的多,所以还不如跑Linux。
另外,官方没有RTOS的SDK,也没有可靠的社区维护RTOS的支持,单靠几个散户移植的源码真的很难保证稳定性。
PS:很多人在本站开放源码都只是贴个附件,而没有使用gitee这种平台来聚集大家的力量。可能很多人都是使用Keil这种对git不怎么支持的开发工具吧,所以git用得少,自然也没怎么用gitee。
最近编辑记录 海石生风 (2022-03-21 08:37:16)
离线
@海石生风
你说的都对,但是linux启动太慢,我们需要启动100ms这样的场合,linux根本满足不了需求,在linux和mcu中间还是有rtos这样的生存空间的,rtt也出了rtt smart用来填补这里的空白 ,全志也有自己的melis系统,说明还是有需求的,
离线
后面提供,有这个计划
离线
后面提供,有这个计划
太好了 可以问一下大概需要什么时候吗 还有t113能否也安排上
离线
midnight 说:后面提供,有这个计划
太好了 可以问一下大概需要什么时候吗 还有t113能否也安排上
😂 好像有些不对,更多的应该是D1,在等DevTerm的risc-v版本,那个是D1
离线
smiletiger 说:midnight 说:后面提供,有这个计划
太好了 可以问一下大概需要什么时候吗 还有t113能否也安排上
😂 好像有些不对,更多的应该是D1,在等DevTerm的risc-v版本,那个是D1
基本上一样的,就是外设少一点,ddram初始化不一样
离线
那在官方没出RTOS之前用XBOOT就好了,XBOOT的稳定性应该好点,来看xboot大侠一直都在更新XBOOT
xboot不支持lvgl和awtk等这些gui啊
离线
支持lvgl这种也就分分钟,作为裸机平台,这个是可以的,反正随意改造,代码足够清晰,不会带你入坑的。
离线
支持lvgl这种也就分分钟,作为裸机平台,这个是可以的,反正随意改造,代码足够清晰,不会带你入坑的。
现在学习全志的芯片都是从xboot开始的,但是没有系统学过xboot都是扣驱动和初始化代码用的,惭愧惭愧,看到新出的t113又心动了,不知道和f133比哪个更能打,现在gui主要使用awtk的,xboot是否也可以考虑支持一下啊,实在没有多少精力各种折腾了,
离线
看了下rt-thread的代码仓库,发现rt-smart的分支有D1的BSP。这个BSP应该是专门为rt-smart设计的,但考虑到rt-smart是混合式微内核,并且其他为rt-smart添加的BSP都支持rt-smart跟rt-thread,所以这个BSP应该也支持rt-thread的线程式内核模式。
另有官方论坛上的描述:https://club.rt-thread.org/ask/question/431693.html
离线
@海石生风
话不能这么说的,RTOS相对于linux还是比较小规模的,规模小自然就比较好控制。linux核心和驱动崩溃了怎么保护?难道不一样的道理?
离线
@海石生风
话不能这么说的,RTOS相对于linux还是比较小规模的,规模小自然就比较好控制。linux核心和驱动崩溃了怎么保护?难道不一样的道理?
内核驱动极少需要从零开发写(这也正是用Linux的理由),最多是移植下改下参数,所以内核驱动是经过行业的测试的,所以不容易崩;核心崩的概率跟中彩票的差不多了吧。
像X86平台的Linux,很少人会说它崩吧。
嵌入式开发,现在绝大多数是用C/C++开发,真的稍不留神就会出现内存访问相关的错误导致崩溃。所以要想安稳,要么上进程、要么用类似rust这样有安全保证(不求绝对安全,但求不容易出错)的开发语言。
最近编辑记录 海石生风 (2022-03-27 21:40:07)
离线
首先说几句题外话,linux内核经过行业测试没错,但是也不能排除设备驱动程序写得蹩脚,宏内核的linux系统一样会崩掉。常用的RTOS获得各种安全认证,比如国产的RTT就获得了ISO 26262 ASIL D、IEC 61508 SIL 3、EN 50128 SIL 4几项安全认证,已经发射上天了。
回到正题,我明白你的意思是MMU可以隔离进程,即使进程崩掉也不会导致系统宕机。这个其实只是理想情况,质量差劲的APP也会吞噬系统资源,让系统处于不死也不活的状态。对于APP崩溃了不影响系统安全的说法,那我还可以说RTOS养条狗还可以无限复活呢。
系统的稳定性跟很多因素有关,很难简单去辩证,复杂的系统也可以很稳定,简单的系统也可能很差劲。
但是从工程管理的角度看,RTOS因为具有代码规模比较小的优势,可控性更强,代码质量更容易管理,所以RTOS的可靠性一般更高。
离线
其实我强调的是有MMU跟无MMU的区别,在消费电子领域看重开发效率的情况下才用了Linux这个带MMU方案。在航空航天领域绝大部分的核心系统都是使用带MMU的RTOS,如VxWorks、RETMS等。
使用MMU来隔离进程,不只是为了有力减少宕机,还为了保证系统数据的完整性和提高防入侵等级。
如果没有隔离的话,假设一个任务在写文件系统或数据库时其内存被别的任务因内存访问异常而使这个任务待写入的数据受到污染,这时即使文件系统或数据再可靠也难以保证写入数据的完整性和正确性。如果这是一个飞行记录仪的话,这将是灾难性的。
提高防入侵等级则是因为MMU使系统关键数据在内存里的物理地址不是固定的,入侵者难以获取有用的关键数据。
所以无论RTT过了什么认证,没有MMU加持,在安全性要求高的场合用起来心里还是没底的。
最近编辑记录 海石生风 (2022-03-29 12:11:31)
离线
RTT咋会没有MMU加持呢?后面提供出来的D1的版本就是带MMU特性RTT smart版本
离线
RT-Smart有对D1/F133做支持,那个芒果MQ F133就可以跑这个系统。参与过这个bsp开发的。
离线
RT-Smart有对D1/F133做支持,那个芒果MQ F133就可以跑这个系统。参与过这个bsp开发的。
现在rt- smart 对d1外设驱动支持的怎么样了 ?常用外设驱动都支持了吗
离线
离线