Hi Stefan,
On Wed, May 25, 2011 at 12:13:31AM +0200, l--putt wrote:
Before I spend more work on the current code: Is the sercomm protocol successful and will stay?
yes.
What interface to userspace do you suggest?
each DLC should be a separate device e.g. /dev/ttyHDLC0.., so a userspace process can simply open one DLC and read/write to it using stadard read/write calls.
Should be something that works on Linux if our stuff ends up on more powerful devices. My proposal: A char device /dev/sercomm Each time you open it, it starts a new channel.
No, please make it explicit and have one device for each DLC Automatically assigning a channel is not a useful feature.
With ioctl, you can change the channel.
then you would have to do that ioctl() every time. I like the idea of one device per DLC better.
Each write is send as a message. Nuttx has buffers for stdio and hence will take care that there are not too many messages (I hope :P )
The receive part: a blocking read?
either blocking read, or the user can set O_NONBLOCK and do select/poll (not sure if nuttx supports that, but at least on Linux it would work)
In terms of Linux there may already be a more generic serial multiplexer protocol that we can re-use. Not sure if it finally has a TS07.10 multiplexer, e.g. If yes, the we may consider switching to TS07.10 instead of our homebrew HDLC.
In any case, on Linux the multiplex driver would be bound as a line discipline to the real serial port, and offers N virtual serial ports for the N DLCs.
Do you see any problems with this? Is there something in the Nuttx ARM7TDMI related code that disables FIQs or otherwise interferes with them?
I thought local_fiq_disable() in secomm_cons messes around with FIQs. Why is that save or what does it actually do?
it is neccessary as we also want to log messages from the L1. Right now the L1 (from FIQ) submits a log message, and the normal code in the UART driver fetches those messages and writes them to the UART. You need some kind of locking/mutex for a very short time to protect the queue of messages here.