Floating Point DSP from Microchip (?)

PSS: I believe you can get one of their evaluation boards on the cheap
($50?), complete with a limited version of the debugger and JTAG. 

Randy Yates <yates@digitalsignallabs.com> writes:

> "Anand P. Paralkar" <anand.paralkar@gnospammale.com> writes:
>> [...]
>
> Anand,
>
> Have you considered the TI TMS320F2806x Piccolo series? They operate to
> 80 MHz and have a Control Law Accelerator - basically an integrated,
> low-level coprocessor that can interface directory with the A/D for
> low-latency processing and MIPS-intensive front-end processing such as
> filtering and decimation.
>
> They also have a floating point unit so you could use floating point at
> least initially and then go to fixed-point later. 
>
> Finally, there's also a VCU (Viterbi/Complex Unit) for accelerating
> certain operations. 
>
> Depending on the algorithm you could probably run this at a sample rate
> as high as 1 MHz. (We are!)
>
> --Randy
>
> PS: I sound like a TI salesman/rep - I am not!
>
>
>> On 24-04-2012 11:00, robert bristow-johnson wrote:
>>
>>> what's your sampling rate expected to be? if the sampling rate is slow
>>> enough, you could do this with any chip, even those that don't know how
>>> to multiply (where you have a routine to do that).
>>
>> Don't know as yet.  Since this is not an application with a natural
>> signal (audio/video and the like) as it's start point, I am having a
>> tough time figuring this out.  I have an ominous feeling that it will
>> be what it will be after I have finished implementing everything! :|
>>
>>>
>>> also how is the valve physically controlled?
>>
>> Using a pneumatic control block that takes a two bit digital input.
>>
>> 00 => chamber A to B (this results in valve open)
>> 01 => chamber B to A (results in valve close)
>> 10 => stop
>> 11 => not allowed
>>
>> this pneumatic control block will get a pwm input from the pid controller.
>>
>>>how is the position or
>>> state of the valve measured?
>>
>> Either a resistance (generated by a position indicating rheostat)
>> converted to voltage or a current (4 - 20 ma) converted to voltage.
>>
>> Even the set point will be indicated using a 4 - 20 mA signal.
>>
>> how will these values get in and out of the
>>> DSP (or CPU or MPU or whatever the chip is)?
>>
>> Using an ADC of a suitable resolution (basically whatever the DSP
>> offers) and a suitable front-end.  I will probably use a low pass
>> filter here.  I am yet to figure out what will be the cut-off
>> frequency.
>>
>>>
>>> FWIW, floating point looks ostensibly easier and safer, but it is not
>>> always and then when bad things happen, it can be harder to find and
>>> deal with using floating point.
>>>
>>> case in point: denormalized numbers.
>>>
>>> another case in point: a digital integrator used in a moving sum operation.
>>>
>>> lastly, it's generally important to know your algorithm so well that you
>>> have an idea for how big numbers can get at any "node" in the alg. once
>>> you know that, you're in just as good of a position to do this in fixed
>>> point as you are in floating point.
>>>
>>
>> Agreed.  Except that, now I need an algorithm to know my algorithm! :)

-- 
Randy Yates
DSP/Firmware Engineer
919-577-9882 (H)
919-720-2916 (C)

Yup,  that's the one that looks most likely - TMS320F28069.  Thanks for 
the suggestion.  (Kind of validates my search.)

Thanks,
Anand

P.S.: If only *salesman* could talk with this much clarity. ;)

On 24-04-2012 13:04, Randy Yates wrote:
> "Anand P. Paralkar"<anand.paralkar@gnospammale.com>  writes:
>> [...]
>
> Anand,
>
> Have you considered the TI TMS320F2806x Piccolo series? They operate to
> 80 MHz and have a Control Law Accelerator - basically an integrated,
> low-level coprocessor that can interface directory with the A/D for
> low-latency processing and MIPS-intensive front-end processing such as
> filtering and decimation.
>
> They also have a floating point unit so you could use floating point at
> least initially and then go to fixed-point later.
>
> Finally, there's also a VCU (Viterbi/Complex Unit) for accelerating
> certain operations.
>
> Depending on the algorithm you could probably run this at a sample rate
> as high as 1 MHz. (We are!)
>
> --Randy
>
> PS: I sound like a TI salesman/rep - I am not!
>
>

