我有:
问题: GDB调试器无法通过串行线连接到目标.
我想要的是:嗅探GDB远程协议的数据包,以便查明目标上的GDB存根是否存活并运行.
详细信息: RedBoot可以选择将目标控件传递给内置GDB存根.我知道RedBoot还活着,我可以连接它并通过串行线发送命令.RedBoot手册说,可以通过键入$或+符号(实际上是GDB远程协议数据包的前缀)来切换到GDB存根.它似乎适用于我发送终端死亡的那些符号.但我不确定RedBoot是否使用GDB存根支持进行编译(不要问我为什么:-)).
然后,当我尝试使用我的GDB调试器连接到电路板时,我得到以下图片(在Windows上):
(gdb) target remote COM3
Remote debugging using COM3
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
端口是正确的,波特率也是如此.实际上,如果我尝试对另一个没有连接的串口做同样的输出,我会得到相同的输出.
我想知道的是GDB存根是否发回任何东西？
直觉上我想的可能
set verbose on
会有所帮助,但GDB手册说它影响非常有限,我的情况超出了它.
也许可以使用宏来编译GDB调试器,从而启用调试日志记录？
对于MIPS-32处理器体系结构,似乎没有明确的标准化堆栈帧和C语言调用约定(寄存器使用等).也就是说,似乎完全取决于汇编器/编译器工具链来定义自己的堆栈帧和调用约定.我很难找到GCC编译器用于MIPS-32指令集的约定的确切参考.我特意在Cygwin上使用GCC交叉编译器,目标是在eCos开源内核的嵌入式环境中使用MIPS-32内核.
任何有关MIPS-32在该领域的GCC权威文件的提及都将受到赞赏.
一种看待它的方法 - 嵌入式Linux从桌面Linux开始,并抛弃嵌入式系统不需要的部分(这实际上是真的吗？),而eCos是从头开始为嵌入式系统设计的.
现在,假设一个ARM处理器,可能是ARM 7 - 性能是否有所作为？实际上,我们谈的是一个非常低负荷的系统,每天最多500笔交易.
一个优于另一个(或FreeRTOS等)的任何优点？稳定性,成熟度,性能,开发工具,还有其他什么？
我能想到的是,如果我确定我永远不会移植到另一个o/s,那么如果我使用嵌入式Linux,我不需要o/s抽象层来允许我进行单元测试主机(桌面Linux机箱).
有什么想法或意见吗？谢谢.
我有一个运行eCos的MIPS目标,它使用多个线程.为了调试我正在使用gdb 7.5和JTAG探针.
我如何从GDB检查并回溯跟踪非当前线程.我确实有基本线程地址,以及来自备用线程的程序计数器(如果需要,我可以正确地找到其他信息).
由于gdb不了解eCos,因此诸如"info threads"之类的命令不起作用.所以我很可能不得不手动gdb中的线程上下文...
我听说过eCos,看起来作为一个爱好项目玩起来会很有趣.
任何人都可以推荐一个价格合理的开发板.如果它没有增加太多的成本,我想要按几个按钮(并以编程方式检测按键)和一些LCD用于某些调试输出.以太网会很好(嗯,也许还有wifi USB和BlueTooth,如果它们不会增加太多的成本).
有什么建议？(我通常为ARM 7或9开发,但是玩游戏时需要相同吗？)