Suggestion - how to make teensy much simpler

I

ippisl

Member
One thing that is still a bit undeveloped with the arduino is concurrency and non-blocking libraries - and it makes it harder for beginners to write code,especially complex code, because of timing issues.

At the moment there all kinds of ideas , but they are relatively complex and require some rtos knowledge.

So i've been thinking about what's the simplest way to enable concurrency for beginners:

What about software "chips" ? You basically just instantiate them(power them up), send them commands, and check if they have new data to read, and if so - read the data ?

This way requires almost zero learning(unlike all common current common concurrency methods) , because as part of learning to use the arduino users already learn the concept behind chips(or shields).

So something like this(pseudo code):

c = KeyboardScannerChip(scan_inputs, scan_outputs, speed) ; \\key scanner is a concurrent module

c.change_speed(3);

c.key_available(){
data = read_key();
}


And by requiring almost zero learning, it might have a decent chance to be adopted by the community, and significantly increase the level of abstraction and code reuse in the community.

And while writing "chips" will be more complex(since they need use an rtos, manage queues and work in parallel) , i think it would make sense to invest that effort for some people in the community, for example, shield makers. And even a small number of such chips(say 20-30) could open many opportunities for the platform.

Of course the hard part is how to implement this - which i don't have good ideas to how :) .And i think it might take more memory, so it might not work on the atmega and such.

So what do you think ?
 
OK and how do you think how the teensy would handle all these concurrency issues? Essentially you are asking for the teensy to become an RTOS.
Most arduino libraries are already set up, so that they support COOPERATIVE multitasking, hence the existence of available() functions.
The main problem between libraries is in general the usage of hardware resources. Your ideas of chips will not fix this. The way around this would be to write a hardware abstractions layer with locking and permissions. So again you are writing an OS.
 
kpc: i think there's a ChibiOS version that enabled multithreading(at least cooperative) and created an arduino compatible HAL. I've seen also version for the due and maybe teensy.

http://forum.arduino.cc/index.php?topic=176757.0 - search " existing Arduino libraries".

So maybe this offer a partial or full solution. And while this is an important problem, i think this solution isn't fit non-expert users - far too complex , they need to learn about all the RTOS primitives.

And i think adoption in the arduino world really depends on adoption by non-experts - because they are the majority - so they have a big influence on library/shield makers.
 
I think that a true HAL for the teensy would be a nice thing for the advanced developer, so that you could write multi-hardware-platform code by querying H/W resources, i.e. with ADC::count() or FTM[0].channels::count(). But this would be far beyond the needs of the average user and make things ways too complicated for the beginner.

The available libraries allow even the non-experienced to make things easily work, and that's what makes the Teensy sell.

An advanced programmer will for sure find more elegant ways to deal with hardware ressources and timing issues without eating up half of the Teensy's memory with a HAL library and abstract drivers.

I for myself wouldn't want to install Win7 on a 486 processor system... ;-)
 
Theremingenieur, even non-experienced users feel the lack of concurrency and non-blocking libraries. For example, if a non-experienced user want to combine two different projects into one - he'll run into timing issues and unnecessary complications.

>> I for myself wouldn't want to install Win7 on a 486 processor system... ;-)

Of course when you put it this way, it doesn't sound appealing. But maybe the resource consumption will be reasonable and the amount and quality of libraries we'll gain would be worth it ?
 
FWIW, I've decided to throw money at this problem.

