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

[Ulrich Prinz]

 Hi!


 



On Wed, Mar 4, 2009 at 9:22 PM, Ulrich Prinz <uprinz2 at netscape.net> wrote:


>> 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.

It could be a compile time option. We have that for the text displays,
to select pins, bus width, etc.

I'd like to implement that the same way, as it is the only way to keep the code small.

> 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.
>

I could help with that, keeping the code "cross platform". It's not
hard, actually :)
Fine, then I don't have to bother with that.

Regarding best way of...
The term functions are pretty fine and I don't see a reason for throwing them away. But the term is calculating in characters.
I implemented a character driver and can now stack it upon term. But this disables the option to use graphical functions. 
It even fails if I'd like to use fonts of different size or height. So my idea is to copy term into gterm and modify gterm:
- Calculating in pixels instead of characters. 
- Append _ioctl options to switch between binary mode and character mode.
- Second step would be to implement variable width fonts.
- Expand ESC sequences for font selection
- Expand the ESC sequences for adding special graphical functions. 

Fonts is a special theme here. I know about 3 or 4 different ways displays like to have their data oriented. 
So it might be necessary to hav a tool compiling the fonts from a raw format to the displays specific format. 
Yes, one could fit the data in the target software and throw it to the display, but it will waste lots of 
CPU power and code space. It would be more efficient to have the fonts selectable and optimized for a 
simple access. 

And at least I'd like to use the display more automated. I didn't analyze the SPI code and don't know if it uses DMA and things like that to 
keep code and hassle with threads small. But I'll find out.

>> 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.
>

Hmm I never got it to compile so I haven't seen that behavior. It
works ok under Windows.
Probably the problem lies with wxWidgets, it's terrible for
cross-platform because if those platform dependent quirks. They just
have too much platform dependent code as they try to abstract the
platforms at the system widget level instead of at the painter level.
They were doing a wxUniversal or something like that to correct this
design flaw, but I don't know if it's usable or if the Nut
Configurator can be ported to that.

That's right, as it matches what we found out there. But this actually has very low priority for us.

Btw, you should try the configurator from CVS, there was some fixes
there that will show up in 4.8 sometime this month.

I cannot mix up version now, but will do that may be on a private basis after the new drivers work smart.



Thanks,
   Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion