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

[Ulrich Prinz]

 Hi Harald!




Ulrich Prinz wrote:
> I'm almost new to nutos, almost as I used it mostly as it is before. But 
> now I'd need to extend it in many ways and I am missing lots of how-to's 
> or best ways.

Hi Ulrich,

I'm quite busy right now and hope to be able to answer in more detail
later. Did you find the following document?

 http://www.ethernut.de/en/documents/ntn-6_spi.html

The whole stuff is relatively new and the docs are rare.

The character based LCD on the Medianut Board is initialized like this:

 NutRegisterSpiDevice(&devSpiMegaLcd, &DEV_SPIBUS, 2);

This initializes (calls dev_init for) both, the bus controller and the
device.

You can the use stdio to open the dispaly and write to it. As a more
advanced example here is the code to register and mount the raw file
system on an SPI DataFlash:

 NutRegisterSpiDevice(&devSpiAt45d0, &DEV_SPIBUS, DATAFLASH_CS);
 NutRegisterDevice(&devRawFs0, 0, 0);
 volid = _open("AT45D0:0/RAWFS0", _O_RDWR | _O_BINARY);
 fp = fopen("RAWFS0:", "r");

That's right the thing I'd like to have for any kind of display. Define the interface, open it, attach the display to the interface and use it.

The current LCD interface mimics a VT52 terminal, so we can use ESC
sequences to control the cursor and a few editing functions. I don't
think, that this makes much sense for a graphic display.

Yes and no. You always want to display text on your display. So why not using well known functions without having to bother 
what type of display is connected. To set it easy: Anyone likes fputs( display, "Hello World!\n");
An additional set of functions should then be able to select fonts, copy different types of images from FLASH/MMC/SFLASH... and display them and so on.

I've done some evaluation on GUI interfaces and, so far, came to a few
results:

- All graphic output should go to widgets, not directly to the screen,
although the screen (desktop) may be a widget too.

- I still hope that it is possible to avoid a frame buffer in memory,
but exclusively use the display's RAM. This will allow tiny systems like
the AVR to control large color displays. It requires that all refreshes
is done by drawing routines.

- All graphic routines should use pure integer calculations, may be
except color adjustments, which should be optional.

I'm not well experienced with this stuff, though.

Regarding Nutconf: If the GUI fails, try the CLI

 http://www.ethernut.de/en/documents/debian.html

I'll have a look there. I simply skipped the whole GUI thing in linux and call the makefiles with a script.

CU,

Ulrich Prinz