In article <4F965004.8030808@gnospammale.com>, 
anand.paralkar@gnospammale.com says...
> 
> On 24-04-2012 11:00, robert bristow-johnson wrote:
> 
> > what's your sampling rate expected to be? if the sampling rate is slow
> > enough, you could do this with any chip, even those that don't know how
> > to multiply (where you have a routine to do that).
> 
> Don't know as yet.  Since this is not an application with a natural 
> signal (audio/video and the like) as it's start point, I am having a 
> tough time figuring this out.  I have an ominous feeling that it will be 
> what it will be after I have finished implementing everything! :|
> 
> >
> > also how is the valve physically controlled?
> 
> Using a pneumatic control block that takes a two bit digital input.
> 
> 00 => chamber A to B (this results in valve open)
> 01 => chamber B to A (results in valve close)
> 10 => stop
> 11 => not allowed
> 
> this pneumatic control block will get a pwm input from the pid controller.
> 
> >how is the position or
> > state of the valve measured?
> 
> Either a resistance (generated by a position indicating rheostat) 
> converted to voltage or a current (4 - 20 ma) converted to voltage.
> 
> Even the set point will be indicated using a 4 - 20 mA signal.

Know your real world PHYSICAL limits first !!!!

1/ How fast does the pneumatic control block take to operate

2/ In your setup how long from valve operating, to seeing effect
   at your sensor.

3/ Does your sensor get affected by temperature of ambient and
   the item it is sensing. Or for that matter vibration from the 
   material that is being sensed or other actions even the valve
   operating. IE will the valve cause a pulse surge in flow or just
   plain send vibrations the sensor can pick up.

4/ What algorithms do you need to put around the sensors and outputs
   to detect broken or stuck sensor, or even pneumatic valve stuck.

These help determine the latency of the system and how that will
effect your control loop and the numbers.

A lot of this will determine sampling rate and  loop frequency.

Run sampling or loop too fast and you need all sorts of tiny multipliers
to overcome the repeated samples of smae position because the real world
has not changed yet. Also Integrators will reach saturation point or 
worse still overflow/wrap around causing numerical problems.

In other words do not run loop much faster than the fastest response 
time or sample sensors at MHz if they only change at Hz rates.

By sound of things this is going to very fairly slow, compared to
some controllers I have worked on with fast response light controllers
with photodiode sensors.

> how will these values get in and out of the
> > DSP (or CPU or MPU or whatever the chip is)?
> 
> Using an ADC of a suitable resolution (basically whatever the DSP 
> offers) and a suitable front-end.  I will probably use a low pass filter 
> here.  I am yet to figure out what will be the cut-off frequency.
> 
> >
> > FWIW, floating point looks ostensibly easier and safer, but it is not
> > always and then when bad things happen, it can be harder to find and
> > deal with using floating point.
> >
> > case in point: denormalized numbers.
> >
> > another case in point: a digital integrator used in a moving sum operation.
> >
> > lastly, it's generally important to know your algorithm so well that you
> > have an idea for how big numbers can get at any "node" in the alg. once
> > you know that, you're in just as good of a position to do this in fixed
> > point as you are in floating point.
> >
> 
> Agreed.  Except that, now I need an algorithm to know my algorithm! :)

Understand all the physics and time delays of the controls, sensors, and
the object being controlled/measured by them.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

In comp.dsp robert bristow-johnson <rbj@audioimagination.com> wrote:

(snip, someone wrote)
>> Hope I do not end-up triggering a huge "Floating Point vs Fixed Point"
>> debate here. I am trying to implement a PID controller for valve 
>> control.

You might get one, though.

(snip)
> what's your sampling rate expected to be?  if the sampling rate is slow 
> enough, you could do this with any chip, even those that don't know how 
> to multiply (where you have a routine to do that).

(snip)
> FWIW, floating point looks ostensibly easier and safer, but it is not 
> always and then when bad things happen, it can be harder to find and 
> deal with using floating point.

(snip)
> lastly, it's generally important to know your algorithm so well that you 
> have an idea for how big numbers can get at any "node" in the alg.  once 
> you know that, you're in just as good of a position to do this in fixed 
> point as you are in floating point.

It seems to me that working with fixed point numbers isn't taught
in as much detail as it should be. Then again, maybe not floating
point, either. I did know some years ago, a class for actuarial
students on the properties of floating point.

We learn add, subtract, multiply, and finally division with 
remainder (in fixed point) in elementary school, and are expected 
to keep using what we learned. 

It would seem to me that a valve position would not have a huge
dynamic range. That if 16 bit fixed point wasn't enough, then
use 24 bit or 32 bit. 

-- glen

On Apr 24, 4:59=A0pm, "Anand P. Paralkar"
<anand.paral...@gnospammale.com> wrote:
> Hope I do not end-up triggering a huge "Floating Point vs Fixed Point"
> debate here. =A0I am trying to implement a PID controller for valve contr=
ol.
>

use a couple of op-amps.

robert bristow-johnson <rbj@audioimagination.com> wrote in
news:jn5ag7$7aj$1@dont-email.me: 

