[En-Nut-Discussion] RFC: "conflicts" statement in configurator scripts

[Ulrich Prinz]

Hi Ole,

I am not quite sure if that works. Any CPU having a serial bus can
access external serial memories. Even it does not have an external
serial bus it could do it via either an CPLD/FPGA or a bitbanging interface.

If the memory has a parallel bus, but the CPU doesn't provide one, it
might be possible to use a serial interface and some glue logic.

So the problem is the point of definition where to activate the driver
for this chip and more or less automatically initialize it.
I hit that NutConfig part several times, where Nut/OS tries to read out
a memory just to detect its own name. I had to modify that part as my
Cortex CPUs use the last flash page for this instead of external memory,
but I still leave it to a users choice to select any external memory if
he prefers.

Check your settings in "Device Drivers->Non Volatile Memory"

What I'd prefer to modify is:
1) move this option somewhere else as it relies on available memories
and available drivers supporting them, but it is OS specific.

2) Add an option to not use this thing at all. For new boards/CPUs set
this option by default to "not available" and preset the config section
with "ethernut" as name.

Then it is to the users choice to make this name configurable and where
to place this.

I know, Nut/OS is network oriented, but I use it now in several projects
with big success where no Ethernet can be connected.

Gretz, Ulrich

Am 25.05.2011 17:03, schrieb Ole Reinhardt:
> Hi all,
> 
> I just spend two days in hunting an abort exception right on boot time.
> 
> The problem was quite simple:
> 
> The configurator script dev.nut includes a configuration for AT49BV
> Flash chips even if the CPU does not have an external bus.
> 
> This config defines the FLASH_CHIP_BASE macro which again is used in
> at91_efc.c and is defined there only if not defined in any other place.
> 
> In short: As it is just defined for the AT49BV chips, this macro is not
> redefined to the settings needed for the internal flash of some AT91
> chips.
> 
> I solved the problem in renaming the 
> 
> FLASH_*** constants in at91_efc.c into EFC_*** constants.
> 
> 
> But now my RFC:
> 
> I would suggest to add a "conflicts" statement (in oposit to the
> requires statement) into the configurator scripts that allows to define
> conflicting configuration options.
> 
> So we could say AT49BV does conflict with MCU_AT91SAM7X512 for example.
> 
> Any further ideas?
> 
> Regards,
> 
> Ole
>