Nuttx for Calypso

Sylvain Munaut 246tnt at
Tue May 24 22:27:09 UTC 2011

> Before I spend more work on the current code: Is the sercomm protocol
> successful and will stay? What interface to userspace do you suggest?

I think that yes sercomm is useful and should stay but be 'separate'.

So my vision is to have a real 'normal' uart driver. Then 'above'
that, we have a 'sercomm' layer that allows multiple protocol to be
'registred' over it and one of those would be a 'virtual' uart driver
that would have for nuttx the same interface as any other driver).
Then the gsm ass would just register another DLCI handler for the
L1CTL link.
And you just configure the 'secomm' layer to use any nuttx uart (in
our case the ) as physical link.

|Ser com UART | Sercom L1CTL | Sercomm xxx |
                Sercomm layer
                 Phys UART

> My proposal: A char device /dev/sercomm Each time you
> open it, it starts a new channel. With ioctl, you can change the
> channel. 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?

On linux, yes that sounds good, but I would also have an internal API
(for the kernel) so that you can create a real /dev/ttyXXX driver that
talks over sercomm as well.

> If you don't see any problems, I would like to go one step further and
> move some of the hardware initialization like dsp, dma,... into
> user_main. Advantage: I won't go into the binary if you don't need it
> (hello_world, charger debugging, whatever)

DSP is really GSM specific and should not be there IMHO because it's
one of those things that can change (especially all the API zone init
and the patches loading). It's also completely useless for anything
but GSM.

> I thought local_fiq_disable() in secomm_cons messes around with FIQs.
> Why is that save or what does it actually do?

it's to protect the state of the various queues and some shared state.

More information about the baseband-devel mailing list