Searching \ for '[PIC]: Sine table' 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/math/index.htm?key=sine
Search entire site for: 'Sine table'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Sine table'
2000\08\18@131753 by Andrew Kunz

flavicon
face
Anybody have a quick program to build a 128-point (or so) sine table?

Thanks.

Andy

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\08\18@132624 by Simon Nield

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

2000\08\18@132851 by M. Adam Davis

flavicon
face
Yeah, Excel.  Would you like:
128 points of a (full/half/quarter) wave
Full scale (0 and 255 are peak, 128 is mid)
Any other needs?

I can do this now.

-Adam

Andrew Kunz wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\08\18@133144 by Andrew Kunz

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

2000\08\18@133754 by Andrew Kunz

flavicon
face
part 1 334 bytes content-type:text/plain; charset=us-ascii


So nobody needs to ask the same dumb question as I just did...

Note that this program gives me 8-bit values to output to a parallel DAC (with
appropriate filtering), and that it takes advantage of the fact that the table
is symmetrical top to bottom but also on either side of the maxima.

Andy


(See attached file: sinetbl.c)



part 2 413 bytes content-type:application/octet-stream; (decode)

part 3 144 bytes
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\08\18@174649 by pandersn

flavicon
face
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_OUTakunzTakeThisOuTspamTDIPOWER.COM]
wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\08\18@220338 by Dan Michaels

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

2000\08\19@061459 by Alan B. Pearce

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

2000\08\20@190127 by Tony Nixon
flavicon
picon face
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
.....salesKILLspamspam@spam@picnpoke.com

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

2000\08\21@072647 by Andrew Kunz

flavicon
face
So who uses assembly any more?  I do almost everything in C.

Andy









"Alan B. Pearce" <A.B.PearcespamKILLspamRL.AC.UK> on 08/19/2000 06:13:26 AM

Please respond to pic microcontroller discussion list <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>








To:      EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.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-requestspamspam_OUTmitvma.mit.edu>

2000\08\21@073725 by Frank Adlam

flavicon
face
Well said Andy!

-----Original Message-----
From: Andrew Kunz [@spam@akunzKILLspamspamTDIPOWER.COM]
Sent: Monday, August 21, 2000 1:26 PM
To: KILLspamPICLISTKILLspamspamMITVMA.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.PearceTakeThisOuTspamRL.AC.UK> on 08/19/2000 06:13:26 AM

Please respond to pic microcontroller discussion list
<spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU>








To:      TakeThisOuTPICLISTEraseMEspamspam_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-requestspamTakeThisOuTmitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu>

2000\08\21@091059 by Bob Ammerman

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

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2000\08\21@092724 by Alan B. Pearce

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

I used to work on a machine where the assembler was known as REAL. It stood for
RElocatable Assembly Language. Anyone else here who used to work on QANTEL
systems???

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu>

2000\08\21@094138 by Scott Dattalo

face
flavicon
face
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-requestEraseMEspamEraseMEmitvma.mit.edu>

2000\08\21@095218 by Andrew Kunz

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

I agree 100%.

"The right tool for the job."

Andy

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUTspamKILLspammitvma.mit.edu>

2000\08\21@095629 by Andrew Kunz

flavicon
face
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 <RemoveMEscottTakeThisOuTspamspamDATTALO.COM> on 08/21/2000 09:42:11 AM

Please respond to pic microcontroller discussion list <EraseMEPICLISTspamspamspamBeGoneMITVMA.MIT.EDU>








To:      RemoveMEPICLISTKILLspamspamMITVMA.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-requestSTOPspamspamspam_OUTmitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestSTOPspamspamEraseMEmitvma.mit.edu>

2000\08\21@101853 by Scott Dattalo

face
flavicon
face
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
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu>

2000\08\21@102932 by Andrew Kunz

flavicon
face
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 <EraseMEscottspamEraseMEDATTALO.COM> on 08/21/2000 10:20:51 AM

