Arduino Forum

Development => Other Software Development => Topic started by: fabriceo on Dec 17, 2012, 08:35 am

Title: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 17, 2012, 08:35 am
Hello,

I m pleased to release another multi tasking alternative called SCoop for Simple Cooperative scheduler, for the Arduino and Teensy platforms AVR and ARM, using the yield() standard function.

There are couple of alternatives for doing multi tasking on arduino, including famous RTOS like chibiOS or freeRTOS, but also some light implementation like adOS published on this forum or interrupt driven library like ieOS.

I decided to create this one to bring some user friendly declaration principle and to bring some features I didnt find in other, especiall needed when doing home automation or industrial control, like we find sometime in PLC.

the Version 1 jus released this week end is available on google code here :
https://code.google.com/p/arduino-scoop-cooperative-scheduler-arm-avr/ (https://code.google.com/p/arduino-scoop-cooperative-scheduler-arm-avr/)

This pack includes a comprehensive (hopefully) 14 pages user guide and contains 3 standalone libraries.

SCoop.h provides object and macros for easy creating Tasks, Events and Timers.
TimerUp/Down.h provides object class for defining unlimited time counter object with time base handling
IOFilter.h provide objects for declaring and using Input, Output, time filter inputs (extended debounce style)
user guide v1.0 with user and technical info and some performance measurement.

The pack has been tested on Arduino Uno, Teensy++2.0 and Teensy3.0 (beta8) with Arduino IDE v 1.02.
I d be glad if someone could look at it and try it on Arduino DUE as I have not this board myself. just force the definition of __MK20DX128__ at the begining of SCoop.h

remark : to use it in a final project you might remove the line including "scoopdebug" and removing the SCOOPTRACE definition in the SCoop.h. at the moment it is still included, this gives the possibility to "trace" your code : just use trace("my step one in task1")

just an example:
Code: [Select]

#include "SCoop.h"

defineTask(myTask1)
void myTask1::setup() { Serial.begin(57600); }
void myTask1::loop() { Serial.println("hello from task");sleep(1000); }

defineTask(myTask2)
void myTask2::setup() { pinMode(13, OUTPUT); }
void myTask2::loop() {
  Serial.println("led HIGH");digitalWrite(13, HIGH);sleep(500);
  Serial.println("led LOW");digitalWrite(13, LOW);sleep(500); }

void setup() { mySCoop.start(); }
void loop() { Serial.println("do whatever you want here also"); mySCoop.sleep(500); }


got it ? :)
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 17, 2012, 10:18 pm
A short update regarding performance and footprint in memory.

The extra code size needed for the library for the scheduler, the task wrapper and a single call to yield in the main loop() is 1700 bytes on AVR  This looks cool especially considering that the library is written Object Oriented and use extensively the benefit of virtual methods.  :)

on Teensy 3 (ARM) we end up surprisingly with 4900 bytes more for the library. this is not really a problem as the chip got 128K program size, but I will investigate why sometime.

RAM memory used by the library variable is not significant here but is mainly impacted by the size of the stacks allocated to tasks. Hopefully this can be sized to the very minimum by using the library method stackLeft to monitor the unused space.

regarding performance, with a recent update in the yield method (to be published wednesday), we end up with a total time of 45us for switching between 2 tasks on a Teensy++2.0 and 55us on Arduino Uno and less than 10us on Teensy 3 (arm).
this time includes timing checking and storage with some calls to (un)famous millis as this library doesnt need any timer or interrupts.
this is anyway  good performance which provide a 5% max time lost for scheduling 4 task runing on AVR (3+main loop) and less than 1% on Teensy 3.

unless you do realtime missile cruise calculation you d be safe , right ?

here we go
any body got a DUE to try this fancy lib ?? !  :smiley-mr-green:
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 18, 2012, 12:21 am
Any idea why the context switch is slow?

Typical RTOS times are faster.  For ChibiOS/RT giving a semaphore plus a context switch to the task that takes the semaphore is:

Uno: 15 us

Teensy 3.0: 3 us

Due: 2 us

Task context switch time are less, 11.25 us for 16 MHz AVR and 1.02 us for 72 MHz ARM CM3. http://www.chibios.org/dokuwiki/doku.php?id=chibios:metrics (http://www.chibios.org/dokuwiki/doku.php?id=chibios:metrics)

Clearly this is not a problem for a cooperative scheduler.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 18, 2012, 08:07 am
yes, some idea about that

in fact the time I ve given is the total overhead time needed by the scheduler to

1- verify if the task should be interupted. this includes verifying time spent in the task and comparing it to a "quantum". this garantees that all the task will get a certain amount of cpu time (unless they slep of course)
2-calculate overage time spent in this task over the 2/4/8/16 last cycles
3- check which task is next
4- switch task context to next
5- calculate overage time spent since we enter in this task (2/4/8/16 last cycles), to update the overall cycle time variable.

and then it is very ok compared to the pure assembly context switch routine which is very fast as you pointed out.

the steps 2 & 5 can now be de activated in a new version of the library (pre processing) and this will probably divide the time given by 2, but I need a oscilloscope to check this !

last but not least, the library isnt using any interrupt but systematic calls to the Arduino Millis() and this approach is very flexible but consume more cpu than traditional RTOS systick method, especially on Arduino compared to Teensy which is better optimized.

here we are
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 18, 2012, 01:36 pm
RTOSes do these thing also.  A RTOS has more task states to manage and reasons for context switches so the overhead for an RTOS should be higher.  The difference is that great algorithms have been invented in the last thirty years for scheduling.

RTOSes log counts and statistics and the overhead is tiny.  See the reports in the above link for ChibiOS performance statistics.  It isn't done with an oscilloscope.

Quote

last but not least, the library isnt using any interrupt but systematic calls to the Arduino Millis() and this approach is very flexible but consume more cpu than traditional RTOS systick method


In what way is it more flexible or better?

I do believe that a coop scheduler is best for most Arduino users.  It was good enough for the Apollo moon missions.

Here is a description of the Apollo OS.
Quote

There was a simple real-time operating system consisting of the Exec, a batch job-scheduling system that could run up to eight 'jobs' at a time using cooperative multi-tasking (each job had to periodically surrender control back to the Exec which then checked if there was any waiting job with higher priority). There was also an interrupt-driven component called the Waitlist which could schedule multiple timer-driven 'tasks'. The tasks were short threads of execution which could reschedule themselves for re-execution on the Waitlist, or could kick off a longer operation by starting a 'job' with the Exec.

Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 18, 2012, 09:57 pm
hi fat16lib,

it is true that I would have a lot to learn in context switching if the goal for SCoop was to be the best os alternative for the Arduino comunity  :).
Now, I feel that the result we get with SCoop is still better than what we get out of the box from other rtos for the following reason :
SCoop is designed for the users, (based on my personal experience on selling software and hardware solution for industry in the 90's).
it is not design for the features or for topmost performances; as an example there is no concept of priorities !
but then this is sometime better and let me do the demonstration on an example that you could reproduce easily.

just setup 3 tasks doing a single 32 bits count++ in a loop containing a yield. with 1 specific counter per task count1,2 and 3. nothing else.
then in the main loop, just put another count4++ and 20 calls to yield.
then use a basic test against the standard millis() to stop and print something after 10seconds. of execution. this test is not going to impact the overall timing as there are 20 yields above it, right.

just print the sum of the 4 counters. (I used only Arduino Uno for this example)

with scoop, the value is 1 086 746 , so in 10 seconds we were able to increment 32 bit counters more than 1 million time.

with chibiOS_AVR out of the box, I got 460 855
with chibiOS configured in cooperative mode with CHCONF = 0, I got 413 824

so you understand where the problem comes from : the yield function in chibiOS is switching almost imediately to next task. As each task contains a very basic sequences which probably represent 1 us, then the total time spent in the overhead scheduling is very high compared to the task themselves.

in SCoop, the default yield is more complex in this regards as it checks the total amount of time spent in the task (400us for AVR by default) before accepting a switch. result is obviously less time in switching compared to the time allocated to the task.
and then we get 2 time more CPU time for the task, as the total counter reach 1 million.

so, as you pointed, I m sure that cooperative mode is a good way forward for majority of arduino community and then we need to provide them with mechanisms which are optimized for their usage, from a user standpoint.

I d love to see feedbacks from users about our libraries so that we can improve their usability, but in the meantime lets continue guiding them with our both respective approach !
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 19, 2012, 01:05 am
Your example of counting is silly but to continue being silly, here is my example of counting.
Quote

just setup 3 tasks doing a single 32 bits count++ in a loop containing a yield

Why would anyone put a yield in a loop with a preemptive RTOS?  That's what round robin is for.

With proper design ChibiOS does over seven million increments, seven times better than SCoop.

Here is the sketch with five tasks:
Code: [Select]

// Simple counting demo
#include <ChibiOS_AVR.h>

volatile uint32_t n1 = 0;
volatile uint32_t n2 = 0;
volatile uint32_t n3 = 0;
volatile uint32_t n4 = 0;
//------------------------------------------------------------------------------
static WORKING_AREA(waThread1, 16);
static msg_t Thread1(void *arg) {
 while (1) {
   n1++;
 }
 return 0;
}
//------------------------------------------------------------------------------
static WORKING_AREA(waThread2, 16);
static msg_t Thread2(void *arg) {
 while (1) {
   n2++;
 }
 return 0;
}
//------------------------------------------------------------------------------
static WORKING_AREA(waThread3, 16);
static msg_t Thread3(void *arg) {
 while (1) {
   n3++;
 }
 return 0;
}
//------------------------------------------------------------------------------
static WORKING_AREA(waThread4, 16);
static msg_t Thread4(void *arg) {
 while (1) {
   n4++;
 }
 return 0;
}
//------------------------------------------------------------------------------
void setup() {
 Serial.begin(9600);
 // initialize ChibiOS
 chBegin(chSetup);
}
//------------------------------------------------------------------------------
void chSetup() {  
 chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO, Thread1, NULL);
 chThdCreateStatic(waThread2, sizeof(waThread2), NORMALPRIO, Thread2, NULL);
 chThdCreateStatic(waThread3, sizeof(waThread3), NORMALPRIO, Thread3, NULL);
 chThdCreateStatic(waThread4, sizeof(waThread4), NORMALPRIO, Thread4, NULL);
}
//------------------------------------------------------------------------------
// idle loop runs at NORMALPRIO
void loop() {
 uint32_t s1, s2, s3, s4;
 chThdSleepMilliseconds(10000);
 uint32_t t = millis();
 noInterrupts();
 s1 = n1;
 s2 = n2;
 s3 = n3;
 s4 = n4;
 interrupts();
 Serial.print("millis: ");
 Serial.println(t);
 Serial.print(s1+s2+s3+s4);
 Serial.write('=');
 Serial.print(s1);
 Serial.print('+');
 Serial.print(s2);
 Serial.print('+');
 Serial.print(s3);
 Serial.print('+');
 Serial.println(s4);
 while(1);
}

