Hi,<br><br>Do we really need an X11+Win32 GDI API implementation for such a small screen?<br><br>Sebastien<br><br><div class="gmail_quote">On Tue, Apr 19, 2011 at 11:23 AM, Marius Cirsta <span dir="ltr"><<a href="mailto:mforce2@gmail.com">mforce2@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Harald , just out of curiosity , what's you opinion regarding RTEMS ?<br>
At first glance it seems pretty good, and already has a GUI<br>
implementation ( nano-X based ) .<br>
<div><div></div><div class="h5"><br>
On Mon, Apr 18, 2011 at 5:03 PM, Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> wrote:<br>
> On Sat, Apr 16, 2011 at 09:35:30PM +0200, l--putt wrote:<br>
><br>
>> FreeRTOS<br>
>> What is the problem?<br>
><br>
> To be honest, just looking at the source code makes me want to run<br>
> away. Several other people in the vicinity of the project have the<br>
> same feeling. Also, I find their Makefiles/build system hard to<br>
> underestand, and there seems to be no clean separation between OS<br>
> and application - or maybe I was not trying hard enough to find out<br>
> and/or understand.<br>
><br>
>> TNKernel<br>
>> <a href="http://www.tnkernel.com/tn_description.html" target="_blank">http://www.tnkernel.com/tn_description.html</a><br>
>> Scheduler, Mutexes, Queues, etc. available<br>
>> strange (at least unfamiliar) API for memory<br>
><br>
> Actually this looks quite interesting. Yes, it seems like it has<br>
> little activity and at least the manual was last modified in 2006,<br>
> but it has all the core elements we need.<br>
><br>
> The queues also look interesting. In the end, a lot of what is happening in<br>
> our code will be messages that are placed in queues. This can be actual<br>
> gSM signalling messages (LAPDm frames), but also any kind of events/primitives<br>
> that we have between various subsystems. Having proper infrastrucutre in<br>
> this area is definitely useful - if whatever OS we choose doesn't have<br>
> it, we will likely have to write our own queue code.<br>
><br>
>> eCos<br>
>> <a href="http://ecos.sourceware.org/about.html" target="_blank">http://ecos.sourceware.org/about.html</a><br>
>> many target MCUs but are their any other than ARM in BB chipsets?<br>
><br>
> there are non-ARM baseband chips, especially older Infineon/Siemens. But<br>
> I think there is absolutely no point in looking beyond ARM for the scope<br>
> of OsmocomBB<br>
><br>
>> powerful but complex (at least at first glance)<br>
><br>
> doesn't sound like what I'd be looking for.<br>
><br>
>> NUT/OS<br>
>> <a href="http://www.ethernut.de/en/" target="_blank">http://www.ethernut.de/en/</a><br>
>> minimalistic RTOS, easy to port<br>
>> seems to have sound community<br>
>> familiar APIs: malloc, fopen's devices, ...<br>
>> cooperative multithreading: Is that OK? We still have IRQs for<br>
>> realtime...<br>
><br>
> I'm not entirely sure if cooperative multithreading is sufficient. This needs<br>
> some more thought. In the end, it comes down to the application developers,<br>
> i.e. you :)<br>
><br>
> I've just had a quick look and noted that they already have LUA integration,<br>
> which is something we always thought of as a great idea. Executing LUA scripts<br>
> on the phone itself would make it highly customizable - without touching the C<br>
> source code and recompiling all the time.<br>
><br>
>> Since we seem to barely need an OS, a full-blown OS like eCos seems<br>
>> excessive.<br>
><br>
> ACK<br>
><br>
>> For compatibility with MT6235 user space, malloc and<br>
>> fopen is the right direction. Hence, my favourite is NUT/OS.<br>
><br>
> I tend to agree with your preferences based on the selection you have<br>
> provided.<br>
><br>
>> Open question: How much overhead can we afford, i.e., how much spare<br>
>> time is there on the CPU? Does "Disable RTC interrupt as it causes<br>
>> lost TDMA frames" (layer1/init.c) indicate issues? (Yes, sorry,<br>
>> haven't read GSM specs yet...)<br>
><br>
> If there still are such issues, they are mostly due to badly written code.<br>
><br>
> One of our main issues still is debug output, as printing stuff through the<br>
> UART is terribly slow and time-consuming. A proper thread taking care of<br>
> this might make things better. Also, we should start using DMA, if we can.<br>
><br>
>> If yes, is it reasonable to independently handle GSM stuff with FIQ and only<br>
>> give IRQ to whatever OS we choose?<br>
><br>
> The GSM L1 should remain a FIQ, all other IRQ handlers should be short,<br>
> the remainder handled in OS/user context.<br>
><br>
> Regards,<br>
> Harald<br>
> --<br>
> - Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> <a href="http://laforge.gnumonks.org/" target="_blank">http://laforge.gnumonks.org/</a><br>
> ============================================================================<br>
> "Privacy in residential applications is a desirable marketing option."<br>
> (ETSI EN 300 175-7 Ch. A6)<br>
><br>
><br>
<br>
</div></div></blockquote></div><br>