AVR Architecture changes? Topic is solved

[tfAteba]

Hi Giovanni, Utzig,

I'm working on porting ChibiOS on many AVR architecture. My goal is to learn and have better understanding of how RTOS work.

Bellow is starting point for the tinyAVR architecture for example:
https://github.com/tfateba/chibios-on-attiny85

While starting, I think about have another structure under os/hal/port/AVR/:
Instead of having all low devices drivers files there, I would like to add additional directories represanting the supported architecture sush as "tinyAVR, megaAVR, xmegaAVR and so on."

What about that idea? Can I make this kind of structure or is there some disadvantage?

Thanks.

[Giovanni]

Hi,

Up to you and Fabio, are you going to duplicate drivers for the various architectures?

Giovanni

[tfAteba]

are you going to duplicate drivers for the various architectures?

To make it simple for the begining, yes I'm going to dupicate the drivers.

But after having several architectures implemented, I will try to make some common drivers like in the LDD folder on the STM side.

Is there a problem if I duplicate the code and let it duplicated ?

[Giovanni]

Duplicating is generally a bad idea, I do my best to avoid that.

Giovanni

[tfAteba]

I understand, so I will then keep the same concept.
In that case, I will see if it is still pertinent to change the actual architecture so that the specific part goes under the new folders.

[tfAteba]

Thank you for your feedback Giovanni

[utzig]

Hi,

AFAK the core should be very similar, requiring just some #ifdef's, but the HAL is different enough to require new drivers for most peripherals. I would suggest eventually using a directory structure like:

Code: Select all

os/hal/ports/AVR/MEGA/<current drivers moved here>
os/hal/ports/AVR/XMEGA/<new drivers for ATXmega>
os/hal/ports/AVR/TINY/<new drivers for ATtiny>

I don't see much value in running an OS in a Tiny MCU to be honest. They have very little resources, their peripherals are really simple to program, so not really sure why someone would use an OS there (apart from learning reasons). I have one XMega board somewhere but never really used it for anything. Maybe I could help with a bring up of PAL/SERIAL and have one basic blinking/test demo running (but free time is not great right now!).

Cheers,
Fabio Utzig

[tfAteba]

Hi,

Utzig, what you propose was my first idea, but after Giovanni remarks, I decide to not modify the current structure to avoid code duplication.

If we are agree, I will then make the actual port look like you said:

Code: Select all

os/hal/ports/AVR/MEGA/<current drivers moved here>
os/hal/ports/AVR/XMEGA/<new drivers for ATXmega>
os/hal/ports/AVR/TINY/<new drivers for ATtiny>os/hal/ports/AVR/MEGA/<current drivers moved here>
os/hal/ports/AVR/XMEGA/<new drivers for ATXmega>
os/hal/ports/AVR/TINY/<new drivers for ATtiny>

Utzig wrote
I don't see much value in running an OS in a Tiny MCU to be honest. They have very little resources, their peripherals are really simple to program, so not really sure why someone would use an OS there (apart from learning reasons).

You are rigth, I started to port ChibiOS RT and NIL on the ATTINY just for learning reason, and I tougth it would be interesting to share with other people.

I have also plan to work on XMEGA port, just after finishing the the ATTINY, so do not worry if you don't have the time to work on. I already have the hardware too

[tfAteba]

Hi Giovanni, Utzig, All,

I just want to signal that the AVR part of the project sow is architecture change last few weeks, sorry for the notification delay.

I have apply changes as suggest by Utzig in os/hal/port/AVR/ to add MEGA, TINY directories to be able to easily add support for Tiny AVR micro-controllers.

XMEGA will come soon .

Thanks.

[utzig]

Very nice! Once you have serial+pal working just push them, then I'll try taking some time to test on my board and maybe writing a spi or i2c or usb driver.