Post by thread:[PIC]: Sine table

Hi Andy: It's is interesting in that we all do it: bring sophisticated tools to simple problems. It is hard to do but we need to try to remember to set back and think of simple solutions to problems. Saw some of the responses. Liked the "use the spread sheet." This tread reminded me of a book on design: The Design of Everyday Things. Can't remember of author. He said he wrote the book because he was tired of working with products - of all kinds - without a simple interface - one that you can "look at and deduce proper operation" - for example the design of the pattern of burners on a stove and the associated design of the panel of switches. My GE at home is a loser! Ha. Have a good weekend. Phil Anderson. On Friday, August 18, 2000 12:30 PM, Andrew Kunz [SMTP:spam_OUTakunzTakeThisOuTTDIPOWER.COM] wrote: {Quote hidden}> Thanks. I don't know what I was (not) thinking. > > I got it done on my PC with MSVC. > > THanks anyway. > > Andy > > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

Phil Anderson wrote: ........ >This tread reminded me of a book on design: The Design of Everyday Things. >Can't remember of author. He said he wrote the book because he was tired of >working with products - of all kinds - without a simple interface - one >that you can "look at and deduce proper operation" - for example the design >of the pattern of burners on a stove and the associated design of the panel >of switches. My GE at home is a loser! Ha. > author = Donald A. Norman - too bad the guys who designed the insipid flashing 12:00 on the VCR machine never read the book. And note - after 10 years, I still don't know how to set the digital clock on my [used] car radio. - danM -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

Simon Nield wrote: > > Try using Excel or some other spread sheet to give you n values for the first pi/2, export is as a > text file and then paste in some retlws ? > add a couple of lines of code to invert and add 1 to the result when neccessary and Bob's your > mother's brother. > > Simon > > p.s. it's the weekend. phew! > > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements Use the DT table maker. Copy the column of data to the clipboard, paste into DT, press a button and presto, a table of RETLW or DT type instructions is created ready for saving or pasting directly into code. http://www.picnpoke.com/demo/dtimg.html -- Best regards Tony ICmicro's http://www.picnpoke.com .....salesKILLspam@spam@picnpoke.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

So who uses assembly any more? I do almost everything in C. Andy "Alan B. Pearce" <A.B.PearceKILLspamRL.AC.UK> on 08/19/2000 06:13:26 AM Please respond to pic microcontroller discussion list <.....PICLISTKILLspam.....MITVMA.MIT.EDU> To: EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Sine table >export is as a >text file and then paste in some retlws ? you could probably have a column of Retlw in excel so it gets included in the export. It is some time since I tried to do a CSV export from excel, so cannot remember if you can tell it to use spaces instead of commas. -- 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 -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspam_OUTmitvma.mit.edu>

Well said Andy! -----Original Message----- From: Andrew Kunz [@spam@akunzKILLspamTDIPOWER.COM] Sent: Monday, August 21, 2000 1:26 PM To: KILLspamPICLISTKILLspamMITVMA.MIT.EDU Subject: Re: [PIC]: Sine table So who uses assembly any more? I do almost everything in C. Andy "Alan B. Pearce" <RemoveMEA.B.PearceTakeThisOuTRL.AC.UK> on 08/19/2000 06:13:26 AM Please respond to pic microcontroller discussion list <spamBeGonePICLISTspamBeGoneMITVMA.MIT.EDU> To: TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Sine table >export is as a >text file and then paste in some retlws ? you could probably have a column of Retlw in excel so it gets included in the export. It is some time since I tried to do a CSV export from excel, so cannot remember if you can tell it to use spaces instead of commas. -- 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 -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseME.....mitvma.mit.edu>

On Mon, 21 Aug 2000, Bob Ammerman wrote: > At the risk of starting a flame war... > > Real (wo)men code in assembly (or if they are extra tough, binary) :-) > > > Just kidding of course. Both asm and "C" have their place. For typical > applications "C" is fine, but when you are trying to get the most possible > function out of the least possible hardware, you can't beat asm. (see my sig > line to figure out where I prefer to be). True. If you need a slow sine, then fine. If you need a fast one then Eric's 6-cycle one can not be beat by any C-compiler (except those that support in-line assembly). Scott -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestEraseMEEraseMEmitvma.mit.edu>

I need to generate a 48-63 Hz sine as part of a PLL for a power system (sync the output to the line, slightly out of phase due to the power-generation lag time). I have LOTS of time to make it do it's thing. Andy Scott Dattalo <RemoveMEscottTakeThisOuTspamDATTALO.COM> on 08/21/2000 09:42:11 AM Please respond to pic microcontroller discussion list <EraseMEPICLISTspamspamBeGoneMITVMA.MIT.EDU> To: RemoveMEPICLISTKILLspamMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Sine table On Mon, 21 Aug 2000, Bob Ammerman wrote: > At the risk of starting a flame war... > > Real (wo)men code in assembly (or if they are extra tough, binary) :-) > > > Just kidding of course. Both asm and "C" have their place. For typical > applications "C" is fine, but when you are trying to get the most possible > function out of the least possible hardware, you can't beat asm. (see my sig > line to figure out where I prefer to be). True. If you need a slow sine, then fine. If you need a fast one then Eric's 6-cycle one can not be beat by any C-compiler (except those that support in-line assembly). Scott -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestSTOPspamspam_OUTmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestSTOPspamEraseMEmitvma.mit.edu>

