Floating Point DSP from Microchip (?)

Hello Anand, I'll bet that you are correct, in that the Microchip microcontroller chips do not have high-speed 'hardware multiply' capability.

At:

their PIC24 microcontroller chip requires 81 clock cycles to perform one floating point multiply.

Good Luck, [-Rick-]

"Anand P. Paralkar" wrote in news: snipped-for-privacy@mid.individual.net:

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

nice to see you around, Al. it's been a few weeks or months. you and Lori Ann okay?

--

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

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.

Thanks, Anand

then per unit cost is not an issue.

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

also how is the valve physically controlled? how is the position or state of the valve measured? how will these values get in and out of the DSP (or CPU or MPU or whatever the chip is)?

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.

--

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

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

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

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.

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

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.

Agreed. Except that, now I need an algorithm to know my algorithm! :)

If you are attempting proportional control with a pneumatic actuator in the loop then I wish luck - you are going to need it ! It is WAY too soon to be worrying about the processor. First you need a model of your system, then you can attempt to model the control loop, then you will KNOW who much maths the processor needs to do. I would start by building a system model in SIMULINK (or MAPLE SIM) - if you don't have tools like that available you will need to do it some other way. You will very likely find that you can't get the parameters you need for the model from the part manufacturers and you will need to measure them yourself. Is this a commerical or a study project ?

Michael Kellett

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!

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

--
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 > "Anand P. Paralkar" writes:

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.

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
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

(snip, someone wrote)

You might get one, though.

(snip)

(snip)

(snip)

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

ol.

use a couple of op-amps.

robert bristow-johnson wrote in news:jn5ag7$7aj$ snipped-for-privacy@dont-email.me:

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

Al

>

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

--Randy

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

"Anand P. Paralkar" wrote in news: snipped-for-privacy@mid.individual.net:

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

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.

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.