NetPrint
Every designer needs sooner or later to know, what is going on inside
the device he is designing. The simplest possibility
which can be used on almost every microcontroller is outputting the debug information over
one of its serial lines. But what to do if all of them are busy?
The answer is simple. Debug over Ethernet!
Note: The following example is rather fresh and dirty which means that there is still a lot of space for improvements.
However it does its job well.
If we program PC and can use a console for debug output, debug messages
look usually like this one:
fprintf(stderr,"This is %dth time I'm doing just this\n",++count);
We can split this action into two steps:
- creating a debug message string
- sendig it to the console
sprintf(txt,"This is %dth time I'm doing just this\n",++count);
fpritnf(stderr,txt);
We obviously don't have the console in a small system therefore
txt must go to different device, for instance to a LCD display:
sprintf(txt,"This is %dth time I'm doing just this\n",++count);
lcd_text_at(LCD_L1,txt);
Or it can go somewhere else:
sprintf(txt,"This is %dth time I'm doing just this\n",++count);
udpdebug(txt); //network output is finally here!
The udpdebug() function can look like this:
void udpdebug(char *txtb)
{
uint8_t _reip[4]={192,168,0,2};
udpsend(_reip,2001,20010,txtb,strlen(txtb)+1);
}
The udpsend() function sends the packet over Ethernet network to destination
IP address 192.168.0.2 and port 20010. We use UDP protocol instead of TCP because
of its smaller overhead.
It "sends and forgets" and this is much faster because it doesn't use "reliability" mechanism used by TCP.
In most cases it is fast enough to debug in the realtime.
We can send the messages yet, so it's time to receive them by something.
A PC computer with program called netcat can be used for this very well:
c:\nc -u -l -p 20010
Or, we can use NetPrint:
Conclusion.
An advantage of having Ethernet inerface on the board can be very
easily used for replacing the classic console for debug information output.
This is especially useful when there is a need for state machines debugging, the designer can
watch state sequence and eventually change the code, remove bugs, etc.
The possibilities of using such debugging technique are virtually endless, though.
Multiple NetPrint or netcat "receivers" can be used, each listening on a
different UDP port. The device under test can send messages from each inside process
to different port therefore to different NetPrint or netcat window. Then the designer has
better view what is going on inside his baby.
© 2004 michal at vanka dot net