第10篇TinyOS/TOSSIM的debug（教程lesson 5）

最新推荐文章于 2023-04-23 14:34:10 发布

超级熊熊

最新推荐文章于 2023-04-23 14:34:10 发布

阅读量3.9k

点赞数

分类专栏： TinyOS学习文章标签： command 程序调试工具 application debugging module output

本文链接：https://blog.csdn.net/utnewbear/article/details/6314460

版权

TinyOS学习专栏收录该内容

19 篇文章 5 订阅

订阅专栏

在tinyos/NesC当中,debug的方式主要有两个:

TOSSIM自身的调试信息和使用 gdb的调试.

TOSSIM调试功能:

优点是可以像 printf一样,在程序中各个希望知道变量结果的地方,加入相应的输出信息.

缺点是和printf一样麻烦,要在所有需要的地方写代码.

GDB是GNU开源组织发布的一个强大的UNIX下的程序调试工具。所以在linux下是可以直接使用的,所以对于作为linux模拟器的cgywin来说,当然也是可以直接使用的.

优点是有他就是一个debug工具,所以拥有强大的功能,比如设置断点.在循环结构和有关时间的程序当中，还是非常重要的。

缺点是他是c语言的调试工具,而不是nesc,所以它不太认识nesc,在调试的时候,很多东西都要转换.

以下分别介绍如何使用:

1. TOSSIM

缺省情况下，TOSSIM 在console输出所有调试信息。但用户更关心的是数据包的输出和节点上LED 的显示值。TOSSIM 输出可以通过在shell 中设置DBG 环境变量而进行配置，输入命令：

export DBG=am,led，

这条命令使得只有LED 和AM（活动消息）数据包才可以输出。

为了把console的调试信息保存到文件中, 可以采用如下命令：

make build/pc/main.exe 1 > tossim.txt

文件名可以自定.所生成的文件会放在cygwin当前的工作目录下。

那么就只会在文件当中显示调试信息，而在console当中不会显示。所以感觉在console当中是死机了一样，卡住了，其实后台正在运行。同样用Ctrl+C结束程序。

TinyOS 代码中，调试消息命令如下：

dbg(<mode>, const char* format, ...);

那么这里一目了然,以dbg当中的内容就是需要输出的内容.

其中mode 参数指定在哪种DBG 模式下将输出这条消息。一般而言，在运行模拟器时，TinyOS 代码中DBG 的模式名是预先指定的名称。例如：

am 是DBG_AM，packet 就是DBG_PACKET，而boot 也即是DBG_BOOT。

dbg模式可以有很多种, 比如temp,usr1,usr2，am，led等等.

参数format 及其后面的其他参数指明将要输出的字符串，并且具有与 printf()相同的语义。例如，在编程器中打开tos/lib/Counters/Counter.nc，在 Timer.fired()中返回语句之前加上这一行语句：

dbg(DBG_TEMP, “Counter: Value is %i/n”, (int)state);

注意到这里使用的是%i，而不是我们熟悉的%d，后面也采用了强制类型转换（int）state。

在console输入DBG= temp

将DBG 设置为temp 并运行模拟将可以看到计数器在增加。

在运行模拟时不仅可以指定多个模式，而且单个调试消息可以在多种模式下激活,对它们使用所有标准逻辑操作，如|，~。

例如：

dbg(DBG_TEMP|DBG_USR1, "Counter: Value is %i/n", (int)state);

此时，只要DBG 模式是temp 或者usr1，都可以看到结果。

可用的所有DBG调试模式如下：

all: Enable all available messages

boot: Simulation boot and StdControl

clock: The hardware clock

task: Task enqueueing/dequeueing/running

sched: The TinyOS scheduler

sensor: Sensor readings

led: Mote leds //单机程序和观察节点变化常用

crypto: Cryptographic operations (e.g., TinySec)

route: Routing systems

am: Active messages transmission/reception //无线传输常用

crc: CRC checks on active messages //通讯信息发送接收常用

packet: Packet-level transmission/reception

encode: Packet encoding/decoding

radio: Low-level radio operations: bits and bytes

logger: Non-volatile storage

adc: The ADC

i2c: The I2C bus

uart: The UART (serial port)

prog: Network reprogramming

sounder: The sounder on the mica sensor board

time: Timers

sim: TOSSIM internals

queue: TOSSIM event queue

simradio: TOSSIM radio models

hardware: TOSSIM hardware abstractions

simmem: TOSSIM memory allocation/deallocation (for finding leaks)

usr1: User output mode 1 //debug专用

usr2: User output mode 2 //debug专用

usr3: User output mode 3 //debug专用

temp: For temporary use //debug专用

2. gdb

我本身对GDB不熟悉, 还是习惯那种图形界面方式的，像VC、Eclipse等IDE的调试方式,不过现在都玩传感器了,还是要熟悉这个命令行的调试方式,也许功能更为强大.

一次典型的gdb使用如下(基于我自己的理解)：

To start a gdb debugging for a general NesC application, I used the following command:

$ gdb --args build/pc/main.exe 4

The gdb console gave the following information:

GNU gdb 2003-09-20-cvs (cygwin-special)

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details.

This GDB was configured as "i686-pc-cygwin"...

screenshot 1 start a application with gdb

因为gdb不能兼容nesc, 所以在用gdb来调试nesc程序的时候,其实质是调试c代码,所以存在一个映射的问题.

As we know before, gdb does not (yet!) have a nesC-specific mode. Instead, in gdb you are effectively debugging the C code generated by the nesC compiler. However, the nesC compiler includes #line directives in the code it generates, so single-stepping through nesC code will display the correct nesC source code, and breakpoints can be set based on the line numbers and file names of nesC components. The situation for variable, function, command and event names is however not as straightforward.

To set up a break point, I used the following command:

(gdb) break *BlinkM$StdControl$init （这里存在nesC到C的映射关系）

映射关系如下:

Note the * and $ here, Types, variables and functions in C files (included via the includes statement) are left unchanged in the generated C code, except if they correspond to a nesC keyword. There is a mapping from nesC names to C names.

A module variable (top-level data declarations in modules) X in module M is called M$X in the generated C code.

A function F in module M is called M$F in the generated C code.

Local variable names in modules are left unchanged in the generated C code.

A command or event C in module M is called M$C in the generated C code.

A command or event C of interface instance I in module M is called M$I$C in the generated C code.

The gdb console gave the following information:

Breakpoint 1 at 0x4073e4: file BlinkM.nc, line 52.

screenshot 2 set breakpoint in gdb

To make the application run, I used the following command:

(gdb) run

The gdb console gave the following information:

Starting program: /opt/tinyos-1.x/apps/Blink/build/pc/main.exe 4