It prints:
Quote

millis: 10055
7180551=1798316+1798959+1798966+1784310

I am sure SCoop will be great for most Arduino users.

Still, I could give you endless examples that are not "topmost performances" where an RTOS is a better solution than SCoop.

RTOSes are now in billions of common products.  Every embedded software tools company provides a RTOS.

Here is Keil's RTX offering http://www.keil.com/rl-arm/rtx_rtosadv.asp (http://www.keil.com/rl-arm/rtx_rtosadv.asp).
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 19, 2012, 10:40 pm
Hi fat16lib, how are you ?


Quote

Why would anyone put a yield in a loop with a preemptive RTOS?  That's what round robin is for.

well, but my topic is just all about cooperative mode ! and also you recently published an example in coop mode, thats why I thought it would be interesting to provide a basic comparison out of the box in coop mode. in such a case you might recognize that yield() is and must be used as much as possible to provide fluent time sharing.

Quote

With proper design ChibiOS does over seven million increments, seven times better than SCoop.

you are right, you reach 7 million counts, in preemptive mode. I cannot do such a test as I do not support this mode.
but if we put a simple chThdYield() in each loop, your exmple falls to 592876 and that was and still is my point:
we have to provide users with a strong framework and couple of exampels, otherwise they will miss-use the os and will get wrong result.

so at this time we could propose a deal: SCoop for cooperative and chibiOS for preemptive !

but if I was a user lloking for a simple and efficient multitasking solution, I would love to see a chibiOS-wrapper, user oriented, that would combine the best of these both worlds !
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 19, 2012, 11:35 pm
Quote
well, but my topic is just all about cooperative mode !


Sorry, I didn't know the rules.

Quote
if we put a simple chThdYield() in each loop, your exmple falls to 592876 and that was and still is my point:
we have to provide users with a strong framework and couple of exampels, otherwise they will miss-use the os and will get wrong result.


But I would never do that, I would use other features of the RTOS to handle high priority requirements.  But that would break your rule that we can only use features of SCoop.

Salting yield calls at various places in code to make embedded applications work is a real pain and makes the code fragile and unreliable.  You get horrible interactions between unrelated tasks.

I wrote my last cooperative scheduler in 1972.  I don't plan to go back there.

I'll stick with technology I helped develop thirty years ago, the predecessor of VxWorks.  VxWorks is the RTOS used in many NASA projects including all JPL Mars Rovers.

Good luck with SCoop.

Edit: here is a going away challenge, implement the ChibiOS_ARM chFastLogger example with SCoop.  This example logs four ADC values at a rate of 1000 Hz.  Note that ChibiOS achieves a time jitter of about one microsecond between samples.  To get low SNR in a signal you need this level of jitter at 1000 Hz.  See any good reference on the theory of ADC signal measurements.

I ran the example with Teensy 3.0.

Here is a bit of typical data the first column is the time in micros():
Quote

micros,data0,data1,data2,data3,over
6178008,290,279,231,262,0
6179008,253,246,217,241,0
6180008,258,244,220,241,0
6181008,260,243,222,239,0
6182008,260,242,222,238,0
6183008,261,242,220,240,0
6184008,262,241,220,239,0
6185008,261,241,220,239,0
6186008,261,240,220,238,0
6187008,262,240,219,240,0
6188008,262,241,220,238,0
6189008,263,241,220,237,0
6190008,263,241,220,239,0
6191008,263,241,220,239,0
6192008,265,241,220,238,0
6193008,266,242,221,239,0
6194008,266,242,222,239,0
6195008,265,243,223,239,0
6196008,266,242,223,238,0
6197008,266,242,223,240,0
6198008,260,233,219,239,0
6199008,271,251,224,239,0
6200008,264,243,220,239,0
6201008,265,241,219,239,0
6202008,266,240,221,239,0
6203008,266,242,221,239,0
6204008,266,241,221,237,0
6205008,265,241,222,238,0
6206008,266,241,222,238,0
6207008,266,242,222,240,0

Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 21, 2012, 10:13 pm
NEW VERSION

I m pleased to release a new SCoop library V1.1 XMass Pack with some updates and goodies.

- updated user guide now 17 pages

SCoop.h :

   yield() routines optimized,
   new object SCoopFifo for easy handling of Fifo buffers,
   some preprocessing parameters to optimize speed
   should compile for Arduino DUE but NOT TESTED ...



Timer Up & down : cosmetic changes, code moved from .h to .cpp

IOFilter : not changed

some new examples including a 1KHZ sampling with fifo, to answer fat16lib post above :) and a new performance measurement sketch...

ok, it is time for a Christmas break and I wish you all a  * * * merry Christmass * * * and an happy new year !
cheers

here : https://code.google.com/p/arduino-scoop-cooperative-scheduler-arm-avr/downloads/list (https://code.google.com/p/arduino-scoop-cooperative-scheduler-arm-avr/downloads/list)
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 22, 2012, 12:39 am
I looked at example4, it satisfied my curiosity.  It was about what I expected.

Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 22, 2012, 10:01 am
:)

also, after a good night, I have slightly update the user guide (now V1.1.1) to correct some typos or bugs in the example code...
please update your file by downloading it from the google code project repository

feel free to provide feedbacks or updates to it, sure there are lot of gramar typo as I m not native english speaker :)
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 22, 2012, 01:59 pm
Guess I should have said more about example4 and SCoop in general.  My request for the data logger was a test to see if you know anything about embedded tools.

Of course you couldn't solve the problem with SCoop and needed to introduce an ISR since coop schedulers just can't do deterministic scheduling of a task.

Scoop is bug ridden as soon as it is used in an environment with interrupts. Take your queue for example.  Store and fetch of pointers is not atomic on AVR so you must not access a pointer from both an ISR and non-interrupt code unless you use proper methods.

Here is an example of the code for a store:
Code: [Select]

ptrIn=post;
18:   f0 93 00 00     sts     0x0000, r31
1c:   e0 93 00 00     sts     0x0000, r30

An interrupt could happen between the store of the two bytes and the interrupt routine would fetch trash.

In addition you need to type many of your variables as volatile or the compiler will kill you as soon as something is shared in an interrupt context.  This is even true in much simpler multitasking environments.

Notice that I typed counts as volatile in many of my examples.  If you remove volatile from the counts in the ChibiOS example above like this:
Code: [Select]

uint32_t n1 = 0;
uint32_t n2 = 0;
uint32_t n3 = 0;
uint32_t n4 = 0;

It will print
Quote

millis: 10055
0=0+0+0+0

instead of
Quote

millis: 10055
7180551=1798316+1798959+1798966+1784310


My advice is to avoid SCoop until it is fixed.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 22, 2012, 03:29 pm
thank you for your inestigation fat16lib;

yep I missed that :)
but we know this type of bug is not the first as there was one like that in Hardware serial for long time :)
anyway, I shouldnt have missed that. sorry for any inconvenience.

lets be clear : using an instance of SCoopFifo in an interupt (isr) might jeopardize the fifo methods.

I have just modified the code so that it is now atomic where needed for the AVR platform.
I will publish a version 1.1.1 in a couple of hours, just the time to do regression tests...
any other feedbacks or input greatly apreciated as it seems you have experienced a lot in this area

stay tuned.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 22, 2012, 05:04 pm
Why do you need an ISR?  Any simple RTOS can read an ADC in a thread at low speeds like one point every tick.

All the systems I have tested do it with low jitter, a few microseconds at the most and about one microsecond on ARM.

My view is that as soon as you need an ISR the advantages of coop schedulers vanish.

I spent my career at several large physics research labs and we gave up coop schedulers forty years ago.  NASA scraped them after Apollo.

I worked for a while at CERN on LHC.  CERN uses LynxOS which I didn't appreciate at first.  It is very Unix/Linux like and allows scientists to do many embedded programming tasks on their own. 

Here is the pitch for LynxOS:
Quote

Because the LynxOS RTOS is designed from the ground up for conformance to open system interfaces, OEMs are able to leverage existing Linux, UNIX and POSIX programming talent for embedded real-time projects. Real-time system development time is saved and programmers are able to be more productive using familiar methodologies as opposed to learning proprietary methods.


