>Yeah, I think this is the answer. PIC and Scenix have been marketed
>as having deterministic timing, in the sense that you could know

"Easily determined" and "deterministic" are NOT identical.  I can easily write
non-deterministic code for which the timing is easily determined, and
deterministic code which can be very tedious to determine the cycle count w/o a
simulator or ICE.

>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.

True.  But who ever said that timing was the only thing we needed to know?

Who also ever said the it was a test of "strict C?"

>Andy, I think you painted yourself into a corner. With C, if you

I think we're arguing the definition of determinism here.  Deterministic means I
know it will arrive at an answer.  Not that it will always take the same amount
of time to get there - that's isochronicity (which is a special case of
determinism).  If we are talking about how long it will be before I detect an
event has occured, that's latency.

The kind of stuff I've been doing lately is more often easily done by handling
"interrupts" in the main loop, and handling the time-critical portions with an
ISR.

My two big constraints are

1) that the control algorithm (this is another model boat project) has finished
it's calculations in time before the data in the polled interrupts is OBE (using
CCP to catch both rising and falling edges of a servo pulse), and

2) the RB0 interrupt is captured with sufficient accuracy that I don't see more
than 1uS of jitter.

The deterministic behavior has to do with (1).  Latency is (2) and is
fortunately easily handled by a PIC with the appropriate interrupt enabled.  See
the difference?

>change just one instruction, the timing may be 10s of cycles different.
>This is not deterministic. Fiddling with the C, counting the #cycles

The FINAL CODE IS DETERMINISTIC THOUGH!

Determinism has to do with the FINAL PRODUCT, not EVERY ITERATION of source
code.  Although for us lazy, easily-bored humans, it is easier to guarantee time
constraints are met if minor source changes don't produce drastically different
generated code (which is entirely possible with C, as better optimizations may
become evident to the compiler system with different source input).

>in the assembler output, and iterating endlessly just doesn't seem
>especially elegant or efficient.

Dan, I'm getting so lazy that I often write the routine in C, and if I need it
to be in assembly I cut-and-paste until it's done (only one customer needs
assembly, and that's because he doesn't want to buy PICC).  FAR more efficient
than bottom-up assembly.  Plus I get the (debugged) C as comments for a bonus.

>Best to know both C and assembler, and use the latter when you
>need an exact number of cycles.

If you read an earlier post to Bob Ammerman, I said "The right tool for the
job."  I still stand by that.

>I think it's time to retract your initial statement that C can produce
>deterministic code - don't you think? [come'on , give up already - I
>need to do some work today - even if it is monday].

Please check a definition on determinism.  There's more than isochronicity that
we are talking about here.

Andy

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