Please respond to pic microcontroller discussion list <@spam@PICLIST@spam@spamspam_OUTMITVMA.MIT.EDU>








To:      spamBeGonePICLISTspamKILLspamMITVMA.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_OUTspammitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-request.....spamTakeThisOuTmitvma.mit.edu>

2000\08\21@103342 by Dan Michaels

flavicon
face
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
TakeThisOuTpiclist-unsubscribe-requestKILLspamspamspammitvma.mit.edu>

2000\08\21@103531 by Andrew Kunz

flavicon
face
Yes.

Andy








Dan Michaels <.....oricomspamRemoveMELYNX.SNI.NET> on 08/21/2000 10:32:40 AM

Please respond to pic microcontroller discussion list <RemoveMEPICLISTspamspamBeGoneMITVMA.MIT.EDU>








To:      spamBeGonePICLIST@spam@spamspam_OUTMITVMA.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
TakeThisOuTpiclist-unsubscribe-requestspamspammitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspammitvma.mit.edu>

2000\08\21@104140 by Dan Michaels

flavicon
face
And it's *obvious* to the programmer what it is?



At 10:35 AM 08/21/2000 -0400, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamBeGonespammitvma.mit.edu>

2000\08\21@104557 by Andrew Kunz

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

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-request@spam@spamspamBeGonemitvma.mit.edu>

2000\08\21@104603 by Dan Michaels

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

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu>

2000\08\21@110104 by Scott Dattalo

face
flavicon
face
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_OUTspam@spam@mitvma.mit.edu>

2000\08\21@110304 by Dan Michaels

flavicon
face
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
spamBeGonepiclist-unsubscribe-request@spam@spammitvma.mit.edu>

2000\08\21@110633 by Andrew Kunz

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

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamKILLspammitvma.mit.edu>

2000\08\21@110840 by Andrew Kunz

flavicon
face
I'm not trying to be obtuse, but YES, you pad it.

Andy










Dan Michaels <spamBeGoneoricomspam_OUTspamRemoveMELYNX.SNI.NET> on 08/21/2000 11:02:35 AM

Please respond to pic microcontroller discussion list <.....PICLISTspamRemoveMEMITVMA.MIT.EDU>








To:      PICLISTspam@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}

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-requestRemoveMEspamSTOPspammitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspamTakeThisOuTmitvma.mit.edu>

2000\08\21@111952 by Dan Michaels

flavicon
face
Duh - just can't this follow this on monday morning.



At 11:08 AM 08/21/2000 -0400, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu>

2000\08\21@112000 by Dan Michaels

flavicon
face
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-requestspamBeGonespam.....mitvma.mit.edu>

2000\08\21@113948 by Scott Dattalo

face
flavicon
face
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-requestspam.....mitvma.mit.edu>

2000\08\21@115018 by Andrew Kunz

flavicon
face
>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-requestspamKILLspammitvma.mit.edu>

2000\08\21@115638 by Harold M Hallikainen

picon face
       Still doing everything in assembly...

Harold

On Mon, 21 Aug 2000 07:26:07 -0400 Andrew Kunz <RemoveMEakunzRemoveMEspamEraseMETDIPOWER.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-requestspamspamBeGonemitvma.mit.edu>

2000\08\21@120256 by Dan Michaels

flavicon
face
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-requestspamspammitvma.mit.edu>

2000\08\21@120931 by Dan Michaels

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

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamBeGonespamRemoveMEmitvma.mit.edu>

2000\08\21@121927 by Dan Michaels

flavicon
face
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-requestspamBeGonespammitvma.mit.edu>

2000\08\21@122542 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Dan Michaels [SMTP:@spam@oricomSTOPspamspam@spam@LYNX.SNI.NET]
> Sent: Monday, August 21, 2000 5:01 PM
> To:   PICLISTspamBeGonespamspamBeGoneMITVMA.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-requestspammitvma.mit.edu>

