[AVR] square on AVR

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[AVR] square on AVR

madscientistatlarge
Sorry, that should be square root (time for a nap).  It would be on an atmega2560 AVR, running at 16MHZ.


Sent with ProtonMail Secure Email.



--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

Christopher Head-7
On Sat, 12 Sep 2020 00:48:16 +0000
madscientistatlarge <[hidden email]> wrote:

> Sorry, that should be square root (time for a nap).  It would be on
> an atmega2560 AVR, running at 16MHZ.

16-bit sounds easily within reason to me. My go-to integer square root
implementation is a binary search: “for each bit from N−1 downto 0, try
turning it on, square that number, if the square is ≤ the input then
keep the bit, otherwise clear it”. There may be better ones, but I’ve
found this to be something that can be implemented in an extremely
tight loop, in assembly if necessary, quite easily (or unrolled if you
want to absolutely max out performance). It looks like the 2560 has a
hardware multiplier—I assume probably 8×8→16—which should make this
doable in just a few dozen cycles, out of a budget of 40,000!

20-bit, you’d just have to synthesize the larger multiplication
operation. It is also possible to rip the SQRT into pieces and do some
subtractions so you don’t have to deal with all 20 bits on every cycle.

Doing it in C, YMMV, especially if you do larger-than-CPU-native-size
multiplies. Assembly should be fine though.

This is all assuming you want a floored integer output and don’t care
about the fractional part!
--
Christopher Head

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

