Post by thread:[PIC]: REPOST: RTOS and C-compilers for 18C452

I will repost this, as there were a typo in the topic tag. If you have already received this, please discard this now. I'll try to be more punctual in the future. - K - Hi all, Recently it has become clear that I must write a real-time OS to enhance one of our existing products. The product was orginally designed for 16C77 and now we are using 18C452. We have considered about re-designing to Atmel ATmega103, but we would lose the possibility to upgrade the old, already sold equipment. Now I am asking if anyone has any axperience in writing RTOS to 18C452. Biggest problem seems to be finding a C-compiler that can be used to build a RTOS. If any of you has used any C-compiler and managed to build a true pre-emptive RTOS with it, I would appreciate much if you could share the information. I have now looked at Hitech's compiler, IAR's compiler and Microchip's compiler. From these three Microchip is the most promising. Is there any other compilers available? Thanks in advance, Kari Lehikko (Mr) Software Designer H.Vesala Ltd. Finland -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> Now I am asking if anyone has any axperience in writing RTOS to 18C452. > Biggest problem seems to be finding a C-compiler that can be used to > build a RTOS. This is exactly the kind of code where you don't want a compiler between you and the machine. It may be fine to write the application in C on the RTOS, but I certainly wouldn't want to see critical parts of the RTOS written in anything but assembler. When you are writing an RTOS, you have to assume that the task switching code is both speed and space critical. You also have to perform some fancy stack diddling which would confuse most compilers. Since you want a pre-emptive RTOS, a lot of the task switching code will be in the interrupt routine. This is even more reason to write it in assembler. Are you really sure you need a pre-emptive RTOS? Is it really that hard to break your tasks into "small" chunks of no-wait code? Pre-emptive can look like the more elegant solution, but adds more overhead and trouble than you may realize. The big gotcha is that any thread has to be prepared to be swapped out at any time. This means you either need to disable task swithing during critical parts or add interlocks around global state. I've done a lot of embedded system designs (It's what I do for a living). While I have used multiple tasks or pseudo-tasks (can't do real tasks on PICs other than 18 family, for example) many times, I have never yet needed to do pre-emptive task swithing on a small resource-limited system. ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, spam_OUTolinTakeThisOuTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Re: >This is exactly the kind of code where you don't want a compiler between you >and the machine. It may be fine to write the application in C on the RTOS, >but I certainly wouldn't want to see critical parts of the RTOS written in >anything but assembler. When you are writing an RTOS, you have to assume >that the task switching code is both speed and space critical. You also >have to perform some fancy stack diddling which would confuse most >compilers. Since you want a pre-emptive RTOS, a lot of the task switching >code will be in the interrupt routine. This is even more reason to write it >in assembler. As a data point, Salvo on a PIC16C77 doing fully priority-and event-based cooperative multitasking context-switches at around 2500 context switches/sec with a 4MHz crystal / 1us instruction cycle. That's written entirely in C. I suspect the performance would improve to about 3000/sec if it were written in assembler. This is Salvo's Demo #1, available in hex form for programming into a PIC16C77 or equivalent in the freeware download from our website. {Quote hidden}>Are you really sure you need a pre-emptive RTOS? Is it really that hard to >break your tasks into "small" chunks of no-wait code? Pre-emptive can look >like the more elegant solution, but adds more overhead and trouble than you >may realize. The big gotcha is that any thread has to be prepared to be >swapped out at any time. This means you either need to disable task >swithing during critical parts or add interlocks around global state. > >I've done a lot of embedded system designs (It's what I do for a living). >While I have used multiple tasks or pseudo-tasks (can't do real tasks on >PICs other than 18 family, for example) many times, I have never yet needed >to do pre-emptive task swithing on a small resource-limited system. Yes, it's pretty astonishing what you can do in a cooperative system. For highest performance, you do need to perhaps tailor your tasks to ensure minimal latency for higher-priority tasks, but for many PICmicro apps we're seeing, it's not an issue. Check out our website for more info. -- ______________________________________ Andrew E. Kalman, Ph.D. Salvo(TM), The RTOS that runs in tiny places(TM) Pumpkin, Inc. 750 Naples Street San Francisco, CA 94112 tel: (415) 584-6360 fax: (415) 585-7948 web: http://www.pumpkininc.com email: .....aekKILLspam@spam@pumpkininc.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

In response to: > Andrew E. Kalman, Ph.D. > Salvo(TM), The RTOS that runs in tiny places(TM) > As a data point, Salvo on a PIC16C77 doing fully priority-and > event-based cooperative multitasking context-switches at around 2500 > context switches/sec with a 4MHz crystal / 1us instruction cycle. > That's written entirely in C. I didn't say it wasn't possible, only that it was not a good idea. Your own statement confirms this if I understand it right. I assume by 2500 context switches you mean that the tasks are doing nothing but immediately yeilding the processor to the next task. If so, that means it takes Salvo 400 instruction cycles to switch between tasks. This sounds VERY high. I have occasionally used macros for this on the 16C family, and I doubt they even take 40 instructions. I imagine this huge discrepancy comes from the fact that you are writing a general RTOS that has to be ready for anything, whereas my macros do just what I need them to and otherwise get out of the way as quickly as possible. What this really points out is the absurdity of trying to use an RTOS on processors like the 16xxx PIC family. Your statement "fully priority-and event-based cooperative multitasking context-switches" might leave some people with the wrong impression. Since the software can't access the stack on the 16xxx family, there must be some restrictions on your tasks. I imagine you can't "call" YIELD inside a subroutine, right? Or do you get around the stack access problem in a different way that results in different restritions? ******************************************************************** Olin Lathrop, embedded systems consultant in Littleton Massachusetts (978) 742-9014, olinKILLspamembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Olin Lathrop wrote: >I didn't say it wasn't possible, only that it was not a good idea. Your own >statement confirms this if I understand it right. I assume by 2500 context >switches you mean that the tasks are doing nothing but immediately yeilding >the processor to the next task. If so, that means it takes Salvo 400 >instruction cycles to switch between tasks. This sounds VERY high. I have >occasionally used macros for this on the 16C family, and I doubt they even >take 40 instructions. Your assumptions are somewhat correct -- here are the corrections: 1) The demo is for the base Salvo version, which uses priority queues to manage tasks. For 8 tasks doing real work (not just immediately yielding, but most of the tasks are waiting on an event or are delayed or timed out, so they don't, on average, use up too many extraneous cycles that would affect the context-switching rate), yep, the number is around 400 instructions. Salvo can also be configured to use priority arrays, in which case the numbers drop to around 120-160 cycles independent of the number of tasks. The maximum amount of time that interrupts are disabled is roughly half that. 2) I too, can write ASM or C code to make "tasks" "context switch" in 40 cycles. But not when I'm supporting priorities, multiple task states (waiting, delayed, stopped, eligible, timed out, etc.). We're talking apples and oranges here. The point of Salvo is to bring a high-level programmer's toolset (C, RTOS, integrated development environment) into the realm of the PIC in order to reduce time-to-market. >I imagine this huge discrepancy comes from the fact that you are writing a >general RTOS that has to be ready for anything, whereas my macros do just >what I need them to and otherwise get out of the way as quickly as possible. Absolutely. We wrote Salvo for the general case, and it's turning out to be extremely applicable across the board. >What this really points out is the absurdity of trying to use an RTOS on >processors like the 16xxx PIC family. Hardly -- in fact, just the opposite. But I'll let Salvo users and the chip manufacturers and tool vendors who have taken a keen interest in Salvo speak to this point. See us at ESC2001 West. As before, we'll be in the HI-TECH booth. >Your statement "fully priority-and event-based cooperative multitasking >context-switches" might leave some people with the wrong impression. Why? It does exactly what it says. And while some may take issue with "context-switch" vs. "task switch", in the case of the PIC and Salvo they are one and the same, as the PIC's context is so little (W, PCLATH, FSR, STATUS) and is transparent to the (Salvo) user. >Since the software can't access the stack on the 16xxx family, there >must be some >restrictions on your tasks. I imagine you can't "call" YIELD inside a >subroutine, right? Or do you get around the stack access problem in a >different way that results in different restritions? You're exactly right -- tasks can only context-switch at the task level (due to the lack of a general-purpose software stack on the PIC12/PIC16/PIC17), and each task must context-switch at least once. There will always be applications where Salvo, and even C, simply can't be used because you're extracting every last micro-MIP out of a PIC at the slowest possible clock speed, and absolutely no overhead can be tolerated. There are many people on this list (you included, I presume) who are eminently capable of writing such code, and their skillset is impressive. But for the rest / majority of PIC programmers, without the years of assembly-level programming that you and I have, how you get the job done is often less important than how quickly you get it done, and how you can then leverage that time against your competition, etc. That is one of the more important things Salvo brings to the table. We've encountered substantial resistance to the notion of an RTOS running on a PIC. But after people see it in action, many turn 180 degrees and run with it, pleasantly surprised at how useful a tool Salvo is. Finally, I'll close with a recent customer "testimonial", and invite anyone who's read this far to visit our website, download the demo / freeware version, peruse or even read the whole manual, and contact Pumpkin with any questions. You will need a working C compiler (currently only HI-TECH PIC C). "The new application has a core of about half of the code from the old application. It took about 2 days to convert it to Salvo and modify it for the new hardware as well as add some new bits (cpu driven multiplexed LED display instead of character LCD). It took one day to get a build (should have taken 1 hour). It took just one day to get the code running on the new hardware. Now that's a LONG way short of 8 months!!! And it is shaping up to be lean and mean - 2k words sofar for 6 tasks and 6 events and only a few more tasks to add. Well done - I am impressed with Salvo sofar. The ability to standardize the way in which multitasking applications are written and structured is very appealing to me. It enables me to incorporate important extensions to standard methodology and conventions into my iso9001 procedures manual." I couldn't have said it better myself. I hope that this post has been within the acceptable posting standards for the PICList. Regards, -- ______________________________________ Andrew E. Kalman, Ph.D. .....aekKILLspam.....pumpkininc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Olin, > This is exactly the kind of code where you don't want a compiler between you > and the machine. It may be fine to write the application in C on the RTOS, > but I certainly wouldn't want to see critical parts of the RTOS written in > anything but assembler. When you are writing an RTOS, you have to assume > that the task switching code is both speed and space critical. You also > have to perform some fancy stack diddling which would confuse most > compilers. Since you want a pre-emptive RTOS, a lot of the task switching > code will be in the interrupt routine. This is even more reason to write it > in assembler. I agree that I would be better to write the kernel with an assembler. But if I want to use C in my application code, I would at least need a compiler that states clearly how to mix assembly and C, how is the stack used etc. I have now ordered IAR's EWPIC18, hopefully it can do the job. > Are you really sure you need a pre-emptive RTOS? Is it really that hard to > break your tasks into "small" chunks of no-wait code? Pre-emptive can look > like the more elegant solution, but adds more overhead and trouble than you > may realize. The big gotcha is that any thread has to be prepared to be > swapped out at any time. This means you either need to disable task > swithing during critical parts or add interlocks around global state. Yes, I have tried a couple of different ways of doing a co-operative RTOS, but I ran into large problems in certain areas in my application. I have already ported my application to ATmega103 and written an RTOS to it. But, as mentioned earlier my superiors are not willing to change the type of the processor in our telephone, so I'll have to stick with 16C77 compatibles. > I've done a lot of embedded system designs (It's what I do for a living). > While I have used multiple tasks or pseudo-tasks (can't do real tasks on > PICs other than 18 family, for example) many times, I have never yet needed > to do pre-emptive task swithing on a small resource-limited system. Well... I don't know what kind of designs does the company you work for do. I can assure you that the pre-emptive RTOS is really necessary here. Most of our competitors use 16-bit or 32-bit processors in their products. We use PIC. (Not my fault, the decision was made before I was hired :) Regards, Kari Lehikko -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body