[En-Nut-Discussion] RFC: LEDs of Demo Kits
uprinz2 at netscape.net
Fri Apr 22 00:31:12 CEST 2011
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
> 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.
> 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
> 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?
More information about the En-Nut-Discussion