Thanks, Scott. That'll be interesting reading. I'm working the PLL from the angle of changing time between steps rather than amplitude in order to keep phase locked (my only input is a zero-crossing detector). I also have to generate multiple waves, since I'm generating "real" power not just a 110V household socket. Andy Scott Dattalo <EraseMEscottEraseMEDATTALO.COM> on 08/21/2000 10:20:51 AM Please respond to pic microcontroller discussion list <@spam@PICLIST@spam@spam_OUTMITVMA.MIT.EDU> To: spamBeGonePICLISTKILLspamMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Sine table On Mon, 21 Aug 2000, Andrew Kunz wrote: > I need to generate a 48-63 Hz sine as part of a PLL for a power system (sync the > output to the line, slightly out of phase due to the power-generation lag time). > I have LOTS of time to make it do it's thing. That's the kind of thing I wrote this for: http://www.dattalo.com/technical/software/pic/picsine.html The phase accumulators can be directly fed from a PLL. Scott ps. Beware, it's overly commented :). -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestspam_OUTmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-request.....TakeThisOuTmitvma.mit.edu>

And it's *obvious* to the programmer what it is? At 10:35 AM 08/21/2000 -0400, you wrote: {Quote hidden}>Yes. > >Andy > > > > > > > > >Dan Michaels <RemoveMEoricomEraseMEspam_OUTLYNX.SNI.NET> on 08/21/2000 10:32:40 AM > >Please respond to pic microcontroller discussion list <@spam@PICLISTRemoveMEEraseMEMITVMA.MIT.EDU> > > > > > > > > > To: EraseMEPICLIST@spam@MITVMA.MIT.EDU > > cc: (bcc: Andrew Kunz/TDI_NOTES) > > > > Subject: Re: [PIC]: Sine table > > > > > > > > >At 07:26 AM 08/21/2000 -0400, you wrote: >>So who uses assembly any more? I do almost everything in C. >> >>Andy >> > >Can you get **reliable** deterministic timing in C? > >-- >http://www.piclist.com hint: To leave the PICList >@spam@piclist-unsubscribe-requestspam_OUT.....mitvma.mit.edu > >-- >http://www.piclist.com hint: To leave the PICList >spamBeGonepiclist-unsubscribe-requestEraseMEmitvma.mit.edu > > -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspamBeGonemitvma.mit.edu>

Let me re-issue: And it's *obvious* to the programmer what it is? How can you tell *exactly* how many cycles a routine takes without looking at the assembly code? At 10:35 AM 08/21/2000 -0400, you wrote: {Quote hidden}>Yes. > >Andy > > > > > > > > >Dan Michaels <.....oricom@spam@EraseMELYNX.SNI.NET> on 08/21/2000 10:32:40 AM > >Please respond to pic microcontroller discussion list <.....PICLISTRemoveMEMITVMA.MIT.EDU> > > > > > > > > > To: .....PICLISTSTOPspam@spam@MITVMA.MIT.EDU > > cc: (bcc: Andrew Kunz/TDI_NOTES) > > > > Subject: Re: [PIC]: Sine table > > > > > > > > >At 07:26 AM 08/21/2000 -0400, you wrote: >>So who uses assembly any more? I do almost everything in C. >> >>Andy >> > >Can you get **reliable** deterministic timing in C? > >-- >http://www.piclist.com hint: To leave the PICList >piclist-unsubscribe-requestEraseME@spam@mitvma.mit.edu > >-- >http://www.piclist.com hint: To leave the PICList >RemoveMEpiclist-unsubscribe-requestspamBeGonemitvma.mit.edu > > -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu>

On Mon, 21 Aug 2000, Andrew Kunz wrote: > Thanks, Scott. > > That'll be interesting reading. I'm working the PLL from the angle of changing > time between steps rather than amplitude in order to keep phase locked (my only > input is a zero-crossing detector). I also have to generate multiple waves, > since I'm generating "real" power not just a 110V household socket. Perhaps, however I don't discuss the PLL part of it at all. I'm not sure how your system is implemented. On one design I had to phase lock to a ~50-60 power sine wave too. I found that zero-crossing information was unreliable. The reason was that this was part of a power quality instrument and (almost) by definition the "sine wave" is suspect. The jitter in zero crossing could be very large. So instead, I wrote a single frequency 'DFT'. In other words, I did something like this: Assume f = f0 for one cycle's worth (delta t = 1/f) of sine wave samples compute the quadrature components: sine_power = sum of (sine samples * sin(t*i)) cosine_power = sum of (sine samples * cos(t*i)) In other words, the integral of the unknown waveform multiplied by sine and cosine functions was computed. You may also view this as two narrow FIR band pass filters center about the frequency 'f'. Now you can find the arc tangent of the ratio: phase ~= arctan(sine_power/cosine_power) to find the phase. This can then server as the control input to a PID algorithm. The control output of course being the frequency. A simple proportional algorithm could go something like: If the phase is positive decrease the frequency slightly else increase the frequency slightly But beware, this can (will) have trouble locking. At the minimum, you'll need a little part of 'D' in PID. As you might expect, computing the division and then following that by arctan is expensive (but doable...). So instead, I might suggest using the raw sine_power and cosine_power terms. You may be lucky to just get away with only the sine_power term. However, if your sine wave amplitude varies then the cosine computation can help normalize the calculation. Scott -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspam_OUT@spam@mitvma.mit.edu>

