[En-Nut-Discussion] RFC: LEDs of Demo Kits
harald.kipp at egnite.de
Thu Apr 21 11:07:09 CEST 2011
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
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
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
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.
More information about the En-Nut-Discussion