RT-Thread/STM32F103VB 0.3.0 beta版本

发布于 2009-03-26 23:21:12
从RT-Thread 0.3.0的STM32F103ZE版本中分支出来,主要对原来0.2.4版本中firmware进行更新,更新到ST的2.0.3版本。由于ST的STM Firmware v2.0.3是和STM32F103E评估版一起推出的,所以里面带了E系列的一些功能,但这些是VB系列所不需要的,所以把其中一些不必要的进行剪裁。

这个版本的默认配置如下:
RT-Thread Kernel + FinSH
内核对象名称大小 8字节
线程支持优先级 32
每个tick时长 10ms
使用Hook
使用Semaphore,Mutex
使用Event,MailBox,Message Queue
使用Memory Pool,Small Memory的Heap管理
使用FinSH,并支持符号表、符号描述
下载附件[rt-thread-0.3.0-stm32f103vb.zip]

查看更多

关注者
0
被浏览
31.2k
54 个回答
dragonwww
dragonwww 2009-03-27
效率如此之高,佩服佩服 [s:157]
忽然想起了孙悟空去东海龙宫寻兵器,到定海神针铁面前说到:再细点、再小点!最终眼睛一亮:金箍棒出世了!
bernard
bernard 2009-03-30
效率如此之高,佩服佩服 [s:157]
忽然想起了孙悟空去东海龙宫寻兵器,到定海神针铁面前说到:再细点、再小点!最终眼睛一亮:金箍棒出世了!


dragonwww,你有STM32F103VB的开发板吗?万利 还是 那种Mini版本的?

能否说说你的情况,
1、学习 or 用于产品
2、运用于哪方面?(上次你似乎说了是连GPRS模块的)
3、对OS的需求
dragonwww
dragonwww 2009-03-30
我的情况是:买的是万利的STM32F103VB的开发板,当然想是用于产品,但现在对OS还是不太熟悉,还在学习阶段。
我最初是用汇编玩单片机的,后来用了C51,现在觉得STM32很牛X,所以想转向它,有了它就想上个OS,这不,盯上RT-Thread了 [s:160]
想用到无线数传上,想加GPRS和GPS模块,现在想法是有了,关键是如何实现了,OS和C51的编程还是很不同的,我说过我是一名伪程序员,不是科班出身的,所以对我来说还是有点难度的。
至于对OS的需求,我觉得稳定、简单、好用最重要,而且可能到时连STM32F103VB都不用,会用更便宜的STM32F103R系列的,64pin,对于产品来说成本很重要。
再说点个人感受:大多数嵌入式的串口资源很宝贵的,所以FinSH对我来说用途不大,何况它要占用一个串口,产品运行起来也不会通过它来调试的。
bernard
bernard 2009-03-30
我的情况是:买的是万利的STM32F103VB的开发板,当然想是用于产品,但现在对OS还是不太熟悉,还在学习阶段。
我最初是用汇编玩单片机的,后来用了C51,现在觉得STM32很牛X,所以想转向它,有了它就想上个OS,这不,盯上RT-Thread了 [s:160]
想用到无线数传上,想加GPRS和GPS模块,现在想法是有了,关键是如何实现了,OS和C51的编程还是很不同的,我说过我是一名伪程序员,不是科班出身的,所以对我来说还是有点难度的。
至于对OS的需求,我觉得稳定、简单、好用最重要,而且可能到时连STM32F103VB都不用,会用更便宜的STM32F103R系列的,64pin,对于产品来说成本很重要。
再说点个人感受:大多数嵌入式的串口资源很宝贵的,所以FinSH对我来说用途不大,何况它要占用一个串口,产品运行起来也不会通过它来调试的。


如果你确定下来把RT-Thread用于产品中,可以获得RT-Thread的免费技术支持:
- 12小时内Email/论坛答复
- 和OS相关的问题追踪及修复
- (软件)系统设计上的咨询

至于用STM32哪个系列这个需要你来定了,RT-Thread最小的基本系统基本要求是:10K ROM,2KRAM。STM32F103R6/8都能满足,STM32F103R6资源稍微紧张些。