I am beginning to think the coop scheduler thing is always a poor choice for ARM Arduino.  Even RTOSes like ChibiOS are are not right for most users.  A real OS that is more like LynxOS may be a better choice.  I guess I will reexamine the options to see what is available if I write AVR off.

To paraphrase a well known quote, you can put object-oriented lipstick on a coop scheduler but it still is a coop scheduler.


Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 22, 2012, 09:51 pm
here we go:

google code updated with SCoop library V1.1.1 XMass Pack, for enhancing the SCoopFifo object with atomic code portion.
this now enables using fifo in ISR like in example 4 of the pack.
thanks to fat16lib for finding the bug.
please download this version if you plan to use fifo in isr.

also include a new example 5 demonstrating a 500hz analog sampling with fifo logging and treatmet by a task without interrupts

time for the week end, I might do some followup as of 25/26th of december due to XMass week end with familly.

// BTW // regarding post above, linux type of OS is probably a nice alternative, especially for raspberry pi or PC on key with android for example. but for Teensy3 and Arduino DUE, the size of the program memory might not be ok, considering the large size of code generated by the ARM compiler... I still beleive that we have nice days ahead of us with Schedulers :)

cheers
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 22, 2012, 10:53 pm
I am not interested in sampling, the problem is that libraries required to log data can not be salted with enough yields() to get low jitter or worse, missed data points.  You don't need a scheduler to sample at 500 Hz, it's trivial.

You must learn something about the theory of SNR for ADC sampling.  Data is worthless if there is substantial jitter in the time between data points.

Your toy examples don't proving anything.  You must do real examples with popular Arduino libraries.  That's why I include a real data logging example.

Quote
but for Teensy3 and Arduino DUE, the size of the program memory might not be ok

I didn't mean running a true Linux/Unix I meant one of the many small kernels that are Linux like.  These kernels run on very small processors.  There are an amazing number of kernels out there.

Quote
I still beleive that we have nice days ahead of us with Schedulers

Your right, there are still lots people writing coop schedulers so you are not the last diehard.  People still write apps in assembler too.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 23, 2012, 11:54 am
hello

thanks for your advice about jitter and snr. myself I m quite aware of these theories and their effect typically in the audio world as I have invested in a Fifo board for my oppo player, just to dejitter the digital signal :) and it makes an incredible difference.
FYI here is the product and I highly recommend it :http://audiopraise.com/vanity93/overview.php (http://audiopraise.com/vanity93/overview.php)
(of course it is worthless if you do not put a DAC with clean clock after it)

that said, the examples are just written to show how to use the macros and objects of the library, I will not pretend giving state of the art coding technics in the whole sampling or digital treatment area. therefore if you suggest to change the prefix names of the examples by the word "toy" , feel free to log an issue in the google code project, but I suggest you flag it low importance as i would not change it before the next release planned early 2013.  8)

I hope we can get the full benefit of our mutual experience and collaboration in the coming post, for the benefit of the community.
merry Christmass to all !
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 23, 2012, 06:50 pm
Yes, digital audio is truly amazing.  In another thread I cited audio ADC performance as an example.  The person I replied to wrote me off.  He said he was interested in "high quality ADCs".  If a 124dB, 384kHz Audio ADC isn't impressive what is.

Here is a jitter test sketch.  It only captures a counter since the test is how precise scheduling is.  It does not use an ISR since many devices/sensors can not be accessed in an ISR using popular Arduino libraries.  The I2C Wire library can't be used in an ISR and I2C devices are very common in the Arduino world.

It records the results to an SD.  I use my SD library but you can use the "Official Arduino SD library" it's an ancient version of my library with a wrapper to, as you say, "make it user friendly".

The only other library I use is ChibiOS.  I did a simple fifo with two semaphores and an array.  The data rate is slow, a point every 10,240 usec, since it is common for Arduino users to record things like accelerometers at about 100 Hz.

I ran the test for a number of minutes and there was no jitter between points.  micros() in AVR ticks every 4 usec so that limits the accuracy of the test.

Here is calculation of what 4 usec of jitter means in this case.  Here is the formula:
Quote

SNR due clock jitter:

SNR(dB) = -20*log(6.28*f*t)

f is the measurement frequency

t is the time jitter in seconds


For t = 4 usec and f about 98 Hz you get about 52 dB.  The SNR for an ideal 10-bit ADC is about 62 dB so even this much jitter degrades the signal.

I don't know a lot about audio but I have read about ADC clocks with jitter well below 100 femtoseconds.  Wow, not nano, not pico, but femto.  I guess you can lease a Galaxy FemtoSecond 77 fsec clock for $233 a month on a six year term.

Here is the sketch for ChibiOS and it is followed by a bit of the file.  I look forward to your sketch for this test so I can run it and produce a file.
Code: [Select]

#include <ChibiOS_AVR.h>
#include <SdFat.h>

// interval between points in units of 1024 usec
const uint16_t intervalTicks = 10;
//------------------------------------------------------------------------------
// SD file definitions
SdFat sd;
SdFile file;
//------------------------------------------------------------------------------
// Fifo definitions

// size of fifo
const size_t FIFO_SIZE = 20;

// count of data records in fifo
SEMAPHORE_DECL(fifoData, 0);

// count of free buffers in fifo
SEMAPHORE_DECL(fifoSpace, FIFO_SIZE);

// data type for fifo item
struct FifoItem_t {
 uint32_t usec;  
 int value;
 int error;
};
// array of data items
FifoItem_t fifoArray[FIFO_SIZE];

// head and tail index for fifo
size_t fifoHead = 0;
size_t fifoTail = 0;
//------------------------------------------------------------------------------
// 64 byte stack beyond task switch and interrupt needs
static WORKING_AREA(waThread1, 64);

static msg_t Thread1(void *arg) {
 int error = 0;
 int count = 0;
 while (1) {
   chThdSleep(intervalTicks);
   // get a buffer
   if (chSemWaitTimeout(&fifoSpace, TIME_IMMEDIATE) != RDY_OK) {
     // fifo full indicate missed point
     error++;
     continue;
   }
   FifoItem_t* p = &fifoArray[fifoHead++];
   if (fifoHead >= FIFO_SIZE) fifoHead = 0;
   p->usec = micros();
   p->value = count++;
   p->error = error;
   error = 0;
   
   // signal new data
   chSemSignal(&fifoData);
 }
 return 0;
}
//------------------------------------------------------------------------------
void setup() {
 Serial.begin(9600);
 Serial.println(F("type any character to begin"));
 while(!Serial.available());
 
 // open file
 if (!sd.begin() || !file.open("DATA.CSV", O_CREAT | O_WRITE | O_TRUNC)) {
   Serial.println(F("SD problem"));
 }
 
 // throw away input
 while (Serial.read() >= 0);
 Serial.println(F("type any character to end"));
 
 // start kernel
 chBegin(chSetup);
 while(1);
}
//------------------------------------------------------------------------------
void chSetup() {
 // start producer thead
 chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO + 2, Thread1, NULL);  
}
//------------------------------------------------------------------------------
// time in micros of last point
uint32_t last = 0;
void loop() {
 // wait for next data point
 chSemWait(&fifoData);
 
 FifoItem_t* p = &fifoArray[fifoTail++];
 if (fifoTail >= FIFO_SIZE) fifoTail = 0;
 
 file.print(p->usec - last);
 last = p->usec;
 file.write(',');
 file.print(p->value);
 file.write(',');
 file.println(p->error);
 
 // release space
 chSemSignal(&fifoSpace);
 
 if (Serial.available()) {
   file.close();
   Serial.println(F("Done"));
   while(1);
 }
}

Here is the file.  The first column is the time between points in micros(), the second is the counter, and the third is the number of missed points due to no fifo space.
Quote

10240,10,0
10240,11,0
10240,12,0
10240,13,0
10240,14,0
10240,15,0
10240,16,0
10240,17,0
10240,18,0
10240,19,0
10240,20,0
10240,21,0
10240,22,0
10240,23,0
10240,24,0
10240,25,0
10240,26,0
10240,27,0
10240,28,0
10240,29,0
10240,30,0
10240,31,0
10240,32,0
10240,33,0
10240,34,0
10240,35,0
10240,36,0
10240,37,0
10240,38,0
10240,39,0
10240,40,0
10240,41,0
10240,42,0
10240,43,0
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: neil12 on Dec 23, 2012, 07:09 pm
Hey good to see the SCoop - I haven't been able to try it out yet - but fantastic to see something published.
I've put a simple multi-loop tasker together myself - based on the TinyOs.net way of doing it. However I haven't had time to be able to test it out or publish.
I look forward to checking out SCoop.
IMHO the value of a co-operative scheduler, is to have a simple move into multi-tasking.
It seems to me the value of pre-emptive schedulers is to be able to do system level heavy lifting - especially for buffered IO process tcp/ip interrupts, and to be able to meet other hard deadlines.  The cost of the pre-emptive scheduler, IMHO, is high in terms of system complexity and maintaining stability.
In a previous life with a 100 realtime software engineers, the Software VP owned the pre-emptive schedulers priorities to stop just anyone optomizing it for their functional systems.  In fact most of the processes ran at the same priority, and just the few processes that were managing the hardware redundancy and I/O had higher priorities.

My experience in software has been to simplify the design and use as simple as possible primitives to implement it. For this type of design event based designing is extremely valuable .  That is encouraging a discussion of what events are coming into the board and what are the outputs.  So having the ability to collect user input in a buffer via an interrupt and then process/schedule a task::loop to parse the input on a terminating  <CR> or '?' is very simple. Very simple primitives - user input collection - and the ability to schedule a task::loop. Also supports the architecture for low power processing.
Wishing everyone a nice seasonal holiday - Cheers Neil
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 23, 2012, 10:29 pm
neil12,

