Firmware error logging to file

[justbuchanan]

Right now all logging goes to cout, which is great when we're screened into the robot from the computer, but if an error happens while the robot is out and about, it'd be nice to be able to see what it is. File I/O is pretty slow, so we probably don't want to do this for every single log message, but for errors, it could be pretty handy. Thoughts?

cc @barulicm, @jjones646

[justbuchanan]

Also, is there a way to tell if the serial port / cout is being read from? If we can detect that it's not being read from, we could just send non-error log messages to the DummyStream object and avoid the overhead of using an actual stream.

[barulicm]

This would probably be helpful if&when we have to debug an intermittent hardware failure. I don't know if mbed exposes a way to check the serial connection status. There's a note in the Console class's ConComCheck method that would indicate it's not possible yet.

[jjones646]

This can get rather tricky since serial is asynchronous and all the radio communications are packet structured. The most straightforward way of doing something like this that I can think of is using the MODSERIAL library along with the MODDMA library. Here's a form question about redirecting stdout, and here's a page going through using MODSERIAL with MODDMA.

For TX: Attach a function to the attach_dmaSendComplete() handler that will take the bytes and structure it into radio packets that are then written to the radio's TX buffer. The radio class would handle the rest. Priorities for all of this could be set to something pretty low since we really don't care how long it takes for a log line to come in. Got to be careful though because buffers will overflow and shit will hit the fan if no radio is connected (or the radio has an error...) and what to do for a TX buffer overflow is not defined...

For RX: More complicated than worth dealing with since RX radio packet operations can be easily changed. There's no benefit in taking structured radio packets and turning them back into an asynchronous stream that I can see.

For soccer, the received bytes from a robot would be a radio packet(s) with an ascii encoded payload. Even if the wireless RX serial link was implemented, the ability to individually screen into a robot is weird because there's only 1 USB device - the base station. So it might be best to append the robot's ID to the received payload and write it to a console block within the GUI.

[justbuchanan]

Yeah I kinda forgot about all the threading stuff with regards to logging... Logging a message from a timing-specific function (like radio receive) should be avoided except for errors. The MODSERIAL thing you pointed out though might help in that case because of the buffering.

I do like the idea of being able to get log messages wirelessly on the computer, but I wonder how tough it would be to add that into our radio stuff. I was thinking more of just saving error messages to a file on the mbed, so if we can tell that something's up, we can plug it in and open up the file. Adding that to the logger would be really easy to do. I think next year we should add some badass features like that to the protocol, but for this year we should keep it as simple and close to last year's as possible considering we're pretty close to comp and have quite a todo list :)

[JNeiger]

I noticed the title changed for this. Does this now mean we want to write the log files to the mbed? Or are we still trying to do it over wireless?

[justbuchanan]

Just to a file for now. Sending log messages wirelessly would be pretty cool, but it'll be a while before we can get something like that setup.

[JNeiger]

https://developer.mbed.org/handbook/LocalFileSystem

When a file handle is open, you cannot access the mbed from the PC (Not sure if this includes screening).

I can have it occasionally write, but that may cause a few program loads to fail every once in a while and it would get annoying.

If we can see when it's connected to a PC, it should be simple to stop the file logging, but I'm not really sure of a clean way to check if it's connected.

Thoughts @justbuchanan?

[justbuchanan]

Sorry for the slow response, it's been a pretty busy past few days.

I've done some experimenting with this and it turns out that you can have the mbed read/write files while you're screened into it, you just can't have the mbed mounted as a usb drive. I made a quick demo of this here - just make sure the mbed is unmounted when you run it.

I think this can work for us fairly well, we can just set it up so that whenever log() is called, it writes to the serial out and to a file at the same time.

[jgkamat]

Issue moved to rj/rc-firmware (see above link)