PDA

View Full Version : Improved Serial I/O, STDIO and Error Handling


njones
09-09-2009, 11:40 AM
I'm interfacing to a subsystem using the serial port. Right now I have to cross connect the port to STDIO and hook the STDIN event and use PRINT for output.

Problem #1: error messages go to STDOUT by default. Remotely monitoring STDOUT is not helpful since my binary serial traffic gets mixed with error messages.

Problem #2: I can't use both serial ports for binary serial communication, only 1 can be connected to STDIO at one time.

Problem #3: there is no option for me to intercept errors and handle them internally (and not have messages output on STDOUT).

Suggestion #1: I'd like to see a seperate event and output function for serial I/O, supporting multiple ports, that do not link to STDIO. Then I can use one or both ports independently of STDIO and remotely monitor STDIO for error and debug messages.

Suggestion #2: Create a new ERROR event, the handler can allow the application to do whatever it need to do (including reset the node). If the even is not linked, the "default" handler can still output a message to STDOUT.

mrmaple
08-27-2010, 02:42 PM
>Suggestion #1: I'd like to see a seperate event and output function for serial I/O,
>supporting multiple ports, that do not link to STDIO. Then I can use one or both ports
>independently of STDIO and remotely monitor STDIO for error and debug messages.

Bump +1, a uartWrite command would solve a problem I'm having where the print command adds a LF... and if you end it with a comma, it adds a space (I think)

Is there any chance a writeUart(uartNumber, string) could be added?
Thanks!

kbanks
08-27-2010, 10:32 PM
Bump +1, a uartWrite command would solve a problem I'm having where the print command adds a LF... and if you end it with a comma, it adds a space (I think)

I think you are correct regarding "desktop" Python, but SNAPpy does not add a space when COMMA is used. This allows print statements to be used to generate binary protocols.

Is there any chance a writeUart(uartNumber, string) could be added?

This idea is in our "feature bucket" but right now the bulk of our engineering resources are going to porting the existing feature set to more and more hardware platforms (and to catching back up on documentation).