I agree with most of your observations.  Without training or close supervision of programmers, embedded systems with preemptive RTOSes get way too complex.  This is a problem with design, not the OS.

Typically 95% of an embedded system's code and execution time could run on a PC, Mac, or Linux. With that in mind  lets look at these two statements.
Quote

IMHO the value of a co-operative scheduler, is to have a simple move into multi-tasking.

Quote

The cost of the pre-emptive scheduler, IMHO, is high in terms of system complexity and maintaining stability.

Microsoft's Windows designers believed this and tried to stick with coop scheduling.  Microsoft finally introduced a minimal preemptive scheduler in Win95.  Now Mac, Linux, and Windows have preemptive schedulers for simplicity and reliability.

So I think most tasks in a mufti-threaded Arduino environment should run in coop mode or round-robin at the same priority.  I prefer round-robin because I think it's simplest since you don't need to yield.

For decades standard practice in groups I worked in was to use round-robin with a quantum that was often AC line frequency, 20 ms is still common.

Here is another interesting statement:
Quote


In a previous life with a 100 realtime software engineers, the Software VP owned the pre-emptive schedulers priorities to stop just anyone optomizing it for their functional systems.  In fact most of the processes ran at the same priority, and just the few processes that were managing the hardware redundancy and I/O had higher priorities.

Good plan.  There should be only a few task that don't run at normal priority and it is really unusual to need more than two levels above normal priority.

So why do you need a preemptive OS?  One reason is to be able to provide deterministic scheduling for a few key events, that's what distinguishes real-time systems.  

Another is to make an integrated device driver environment, so signaling between interrupt and non-interrupt routines can be abstracted in a HAL, hardware abstraction layer, with high performance drivers.  Modern chips like Cortex M are designed to get their best performance with a preemptive RTOS.

I believe a RTOS is necessary for new generation chips but the application programming environment should be as simple as possible.  

Of course embedded systems require semaphores, mutexes, messaging, queues, memory pools, and other stuff so processes can safely and efficiently cooperate.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: perkunas on Dec 23, 2012, 11:09 pm
Wow this looks promising,
Multitasking is why I left arduino, for other platforms that had integrated stable multitasking.
As you know C does not provide for multitasking, so you need to have things like Free RTOS which has compatibly issues with arduino, so thus the DuinOS was born. These are not solutions or even a good patch in my opinion, DuinOS is in Alfa and has little support. Free RTOS is like learning a new programing language, confusing and provides no real support for the 1st time user.This whole Idea of get this alfa, and download patch this and that, and maybe it will work, if you can figure it out, and doesn't crash on you is stupid. Occam-pi is another way to get multitasking out of your arduino but it's a totally new programing language with little support. In many ways I think Occam is far better programing environment then C or even RTOS at least when you learn to use it, its easy to move on to the multitasking. I sure hope you guys can work this out, but its never going to work if its not simple and fully integrated, something that I don't see happening soon.

Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 24, 2012, 12:38 am
Quote

I sure hope you guys can work this out, but its never going to work if its not simple and fully integrated, something that I don't see happening soon.

You are right but the Arduino company will decide what gets integrated, not users.  I expect Arduino to do something extremely simple.  Arduino users are mostly hobbyists looking for instant gratification so learning how to properly use an RTOS won't be appealing to most users.  Even a system like SCoop has too many features and is too complex.

FreeRTOS is the most popular open source RTOS with about 100,000 downloads per year.  It is a pretty typical RTOS in terms of features.  Billions of common electronic products now use systems like FreeRTOS.  Many of these products use commercial RTOSes.

Clearly a typical RTOS is not for you. 

There are lots of little open source efforts like SCoop and languages like Occam-pi.  Few of these efforts seem to be successful in the long term.

No magic tool or language will make you a good embedded system designer/programmer.  It's a lot more than a language, that's why good real-time systems engineers are highly paid and sought after.  It's a profession that takes talent, training/study, and experience.  That's why I think adding just a very few features for the simplest possible multitasking is what the Arduino company will do.  That way users won't be overwhelmed and will be have new capibilities.

FreeRTOS does run on Arduino without patches and performs well.  Support for FreeRTOS is not free and the few people that use it on Arduino don't seem to be very active in forums.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: leo72 on Dec 24, 2012, 07:45 am

I expect Arduino to do something extremely simple.  Arduino users are mostly hobbyists looking for instant gratification so learning how to properly use an RTOS won't be appealing to most users.  Even a system like SCoop has too many features and is too complex.

That's the reason why I wrote leOS, a very simple scheduler that do little jobs in background, using an interrupt-driver mechanism.
No preemptive, no cooperative... a "task" (or job, a better therm), waits until its time is reached and then the scheduler calls it. The job then runs until it has done its work and then it leaves the control back to the ISR, that terminates its work and returns the control at the main loop. A supervisor system checks if a task freezes, in such case it resets the microcontroller (useful in case your circuit runs in a place not easily accessible).

No complicated setups for the user, no complicated methods to add/modify/pause/delete jobs.
No separated editors/IDEs to use, just a simple library to include and use.


PS:
I would say a couple of words.
I followed this thread and the other ones where you, fat16lib, partecipated talking about RTOSs and I appreciated your ideas and your knowledge.
Thanks for every work you spent trying to explain us the oceans about RTOSs  :smiley-sweat:
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fat16lib on Dec 24, 2012, 05:45 pm
leo72,

I am sure efforts like leOS will work for some problems.  Maybe you have even found a Silver Bullet in the Holy Grail.

Quote

No preemptive, no cooperative... a "task" (or job, a better therm), waits until its time is reached and then the scheduler calls it. The job then runs until it has done its work and then it leaves the control back to the ISR, that terminates its work and returns the control at the main loop. A supervisor system checks if a task freezes, in such case it resets the microcontroller (useful in case your circuit runs in a place not easily accessible).


This approach is not general enough for many embedded multitasking situations.  RTOSes aren't complex unnecessarily.  Embedded systems deal with devices in ways that users of a PC, Mac, or Linux never see.

Of course simple apps don't need multitasking.  Arduino is doing fine for lots of things.  Adding multitasking to Arduino in a way that is reliable, simple, and easy for users to understand and apply will be tricky. 

Here are features that you might look for when evaluating an RTOS.  If you don't understand why an RTOS would have these things, you are not ready to write an RTOS replacement.

Quote

Abstract streams and channels
Binary semaphores
Condition variables
Core memory manager
Counting semaphores
Event flags
Hardware Abstraction Layer (HAL)
Heap allocator
I/O queues
Interrupts nesting
ISRs abstraction
Kernel base threading services
Mailboxes (message queues)
Memory pools allocator
Mutexes (priority inheritance)
Preemption
Priority based scheduling
Round robin scheduling
Static kernel
Synchronous messages
Threads registry
Timeout on wait primitives
Virtual timers
Zero latency interrupts


The question for Arduino is how much of this is needed internally to support sharing of resources and devices for multitasking and how much is presented to users in new APIs.

Every time I think about the current Arduino environment I find problems.  A coop scheduler doesn't avoid sharing problems.  If you put a yield inside existing libraries, two libraries like Enet and SD may access a shared resource like an SPI bus.  Two threads could be writing to a files and trash the SD cache.

If you add preemption or run code for String in an ISR you will trash the heap.  String uses malloc/free and these are not thread safe.

The exercise of porting ChibiOS and FreeRTOS to Arduino has opened my eyes to how primitive the current state is.  Arduino is like an old DOS system or the original MAC OS.  OS X is far away. 
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: leo72 on Dec 28, 2012, 11:57 am
fat16lib,
I undestands the problematics that relies in a RTOS and I don't want to raise me up to those coding levels  :smiley-sweat:

I think that an RTOS is more complex than I know but think that a "real" RTOS on a little MCU like the Atmega328 can be too complex for the normal usage too. Things like Scoop or avr-os reserve 256 byte of SRAM for each task... in a product that contains only 2048 byte of RAM. Too expensive in therms of resource consumption.

I am very very interested in such projects (Scoop, avr-os, RTuinOS, FemtoOS) but IMHO I consider them too complex for newbie users (like me...  :smiley-sweat:).

Thanks for your reply  ;)
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Jan 10, 2013, 11:28 pm
SCoop V1.2 is out and brings lot of goodies :)

SCoop V1 brougth the idea of easy cooperative scheduler by extensively using OOP and by providing a (hopefully) comprehensive user guide.
Several objects class like SCoopTask SCoopTimer SCoopEvent and SCoopFifo brings good support for serious but simple multitasking. With the 3 other complementary libraries (IOFilter, TimerUp&Down) this brings a set of features that makes Arduino experience even simpler

V1.2 is very much faster and brings performance close to what we get with very basic scheduler like the "Android" one provided with arduino 1.51 for Arduino DUE, but with much more features!

the yield() routine has been optimized and is now providing a mechanism to switch to next task without coming back to the main scheduler routine which saves lot of CPU time. the result is 15us total switching time on AVR and an amazing 3.2uS on Teensy 3.0 !
lets be fair, the Android version (included in SCoop pack) is still 40% faster but it does nothing else than swiching :)

