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

[Ulrich Prinz]

Hi Harald!

Am 21.04.2011 11:07, schrieb Harald Kipp:
> Hi Ulrich,
> 
> On 4/21/2011 12:09 AM, Ulrich Prinz wrote:
>> I found out that a lot of demos where deactivated in the Makefile cause
>> they do not compile on any kind of board.
> 
> Right. Sorry about this rigorous action. Running distcheck.lua didn't 
> make sense anymore with many applications failing on many platforms. The 
> point is, that make will terminate on the first failure, leaving behind 
> several untested samples. I tried

I used the 'make clean all' on the STM32 branch after merging latest
trunk to it. Just to check what the examples tell so far.
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.
> 
>> Some of the demos depend on some hardware, like led_key needs some LEDs
>> and push buttons and ioexpander needs some kind of ioexpander on the I2C
>> bus.
> 
> Right, we even have boards without Ethernet interface at all. But still 
> all samples should at least compile. The goal is, to even get an 
> executable binary which simply displays, that the application is not 
> supported on this platform.

Yes, I saw this in the led_key demo and appreciate the idea. I'd check
if I can add this to any demo if not Andres does it.
> 
> I admit, there's some commercial interest here. If we (or other vendors) 
> sell a board to a customer, she will most probably try the samples 
> first. If it fails to compile, she will spend a lot of time trying to 
> figure out what's wrong and finally call for support. Even worse, she 
> may give up, spreading the word of a lousy OS, where not even the 
> samples are working. On the other hand I have several emails from 
> customers, who tried xyzOS with lots of trouble and were enthusiastic 
> about Nut/OS working out of the box.

I fully agree with this, even I am not involved in the selling of
hardware, I like to the Nut/OS community grow. I knew how much power is
hidden inside and I can see how fast you can start developing if even
only basic support of the architecture is availbale. I just need to
watch my colleagues that never programmed a controller before and now
work really fast and effective with Cortex and ARM on Nut/OS.
Not to mention the time I put into this project :)
> 
> To conclude, it is essential to have well done and working samples.
> 
Yes!

> Well, our reality differs. Initially samples were been done to 
> demonstrate programmers, how to use various Nut/OS features. The httpd 
> demo is the one of the fist that is checked by most newbies. But look 
> into this horrible source code. It shows how to use constant data in 
> flash memory, how to display netstat or other system information, 
> demonstrates SSI, ASP, CGI, several file systems, network configurations 
> etc. This is not a good starting point!

Yes! http demo is worse a rework, even it works still good on SAM7X.
> 
> I'm considering breaking down httpd into several reduced samples, each 
> of which demonstrates a single aspect.

It is not a failure to provide one single 'all I can eat' demo to show
how powerful a system can be even running on a small CPU. But for
training it is better to provide it in pieces.
> 
>> We only define super-minimum hardware of our supported boards and so
>> some demos have a difficult life.
> 
> Indeed. I'd suggest to move this target dependent stuff temporarily to
> 
> http://www.ethernut.de/nutwiki/Nut/OS_Examples
> 
> until we have a better solution. One possibility would be to add target 
> specific sample directories. Another one is...
> 
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? I mean, if someone buys a platform and needs some demo that
fits to it, why just sharing super-minimum things that any system with
any OS can show?
> 
>> How about adding some minimal I/O to the board definitions?
>>
>> At least some LEDs and push buttons should be defined for general usage.
> 
> Andre proposed this some months ago, nothing happed so far. (Hi Andre! 
> Are you listening?) I do not understand why people are spending so much 
> time on their own stuff instead of contributing to Nut/OS. ;-)
> 
Hihi, I can't tell, I shoved SHT21 device driver to trunk, and I have
drivers for Sensirion SDP pressure sensors, Freescale MMA754x velocity
sensor and may others on the ramp for release. I provide any driver,
even from commercial projects, that are not buried to any IP of my
company. Or lets say, I commit anything that could easily be written by
just reading the datasheet of the chip.

> If such an API exists, an LED sample in nutapp would make much more 
> sense for all users.
> 
Hehe, I know the problem. Most egnite boards do not have much LEDs and
Buttons :) But if you support a demo kit from any chip manufacturer you
should provide some demo code for a good measure of features of this
board. And most of the original boards from Atmel or STM or their
counterparts from Olimex provide some I/O. Different target users than
the more industrial / control related things from egnite.

> Anyway, it's your code and your decision. I just wanted to fix the 
> distribution check. If you think that it could be done in a portable 
> way, please go ahead and don't hesitate to re-enable it in the Makefile 
> again. I have all required tools for the distribution check installed 
> and can test it. While checking the distribution, I may fix minor 
> problems too, but creating new APIs or figuring out compatibility 
> problems is beyond distribution testing.
> 
You know me, I fix it and enable it without hesitation. But with your
support I'll be sure we will get it working.
> 
>> Another problem is the eeprom demo I wrote. The intention was not to
>> simply write something into the EEPROM and read it back. It is more or
>> less a stress test:
> 
> Understood. But please make up your mind. Shouldn't we move all this 
> testing stuff elsewhere?
> 
Ok... It is difficult to tell. For this extreme testing of the I2C and
EEPROM system it is a very helpful tool for any system designer,
software or hardware. On the other hand it has some requirements that
are not met by any know board besides the STM32F3210x-EVAL kits that
provide multiple slaves on the I2C out of the box.

So it makes sense to add a testing tree to the nut tree and provide this
type of code there. The eeprom demo in the app directory should be
reduced to a level that works on all platforms and shows how to use an
eeprom not how to stress it.

> I know, I'm throwing stones from inside a glass house. The worst of all 
> is Basemon. Well, in fact its a great piece software, running even on 
> broken hardware and different AVR targets without re-compiling 
> [self-praise off]. It should be the first one being removed from nutapp, 
> because it makes sense on Ethernut 1 and 2 based designs only and is 
> more confusing than explaining.
> 
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?

Ulrich