RT-Thread是一个可裁剪的系统,如果是用GCC作为开发环境这点尤为明显,所以FinSH如果不需要,只需要在rtconfig.h中把相应的宏注释掉,在工程中删除掉finsh group就可以了。
dragonwww
dragonwww 2009-03-30
to bernard:
你的回复更加坚定了我用RT-Thread的信心了,不过对于我这伪程序员可能会给你们添不少麻烦,要有心理准备啊 [s:154]
其实真的挺羡慕你们:可以全身心的去投入到自己喜欢做的事情中去,可以看着自己的孩子--RT-Thread慢慢长大,人生在世,总得留下点什么才好,呵呵,扯远了。
dragonwww
dragonwww 2009-03-30
另外报告一下:简单的注释掉#define RT_USING_FINSH还不够,
start_rvds.s中把USART1的中断处理函数USART1_IRQHandler重定向到了rt_hw_uart_rx_int,而
board.c中rt_hw_uart_rx_int用的#ifdef RT_USING_FINSH预处理,简单的注释掉会产生一个Error: L6218E: Undefined symbol rt_hw_uart_rx_int (referred from start_rvds.o).
所以我觉得还应该在start_rvds.s中改回来:
;IMPORT rt_hw_uart_rx_int
IMPORT USART1_IRQHandler
....
;DCD rt_hw_uart_rx_int
DCD USART1_IRQHandler
不知道官方答案是什么啊? [s:157]
bernard
bernard 2009-03-30
是的,目前确实是这样。

这个也仅仅针对于STM32的移植才是这样的,而接下去几天会给一个修正的,带串口通用设备接口的版本。这个版本将不存在这个问题。。。
dragonwww
dragonwww 2009-04-03
请问新版本何时放出?
另外有个问题请教:多串口操作时我使用两个串口,速率都是115200,开了三个线程,思路是开两个缓冲区,设两个信号量,串口中断中保持字串到各自的缓冲区,收到字符结束时发送信号量,主程序中负责处理数据的线程查询信号量进行处理,也就是把收到的字串再打印出来,单独操作时每个都是好用的,但两个同时工作时就会乱码,不知是哪里的问题啊?我在中断函数中使用下面的结构还是有乱码,我改到tick为1ms也没解决,
/* enter interrupt */
rt_interrupt_enter();

/* do interrupt service routine */

/* leave interrupt */
rt_interrupt_leave();
rt_hw_interrupt_thread_switch();

请问串口中断中用不用上面的结构?多串口编程采用什么结构可以更稳定?多谢!
bernard
bernard 2009-04-03
不知道你是如何处理的。说说我会采用的设计:(结合新版的串口设备接口)

串口驱动包含三个回调函数:
rx_indicate(rt_device_t dev, rt_size_t size);
tx_complete(rt_device_t dev, void* buffer);
status_indicate(rt_device_t dev, rt_uint32 status);

rx会在接收到数据时调用,size给出接收到的数据长度。
tx会在发送完成时调用,buffer给出发送完的数据块指针。
status会在出错或设备状态(例如网络接口设备link down、link up)改变时调用

假设两个串口分别是UART0, UART1

那么处理线程可以是(假设只需要处理接收,而发送是采用polling方式):
初始化部分代码:
rt_device_t device;

// 获得UART0的设备句柄
device = rt_device_lookup("UART0");
rt_device_set_rx_ind(device, mythread_rx_ind);

// 获得UART1的设备句柄
device = rt_device_lookup("UART1");
rt_device_set_rx_ind(device, mythread_rx_ind);

/* 创建一个mailbox */
mymailbox = rt_mb_create(...)

处理线程:
// 消息定义
#define MSG_RX_IND 1
struct mythread_msg
{
rt_uint8_t msg_type;
rt_device_t dev;
};