The concept of delaying yield() by several micros seconds called "quantum time" is still in place and makes a huge difference with traditional cooperative scheduler as this brings the benefit of some CPU resource allocations to tasks, and some predictability in the cycle length, like we have with preemptive RTOS. The micros() routine have been optimized for Arduino UNO (by reusing some tips from the Teensy core) and  this brings a very good 2.5us lead time to call yield() (AVR) and to check if it is time to switch or not to the nex task, so only <20% of a standard yield() which enable calling yield() everytime everywhere then.

New methods have been introduced to pause/resume timer, events or task, and to monitor their "state"

A new SCoopDelay object is introduced to rationalize timeout handling inside the library and it can be used in the main sketch (sort of simpler TimerDown)

last but not least, the SCoop pack is now provided with a copy of the standard Android Scheduler, ported for the AVR, and then compatible with both ARM or AVR platform and arduino < 1.5 (tested on 1.0.3) !
Then you have the choice : test and adopt the SCoop suite or quickly include the android scheduler.h and play multitask imediately also on AVR.

for mor details on the changes, please review the change log file as few but some important changes are NOT backward compatible with V1.1.1 including the basic defineTimer macro ...

every thing on GooGle code here:
https://code.google.com/p/arduino-scoop-cooperative-scheduler-arm-avr/

thanks for supporting us and providing your input or feedbacks

edit : change log in attachement
edit: all source code now on github : https://github.com/fabriceo/SCoop/tree/v1.2 (https://github.com/fabriceo/SCoop/tree/v1.2)
Title: Re: SCoop - Subroutines in Scoop Tasks
Post by: omegaman477 on Feb 15, 2013, 01:07 pm
I am sure this is a stupid question..

I have SCoop operating well, EtherMega, no issues, clean and simple install.

However, whenever I introduce a call to a subroutine from any myTask::loop (say to call a common logging routine) the code reboots.  This is not the case when subs are called from myTask::setup or from Timers.

Am I doing something wrong ;-p

rich..
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Feb 15, 2013, 09:21 pm
Hello omegaman477
I d bet on a problem with a stack colision.

could you please try extending the size of the stack allocated to the task, say 512 and then trying again.
once it runs ok, you can reduce the size of the stack by monitoring it with the stackLeft() method.

if this doesnt work, then this might be link to the "3BYTESPC" but I would need a copy of .elf file to troubleshoot it

let me know and dont hesitate to attach or post your code, or PM if preffered
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: omegaman477 on Feb 18, 2013, 01:29 am

Hello omegaman477
I d bet on a problem with a stack colision.

could you please try extending the size of the stack allocated to the task, say 512 and then trying again.
once it runs ok, you can reduce the size of the stack by monitoring it with the stackLeft() method.

if this doesnt work, then this might be link to the "3BYTESPC" but I would need a copy of .elf file to troubleshoot it

let me know and dont hesitate to attach or post your code, or PM if preffered


Increasing stack size had no effect.  Where are the ELF files located, I will IM them and the Source to you.

Thanks.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fpoto on Oct 20, 2013, 10:57 am
Version 1.2, manual corrections and volatile

I see that a new version 1.2 has been posted on <https://code.google.com/p/arduino-scoop-cooperative-scheduler-arm-avr/>, thanks for that. I am just starting a new project and I think Scoop is the right tool for me and am going to try it.

I would like to propose some corrections to the manual, but I do not seem to find the source of it, which would make the job much easier: can I access it anywhere? In any case, where should I send proposal for changes?

By the way, one of the things I notice in the manual is the use of volatile in the very first example, the one on the first page. As far as I can tell, volatile is useless here, because the compiler will never optimise out accesses to this variable. That would happen if we had an infinite while loop instead of the loop entry point and if the scheduler were preemptive, but none of these two conditions are true here.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Oct 20, 2013, 07:08 pm
Hello!

I m sure you will get success in using SCOOP, plese let us know!

for the document, just give me your email adress by private message and I ll send you the original .doc file.

for the volatile count ... you are probably right in this example. But in general, when the variabe is used accross tasks, my experience is that you avoid loosing time in trouble shooting by putting them volatile , even in coopreative mode  :P

hope you succeed in your project
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fpoto on Oct 20, 2013, 07:17 pm
I sent you my mail address with a private message.

As far as volatile is concerned, you may be right that there are cases where this is necessary even with cooperative scheduling (even if I do not see on off the top of my head), but stating in the first example that this is necessary is confusing and adds unnecessary complexity and black magic.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: wongss on Nov 07, 2013, 05:05 pm
Thanks for the excellent simple kernel which does not have many issues that come with preemptive ones when using standard Arduino libraries.

Now I don't have to use superloop to call state machines to handle different events. State machines are often hard to write and difficult to understand. Each task can now almost can behave as if it is an independent program, similar to rtos.
Hope to introduce to my project students.

As for the volatile, I suppose it is often better to be safe.

Thank you.
Title: Helper functions for reporting the unused stack sizes in SchedulerARMAVR
Post by: fpoto on Dec 03, 2013, 12:33 am
Thanks for your nice and very useful scheduler libraries.

After having worked with SCoop, I discovered that I was using no one of the many goodies provided, apart from stack printing. So I tried the SchedulerARMAVR and I discovered that it saves over 1500 bytes of program memory and 58 bytes of data memory with respect to SCoop, both of which are important to my project. Having to use dynamic allocation for the stack is a non-issue for me, as I allocate it during setup() and never free it.

The only thing  I was missing is the printing of the size of the stack left free for the tasks. So I got down and wrote my own functions, which appear to work for me.

It is possible to make them slightly more compact by incorporating them into SchedulerARMAVR.cpp, I can provide a patch if you wish. I think they would be a useful addition to SchedulerARMAVR.  Here they are:

Code: [Select]

// Use this rather than Scheduler.StarLoop() and save the pointer returned
// so that you can  pass it to stackUnused().
// This function relies on malloc to just give back the same pointer after free(),
// and on Scheduler.StarLoop() to do the first malloc() call to allocate the stack.
// If the SChedulerARMVR code is changed so that the above is not true, memory corruption will result.
byte *startLoop (SchedulerTask task, unsigned stackSize) {
  byte *stack = (byte *)malloc(stackSize); // the same allocation Scheduler.StarLoop will do
  // If we are being called from the main loop, let's fill our stack, too
  extern byte *__brkval;    // set after malloc, it is the top of the heap
  if ((byte *)&stack > __brkval)    // this function called from the main loop
    for (byte *end = (byte *)&end - 10;    // leave space for a small interrupt routine
__brkval < end;    // until end pointer smashes into the heap
*end-- = 0x55) ;    // fill stack with fixed value
  memset(stack, 0x55, stackSize);    // fill the stack's stack with fixed values
  free(stack);    // now we free the space allocate with malloc
  Scheduler.startLoop(task, stackSize);    // start the task
  memset(stack, 0x55, 4);    // rewrite over memory dirtied by free()
  return stack;    // stack base, to be passed to stackUnused()
}

// When not using the scheduler, call it from setup()
// Else, this work is done when calling startLoop(), so this function should not be used
void fillStack () {
  extern byte __heap_start, *__brkval;
  byte *beg = (byte*)(__brkval ? __brkval : &__heap_start);
  byte *end = (byte*)&end - 10; // leave space for a small interrupt routine
  while (beg < end) *beg++ = 0x55; // can't use memset here: it would use the stack
}

// Count bytes marked 0x55 from the stack base to the the local variables
// Should be called with either no arguments, for counting free stack on the main loop,
// or with two arguments, for the tasks.
unsigned stackUnused (byte *stackBase, unsigned stackSize) {
  byte *end = stackSize ? stackBase + stackSize : (byte *)&end - 10;
  byte *p = stackBase;
  while (*p == 0x55 && p < end)
    p += 1;
  return p - stackBase;
}


In order to use the code, you should use startLoop(task, stackSize) rather Scheduler.startLoop(task, stackSize), and save the return value, that is, the base of the stack of the task just created. Also, save the value of the stack size in a variable.

Then, you can call stackUnused() either from the main loop without arguments, or from wherever you want with two arguments: a task's stack base pointer and the task stack size. It returns the number of bytes on the stack that have been left unused for the main loop or for that task, respectively.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: jimford on Dec 04, 2013, 08:33 pm
I've been looking for a simple task manager/scheduler for my project, and came across SCoop.

I did as I usually do first off with 'strange' libraries and tried to run the examples to get a 'feel' for SCoop.

I found that none of the examples would compile with the Arduino 1.5.4 IDE - they all gave multiple errors that appeared to be library related,  but I didn't look any deeper.

Is there an 'issue' with SCoop and the Arduino IDE?

Jim
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: jimford on Dec 12, 2013, 11:32 pm
OK no response so far, so some details:

EXAMPLE 1
VERSION 1.2 NEW YEAR PACK 10/1/2013

Gives the following compilation errors:

Arduino: 1.5.4 (Linux), Board: "Arduino Duemilanove or Diecimila, ATmega328"

example1:7: error: expected constructor, destructor, or type conversion before '(' token
example1:10: error: expected constructor, destructor, or type conversion before '(' token
example1:13: error: 'myTask2' has not been declared
example1.ino: In function 'void loop()':
example1:14: error: 'sleepSync' was not declared in this scope
example1.ino: At global scope:
example1:17: error: expected constructor, destructor, or type conversion before '(' token

 This report would have more information with
 "Show verbose output during compilation"
 enabled in File > Preferences.

All the the  other examples give similar errors, plus a whole load more!

Ideas, anyone - please?

