What about FreeRTOS

[Massimo Banzi]

Hello Devs

Now that Amazon has helped re-license FreeRTOS to MIT it seems like a good target for Arduino.

A member of the community has done a good job to package it up as a library.

What do you guys think about FreeRTOS?

(/me wears bulletproof vest and waits)

M 

--

Massimo Banzi

m.b...@arduino.cc

[Thibaut VIARD]

Hi Massimo,

It is maybe a bit early to jump on it.

Let's see how the move to real opensource project is going first. There may be other solutions on the opensource field for that kind of extension.

You may have to discuss with Amazon if they agree on seeing FreeRTOS LGPLized while statically linked with Arduino Core (may it be the case?).

Thinking out loud, and putting my kevlar vest, it may be interesting to switch from LGPL to MIT or Apache 2.0 license for Arduino Core.

Going back to more technical stuff, I'm not really fond of having an RTOS library but would prefer seeing the RTOS being at the heart of the Core, as oftenly discussed here and there, so that we obtain a consistent offer from the ground up (Arduino 2.0?).

My 2 cents,

Thibaut

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[Massimo Banzi]

Hello Thibaut

Moving the core to Apache 2 or MIT would be really good, it’s a 1 year project as we need to get approval from all the people who contributed to the code In the past.

That’s maybe for a separate thread :)

I also would like to see an RTOS as the core, we already used the Arduino API on top of linux and we’ll be able to more easily use them on top of other RTOS like mbedOS when we release the “chainsaw” code I mentioned in my last talks (looking at you Cristian Maglie ;) ) Ideally the Arduino API should be pluggable on top of a number of implementations with this code.

Thanks for the comment :)

m

--

Massimo Banzi

m.b...@arduino.cc

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Phillip Stevens]

Now that Amazon has helped re-license FreeRTOS to MIT it seems like a good target for Arduino.

A member of the community has done a good job to package it up as a library.

Massimo, not sure if you're referring to this AVR specific library in the Project Hub.

If so then, yes it has gathered quite a bit of attention, and downloads.

I've moved it onto the v10 with MIT licence already, so it is pretty much ready to go as a stand alone FreeRTOS library for AVR.

Unfortunately I still like 8 bit machines, so I've never converted my work to support 32 bits.

But plenty of others have done that work already too.

What do you guys think about FreeRTOS?

I have been working with it for 6 years.

+1 for consistency and longevity.

+1 for stability of API and being bug free (lots of OpenRTOS and SafeRTOS experience flows in).

+1 for ease of use.

+1 lightweight (just a few C files), with "just enough" features.

As a library FreeRTOS works excellently with most AVR machines (even the 3 byte PC device the Mega), but the Core USB keep-alive timer implementation sometimes causes issues for the 32u4 based boards.

I can't comment on other CPU implementations, so I won't.

Cheers, feilipu

[Andrew Kroll]

Never liked RTOS's, too much bloat, too much to go wrong.

I always found a real preemptive system better.
Sure it requires a larger MCU, mega2560+RAM, or ARM, but way easier to use and more intuitive to write code on IMHO.

Yes, there are people who have "issues" with locks, spinlocks. and when to use them, etc.

These people just need to push themselves harder to learn the concepts, which really are not all that difficult.

These same people have issues with the silly RTOS on the ESP8266, and wonder why when they have a loop that takes too long, that the WDT barks, and does a reset. Of course the horrible fix for this is sprinkling yield() all over the place, bloating the code.

No, sir, I don't like RTOS junk, it is overkill. I'll just use my own stuff which is way better, and much leaner, and if I want to, can assign task priorities, or not. Usually I don't assign any kind of prioritization, and instead use even time slices. This is not a huge issue because you normally don't have enough RAM on an MCU to do so many tasks that any one task is going to be so slow, that it fails. When you get to that point, it is time to use multiple MCUs and distribute the problem.

Do what you like, I won't be using it.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--

Visit my github for awesome Arduino code @ https://github.com/xxxajk

[Holger Lembke]

I would ask the following questions: Who is the target audience? Who is the user?