2000\08\21@122953 by Alan B. Pearce

face picon face
>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-requestSTOPspamspammitvma.mit.edu>

2000\08\21@123212 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

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-requestspamspamspam_OUTmitvma.mit.edu>

2000\08\21@123420 by Severson, Rob

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

Dan,

I think you have a very narrow definition of "deterministic". Deterministic
goes beyond exact cycle counting.

Lets argue about "real time" next. ;-D

-Rob

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestRemoveMEspammitvma.mit.edu>

2000\08\21@123617 by Spehro Pefhany

picon face
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"
EraseMEspeffSTOPspamspamRemoveMEinterlog.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-requestRemoveMEspamEraseMEmitvma.mit.edu>

2000\08\21@125107 by Andrew Kunz

flavicon
face
>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-requestRemoveMEspam@spam@mitvma.mit.edu>

2000\08\21@130400 by Dan Michaels

flavicon
face
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-requestRemoveMEspammitvma.mit.edu>

2000\08\21@130732 by Dan Michaels

flavicon
face
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.....spamspammitvma.mit.edu>

2000\08\21@131145 by Andrew Kunz

flavicon
face
>Can you get **reliable** deterministic timing in C?

To which I must reply,

YES!

WIth the qualification, "What level of granularity?"

Andy

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspam_OUTspam@spam@mitvma.mit.edu>

2000\08\21@132508 by Harold M Hallikainen

picon face
On Mon, 21 Aug 2000 10:07:45 -0600 Dan Michaels <.....oricomspamspam.....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-requestKILLspamspamEraseMEmitvma.mit.edu>

2000\08\21@133115 by Andrew Kunz

flavicon
face
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@spam@mitvma.mit.edu>

2000\08\21@133119 by Andrew Kunz

flavicon
face
>        Yes... Too Long!  Anyone have any sort of histogram program to tell me
>where the processor is spending all its time?

I usually use the timing module for the Mathias when I need that.  Not being an
MPLAB user, I would expect a similar functionality in the simulator.  How about
GPSIM?  Seems to me like this would be a very elementary function of any
simulator.

Andy

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestspamspamKILLspammitvma.mit.edu>

2000\08\21@133538 by Scott Dattalo

face
flavicon
face
On Mon, 21 Aug 2000, Harold M Hallikainen wrote:

> On Mon, 21 Aug 2000 10:07:45 -0600 Dan Michaels <spamBeGoneoricomRemoveMEspamEraseMELYNX.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-requestKILLspamspamRemoveMEmitvma.mit.edu>

2000\08\21@135000 by Dan Michaels

flavicon
face
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-requestspammitvma.mit.edu>

2000\08\21@135403 by Scott Dattalo

face
flavicon
face
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-requestKILLspamspamTakeThisOuTmitvma.mit.edu>

2000\08\21@140243 by David VanHorn

flavicon
face
>
>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.....spamKILLspammitvma.mit.edu>

2000\08\21@145446 by Andrew Kunz

flavicon
face
>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-requestspammitvma.mit.edu>

2000\08\21@152336 by Mark Skeels

picon face
> >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-requestSTOPspamspammitvma.mit.edu>

2000\08\21@152757 by Andrew Kunz

flavicon
face
Yup.  My whoops.  That's what happens when you think geometry too much on a
Monday.

Andy








Mark Skeels <meskeelsSTOPspamspamKILLspamEARTHLINK.NET> on 08/21/2000 03:25:16 PM

Please respond to pic microcontroller discussion list <@spam@PICLIST.....spamspamMITVMA.MIT.EDU>








To:      spamPICLIST.....spam.....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.....spammitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspam_OUTspammitvma.mit.edu>

2000\08\21@165455 by Olin Lathrop

flavicon
face
> 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, spam_OUTolinspamTakeThisOuTcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-request.....spamRemoveMEmitvma.mit.edu>

2000\08\21@194720 by Bob Ammerman

