Nuttx for Calypso
laforge at gnumonks.org
Wed May 25 06:19:20 UTC 2011
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?
> 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
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
More information about the baseband-devel