Scott wrote:
.........
>
>I think the level of "determinism" needs to be defined. In many applications, a
>timer interrupt can be used to trigger events that can then be processed by
>high-level C-code. I had an application like this to control a bank of 64
relays
>once. It just didn't need to be deterministic to the microsecond, 10's of
>milliseconds was good enough. That was written in C. If you need 10's of
>microseconds of resolution, then you'd be hard pressed to get determinism
out of
>C-compiler. You'd have to either resort to inline assembly and/or careful tune
>the way C-code is written.
>

Yeah, I think this is the answer. PIC and Scenix have been marketed
as having deterministic timing, in the sense that you could know
"exactly" how many cycles both your code and your interrupts will
take. This is converse to the std CISC processors, where the same
instruction can take vastly different #cycles, depending upon the
arguments and addressing modes.

With C, I think, you can only a priori "code" deterministic timing
if you know **exactly** how many asm instructions a C instruction
will compile into - which is probably much more trouble than is
worth thinking about.

Even if you can read the asm produced by the C, all you know is
what the compiler gave you, and you are not necessarily in
control of the output - plus you have to read the asm to tell
what you have anyways.

Trying to fine-tune the C to get the "desired" asm output sounds
like a losing proposition, for several reasons. And obviously,
using inline asm to get determinism is not coding in C.

C = determinism = I doubt it [polite form of NO!]

best regards,
- danM

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu