[En-Nut-Discussion] Missing status return option in driver structure
uprinz2 at netscape.net
Mon Aug 24 23:37:00 CEST 2009
Hi again :)
Yes I am actually doing NutO/S coding for four projects in parallel, so
there will be more to com from my side :)
Attaching a graphical OLED to the system, that should be simply used by
printf() I went the same way as the HD44780 or this STsomthing LCD.
I have a NUTDEVICE for the OLED, referring to a TERMDCB for the term.c
code. With that one can easily do character output and some cursor
control oon the display.
But I have some different displays ans some hardware that have slight
differences. I dream of displays that can return some information over
the SPI, but I never saw one of them :(
Now, the NUTDEVICE has an init function, returning an int as status if
the init failed. Sow the software can tell if the other software failed.
But the TERMDCB only accepts a void from the hardware init function. So
the hardware cannot tell the software if it failed.
The most reasons for the return codes in the NutO/S driver structure
are, that there might not be enough memory for installing the drivers
variables, structs or buffers in the ram. My hardware driver for the
oled needs some bytes of ram too and I prefer to install them only if
the hardware is found and the hardware is needed.
As a result you cannot detect, if the hardware failed and take actions
like reconfiguration, trying a different address for the hardware or
anything else. I even cannot detect if there is not enough ram to
install hardware drivers that need some ram space.
So, how about modifying this and giving hardware driver related Init()
functions always a return as int? I just ask if there is any reason
against that? If not, I'll include that into trunk in one of my next
And yes, the new led driver is missing its led.c... On my work PC it's
there, in the repository, it's there, but on my home PC it doesn't
appear in the checkout... If one of you guys has it hidden under his
keyboard, trust me I'll get you :)
Best regards, Ulrich
More information about the En-Nut-Discussion