[En-Nut-Discussion] New displays, chained devices, best way or how to

[Ulrich Prinz]

Hi Thiago,


Thiago A. Corrêa wrote:
> Hi,
> 
> On Wed, Mar 4, 2009 at 7:08 PM, Ulrich Prinz <uprinz2 at netscape.net> wrote:
>> Hi!
>>
>    That's an interesting topic. Harald has expressed interest in a
> "GUI API" for graphic displays, but AFAIK, nothing has been designed
> yet.
>    He did mention that he didn't want a simple primitives lib with
> lines and boxes, but something more elaborated.
> 
My actual application is a small user interface for an industrial 
device, so two or three different sized fonts and some lines are quite 
enough. My displays have 128 to 132 by 64 to 96 pixels. But you're 
right, I prefere open interfaces to, that can be extended quite easy.
May be some pre defined functions like bar graphs and gauges are 
usefull. But if the interface is well defined, one could extend the 
functionality ast will.

>    Perhaps you could open up an entry on the wiki to discuss your
> proposed implementation?
>    Contiki has an GUI API, we should take a look at how they do it.
> 
Ok, I'll try to find out about the wiki.

>> Chaining Devices:
>> The displays I am trying to attach are SPI displays. So I need to
>> register a new device for the SPI bus. Then I need to register a new
>> stream device attached to the spi device from before. Is there an
>> optimal way to do this? Actually I do the NutRegisterSPIDevice and then
>> I do a NutRegisterDevice. But I think the registration of the display
>> device itself should keep care for registering itself on the SPI bus in
>> its init routines.
> 
> The reason for the NutRegister*Device in app code is to make it easy
> for the linker to axe unused code.
> 
Yea, I have to look at that in detail. The displays I use mostly have 
both interfaces, a parallel and a serial one (SPI). So it might be a 
good idea to first register a display interface and then register the 
display to that interface. So one could use both physical connections. 
But I am trying to avoid blowing up the code just to throw some pixels 
on a screen. I'd prefer to have some space for the application left in 
the flash.

By the way, I design on the AT91SAM7X256-EK. And project pressure is 
quite high. So I'll support any port to other CPUs of the nutos a bit later.

>> At all I really miss some guides of how to do some thing inside nutos
>> the best way. Is there any further documentation available?
> 
> There is the wiki, the main website and the mailling list. Feel free
> to post your specific problems, perhaps some of us can be of
> assistance.
> 
wiki... I really have to get a look there.

>> Ah, I develop these nutos drivers under linux but will backport them to
>> the windows release for shure and share them to the community. But  I
>> have massive problems getting the GUI going of the nutos configurator
>> under linux. Any comments for that too?
> 
> I had issues too, with the autotools. I couldn't generate the Makefile
> under Gentoo. It just can't find lua files, don't know about others.
> Is that the same problem you are having?
> 
Some externals from us ported the 4.6.4 code to work on linux and they 
promised to push any open source code modifications back to the 
community. So under suse 10 and ubuntu >7.x it's compiling fine in the 
shell. But the GUI configurator has it's problems. It starts but doesn't 
get very far. You might see duplicate scrollbars and only one is working 
mostly. The other one sends the gui to hell.

They'll figure it out, I think.

Thanks fo the hints and best regards
Ulrich