I'm not trying to be obtuse, but YES, you pad it. Andy Dan Michaels <spamBeGoneoricomspam_OUTRemoveMELYNX.SNI.NET> on 08/21/2000 11:02:35 AM Please respond to pic microcontroller discussion list <.....PICLISTRemoveMEMITVMA.MIT.EDU> To: PICLIST@spam@MITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Sine table At 10:45 AM 08/21/2000 -0400, you wrote: {Quote hidden}>Sorry, forgot to add a wink ;-) > >I use interrupts for long-period stuff (like the period between steps for my >sine generation). When I need short items, I pad with NOPs and delay loops >(inline assembly works great). > >Essentially the same way as with assembly code, just easier to comprehend. > >Andy > This is how you get deterministic timing in C - by using inline assembly? [guess it's difficult to get a straight answer on a monday morning]. - danM -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestRemoveMESTOPspammitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestKILLspamTakeThisOuTmitvma.mit.edu>

Duh - just can't this follow this on monday morning. At 11:08 AM 08/21/2000 -0400, you wrote: {Quote hidden}>I'm not trying to be obtuse, but YES, you pad it. > >Andy > > > > > > > > > > >Dan Michaels <spamBeGoneoricom@spam@LYNX.SNI.NET> on 08/21/2000 11:02:35 AM > >Please respond to pic microcontroller discussion list <RemoveMEPICLISTspam_OUTMITVMA.MIT.EDU> > > > > > > > > > To: PICLISTspamMITVMA.MIT.EDU > > cc: (bcc: Andrew Kunz/TDI_NOTES) > > > > Subject: Re: [PIC]: Sine table > > > > > > > > >At 10:45 AM 08/21/2000 -0400, you wrote: >>Sorry, forgot to add a wink ;-) >> >>I use interrupts for long-period stuff (like the period between steps for my >>sine generation). When I need short items, I pad with NOPs and delay loops >>(inline assembly works great). >> >>Essentially the same way as with assembly code, just easier to comprehend. >> >>Andy >> > >This is how you get deterministic timing in C - by using inline assembly? >[guess it's difficult to get a straight answer on a monday morning]. > >- danM > >-- >http://www.piclist.com hint: To leave the PICList >spam_OUTpiclist-unsubscribe-requestspam_OUTspam_OUTmitvma.mit.edu > >-- >http://www.piclist.com hint: To leave the PICList >piclist-unsubscribe-requestspam_OUTmitvma.mit.edu > > -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu>

At 11:05 AM 08/21/2000 -0400, you wrote: >>And it's *obvious* to the programmer what it is? >> >>How can you tell *exactly* how many cycles a routine takes >>without looking at the assembly code? > >I said I don't WRITE much assembly code, but I still READ it! > >The HiTech C compiler gives you the C with the assembly that it generates in the >.AS file. > >Andy > Ahh, so. "Deterministic timing" is whatever the compiler **gives** you, whether it gives 10 cycles to code a loop, or 25 - whether a C instruction gets coded into 1 cycle or 8. Slowly it's coming across. best regards, - danM -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspamBeGone.....mitvma.mit.edu>

On Mon, 21 Aug 2000, Dan Michaels wrote: > At 11:05 AM 08/21/2000 -0400, you wrote: > >>And it's *obvious* to the programmer what it is? > >> > >>How can you tell *exactly* how many cycles a routine takes > >>without looking at the assembly code? > > > >I said I don't WRITE much assembly code, but I still READ it! > > > >The HiTech C compiler gives you the C with the assembly that it generates > in the > >.AS file. > > > >Andy > > > > Ahh, so. "Deterministic timing" is whatever the compiler **gives** you, > whether it gives 10 cycles to code a loop, or 25 - whether a C instruction > gets coded into 1 cycle or 8. Slowly it's coming across. 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. Scott -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-request.....mitvma.mit.edu>

>Ahh, so. "Deterministic timing" is whatever the compiler **gives** you, >whether it gives 10 cycles to code a loop, or 25 - whether a C instruction >gets coded into 1 cycle or 8. Slowly it's coming across. Maybe the definition of "determinism" is the problem. It simply means that I know ahead of time how long something takes, whether 5 or 50 cycles (or 6/51 in certain cases). It means nothing about the identical timing of some routine(s). If I need to make something ALWAYS take the same amount of time, I adjust the generated code so it does. That is a special case of determinism. Deterministic behavior means it will always come to a (correct) answer. It can also have time limitations added to it if you like. Andy -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestKILLspammitvma.mit.edu>

Still doing everything in assembly... Harold On Mon, 21 Aug 2000 07:26:07 -0400 Andrew Kunz <RemoveMEakunzRemoveMEEraseMETDIPOWER.COM> writes: > So who uses assembly any more? I do almost everything in C. > > Andy > FCC Rules Online at http://hallikainen.com/FccRules Lighting control for theatre and television at http://www.dovesystems.com ________________________________________________________________ YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: dl.http://www.juno.com/get/tagj. -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestspamBeGonemitvma.mit.edu>

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 piclist-unsubscribe-requestspammitvma.mit.edu>

AndyK wrote: >>Ahh, so. "Deterministic timing" is whatever the compiler **gives** you, >>whether it gives 10 cycles to code a loop, or 25 - whether a C instruction >>gets coded into 1 cycle or 8. Slowly it's coming across. > > >Maybe the definition of "determinism" is the problem. It simply means that I >know ahead of time how long something takes, whether 5 or 50 cycles (or 6/51 in >certain cases). > >It means nothing about the identical timing of some routine(s). > >If I need to make something ALWAYS take the same amount of time, I adjust the >generated code so it does. That is a special case of determinism. > >Deterministic behavior means it will always come to a (correct) answer. It can >also have time limitations added to it if you like. > Andy, I think you painted yourself into a corner. With C, if you change just one instruction, the timing may be 10s of cycles different. This is not deterministic. Fiddling with the C, counting the #cycles in the assembler output, and iterating endlessly just doesn't seem especially elegant or efficient. Best to know both C and assembler, and use the latter when you need an exact number of cycles. 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]. cheers, - danM -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestspamBeGonemitvma.mit.edu>

