[En-Nut-Discussion] RFC: LEDs of Demo Kits

[Harald Kipp]

Hi Ulrich,

On 4/24/2011 7:56 PM, Ulrich Prinz wrote:
> Am 22.04.2011 13:57, schrieb Harald Kipp:
>> Any specific reason why 'make clean' had been disabled for app/hhopen?
> No, I thought about deleting that project completely. I introduced it
> over a year ago but the hardware changed some times and I suddenly
> didn't have enough time to complete the project. I only have the old
> hardware for this open source OBD Analyzer... Doesn't make sense to keep
> it up.

If we introduce board specific samples, we would need a policy for this 
case. Unmaintained samples should be removed after a specific period of 
grace.


>> application sample tree is a temporary solution.
> But that should be discussed in a new thread.

Right. Just meant as a warning not to invest too much effort.


> For now we could simply split app into app/general and app/arch/xxx and
> then copy app/general together with architecture dependent examples into
> the nutapp_xxx_gcc directory. That is sort of a 2-liner in qnutconf and
> would help a lot.

Not sure about moving the samples down one level in the tree. I know, 
many of you guys are using absolute paths, but I'm quite defendant on 
relative paths in Makefiles.


> On the other side I only asked for support of may be 4 LEDs and 4
> Buttons that are predefined in the board.h.

Only? :-) As we say in Germany: Beware the rat-tail.

What's missing is a clear statement, what has to be implemented for any 
new target. De facto the GPIO API is a requirement. If GPIOs are not 
available at all (GBA, Linux Emulation), Nut/OS may provide dummy routines.

Beside defining, what APIs are required for every target, we need to 
specify the required functions. For example, we have the new functions 
TwMasterRegRead() and TwMasterRegWrite(), which are convenient, widely 
excepted and used in two general drivers at24.c and pca9555.c. The 
implementor needs to know, that he is only forced to implement them, if 
he needs support for AT24xx or PCA9555 chips. Luckily the Configurator 
is of great help here.

Back to the topic. No problem, if the LED/Button API is based on the 
GPIO API. It will automatically compile for any target and the port pins 
can be defined in the .conf files. Just someone has to do it. ;-)

There's a minor problem left for users still using the source tree for 
compiling. Shall we drop support for this and force users to install Lua 
and nutconf(igure)?

Regards,

Harald