As far as I see, beginners would benefit from a simple, low profile sheduler concept, Something easy to understand, easy to work with, easy to solve cases like dependencies of "threads".

As an experienced developer I would shrug my shoulders and say "whatever. all the same, take something that looks like an aktive project and meets my demands, Idc.".

As a project leader for the Arduino project I would focus on very different tasks.... :-)

[Andrew Kroll]

@Holger Lembke

Yes, there are many ways to do this, and lots of stuff out there that already works. No sense in bogging down the devs with suporting yet another library, especially one that the dev team didn't even write.

+1 to you.

[Massimo Banzi]

Holger

I’m genuinely interested in your feedback on this

As a project leader for the Arduino project I would focus on very different tasks.... :-)

What would you focus on?

M

I’ll reply your other questions on the original thread

[Massimo Banzi]

There is no single use case

The beginner on the Arduino UNO doesn’t need an RTOS. Being able to declare multiple “loop()” methods is enough

A more advanced user on a more capable processor like an ARM will have several tasks going on in parallel with TCP IP stack, SSL stack , IO from different buses to manage. Having an Arduino standard way to interface RTOSs would be useful.

My question was about what you guys think of FreeRTOS, not what you guys think of RTOSs in general, we had that conversation already in the past…

M

--

Massimo Banzi

m.b...@arduino.cc

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Massimo Banzi]

> especially one that the dev team didn't even write.

There is a lot of code none of us wrote (libc on different platforms, CMSIS on arm etc etc) and yet we use it every day.

M

[Thomas Roell]

First of all, I do not like FreeRTOS at all. It's incredibly bloated (API wise), and implementation wise it's the worst nightmare. 

Some examples here quickly:

xSemaphoreTakeFromISR(SemaphoreHandle_t xSemaphore, signed BaseType_t *pxHigherPriorityTaskWoken)

So really you need to first off separate out whether you called from an ISR or not (which is something more grown up RTOSes frown upon). And then you have this ultra-odd "pxHigherPriotiyTaskWoken), which basically means you half way have to implement task dispatching logic in your application code.

There is a whole zoo of those things, which you as a developer coming from using a lot of other RTOSes stop and think, WTF ? Some are marked now as obsolete, but are still dragged around ...

Also please consider that FreeRTOS is insanely slow. I did compare it to one of my own creations (a uITRON based statically configured RTOS), and there was a 10x difference in most cruical functions (Cortex-M3). There have been a lot of talk on forums with numbers for other processors, and a lot of bad talk about the fact that at least at the time FreeRTOS prevented you from publishing numbers for any benchmark for their code ...

At the end of the day, the Amazon move is purely marketing. They picked one that was not associated with anybody else yet. There technically better solutions out there, like RIOT-OS, Zepyher and MyNewt-OS.

IMHO the key question first has to be, "what problem are you wanting to solve". 

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[Thibaut VIARD]

+1 regarding FreeRTOS API

+1 regarding RIOT-OS

[Paul Stoffregen]

> Being able to declare multiple “loop()” methods is enough

Oh, if only it could be that simple!

The hard problem is how novice or even experienced Arduino users decide
to divy up memory into separate stacks for each loop() they declare. 
You don't get to just declare more loop() functions. FreeRTOS makes you
assign memory to be used as their stack space.

Today the mental model of RAM which Arduino presents to users looks like
this:

  Global variables use 435 bytes (16%) of dynamic memory, leaving 2125
bytes for local variables.

The memory "for local variables" is also for String & other stuff using
malloc(), as well as interrupts.  Today the Arduino IDE prints "Low
memory available, stability problems may occur" when this local
variables memory is under a pre-defined threshold. Running out of RAM is
one of the hardest, most confusing problems beginners face on Arduino.

The normal model for FreeRTOS is a professional engineer is familiar
with the memory usage of all the code they've put into every task. How
will Arduino users who don't know the inner workings of the many
libraries they use make these sorts of choices?

[Thomas Roell]

+167 Paul

