[En-Nut-Discussion] RFC: LEDs of Demo Kits
harald.kipp at egnite.de
Tue Apr 26 10:38:52 CEST 2011
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
>> 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
More information about the En-Nut-Discussion