[En-Nut-Discussion] RFC: New driver interface for TWI, I2C and others

[Ulrich Prinz]

Hi Uwe...

you're following me, are you (look around...) :)

Am 27.04.2011 11:41, schrieb Uwe Bonnes:
>>>>>> "Ulrich" == Ulrich Prinz <uprinz2 at netscape.net> writes:
> 
[...]
> 
> Ethernut runs on RAM starving and platforms with ample RAM. My CAN
> application on an AT90CAN128 uses one binary for a pletora of devices, as
> flash with 120(128)kiB is ample, but RAM with 4 kiB is few. I guess those
> driver descriptor structure will use ample RAM, and on those ram-starving
> devices their usage has to be considered.
> 
> Otherwise the approach sound fine.

Thanks... Yes, I thought about that long time. I am talking of 10..20
bytes of RAM... But yes, if you add that all together it may increase
RAM usage about 1..2% and that is much if you only have 4k or less.

With I2C I already did it in another way:
Old functions where called TwMasterXyz(...)
New functions are called NutTwMasterXyz(NUTTWIBUS *bus, ...)
Now to things glue them together:
1) In Nutconf you can configure one bus of the ARM/Cortex devices to be
the default bus.
2) In a header file the things are patched together:
#define TwMasterXyz(p) NutTwiMasterXyz(DEFAULT_TWIBUS, p)

So you can compile existing code relying on the TwMaster thing and get
the new driver beyond it. But if you have an application that needs
more, you can change to the NutTwMaster thing.

The same could be done with the USARTs and the other devices of the chips.

I got that idea from the eeprom. I needed to add multiple EEPROM like
devices and so I wrote the AT24C driver. The older eeprom.c could only
work with one real EEPROM. But modifying it would break all platforms
and all existing user projects. So I added At24C driver and a small
#define layer in the middle. The driver is now used on any ARM platform
and I am sure that some users never knew about that. But AT24 registers
an EEPROM with a tiny little struct and I can prepare such structs as
many as I like an register all that chips at any bus.
> 
> P.S.I am trying to switch to STM32F for the reason og low RAM on the
> AT90CAN, the missing speed at 3.3 Volt and the missing 5-Volt tolerance of
> the AVR when run at 3.3V.

Yes, right my reason to leave ATMEL for a while. All of their chips miss
at least one thing I need. And while price doesn't differ much if you
compare chips with same size of FLASH, the features and speed differ a lot!

And one should ask himself if it makes sense to design a sensor system
that most times works with values and data of 16..20 bit on a CPU that
only has 8 bit. It obviously will increase cycles and FLASH needed. So
instead of running a 8 bit CPU at 16MHz full speed at 20mA I run a 32
bit CPU at 16MHz <10mA even it could go 72MHz.
> 
> PPS: Has anybody informations where to get STM32F2xx devices?

I need to call STM these days anyway, if you like I can request a
contact for you. Ah, for business use, call EBV Elektronik.

Ulrich