// 处理线程入口
mythread_entry()
{
struct mythread_msg* msg;
char buffer[128];
rt_uint32_t length;

while (1)
{
// 从信箱接收消息
if (rt_mb_recv(mymailbox, &msg) == RT_EOK)
{
if (msg->msg_type == MSG_RX_IND)
{
length = rt_device_read(msg->dev, &buffer[0], 0, 128);
if (length == 0) continue;

/* 数据处理,放在buffer中,长度是length */
...
}

/* 释放消息内存块 */
rt_free(msg);
msg = RT_NULL;
}
}
}

// 数据到达回调函数
void mythread_rx_ind(rt_device_t device, rt_size_t size)
{
struct mythread_msg *msg;

/* 因为是通过邮箱发送消息的地址,所以需要动态分配个消息结构 */
msg = (struct mythread_msg *)rt_malloc(sizeof(struct mythread_msg));
if (msg != RT_NULL)
{
/* 填充消息 */
msg->dev = device;
msg->msg_type = MSG_RX_IND;

/* 发送到信箱 */
rt_mb_send(mymailbox, msg);
}
}
bernard
bernard 2009-04-03
使用以上的这种方式,只需要使用一个线程就可以了。

新版本我会尽快放出,其中就包含新版本的设备驱动接口。
dragonwww
dragonwww 2009-04-03
静候佳音,呵呵,RT-Thread的面向对象编程的思想很有个性啊 [s:157]
LEAN
LEAN 2009-04-05
最近在学习使用STM32上适用的RTOS,目前就接触过FreeRTOS。
关注RT-Thread差不多也有一个礼拜了,看了一些相关资料和文档后,感觉RT-Thread的开发主线很明确而且团队也很有底气。很棒!:D

不过我目前出现的小小问题:
我用的是万利的LK1板子,今天下了份STM32F103VB 0.3.0 beta版本。代码没有修改只是用RVMDK编译后调试,发现执行rt_application_init后,就进入HardFaultException循环了。
不知道是不是用了新FWLib的问题(FreeRTOS V5.2.0换成FWLibv2.03也会有此问题)?还是什么地方我没有配置好?
bernard
bernard 2009-04-05

不过我目前出现的小小问题:
我用的是万利的LK1板子,今天下了份STM32F103VB 0.3.0 beta版本。代码没有修改只是用RVMDK编译后调试,发现执行rt_application_init后,就进入HardFaultException循环了。
不知道是不是用了新FWLib的问题(FreeRTOS V5.2.0换成FWLibv2.03也会有此问题)?还是什么地方我没有配置好?


这点我昨天在STM32F103ZE上也出现了,原因是:STM32启动后默认中断是打开的,当执行完rt_hw_board_init后,时钟中断会被触发(除非中断触发前系统已经初始化好),当时钟中断触发后,系统会检查当前线程的时间片是否用完。而此时如果系统没初始化完毕,当前线程是空,会直接进入HardFaultException(RT-Thread老的版本在HardFaultException处理上也存在问题,应该需要进入死循环的,但是直接返回)。

针对这个问题,需要在main函数中添加关中断的代码,整个main函数如下:

int main()
{
rt_uint32_t level;

/* disable interrupt firstly */
level = rt_hw_interrupt_disable();
rtthread_startup();

return 0;
}


而HardFaultException则需要修改成和你说的类似,进入死循环:

