Searching \ for '[PIC] OS for PIC16' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'OS for PIC16'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] OS for PIC16'
2009\05\17@233138 by solarwind

picon face
Hey all. Does any of you know of an RTOS (or OS) for PIC16Fs? Preferably free.

-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\05\18@004048 by Xiaofan Chen

face picon face
On Mon, May 18, 2009 at 11:23 AM, solarwind <spam_OUTx.solarwind.xTakeThisOuTspamgmail.com> wrote:
> Hey all. Does any of you know of an RTOS (or OS) for PIC16Fs? Preferably free.
>

If you are willing to use PIC18, there are quite some.
www.microchip.com/forums/tm.aspx?m=381449
FreeRTOS is one of the free ones. PICOS18 is another.

There are some for the PIC16 but they are not free.

AN585 is from Microchip but I have never looked at it so I do not
know if it is good for you.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011105

--
Xiaofan http://mcuee.blogspot.com

2009\05\18@012152 by solarwind

picon face
On Mon, May 18, 2009 at 12:40 AM, Xiaofan Chen <.....xiaofancKILLspamspam@spam@gmail.com> wrote:
> If you are willing to use PIC18, there are quite some.
> www.microchip.com/forums/tm.aspx?m=381449
> FreeRTOS is one of the free ones. PICOS18 is another.
>
> There are some for the PIC16 but they are not free.
>
> AN585 is from Microchip but I have never looked at it so I do not
> know if it is good for you.
> http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011105

Thanks. I also found "salvo" which works on PIC 12 and 16 as well as
the higher end PICs. Seems to be popular in the PIC world.

2009\05\18@013915 by Vitaliy

flavicon
face
solarwind wrote:
> Hey all. Does any of you know of an RTOS (or OS) for PIC16Fs? Preferably
> free.

Why do you think you need an RTOS?

2009\05\18@014503 by solarwind

picon face
On Mon, May 18, 2009 at 1:38 AM, Vitaliy <spamspamKILLspammaksimov.org> wrote:
> Why do you think you need an RTOS?

Primarily so that my nodes can do multiple things at once such as poll
sensors, manage protocol, execute commands given by other nodes and so
on in a clean and timely fashion.

2009\05\18@032052 by Tamas Rudnai

face picon face
There is this VELOOS, never tried it myself though:
http://hutorny.in.ua/projects/pic/very-low-overhead-operating-system

Tamas


On Mon, May 18, 2009 at 4:23 AM, solarwind <.....x.solarwind.xKILLspamspam.....gmail.com> wrote:

> Hey all. Does any of you know of an RTOS (or OS) for PIC16Fs? Preferably
> free.
>
> -- [ solarwind ] -- http://solar-blogg.blogspot.com/
> -

2009\05\18@040510 by Jan-Erik Soderholm

face picon face
solarwind wrote:
> On Mon, May 18, 2009 at 1:38 AM, Vitaliy <EraseMEspamspam_OUTspamTakeThisOuTmaksimov.org> wrote:
>> Why do you think you need an RTOS?
>
> Primarily so that my nodes can do multiple things at once such as poll
> sensors, manage protocol, execute commands given by other nodes and so
> on in a clean and timely fashion.

Of course you do not *need* an RTOS to do that.
I'm not sure it actualy helps doing that (on an PIC16).
Besides, even an RTOS can't do more than one thing "at once"...

2009\05\18@053213 by Tamas Rudnai

face picon face
On Mon, May 18, 2009 at 9:05 AM, Jan-Erik Soderholm <
jan-erik.soderholmspamspam_OUTtelia.com> wrote:

> Besides, even an RTOS can't do more than one thing "at once"...
>

Of course, you have one core anyway. But it could help you to think as
threads were running parallel. It is just a different abstraction to
interrupts or polling methods on a non rtos system.

Like an event driven rtos 'thinks' that a change on a pin is an event when a
process has to be triggered to run. On a cooperative rtos the thread waits
for the pin change and till the thread is suspended. On a preemptive you can
poll the pin without suspending the thread (and the entire mcu) -- all of
them are doing the same basically with different way of thinking (and of
course of different overhead on it). One could help to approach a specific
problem better, the other one fits worse/better to many other related
functions. But of course there is no rtos that makes you possible to write a
firmware that was impossible on the bare silicon.

Tamas
--
http://www.mcuhobby.com

2009\05\18@073459 by Bruno L. Albrecht

picon face
why don't you try some state machines?

On Mon, May 18, 2009 at 6:32 AM, Tamas Rudnai <@spam@tamas.rudnaiKILLspamspamgmail.com>wrote:

{Quote hidden}

> -

