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

[Ulrich Prinz]

Hi!

Am 26.04.2011 10:38, schrieb Harald Kipp:
> Hi Ulrich,
> 
> On 4/24/2011 7:56 PM, Ulrich Prinz wrote:
>> Am 22.04.2011 13:57, schrieb Harald Kipp:
>>> Any specific reason why 'make clean' had been disabled for app/hhopen?
>> No, I thought about deleting that project completely. I introduced it
[...]
> 
> If we introduce board specific samples, we would need a policy for this 
> case. Unmaintained samples should be removed after a specific period of 
> grace.
> 
I was faster: declared hhopen dead and removed it from app and Makefiles.
> 
>>> application sample tree is a temporary solution.
>> But that should be discussed in a new thread.
> 
> Right. Just meant as a warning not to invest too much effort.
> 
I wouldn't, was just an idea of how to do that in future.
> 
>> 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.
> 
> Not sure about moving the samples down one level in the tree. I know, 
> many of you guys are using absolute paths, but I'm quite defendant on 
> relative paths in Makefiles.
> 
You might have misunderstood me. My solution just copies back every demo
to nutapp_xxx_gcc/ but it sources from first app/general and second
app/arch/xxx/. The result is still a one level nutapp directory but it
only conatins working minimal and working architecture dependent demo
code. For the current users nothing has changed.
> 
>> On the other side I only asked for support of may be 4 LEDs and 4
>> Buttons that are predefined in the board.h.
> 
> Only? :-) As we say in Germany: Beware the rat-tail.
> 
> What's missing is a clear statement, what has to be implemented for any 
> new target. De facto the GPIO API is a requirement. If GPIOs are not 
> available at all (GBA, Linux Emulation), Nut/OS may provide dummy routines.
> 
As we say in german: keep the church in the town.
It is one thing to add LED_PORT1 / LED_PIN1 and write a #if defined
(LED_PORT1) && defined(LED_PIN1) \ GpioPinConfig....

It is another thing to document all board features supported and how to
define them in a board.h and then rewrite 90% of the existing code by
splitting lots of files to board... Wow, that needs to be done with at
least 4 people with a locked repository in 14 days and then committed on
one bunch. Otherwise lots of open ends will exist rendering lots of
boards unsupported and code uncompilable. Sam situation if I commit my
STM32 changes. I already verified lots of the code against SAM7 but need
to rewrite some parts of AVR. Or we have some transfer-defines left in
the code that transform old calls into new ones.

> Beside defining, what APIs are required for every target, we need to 
> specify the required functions. For example, we have the new functions 
> TwMasterRegRead() and TwMasterRegWrite(), which are convenient, widely 
> excepted and used in two general drivers at24.c and pca9555.c. The 
> implementor needs to know, that he is only forced to implement them, if 
> he needs support for AT24xx or PCA9555 chips. Luckily the Configurator 
> is of great help here.
> 
Yes, that's the point, where the old guys stuck with slow _eeprom_ acces
and no hint, that there is a driver that can be configured to enable his
specific EEPROM in full speed with polling and non blocking shared I2C
access and so on. You never see, that if you use at24 driver instead of
the old eeprom driver, that this driver can be used to register even as
many EEPROMs as you like and it even can register buried EEPROMs that
are available in RTCs and other chips. And you never see, that this
driver only needs about 10 bytes of RAM per additional EEPROM you add.
(I registered the SHT21 and SDP sensirion sensors (humidity and
pressure) with it and it worked out of the box.

And if you stick to the good old TwMasterRegRead on the AVR and SAM7X
version you never see, that with the new version ( that needs one
additonal pointer to a i2c-bus struct) you can add as many I2C buses as
your chip provides with only paying some 10 bytes of RAM and only very
few bytes of flash.

For convenience the STM32 branch provides a define for NutTwiMasterxyz()
to translate it to the bus that is marked as the default bus in the
configurator. But the target is to replace the multiple compiled drivers
with the lean ones.

And so it is for the USART. And if your chip provides five of them it
does matter if you duplicate the complete code of the USART or if you
just carry another 20 bytes of RAM (+buffer) in a struct per port.

Yes, you guessed right, it is exactly the same with SPI... (STM provides
3..7 of them per chip)

Oh my... This is a real discussion thing that should be in a separate
post. But there are already big discussions ongoing.
Don't beat me, I try it :)

> Back to the topic. No problem, if the LED/Button API is based on the 
> GPIO API. It will automatically compile for any target and the port pins 
> can be defined in the .conf files. Just someone has to do it. ;-)

Yes, that was what I meant. We already have a board.h file that provides
some additional specific options like naming the first USART and the
first I2C bus. If we could add 2 LEDs and 2 buttons our examples would
light up even the first-time user has messed up with RX/TX lines.
> 
> There's a minor problem left for users still using the source tree for 
> compiling. Shall we drop support for this and force users to install Lua 
> and nutconf(igure)?

I didn't check this as I forgot that this is possible. I only checked
with separate nutapp directory. I don't see any reason to poison the
installation sources if there is an option to provide clean checkouts
that can be reconstructed at any time.

I guess this option is for command-line only users and linux? So why not
adding a Makefile command to create the directory? Should be possible
without problems.

Ulrich