Not convinced that the power meter I'm developing would be able to handle measurements and SD card writes simultaneously, I've dedicated a processor to dealing with polling and writing to SD (and hence it's less timing dependent) while the other processor just does power measurements.

As for the RTOS option, at least the three I looked at scared me away with documentation that was perhaps legible to a CS major or a serious enthusiast but not to me.
 
A few years ago, Arduino intended to move towards an event model for concurrency. I believe Javascript was the primary motivation & model. Or at least that was the idea and intention, as I recall mostly from David Mellis. So far, the results have been underwhelming (eg, serialEvent) and since then Arduino has moved in all sorts of other directions. Obviously their internal legal battle took some toll on development, until very recently.

I believe David's idea, at least in general, is probably the best way to make concurrency accessible for novices. David would probably disagree with me on technical details.

On Friday I'll be talking with Massimo in person at Maker Faire. At least that's the plan.... but then, we've planned to talk every year, but never got to for more than a few minutes. Everyone wants a piece of Massimo's time, including a lot of big media people. I think this year, specifically whether Massimo makes time to chat or gets pulled away, will be a good litmus test for how interested Arduino really is to work with me.

Ideally, I'd like to see event handlers for hardware and software timers and for other I/O. I think that could really pave the way for Arduino to gain a lot of useful concurrency, without the huge complexity preemptive scheduling, and without the wasteful memory segmenting of many stacks.

Realistically, if the Arduino guys remain focused on... well, whatever they're focused on (I really have no idea) if anything, then I'll probably keep working on debug, more USB types, more audio features for 2015. I do want to do better concurrency and lots of other stuff, as well as a couple more Teensy products, but everything takes time. Lots of time. Always lots more than anticipated!
 
@Paul
Obviously their internal legal battle TOOK some toll on development, UNTIL VERY RECENTLY.
Click to expand...
Sorry if I missed the news. But I notice you are talking in past tense. Court case settled?
 
duff said:
can you elaborate on what you have planned?
Click to expand...

No, I can not discuss details at this time, other than to say I'm working on something that will eventually provide debug on future Teensy.

Really, this is just in the context of prioritizing my time.... which do you think will make the most people happy, debug first, or better concurrency support first?
 
debug seems to me would offer more benefit to wider teensy community, which I think would help in concurrency development also.

I have a scheduler library (round robin) based of William Gays fibers library that provides a good test case for concurrency. Its not RTOS but I've used it with OCTO library with some satisfying results though its still in development, slowly though. The Chibios and FreeRTOS ports are good but makes you have to write drivers using their Hals formats in which a lot of the standard Arduino libraries will fail especially if they set interrupts.
 
kpc said:
@Paul

Sorry if I missed the news. But I notice you are talking in past tense. Court case settled?
Click to expand...

Here are all the releases Arduino has ever made:

2005: 0001, 0002
2006: 0003, 0004, 0005, 0006, 0007
2007: 0008, 0009, 0010
2008: 0011, 0012
2009: 0013, 0014, 0015, 0016, 0017
2010: 0018, 0019, 0020, 0021, 0022
2011: 0023, 1.0
2012: 1.0.1, 1.0.2, 1.0.3, 1.5, 1.5.1, 1.5.2
2013: 1.0.4, 1.0.5, 1.5.3, 1.5.4, 1.5.5
2014: 1.0.6, 1.5.6, 1.5.7, 1.5.8
2015: 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.4

This many not look so remarkable, until you consider the 5 releases this year occurred from February to May.

The 1.6.2 release was the first, as far as I know, to release a huge amount of new functionality developed exclusively by the Arduino team. Even the 1.5.x platform/architecture stuff was started as a contribution by Mark & Rick working on the Chipkit stuff.

I have followed Arduino's development pretty closely since mid-2008. They've definitely started moving a LOT faster and doing things with far more urgency that I've ever seen before.
 
Would be cool to put WFW_3.11 - Win_98 on an i7! {go linux}

On the T_3.1 is there a short path to usable debug or is the HDW setup going to hinder that - or expose PJRC work to clone? Debugging into the LIBS and low level likely only helps the dedicated experts on timing & HDW issues. Though breakpoints and local variables could be handy to all when the mistake it theirs. What's the ZERO model - but that has special HDW ports/support.

Linux on RasPi - makes it powerful and yet sluggish compared to AVR or 3.1 - depending on what you want to do.

How much could be done through documentation and samples and a model showing how to program well and not use delay() and cooperatively do what you can while waiting for what you need? This could make it 'simpler' learn and to do the right thing. The Teensy system of LIBS and HDW is awesome - but takes a good sample, deep dive into lib sources, or too often a reply on the forum:: GO WIKI!

Having good system support doesn't stop poor/uninformed programming from ruining it, or having an OS exert overt control can likewise ruin desired task completion through its own overhead.

Concurrency is a combination of the HDW (speed/resources) and the LIBS ( some do .available and some block ) and how it gets used/modeled to do it. My expectation is it would either force an unknown paradigm - or run out of resources trying.

Touching a couple interrupts doing much can throw off system timing, and bus I/O limits on throughput and meeting timing needs on special tasks (bit banging a VGA display versus HDW support). Where the HDW (serial or DMA mapped I/O) supports stuff it works now co-operatively when properly modeled, adding a background arbiter (OS) would change the way it works and then run out of steam somewhere else when the HDW or LIBS became the limiting factor - and would likely take a change from the Arduino programming model.

Maybe ship a MultiCore Teensy scheme : new MCU or a onehorse ESP8266 coprocessor or a Teensy Cluster API.
 
kpc said:
@Paul

Sorry if I missed the news. But I notice you are talking in past tense. Court case settled?
Click to expand...
I could also imagine the lawyer's saying if they didn't make the change, they would make themselves open to another attack (i.e. the lawyers being pro-active trying to prevent future problems).
 
How many of those listed releases were extended/only 'beta'? It seems Teensy support was 1.0.6 to 1.6.X - none of the 2015 IDE releases sat for 'beta'- unless it was 1.6.0 before Paul picked it up in Feb.
 
I've never published Teensy support for any 1.5.x version (the "beta" ones, where their website still recommended using the 1.0.x version).

I have published Teensy support for every other Arduino version since 0012. Well, except for 0020, which was replaced within just a few days by 0021, and only partially for 0014, which never got a Linux version and was also quickly replaced by 0015. Usually I've release a new Teensyduino installer within 1 week, and often within 1 day.
 
Last edited:
That says the recent supported Arduino history looks like this - which emphasizes your point on them being pushed/freed to 'release':

2011: 0023, 1.0
2012: 1.0.1, 1.0.2, 1.0.3
2013: 1.0.4, 1.0.5
2014: 1.0.6
2015: 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.4
 
Well besides removing changes about flagging arduino.org's boards, another change is support for the Adafruit/Arduino Gemma. Given Adafruit was starting to sell the boards on the day 1.6.4 came out, it may be the release was due to pragmatism and not lawyers (i.e. wanting customers to be able to run code when they got the boards).

I happened to watch the Adafruit Ask an Engineer video (8pm EST) that night, and they said they had sold out of the initial shipment before the ATE video aired. So maybe it was a sympathy order, where people wanted to send money to arduino.cc and figured to pick up an Gemma as well.

IMHO, removal of the code probably due to lawyers, but release date may have been tied to the Gemma.
 
Last edited:
My thought would be attempting a true RTOS in something that doesn't have a standalone clock to tie the functions to is always going to be excessively complex since every interrupt will be potentially loosing time while millis() isn't being handled.

For the work done in Arduino (not in proper IDEs by proper programers an the same CPUs) using blocking code will probably get people doing something fun quicker than layering on an OS. That said I'd really love to see the examples folder have blink, blink (basic state machine) and blink (interval timer) to expose the concept of not using 5 second delays in your code sooner.

What would be nice would be that compiler report saying how much flash being used also being expandable to report which on chip resources are in use by your code, and any libraries using the same peripheral. This of course would require a pile of code for every peripheral for every CPU. Sadly I suspect even with infinite money the time taken to get it working would be longer than the life cycle of the chips.
 
ippisl said:
Constantin, at which RTOS libraries have you looked(and was disappointed from) ?
Click to expand...

Apologies for the late reply. My main issue was the lack of good documentation that clearly illustrates how to get it set up followed by giving examples of running tasks with different priorities. However, my needs are specific and the issues also relate to hardware limitations... i.e. receiving ~1500 samples per second from a SPI device (MCP3910) while also periodically wanting to write to a SD card. Further complicating the issue, the SPI ADC I pulling data from has to deal with data where one signal is offset by about 2 reads from the other channel (~1.3ms). Thus, it's even more important to maintain a constant read cycle as the ADC pumps out new data.

In the end, I decided that it would be easier for me to implement a two processor solution that allows the SD card to have a dedicated bus, ditto for the power meter. The RTOS was simply too much effort to learn (and a suite of examples, etc. would be helpful) for the gain vs. the physical issues related to running multiple devices on the SPI bus when timing is important. Going to a two-processor solution costs a couple of extra bucks but allows the Master CPU to deal with whatever latency the SD card throws its way while the meter just focuses on gathering samples as consistently as it can.
 
many (most) avocational projects can be done without the overwhelming (to most hobby/student users) complexity and risks of a preemptive RTOS.
A set of state machines - make for a well planned and predictable run time instead of spaghetti code.
A run-to-completion task scheduler is the next least complicated.
FreeRTOS with its preemption disabled (a .h setting) - is a very good way to start on the Teensy.

With lots of experience, one can tackle a preemptive RTOS.
 
I vote for a hardware mux that can be switched by hardware (toggle switch or jumper or some such) - to allow ordinary SWO tools to be used.
Rather than adding to Paul's burdens the work to develop and sustain a flash breakpoint debugger. Or adapt a hack like OCD.
 
stevech , sure, state machines(or events like paul suggested) are relatively simple and a good idea.

But i think they are too complex for beginners. and to make the platform the easiest for beginners(which is clearly the goal of the arduino), they should be abstracted, and abstraction inside "chips"(like i wrote in the beginning) could work well.

So maybe code will be written using state machines/run-to-completion, but the end user will consume "chips" .
 
You must log in or register to reply here.
Back
Top