> -----Original Message----- > From: Dan Michaels [SMTP:@spam@oricomSTOPspam@spam@LYNX.SNI.NET] > Sent: Monday, August 21, 2000 5:01 PM > To: PICLISTspamBeGonespamBeGoneMITVMA.MIT.EDU > Subject: Re: [PIC]: Sine table > > 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!] > With the majority of real time applications, only a relatively small part of the code is critical. The beauty of C is that the rest of the code can be written quickly and reasonably efficiently, and time critical sections can be written in ASM. OK, this loses (or at least reduces) the portability of the code, but to be honest, how often do you port your washing machines controller code to your cars ECU? :o) You *can* write deterministic code in C, but you could be shooting yourself in the foot as it is quite likely to be more difficult and time consuming than using ASM (e.g. having to refer to the compilers ASM listing and then tweaking the C code). You seem to be a little "anti-C"? If you work in a market where time to market is probably the single most important factor, then you'd really see the benefits. Mike -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestmitvma.mit.edu>

>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]. Actually I suspect this is just the same method as an assembler programmer uses to tweak the execution time. It may be that there would be more tweaks of the code to change the exact execution time when a line of C code gets changed because of the rehash of the assembler output, but I suspect it would still take less time than doing it all by assembler. The only advantage I can see for doing it all in assembler is the programmer can tell how long the code may take while still scribbling on the back of the cigarette packet. The C assembler may have to wait for the first compile to see the assembler output, but an experienced programmer would get a feel for this anyhow. -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestSTOPspammitvma.mit.edu>

{Quote hidden}> -----Original Message----- > From: Dan Michaels [SMTP:RemoveMEoricomspamLYNX.SNI.NET] > Sent: Monday, August 21, 2000 5:18 PM > To: TakeThisOuTPICLISTspamRemoveMEMITVMA.MIT.EDU > Subject: Re: [PIC]: Sine table > > AndyK wrote: > >>Ahh, so. "Deterministic timing" is whatever the compiler **gives** you, > >>whether it gives 10 cycles to code a loop, or 25 - whether a C > instruction > >>gets coded into 1 cycle or 8. Slowly it's coming across. > > > > > >Maybe the definition of "determinism" is the problem. It simply means > that I > >know ahead of time how long something takes, whether 5 or 50 cycles (or > 6/51 in > >certain cases). > > > >It means nothing about the identical timing of some routine(s). > > > >If I need to make something ALWAYS take the same amount of time, I adjust > the > >generated code so it does. That is a special case of determinism. > > > >Deterministic behavior means it will always come to a (correct) answer. > It can > >also have time limitations added to it if you like. > > > > > Andy, I think you painted yourself into a corner. With C, if you > change just one instruction, the timing may be 10s of cycles different. > This is not deterministic. Fiddling with the C, counting the #cycles > in the assembler output, and iterating endlessly just doesn't seem > especially elegant or efficient. > I hope you don't see this as nit-picking, but the whole point is that you can't change one *instruction* in C. You can change an operation, a variable or a literal and depending what you have done, then yes, the compiled code may have increased (or decreased) by several cycles. But if you needed to do the same thing in ASM, chances are that you would need to alter or add more than one instruction also. > Best to know both C and assembler, and use the latter when you > need an exact number of cycles. > Agreed. > 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]. > It's almost definately *possible*. It's almost certainly not *practical* Mike -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu>

At 10:01 AM 8/21/00 -0600, you wrote: > >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. Deterministic means that it always does the same thing, under the same conditions. Usually code is deterministic on 8-bit processors (see below). That is, it takes the same number of cycles every time. This *may* not be true on some of the bigger processors because of things like caching, multiple instruction units, speculative execution etc. where there is more dependency on past instructions (which may have been different because of context switches or interrupts). Interrupts are "more" determininstic in PIC's in the sense that when an interrupt comes at the correct time to be recognized within the 4 clocks, it always takes the same number of clock cycles to be recognized. CISC processors usually have to finish the instruction in progress, which (on, say , an HC05), might be from 2 to 11 bus cycles long (the latter for an 8 x 8 multiply), so at 4MHz, from 1 to 5.5 usec, meaning an uncertainty for an asynchronous interrupt of +/- 2.75usec (+/- 1.25 usec if you don't use the MUL instruction). With the PIC, the uncertainty at 4MHz is more like +/- 0.5usec. This is especially important if your processor lacks a decent capture compare module, as many PICs do. On the Scenix processor, a 3-cycle branch is aborted in progress in order to maintain this degree of "determinism". This, of course, means that the total execution time (background + interrupt) is *not* as deterministic as on an '05, but that usually doesn't matter. Best regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Spehro Pefhany --"it's the network..." "The Journey is the reward" EraseMEspeffSTOPspamRemoveMEinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestRemoveMEEraseMEmitvma.mit.edu>