(Come on 'fabriceo' SCoop's - your pet. You should be able to provide some input here!    ;^)  )

Jim
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fpoto on Dec 16, 2013, 06:27 pm
I have not tried, but it looks like <SCoop.h> is in fact not included.
As the message says, try to enable verbose output to get more information.
Make sure you have SCoop installed int he right place and enabled in the IDE.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: jimford on Dec 16, 2013, 08:12 pm

I have not tried, but it looks like <SCoop.h> is in fact not included.
As the message says, try to enable verbose output to get more information.


The above message is verbose.

Quote
Make sure you have SCoop installed int he right place and enabled in the IDE.


It all appears to be installed in the correct place and appears in the IDE OK.

The only example I've managed to get to comple is the SCoopME template.ino. In fact I'm starting to use SCoopMe in my project and it shows some promise. I've abandoned SCoop! The 'basic sketch' on page 1 of the 'Scoop User Guide V1.2' doesn't compile for me either.

Do you know what the difference is between SCoop and SCoopME ? 'fabriceo' offers no clues and appears to have  gone silent on this thread!

Thanks for the  reply.

Jim
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fpoto on Dec 17, 2013, 12:47 am
I had a look at the SCoopME sources, but without diving into it: it looks like a cleaned up version of SCoop, better written and probably smaller. I suggest you use that instead of SCoop, at least until fabriceo comes up and explains what are the differences.

In fact, I had tried SCoop and then witched to SchedulerARMAVR, which is much simpler, and which I am using right now, because I do not need all the goodies provided by SCoop, it is much smaller and has the same interface as the standard Arduino Scheduler library. The only thing is that I needed to measure the stack occupancy of tasks and I had to write those functions by myself (I posted them above).
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: jimford on Dec 17, 2013, 08:15 pm

In fact, I had tried SCoop and then witched to SchedulerARMAVR, which is much simpler, and which I am using right now, because I do not need all the goodies provided by SCoop, it is much smaller and has the same interface as the standard Arduino Scheduler library.


Interesting - I'll have a look at the SchedulerARMAVR library. Like you, my project uses very little of the facilities that SCoop/SCoopME offer and SchedulerARMAVR may suit.

There's precious little documentation for SchedulerARMAVR and there appears to only the Scheduler.startloop and yield() functions. Do you happen to know of anything else that will enable me to get a 'handle' on it, please?

I notice in the 'Multiple Blinks' example:

Code: [Select]
// IMPORTANT:
 // When multiple tasks are running 'delay' passes control to
 // other tasks while waiting and guarantees they get executed.
 Scheduler.delay(1000);


I'm a bit confused as I thought it was yield() that passes control to the other tasks!

Jim
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fpoto on Dec 17, 2013, 09:03 pm
First look at the Scheduler library (http://arduino.cc/en/Reference/Scheduler) page, then at the page (http://forum.arduino.cc/index.php/topic,142101.0.html) where Fabrice Oudert announces SchedulerARMAVR, you'll find many indications.

Anyway, if you use the 1.5.x library, the delay() function calls yield(). If you use the 1.0.x library, the delay() function does not call yield(), so you should use Scheduler.delay() rather than delay() to obtain the same effect.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 28, 2013, 03:33 pm
Hello;

I m so sorry that I didnt pay attention to this thread in the past weeks... I was spending time on another fancy project more around electronic and DSP, but ok :)

for some of you having tried Scoop V1.2, for one year ago I havent tried it myself on the early release of Arduino and I ll try to do so in the comming days. I ve just received also a pair of teensy 3.1 and a pair of sparkcore and will check that the lib is working with arduino 1.05 and teense 1.18 and may be on spark later

it is fair to use the SchedulerARMAVR instead of SCoop as it is smaller. I ve just put the Assembly code in it to make it compatible with AVR, credit goes to others and the android team;

still Scoop can offer a bit more features, especially the ring token handling and some time allocation to task, which at some point in your devlopement might be needed to optimize the CPU time given to a task

SCoopeME is a concept which is a rework of SCoop 1.2 but using object templates instead of macros.
also it is ported for TexasIntrusment MSP430 (at least I got it to work)
I ve missed time to finish it as I wanted, and to write proper documentation, but it s not bad and can be considered if you are an early adopter :)

I still strongly beleive in cooperative scheduler concept and whish all the best to the 230+ people having downloaded it and the other to come

cheers and Happy new 2014
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: jimford on Dec 28, 2013, 07:57 pm
I'm relieved to see that you haven't abandoned SCoop, Fabrice!

Firstly, thank you for SCoopME - it's transformed my project and integrates nicely with the phi_prompt menu library I'm using.

As I mentioned in an earlier post, I couldn't get the SCoop examples to compile on Arduino 1.5.4, and switched to SCoopME, which works well.

One feature I ideally need is for the SCoopTimer to handle a time period of 1 Hour, so it needs a milliseconds input of a long unsigned int, rather than int as it is now.  Any ideas how I can work round this problem, please?

Jim 
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 29, 2013, 12:49 pm
Hello

that the beauty of modern programing with templates,
in fact when you declare a SCoopTimer you can specify as a third paramter another object in charge of counting the time.
by default the object used is "SCtimerMs"
and this is visible in the source code line 240. here is the extract
Code: [Select]

// class for creating "timers"
template< class CHILD,
          unsigned TIME,
  class SCTIME = SCtimerMs >

struct SCoopTimer : SCoop< SCoopTimer< CHILD, TIME, SCTIME > > {

  static SCTIME timer;
  static SCTIME thresold;


if you create you own object called SCtimerSec then you can pass it when declaring your timer, as a third parameter, like this

Code: [Select]
struct myTimer1 : SCoopTimer< myTimer1, 100, SCtimerSec > { // every 100 second
static void run() {
  // user code go here.
} } myTimer1;


and for creating you own SCtimerSec, just copy paste and rework the SCtimerMs :)

I have tested some month ago and rember it worked. Hope you ll get successfull :)
this template stuff is really amaizing

or you could alsways enter in the timer.run() every second and manage to continue only after 3600 ticks :) thats the old fashion way but without risk!


Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: jimford on Dec 29, 2013, 01:36 pm
Thanks for the quick reply Fabrice.

I'm going to have to digest your suggestions - I have enough problems with 'regular' programming, let alone 'modern'!

Many thanks again for the support - have a good New Year!

Jim
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: kert on Dec 29, 2013, 07:50 pm
Is there a page somewhere with the list of cooperative schedulers available for arduino ?  I've seen scoop, schedulerarmavr , leOS2 AVRQueue mentioned here etc.

Ideally is there a  simple combination of a roundrobin function scheduler that can be driven from both the superloop and a timer plus a basic task state machine ? It'd be really nice to have a desktop c++ code path for basic testing. ( and i mean explicitly a run-to-completion coop scheduler, not something that needs yield() )
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Dec 31, 2013, 11:00 am
Hello Kert!

well indeed the magic solution is not yet known :)
the problem is tradeoff. I mean, if you go with something like FreeRTOS or ChibiOS, you ll get this kind of features all together in a modular form trough a config file, e.g. I remeber that ChibiOS has a cooperative mode.

also there is some sort of incompatibility between RTOS and coop scheduler : RTOS slice the CPU time on regular basis and change the task context and if you want to care about side effect you have to deal with semaphore and make sure the library is ready for re-entrance or atomic code for example.

for coop scheduler, it is more up to the user to decide the context switch, by calling the yield(), therefore accomodating this constrains inside the core program.
sometime the yield() is hidden in a waiting or pooling function like Serial.read() or keypressed() or delay() and this looks easier, but not different in fact. e.g. usleep() in some linux distro.

as soon as you want a task to be launched periodically, like timer based, you have a decision to make if the code of this task takes long CPU time or not. if not, then it looks more like an interrupt and this is the model of ieos2 if I remeber well
If it takes long time, then you need to pass the token to another task after some time and then comes the need for a specific stack for this task; and then this use cas can be handled with a coop scheduler, you only have the concern of the jitter when re-entering in the task.

So I feel you can do a lot with simple schedulers like SchedulerARMAVR or SCoop and then if someone needs more, just invest in learning RTOS, and accept that the Arduino library are probably not usable as-is.

I would be pleased to record in this thread any suggeston for improving SCoop, as long as we respect the inherent border between RTOS and coop scheduler.

for example, one limitation of SCoop is the fact that any interrupts will use the current stack context, therefore we need to size the stack of each task to include the total interrupt stack size. we could imagine a specific context switch to force using the stack of the main loop().

another example is sleep mode. If you have say 3 task in paralell all containing a sort of loop with a delay() then you can for sure put the CPU in sleep mode for a certain duration representing the least or remaining delay of the pending tasks.
I ve tried this successfully on a MSP430 but the code is too big and not clean enough to be published at the moment.

lets engage the discussion!
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: jimford on Dec 31, 2013, 06:24 pm

Hello

that the beauty of modern programing with templates,
in fact when you declare a SCoopTimer you can specify as a third paramter another object in charge of counting the time.
by default the object used is "SCtimerMs"
and this is visible in the source code line 240. here is the extract
Code: [Select]

// class for creating "timers"
template< class CHILD,
          unsigned TIME,
  class SCTIME = SCtimerMs >

struct SCoopTimer : SCoop< SCoopTimer< CHILD, TIME, SCTIME > > {

  static SCTIME timer;
  static SCTIME thresold;


if you create you own object called SCtimerSec then you can pass it when declaring your timer, as a third parameter, like this

Code: [Select]
struct myTimer1 : SCoopTimer< myTimer1, 100, SCtimerSec > { // every 100 second
static void run() {
  // user code go here.
} } myTimer1;


and for creating you own SCtimerSec, just copy paste and rework the SCtimerMs :)

