Hi,<br /><br /><br />> So unless anyone raises major objections, I think we should move ahead<br />> with Nuttx.  Who is interested in working on the calypso port?<br /><br />I'd definitely like to be involved in that, especially for the GSM specific part and<br />L1 integration and possibly trying to define more abstract interface for it (so that we can switch from calypso to MTK. The current common code makes calls from common code to calypso specific stuff directly).<br /><br />I'm off until next week but after that I'll definitely look into it.<br /><br />Some things from the top of my head that needs to be taken care of from the get go (to be on solid ground):<br /><br /> - Platform (mtk / calypso / qemu?) and board support. Possibly even variant (US / EU versions)<br /> - Configuration options (TX enable / debug mode / ... )<br /> - For each type of device (spi / i2c / keyboard / ...), define a clear 'Driver API' that each specific driver<br /> - As you said, memory allocator :)<br /><br />(note that some/many of those may be taken care of by nuttx itself)<br /><br /><br />> Meanwhile we will figure out how it would be<br />> possibel to keep the gsm related 'application' code out-of-tree from<br />> the nuttx code base.<br /><br />Any idea how to do that yet ?<br /><br />Essentially the GSM part is three things :<br /><br /> - A collection of drivers for the hw part<br /> - A FIQ handler (the only one)<br /> - A background task that communicates with serial. (altough currently it's all handled in IRQ and that's bad)<br /><br />I'm kind of in favor of progressively recopying all the code we have in a new directory and clean it up as we go. (so we keep the currently working L1 in the current dir and just progressively import functionality).<br />This way we can at each addition take care of what we did wrong the first time around.<br /><br />(And I'd definitely like to be involved in that process).<br /><br /><br />Cheers,<br /><br />    Sylvain