You pretty much summarized the concerns. IMHO multitasking for the enduser is a dead duck. Even most grown up application (as so nicely described) use multiple tasks only for their middleware stacks, but NOT for the real application code. So I can see a internal RTOS use case for things like LwIP in the background, but not for multiple "loop()" instances.

The biggest hurdle is the separate stack requirement. How big does each stack need to be ? How do I detect a stack overflow ? What do I do about it ? Many of those questions cannot be addressed without proper tools (say a debugger like "gdb"). So they are out of reach for 95% of the end users. 

If you want to go there, then MBED + Eclipse might be a better choice that already does exist.

[Mikael Patel]

I think we can all agree that an RTOS is not recommended for smaller MCUs such as the Arduino Uno. But having said that we need more Software Architecture within the Arduino community (e.g. libraries and cores) to improve reusability, robustness, quality and performance.

Adding a Scheduler (collaborative) is not a big issue. Also adding stack size detect can easily be done (please see https://github.com/mikaelpatel/Arduino-Scheduler for an example). The real challenge is making a transition to a higher level of Software Architecture and maintaining as many contributions to the Arduino eco-system as possible. Many Arduino "device drivers" do not work together very well. This is becomes more obvious as we transition to boards with more resources and higher performance.

In some sense, it is not as much about choosing an RTOS as defining rules for resource management (hardware modules, drivers, etc). In any case, I am all for this discussion.

FreeRTOS is a solution to a problem and now we need to understand the problem :)

Cheers! Mikael

[Osqui]

Sorry if I misunderstood but ... wasn't Arduino 101 based on custom Zephyr? It could be a (already started) beginning...

[Mike]

There are more boards using ESP8266, ESP32, SAMD (M0), STM (not sure) with anticipation that M4 boards will arrive in 2018. The MKR line is going strong for Arduino.

Should Uno, 32u4, etc. have an RTOS - probably not. But like some previous Arduino+Linux boards, one can draw a line and say "above this an RTOS could be considered, below not".

So perhaps coming up with an overall set of ideas on how things might be shaped up and go from there?

[M.]

how can I unsubscribe from that mailing list? the developers+...@arduino.cc does not work. the webm...@arduino.cc is invalid. I goet just deliver daemon responses. Annoying

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Thomas Roell]

Couple of more comments.

There is a whole zoo out there what could be done.

The real killer problem for most entry level users is that task stack. There are fundamentally 2 ways around that. One is to use a setup where only one stack is used. This implies run-to-completion semantics per task, and is mostly used in event based systems (async event callbacks can pre-empty the main task). The other solution is to let the task stack grow if needed. In a non-VM system this means essentially that you need page in/out the stack per task. Of course this is not really "realtime" anymore.

What many users would like to do as a first step is to avoid having to call "BLEperipheral.poll()" (and similar APIs) to get callbacks dispatched. So intuitively they are asking really for an event based system as a first step.

But then there is this problem of adding 3rd party network stacks or similar middleware that is coming from a more traditional environment, where the answer to concurrency issues always has been a RTOS. They do expect semaphores and event-flags as a means to communicate between ISRs and tasks. Those traditional RTOS objects are totally counter-intuitive for the beginners ("hey, I just want to have a callback when somebody writes the my BLE attribute"). 

FreeRTOS now is totally focused on being a traditional RTOS. It has a lot of baggage from an organic growth process (why do people have to reinvent the wheel over and over again, just to find themself having the same round wheel ...). So the problem that most users would need to have solved is not solved with FreeRTOS. In fact about 70% of the functionality is redundant. 

