With USB firmware loading via an ioctl, we can improve USB debugging.
I've added one new shell command with a few sub-commands for this:
usb [help]
Show what sub-commands are available.
usb load <filename>
Loads the firmware from the specified file and resets the Navre
(the internal microcontroller that implements low-level USB
support.)
The path to the firmware is from the file system's root. If the
firmware has been uploaded with FTP, the file would be under
/ssd/ by default, so the commands would be
ftp> put softusb-input.bin
...
[/] # usb load softusb-input.bin
The USB firmware binary is simply the file softusb-input.bin
generated when running "make" in softusb-input/ of milkymist.git
usb debug [wait]
This command dumps the debugging messages generated by the Navre
to the console.
Without argument, it dumps all the messages in the buffer and
then returns. With "wait", it will keep on polling until the next
keystroke on the console.
Some gory details:
- the debug message buffer has a size of 256 bytes. If it fills
up, new messages will overwrite the beginning of the buffer.
- all forms of "usb debug" read until the the message buffer is
empty. At least in theory, a Navre generating lots of messages
could therefore cause the command to run forever.
By the way, waiting for a keystroke is rather tricky in RTEMS. I've
tried fcntl(0, F_SETFL, ...) (fails silently), ioctl(0, FIONBIO, ...)
("Bad file number"), and open("/dev/console", O_RDONLY | O_NONBLOCK)
(ignores the O_NONBLOCK).
What finally worked was creating a thread that does just the blocking
read and then signals the main thread. Phew :-)
- Werner
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
