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

[Ulrich Prinz]

 Hi Ole,

nice to see you here, we know each other from mikrcontroller.net :)




sorry for jumping into this discussion late so I'll probably answer
older questions in this mail too.

That pretty fine!

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

Ok, let's discuss this terminal emulation thing.

Terminal emulation is just done on the character level. It shall emulate
some subset of the VT42 I think. So that's not the right way to talk
with a graphical display on the low-level view.

What you would better need is some kind of a frame buffer driver.

So: First implement a framebuffer, that gives you a memory reagion to
write your graphics data into. The framebuffer driver at least shall
initialize the graphics display and perhaps implement some more
sophisticated functions like copying an image reagion or drawing=2
0of some
very primitives like lines / circles. But even those drawing functions
should better be located in a low level graphics library, so that you
framebuffer should simply provide the memory and should update the
display in a regular manner. Perhaps, if your display supports some
graphics acceleration, provide an interface for the graphics API to use
these accelerations.

I thought about that too. But there might be a problem with that if I start backport to AVR. With 64k in my SAM7X its not a problem
to store 1056 bytes representing a frame buffer. But 1056 bytes is more than most 8Bit CPUs have at all. So my intention was to
do it more virtual, by tracking the things I am doing.

On top of this very low framebuffer implementation. You would the
implement a low level graphics api, providing pixel drawing, line
drawing and so on. You should also provide some kind of text api, that
will be used to draw single characters as well as strings.

Yes, I know this way from linux based systems. But I thought, that this way is to much memory consuming and I use NutOS for its 
relatively small footprint. I alsoo do an actual development on a hardware where we might decide to go a step back and 
save PCB spave and some money by using SAM7S128 what reduces RAM to 32k.

Now you have everything to provide a text buffer. Ans that's the point
where you get in contact with the terminal emulation again. As you now
can implement a text layer upon your graphics layer. Eventutaly it would=0
Abe nice to implement virtual terminals as well, where you can
instantiate a terminal in just a small window of you graphics region and
another one in another window.

Yes, I fully agree, and I think I'd have fun to implement that. But again, isn't ist against the idea behind NutOS, open, configurable to 
last detail and small in footprint?

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

Yes for shure. There are even some displays out there which support
native font drawing as acceleration function too.

Unfortunately I don't have such displays, my are more or less dump... Otherwise I wouldn't have started any development there but just 
switched them to text mode and used the term functions as they are.

So my Idea would be to implement a general framebuffer driver api where
you can register the different acceleration options you display provide.
If the display driver does not register this acceleration function it
will be emulated on a software basis by the graphics api and so will be
done with the font rendering too.

> And at least I'd like to us
e 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.

Just one hint if you use SPI: If you will only send small data packets
(just a single or very few bytes) over SPI, use the polling mode. It's
much faster than the dma mode, as the overhead is larger than the speed
gain for such short transfers. If you have large transfers (sending a
whole image for example) DMA transfer gets way faster though.

Ok, but if you use a frame buffer you'd use DMA and copy the whole memory at once to the display. So easiest way is to start a refresh timer
and if it runs out, do a copy. So one could setup the refresh cycle by configurator or can force timeout to 0 by a function call to 
immediately refresh the screen. 
If you'd like to do it somewhat smarter you might give some functions to watch modifications in different FB regions and only update these regions. 
In my case this might be helpfull, as the display has some coloured status fields on top of a large general area. By the way, the display is
the DD-32645C-1A from Densitron. 

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

So for what I can say I use the configurator now since quite some time
on Debian/sid and Ubuntu Intrepid. Both are able to compile the
configurator without problems provided that you have installed all
needed depenencies (like liblua and wxWidgets >= 2.8) for example.

There are some known issues, but you will run fine, if you use the
lastest CVS version (or unstable release) of the NutOS code.

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

There is no problem with compiling / installing just the configurator
from the most recent NutOS version and using it with older NutOS trees.

Hope I could give you some ideas for your api. It might be a good idea
to bring this discussion to the wiki and to get some more views, as this
is not a simple design decision and might result in doning some work
more than once if everybody designs it's onw graphics api. Graphic
displays are becoming that cheap that sooner or later NutOS needs some
well designed graphics api.

And if we just started t
hinking about it we are in need of well designed
widget set for this api too.

I'd nevber thought about the API problems put into the wiki. But for the display discussion it might be the right place. 
I created an account in the wiki but I am not shure where to start the display thread in there. And may be we should discuss the best way here and
start the wiki with some basic decisions already made? Actually I see myself as a newbee in the nutos development, so it's your decision :)

But we can do the basic things by phone and present some framework to the community as sort of RFC?

Best regards

Ulrich Prinz
Rittal GmbH & Co. KG · Auf dem Stützelberg · D-35745 Herborn
Phone: +49 2772 505 1707 · Fax: +49 (0)2772 505 - 71907

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion