|
|
View previous topic :: View next topic |
Author |
Message |
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
Impressions of CCS RTOS in PIC-C |
Posted: Fri Mar 11, 2011 12:46 pm |
|
|
Hey there,
I was looking at the #USE RTOS again for something and was wondering what the various experiences people have had here using it.
Anyone do anything cool/reasonably big using the RTOS they thought had good outcomes versus something like an interrupt driven w/more free running environment?
Thanks,
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1909
|
|
Posted: Fri Mar 11, 2011 12:54 pm |
|
|
I haven't used the CCS RTOS but I have to support several projects that use the RTXC RTOS, but not on a PIC.
For things like user interfaces (many different "screens" on a graphical display) and handling button presses, a RTOS makes things a bit easier. However, getting down to the dirty details of reacting to fast events, messages (such as CAN messages), I find a RTOS makes that truly difficult. I'm uncovering issues that we thought were due to hardware that are actually weird race conditions caused by the RTOS.
A redesign of our system is on the books and I'm definitely turfing the RTOS approach. I frankly haven't seen anything that the RTOS does that can't be done in a traditional interrupt-driven approach. In fact, the RTOS tends to hide things under many layers of abstraction and is a real pain to troubleshoot, especially when you're dealing with 10 year old code which has been added to by 5 different individuals over the years.
I know this isn't the information you were looking for, but hopefully you find it relevant. |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Fri Mar 11, 2011 2:43 pm |
|
|
newguy wrote: | I haven't used the CCS RTOS but I have to support several projects that use the RTXC RTOS, but not on a PIC.
For things like user interfaces (many different "screens" on a graphical display) and handling button presses, a RTOS makes things a bit easier. However, getting down to the dirty details of reacting to fast events, messages (such as CAN messages), I find a RTOS makes that truly difficult. I'm uncovering issues that we thought were due to hardware that are actually weird race conditions caused by the RTOS.
A redesign of our system is on the books and I'm definitely turfing the RTOS approach. I frankly haven't seen anything that the RTOS does that can't be done in a traditional interrupt-driven approach. In fact, the RTOS tends to hide things under many layers of abstraction and is a real pain to troubleshoot, especially when you're dealing with 10 year old code which has been added to by 5 different individuals over the years.
I know this isn't the information you were looking for, but hopefully you find it relevant. |
Actually, this kind of comment is very useful - I'm dealing with a Rabbit right now and the RTOS is a little creepy... and so I was contemplating how it would translate to PIC because I'm finding I don't like DynamicC very much. They make some departures from regular C that I find a little inexcusable.
So, I asked because I'm wondering how well it would translate to CCS's RTOS as a fair comparison.
Of course, additional comments from others is welcome...
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|