Missing status return option in driver structure

[uprinz]

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

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
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[uprinz]

After waiting a week for comments...

It's checked in.

The LCD terminal driver, which will support my OLEDs too (coming in the
next days) now expects a return value from the init-routine called from
TERMDCB.
Existing LCD drivers are modified to return 0 as they seem not to have
many features to detect broken communication or anything else.

The OLEDs too do not have any kind of return path, but the driver needs
some memory. If that cannot be reserved, it returns -1 for a failure.

> 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  :)
>
Sorry, it was under my coffee cup... I checked it in.

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