Software Team Meeting 06/09/2003
Another all-nighter -- I'm writing this a week later so I've forgotten most of the specifics.
When I left Andrew and Jamey at 6:30am, after apologizing for growling at people, the flight computer was fairly reliably passing data through from test programs on a freshly installed-laptop, via wireless to and from CAN bus devices (also working around problems in the Can Bus driver). I had documented instructions on how Andrew can test and tweak the flight computer software and network system.
Andrew says that by 8:30am he and Jamey had teased out the last of some nefarious Java issues and IMU data was flowing through the flight computer, wireless link, to the laptop and into Rocketview, and updating the graphs.
We had successfully accomplished the demo criteria:
The inertial measurement unit sends data over CAN to the Flight Computer which sends the virtual CAN packets over wireless (802.11b) to the telemetry computer which then displays them in rocketview.
During the meeting, Andrew observed we had been slashdotted! I put together a page for it at 2003-06-09-slashdot. Jamey and I spent some time tweaking the PSAS server to handle the load, but it didn't really seem to be that heavily loaded.
FIFO changes
The fifo device files were being opened readonly on the reader side, and writeonly on the writer side. POSIX specifies (see the man 4 fifo page) that both reader and writer block on the open() until the other side is opened. Ugh. Our application design needs to be able to read or write or open the pipe with no one else present. Fortunately, Linux fifos implement this functionality when opened for reading+writing. I modified the fifo library to accomplish this functionality.
Can Bus Driver changes
The CAN bus driver apparently is unhappy with being opened read/write and then issuing read calls, a write call, and more read calls. The second group of read calls never actually returns any data. Unloading and reloading the CAN bus driver seems to allow you to read data again.
So, the planned strategy of the manager task opening a read/write file descriptor, and handing it to can reader and can writer tasks isn't going to work. We did not have time to debug the driver, so I removed manager open of the CAN bus device, and merged the two CAN processes into a can read/write task. This task opens the device for reading, then closes and reopens it for writing to write data, then closes and reopens it for read to get the next bit of data.
The can reader/writer task works. The can driver needs attention to make it better... but that may not happen until we rewrite it for RTCore.
Rocketview changes
Jamey examined rocketview (David had done much work on it) and after some heated discussion accepted the unhappy task of reworking all the networking in Rocketview to match the flight computer's UDP port and broadcast socket assignments. In the process he discovered a number of network byte order and data representation issues and worked around them. Fortunately he knows both Java and C better than anyone else on the team does (at least, that was around Tuesday morning from about 5am to 8:30am).
_ Later in the week, I found the same bugs whilst working on the LTC software and compiling RocketView on my Mac. After discussing the matter with Jamey, I've checked in fixes in both the C and Java socket modules (Cansocket and ltc_fc_common). All should be well after a recompile. _
At the meeting, having failed to get the ?LaunchTowerComputer wireless card running the previous day, I converted the LTC software from UDP to TCP communication and called it a night. The TCP networking modules are now also in ltc_fc_common for others to use. -- IanOsgood
Left to do:
The remaining demo functions are handled by Andrew and the avionics team Tuesday night (does this man ever sleep? No!)
THANKS to everyone for their contributions, and a special thanks to Andrew, James, and Jamey for staying so late.
-- ?JamesPerkins - 17 Jun 2003