--_003_53013DA75010603yahoocombr_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I started using state machines like that several years ago. After a while I moved to co-routines, that are the same thing written in a cleaner way using C macros (more on that later). They both are great, but have a lot of shortcomings, the main one is that as code grows in complexity things start to become complicated and unmanageable. The problem with S.M. and C-R is that you can only transfer control to a different S.M. or C-R from inside the body of the S.M. or C-R, not from a sub-routine. So, you cannot stay in a loop in a sub-routine waiting for something to happen because your whole system will stop responding. There are solutions for that also, but they are not straightforward and the code starts becoming too complex. S.M and C-R usually force you to write code that is less modularized and has long sequences of code repeated all over your S.M or C-R function because you cannot put that code in a sub-routine. That's why I am an enthusiastic supporter of RTOSes. For simple and small projects, perhaps code for a S.M. or C-R approach can be as simple and readable as for an RTOS, but when the size and complexity starts to grow, the RTOS code will be much simpler, modularized, readable and efficient. The main problem with RTOSes is that they use much more memory. More on co-routines: The old state machines can be made much more readable using some tricks, see the attached file. Best regards, Isaac Em 16/02/2014 16:54, Veronica Merryfield escreveu: > Martin > > You can do this simply with state machines. I use the following which has= a very small RAM impact. > > > In main > > char again; > > while (1) > { > again =3D 0; > > if (statemachine()) > again =3D 1; > > if (anotherstatemachine()) > again =3D 1; > > =85 > > if (!again) > sleep(); > } > > in each state machine=20 > > switch (state) > { > case STATE1: > return 1; > case STATE2 > break; > etc > } > return 0; > > > each state case does what is needed in short bursts and I use the again m= ethod to keep processing, so for instance, processing a serial data stream = would be done by repeated calls to the state machine until done. This also = allows the rest of the system to stay responsive. > > I use a lot of interrupt driven IO and a timer. The interrupts wake the s= ystem and that then triggers the main loop to run. Each interrupt does the = minimum needed and sets a flag. The state machines deal with the data based= on the flag. Mostly, I do not disable interrupts and I have a few lockless= constructs for things like serial fifos that let this happen. In my debug = code, I check if a flag is already set in the interrupt routines. > > I don=92t use release and debug builds but rather release the debug code.= I have learnt to mostly write code that an optimiser can=92t do much with.= Too many times I have had release code fail in some odd ways. I do use som= e extra monitoring code in my debug builds. > > The overhead per state machine is 1 byte + 1 byte in the main loop which = on a small ram device is a huge motivation.=20 > > I use a few rules in state design=20 > - if the code is bigger than one screen full in a state I push it out to = a function; this avoids loosing where you are in the whole state machine=20 > - if a few states have common code, use a function. Pass the state if nee= ded to change state progression > - use an enum for the state=20 > - prefer small amounts of code in each state and go again rather than usi= ng large states. This makes it easier to design and follow and leads to a r= esponsive system. > > > I have used this scheme many times. > > Veronica > > > On Feb 16, 2014, at 8:06 AM, Martin Klingensmith wrote= : > >> On 2/16/2014 8:21 AM, Isaac Marino Bavaresco wrote: >>> The PIC24 port is available at the page >>> >>> >>> And did I mention it is free and open source? >>> >>> >>> Ports for PIC24 and PIC32MX done. Now I will work on dsPIC, PIC32MZ >>> (hopefully Microchip release them within this year), PIC18, ARM >>> Cortex-M3 and ARM Cortex-M4. >>> >>> >>> Best regards, >>> >>> Isaac >>> >>> >> Isaac, >> Thank you for sharing your code. >> Personally I would be interested in a very basic round-robin non=20 >> preemptive cooperative tasking system. Basically you would setup tasks=20 >> and then each task would run until it calls taskyield(). Then the next=20 >> task would run. >> >> Is this something that your code can do? It looks like it has a lot of=20 >> features, though fewer than FreeRTOS. My issue with FreeRTOS is that the= =20 >> examples were very full of features. I didn't know where to start. >> >> - >> Martin >> --=20 >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist > --_003_53013DA75010603yahoocombr_ Content-Type: text/plain; name="C-R.c" Content-Description: C-R.c Content-Disposition: attachment; filename="C-R.c"; size=2655; creation-date="Sun, 16 Feb 2014 21:49:10 GMT"; modification-date="Sun, 16 Feb 2014 21:49:10 GMT" Content-Transfer-Encoding: base64 Lyo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ki8NCiNpbmNsdWRlIDxwaWMuaD4NCi8qPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PSovDQp2b2xhdGlsZSB1bnNpZ25lZCBsb25nIFN5c3RlbVRpY2sgPSAwOw0KLyo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ki8NCiNkZWZpbmUJVGFza1N0YXJ0KCkJc3RhdGljIGludCBfX1N0YXRl PTA7c3dpdGNoKF9fU3RhdGUpe2Nhc2UgMDoNCiNkZWZpbmUJVGFza0VuZCgpCX0NCiNkZWZpbmUJ WWllbGQoKQkJZG97X19TdGF0ZT1fX0xJTkVfXztyZXR1cm4gMDtjYXNlIF9fTElORV9fOjt9d2hp bGUoMCkNCiNkZWZpbmUJU2xlZXAodCkJZG97X19TdGF0ZT1fX0xJTkVfXztyZXR1cm4gKHQpO2Nh c2UgX19MSU5FX186O313aGlsZSgwKQ0KI2RlZmluZQlGaW5pc2goKQlkb3tyZXR1cm4gLTE7fXdo aWxlKDApDQovKj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0qLw0KDQojZGVmaW5lIE5VTV9UQVNLUwkyDQoN CnZvbGF0aWxlIGludCBhID0gMCwgYiA9IDA7DQoNCmludCBUYXNrMSggdm9pZCApDQoJew0KCS8v IERlY2xhcmUgYWxsIHZhcmlhYmxlcyBhcyBzdGF0aWMNCglzdGF0aWMgaW50IGk7DQoNCglUYXNr U3RhcnQoKTsNCg0KCXdoaWxlKCAxICkNCgkJew0KCQkvLyBEbyBzb21ldGhpbmcuLi4NCgkJWWll bGQoKTsNCgkJZm9yKCBpID0gMDsgaSA8IDEwOyBpKysgKQ0KCQkJew0KCQkJLy8gRG8gYW5vdGhl ciBzb21ldGhpbmcuLi4NCgkJCWErKzsNCgkJCVlpZWxkKCk7DQoJCQl9DQoJCS8vIEFuZCBzbyBv bi4uLg0KCQl9DQoNCglUYXNrRW5kKCk7DQoNCgkvLyBXaWxsIG5ldmVyIHJlYWNoIGhlcmUNCgly ZXR1cm4gLTE7DQoJfQ0KDQoNCmludCBUYXNrMiggdm9pZCApDQoJew0KCS8vIERlY2xhcmUgYWxs IHZhcmlhYmxlcyBhcyBzdGF0aWMNCglzdGF0aWMgaW50CWo7DQoNCglUYXNrU3RhcnQoKTsNCg0K CXdoaWxlKCAxICkNCgkJew0KCQkvLyBEbyBzb21ldGhpbmcuLi4NCgkJWWllbGQoKTsNCgkJZm9y KCBqID0gMDsgaiA8IDEwOyBqKysgKQ0KCQkJew0KCQkJLy8gRG8gYW5vdGhlciBzb21ldGhpbmcu Li4NCgkJCWIrKzsNCgkJCVlpZWxkKCk7DQoJCQl9DQoJCS8vIEFuZCBzbyBvbi4uLg0KCQlTbGVl cCggNSApOw0KCQl9DQoNCglUYXNrRW5kKCk7DQoNCgkvLyBXaWxsIG5ldmVyIHJlYWNoIGhlcmUN CglyZXR1cm4gLTE7DQoJfQ0KDQovKj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0qLw0KDQp2b2lkIGludGVy cnVwdCBJU1IoIHZvaWQgKQ0KCXsNCglpZiggVE1SMUlFICYmIFRNUjFJRiApDQoJCXsNCgkJVE1S MUlGCT0gMDsNCgkJU3lzdGVtVGljaysrOw0KCQl9DQoJLy8gU2VydmljZSBvdGhlciBpbnRlcnJ1 cHRzLi4uDQoJfQ0KDQovKj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0qLw0KDQp0eXBlZGVmIGludCAoKnRh c2twdHJfdCkoIHZvaWQgKTsNCg0KaW50CQkJVGFza3NTdGF0ZVtOVU1fVEFTS1NdCT0geyAwLCAw IH07DQp0YXNrcHRyX3QJVGFza3NbTlVNX1RBU0tTXQkJPSB7IFRhc2sxLCBUYXNrMiB9Ow0KDQov Kj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0qLw0KDQppbnQgbWFpbiggdm9pZCApDQoJew0KCXVuc2lnbmVk IGxvbmcJdDsNCglpbnQJCQkJaSA9IDA7DQoJaW50CQkJCXRlbXA7DQoNCgkvLyBJbml0aWFsaXpl IHRoaW5ncy4uLg0KCVRNUjEJPSAwOw0KCVRNUjFJRgk9IDA7DQoJVE1SMUlFCT0gMTsNCglQRUlF CT0gMTsNCglHSUUJCT0gMTsNCglUTVIxT04JPSAxOw0KDQoJd2hpbGUoIDEgKQ0KCQl7DQoJCWZv ciggaSA9IDA7IGkgPCBOVU1fVEFTS1M7IGkrKyApDQoJCQl7DQoJCQlDTFJXRFQoKTsNCgkJCUdJ RQk9IDA7DQoJCQl0CT0gU3lzdGVtVGljazsNCgkJCUdJRQk9IDE7DQoJCQkvLyBGSVhNRTogVGhp cyB0ZXN0IGlzIG5vdCBjb3JyZWN0LCBpdCB3aWxsIGJyZWFrIHdoZW4gU3lzdGVtVGljayBhcHBy b2FjaGVzIDB4ZmZmZmZmZmYNCgkJCWlmKCBUYXNrc1N0YXRlW2ldID49IDAgJiYgU3lzdGVtVGlj ayA+PSBUYXNrc1N0YXRlW2ldICkNCgkJCQl7DQoJCQkJdGVtcCA9IFRhc2tzW2ldKCk7DQoJCQkJ aWYoIHRlbXAgPiAwICkNCgkJCQkJVGFza3NTdGF0ZVtpXSA9IHRlbXAgKyB0Ow0KCQkJCWVsc2UN CgkJCQkJVGFza3NTdGF0ZVtpXSA9IHRlbXA7DQoJCQkJfQ0KCQkJfQkJICAgDQoJCX0NCgl9DQoN Ci8qPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PSovDQo= --_003_53013DA75010603yahoocombr_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=224; creation-date="Sun, 16 Feb 2014 21:49:10 GMT"; modification-date="Sun, 16 Feb 2014 21:49:10 GMT" Content-Transfer-Encoding: base64 LS0gDQpodHRwOi8vd3d3LnBpY2xpc3QuY29tL3RlY2hyZWYvcGljbGlzdCBQSUMvU1ggRkFRICYg bGlzdCBhcmNoaXZlDQpWaWV3L2NoYW5nZSB5b3VyIG1lbWJlcnNoaXAgb3B0aW9ucyBhdA0KaHR0 cDovL21haWxtYW4ubWl0LmVkdS9tYWlsbWFuL2xpc3RpbmZvL3BpY2xpc3QNCg== --_003_53013DA75010603yahoocombr_-- .