Searching \ for '[PIC]: REPOST: RTOS and C-compilers for 18C452' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'REPOST: RTOS and C-compilers for 18C452'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: REPOST: RTOS and C-compilers for 18C452'
2001\03\23@023433 by Kari Lehikko

flavicon
face
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


2001\03\23@081825 by Olin Lathrop

face picon face
> 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_OUTolinTakeThisOuTspamembedinc.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


2001\03\24@153627 by Andrew E. Kalman

flavicon
face
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}

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: .....aekKILLspamspam@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


2001\03\25@175732 by Olin Lathrop

face picon face
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, olinspamKILLspamembedinc.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.


2001\03\25@191438 by Andrew E. Kalman
flavicon
face
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.   .....aekKILLspamspam.....pumpkininc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\26@013407 by Kari Lehikko

flavicon
face
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_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


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