2009\05\18@075300 by Isaac Marino Bavaresco

flavicon
face
solarwind escreveu:
> Hey all. Does any of you know of an RTOS (or OS) for PIC16Fs? Preferably free.
>  

Take a look at mine, *just* *perhaps* it may be useful:
<www.piclist.com/techref/member/IMB-yahoo-J86/SimpleRTOS.htm>
It is free and there is a (silly) example. It implements the very basic
task scheduling and simple mutexes.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\18@081202 by Byron Jeff

flavicon
face
On Mon, May 18, 2009 at 07:34:57AM -0400, Bruno L. Albrecht wrote:
> why don't you try some state machines?

A RTOS is supposed to make guarantees on the latency of processing a task
or an event.

The biggest problem with SW and all his question is that he never gives
sufficient background as to what he's doing to give the question meaningful
context.

There are CS and Engineering people here on the list that have decades of
experience and education that SW could leverage if he'd start asking the
right questions. Design isn't about tools and toys. It's about understand
what you need to get done, and how to leverage the available tools to do
it.

So whether it's a RTOS, or a state machine, or an event loop doesn't really
matter. Tell us what you are trying to accomplish and then the available
tools start to make more sense.

BAJ

{Quote hidden}

2009\05\22@144455 by Gerhard Fiedler

picon face
solarwind wrote:

>> Why do you think you need an RTOS?
>
> Primarily so that my nodes can do multiple things at once such as
> poll sensors, manage protocol, execute commands given by other nodes
> and so on in a clean and timely fashion.

On a PIC16, it is likely that any general-purpose RTOS will do this less
timely than the simpler techniques, because of the overhead the
general-purpose RTOS introduces.

Gerhard

2009\05\22@160237 by Isaac Marino Bavaresco

flavicon
face
Gerhard Fiedler escreveu:
> solarwind wrote:
>
>  
>>> Why do you think you need an RTOS?
>>>      
>> Primarily so that my nodes can do multiple things at once such as
>> poll sensors, manage protocol, execute commands given by other nodes
>> and so on in a clean and timely fashion.
>>    
>
> On a PIC16, it is likely that any general-purpose RTOS will do this less
> timely than the simpler techniques, because of the overhead the
> general-purpose RTOS introduces.
>
> Gerhard
>  

I have some old projects that use state machines (some projects use lots
of them).

Since I met FreeRTOS, I started using it and plan to use it in every
project in which  it may fit into the processor.

I am using it already for PIC18, dsPIC30 and dsPIC33 and I'm very
satisfied with the results.

State machines sometimes get too large and complicated, almost
unmaintainable. With a RTOS (preemptive or non-preemptive) you may
program in a more "normal" manner.
It also simplifies the migration of the code between different
processors and architectures. Unfortunately, the smaller families of PIC
cannot use a preemptive RTOS (or at least not in a useful manner).

Some projects I can build for embedded (PIC) or desktop (PC) systems,
using the same source code (only the basic access routines are
different). This speeds up the development cycle a lot, since I can
debug the code natively in the PC, and only now and then I build it for
the PIC for testing.

It is a fact that a RTOS takes up some resources of the processor, but
you can do a lot with FreeRTOS and a PIC18 with 3.8KB RAM.

The new Enhanced PIC16F will be able to run a preemptive RTOS, I am
curious to test it.


Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\22@172957 by solarwind

picon face
On Fri, May 22, 2009 at 4:02 PM, Isaac Marino Bavaresco
<TakeThisOuTisaacbavarescoEraseMEspamspam_OUTyahoo.com.br> wrote:
{Quote hidden}

Isaac, I've been trying and trying but unable to get FreeRTOS for
PIC18 to compile correctly. I need help, lol.

2009\05\24@091706 by M.L.

flavicon
face
On Fri, May 22, 2009 at 4:02 PM, Isaac Marino Bavaresco <
RemoveMEisaacbavarescospamTakeThisOuTyahoo.com.br> wrote:

>
> State machines sometimes get too large and complicated, almost
> unmaintainable. With a RTOS (preemptive or non-preemptive) you may
> program in a more "normal" manner.
> It also simplifies the migration of the code between different
> processors and architectures. Unfortunately, the smaller families of PIC
> cannot use a preemptive RTOS (or at least not in a useful manner).
>

I find state machines useful when you're interfacing with the user and you
have Menu A with options 1,2,3 which lead to sub-menus B, C, and D for
example - it's easy to encode this into a state machine with standard
structure.

State machines are very fundamental concepts and even if you don't think
you're using one you probably are. An "event loop" that checks for the
status of inputs and timers is checking the state of the system and reacting
accordingly.

