next topic »

[Reply #30 on:]

Brig, while I find the (software) threads concept quite fascinating, after reading this (interesting) (forum) thread I still can't understand what is wrong about "polling" the RTC time inside loop().
If you want to practice with threads on the Arduino, fine. But if your main goal is use the Arduino to manage an acquarium, then do yourself a favor and totally forget about threads.
There is the excellent Time library, which maintains the current time either via millis() or communicating with an RTC clock via I2C. This is 99% transparent, i.e. you can code to it and switch back and forth from an RTC to a RTC-less sketch in no time.
It's an excellent choice for periodic tasks.
Other libraries exists in the Playground that are equally good, although not as complete.

HTH

[Reply #31 on:]

for didactic reasons I got used to the thread, and as long as this simple things I immediately use they natural ...

I repeat, my problem is a particular case, but should be seen in a wider range, where perhaps one can also do something nice ...
For example, alter the input from the numeric keypad (the phone), leaving a thread waiting on readChar even do a poll ... I find it more appropriate

and then repeat, not a problem, insert the line "RTC.refresh ()" it's just that I would rather not do it, because a programmer who uses my library can forget it, and before finding this little error... while if launch a thread that makes it alone, putting a mutex from Lokke on each access to the variables of RTC ... would be more simple and straightforward ...

personally if I had time, more knowledge of assembler and C more knowledge in general, I'll try to implement them willingly thread on arduino as good exercise!

[Reply #32 on:]

In general, the problem with multithreading on a small microcontroller like the AVR is that there is not enough RAM.  A complete process context (32 registers + PC + stack + stack pointer is probably over 100 bytes, and the atmega328 chip used on Arduino only has 2k total.

[Reply #33 on:]

May I suggest a couple of links:

DuinOS, a FreeRTOS port to the Arduino platform:

http://www.multiplo.org/duinos/wiki/index.php?title=Main_Page

The QP framework (you can find it in the Playground, too):

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

[Reply #34 on:]

And add to those 2, QNX which has been implemented on many much slower processors than the ATMEGA328 and which is running thousands of automatic machines of one kind or another in industry today. 

Other viable RTOS kernels have been implemented on processors from the 6502/6800 onwards. I even wrote one in 1980 that pretty much worked    And I wrote lots of EDX based code on Series/1 with only 64K of memory, in the same era.

The main points about 'threads' or 'tasks' like: "Threads, as a model of computation, are wildly nondeterministic" is an argument against nondeterministic coding, not threads.  This is exactly why the QP Framework is based on the idea that all threads MUST be Finite State Machines.  This is a concept that I was able to enforce (Oh, Um, technically lead?) in Semiconductor manufacturing in one IBM plant in the 1990's.. and it DID decrease the instances of "wildly nondeterministic" code.  Requiring that network communications interfaces to process equipment be documented as Finite State Machines was finally accepted practice.  One grudging response was "I think we wasted some time using (this method) but it did make debugging a lot easier".

That said, I DID write a communications protocol using the approach which seemed to work OK and went into production and after it was running on about 20 systems for a few months it became clear that it occasionally crashed.  Ugg... Finally my friend Tony Burke (Who I am glad to credit years later!!!) found the bug. 

So nothing is sacred and nothing is perfectly error free. 

In a similar way, Proof is in the nontrivial application running clean for 1000 hours. Anyone writing some QP FRamework stuff on the free Arduino version?  I HOPE to get some time on this even though I should be writing other stuff.  "But Mom, I LOVE writing RTOS stuff    it's SO cool." And the .NET guys and the IphoneAPP guys don't know WHAT the hell you're even talking about...

[Reply #35 on:]

QNX which has been implemented on many much slower processors than the ATMEGA328

How do you figure?  I thought the smallest thing QNX ran on was a relatively good-sized x86?
In any case, "slow" isn't the problem.  RAM is the problem.  There are lots of nice multitasking systems that run fine on a system with 256K of RAM, but will have big problems on a system with 256K of flash and 8k of RAM...

[Reply #36 on:]

QNX which has been implemented on many much slower processors than the ATMEGA328

How do you figure?  I thought the smallest thing QNX ran on was a relatively good-sized x86?

Maybe I'm older than you 

Today QNX is supported on ARM, PowerPC and X86 etc, and now on the Blackberry Tablet     

But 25 years ago QNX did run on some of the earlier microprocessors that existed then. I'll try to find a reference, other than my recall of semiconductor process equipment running it...

Modern QNX has features that could never be supported on machines with very limited memory... 

But the QP framework has working examples running on Arduino, so they have some stuff figured out for 2011.

I'd mainly like to see some set of known solutions for Arduino beginners to start to encounter apparent concurrency without going back to school to learn about interrupt latency and directed graphs.

[Reply #37 on:]

We used QNX for building control on a 6809-based computer in the 80s, I don't remember the details but it's probably fair to say it had 64k RAM.

One assumes though that QNX has gone the bloatware track like everything else.
______
Rob

[Reply #38 on:]

Ah, the old 6809. I like the Wikipedia article about it, in particular the HCF instruction (Halt and Catch Fire).

http://en.wikipedia.org/wiki/Halt_and_Catch_Fire

I don't suppose the Atmega has one of those?

[Reply #39 on:]

We used QNX for building control on a 6809-based computer in the 80s, I don't remember the details but it's probably fair to say it had 64k RAM.
...

Thanks for validating that my personal memory is still retrieving!   Hadda be someone associated with "Gray", I guess..

[Reply #40 on:]

And then there was XPR (eXecute PRogrammer) LDN (LoaD Nothing) and a lot of other funny ones around a few years ago.

______
Rob

[Reply #41 on:]

Here's a comparisons of RTOS possibilities for Arduino: http://www.out--there.com/blog/rtos-for-arduino/

[Reply #42 on:]

And then there was XPR (eXecute PRogrammer)

My personal favourite was the PowerPC's EIEIO instruction

[Reply #43 on:]

That was on the Old MacDonald variant of that processor wasn't it?

______
Rob

[Reply #44 on:]

My personal favourite was the PowerPC's EIEIO instruction

So you are not referring to:

A "computer bought the farm" message is an error message displayed on GNU Hurd when one of the servers that provide kernel-like functions reaches a "hopeless" situation (after which it is usually terminated). This is a rough equivalent of a kernel panic in monolithic Unix-like kernels. Its corresponding error code is the Hurd-specific EIEIO, a reference to the folk song Old McDonald Had a Farm.

But rather:

Enforce In-Order Execution of I/O is an assembly language instruction used on the PowerPC computer processor used to prevent one memory or I/O operation from starting until the previous memory or I/O operation completed.

So, "do things in the order I tell you to"?