void HardFaultException(void)
{
/* Go to infinite loop when Hard Fault exception occurs */
rt_kprintf("hard fault exception
");
while (1)
{
}
}

下个版本会修正这个问题。
LEAN
LEAN 2009-04-05
在main函数中关闭硬件中断以后,线程任务是可以跑起来了。但是也存在一些问题。

在RVMDK模拟环境中,thread1 和 thread2 都能获得时间片执行。finsh shell 在模拟串口内也输出版本信息和命令行提示符等。
可是当我在线调试时,finsh shell 输出数据似乎有点不正常,具体数据如下:

finsh>>sh>>insh>>0                  
Null node
finsh>>>alid token
0, 0x0000
finsh>>sh>>insh>>0
Null node
finsh>>>alid token
0, 0x0000
finsh>>sh>>insh>>0
Null node
finsh>>>alid token


整个过程都在不停读写串口。而且thread1 和 thread2 只有thread1得到运行机会thread2没有。
我打算屏蔽掉finsh以后再试试看。
dragonwww
dragonwww 2009-04-05
呵呵,问题问的很及时啊,我刚焊好板子,直接就拿RT-Thread来实验,结果错误,我还以为是板子有问题呢,呵呵,技术支持很有必要 [s:154]
pupist
pupist 2009-04-05
在我的万利的班子上一转 就停在这个里面了 HardFaultException 什么原因呢 realview mdk似乎看不见 调用栈
bernard
bernard 2009-04-06
在main函数中关闭硬件中断以后,线程任务是可以跑起来了。但是也存在一些问题。

在RVMDK模拟环境中,thread1 和 thread2 都能获得时间片执行。finsh shell 在模拟串口内也输出版本信息和命令行提示符等。
可是当我在线调试时,finsh shell 输出数据似乎有点不正常,具体数据如下:

finsh>>sh>>insh>>0                  
Null node
finsh>>>alid token
0, 0x0000
finsh>>sh>>insh>>0
Null node
finsh>>>alid token
0, 0x0000
finsh>>sh>>insh>>0
Null node
finsh>>>alid token


整个过程都在不停读写串口。而且thread1 和 thread2 只有thread1得到运行机会thread2没有。
我打算屏蔽掉finsh以后再试试看。


这个样子似乎是串口驱动有些问题。说说你的具体情况吧,thread1、thread2在干什么?两个都在不停的读写串口?你可以检查下现在代码中的串口驱动,是否和万利自己给的不一样。

另外一个,目前RT-Thread的打印函数是输出到一个全局变量的buffer中,并且是没有保护的,所以如果是多个任务去同时打印,也是有可能有问题的。你可以考虑试着修改kservice.c中的rt_kprintf函数成如下这个样子:

void rt_kprintf(const char *fmt, ...)
{
va_list args;
rt_uint32_t level;

va_start(args, fmt);

/* disable interrupt to lock scheduler */
level = rt_hw_interrupt_disable();
vsnprintf(rt_log_buf, sizeof(rt_log_buf), fmt, args);
rt_console_puts(rt_log_buf);
/* enable interrupt */
rt_hw_interrupt_enable(level);

va_end(args);
}


(至于为什么没在代码中直接采用关中断的形式,那是因为如果要输出一个比较大的数据会立马造成实时性能的下降。所以,如果上层应用需要多任务的方式操作输出,可以在上层添加互斥操作(semaphore会更好些))
bernard
bernard 2009-04-06
在我的万利的班子上一转 就停在这个里面了 HardFaultException 什么原因呢 realview mdk似乎看不见 调用栈


请参考我上面的帖子,谢谢。
dragonwww
dragonwww 2009-04-06
新版什么时候放出啊?急切盼望中 [s:179]
最好可以实测一下多串口,甚至是3个串口同时工作的情况,能有例程最好了,以及讲一下RT-Thread多串口编程中应该注意的事项。毕竟嵌入式中串口用的还是最多的。
bernard
bernard 2009-04-06
新版什么时候放出啊?急切盼望中 [s:179]
最好可以实测一下多串口,甚至是3个串口同时工作的情况,能有例程最好了,以及讲一下RT-Thread多串口编程中应该注意的事项。毕竟嵌入式中串口用的还是最多的。


应该是今天吧。
LEAN
LEAN 2009-04-06
USART初始化正确RT-Thread版本信息是可以正常输出的。 我测试的thread1和thread2是默认演示代码,不过即使用户线程中不做任何输出,finsh一样出错。

经过跟踪分析得出:
(shell.c)[116]: rt_kprintf("finsh>>"); 输出shell提示符
(shell.c)[127]: ch = rt_serial_getc(); 读到上一次输出"finsh>>0x0A0x0D"字符0x0D
(shell.c)[135]: 判断为一个finsh shell语句并增加";"结束符
(shell.c)[146]: 向串口输出该shell语句
(shell.c)[147]: finsh_parser_run(&parser, (unsigned char*)&line[0]);解析该shell语句,但似乎并没有检测出是无效空白语句
(shell.c)[150]: 条件成立
(shell.c)[152]: 编译该shell语句但仍就未发现错误finsh_errno() == 0成立
(shell.c)[162]: 将编译后的语句载入虚拟机执行
(shell.c)[173]: 打印出堆栈" 0, 0x0000"
(shell.c)[179]: finsh_flush(&parser);
循环回到116行
(shell.c)[116]: rt_kprintf("finsh>>"); 输出shell提示符
(shell.c)[127]: ch = rt_serial_getc(); 读到"finsh"字符串
...

接下去恶性循环就开始了。

以下是在万利板子上串口输出的信息
  | /
- RT - Thread Operating System
/ | 0.3.0 build Apr 6 2009
2006 - 2009 Copyright by rt-thread team
finsh>>
0, 0x0000
finsh>>finsh
Unknown symbol
finsh>>
0, 0x0000


刚才又和模拟器调试对比了下,发现在板调试时rt_hw_uart_rx_int在rt_console_puts时都会中断导致错误地执行finsh_notify();释放信号,但是在模拟器中不会。
pupist
pupist 2009-04-06
在我的万利的班子上一转 就停在这个里面了 HardFaultException 什么原因呢 realview mdk似乎看不见 调用栈


请参考我上面的帖子,谢谢。


还有就是 我想用你们的 editminus 但是论坛的下载不到
bernard
bernard 2009-04-06

...

刚才又和模拟器调试对比了下,发现在板调试时rt_hw_uart_rx_int在rt_console_puts时都会中断导致错误地执行finsh_notify();释放信号,但是在模拟器中不会。


奇怪,难道在F103VB上跑,串口的发送完成中断会被打开?你在rt_hw_uart_rx_int中加个判断,只在接收时调用finsh_notify去释放信号量。
bernard
bernard 2009-04-06
在我的万利的班子上一转 就停在这个里面了 HardFaultException 什么原因呢 realview mdk似乎看不见 调用栈


请参考我上面的帖子,谢谢。


还有就是 我想用你们的 editminus 但是论坛的下载不到


editminus的更新暂停,会在wxPython的下一个官方版本出来的时候考虑是否释放出新的版本,老的版本也暂时无法提供。
pupist
pupist 2009-04-06
已经在main里关中断

在同样优先级thread轮转的时候 也会有 陷入HardFaultException 出不来的问题
pupist
pupist 2009-04-06
知道原因了 优先级不支持那么多 这个应该想办法控制一下 要不然新上手的人比较郁闷.`
bernard
bernard 2009-04-06
知道原因了 优先级不支持那么多 这个应该想办法控制一下 要不然新上手的人比较郁闷.`


谢谢反馈。下次在初始化一个线程的时候做一个assert,这样就方便排查问题了。

目前RT-Thread的优先级支持两种版本,32个优先级和256个优先级。STM32F103VB默认的是32个优先级,STM32F103ZE则是256个优先级。
LEAN
LEAN 2009-04-06

...

刚才又和模拟器调试对比了下,发现在板调试时rt_hw_uart_rx_int在rt_console_puts时都会中断导致错误地执行finsh_notify();释放信号,但是在模拟器中不会。


奇怪,难道在F103VB上跑,串口的发送完成中断会被打开?你在rt_hw_uart_rx_int中加个判断,只在接收时调用finsh_notify去释放信号量。


确实是USART_IT_RXNE中断。因为rt_hw_uart_rx_int中有判断是USART_IT_RXNE才去调用finsh_notify释放信号量。我把Finsh屏蔽掉以后调用rt_kprintf输出字符串测试,如果USART_IT_RXNE中断允许的话。在发送字符串的时候就会有USART_IT_RXNE中断进来。

我曾在资料上看到TX和RX是共用一个DR的,会不会在执行USARTx->DR = (c & 0x1FF)的时候,USART认为RX not Empty然后引发中断?

这个问题调试了大半天了,因为在RVMDK模拟运行完全没有问题,脱离调试器后就出错,感觉很奇怪。
请大家帮忙验证下。谢谢
bernard
bernard 2009-04-06
LEAN,放心,我在看这个问题,串口相关的总会给个定论的。

另:
你能否检查下你的硬件?不会RX和TX线接在一起了吧。或者,你写入一个字符,产生RXNE中断,读出来的字符会是什么。
bernard
bernard 2009-04-06
新版什么时候放出啊?急切盼望中 [s:179]
最好可以实测一下多串口,甚至是3个串口同时工作的情况,能有例程最好了,以及讲一下RT-Thread多串口编程中应该注意的事项。毕竟嵌入式中串口用的还是最多的。


抱歉,今天出不了版本了。在考虑DMA传输的问题,感觉实现一个general的serial port有一定难度啊。
dragonwww
dragonwww 2009-04-06
没关系的,你们的效率已经很让我吃惊了,呵呵,至于串口统一的接口,我就是觉得那样用起来方便,没考虑到实现的难易程度,如果困难的话完全可以分开来做,我认为程序的稳定性和执行速度才是最重要的,我在没用OS之前也是分开来用的 [s:154]

ErrorStatus COM1_printf(u8* pString, u16 Buffer1Length)
{
while(Buffer1Length--)
{
/* Write a character to the USART */
USART_SendData(USART1, (u8) *pString++);
/* Loop until the end of transmission */
while(USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET)
{
}
}
return SUCCESS;
}

ErrorStatus COM2_printf(u8* pString, u16 Buffer2Length)
{
while(Buffer2Length--)
{
/* Write a character to the USART */
USART_SendData(USART2, (u8) *pString++);
/* Loop until the end of transmission */
while(USART_GetFlagStatus(USART2, USART_FLAG_TXE) == RESET)
{
}
}
return SUCCESS;
}
pupist
pupist 2009-04-06
新版什么时候放出啊?急切盼望中 [s:179]
最好可以实测一下多串口,甚至是3个串口同时工作的情况,能有例程最好了,以及讲一下RT-Thread多串口编程中应该注意的事项。毕竟嵌入式中串口用的还是最多的。


抱歉,今天出不了版本了。在考虑DMA传输的问题,感觉实现一个general的serial port有一定难度啊。


希望能同时放出x86 的版本最好vc下可以调试
这样很多代码都可以在pc上模拟调试好再在板子上做 会方便很多的
门槛也低
bernard
bernard 2009-04-07

希望能同时放出x86 的版本最好vc下可以调试
这样很多代码都可以在pc上模拟调试好再在板子上做 会方便很多的
门槛也低


有x86下的直接移植,能够在QEMU和VMware里跑。0.2.4正式版里应该有吧,记得很久以前也写过VMware虚拟的pcnet网卡的。也就是,用VMware如果把pcnet网卡驱动给移植了,那么用VMware来跑个ftp server、web server什么的也是可以的。

如果要支持VC调试,那就只能在PC上做一层虚拟层来跑,只能调调上层的代码,下层的驱动是不行了。RTGUI的开发就是基于这种模式,RT-Thread API的win32版本 + LCD驱动模拟。
shaolin
shaolin 2009-04-07
新版什么时候放出啊?急切盼望中 [s:179]
最好可以实测一下多串口,甚至是3个串口同时工作的情况,能有例程最好了,以及讲一下RT-Thread多串口编程中应该注意的事项。毕竟嵌入式中串口用的还是最多的。


抱歉,今天出不了版本了。在考虑DMA传输的问题,感觉实现一个general的serial port有一定难度啊。


希望能同时放出x86 的版本最好vc下可以调试
这样很多代码都可以在pc上模拟调试好再在板子上做 会方便很多的
门槛也低


x86的版本是可以在PC上调试的,不过不是用vc工具,工具链都是用的GCC,GDB这套,可以用GDB或者它的前端工具insight来调试.
目前最方便在模拟器上调试的是s3c2410版本,支持调试driver,rtos,tcp/ip以及所有上层应用,支持单步源码调试,前端工具使用arm-insight来调试.
pupist
pupist 2009-04-07

希望能同时放出x86 的版本最好vc下可以调试
这样很多代码都可以在pc上模拟调试好再在板子上做 会方便很多的
门槛也低


有x86下的直接移植,能够在QEMU和VMware里跑。0.2.4正式版里应该有吧,记得很久以前也写过VMware虚拟的pcnet网卡的。也就是,用VMware如果把pcnet网卡驱动给移植了,那么用VMware来跑个ftp server、web server什么的也是可以的。

如果要支持VC调试,那就只能在PC上做一层虚拟层来跑,只能调调上层的代码,下层的驱动是不行了。RTGUI的开发就是基于这种模式,RT-Thread API的win32版本 + LCD驱动模拟。

可能说的有歧义了 我的意思是后者
从应用的角度来说两句
我想有一点可以确认 做这个os的目的不是为了做一个os而已 是希望有人来用这个系统的
所以对使用者的照顾应该被重视 一个真正想把这个系统用于产品的人 绝对不想关注os调试 他需要一个可靠稳定的平台
他更关心的是自己的应用程序在这个系统上能不能正确运行
如果提供pc上的验证 并且能确保pc上成功的 硬件上也能成功 这样对于做应用的人绝对是好事
他团队的程序员可以部分摆脱硬件 也可以降低用人成本
bernard
bernard 2009-04-07

如果提供pc上的验证 并且能确保pc上成功的 硬件上也能成功


这点我相信任何一个操作系统开发环境都搭不到,除非是Windows或者Linux本身的开发。因为在Host机上的模拟层不可能完全模拟真实的环境,特别是和硬件相关的地方。

如果想在PC上调试自己的应用程序,我建议可选择两种方式:
1、选择RT-Thread SDL模拟层,这个就是现在RTGUI中使用的模拟层,可以使用VC++调试自己的应用代码,它基本上模拟出了RT-Thread的线程创建,线程间同步机制,通信机制。运行速度也和一般的Win32程序一样。
2、QEMU/2410平台,这是一个完全虚拟的平台,完全模拟了一个S3C2410的开发板,包括数种外设(LCD,Audio,NandFlash,SD Card,SPI等等)。如果在这个平台上运行成功了,那么放到板子上也基本可以运行。

这两种相比较而言,1的速度会快些,并且是用VC++调试,缺点是模拟不完备。2的模拟更完备,基本上和一个真实的环境一模一样,但速度慢一些,并且只能采用gdb进行调试。
dragonwww
dragonwww 2009-04-07
呵呵,我偏硬件,模拟的东西有时确实有点帮助,但还是在要用的硬件平台上调试通过才是最放心的,结果也最直观。
pupist
pupist 2009-04-07

如果提供pc上的验证 并且能确保pc上成功的 硬件上也能成功


这点我相信任何一个操作系统开发环境都搭不到,除非是Windows或者Linux本身的开发。因为在Host机上的模拟层不可能完全模拟真实的环境,特别是和硬件相关的地方。

我说的就是纯软件的部分 有一个模拟的环境会有很多方便
你说的RT-Thread SDL模拟层这个 在哪里能下到呢
bernard
bernard 2009-04-07
发现STM32的多串口框架不是一般的麻烦,最麻烦的是STM32的中断服务程序没有装载的概念。

假设STM32F103VB的三个串口分别为USART1,USART2,USART3

如果其中一个串口使用了DMA来做发送,那么DMA中断服务程序如何指向固定的位置?(中断服务程序中需要调用device的tx_complete回调函数以通知上层应用程序数据已经发送完毕)

所以,这个只能做一个简化了,做成例子
的形式提供:
1、默认rt_kprintf是通过USART1输出,如果修改需要修改rt_console_puts函数
2、FinSH实际只负责接收数据,可以用finsh_set_device设置从哪个设备中获得数据

3、USART1 采用中断方式收取到一个buffer的形式驱动;轮询方式写。
4、USART2 采用DMA的形式接收;轮询方式写。
5、USART3 采用DMA的形式发送;中断方式收。

几个USART的配置,初始化文件在bsp\stm32f103vb\usart.c中提供。

目前两个USART在我这里用仿真方式并无什么问题,我会尽快提供代码。
dragonwww
dragonwww 2009-04-08
呵呵,老大要加把劲了啊,ST的(STM32F10xxx StdPeriph_Lib V3.0.0)又放出来了,他们更新也够勤的,这2.0.3还没弄熟就出来了3.0.0了。
不过对于RT-Thread来说应该是好事,我大体扫了一眼,接口统一成了ARM公司推出的ARM? Cortex?微控制器软件接口标准 CMSIS。

CMSIS简介:
ARM? Cortex?微控制器软件接口标准(CMSIS: Cortex? Microcontroller Software Interface Standard)。
CMSIS是独立于供应商的Cortex-M处理器系列硬件抽象层,为芯片厂商和中间件供应商提供了连续的、简单的处理器软件接口,简化了软件复用,并减少了新入门的微控制器开发者的学习曲线和新产品的上市时间。
aozima
aozima 2009-04-08
拒绝白嫖,拒绝键盘侠!
我觉得这事使用者应该多出出力...
不然.....

凭一已之力..迟早蹦了不可....
dragonwww
dragonwww 2009-04-09
你说的有道理,但我也是心有余而力不足啊,对于OS能使用就不错了,从没奢望过编写OS,这可能就是学硬件和学软件的区别吧。
bernard
bernard 2009-04-09
我觉得这事使用者应该多出出力...
不然.....

凭一已之力..迟早蹦了不可....


我还在想着啥时会蹦了呢 [s:191]
LEAN
LEAN 2009-04-09
我觉得这事使用者应该多出出力...
不然.....

凭一已之力..迟早蹦了不可....


aozima说得没错,不过使用者在系统架构和用户接口还尚不熟悉的情况下,不可能凭空参与开发工作。他们只要多使用并及时反馈问题就是最大的贡献。
软件最不缺就是开发者,如果有大量使用者的前提下。

对于RT-Thread这套RTOS来说,培养长期使用者远比培养开发者来得更重要。RT-Thread团队的工作是艰巨而又受尊敬的。

我绝对支持做一些力所能及的事! [s:160]
bernard
bernard 2009-04-09
我觉得这事使用者应该多出出力...
不然.....

凭一已之力..迟早蹦了不可....


aozima说得没错,不过使用者在系统架构和用户接口还尚不熟悉的情况下,不可能凭空参与开发工作。他们只要多使用并及时反馈问题就是最大的贡献。
软件最不缺就是开发者,如果有大量使用者的前提下。

对于RT-Thread这套RTOS来说,培养长期使用者远比培养开发者来得更重要。RT-Thread团队的工作是艰巨而又受尊敬的。

我绝对支持做一些力所能及的事! [s:160]


感动ing [s:187]
dragonwww
dragonwww 2009-04-09
我觉得这事使用者应该多出出力...
不然.....

凭一已之力..迟早蹦了不可....


aozima说得没错,不过使用者在系统架构和用户接口还尚不熟悉的情况下,不可能凭空参与开发工作。他们只要多使用并及时反馈问题就是最大的贡献。
软件最不缺就是开发者,如果有大量使用者的前提下。

对于RT-Thread这套RTOS来说,培养长期使用者远比培养开发者来得更重要。RT-Thread团队的工作是艰巨而又受尊敬的。

我绝对支持做一些力所能及的事! [s:160]


精辟,看来我能做的也就是反馈一下遇到的问题了 [s:187]
LEAN
LEAN 2009-04-09
我板子串口的问题似乎不存在了。解决方法是重新拔插了一次串口线! [s:169]
bernard
bernard 2009-04-10
我板子串口的问题似乎不存在了。解决方法是重新拔插了一次串口线! [s:169]


呵呵,够强啊。发送后收到接收中断,感觉确实像硬件有些问题呢。
dragonwww
dragonwww 2009-04-14
改进版何时放出啊?热切盼望ing.
bernard
bernard 2009-04-14
还在调,比较奇怪DMA为啥没起作用。。。

撰写答案

请登录后再发布答案,点击登录

发布
问题

分享
好友

手机
浏览

扫码手机浏览