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

Ulrich Prinz uprinz2 at netscape.net
Sun Apr 24 19:56:10 CEST 2011


Am 22.04.2011 13:57, schrieb Harald Kipp:
> Hi Ulrich,
> On 4/22/2011 12:31 AM, Ulrich Prinz wrote:
>> So I stumbled accross some of the compile breaking points and fixed the
>> issues for this platform. Well, fixed it but not tested every example.
> 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.
>> Yes and no.  There is no fault to provide target specific demos right in
>> the installation. May be we should split the things a bit and only
>> install demos from the nut/app to the nutapp_xxx_yyy if the platform
>> matches?
> As long as such demos are clearly marked as target board specific, I 
> have no objections.
The demos are made for people starting with OS at all. So they buy a
valuable demo kit that already inherits some interesting hardware. So
besides learning how to use a USART it may help to provide examples for
velocity- / temperature- / light- / whatever sensors. That shows the
general power of the underlying OS and may help to find the way how to
write a driver and bind it to the OS. If I finished the Freescale Sensor
I'll add the STM sensor easy :)
>> Again, why not adding a feature to (q)nutconf and a app.nut to just copy
>> over those apps that are confirmed to work with the selected platform?
>> And a basic set that shows how to use LED, key, usart, ethernet?
> Could be done. Although, the Configurator's function to create an 
> application sample tree is a temporary solution. One of those long 
> living temporary solutions, I agree. There are old plans to provide an 
> application wizard instead.
Ok, with the wizard it could be done the other way round. While we now
would have to place lots of #if defined(THIS_BOARD) in the demos, a
wizard could assemble a demo out of code pieces. That would result in
clean code without any board or chip dependent #if lines. That could be
a nice thing of work :) But that should be discussed in a new thread.

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.

On the other side I only asked for support of may be 4 LEDs and 4
Buttons that are predefined in the board.h. For egnite boards there
should be pins predefined that are not used by any other on board
component. So the user could add the LEDs and buttons easy.

I'd just like make newbies life easy: Start with getting a LED blinking,
the rest will come :)


More information about the En-Nut-Discussion mailing list