An interesting system that one might take a peek at is PROS for the VEX controllers (https://pros.cs.purdue.edu/api/). We are using that amongst other tools for robotics at our school. It's driven by Purdue, so also coming out of the research field. The API is semi-Arduino, so kind of comparable. What they do is to expose "Task", "Semaphore" and "Mutex" as objects, "void *" and move the resource management off behind the API. For tasks, the stack size is still passed in as parameter, so still the same issue. A detail that shows that a lot of thought went into this is the idea of a periodic loop, which means the look gets started with the same interval, no matter how long the execution of the body took. Normally you'd do that as a cyclic activated task, but by providing this layered API this functionality is easily accessible without jumping throu hoops. The subset of the offered functionality might be an interesting guideline. They did start out with FreeRTOS 7.1.1 internally, but rewrote a good chunk of the code to suit their (and their users) needs.

One of the things I'd warn against is picking ANY RTOS and exposing it at a level where it cannot be replaced by another one. Suppose LwIP would be tied to say ChibiOS, but Arduino SAMD would enforce FreeRTOS. That I cannot use this external piece of source code at all. If an exposed API to Arduino users would be abstract enough it should be easy enough to implement it using either ChibiOS or FreeRTOS.

BTW, before the discussion goes back in cricles. A cooperative scheduler is more or less a preemption priority driven RTOS, except that all tasks that are cooperative share the same periority. So a subclass ...

- Thomas

 

[Andrew Kroll]

Here is what I wrote for larger AVRs with expanded RAM, 128x and 256x.
The strength is in the simplicity of it.
The speed is because of the banked and shared RAM arenas.
Some ARM MCU also support external RAM, and the same concept can be used on them.

Perhaps someone here could make use of it?

Would be a good Arduino product to have for AVR.

[Andrew Kroll]

HAH forgot to post the link.
https://github.com/xxxajk/xmem2

[Marek Poks]

How can I unsubscribe?

Sent from my BlackBerry 10 smartphone.

From: Andrew Kroll Sent: środa, 13 grudnia 2017 19:14 To: Arduino Developers Reply To: devel...@arduino.cc Subject: Re: [Developers] What about FreeRTOS

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Thomas Roell]

Andrew,

while this is interesting, it goes down again the wrong rats hole of "XYZ" vs. "ABC".

First one has to decide what is the problem that is being attempted to be solved. Then one has to figure out what API level objects are required with what functionality. Is the set minimal (anything that is not minimal is bad).  And so on and on again ...

All I am seeing here in terms of discussion is whether "XYZ" is a good choice ... We are not addressing the question of how something like an RTOS should be exposed to the user (are tasks explicite ? Or does a user have to look them up somehow via name ? is there a system object that instantiates (manages) other derived objects (like RTOS.createTask()) ? do we want to expose wait queue in FIFO order, or also in priority order ? what happens if a C++ destructor on a task is called, or on a mutex where another task waits on).

It's like "is a Ferrari a good car ?" (I'd say no, because I cannot mount a bike rack or skis on it ... So my view is driven by requirements I have)

- Thomas

[Andrew Kroll]

Thomas,

Yes, which is one reason why I decided to share the link to it, so that the concepts of it can be looked at.

If you look carefully at it, you may also notice that it does solve quite a few of the problems to be expected from a linear arena broken in to chunks...

As far as writing code using it, you can actually take several sketches and combine them by renaming the main loop and launching it as a task.

I suppose I should write an example showing that within the library, but never got the chance to do so.

A simplistic demo is available here though: https://github.com/xxxajk/testMultitask

[Dennis Lee Bieber]

On Wed, 13 Dec 2017 19:20:37 +0100, Marek Poks
<b...@marekpoks.pl> declaimed the following:

>How can I unsubscribe?

By following the URLs in the message headers...
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[Matthew Ford]

As I mentioned in a previous discussion on 'multi-threaded' Arduino.
Since Arduino is aimed a novices we need something easy to understand
and use.

