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.
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)