madscientistatlarge
I found search results eventually on the web.  The successive approximation looks pretty fast, if done in assembler which shouldn't be too hard for me.  I've manually compiled small pieces of code for a 6502 in a apple][, and a z80, had a course on motorola 68K assembler and had no problem with a 20 page program (based on a 2 page pascal program we were told to redo in assembler).  In the 68K program I wrote code for longer multiplication by spliing the numbers, doing 4 multiplies and adding.  On the 68k code I only had one error, off by one which I thought I might have, and found a bug in the compiler for one of the many compare functions, I used another one that reacted to the flags in the same way to get around it. People thought I was crazy typing in comments before I had it working.  That was a couple of decades ago but I think I can learn a new assembler for such a small piece of code pretty easily, Especially since I found examples on the web. Risc instruction set would likely be a bit harder for me but should be doable by me.  I also calculated 40,000 as total available cycles, obviously there's other code but it's simple in this case so C should be fast enough outside the square root calculation.

This is the first project I've done in awhile but I've had plenty of time to tweak the design of the other hardware.  I'd like to do it this way to cut EMI, I'll hopefully be doing some ham radio before long so I'd like to keep the bench somewhat quite (Yes, I know I spelled it wrong, having trouble finding the correct spelling, I am terrible at spelling).  Not putting a high power pwm signal on external unshielded cables should help with that, as well as helping with whatever else I'm working on.  There will be 4 of these signals, at up to 240 Watts each so obviously it could really radiate!  Each channel will be adjusted 100 times per second. I'm designing myself a "universal" soldering/desolering station that I can use with any 4 irons by putting a new connector on them with a serial eeprom in the connector to tell the station what the specs are for a particular iron.  This will be fun.  I will write it all up and ideally put it on the web.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, September 11, 2020 8:10 PM, Christopher Head <[hidden email]> wrote:

> On Sat, 12 Sep 2020 00:48:16 +0000
> madscientistatlarge [hidden email] wrote:
>
> > Sorry, that should be square root (time for a nap). It would be on
> > an atmega2560 AVR, running at 16MHZ.
>
> 16-bit sounds easily within reason to me. My go-to integer square root
> implementation is a binary search: “for each bit from N−1 downto 0, try
> turning it on, square that number, if the square is ≤ the input then
> keep the bit, otherwise clear it”. There may be better ones, but I’ve
> found this to be something that can be implemented in an extremely
> tight loop, in assembly if necessary, quite easily (or unrolled if you
> want to absolutely max out performance). It looks like the 2560 has a
> hardware multiplier—I assume probably 8×8→16—which should make this
> doable in just a few dozen cycles, out of a budget of 40,000!
>
> 20-bit, you’d just have to synthesize the larger multiplication
> operation. It is also possible to rip the SQRT into pieces and do some
> subtractions so you don’t have to deal with all 20 bits on every cycle.
>
> Doing it in C, YMMV, especially if you do larger-than-CPU-native-size
> multiplies. Assembly should be fine though.
>
> This is all assuming you want a floored integer output and don’t care
> about the fractional part!
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Christopher Head
>
> -----------------
>
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist



--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

Richard Prosser
How fast is  the input changing? if only slowly wrt the sampling rate you
made be able to speed things up by using an estimate based on the current
value. 400 times per second with a 16MHz clock sounds quite do-able to me,
unless the processor is doing a lot of other stuff as well.
if you have spare memory, you can speed things up with a lookup table to
get you close also.

Richard P

On Sat, 12 Sep 2020 at 14:49, madscientistatlarge <
[hidden email]> wrote:

> I found search results eventually on the web.  The successive
> approximation looks pretty fast, if done in assembler which shouldn't be
> too hard for me.  I've manually compiled small pieces of code for a 6502 in
> a apple][, and a z80, had a course on motorola 68K assembler and had no
> problem with a 20 page program (based on a 2 page pascal program we were
> told to redo in assembler).  In the 68K program I wrote code for longer
> multiplication by spliing the numbers, doing 4 multiplies and adding.  On
> the 68k code I only had one error, off by one which I thought I might have,
> and found a bug in the compiler for one of the many compare functions, I
> used another one that reacted to the flags in the same way to get around
> it. People thought I was crazy typing in comments before I had it working.
> That was a couple of decades ago but I think I can learn a new assembler
> for such a small piece of code pretty easily, Especially since I found
> examples on the web. Risc instruction set would likely be a bit harder for
> me but should be doable by me.  I also calculated 40,000 as total available
> cycles, obviously there's other code but it's simple in this case so C
> should be fast enough outside the square root calculation.
>
> This is the first project I've done in awhile but I've had plenty of time
> to tweak the design of the other hardware.  I'd like to do it this way to
> cut EMI, I'll hopefully be doing some ham radio before long so I'd like to
> keep the bench somewhat quite (Yes, I know I spelled it wrong, having
> trouble finding the correct spelling, I am terrible at spelling).  Not
> putting a high power pwm signal on external unshielded cables should help
> with that, as well as helping with whatever else I'm working on.  There
> will be 4 of these signals, at up to 240 Watts each so obviously it could
> really radiate!  Each channel will be adjusted 100 times per second. I'm
> designing myself a "universal" soldering/desolering station that I can use
> with any 4 irons by putting a new connector on them with a serial eeprom in
> the connector to tell the station what the specs are for a particular
> iron.  This will be fun.  I will write it all up and ideally put it on the
> web.
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, September 11, 2020 8:10 PM, Christopher Head <[hidden email]>
> wrote:
>
> > On Sat, 12 Sep 2020 00:48:16 +0000
> > madscientistatlarge [hidden email] wrote:
> >
> > > Sorry, that should be square root (time for a nap). It would be on
> > > an atmega2560 AVR, running at 16MHZ.
> >
> > 16-bit sounds easily within reason to me. My go-to integer square root
> > implementation is a binary search: “for each bit from N−1 downto 0, try
> > turning it on, square that number, if the square is ≤ the input then
> > keep the bit, otherwise clear it”. There may be better ones, but I’ve
> > found this to be something that can be implemented in an extremely
> > tight loop, in assembly if necessary, quite easily (or unrolled if you
> > want to absolutely max out performance). It looks like the 2560 has a
> > hardware multiplier—I assume probably 8×8→16—which should make this
> > doable in just a few dozen cycles, out of a budget of 40,000!
> >
> > 20-bit, you’d just have to synthesize the larger multiplication
> > operation. It is also possible to rip the SQRT into pieces and do some
> > subtractions so you don’t have to deal with all 20 bits on every cycle.
> >
> > Doing it in C, YMMV, especially if you do larger-than-CPU-native-size
> > multiplies. Assembly should be fine though.
> >
> > This is all assuming you want a floored integer output and don’t care
> > about the fractional part!
> >
> >
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> >
> > Christopher Head
> >
> > -----------------
> >
> > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
>
>
>
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

Sean Breheny
If the power required for your setpoint doesn't vary too much then the v^2
nonlinearity can be treated as a linear function of slope 2v and you don't
even need to perform a square root for your PID loop.




On Sat, Sep 12, 2020, 2:38 AM Richard Prosser <[hidden email] wrote:

> How fast is  the input changing? if only slowly wrt the sampling rate you
> made be able to speed things up by using an estimate based on the current
> value. 400 times per second with a 16MHz clock sounds quite do-able to me,
> unless the processor is doing a lot of other stuff as well.
> if you have spare memory, you can speed things up with a lookup table to
> get you close also.
>
> Richard P
>
> On Sat, 12 Sep 2020 at 14:49, madscientistatlarge <
> [hidden email]> wrote:
>
> > I found search results eventually on the web.  The successive
> > approximation looks pretty fast, if done in assembler which shouldn't be
> > too hard for me.  I've manually compiled small pieces of code for a 6502
> in
> > a apple][, and a z80, had a course on motorola 68K assembler and had no
> > problem with a 20 page program (based on a 2 page pascal program we were
> > told to redo in assembler).  In the 68K program I wrote code for longer
> > multiplication by spliing the numbers, doing 4 multiplies and adding.  On
> > the 68k code I only had one error, off by one which I thought I might
> have,
> > and found a bug in the compiler for one of the many compare functions, I
> > used another one that reacted to the flags in the same way to get around
> > it. People thought I was crazy typing in comments before I had it
> working.
> > That was a couple of decades ago but I think I can learn a new assembler
> > for such a small piece of code pretty easily, Especially since I found
> > examples on the web. Risc instruction set would likely be a bit harder
> for
> > me but should be doable by me.  I also calculated 40,000 as total
> available
> > cycles, obviously there's other code but it's simple in this case so C
> > should be fast enough outside the square root calculation.
> >
> > This is the first project I've done in awhile but I've had plenty of time
> > to tweak the design of the other hardware.  I'd like to do it this way to
> > cut EMI, I'll hopefully be doing some ham radio before long so I'd like
> to
> > keep the bench somewhat quite (Yes, I know I spelled it wrong, having
> > trouble finding the correct spelling, I am terrible at spelling).  Not
> > putting a high power pwm signal on external unshielded cables should help
> > with that, as well as helping with whatever else I'm working on.  There
> > will be 4 of these signals, at up to 240 Watts each so obviously it could
> > really radiate!  Each channel will be adjusted 100 times per second. I'm
> > designing myself a "universal" soldering/desolering station that I can
> use
> > with any 4 irons by putting a new connector on them with a serial eeprom
> in
> > the connector to tell the station what the specs are for a particular
> > iron.  This will be fun.  I will write it all up and ideally put it on
> the
> > web.
> >
> >
> > Sent with ProtonMail Secure Email.
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, September 11, 2020 8:10 PM, Christopher Head <[hidden email]>
> > wrote:
> >
> > > On Sat, 12 Sep 2020 00:48:16 +0000
> > > madscientistatlarge [hidden email] wrote:
> > >
> > > > Sorry, that should be square root (time for a nap). It would be on
> > > > an atmega2560 AVR, running at 16MHZ.
> > >
> > > 16-bit sounds easily within reason to me. My go-to integer square root
> > > implementation is a binary search: “for each bit from N−1 downto 0, try
> > > turning it on, square that number, if the square is ≤ the input then
> > > keep the bit, otherwise clear it”. There may be better ones, but I’ve
> > > found this to be something that can be implemented in an extremely
> > > tight loop, in assembly if necessary, quite easily (or unrolled if you
> > > want to absolutely max out performance). It looks like the 2560 has a
> > > hardware multiplier—I assume probably 8×8→16—which should make this
> > > doable in just a few dozen cycles, out of a budget of 40,000!
> > >
> > > 20-bit, you’d just have to synthesize the larger multiplication
> > > operation. It is also possible to rip the SQRT into pieces and do some
> > > subtractions so you don’t have to deal with all 20 bits on every cycle.
> > >
> > > Doing it in C, YMMV, especially if you do larger-than-CPU-native-size
> > > multiplies. Assembly should be fine though.
> > >
> > > This is all assuming you want a floored integer output and don’t care
> > > about the fractional part!
> > >
> > >
> >
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > >
> > > Christopher Head
> > >
> > > -----------------
> > >
> > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > > View/change your membership options at
> > > http://mailman.mit.edu/mailman/listinfo/piclist
> >
> >
> >
> > --
> > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
> >
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

madscientistatlarge
In reply to this post by Richard Prosser
I'm using an overly conservative time constant of 0.1 seconds.  Most of the other microprocessor load will be the PID routine.  If necessary I'll use the lookup table.  It will also be sampling temperature 100 times/S on 4 channels.  I'll also have to convert thermocouple voltage to temperature, I'll use a lookup table with linear interpolation for that most likely.  I'm sure I'll have plenty of memory to spare.  I could use the last value as a starting value for the square root.  Obviously the iron temperature won't be changing terribly fast, so that's a good suggestion.  Binary search for Square root after that, the higher value bits should not change very ocasionally.

It will also be checking for button presses, decoding rotary encoder, and displaying on an LCD module.  I'm using schmitt trigers with 2 resisters and a cap to debounce as it makes life simpler and the capacitor discharge current when the switch closes through a small resistor should avoid dry switching issues, same method for the rotary encoders. The capacitor will charge through the discharge resistor and a charge resistor, the recharge time will be long enough that the scmitt trigger only outputs one transition.

I won't be building the whole thing till next month, fixed income and I'll also be laying out a couple of boards.  A DAC will control a SEPIC dc-dc converter, and I'll use external ADC to measure the thermocouple voltage after amplification.  I'll use the AVR ADC to monitor currents and voltages for fault indication (i.e. open heater)  I have some nice beefy current sense resistors I'll amplify the voltage for the current measurement (5 milliohm) on the low side, depending on deals I can find I may use other resistors, I'll have to use a different value of current sense resistor for the switching controller (that'll prevent problems if the heater shorts some how.  I'll be prototyping a single channel on the bench for circuit verification/debugging.  During testing I'll use an AVR output to monitor the idle time and make sure I have enough headroom (i.e. I'll monitor that pin with my scope).

Working on this has made my brain happy, I like complexity, and steep learning curves.  I'll probably put the desin out as a torrent until I can get a Web page up (still have to get a domain), fortunately I know someone who's does websites professionally who can help me with any problems/confusion about HTML etc.  I'll probably run the site on a raspberry pi.  Fortunately I'm blessed with gigabit symetric internet.  I'll actually be using an Arduino board, if necessary I can use another compiler as I do have a JTAG tool I could program it with.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 12, 2020 12:51 AM, Richard Prosser <[hidden email]> wrote:

> How fast is the input changing? if only slowly wrt the sampling rate you
> made be able to speed things up by using an estimate based on the current
> value. 400 times per second with a 16MHz clock sounds quite do-able to me,
> unless the processor is doing a lot of other stuff as well.
> if you have spare memory, you can speed things up with a lookup table to
> get you close also.
>
> Richard P
>
> On Sat, 12 Sep 2020 at 14:49, madscientistatlarge <
> [hidden email]> wrote:
>
> > I found search results eventually on the web. The successive
> > approximation looks pretty fast, if done in assembler which shouldn't be
> > too hard for me. I've manually compiled small pieces of code for a 6502 in
> > a apple][, and a z80, had a course on motorola 68K assembler and had no
> > problem with a 20 page program (based on a 2 page pascal program we were
> > told to redo in assembler). In the 68K program I wrote code for longer
> > multiplication by spliing the numbers, doing 4 multiplies and adding. On
> > the 68k code I only had one error, off by one which I thought I might have,
> > and found a bug in the compiler for one of the many compare functions, I
> > used another one that reacted to the flags in the same way to get around
> > it. People thought I was crazy typing in comments before I had it working.
> > That was a couple of decades ago but I think I can learn a new assembler
> > for such a small piece of code pretty easily, Especially since I found
> > examples on the web. Risc instruction set would likely be a bit harder for
> > me but should be doable by me. I also calculated 40,000 as total available
> > cycles, obviously there's other code but it's simple in this case so C
> > should be fast enough outside the square root calculation.
> > This is the first project I've done in awhile but I've had plenty of time
> > to tweak the design of the other hardware. I'd like to do it this way to
> > cut EMI, I'll hopefully be doing some ham radio before long so I'd like to
> > keep the bench somewhat quite (Yes, I know I spelled it wrong, having
> > trouble finding the correct spelling, I am terrible at spelling). Not
> > putting a high power pwm signal on external unshielded cables should help
> > with that, as well as helping with whatever else I'm working on. There
> > will be 4 of these signals, at up to 240 Watts each so obviously it could
> > really radiate! Each channel will be adjusted 100 times per second. I'm
> > designing myself a "universal" soldering/desolering station that I can use
> > with any 4 irons by putting a new connector on them with a serial eeprom in
> > the connector to tell the station what the specs are for a particular
> > iron. This will be fun. I will write it all up and ideally put it on the
> > web.
> > Sent with ProtonMail Secure Email.
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, September 11, 2020 8:10 PM, Christopher Head [hidden email]
> > wrote:
> >
> > > On Sat, 12 Sep 2020 00:48:16 +0000
> > > madscientistatlarge [hidden email] wrote:
> > >
> > > > Sorry, that should be square root (time for a nap). It would be on
> > > > an atmega2560 AVR, running at 16MHZ.
> > >
> > > 16-bit sounds easily within reason to me. My go-to integer square root
> > > implementation is a binary search: “for each bit from N−1 downto 0, try
> > > turning it on, square that number, if the square is ≤ the input then
> > > keep the bit, otherwise clear it”. There may be better ones, but I’ve
> > > found this to be something that can be implemented in an extremely
> > > tight loop, in assembly if necessary, quite easily (or unrolled if you
> > > want to absolutely max out performance). It looks like the 2560 has a
> > > hardware multiplier—I assume probably 8×8→16—which should make this
> > > doable in just a few dozen cycles, out of a budget of 40,000!
> > > 20-bit, you’d just have to synthesize the larger multiplication
> > > operation. It is also possible to rip the SQRT into pieces and do some
> > > subtractions so you don’t have to deal with all 20 bits on every cycle.
> > > Doing it in C, YMMV, especially if you do larger-than-CPU-native-size
> > > multiplies. Assembly should be fine though.
> > > This is all assuming you want a floored integer output and don’t care
> > > about the fractional part!
> >
> > > Christopher Head
> > >
> > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > > View/change your membership options at
> > > http://mailman.mit.edu/mailman/listinfo/piclist
> >
> > --
> > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
>
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist



--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

madscientistatlarge
In reply to this post by Sean Breheny
Another great suggestion, I'll try that when I'm prototyping.

I do have a tendency to over engineer stuff, My last electronics job was for a company that made an absolute gravimeter that measured local gravity to 13 significant figures, sensitive enough to detect an elevation change of about 1/8 inch or be driven crazy if there's a floor about where it's setup with people moving.  To make it any more precise would actually require knowing the air pressure at about 100 altitudes.  It had to be compensated for the moon and tides even when inland.  We sold them for about $500K.  That was a very fun job, I got to work on high vacuum chambers and we used a rubidium oscillator for the time measurement and an iodine absorption locked laser.  They trained me in several things for backup, and because I often had good suggestions.  I'm an all around science geek.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 12, 2020 1:28 AM, Sean Breheny <[hidden email]> wrote:

> If the power required for your setpoint doesn't vary too much then the v^2
> nonlinearity can be treated as a linear function of slope 2v and you don't
> even need to perform a square root for your PID loop.
>
> On Sat, Sep 12, 2020, 2:38 AM Richard Prosser <[hidden email] wrote:
>
> > How fast is the input changing? if only slowly wrt the sampling rate you
> > made be able to speed things up by using an estimate based on the current
> > value. 400 times per second with a 16MHz clock sounds quite do-able to me,
> > unless the processor is doing a lot of other stuff as well.
> > if you have spare memory, you can speed things up with a lookup table to
> > get you close also.
> > Richard P
> > On Sat, 12 Sep 2020 at 14:49, madscientistatlarge <
> > [hidden email]> wrote:
> >
> > > I found search results eventually on the web. The successive
> > > approximation looks pretty fast, if done in assembler which shouldn't be
> > > too hard for me. I've manually compiled small pieces of code for a 6502
> > > in
> > > a apple][, and a z80, had a course on motorola 68K assembler and had no
> > > problem with a 20 page program (based on a 2 page pascal program we were
> > > told to redo in assembler). In the 68K program I wrote code for longer
> > > multiplication by spliing the numbers, doing 4 multiplies and adding. On
> > > the 68k code I only had one error, off by one which I thought I might
> > > have,
> > > and found a bug in the compiler for one of the many compare functions, I
> > > used another one that reacted to the flags in the same way to get around
> > > it. People thought I was crazy typing in comments before I had it
> > > working.
> > > That was a couple of decades ago but I think I can learn a new assembler
> > > for such a small piece of code pretty easily, Especially since I found
> > > examples on the web. Risc instruction set would likely be a bit harder
> > > for
> > > me but should be doable by me. I also calculated 40,000 as total
> > > available
> > > cycles, obviously there's other code but it's simple in this case so C
> > > should be fast enough outside the square root calculation.
> > > This is the first project I've done in awhile but I've had plenty of time
> > > to tweak the design of the other hardware. I'd like to do it this way to
> > > cut EMI, I'll hopefully be doing some ham radio before long so I'd like
> > > to
> > > keep the bench somewhat quite (Yes, I know I spelled it wrong, having
> > > trouble finding the correct spelling, I am terrible at spelling). Not
> > > putting a high power pwm signal on external unshielded cables should help
> > > with that, as well as helping with whatever else I'm working on. There
> > > will be 4 of these signals, at up to 240 Watts each so obviously it could
> > > really radiate! Each channel will be adjusted 100 times per second. I'm
> > > designing myself a "universal" soldering/desolering station that I can
> > > use
> > > with any 4 irons by putting a new connector on them with a serial eeprom
> > > in
> > > the connector to tell the station what the specs are for a particular
> > > iron. This will be fun. I will write it all up and ideally put it on
> > > the
> > > web.
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Friday, September 11, 2020 8:10 PM, Christopher Head [hidden email]
> > > wrote:
> > >
> > > > On Sat, 12 Sep 2020 00:48:16 +0000
> > > > madscientistatlarge [hidden email] wrote:
> > > >
> > > > > Sorry, that should be square root (time for a nap). It would be on
> > > > > an atmega2560 AVR, running at 16MHZ.
> > > >
> > > > 16-bit sounds easily within reason to me. My go-to integer square root
> > > > implementation is a binary search: “for each bit from N−1 downto 0, try
> > > > turning it on, square that number, if the square is ≤ the input then
> > > > keep the bit, otherwise clear it”. There may be better ones, but I’ve
> > > > found this to be something that can be implemented in an extremely
> > > > tight loop, in assembly if necessary, quite easily (or unrolled if you
> > > > want to absolutely max out performance). It looks like the 2560 has a
> > > > hardware multiplier—I assume probably 8×8→16—which should make this
> > > > doable in just a few dozen cycles, out of a budget of 40,000!
> > > > 20-bit, you’d just have to synthesize the larger multiplication
> > > > operation. It is also possible to rip the SQRT into pieces and do some
> > > > subtractions so you don’t have to deal with all 20 bits on every cycle.
> > > > Doing it in C, YMMV, especially if you do larger-than-CPU-native-size
> > > > multiplies. Assembly should be fine though.
> > > > This is all assuming you want a floored integer output and don’t care
> > > > about the fractional part!
> >
> > > > Christopher Head
> > > >
> > > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > > > View/change your membership options at
> > > > http://mailman.mit.edu/mailman/listinfo/piclist
> > >
> > > --
> > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > > View/change your membership options at
> > > http://mailman.mit.edu/mailman/listinfo/piclist
> >
> > --
> > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
>
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist



--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

enkitec
In reply to this post by madscientistatlarge

     You could eliminate the DAC and emulate the SEPIC converter in
software with the AVR.

     Just to complicate things a little...

     Regards,
     Mark Jordan


On 12-Sep-20 05:44, madscientistatlarge wrote:
> A DAC will control a SEPIC dc-dc converter, and I'll use external ADC to measure the thermocouple voltage after amplification.  I'll use the AVR ADC to monitor currents and voltages for fault indication (i.e. open heater)

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

madscientistatlarge
That had occured to me, but the switching frequency would be low and require large capacitors and inductors.  Mine will run the switcher at 500KHZ which makes the power supply parts smaller.  Also it would be much less robust if I did it that way.  DACs aren't that expensive for 10-12 bits.  I want somewhat fine drive adjustment for better temperature control, which would require a much lower frequency to get the resolution.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 12, 2020 6:28 AM, <[hidden email]> wrote:

> You could eliminate the DAC and emulate the SEPIC converter in
> software with the AVR.
>
>     Just to complicate things a little...
>
>     Regards,
>     Mark Jordan
>
> On 12-Sep-20 05:44, madscientistatlarge wrote:
>
> > A DAC will control a SEPIC dc-dc converter, and I'll use external ADC to measure the thermocouple voltage after amplification. I'll use the AVR ADC to monitor currents and voltages for fault indication (i.e. open heater)
>
> --
>
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist



--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

Dave Tweed
In reply to this post by madscientistatlarge
> I could use the last value as a starting value for the square root.
> Obviously the iron temperature won't be changing terribly fast, so
> that's a good suggestion.

Indeed, a single iteration of Newton-Raphson should be all you need.

In the case of square root, all you need to do is divide the current input
by the previous sqaure root, and then average that result with the previous
square root to get the new square root.

The "rule of thumb" with this method is that the number of correct bits
in the answer is basically doubled on each iteration. So as long as the
temperature hasn't changed enough to invalidate half of the bits in the
current answer, you're good to go.

Even at startup, when the "previous answer" is simply taken as some fixed
nonzero value (e.g., 2), this will converge within a few cycles to the
correct answer.

-- Dave Tweed
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

madscientistatlarge
That was an excellent suggestion.  I would say I wanted to take the square root of the power calculated with PID, because I'm varying the DC voltage to the heater.  If I did it with PWN the duty cycle would be directly proportional to the power and hence no square root.  I'll only be monitoring the current and converter output voltage for fault protection, hence noise won't be a problem.  I'll be putting the thermocouple amplifier/ digitizer in it's own box inside, And I'll put the switching converters in another.  I'll finally be using some of my altoids tins.  FYI, I'll be using an HP server supply to provide 12V for the other rails.  As I said they can be had for less than $20 on ebay, and the SMbus will also provide potentially valuable data.  They also provide a nice 12V output when "off" that I can use to keep the AVR going.  I'll probably display the time even when it's "off", with a real power switch on the back for issues.

I'll also set it for an adjustable auto off period, I've left way to many irons on accidentally, which makes it hard to maintain the tips and cooks them up nicely.  I will be using mostly tin/lead solder which helps but no iron likes cooking for hours without tending.  At my last real electronics job the first thing I always did to the soldering station was turn the heat down 50 Deg F, and then clean and retin the tip.  I made the fastest and best solder joint of anyone in that small company, including someone who'd done assembly work.  My through hole soldering always had some solder on the pad on top of the board.  Some people don't realize that taking the time to take care of tools saves you more time than the maintenance took.  Not to mention that running the iron 50 Deg F warmer eats tips much faster and makes the surface oxidize faster.

When I was in middle school summers were boring (3 miles from a tiny town), I desoldered a lot of parts off old boards and that taught me a great deal, especially since the nearest radio shack was 30 minutes away in a car.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 12, 2020 9:07 AM, Dave Tweed <[hidden email]> wrote:

> > I could use the last value as a starting value for the square root.
> > Obviously the iron temperature won't be changing terribly fast, so
> > that's a good suggestion.
>
> Indeed, a single iteration of Newton-Raphson should be all you need.
>
> In the case of square root, all you need to do is divide the current input
> by the previous sqaure root, and then average that result with the previous
> square root to get the new square root.
>
> The "rule of thumb" with this method is that the number of correct bits
> in the answer is basically doubled on each iteration. So as long as the
> temperature hasn't changed enough to invalidate half of the bits in the
> current answer, you're good to go.
>
> Even at startup, when the "previous answer" is simply taken as some fixed
> nonzero value (e.g., 2), this will converge within a few cycles to the
> correct answer.
>
> -- Dave Tweed
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist



--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

sergio
In reply to this post by Dave Tweed


On Sat, 12 Sep 2020, Dave Tweed wrote:

>> I could use the last value as a starting value for the square root.
>> Obviously the iron temperature won't be changing terribly fast, so
>> that's a good suggestion.
>
> Indeed, a single iteration of Newton-Raphson should be all you need.
>
> In the case of square root, all you need to do is divide the current input
> by the previous sqaure root, and then average that result with the previous
> square root to get the new square root.

But....

Calculating the square root can be done is a similar manner to binary long
division. Just a couple of extra instructions per iteration. No need for
hardware assisted multiply or big look up tables. And for a 16 bit
argument you're looking at 8 iterations max. Just use (arg-n)^2 in place
of (arg-n) for division (where n is a power of 2).

Regards
Sergio Masci
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

[PIC]: fast square root

sergio
xsqrt is a fast square root function that works in a similar way to the
standard binary long division. It does not use hardware (or software)
multiply to successivly approximate the square root, nor does it use
tables (although one could be used to more quickly count the number of
bits used in the argument).

http://xcprod.com/SQRT/

Regards
Sergio Masci
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

[PIC]: faster square root

sergio
Further optimisations now obviate the need to maintain seperate "x" and
"n" in the main loop.

After I posted my original announcement I decided to put a link up on
Wikipedia and in the process discovered:

https://web.archive.org/web/20120306040058/http://medialab.freaknet.org/martin/src/sqrt/sqrt.c

This is "similar" to my method but uses the dreaded multiply and has a
restriction on the sign bit. Anyway Martin Guy's algorithm (based on a
book by Mr C. Woo) does not maintain seperate "x", "n", "x^2" and "n^2" so
I knew it should be possible for me to further optimise my code. I have
now posted my new code together with an explination to show how the
optimisation was derived.