I have found MicroBit's Fiber implement to satisfy both those
requirements. (a million school children can't be wrong)

Last time I raised this there were a wide range of technical objections.

 However I submit that novice users ONLY care more about how easy it is
to use not how efficient it is.  E.g. Uno is still widely used as a
starter board in spite of its limitation (compared to later chips)

[Thomas Roell]

Matthew, 

> a million school children can't be wrong

Reminds me of the Hiltler Jugend. Could those million kids have been wrong ?

> Last time I raised this there were a wide range of technical objections.

Yeah, it's a turd. Bad concept, sloppily coded, issues left and right. Perhaps good enough for a demo, but then falling apart rather quickly.

- Thomas

[Phillip Stevens]

What do you guys think about FreeRTOS?

Just sticking to the original thread question. 

 

First of all, I do not like FreeRTOS at all. It's incredibly bloated (API wise), and implementation wise it's the worst nightmare. 

Some examples here quickly:

xSemaphoreTakeFromISR(SemaphoreHandle_t xSemaphore, signed BaseType_t *pxHigherPriorityTaskWoken)

So really you need to first off separate out whether you called from an ISR or not (which is something more grown up RTOSes frown upon). And then you have this ultra-odd "pxHigherPriotiyTaskWoken), which basically means you half way have to implement task dispatching logic in your application code.

This is simply a flag which provides an opportunity to do a context switch before exit from the ISR. It can be set to NULL if you don't have a reason to use or care about it.

The documentation is here: https://www.freertos.org/xSemaphoreTakeFromISR.html

There is a whole zoo of those things, which you as a developer coming from using a lot of other RTOSes stop and think, WTF ? Some are marked now as obsolete, but are still dragged around ...

Yes, the basic API has been basically unchanged for as long as I've used it, only 6 years of a 15 year life span.

Which some people would consider to be a useful feature.

Support for legacy API (prior to version 8) can be turned on or off with a single define.

In my understanding, the new MIT licence means that Arduino could take what FreeRTOS offers as a starting point, and do with it whatever you wish.

For example disguising "complicated" features from beginners. But still retain the scheduling API to work with other libraries as needed.

But, speaking as an erstwhile beginner, working with FreeRTOS Tasks is not hard, and simple Uno based examples make it easier.

[Thibaut VIARD]

As long as the RTOS is used only by developers and transparent for any user, I guess everything is doable.

By the way, if the goal is to address only ARM boards, we already have an opensource RTOS provided by ARM through CMSIS, with Apache 2 license.

My 2 cents,

Thibaut

[Dennis Lee Bieber]

On Thu, 14 Dec 2017 09:36:19 +0100, Thibaut VIARD
<aetha...@gmail.com> declaimed the
following:

>By the way, if the goal is to address only ARM boards, we already have an
>opensource RTOS provided by ARM through CMSIS, with Apache 2 license.
>

Really? There is a rather significant "3rd Party" tag on the image at
https://developer.arm.com/embedded/cmsis

Reading that image gives the impression that CMSIS defined an API, but
that API has to be mapped to whatever RTOS kernel is chosen for use.
http://arm-software.github.io/CMSIS_5/RTOS2/html/index.html
http://arm-software.github.io/CMSIS_5/RTOS2/html/rtx5_impl.html implies
that the "reference implementation" (RTX) came from Keil and would need to
be "ported" to be built using other toolchains (okay, that may not be much
different from any other RTOS being adapted to Arduino build tools) -- or
did you mean the RTOS1 variation? So... Just for CMSIS we have two
differing reference implementations, and instructions on migrating from v1
to v2... and tied to ARM-M processors.

{and then there is TI-RTOS, which for some reason Energia does not support
on the TIVA C [ARM] boards, but does support on MSP boards -- yet TI-RTOS
is available on the CCS toolchain... Energia being a TI specific fork/port
of the Arduino IDE}

[Thomas Roell]

Interestingly, the newer CMSIS_5 RTOS spec is much better than FreeRTOS ... Except that there is KEIL's RTX underneeth it ...

But it back to the fact that there is a zoo out there ... it would be helpful to understand what the goal is first ...

Just to throw another one in the mix: https://github.com/LITEOS/LiteOS_Kernel

[Phillip Stevens]

Interestingly, the newer CMSIS_5 RTOS spec is much better than FreeRTOS ... Except that there is KEIL's RTX underneath it ...

>By the way, if the goal is to address only ARM boards, we already have an
>opensource RTOS provided by ARM through CMSIS, with Apache 2 license.

This is Keil PR view on the differences. http://www.keil.com/pr/article/1280.htm

TL;DR Both Keil RTX and FreeRTOS are a button click away. Tied to their respective licences of course. 

--

Sent from a Mobile Device. Replies may appear terse.

[Thomas Roell]

Actually a good point. CMSIS-RTOS is designed as a wrapper to provide a generic RTOS abstraction. Perhaps this is good enough ?

- Thomas

--

[William Westfield]

> we already have an opensource RTOS provided by ARM through CMSIS

Hmm. I thought that CMSIS/RTOS was more of an API specification than an actual RTOS. The sort of thing where ARM says “if you were going to implement an RTOS, we really think that these are the sorts of functions/APIs/names you should implement.” Or did you mean Keil "CMIS-RTOS RTX"? (and how portable to other compilers IS that?)

BillW

[Jack Rickard]

Reinventing the wheel is how we get better wheels.  My Tesla Model S just wouldn't work 

well with large diameter very narrow wooden ones.  

Clean sheet of paper.  An Arduino RTOS.  Make it better, faster, smaller, and easier to use.

That would be a dramatic stroke.

Obsolete FreeRTOS.  Glomming it on kind of just forces redundancy and bloat.

But the train may have already left.  The larger iron such as ESP32, as pointed out, is already 

going FreeRTOS.  So I can see why the question is posed and on the table.

On Thu, Dec 14, 2017 at 10:23 PM, William Westfield <wes...@mac.com> wrote:

You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--

--------------------------------

http://EVTV.me

---------------------------------

[Andrew Kroll]

It's still my opinion that RTOS is too problematic, especially cooperative ones. Having time limits on operations are causing many headaches for people using the esp8266, forcing people to learn state machines... while this isn't a bad thing, there is indeed a better way, and that is to do real preemption.

The thing that scares so many about using preemption is the same concept that scare people into polling and not using an ISR, atomic variables,  and that holds back everyone.

There is a very simple solution to it though, and all you need to do is make all the memory management ISR safe, which I have already done for ARM and AVR. This also makes it safe for a preempted task manager.

I've already written real preemptive multitasking  for AVR with memory expansion too. I've found that depending on the project, it can be a huge benefit. Not all projects will find multitasking useful, sure, but that is something the person writing the firmware decides anyway.

--

You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--

[newc...@flounder.com]

There is a good reason that people avoid preemptive multitasking: it’s
hard to get right. I wrote my first preemptive multitasking app around
1968, and after fifty years of writing preemptive multitasking programs, I
can usually get it right the first time. I have taught it, mentored
people doing it, even written a couple books on it. The hardest part is
the paradigm shift required to get it right.

Yes, I would love to have a preemptive multithreaded environment. But I
would flourish in such an environment. Others may not find it
“user-friendly”. Many “lazy programmer” paradigms break horribly in
preemptive multithreaded environments. The use of global variables to
“pass parameters” breaks. I have lectured on the issues and seen students
do their lab using the techniques I told them not to use. And been able
to deal out “I told you so” in great gobs. And some of them still don’t
get it. But the multicores are coming, and you need things like a
scheduler that understands core bindings. And one whose “idle loop” is
either deep sleep or light sleep, depending on context.

Wait a minute. The multicores are already here.

But be careful what you wish for. Preemptive mulithreading is not for the
faint of heart. Actually, it is easier to teach new programmers, who do
not have years of bad programming habits to unlearn, than to teach
experienced programmers, who have been taught “away from best practice” by
teachers who learned on PDP-11s and who taught that passing parameters is
“expensive” (passing a parameter on a modern x64 architecture typically
has a maximum time of 200 picoseconds, and a minimum time of 0, but to
avoid these costs programmers write code that uses global variables and
cannot be made thread-safe). I have not yet seen the generated code for
an AVR or M0, but I suspect that gcc code can pass parameters with a max
of 1 or 2 clock cycles and a min of 0.
Joe

>>> email to developers+...@arduino.cc.

>>>
>>
>>
>>
>> --
>> --------------------------------
>> http://EVTV.me
>> ---------------------------------
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an

>> email to developers+...@arduino.cc.

>>
>
>
>
> --
> Visit my github for awesome Arduino code @ https://github.com/xxxajk
>

> --
> You received this message because you are subscribed to the Google Groups
> "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to developers+...@arduino.cc.
>

[Andrew Kroll]

Took me only a couple of weeks to get right :-)

