Oh man.... the dashboard program.... my friend (he's known as Ian W. around these parts) and I made one of those *recalls many frustrations and what-not...*
Basically, the way we designed it was there's a C program that reads in the output from the serial port... that little fella reads the packet that the OI spits out... it then processes the data, writes the data to a text file, and a Macromedia Flash program reads it and displays it. The reason we did Flash is because Flash is designed as a graphics package, so rather than learning MFC's (or whatever the C-non-console method of making programs is called), we made a simple console C program to read and a Flash program to display everything nicely. Thing about Flash: it's (relatively) quick and easy to make complicated graphical things, like displays. So the flash is our front-end app, the C is our back-end app.
The display actually came out really nice. We have sliding bars that indicate the speed of the motors on the different sides of the robot (tank-drive system) and... ah, I'll just attach a screenshot of it. It was actually pretty helpful - one of our biggest problems was the transmission not shifting right... after we attached some limit-switches, we could now tell at the controls if our transmission gears were meshed or not. Since we had a very component-happy robot, we used quite a few limit switches (
all of the digi-inputs, to be exact). Anyways, the dashboard program made it VERY easy to see what was going on, so moral of the story: dashboard program is helpful.
To actually sent data back is simple... with PBasic, you have control of one byte in the 26-byte packet that gets spit out the serial port. This byte controls the LEDs. By assigning the states of various components to certain bits and reading those bits, well, you get the point. If you want to do something complicated (but alas, something we failed at), you could try sending analogue signals through this byte as well as digital inputs. The trick is use the BasicRUN bit's state (which alternates every cycle) to tell the dashboard program what the byte you control is carrying - something like if BasicRUN = 0, then {data byte has an analogue value} if BasicRUN = 1, then {data byte has various states per bit}
I'm explaining all this really fast and crappily right now, but most this has been talked about here before, so do a search or post some questions... we'll help ya out.
[edit]Dan's Serial Port Tips:
1. When testing the serial port communications part of it, MAKE SURE YOU'RE ON A FULL BATTERY! You have no idea how much frustration we recieved when we kept on getting incorrect data and we thought there was something screwey in the program when it was actually the RC doing funky things because of a low battery
2. When opening a com port connection, ALWAYS close it. Failure to do this will get you screwey data when testing it the next time
3. If you DO forget to close it, you have to restart the computer. Windows handles serial ports really loosely, and once it's messed up, the only way to fix it is with a reboot. Cold boots are recommended (turn the computer off for 5, 10 seconds, then power back on) to make sure nothing is left over.
4. If you keep on getting screwey data but can't find anything wrong with the program...
4a: Look harder
4b: Look even harder
4c: Ask someone else to take a look at it
4d: Try it from a different computer [/Edit]
Here's a picture of the flash part (front-end) of our dashboard program this year ([Edit]"No file" on the second line of the battery label should say "No fill" [/Edit]):