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

[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

  -$(MAKE) appname

but in that case I'm not able to see any result at all, making the test 
a bit meaningless.


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

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.

To conclude, it is essential to have well done and working samples.

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!

I'm considering breaking down httpd into several reduced samples, each 
of which demonstrates a single aspect.


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


> 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. ;-)

If such an API exists, an LED sample in nutapp would make much more 
sense for all users.

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.


> 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?

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.

Regards,

Harald