I have tested some month ago and rember it worked. Hope you ll get successfull :)
this template stuff is really amaizing

or you could alsways enter in the timer.run() every second and manage to continue only after 3600 ticks :) thats the old fashion way but without risk!





I've had a look at your library Fabrice, and:

You see that tiny speck of silver, high up in the sky? It's a jet aircraft cruising at 40, 000 feet. That's how far over my head your coding is!

;^)

I hoped that by changing the lines as suggested early in the SCoopME.h file:

Code: [Select]
typedef uint32_t SCmillis_t;  // define the size for any timers in milliseconds. can be changed to uint32_t

That I would get a long int for the Timer - but it had no effect.

I've worked round my problem by using a ordinary Task with:

Code: [Select]

struct read_pressure : SCoopTask< read_pressure > {

  static void setup() {}
  static void loop() {

    volatile static uint32_t last_reading = 0;

    if (millis() - last_reading > ONE_HOUR) {
...
// Do barometer pressure reading at 1 Hr intervals
...     
    last_reading = millis();
  }
  }
} read_pressure; // End of Task read_pressure.
[code]

It works OK, but is a bit of a 'kludge' and would be nicer if I could use a 32 bit Timer..

Jim
[/code]
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: kert on Jan 10, 2014, 02:21 am

for coop scheduler, it is more up to the user to decide the context switch, by calling the yield(), therefore accomodating this constrains inside the core program.

So i'm using coop scheduling that does not involve yield, every scheduled function simply runs to completion.
I have found this to be the cleanest simplest design for a lot of things i need to write.

I also normally leave in asserts that first
- make sure that ISRs don't take more cycles than some arbitrary small amount and hence don't mess with scheduling too much
- the scheduler times function execution and asserts/alerts if something is falling behind too much or misses it's scheduling window more than x%
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: alibaba9292 on Feb 28, 2014, 03:23 am
Hello guys!
I think this question has been asked in this thread but I am getting the same error when I try to compile the example code in @fabriceo 's guide! the library is amazing from what I gather and I would really like to us it in my project. Any suggestions of why this might not be working. @jimFord you had the same issue with SCoop.h how did you get around it??

Many thanks for your replies and responses
Regards
Ali
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fpoto on Feb 28, 2014, 11:04 am
If you want help with your code you should provide details.

Anyway, even before doing that, be sure to read the previous posts in this thread: I suspect you'll find a solution.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: alibaba9292 on Feb 28, 2014, 02:45 pm
Hi!
thanks for the quick reply :)
I didnt install the library quickly so I managed to solve that problem!
You were right the solution was in the previous posts!
Many thanks
Regards :D
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: jimford on Feb 28, 2014, 02:59 pm
So were you using Scoop or ScoopME 'alibaba9292'?

As I mentioned in an earlier post, I couldn't get the Scoop examples to compile, so I abandoned it and settled for using ScoopME on my project. With the exception of the timer limitation, it works well.

Jim
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: alibaba9292 on Mar 01, 2014, 11:17 pm
Hi Jimford

I did get the examples that you see in the Ardiuno IDE after installing the library to compile but I cant get some examples in the reference guide to compile but that may be because there are many syntax errors. Which examples are you talking about.
If you are taking about the examples included in the library when you download SCoop (examples 1-5 etc) then you also need to download the Timerup timerdown IOfilter libraries in addition to SCoop for them to compile.
Could you possibly show me where you downloaded the complete SCoopMe library. I cant find it.
Would you please give me a link from where you got the SCoopMe file from?

Thanks Regards
Ali
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: jimford on Mar 01, 2014, 11:30 pm

Could you possibly show me where you downloaded the complete SCoopMe library. I cant find it.
Would you please give me a link from where you got the SCoopMe file from?


Fabrice posted the link for SCoop and SCooMe in his initial post, but here it is anyway:

https://code.google.com/p/arduino-scoop-cooperative-scheduler-arm-avr/downloads/list

Jim

Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: alibaba9292 on Mar 02, 2014, 05:50 am
thanks :) appreciate it!
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: alibaba9292 on Mar 18, 2014, 08:26 pm
Hello again guys!

I have a question regarding using the scheduler library that you can download with the SCoop library. I have tried using shceduler library designed to be used with the ardiuno uno to implement multiple tasking but have been on partially successful. My program has to display a value input by the user using serial monitor and also read a value from an external sensor(loadcell) and display that as well. both these task work well independently of one another but when I combine and try them using scheduler I am only able to light both the seven segment displays. One shows 000(the one thats supposed to show sensor readings) and the other has its digits flickering. I am using 2, 3 digit seven segment displays and using 74hc595 shift registers to drive them. Also like I said the codes for doing each of these tasks works well independently how ever combining them causes problems. I think its the while(1) statement on line 171
I would really appreciate any help that you could give me. Also do you think I'd be better off using the SCoop to do this. If so could you give me some pointers on doing that because I am really confused how to do it.
I have attached the code with this as well.

Code: [Select]
#include <SchedulerARMAVR.h>


//variables for actual_value
const int digitPins1[3] = {
 4,5,6};                     //4 common anode pins of the actual_value
const int clockPin1 = 11;    //74HC595 Pin 11
const int latchPin1 = 12;    //74HC595 Pin 12
const int dataPin1 = 13;     //74HC595 Pin 14
const byte digit1[10] =      //actual seven segment digits in bits
{
 B00111111, //0
 B00000110, //1
 B01011011, //2
 B01001111, //3
 B01100110, //4
 B01101101, //5
 B01111101, //6
 B00000111, //7
 B01111111, //8
 B01101111  //9
};

int digitBuffer1[3] = {
 0};
int digitScan1 = 0;
float pressurekg = 0;

//variables for desired_value

const int digitPins2[3] = {
 A4,A3,A2};                 //4 common anode pins of the desired_display
const int clockPin2 = 7;    //74HC595-2 Pin 11
const int latchPin2 = 8;    //74HC595-2 Pin 12
const int dataPin2 = 10;     //74HC595-2 Pin 14
const byte digit2[10] =      //desired seven segment digits in bits
{
 B00111111, //0
 B00000110, //1
 B01011011, //2
 B01001111, //3
 B01100110, //4
 B01101101, //5
 B01111101, //6
 B00000111, //7
 B01111111, //8
 B01101111  //9
};
int digitBuffer2[3] = {
 0};
int digitScan2 = 0;
unsigned int desiredValue = 0; //desiredValue input from the computer using serial coomunication
char incomingByte;

//variable for averaging
const int numReadings = 10;
int readings[numReadings];      // the readings from the difference of analog inputs
int index = 0;                  // the index of the current reading
int total = 0;                  // the running total
int average = 0;                // the average


void setup(){                
 //setup for actual_display
 for(int i=0;i<3;i++)
 {
   pinMode(digitPins1[i],OUTPUT);
 }
 pinMode(latchPin1, OUTPUT);
 pinMode(clockPin1, OUTPUT);
 pinMode(dataPin1, OUTPUT);

 //setup for desired_display
 for(int i=0;i<3;i++)
 {
   pinMode(digitPins2[i],OUTPUT);
 }
 pinMode(latchPin2, OUTPUT);
 pinMode(clockPin2, OUTPUT);
 pinMode(dataPin2, OUTPUT);

 //setup for averaging process
 for (int thisReading = 0; thisReading < numReadings; thisReading++)
   readings[thisReading] = 0;

 Scheduler.startLoop(loop2); //initiate our second loop
 //void loop always started by default//
}

//writes the actual_pressure value on display
void updateDispActual(){
 for(byte j=0; j<3; j++)  
   digitalWrite(digitPins1[j], LOW);

 digitalWrite(latchPin1, LOW);  
 shiftOut(dataPin1, clockPin1, MSBFIRST, B11111111);
 digitalWrite(latchPin1, HIGH);

 delayMicroseconds(100);
 digitalWrite(digitPins1[digitScan1], HIGH);

 digitalWrite(latchPin1, LOW);  

 shiftOut(dataPin1, clockPin1, MSBFIRST, ~digit1[digitBuffer1[digitScan1]]);

 digitalWrite(latchPin1, HIGH);
 digitScan1++;
 if(digitScan1>2) digitScan1=0;
}

//writes desired_pressure value to display
void updateDispDesired(){
 for(byte j=0; j<3; j++)  
   digitalWrite(digitPins2[j], LOW);

 digitalWrite(latchPin2, LOW);  
 shiftOut(dataPin2, clockPin2, MSBFIRST, B11111111);
 digitalWrite(latchPin2, HIGH);

 delayMicroseconds(100);
 digitalWrite(digitPins2[digitScan2], HIGH);

 digitalWrite(latchPin2, LOW);  

 shiftOut(dataPin2, clockPin2, MSBFIRST, ~digit2[digitBuffer2[digitScan2]]);

 digitalWrite(latchPin2, HIGH);
 digitScan2++;
 if(digitScan2>2) digitScan2=0;
}
//does the averaging process
void averaging(){
 // subtract the last reading:
 total= total - readings[index];        
 // read from the sensor:
 int a = analogRead(A0);// reads the loadcell +ve voltage
 int b = analogRead(A1);//reads the loadcell -ve voltage
 int c = a-b; // calculates the differential voltage
 readings[index] = c;
 // add the reading to the total:
 total= total + readings[index];      
 // advance to the next position in the array:  
 index = index + 1;                    

 // if we're at the end of the array...
 if (index >= numReadings)              
   // ...wrap around to the beginning:
   index = 0;                          

 // calculate the average:
 average = total / numReadings;
 pressurekg = (average*1.11)-1;//converts average to pressure in kg
}