While I never did use a PDP-11 (or older) I used small microcomputer systems from the 70's. You know, us "killionaires".

Getting it right these days is pretty simple, since there are lots of examples out there, and you simply knock out the bloat, and keep the good parts from various places.

For example, sometimes a shared region across all tasks is a great thing to have. On the larger AVR, this region is set to the on-chip RAM, All tasks are held in-place with impossible to corrupt switched memory banks. In order to pass messages, there is a message passing system built-in as well.

Curious? https://github.com/xxxajk/xmem2

Take a peek, you may be surprised what you find there is easier to use than you think.

>>> email to developers+unsubscribe@arduino.cc.

>>>
>>
>>
>>
>> --
>> --------------------------------
>> http://EVTV.me
>> ---------------------------------
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an

>> email to developers+unsubscribe@arduino.cc.

>>
>
>
>
> --
> Visit my github for awesome Arduino code @ https://github.com/xxxajk
>
> --
> You received this message because you are subscribed to the Google Groups
> "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to developers+unsubscribe@arduino.cc.

>


--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[newc...@flounder.com]

Prior to my extensive Internet presence, a search on my name came up with
only two quotes. The relevant one here is “I don’t mind people
reinventing the wheel. I do object when what they invent is a trapezoidal
wheel with an off-center axle.”
Joe