>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 TakeThisOuTpiclist-unsubscribe-requestRemoveME@spam@mitvma.mit.edu>

Michael Rigby-Jones wrote: ......... >> >> 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!] >> >With the majority of real time applications, only a relatively small part of >the code is critical. The beauty of C is that the rest of the code can be >written quickly and reasonably efficiently, and time critical sections can >be written in ASM. > Bingo. ========== >You *can* write deterministic code in C, but you could be shooting yourself >in the foot as it is quite likely to be more difficult and time consuming >than using ASM (e.g. having to refer to the compilers ASM listing and then >tweaking the C code). > Bingo, bingo. =========== >You seem to be a little "anti-C"? If you work in a market where time to >market is probably the single most important factor, then you'd really see >the benefits. > Anti-C - not at all. It's my favorite language, by far. I just learned years ago that you can compile printf("hello, world"); using different compilers, and get vastly different codesizes & runtimes. You never know what you're gonna get - esp after you change something. Depends upon the compiler, how/whether it optimizes/etc. In fact, on the PC [80x86], I often take the asm output file from a C compiler, fine-tune it to get exactly what I want, and then link the massaged file back in, in place of the original C. The asm file keeps all of the housekeeping garbage that makes it compatible with the rest of the C program. Best of all worlds [in my tiny realm]. beat regards, - danM -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestRemoveMEmitvma.mit.edu>

AndyK wrote: >>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. .......... >Please check a definition on determinism. There's more than isochronicity that >we are talking about here. > >Andy > Hi Andy, I am re-posting my original question here? At 07:26 AM 08/21/2000 -0400, you wrote: >So who uses assembly any more? I do almost everything in C. > >Andy > Can you get **reliable** deterministic timing in C? Over and out, - danM -- http://www.piclist.com hint: To leave the PICList spampiclist-unsubscribe-request.....spammitvma.mit.edu>

On Mon, 21 Aug 2000 10:07:45 -0600 Dan Michaels <.....oricomspam.....LYNX.SNI.NET> writes: > Harold M Hallikainen wrote: > > > Still doing everything in assembly... > > > > And I'll bet you always know "exactly" how long all your > "critical" routines take to execute too. > > cheers, > - danM > Yes... Too Long! Anyone have any sort of histogram program to tell me where the processor is spending all its time? Harold FCC Rules Online at http://hallikainen.com/FccRules Lighting control for theatre and television at http://www.dovesystems.com ________________________________________________________________ YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: dl.http://www.juno.com/get/tagj. -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspamEraseMEmitvma.mit.edu>

Scott, According to that last posting about the sine wave generation (not about determinism <G>), it appears to me that you are expecting to see a sine wave as an input. I'm not so lucky - I just get a 60uS pulse during the zero crossing, as determined by some off-chip electronics. Do I want to implement a FIR filter and try to track either 50 or 60 Hz (yes, it's supposed to lock to either one) with a PID loop? Guess I got a little confused - that was basically my thought. As for amplitude, I only have to generate a 0-5V sine wave at the right frequency (determined by the incoming line); the power electronics convert that to 480V for me. Thanks. Andy -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-request@spam@@spam@mitvma.mit.edu>

On Mon, 21 Aug 2000, Harold M Hallikainen wrote: > On Mon, 21 Aug 2000 10:07:45 -0600 Dan Michaels <spamBeGoneoricomRemoveMEEraseMELYNX.SNI.NET> > writes: > > Harold M Hallikainen wrote: > > > > > Still doing everything in assembly... > > > > > > > And I'll bet you always know "exactly" how long all your > > "critical" routines take to execute too. > > Yes... Too Long! Anyone have any sort of histogram program to tell me > where the processor is spending all its time? No, but I've been wanting to add this feature to gpsim (gnupic simulator) . Essentially what I was thinking about was a profiler to count the number of times an instruction at a particular address is executed and plot this info in a histogram. Obtaining the profile info would be trivial (gpsim traces everything already), but plotting it out would require some work... Meanwhile, I'd suggest writing all of your code in the form of a giant isochronous loop! :) Scott -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestKILLspamRemoveMEmitvma.mit.edu>

Harold wrote: >> >> And I'll bet you always know "exactly" how long all your >> "critical" routines take to execute too. >> ..... > Yes... Too Long! Anyone have any sort of histogram program to tell me >where the processor is spending all its time? > Funny, I would have thought this to be fairly obvious to do by looking at the assembler code [dare I say it - as opposed to looking at C code]. Short of trying to do this using a simulator [and counting cycles - gakkk!], I have done this sort of thing in the past by setting/clearing a port pin, and checking timing on a scope. Kinda primitive, but easy to implement - and easier still [to change] with the new 'F parts. Finally got hold of an '874 - love it to death. Good idea for a new product from the s.w. types - PIC Profiler. best regards, - danM -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestmitvma.mit.edu>