//runs the loop for actual value of pressure
void loop(){
 averaging();
 //Pressure display in kgs
 digitBuffer1[2] = (int(pressurekg)/100);
 digitBuffer1[1] = (int(pressurekg)%100)/10;
 digitBuffer1[0] = (int(pressurekg)%10);
 updateDispActual();
 Scheduler.delay(2);
 yield();
}

//runs the loop for input value from the computer
void loop2(){
 if (Serial.available() > 0) {   // something came across serial
   desiredValue = 0;         // throw away previous integerValue
   while(1) {            // force into a loop until 'n' is received
     incomingByte = Serial.read();
     if (incomingByte == '\n') break;   // exit the while(1), we're done receiving
     if (incomingByte == -1) continue;  // if no characters are in the buffer read() returns -1
     desiredValue *= 10;  // shift left 1 decimal place
     // convert ASCII to integer, add, and shift left 1 decimal place
     desiredValue = int(((incomingByte - 48) + desiredValue));
     if (desiredValue > 420)
       desiredValue = 420;

     Serial.println(desiredValue);
   }
 }      

 digitBuffer2[2] = int(desiredValue)/100;
 digitBuffer2[1] = (int(desiredValue)%100)/10;
 digitBuffer2[0] = (int(desiredValue)%10);
 updateDispDesired();
 Scheduler.delay(2);
 yield();
}


edit by mod: please include the code using the proper tags
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on Mar 28, 2014, 10:13 pm
Hello
Seems you are just missing a yield() inside your while (1)  !
Remember That coop scheduler never switch task itself

Hope this helps
Fabrice
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: alibaba9292 on Apr 11, 2014, 02:52 am
thanks fabrecio!
Ill try this :)
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: greypanda on Aug 10, 2014, 01:30 am
I'm confused. If I run this code in a "normal" loop, it prints the value:

void loop()
{

    String s1 = "abcde";
    Serial.println(s1);
}

But within the SCoop loop it fails (doesn't print anything):
void mytask::loop()
{
    String s1 = "abcde";
    Serial.println(s1);
}
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: jimford on Aug 10, 2014, 01:14 pm
Have you got a 'yield' somewhere in your main loop, such that processing is handed over to your 'mytask'?

Jim
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: moe69 on Sep 10, 2014, 01:03 am
hi fabriceo,

i´m looking for an easy and simple multitask/scheduler to get my project working.

These are the basic tasks i want to run:

- Pushbutton (short press/long press = Timer?)
- Write Serial (Bluetooth / Event based)
- Read Serial (Bluetooth / Event based)
- Update Display (Time or Event based)

I looked into your wiki and the tutorial to understand your scheduler.
Do you think it is possible to use SCoop with my project. I got only a  bit of expirience in programming, so your tutorial is not easy to read.
But if it is possible to ask you some questions if i got stuck in coding, then i will give SCoo a try.

I put a blog about my project online. If you want to have a look:
http://arduwin.blogspot.de/ (http://arduwin.blogspot.de/)

Thx for your help!
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: michaeltanner on Oct 08, 2014, 10:38 pm
Hi all,

Really good stuff, SCoop! Thanks for the work!
I would like to use SCoop with Teensy 3.1 but it looks like this doesn't work. I can compile example sketches up to Teensy 3.0 without problems, but as soon as I choose Teensy 3.1 I will get plenty of errors...

Is there somebody around using SCoop already with Teensy 3.1?

Thanks,
Regards,
Mike

Code: [Select]

Compiling 'Scheduler' for 'Teensy 3.1'
PoolControl.ino:In file included from
SCoop.h:79:2: error: #error "this library might not be compatible with this NON-AVR \ ARM platform. Please experiment and report on Arduino.cc forum"
SCoop.h:141:28: error: variable or field 'sleep' declared void
SCoop.h:141:28: error: 'SCDelay_t' was not declared in this scope
SCoop.h:247:24: error: expected ')' before 'reload'
SCoop.h:249:3: error: 'SCDelay_t' does not name a type
SCoop.h:250:3: error: 'SCDelay_t' does not name a type
SCoop.h:257:3: error: 'SCDelay_t' does not name a type
SCoop.h:260:3: error: 'SCDelay_t' does not name a type
SCoop.h:263:3: error: 'SCDelay_t' does not name a type
SCoop.h:265:3: error: 'SCDelay_t' does not name a type
SCoop.h:269:12: error: expected type-specifier before 'SCDelay_t'
SCoop.h:272:3: error: 'SCDelay_t' does not name a type
SCoop.h:272:3: error: ISO C++ forbids declaration of 'rhs' with no type [-fpermissive]
SCoop.h:277:33: error: 'SCDelay_t' does not name a type
SCoop.h:277:43: error: ISO C++ forbids declaration of 'rhs' with no type [-fpermissive]
SCoop.h:280:33: error: 'SCDelay_t' does not name a type
SCoop.h:280:43: error: ISO C++ forbids declaration of 'rhs' with no type [-fpermissive]
SCoop.h:283:3: error: 'SCDelay_t' does not name a type
SCoop.h:285:3: error: 'SCDelay_t' does not name a type
SCoop.h:In member function 'SCoopDelay& SCoopDelay::operator=(int)'
SCoop.h:272:3: error: 'set' was not declared in this scope
SCoop.h:In member function 'SCoopDelay& SCoopDelay::operator=(const SCoopDelay&)'
SCoop.h:275:5: error: 'timeValue' was not declared in this scope
SCoop.h:275:19: error: 'const class SCoopDelay' has no member named 'timeValue'
SCoop.h:In member function 'SCoopDelay& SCoopDelay::operator+=(int)'
SCoop.h:278:12: error: 'add' was not declared in this scope
SCoop.h:In member function 'SCoopDelay& SCoopDelay::operator-=(int)'
SCoop.h:281:12: error: 'sub' was not declared in this scope
SCoop.h:At global scope
SCoop.h:295:25: error: expected ')' before 'reload'
SCoop.h:297:3: error: 'micros_t' does not name a type
SCoop.h:298:3: error: 'micros_t' does not name a type
SCoop.h:305:3: error: 'micros_t' does not name a type
SCoop.h:308:3: error: 'micros_t' does not name a type
SCoop.h:311:3: error: 'micros_t' does not name a type
SCoop.h:313:3: error: 'micros_t' does not name a type
SCoop.h:317:12: error: expected type-specifier before 'micros_t'
SCoop.h:320:3: error: 'micros_t' does not name a type
SCoop.h:320:3: error: ISO C++ forbids declaration of 'rhs' with no type [-fpermissive]
SCoop.h:325:35: error: 'micros_t' does not name a type
SCoop.h:325:44: error: ISO C++ forbids declaration of 'rhs' with no type [-fpermissive]
SCoop.h:328:35: error: 'micros_t' does not name a type
SCoop.h:328:44: error: ISO C++ forbids declaration of 'rhs' with no type [-fpermissive]
SCoop.h:332:3: error: 'micros_t' does not name a type
<--- snip too much errors... --->
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: Rob_Brouwer on Apr 27, 2015, 10:01 am
Hello,

It seems there is no answer on the question if it is possible to use Scoop with the teensy 3.1 version.
Compiling gives a lot of errors and I am wondering why.

Greetings Rob
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: fabriceo on May 03, 2015, 06:13 pm
Hi Rob
Just have a look at the begining of the include file and look for a Define like mk20dx128 and add a new one on the line for the t3.1 which is mk20dx256, or something like that, then it should work ;)

im sory that I didnt followup on this lib as much as it should but still hope you guys have fun with it

Cheers
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: Rob_Brouwer on May 05, 2015, 09:22 pm
Hi Fabriceo,

Thanks for the reply.
I have changed  mk20dx128 in mk20dx256 and now its compiling without errors.
Its now time for me to read the manuals and try all the examples to see if this is what I am looking for. At first glance it looks very promessing.

Greetings Rob

Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: testato on Jun 23, 2015, 03:52 pm
x iscrizione
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: wongss on Jun 29, 2015, 03:20 pm
I used SCoop v1.2 on ATMega328p for a number of projects and worked very fine but I must be very careful with the tasks' stacks due to the very limited RAM. I use a separate task to report all the tasks' stacks and also the maximum time taken to go 1 round-robin (normally <10ms).

SCoop makes handling multiple IO and tasks so easy without the need to go pre-emptive multitasking.

Thanks for the port of SCoop to Teensy 3.1 (using instruction given & also need to change the code very slightly to remove warnings) that has so much more resources. Tried it and works fine too.

Thanks for the SCoop.
Title: Re: SCoop - multitask and Simple COOPerative scheduler AVR & ARM
Post by: leo111 on Aug 28, 2016, 01:21 am
Dear author
I used to do multiTask SCoop module, it is great, thanks
Error beginning from version 1.6.10,version 1.6.11
Compile error, overflow message
Arduino: 1.6.10 (Windows 7), the board: "Arduino / Genuino Uno"

`Timer0_overflow_count 'referenced in section` .text' of C: \ Users \ leo \ AppData \ Local \ Temp \ ccE9u4Aa.ltrans1.ltrans.o: defined in discarded section `.text 'of wiring.c.o (symbol from plugin)

`Timer0_overflow_count 'referenced in section` .text' of C: \ Users \ leo \ AppData \ Local \ Temp \ ccE9u4Aa.ltrans1.ltrans.o: defined in discarded section `.text 'of wiring.c.o (symbol from plugin)

collect2.exe: error: ld returned 1 exit status

attention it please ,thanks