FreeRTOS port for avr xmega CPUs

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I would like to announce a new, better FreeRTOS port for xmega cpus. The code and description is here:

http://www.avrfreaks.net/index.p...

I hope people will find the code useful and provide feedback if they find bugs. Testing is limited to a single application for the moment. Nested interrupts should work (but still not tested).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi... would it be possible for you to upload the source code in Github? I'' interested to pursue this project for Xmega. Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Really?  6 years later!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to note that the link there is a LEGACY link. So I changed the "www." to "legacy." and got to here:

 

http://legacy.avrfreaks.net/inde...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Hi "AVRFREAKERS",

 

I totally realize that this thread is old and some of you will complain that I've resurrected it, but the need for an RTOS for the XMEGA reared it's ugly head for me well over a month ago and I've been struggling to get something to work since. Kudos to georgeov for his work and posting it here. I now have FreeRTOS running on the 32E5 using the latest FreeRTOS version 9.0.0 (not that I need the latest, really, but that's the documentation I can get my hands on). To be honest, FreeRTOS is much more RTOS than I need and I'd hoped for a simple scheduler with a few message queues, a mutex and semaphore or two, and solid bullet-proof operation under interrupts.

 

It has come to my painful conclusion that Atmel should'a provided a "Atmega compatibility mode" to allow a simple interrupt system to be used, with the option of stepping it up to hardware prioritization, etc. should your ap really need that sort of thing. I'm cursing myself for choosing the E5, but the feature set was near perfect for my application, but the interrupt system is, quite frankly, a nightmare (mama didn't warn me about that).

 

By the way, my project is refitting an old (circa 1986)  German beer bottling machine with brand new controls. There are 36 rotary fill heads and each head has an Intelligent Filler Control module based on the E5 mounted on it with a multi-drop RS485 communication network to the master controller (also an E5) and a PLC supervisor with the MMI.

 

Cheers,

Ken

(PS: I owe georgeov a few beers)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cool project!

KenwickVS wrote:
... and I'd hoped for a simple scheduler with a few message queues, a mutex and semaphore or two, and solid bullet-proof operation under interrupts.
Similar exists in Quantum Platform (QP) (event scheduler and framework, event queues, re-entrant, ISRs)

There's some recent work on QP-nano (8 active objects) for XMEGA.

The previous QP for XMEGA is legacy leaving QP-nano for tinyAVR and megaAVR.

QP is dual license (GPLv3, commercial) meaning QP has a price for commercial applications.

KenwickVS wrote:
It has come to my painful conclusion that Atmel should'a provided a "Atmega compatibility mode" to allow a simple interrupt system to be used, with the option of stepping it up to hardware prioritization, etc. should your ap really need that sort of thing.
Doubt that will happen as Microchip has a two level priority interrupt controller in the relatively new tinyAVR 1-series.

fyi, tinyAVR 1-series tiny3217 is in-work and may be an alternative to XMEGA32E5; two of the several advantages for XMEGA E5 is the 16-bit mode for its ADC and more pins.

 


http://www.state-machine.com/

QP-nano for AVR xmega--hold the onions, but give me some extra AO's with that please

https://sourceforge.net/p/qpc/discussion/668726/thread/2e67d9c8/

via https://sourceforge.net/p/qpc/discussion/search/?q=XMEGA

Microchip Technology Inc

Microchip

Press Release

New tinyAVR® MCUs Increase System Throughput While Lowering Power Consumption in Embedded Applications

Microchip Continues Expansion of AVR Microcontroller Product Line with Addition of Three New tinyAVR Devices

Chandler, Arizona

March 13, 2017

https://www.microchip.com/pressreleasepage/new-tinyavr-mcus-1617

...

For more information, visit: www.microchip.com/1617series

...

http://packs.download.atmel.com/#collapse-Atmel-ATtiny-DFP-pdsc

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For mega's and tiny's, I have used a small cooperative RTOS called Salvo for a few projects.

Coop RTOS work fine if your tasks are small and well defined.  http://www.pumpkininc.com/ for details.

Documentation is good, it is a commercial product but has free demos which worked well for my needs. 

 

Jim

 

 

 

edit: typo

Last Edited: Wed. Sep 20, 2017 - 02:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A while since I last "maintained" this list (so some could be dead now) but other RTOS choices for AVR here:

 

http://www.avrfreaks.net/forum/t...

 

Of course the majority are for tiny/mega not xmega and especially not "e5" so any of them would probably have faced similar issues in the porting (especially the preemptive ones)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

μC/OS-II is on XMEGA128A1 and it has a zero price version for small operators.

 

https://www.micrium.com/download/micrium_xmegaga128a1_ucos-ii/

http://www.avrfreaks.net/forum/micrium-%C2%B5cos-makers

 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It has come to my painful conclusion that Atmel should'a provided a "Atmega compatibility mode" to allow a simple interrupt system to be used, with the option of stepping it up to hardware prioritization, etc. should your ap really need that sort of thing.

    If you set the same priority level on all interrupts, (the highest one for example) aren't they behave much like mega ones ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

angelu wrote:

It has come to my painful conclusion that Atmel should'a provided a "Atmega compatibility mode" to allow a simple interrupt system to be used, with the option of stepping it up to hardware prioritization, etc. should your ap really need that sort of thing.

    If you set the same priority level on all interrupts, (the highest one for example) aren't they behave much like mega ones ?

 

Unfortunately, the XMEGA doesn't behave like the MEGA even with using the same interrupt priority for all interrupts in the system. There are some good, but confusing, discussions regarding it on this forum. When I catch up, I'll try to clarify the issues as they relate to an RTOS and the current solution goergev provided for FreeRTOS.

-Ken

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

A while since I last "maintained" this list (so some could be dead now) but other RTOS choices for AVR here:

 

http://www.avrfreaks.net/forum/t...

 

Of course the majority are for tiny/mega not xmega and especially not "e5" so any of them would probably have faced similar issues in the porting (especially the preemptive ones)

 

Yep, I was happily using a small, but nice kernel named "avRTOS" and it had everything I needed, but when I began using it on the xmegaE5 (which I'm committed to at this point) it drove me totally crazy so I switched to FreeRTOS with goergev's port modifications. If I get time, I'd like to convert "avRTOS" to "xavRTOS" for the XMEGA now that I've been through the learning curve. It is open source and I'm sure others could use it.

-Ken