On Mon, 21 Aug 2000, Andrew Kunz wrote: > Scott, > > According to that last posting about the sine wave generation (not about > determinism <G>), it appears to me that you are expecting to see a sine wave as > an input. I'm not so lucky - I just get a 60uS pulse during the zero crossing, > as determined by some off-chip electronics. > > Do I want to implement a FIR filter and try to track either 50 or 60 Hz (yes, > it's supposed to lock to either one) with a PID loop? Guess I got a little > confused - that was basically my thought. > > As for amplitude, I only have to generate a 0-5V sine wave at the right > frequency (determined by the incoming line); the power electronics convert that > to 480V for me. Oh. You're correct. I was assuming that you had continuous access to the sine wave. I guess it's safe to assume then that the `off-chip electronics' do some kind of conditioning to guard against the noise problems I alluded to before. I haven't thought about the problem in this context, but it'd probably make sense to create a filter that takes the time between pulses as it's input. This filter could be as simple as averaging the last n-samples. The output of the filter would be the period of the sinewave. Divide this by `N' and you'll have the sine wave sample time (and could be fed right into the phase accumulator sine wave algorithm - btw, I think you'll want to use this algorithm [or at least a variation], otherwise there will be jitter if N doesn't exactly divide into period of the sine wave). What does the synthesized sine wave need to lock to? Is it sufficient to generate the right frequency? Scott -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestKILLspamTakeThisOuTmitvma.mit.edu>

> >No, but I've been wanting to add this feature to gpsim (gnupic simulator) . >Essentially what I was thinking about was a profiler to count the number of >times an instruction at a particular address is executed and plot this >info in a >histogram. Obtaining the profile info would be trivial (gpsim traces >everything >already), but plotting it out would require some work... Pity no external bus.. I have in my junkbox somewhere, a pair of DACs tied to a 40 pin clip (for Z-80 systems) that output X and Y information to an Oscilliscope. This plots where your code is running, in realtime. It came in handy for debugging, back when we couldn't afford ICEs. No help for microcontrollers though, since you can't see where the code is executing externally. -- Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-request.....KILLspammitvma.mit.edu>

>You're correct. I was assuming that you had continuous access to the sine wave. That would be too easy. >I guess it's safe to assume then that the `off-chip electronics' do some kind of >conditioning to guard against the noise problems I alluded to before. I haven't I would hope so. They haven't finished a spec yet, but that's an item I can write in. >variation], otherwise there will be jitter if N doesn't exactly divide into >period of the sine wave). My plan was to accumulate the error and every M steps insert/delete a uS or so. My goal is to hit 0V within 6 uS of the mains. >What does the synthesized sine wave need to lock to? Incoming power from the electric company 3-phase setup. I will only use one phase as my master reference, the other is assumed to be 90 degrees off. >Is it sufficient to generate the right frequency? Yes, but be locked to the source for phase. It's for continuous UPS equipment. I have to generate the sine waves, and lock to the incoming frequency off the mains. The frequency may change slowly but will nominally be either 50 or 60 Hz. My portion is simply to lock to the incoming wave, generate the sine waves (on a parallel DAC), and if the input goes away I just lock to the last reasonable frequency. When line power comes back on, I will need to lock to it and once locked, flip a switch to enable the mains to provide power again (mains are locked out after a failure). My other input is "phase present" for each phase of the input power. If mains are not present at startup, I default to the last nominal frequency (either 50 or 60 Hz). That is not necessarily the last frequency I saw due to the way lines go dead. The trickiest part of the whole thing will be that I will be crossing 0 at a different time the the inputs, because there is a lag time in the power electronics vs. the sine wave I am feeding them. Andy -- http://www.piclist.com hint: To leave the PICList spampiclist-unsubscribe-requestmitvma.mit.edu>

Yup. My whoops. That's what happens when you think geometry too much on a Monday. Andy Mark Skeels <meskeelsSTOPspamKILLspamEARTHLINK.NET> on 08/21/2000 03:25:16 PM Please respond to pic microcontroller discussion list <@spam@PICLIST.....spamMITVMA.MIT.EDU> To: spamPICLIST..........MITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Sine table > >What does the synthesized sine wave need to lock to? > > Incoming power from the electric company 3-phase setup. I will only use one > phase as my master reference, the other is assumed to be 90 degrees off. > Wouldn't that be 120 degrees off? Mark -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-request.....mitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestspam_OUTmitvma.mit.edu>

----- Original Message ----- From: Andrew Kunz <spam_OUTakunzTakeThisOuTEraseMETDIPOWER.COM> To: <EraseMEPICLISTspamBeGoneKILLspamMITVMA.MIT.EDU> Sent: Monday, August 21, 2000 11:05 AM Subject: Re: [PIC]: Sine table > >And it's *obvious* to the programmer what it is? > > > >How can you tell *exactly* how many cycles a routine takes > >without looking at the assembly code? > > I said I don't WRITE much assembly code, but I still READ it! > > The HiTech C compiler gives you the C with the assembly that it generates in the > .AS file. What happens when an updated compiler generates better (or worse) code? Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) > Andy > > -- > http://www.piclist.com hint: To leave the PICList > RemoveMEpiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestspammitvma.mit.edu>

----- Original Message ----- From: Andrew Kunz <TakeThisOuTakunzKILLspam@spam@TDIPOWER.COM> To: <.....PICLISTRemoveMEMITVMA.MIT.EDU> Sent: Monday, August 21, 2000 2:53 PM Subject: Re: [PIC]: Sine table > >You're correct. I was assuming that you had continuous access to the sine wave. > > That would be too easy. > > >I guess it's safe to assume then that the `off-chip electronics' do some kind > of > >conditioning to guard against the noise problems I alluded to before. I haven't > > I would hope so. They haven't finished a spec yet, but that's an item I can > write in. > > >variation], otherwise there will be jitter if N doesn't exactly divide into > >period of the sine wave). > > My plan was to accumulate the error and every M steps insert/delete a uS or so. > My goal is to hit 0V within 6 uS of the mains. > > >What does the synthesized sine wave need to lock to? > > Incoming power from the electric company 3-phase setup. I will only use one > phase as my master reference, the other is assumed to be 90 degrees off. Huh? 90 degrees? Aren't the phases in 3-phase 120 degrees apart? Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software)s > > >Is it sufficient to generate the right frequency? > > Yes, but be locked to the source for phase. It's for continuous UPS equipment. > I have to generate the sine waves, and lock to the incoming frequency off the > mains. The frequency may change slowly but will nominally be either 50 or 60 > Hz. My portion is simply to lock to the incoming wave, generate the sine waves > (on a parallel DAC), and if the input goes away I just lock to the last > reasonable frequency. When line power comes back on, I will need to lock to it > and once locked, flip a switch to enable the mains to provide power again (mains > are locked out after a failure). > > My other input is "phase present" for each phase of the input power. If mains > are not present at startup, I default to the last nominal frequency (either 50 > or 60 Hz). That is not necessarily the last frequency I saw due to the way {Quote hidden}> lines go dead. > > The trickiest part of the whole thing will be that I will be crossing 0 at a > different time the the inputs, because there is a lag time in the power > electronics vs. the sine wave I am feeding them. > > Andy > > -- > http://www.piclist.com hint: To leave the PICList > KILLspampiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestspam_OUTmitvma.mit.edu>

