Debugging

Debugging on the RCX has just gotten much better. In previous versions of brickOS, you had to dump information to the LCD, much like you would use a printf or cout statement when programming normally, with the exception that you could only display 5 characters at a time. You can still do this, and this is recommended for simple debugging, but for larger, more complex programs, you may want to consider using the data log or the IR debugging tools.

Debugging with the LCD

There is a trick to this part - As pointed out previously, there are physical limits to the refresh rate of the LCD. As a result, if you get caught in a loop, your cputs will get piped to the LCD faster than the screen can deal with it and it will appear as if the screen is covered with junk. To deal with this problem, you'll need to insert delay loops in the code, effectively pausing the RCX and the code until the screen can catch up. To insert a delay in the code, use msleep(X) or sleep(X). Alternately, you can insert a wait_event() or getchar() command, allowing you to look at and contemplate an outputted value until you press a button on the RCX. Depending on the complexity of the code, this might demand a great deal of repetitive button pushing.

Debugging with the IR port

The TAs have written a few debugging tools, which are now available both on Linux and on Windows. The idea behind the IR tools is that since the LCD is often not enough for your information hungry eyes, why not transmit information via IR and have the PC read it? You are expected to have read through the section about LNP before you read through this part.

Basically, you will want to use lnp_printf and lnp_reliable_printf in conjunction with PC-side programs. The programs you want are util/lnp_listen and util/lnp_reliable_listen. (These executables are in the cs148 bin directory on Linux /course/cs148/bin) Run these programs and they will tell you how to use them.

The difference between lnp_printf and lnp_reliable_printf is that lnp_printf will just shoot out data and won't make sure that it gets received. lnp_reliable_printf on the other hand, will block and wait for an acknowledgement (using the reliable LNP protocol) before continuing. Thus, lnp_printf is better suited for when you don't need every piece of information that you shoot out.

Debugging with the data log

The data log is, in short, a beast. The reasoning behind the data log is that you want more detailed debugging information, but your robot moves around too much and is not always able to maintain contact with the PC. The solution to this is to keep an on-brick data log that you can write to while the program is running and then download to the PC once your robot has finished operation.

Initialize the log with init_log( size_t size ) where size is the size of the requested log in bytes.

Write to the log using lprintf( <formatted string> ), just like using printf. Strangely enough, we did make the log thread-safe, so you can write to the log with multiple threads.

Some things to note about log usage

There are a few steps involved in using the data log, and it must be used with care, since we hacked it in to the kernel in a very poor fashion. It can and will cause kernel crashes if not used as prescribed.
The data log must be initialized by your main thread of control.
After your program has finished operation, you cannot do anything with your brick before you download the log. Talk to a TA if you're curious as to why this is.