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

[Harald Kipp]

Hi Ulrich,

On 4/26/2011 11:43 PM, Ulrich Prinz wrote:

> I was faster: declared hhopen dead and removed it from app and Makefiles.

Not completely. NSIS fails, because the files are missing now. Don't 
worry, I've to fix the NSIS script anyway.

Shall we keep hhopen63f.conf? Shall I add this to distcheck.lua as an 
officially supported platform?


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

Yes, I misunderstood that.


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

All this sounds quite attractive, but in the trunk this is only 
available on targets with AT91 TWI hardware, right?

eeprom_test still failed to compile for all other targets. I added the same

#if !defined(MCU_AT91) || defined(MCU_AT91R40008) || defined(MCU_GBA)

This temporary solution should be acceptable for everyone.


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

In early days Nut/OS apps were build in the source tree. There is a 
shell script

http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/nut/nutsetup

to configure Nut/OS. It worked on Windows too, using sh.exe, which is 
included in WinAVR and available from other sources as well.

In version 3 I introduced the Configurator based on Lua scripts. 
Specifically Linux users had severe problems to get this running. I 
added autoconf, but still this didn't help in any case. So we were lucky 
to still have source tree building available.

Today most Linux users were able to switch to the Lua based 
configuration. Building in the source tree is still kept as a last 
resort, enabling users to build Nut/OS apps with a cross toolchain only. 
Although I must admit, that it is not very well maintained and that it 
is not included in the pre-distribution check.

I'm not able to judge, if we should drop it. My main platform is Windows.


Regards,

Harald