picon face
----- Original Message -----
From: Andrew Kunz <spam_OUTakunzTakeThisOuTspamEraseMETDIPOWER.COM>
To: <EraseMEPICLISTspamBeGonespamKILLspamMITVMA.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-requestspamBeGonespamspammitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestspamspammitvma.mit.edu>

2000\08\21@194759 by Bob Ammerman

picon face
No, no, not the "real time" argument.

I think I'll go bang my head against the wall instead :-)

Bob Ammerman
RAm Systems

(contract development of high performance, high function, low-level
software)
{Original Message removed}

2000\08\21@200135 by Bob Ammerman

picon face
----- Original Message -----
From: Andrew Kunz <TakeThisOuTakunzKILLspamspam@spam@TDIPOWER.COM>
To: <.....PICLISTRemoveMEspamMITVMA.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}

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu>

2000\08\21@202928 by Jinx

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

"Assembler vs C" and "Documenting code" seem to be an annual
event. Can we have a picnic and a movie next year instead ?

**************************************
A subtle thought that is in error may yet give rise to fruitful
inquiry that can establish truths of great value.

Isaac Asimov

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamspamSTOPspammitvma.mit.edu>

2000\08\21@212603 by Dan Michaels

flavicon
face
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-requestEraseMEspammitvma.mit.edu>

2000\08\22@034841 by Alan B. Pearce

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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\08\22@082634 by W. K. Brown

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

2000\08\22@084312 by Andrew Kunz

flavicon
face
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_piclistspamRemoveMECOGNIVIS.COM> on 08/21/2000 04:01:47 PM

Please respond to pic microcontroller discussion list <.....PICLISTEraseMEspamMITVMA.MIT.EDU>








To:      spamPICLISTspam_OUTspam@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@spamSTOPspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespam@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

2000\08\22@090139 by Andrew Kunz

flavicon
face
Then you probably saw my reply that it was Monday and I messed up.

It's 3-phase, 120 degree.

Andy










"W. K. Brown" <RemoveMEkbrownRemoveMEspamRemoveMEMARSH-MCBIRNEY.COM> on 08/22/2000 08:25:15 AM

Please respond to pic microcontroller discussion list <PICLISTKILLspamspamspamMITVMA.MIT.EDU>








To:      spam_OUTPICLIST@spam@spamMITVMA.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}

2000\08\22@093718 by Scott Dattalo

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

2000\08\22@094748 by Alan B. Pearce

face picon face
>So one second's worth of simulation time
>will generate a rather large log file...

Don't worry, the simulation will be slowed down by the writing of all this log
file info .... (not) ;-)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\08\22@122251 by Bob Ammerman

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

2000\08\22@180042 by Steve Smith

picon face
Multiple sine waves:-
Make two 120 deg apart and use an op amp to make the third at 240 deg makes
the code simpler

Steve....

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's


2000\08\23@080013 by Andrew Kunz

flavicon
face
>Make two 120 deg apart and use an op amp to make the third at 240 deg makes
>the code simpler

Smaller, but not simpler.  Getting the value for each phase is a quick table
lookup, and since this is in C (remember, this is really the C vs ASM thread
<G>) the copy-paste-update was pretty easy.

I had not thought of using an op amp though.  That's a slick way to do it.
Using 3 DACs will at least give me identical amplitude and drive current, though
- I don't know how important that is.

Andy

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


2000\08\23@125404 by Peter L. Peres

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


2000\08\23@125408 by Peter L. Peres

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

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


2000\08\23@125603 by Peter L. Peres

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


2000\08\23@135109 by Dan Michaels

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


2000\08\23@142705 by Andrew Kunz

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

Which is precisely why I write in C.  I don't _want_ to know, nor do I need to
know.  If I _do_ need to know, I don't do that part in C.

One must always use "the right tool for the job."

Thanks for the lively thread, Dan.  Some people are much better at their
explanations than I am, and I thank them too for this input.

Andy

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


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