> On 4/23/12 11:59 PM, Al Clark wrote:
>>
>>
>> As far as I know, Microchip does not have a floating point device.
>> Generally speaking, floating point emulation is very inefficient with
>> fixed point processors and more times than not, a bad idea if you care
>> about performance. It's usually better to use a fixed point version of
>> the function or migrate to a device with native floating point support.
>>
>> OTOH, Devices that support floating point are usually very good fixed
>> point processors as well.
>>
>> ADI and TI are the main floating point players. What are you trying to
>> do? 
>>
>> Al Clark
>> www.danvillesignal.com
> 
> nice to see you around, Al.  it's been a few weeks or months.  you and 
> Lori Ann okay?

Just very busy - I have been mostly lurking....

Al
> 

Al Clark <aclark@danvillesignal.com> writes:

> robert bristow-johnson <rbj@audioimagination.com> wrote in
> news:jn5ag7$7aj$1@dont-email.me: 
>
>> On 4/23/12 11:59 PM, Al Clark wrote:
>>>
>>>
>>> As far as I know, Microchip does not have a floating point device.
>>> Generally speaking, floating point emulation is very inefficient with
>>> fixed point processors and more times than not, a bad idea if you care
>>> about performance. It's usually better to use a fixed point version of
>>> the function or migrate to a device with native floating point support.
>>>
>>> OTOH, Devices that support floating point are usually very good fixed
>>> point processors as well.
>>>
>>> ADI and TI are the main floating point players. What are you trying to
>>> do? 
>>>
>>> Al Clark
>>> www.danvillesignal.com
>> 
>> nice to see you around, Al.  it's been a few weeks or months.  you and 
>> Lori Ann okay?
>
> Just very busy - I have been mostly lurking....

I'm glad you "unlurked" - Good to hear from you, Al!

--Randy

>
> Al
>> 
>

-- 
Randy Yates
DSP/Firmware Engineer
919-577-9882 (H)
919-720-2916 (C)

"Anand P. Paralkar" <anand.paralkar@gnospammale.com> wrote in
news:9vmvu9F8amU1@mid.individual.net: 

> Hope I do not end-up triggering a "Floating Point vs Fixed Point" debate
> here.  :) I am trying to implement a PID controller for valve control.

I don't think this application will trigger the float/fixed debate. I think 
the others have given you good advice. Understand your system requirements 
first.

PID controllers do not take very many MIPs, at least with slow mechanical 
systems. Any DSP will probably have MIPs to burn. A SHARC would probably 
use less than 1% of its theoretical computation power. 

Since this is a limited production application, the cost of the processor 
is irrelevant. I would use whatever you want to become more proficient at 
once you understand what you need to implement. 

If you want the easy option of using either fixed or float then a SHARC is 
a good candidate (perhaps ADSP-21489) since it does both equally well (32 
bit fixed or 32/40 bit float). The TI camp can probably make a similar 
case.

Al Clark
www.danvillesignal.com
 

   







> 
> I read through a bit of the literature that is available on making a 
> choice between Floating Point and Fixed Point.  For a newbie in signal 
> processing like me, Floating Point seems to be the easiest and safest 
> thing to use.  (Especially, given the fact that it is going to be a 
> custom built product and not destined for production en mass.)
> 
> Your comments regarding the choice of processor or any aspect about PID 
> control for valve positioning are welcome.
> 
> Thanks,
> Anand
> 
> 

On Tue, 24 Apr 2012 03:59:16 GMT, Al Clark <aclark@danvillesignal.com>
wrote:

>
>As far as I know, Microchip does not have a floating point device. Generally 
>speaking, floating point emulation is very inefficient with fixed point 
>processors and more times than not, a bad idea if you care about performance.
>It's usually better to use a fixed point version of the function or migrate 
>to a device with native floating point support.    

How many embedded applications really do any heavy floating point
operations ? 

OK, if you do a lot of floating point matrix multiplications and
inversions with large arrays, a real HW FP is a must.

However, in most cases the need for floating point processing in the
embedded environment is simply due to constructs like

sprintf (TextString, "Length %6.2f meters", Integer_cm_value/100.0) ;

Thus, the total number of floating point instruction is typically very
low and not justify any FP HW. Of course, the emulation code needs
some space, so there are some tradeoffs to be made.

On Tue, 24 Apr 2012 10:29:32 +0530, "Anand P. Paralkar"
<anand.paralkar@gnospammale.com> wrote:

>Hope I do not end-up triggering a huge "Floating Point vs Fixed Point" 
>debate here.  I am trying to implement a PID controller for valve control.
>
>I read through a bit of the literature that is available on making a 
>choice between Floating Point and Fixed Point.  For a newbie in signal 
>processing like me, Floating Point seems to be the easiest and safest 
>thing to use.  (Especially given the fact that it is going to be custom 
>built and not destined for production en mass.)
>
>Your comments regarding the choice of processor or any aspect about PID 
>control for valve positioning are welcome.

So this is about PID control using pneumatic actuators. 

In practice, do you need sampling rates above 10 Hz, perhaps in
extreme cases perhaps 100 Hz ?

Any processor since the tube era should be able to handle this, with
or without floating processor hardware.