Jinx wrote: >> Duh - just can't this follow this on monday morning. > >One of the joys living a day ahead in the S Hemisphere. You get >two goes at Monday morning. Ours and then yours. Yippee skip > Yeah, but you get off for the weekend a day earlier - so you come out better in the end. No? =================== >"Assembler vs C" and "Documenting code" seem to be an annual >event. Can we have a picnic and a movie next year instead ? > Well, it wasn't really about C vs Asm, rather about whether you really know what you're going to get when you write in C. The answer is no, but it doesn't really matter very much, except when timing is critical. As a strong advocate of C, myself, I would never argue "C vs Asm". Somehow the discussion went off track, into terminology. [how come I'm always in the middle of these things? - poor baby]. =============== > >A subtle thought that is in error may yet give rise to fruitful >inquiry that can establish truths of great value. > >Isaac Asimov > "Get the facts first, you can distort them later" - Mark Twain cheers, - danM -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestEraseMEmitvma.mit.edu>

The call stack is accessible on the 03 emulator chip (new 14-bit core). It also has a deeper stack (12 vs 8) for debugging within the emulator. These features are NOT available in production mode, though :-( until you get to the PIC18. This is the part that enables a call stack dump in the Mathias emulator. It's well worth the money to upgrade! Andy Olin Lathrop <spamBeGoneolin_piclistRemoveMECOGNIVIS.COM> on 08/21/2000 04:01:47 PM Please respond to pic microcontroller discussion list <.....PICLISTEraseMEMITVMA.MIT.EDU> To: spamPICLISTspam_OUT@spam@MITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Sine table > Good idea for a new product from the s.w. types - PIC Profiler. It would be difficult to do this in the PIC itself because you can't read back the call stack. With the ICE you could export a trace, then post process the instruction addresses to build a histogram. Sounds like it's more trouble than its worth though. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, spamolin@spam@STOPspamcognivis.com, http://www.cognivis.com -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGone@spam@mitvma.mit.edu -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

Then you probably saw my reply that it was Monday and I messed up. It's 3-phase, 120 degree. Andy "W. K. Brown" <RemoveMEkbrownRemoveMERemoveMEMARSH-MCBIRNEY.COM> on 08/22/2000 08:25:15 AM Please respond to pic microcontroller discussion list <PICLISTKILLspamspamMITVMA.MIT.EDU> To: spam_OUTPICLIST@spam@MITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Sine table If this is late, I apologize, as I read my mail from the bottom up. Is this 3-wire or 3-phase? 3-phase usually means 120 Deg. between phases. Afaik, if there are 3-phase motors present they, when presented with a loss of one phase, will tend to generate the lost one back on to the power network. Determining phase loss is not necessarily trivial. Sounds like an old Lab Course I had with the three glowing light bulbs to determine phase synchronization. If not done right the MG Set could 'go through the wall'. Regards, Keith {Original Message removed}

On Tue, 22 Aug 2000, Alan B. Pearce wrote: > >Obtaining the profile info would be trivial (gpsim traces everything > >already), but plotting it out would require some work... > > Is it practical to stuff it into a file as a comma delimited data stream? It > could then be read a nd plotted by any spreadsheet program. Just a thought for a > quick and dirty way of getting it displayed. > > It may well be that the effort involved in generating the CSV file is as much as > generating the plot directly. The way I'd probably do it is modify gpsim to dump the entire trace buffer to a log file. The way I've got it set up now, each event is encoded into one unsigned 32 bit integer and written to a circular buffer. The `events' are actions that gpsim has performed, e.g. executed an instruction, modified a register, incremented the cycle counter (this one is actually 64 bits), etc. The encoding and writing to the circular buffer is extremely fast and incurs little overhead. What I'll probably do is create a thread to monitor the circular buffer. After say 10,000 events, I'll write the buffer to a log file. This will be raw binary data. The next step would be to parse the file and sift out the information needed. I've already written routines to parse the circular trace buffer, so these can easily be adapted to parse the log file. The parsed information can then be written a CSV formatted file and made available to other routines. However, keep in mind that this file will get rather larger. gpsim simulates a pic at a rate faster than a real pic can actually run. So one second's worth of simulation time will generate a rather large log file... Scott -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

> Sounds like an old Lab Course I had with the three glowing light > bulbs to determine phase synchronization. If not done right the MG Set could > 'go through the wall'. > Even worse: One of my customers is a company that builds control systems for large power plants. We built a system for the Hydro plant at Niagara Falls (about 2.5GW). We told the Power Authority that they did _not_ want the ability to close a generator breaker manually from the control system because of the indeterminate (there is that word again! :-) lag between hitting the key on the keyboard and when the breaker would actually be commanded to close. They argued with us and insisted on the functionality. We put the function in. They used it. They closed in the breaker on a 167MW generator while it was N degrees out of phase (N > 25?). WHOOOOOOOMPH..... It shook the entire plant - sounded like a not-so-small bomb going off. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) > Regards, > Keith > > {Original Message removed}

>Yes... Too Long! Anyone have any sort of histogram program to >tell me where the processor is spending all its time? The simulator can usually tell you where the program spends most of the time. I don't use MPLAB but it should too somehow. The last resort is to make the simulator log to file, run the program, and then process the log with a small Perl program. On bigger systems you can profile the runtime. In my experience withe real life projetcs if the processor load is calculated at 60% when the task book is 'closed' then you will need at least 220% (=60*3+10) by the time the product ships. ;) Also task books are well known applications for infinitely scalable numbers, with the exception of honorary <g>. Peter -- 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

>Can you get **reliable** deterministic timing in C? With a couple of small tricks you can get that afaik. The tricks involve atomic flags to communicate across task/interrupt context switches and other things. Most high level OSes are and have been written in C for some time now afaik (like 10 years or so). Including some RTOSes with good name ?! You can even write constant run time code in C if you have the source for the library (or the space in the run-time for it to auto-learn). The real question from my point of view is, how many lines of C code can I cram into a 16C(5)54, 12C508A etc. I.e. the lowest level PICs. Peter -- 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

Peter Peres wrote: >I understand that by 'deterministic' it is meant that for any given set of >inputs I0..IN the runtime of a piece of code is a constant Tk that depends >only on the set of input parameters. This may or may not be true depending >on interrupts, spinlocks, hidden optimizations (f.ex. computing the >modulus just after computing a division with the same parameters is >usually optimized by the math library - but not on PIC ?), and other >details in the C code and in the library. > Andy Kunz wrote: > >Thank you. > >Dan, I think you're the one who should be retracting <G>. I don't even have to >say anything any more! > OK, Andy, retraction follows: Unfortunately, Monday's discussion moved away from the point being made, and devolved into different opinions about the meaning of the word deterministic, and kindled some kind of "C vs Asm" debate. This was completely off the track. The original point was oriented towards how to produce time-critical code, where the coder is in control of the process - [forgetting about interrupts/timers/etc controlling the timing]. When you write in C, you have very little idea what the final machine code will look like, exactly how many instructions it will have, how these will be optimized [or not] by the compiler, and exactly how long routines will take to execute. You can look at the C-compiler --> assembler output, but that just tells you what the compiler gave you, not necessarily what you wanted to get. Trying to massage code using the C --> asm --> C --> asm [on and on] route is not very elegant or efficient. Also, if you change the C source, add or remove a statement, etc, you are often all the way back to square Zero. [eg, just try changing an INT to a FLOAT, and see what happens]. In short, C may produce code that executes reliably and repeatably in time, after the fact, but whether or not the coder can control this timing in a required and desired manner, before the fact, is a much more difficult situation. The nice thing about using a processor like PIC or Scenix, compared to a CISC chip, is that you can more easily know and control exactly what the execution times of your programs are - where this is important to you. I have numerous applications where I want a PC to produce precise timing, and rather than try to make the PC do it itself, I connect a PIC to it via a serial port, and let the PIC worry about counting microseconds. And I write the PIC code in Asm, so I will know exactly what the timing will be. The bottom line is not that C [incidentally, my favorite language] is better than Asm, or vice versa, but that there are certain limitations you have to recognize and try to understand. I figured this should all have been obvious, but somehow it got lost in Monday's onslaught about what determinism/etc means. best regards, - Dan Michaels ============== -- 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