Atxmega Port with RIOT OS - Where to put abundance of new driver features?

Development archive
1

Hi Everyone,

I’m nearing completion of a port for RIOT OS to the ATxmega family of devices (targeting the atxmega128). The Atxmega is feature rich when contrasted against the Atmega counterpart which I am using as a porting guideline.

  1. Since I would like to contribute my port to the git repository, how should I go about implementing new CPU features not found in the core RIOT OS functionality (enhanced TWI, USART, etc.)?

  2. How should I implement the addition of both Master and Slave functionality to my peripheral interfaces?

  3. How should I go about adding interrupt functionality for these peripherals?

Currently I am just smashing these extra features right into the driver’s .C files as I am trying to preserve the OS-Core files.

Any suggestions would be appreciated!

Madison McCarthy

2

I have a working port of an atxmega256a3u

I started to port it to a common folder maybe we could work something out

3

I just pushed it to my repo as it is, so you can have a look.

https://github.com/Josar/RIOT_XMEGA

I would suggest to implement the common functionality in the atxmega_common folder.

I have done the gpio, timer anf the uart but spi is still hard coded to my platform.

4

Hi Madison,

awesome to hear about your port, it will be very nice to have ATxmega support in RIOT. I will try to answer your questions inline below.

Hi Everyone,

I'm nearing completion of a port for RIOT OS to the ATxmega family of devices (targeting the atxmega128). The Atxmega is feature rich when contrasted against the Atmega counterpart which I am using as a porting guideline.

1) Since I would like to contribute my port to the git repository, how should I go about implementing new CPU features not found in the core RIOT OS functionality (enhanced TWI, USART, etc.)?

I don't quite get the question. TWI (i2c) and UART are interfaces provided by RIOT, which are simply implemented by the specific CPU implementations, hence their implementation code should reside in the corresponding cpu folder (as in /cpu/atxmega_common/periph/uart.c, etc.).

2) How should I implement the addition of both Master and Slave functionality to my peripheral interfaces?

For the master mode of SPI and I2C (TWI) there are interfaces designed by RIOT (-> drivers/include/periph/[spi|i2c].h). So simply implement them for the ATxmega and you should be good to go.

Currently there are no interfaces for the slave mode of these buses, so my proposal would be that you include slave interfaces together with the CPU code (so to make the slave implementations CPU specific for now), and adapt the code at a later point in time once we introduce slave interfaces to RIOT.

3) How should I go about adding interrupt functionality for these peripherals?

Not sure what you mean: peripheral specific interrupts should be handled inside the corresponding periph drivers. The global interrupt handling is abstracted by the core/include/irq.h interface, which needs to be implemented for the CPU family.

Hope this information helps, let me know where clarification is needed!

Cheers, Hauke

5

Hi Hauke and Arndt,

Hauke: your answer is sufficient for me to progress forward, thanks a bunch! My main concern has about adding additional functionality such as interrupts, slave mode, etc. into already defined RIOT peripheral headers. I’ll locate the new features that are not encapsulated within the RIOT-core or RIOT-drivers as device-specific functionality for now.

Arndt: I’ll message you directly about collaborating on an Atxmega port that can be pushed to the RIOT repository. I’ll finish my port first (1-2 days hopefully) before I examine your port so we can blend the two products together into something worth sharing :slight_smile:

Thanks again!

Madison McCarthy