I have not tried an RTOS on a PIC but I would like to, given a project of
necessity.
-
Martin

2009\05\24@103458 by Scott Dattalo

face
flavicon
face
M.L. (aka Martin) wrote:

> I have not tried an RTOS on a PIC but I would like to, given a project
of
> necessity.

Same for me...

Here's another way of restating the RTOS-like approaches others have been
making. In my experience, the 'tasks' generally fall into two categories:
High priority and Low priority. The high priority ones generally involve
asynchronous interrupts.

State machines can split a task in such away that the mixed priorities can
be interleaved. The semaphore and mutex paradigms from RTOS/multi-threaded
programming can then be applied. The tasks can then be interleaved in such
a way that the high priority processes get the CPU when needed. But, each
application is different...

The example that I like to give is a full-duplex communication interface.
Often times, communication interfaces have the highest priority. If so,
circular transmit and receive buffers can be shared between an interrupt
routine and a non-interrupt routine. The buffer pointers can be treated as
semaphores. For example, a receive buffer can have two pointers; one for
the interrupt routine and another for the non-interrupt routine. A
receiver interrupt can read data from the hardware and write it to the
circular buffer. The location written is determined by the pointer
maintained in the context of the interrupt routine. The non-interrupt code
has its own pointer. This code runs at a much slower rate (but fast enough
to ensure the buffer doesn't overflow). Each time it runs, it compares its
pointer to the interrupt routine's pointer. If they're different, then
there is data in the buffer that needs processing.

Of course, I'm skipping over details (like buffer overflow), but the
general point (which others have made better) is that like code reuse,
preemptive multitasking on an embedded processor is somewhat overrated.

Scott

2009\05\24@105333 by Isaac Marino Bavaresco

flavicon
face
M.L. escreveu:
> On Fri, May 22, 2009 at 4:02 PM, Isaac Marino Bavaresco <
> isaacbavarescoEraseMEspam.....yahoo.com.br> wrote:
>
>  
>> State machines sometimes get too large and complicated, almost
>> unmaintainable. With a RTOS (preemptive or non-preemptive) you may
>> program in a more "normal" manner.
>> It also simplifies the migration of the code between different
>> processors and architectures. Unfortunately, the smaller families of PIC
>> cannot use a preemptive RTOS (or at least not in a useful manner).
>>
>>    
>
> I find state machines useful when you're interfacing with the user and you
> have Menu A with options 1,2,3 which lead to sub-menus B, C, and D for
> example - it's easy to encode this into a state machine with standard
> structure.
>
>  

I use state machines a lot, the problem arises when they get large and
complicated.

> State machines are very fundamental concepts and even if you don't think
> you're using one you probably are. An "event loop" that checks for the
> status of inputs and timers is checking the state of the system and reacting
> accordingly.
>
> I have not tried an RTOS on a PIC but I would like to, given a project of
> necessity.
>  

Once you get used to one you will not want to stop.

> -
> Martin
>  


Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\24@112108 by olin piclist

face picon face
Scott Dattalo wrote:
> The example that I like to give is a full-duplex communication
> interface. Often times, communication interfaces have the highest
> priority. If so, circular transmit and receive buffers can be shared
> between an interrupt routine and a non-interrupt routine. The buffer
> pointers can be treated as semaphores. For example, a receive buffer
> can have two pointers; one for the interrupt routine and another for
> the non-interrupt routine. A receiver interrupt can read data from the
> hardware and write it to the circular buffer. The location written is
> determined by the pointer maintained in the context of the interrupt
> routine. The non-interrupt code has its own pointer. This code runs at
> a much slower rate (but fast enough to ensure the buffer doesn't
> overflow). Each time it runs, it compares its pointer to the interrupt
> routine's pointer. If they're different, then there is data in the
> buffer that needs processing.

I've done this too a bunch of times and have made the underlying code
available.  The FIFO_xxx macros in STD.INS.PAS that is part of my PIC
development environment (http://www.embedinc.com/pic) implement the kind of
queue Scott is talking about with the data layout details kept internal.
There are macros for writing a byte to the queue, reading a byte, and
various tests for queue full, empty, byte available, etc.

On a PIC 18 you can combine these with the basic task manager in the
QQQ_TASK.ASPIC template module to do the rest of what Scott described.  You
can write a subroutine in the task that checks the FIFO and calls TASK_YIELD
in a loop until a byte is available, then get the byte and return it.  As
Scott said, this splits the input stream interpreting code into high
priority in the interrupt routine and low priority to process the bytes in a
separate task.  I've done this a bunch of times and it works very nicely and
keeps the command stream interpretation code quite clean.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...