Serial I/O Improvements To Do

• Spoke to Gordon on the phone, asked him to try to give us an ETA on finishing the Java code. His problem at the moment is that he has no Internet at home and no laptop. He may be able to do the work using machines at CS, but isn't sure yet. He also has very little overlap in his schedule with Mike. Alternate Fridays look like the only option.
  
  
• Facebook friend Kragen pointed out that I really should be using memmove() instead of memcpy() in my line-buffered input routine, for extra safety in the face of possible future reimplementations of the Nios version of the newlib API. He is right, and this is an easy fix, so do this ASAP [ ].
  
  
• Kragen also suggested I handle EOF explicitly. Right now, with the default UART driver, there is no way to detect an EOF-like condition. But, I could add gelware to route the RS-232 DTR pin to an Avalon PIO peripheral (which could also generate an IRQ if I want). This would then allow me to check explicitly for a remote device power-down or physical disconnect in my I/O routines. (The more "elegant" way would probably be to write my own custom device driver, but that may be too much of a pain.) However, the problem with even trying to handle this contingency with maximum gracefulness is that it requires significant extra software complexity. The best we could do, if the Wi-Fi board goes down, is to buffer up the real-time data until the board comes back up, then stream it to the server as fast as possible until we catch up. We could actually buffer up quite a large amount of data - maybe even an entire run's worth - if we use the DRAM SIMM card, and/or an SD card. If the Wi-Fi goes down and no one notices for a while, this could save our @$$ if we are trying to do a long data run. So it's probably worth doing eventually, but still not a top priority - since our main goal right now is to get the demonstration system working before the grant runs out, which (worst case) is the end of this summer.