“RTEMS 爱好者之家” 群八月讨论

问题1：

LL (191742441)：

ARM AT91RM9200的中断向量的放置地址如何做处理的？AT91RM9200的BSP中，并没有找到REMAP的地方。

 

雪松回答：

RTEMS是通过MMU实现的中断向量地址的映射。MMU实现的方法比较通用一些，通过寄存器映射的方法比较小众。

 

 

问题2：

LL(191742441)：

前段时间我用我的开发板at91rm9200+ dm9161，rtems自带的ftp服务器;我传了400多M的文件到/dev/null。速度在1500000byte per second。(1.5MBps) 好像有些慢了。你的试验呢？速度大概到多少呢？

 

雪松：

对不起，我没做过相关的实验。

 

LL(191742441)：

原因我查了下，其实大多数是中断写SRAM的时候，没有缓存了。然后丢包、TCP重传就来了；速度就下来了。在想如果缓存开在SDRAM中，让DMA直接写SDRAM，效果会怎么样呢？

 

我在中断里面，网卡的统计变量中加了两个变量。读EMAC接收寄存器的状态，然后再打印mbuf的统计；mbuf总是很充足，没有drop。所以应该就是中断没缓存写了。

 

雪松：

DMA需要申请总线，代码在跑，也需要访问总线。两个是竞争的关系。

 

LL(191742441)：

我也想过这个问题。但是DMA写SRAM的时候，就不竞争了么？我觉得这时候也会有竞争啊。

 

雪松：

有，但会好很多。首先，一般情况下芯片内部SRAM的访问周期比SDRAM短。其次，SRAM没有刷新时间以及突发访问等问题。从RTEMS代码上看，SRAM只放置了向量和网络缓冲区。使用SDRAM当然也可以，由于代码也放置在SDRAM里工作，最终效果不是增大缓冲区和性能成正比的。需要结合硬件具体分析。

 RTEMS的BSD协议栈有些老旧了。所以效率也是个问题；

 

问题3：

霜月孤鸟(154292501)：

LL跑的那个ftp的程序是，network-demos文件夹下的tftpTest么？

 

LL(191742441)：

用函数 rtems_initialize_ftpd 实现的。

 

问题4：

雪松：

移植过来的FreeBSD TCP/IP协议栈很稳定；但是效率不高。特别是拷贝过程比较多；对于有DMA的处理器，发送接收时大多数情况下都必须拷贝一次数据。不过OAR已经注意到这些问题了。会改进这一设计。

 

问题5：

雪松：

关于CPU速度的比拼：

http://en.wikipedia.org/wiki/Million_instructions_per_second#Million_instructions_per_second

 

 

问题6：

周日9:00~10:00讨论MUTEX，全体群人员参与。

这里首先纠正一个术语，关于互斥。操作系统里是没有互斥的概念的。只有进程的同步与通讯。进程的同步的主要任务，是使并发执行的诸进程之间能有效地共享资源和相互合作，从而使程序的执行具有可再现性。

 

纯软件是有不少可以实现MUTEX的办法，但大都是不可靠的。在单个CPU上，只有一个软件办法可以实现MUTEX，那就是关闭中断。其实，单个CPU中，CPU在同一时间内只能执行一个线程的代码。这里就有个问题了，怎么才能执行第二个线程的代码？操作系统怎么实现这个过程的？只有搞清楚这个过程，才能堵住漏洞，保证操作过程不被打断。首先是中断；其次是当前正在执行的线程主动放弃CPU的执行权。但进入临界保护的时候，线程傻了才主动放弃执行权。所以只有中断! 关闭中断理所当然的可以实现单个CPU上的临界保护，也就是MUTEX

 

多个CPU就麻烦些。A CPU的线程关了中断，并不能阻止B CPU线程的执行。B CPU线程依然好好的在跑。只能是采用test-and-set指令。还有SWAP指令。linux下的spin锁，就是SWAP指令实现的。这个是同构的CPU

 

异构的CPU的MUTEX需要通过通讯来实现，通过Proxy，转化成单CPU的MUTEX。

 

RTOS上的MUTEX有一个问题，就是优先级别反转的问题。是的，一个是优先级置顶算法，一个是优先级继承算法。优先级置顶算法很简单，没啥好说的。一般用于比较简单的场合，比如说两三个线程竞争的场合。多了就不适合了。优先级继承算法，就稍微复杂一些。属于动态调整和调度。但这属于对RMS算法的一个非常有效的改进。有三个线程，ABC，A最高，C最低。C先获得一个Mutex1，B后申请Mutex1,C优先级被提到了B同等的优先级别。C在临界区内又获得了Mutex2，随后，A也去申请Mutex2，结果C在被提升到B优先级之后，又被提升到A优先级别。算法本身是没有问题的，但是C线程释放Mutex2，然后再释放Mutex1，优先级别怎么变化的呢？合理的方案是释放了Mutex2，就恢复到B的优先级，释放了MUTEX1就恢复到原来的优先级，但如果没按照申请顺序释放又怎么办呢？RTEMS给的解决方案是释放所有的Mutex后，一次性恢复到原来的优先级别。在释放过程中，是不恢复优先级别的。另外，就提醒一下大家，虽然uc/os-III支持优先级继承，实际上这种问题是没有解决的。优先级继承后，只被提升一次是没问题的，被提升了超过2次就有问题了。系统就错乱了。

 

问题7：

更深的蓝(621394)：

#include<unistd.h>

intmain()

{

Write(1, “\033[H\033[J”, 6);

return (0);

}

我分析了busybox源码，&#160;它的实现就是我贴出的代码。基本上这就是正规做法了，一般的终端软件都能接受。

 

霜月孤鸟(154292501)：

TO:更深的蓝

昨天你提供的解决rtems下刷屏的方法，我今天试验了下，是可以的我的用的平台是PC104+普通的显示器，你提供的方法可行。还存在一个问题：刷屏的时候闪烁特别明显，而在同样的平台上跑dos下的刷屏程序，闪烁不明显。