http://xcprod.com/SQRT/

Regards
Sergio Masci

On Mon, 14 Sep 2020, sergio wrote:

> xsqrt is a fast square root function that works in a similar way to the
> standard binary long division. It does not use hardware (or software)
> multiply to successivly approximate the square root, nor does it use
> tables (although one could be used to more quickly count the number of
> bits used in the argument).
>
> http://xcprod.com/SQRT/
>
> Regards
> Sergio Masci
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [PIC]: faster square root

Christopher Head-7
On Wed, 16 Sep 2020 12:58:52 +0100 (BST)
sergio <[hidden email]> wrote:

> This is "similar" to my method but uses the dreaded multiply

Why dread multiply? ATmega2560 has a hardware multiplier. Certainly
it’s helpful to have such algorithms around for
non-hardware-multiply-equipped processors, but in this particular
situation, the OP already chose a processor which has a multiplier, so
why not pick something simple and fast that uses it?
--
Christopher Head

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [PIC]: faster square root

madscientistatlarge
I recommend the book "Numerical recipes in C"  I may try a couple of ways just to compare them and hopefully learn something.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, September 16, 2020 8:34 AM, Christopher Head <[hidden email]> wrote:

> On Wed, 16 Sep 2020 12:58:52 +0100 (BST)
> sergio [hidden email] wrote:
>
> > This is "similar" to my method but uses the dreaded multiply
>
> Why dread multiply? ATmega2560 has a hardware multiplier. Certainly
> it’s helpful to have such algorithms around for
> non-hardware-multiply-equipped processors, but in this particular
> situation, the OP already chose a processor which has a multiplier, so
> why not pick something simple and fast that uses it?
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Christopher Head
>
> -----------------
>
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist



