[En-Nut-Discussion] Ethernut on TI's Cortex-M3 (Stellaris LM3S...)

[Ole Reinhardt]

Hi Philipp,

> Could anyone point out the "usual way" to add support for existing 
> devices to new platforms?

First of all, to make collaboration and later integration of your work
to the mainline Nut/OS easier, I'd suggest that we should create a SVN
branch for your work. It would appreciate if you could use this SVN tree
for your development, so everyone who is interested can have an (easy)
look and can compare files with svn diff.

I did not yet found a good workflow to use your git repo / patches / and
the SVN trunk together to follow your development.


So my suggestion:

Do you have a sourceforge account? If yes, please send me a mail with
your account name. I could than add you as developer to the project and
grant you write access. I also could create a branch and add your latest
changeset there.



Next:

Yes, there is a porting guide:

http://www.ethernut.de/en/firmware/porting.html

But I think this one is still far from complete. So feel free to note
down everything you learned while porting, perhaps we can then complete
this guide.


In general:


First try to understand how the configurator works and setup you own set
of .conf flags. Create a new subtree in nur/conf/arch/cm3 for your own
platform.


Concerning the device drivers:

Try to compare the different implementations, e.g. AT91, LPC, STM32. If
you start with AT91 and LPC, you might get a nice overview, STM32 just
implements drivers for so much different sub-types, that you might
easily lose the overview.


> Example: There is a file uart.h and a usart.h. What is the
> difference? I'd expect them to be almost identical, with the only
> exception that a USART also supports synchronous interfaces. But the
> two headers do not seem to be similar in any way.

AFAIK uart.h is more or less deprecated, all modern drivers use usart.h 


> According to what I've seen in the source tree, I'd probably add UART 
> support for the LM3S this way:
> 
> - Add some UART device to the LM3S family configuration.

Exactly

> - Create a header lm3s_uart.h which exports the available UARTs as 
> DEV_UART0, DEV_UART1 and so on.

Right. Depending on the way you want to implement the driver, you might
want to create the UART driver according to the LPC implementation,
where your driver consists of two parts:

a) generic functions in a lm3s_usart.c
b) one file for each instance, including the first one. Each providing
   one device for this instance (e.g. lm3s_usart0.c, lm3s_usart1.c, ...)

> - Create a source file lm3s_uart.c which populates and exports a 
> NUTDEVICE structure per device and implements the necessary callbacks.

Yes, but ideally split up these implementations as explained above. This
way only the code which is realy needed by an application is linked.
Dead code (for driver instances that are not used anyway) will be
omitted by the linker.

> Is this correct, or are there other levels of abstraction which should 
> be taken into account?

For some other drivers we just have a common API as well:

- Debug UART (UART in polling mode)
- GPIO api
- SPI bus api
- TWI bus api
- RTC api
- Not really a generic api, but a more or less common way to implement
  ADC
- Some kind of CAN-Bus api
- Ethernet PHYs
- Network interface


If you have specific questions for some drivers, please let me know.

bye,

Ole

-- 

Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting

http://www.embedded-it.de

Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen - 
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97

Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280