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

[Ulrich Prinz]

Hi Harald...

Am 27.04.2011 11:24, schrieb 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.

Ouch... So much corners where a mouse can hide :)
> 
> Shall we keep hhopen63f.conf? Shall I add this to distcheck.lua as an
>  officially supported platform?

No, the hhopen changed the CPU to a cortex and I lost track of the
project and only have an old release with the AVR. So you can kill the
conf file too.
> 
[...]
> 
>> 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?
> 
No, I added this for any ARM architecture as it will be the same on LPC
and STM32.
But I added a simple thing you can see in the branch:
I called the new routines NutTwiMasterXxx(NUTTWIBUS *bus, ...) while the
old routines for AVR are called TwMasterXxx(...) without Nut in front.
In the nutconf you can select one bus to be the preferred one.
This one is now set in with a simple
#define TwMasterXxx(v) NutTwMaster(DEFAULT_BUS, v)

> eeprom_test still failed to compile for all other targets. I added
> the same
> 
> #if !defined(MCU_AT91) || defined(MCU_AT91R40008) ||
> defined(MCU_GBA)

That may be my fault as I do not have an EN1.x setup to test everything
there and I even failed to run a blind compile run for that target.

In the demo code the routines should be called TwMasterXxx() so they
don't fail with AVR.

The eeprom demo code should be kept for all boards as it is an often
used chip and the code shows how to use it. So anyone can connect an
EEPROM to any supported board and sees how it runs.
> 
> This temporary solution should be acceptable for everyone.
> 
Hmm... I accept AT91R40008 as it doesn't have I2C and MCU_GBA which
might not have I2C, but I tested the code yesterday on AT91SAM7X-EK and
it works with an EEPROM connected. So no idea why it fails for you.
> 
>>> 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)?
>> 
Hard to decide. I never needed that way but I stumbled across the
horrible Makefiles needed for that. I modified then to support Cortex
but never found any changes in the make process behavior. Then I found
out that these files are not the ones I'd like to change. (You told me
that on the phone)

> 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.
sh is included in cygwin too. I could test if that works.
But I am really not sure if we should carry that big bag of stones with us.
> 
> 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.
In that case we should keep it. But we shouldn't roll the drums to much
for it.
> 
> 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.

I did some work with AT91 under linux until I ported that work into the
.nut and .conf files to get it going under windows...

Then we should keep it on a low level. If that is the only thing that
fails for the new version, we should not postpone the version but fix
that special part later.

Ulrich