--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [PIC]: faster square root

sergio
In reply to this post by Christopher Head-7


On Wed, 16 Sep 2020, Christopher Head wrote:

> On Wed, 16 Sep 2020 12:58:52 +0100 (BST)
> sergio <[hidden email]> wrote:
>
>> This is "similar" to my method but uses the dreaded multiply
>
> Why dread multiply?

In my experience "hardware multiplier" for a microprocessor often comes
with a lot of restrictions or hidden overheads. Sometimes this comes down
to loading the arguments into special registers and then storing the
result before it can be further used in a calculation, sometimes specific
general purpose registers are used which greatly affect the way a compiler
is able to optimise the rest of the code, sometimes the hardware
multiplier takes a lot of cycles to execute. On the other hand a simple
shift (in my experience) is often much easier to use with very few
restrictions or hidden overheads (and more often much faster to execute
than a multiply even when done in hardware).

> ATmega2560 has a hardware multiplier.

I don't know what restrictions or hidden overheads the ATmega2560 hardware
multiplier has.

> Certainly
> it’s helpful to have such algorithms around for
> non-hardware-multiply-equipped processors, but in this particular
> situation, the OP already chose a processor which has a multiplier, so
> why not pick something simple and fast that uses it?

Because without serious modifications (and speed penalties), that tie him
to a CPU / MCU with an 8x8 multiply, the alternative algorithm (using
shifts) can easily be extended to provide a fractional component to the
result (say 4 bits to give one decimal place).