> Reinventing the wheel is how we get better wheels. My Tesla Model S just
> wouldn't work
> well with large diameter very narrow wooden ones.
>
> Clean sheet of paper. An Arduino RTOS. Make it better, faster, smaller,
> and easier to use.
> That would be a dramatic stroke.
>
> Obsolete FreeRTOS. Glomming it on kind of just forces redundancy and
> bloat.
>
> But the train may have already left. The larger iron such as ESP32, as
> pointed out, is already
> going FreeRTOS. So I can see why the question is posed and on the table.
>
> On Thu, Dec 14, 2017 at 10:23 PM, William Westfield <wes...@mac.com>
> wrote:
>
>>
>>
>> You received this message because you are subscribed to the Google
>> Groups
>> "Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an

>> email to developers+...@arduino.cc.

>>
>
>
>
> --
> --------------------------------
> http://EVTV.me
> ---------------------------------
>

> --

> You received this message because you are subscribed to the Google Groups
> "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to developers+...@arduino.cc.
>

[Andrew Kroll]

Yeah, but an off-center hole for the axle works if your axle is bent ;-)

Also, wheels these days look more like gears, for grip, so someone DID reinvent the wheel.

On Tue, Jan 23, 2018 at 3:35 AM, <newc...@flounder.com> wrote:

Prior to my extensive Internet presence, a search on my name came up with
only two quotes.  The relevant one here is “I don’t mind people
reinventing the wheel.  I do object when what they invent is a trapezoidal
wheel with an off-center axle.”
      Joe

> Reinventing the wheel is how we get better wheels.  My Tesla Model S just
> wouldn't work
> well with large diameter very narrow wooden ones.
>
> Clean sheet of paper.  An Arduino RTOS.  Make it better, faster, smaller,
> and easier to use.
> That would be a dramatic stroke.
>
> Obsolete FreeRTOS.  Glomming it on kind of just forces redundancy and
> bloat.
>
> But the train may have already left.  The larger iron such as ESP32, as
> pointed out, is already
> going FreeRTOS.  So I can see why the question is posed and on the table.
>
> On Thu, Dec 14, 2017 at 10:23 PM, William Westfield <wes...@mac.com>
> wrote:
>
>>
>>
>> You received this message because you are subscribed to the Google
>> Groups
>> "Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an

>> email to developers+unsubscribe@arduino.cc.

>>
>
>
>
> --
> --------------------------------
> http://EVTV.me
> ---------------------------------
>
> --
> You received this message because you are subscribed to the Google Groups
> "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to developers+unsubscribe@arduino.cc.

>


--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.