Hi, I am trying to multitask with Arduino UNO using FreeRTOS. It works well when using LEDs etc. but in the case of the stepper motor, it is not working perfectly as the rotor produces some vibrations. plz guide.
thanks in advance
plz post code
RTOS stands for Real-Time Operating-System.
Realtime means the RTOS guarantees that any task will be called withing a certain time-limit.
I don't know the FreeRTOS for arduino and never had a use for it though I'm doing a lot of multitasking stuff.
I assume FreeRTOS uses a timer-interrupt to make sure each task is executed withing a certain time-limit.
stepper-motors need a timely very regular pattern of step-pulses.
Now the FreeRTOS interferes with that through the interrupts.
If an interrupts occurs all and everything what the code is executing wil be (name is program) interrupted to do execute the interrupt-code and then returning back to normal operation.
If you want to have a stepper-motor running very smoothly and do other things like controlling servos or LEDs etc. at the same time use the MobaTools from user @MicroBahner
best regards Stefan
Thank you so much. Plz provide me with an example of code in your suggested library including stepper motors and other functions as I am a beginner.
#include <Arduino_FreeRTOS.h>
// #include <AccelStepper.h>
int seedcount=0;
int flag=0;
int delayValue = 3500; // in microseconds
int VacuumSpeed = 150;
// Vacuum Motor pins
#define RPWM_Output 5
#define LPWM_Output 6
// Nema 23 pins
#define pulPin 9
#define dirPin 8
void setup() {
// int A_V = analogRead(A0);
Serial.begin(9600);
xTaskCreate(Vacuum_Nema, "Vacuum", 256, NULL, 1, NULL);
//xTaskCreate(Nema, "Nema", 256, NULL, 1, NULL);
xTaskCreate(Seed, "Seed", 256, NULL, 1, NULL);
vTaskStartScheduler();
}
void loop() {}
void Vacuum_Nema(void *pvParameters){
// Vacuum pins
pinMode(RPWM_Output, OUTPUT);
pinMode(LPWM_Output, OUTPUT);
analogWrite(LPWM_Output, 0);
//Nema pins
pinMode (pulPin, OUTPUT); // set Pin9 as PUL
pinMode (dirPin, OUTPUT); // set Pin8 as DIR
digitalWrite (dirPin, LOW); // set high level direction
while(1){
//vacuum speed control
analogWrite(RPWM_Output, VacuumSpeed);
//nema speed control
digitalWrite (pulPin, HIGH);
delayMicroseconds (delayValue);
digitalWrite (pulPin, LOW);
delayMicroseconds (delayValue);
}
}
void Seed(void *pvParameters) {
int A_V;
while(1) {
A_V = analogRead(A0);
Serial.println(A_V);
if (A_V >=25 && flag == 0)
{
seedcount = seedcount+1;
flag=1;
//Serial.println(seedcount);
}
else if (A_V < 15 && flag == 1)
{
flag = 0;
}
//delay(150);
}
}
Down load the tool, it comes with examples.
What does this mean? Your code could be responsible for this
Thanks you @killzone_kid . i have posted the code. actually i am begineer in programming. need help in optimizing that code for Arduino FreeRTOS.
feeRTOS on a Uno is an add on, an after thought. The library consumes a lot of memory for little gain and at least 20% of the processors resources. With an Uno a State machine would multi-task much better. On the other hand freeRTOS is the OS that the ESP32 boots when power is applied and a ESP32 has enough ram RAM.
please describe your project. What kind of functionality do need in the end.
Running a stepper-motor continously in a while (1)-loop means your stepper-motor could be replaced a standard-DC-motor that is simply switched on/off.
I second using a state-machine instead of FreeRTOS for multitasking
good suggestions can be made if you have posted an overview about your project
best regards Stefan
I too would support that proposal.
That's in incredibly bad idea given the limited resources of the Uno platform.
If you're a beginner, you definitely shouldn't be trying to program in a multi-tasking OS environment. You literally don't even know what you don't know. You likely don't even know why you want to be using FreeRTOS.
As others have stated, stick with millis-based "Arduino Style Multitasking" and a state machine.
With due respect to all who answered to move away from a rtos model, the fact is that the microcontroller world is quickly moving toward the RTOS model; you simply can deny it as with the ESP32 and respect that it is working behind-the-scenes, but you lose the whole concept of dual-cpu capability from the end-programmer perspective.
Now, jumping on freeRTOS with an UNO is walking on resource-thin ice, but your use of two tasks and the rtos is legitimate even if a simpler methodology exists. At issue is that both of your two tasks could be simpler but you would not know that because you have not performed a task profile: do you know how long each task will take on the average? Without an understanding on how 2 tasks must work together you have no way to inform freeRTOS what the task priorities are.
There is a volume of information on the Internet regarding how to time section of your code and I'll leave this as an exercise for you.
More importantly, you need to understand what freeRTOS does with priority ... start with an understanding on how the task is created:
and then read the section on priority several times. This is critical and it is one of the primary methods of tuning the rtos to work with your software design.
With more of the Arduino hardware line using multiple-core processors in their designs, there is no better time than the present to start working with freeRTOS. This means understanding when the supervisor is required and how to "tune" the software. As stated by others, often rtos is more trouble than it is worth and can slow project development.
That's all well and good. But it all depends on your interpretation of a statement such as:
If that means "I'm a competent coder in all things single-task and single-core but I'm a beginner to RTOS and multi-tasking", then Great! Have at it, jump into programming under FreeRTOS. You'll find it interesting and fairly easy.
But, if it means "I'm a beginning programmer who has never coded before", then I stand by my previous advice.
Post #1:
Clearly, Op had at least one successful play with freeRTOS and this post indicated a successful implementation/compile but with issues/concerns. Viewing the forum as a "help" forum, I found it appropriate to provide resources back into the tech reference for freeRTOS and not tear down existing work effort.
Of course, I offered and reinforced the strong caveat you and others offered; but, I see no need to toss the existing codebase. Likely, Op is only a few tweeks away form getting the code to function as needed... cleaning up the stepper routine would be my priority.
I encourage you to stand-by your advice, I even emphasized that. But there is simply no reason to tear-down an approach as too complex, too resource-hungry, when the Op has successfully implemented the paradigm and has learned the implementation but not all the nuances.
I am not a beginner with using freeRTOS on a Uno. I can say that trying to write and run any meaningful program using a freeRTOS library on an Uno just plain sucks.
I learned RTOS with a DUE using uMT. The DUE has enough butt to run a RTOS but not an Uno. When I tried freeRTOS on a Uno I found it just does not work well and may discourage people from moving into the RTOS world. I know if I had jumped into RTOS and had originally encountered all the issues that the Uno is going to throw, I'd have not continued to use an RTOS.
Which is where my POV come from. I say freeRTOS and an Uno, sure go for it. Do it. But know it's going to suck, especially when one begins to use Queues and finds the Uno just does not have the RAM. And the whole semaphore thing gets really wonked out. Thus, why would I encourage or promote someone to use RTOS on a Uno when I know it just plain sucks?
I have to respectfully disagree with this statement. I've found that FreeRTOS works really well on AVR based boards, especially for modest projects that require say 5 or so tasks and a similiar number of software timers. This includes the use of inter-task communication such as queues, binary and counting semphores, task events and notification.
Obviously, not all applications require, or are suitable for a real-time operating system, but it does provide a number of advantages, even on small AVR microcontrollers. Usually, the main reason for precluding FreeRTOS on these microcontrollers is the slow 15ms minimum time slice interval.
The programming model actually simplifies the code:
The FreeRTOS can implement priority based preemptive scheduling and time slicing, or alternatively these can be turned off for co-operative scheduling instead. The latter is great for beginners, because it means not having to deal with mutual exclusion, since it ensures that tasks are run to completion and block before switching.
Inter-task communication makes the passing of data and/or data structures between tasks conceptually relatively easy.
Continous and oneshot software timers are easy to implement. The fact that they're generated from the AVR mcirocontroller's watchdog timer, means that other timers (0, 1, 2, etc..) remain unaffected, as are the Arduino libraries that use them.
Hardware interrupts are handled outside the context of the RTOS, but can be configured within the ISR function to trigger the execution of a RTOS interrupt handler task. This ensures that ISR functions are kept short and allows the processing to be handled within the RTOS itself, which is a really neat feature.
Idle task hook is executed when all the tasks are done and there's currently nothing more to do. This allows for more efficient operation, since it allows for low priority code to be executed and an ideal opportunity for the microcontroller to be put to sleep.
State machines and real-time operating systems are not mutuallly exclusive and serve different purposes. It's possible to implement state machines within RTOS tasks.
My last project was run on a ATmega32U4, which once the 4k bootloader is taken into account, leaves a total memory of 28k. It uses FreeRTOS and runs 4 prioritsed tasks (co-operative scheduling, no time slicing) with task notifications, 6 software timers, state machine, tone, RTC, rotary encoder and scrolling 4-digit 7-segment alpha-numeric LED display menu.
Hi @m_umer_awan
In your code, since the two tasks (Vacuum_Nema and Seed) are at the same priority (level 1), the FreeRTOS scheduler will switch between them around every 15ms, providing each one with an equal time slice.
Vaccuum_Nema will be unable to provide speed control, while the Seed task is executing.
With 2KB of RAM? How much stack space are you allocating per task? Seems like that would be a constant battle against stack overflows. I can imagine endless tweaking as you try taking a few bytes away from one task's stack and give it to another to fight the latest unexplained crash.
Hi @gfvalvo
I allocate 128 bytes per task and to be honest I've never encountered a problem. If I had, I could always use the FreeRTOS uxTaskGetStackHighWaterMark() function to keep tabs on how much memory I've got left before stack overflow, and allocate more if necessary.
In any case, a local variable stored on a task's stack is usually one less variable stored globally on the main stack, so the task's memory overhead is generally just storing the task's context whenever it's in the blocked state.
There's also the task's *pvParameters function parameter that can be used to pass a pointer to an external data structure if required.