Regards
Sergio Masci
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

Zona-3
In reply to this post by madscientistatlarge
You can find one in source code of DOOM.
which was running on 66MHz x86, supply a 3D battle field.


On Sat, 12 Sep 2020 00:48:16 +0000
madscientistatlarge <[hidden email]> wrote:

> Sorry, that should be square root (time for a nap).  It would be on
> an atmega2560 AVR, running at 16MHZ.
>
>
> Sent with ProtonMail Secure Email.
>
>
>
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist


--
BR.
----
Zona <[hidden email]>
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [AVR] square on AVR

Mike Rigby-Jones
The Doom square root is a very clever bit of code, but it relies on the
32bit floating point format which you probably won't be using on an AVR
if speed is important.

Mike

On 17/09/2020 07:35, Zona wrote:

> You can find one in source code of DOOM.
> which was running on 66MHz x86, supply a 3D battle field.
>
>
> On Sat, 12 Sep 2020 00:48:16 +0000
> madscientistatlarge <[hidden email]> wrote:
>
>> Sorry, that should be square root (time for a nap).  It would be on
>> an atmega2560 AVR, running at 16MHZ.
>>
>>
>> Sent with ProtonMail Secure Email.
>>
>>
>>
>> --
>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [PIC]: faster square root

sergio
In reply to this post by madscientistatlarge


On Wed, 16 Sep 2020, madscientistatlarge wrote:

> I recommend the book "Numerical recipes in C"  I may try a couple of ways just to compare them and hopefully learn something.
>

Your original question:

> Is it reasonable to calculate the square root of a 16 bit or preferably
> 20 bit integer?  I'll need to do this 400 times a second.

I guess I should have just replied: yes easily

Regards
Sergio Masci
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
12