Searching \ for '[PIC:] How much can a PIC do?' 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/devices.htm?key=pic
Search entire site for: 'How much can a PIC do?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] How much can a PIC do?'
2006\02\13@041737 by Denny Esterline

picon face
I've done more than a couple PIC projects but this one's upped the ante and
I'm trying to decide if I should throw a whole handful of PICs at it or
should I move on to something else. I think your considered opinions might
be some use here so...

This is a testbed application for a local engineering college to study some
aspect of vehicle dynamics, I'm under NDA for most of the details, but
here's the broad strokes:
It will be on the car, mostly in the engine compartment (electrical noise
and mass issues)
Primary task is to run a PID loop between a linear encoder and a brushless
motor ~10mS update rate
Monitor several sensors and perform an unspecified (complicated, possibly
floating point) algorithm to control the position of the motor
Sensors include at least one remote node (probably CAN), 3x ADC, 2x timers
and an accelerometer (probably an Analog ADXL...)
Filter and log the data (~40 bytes @ 20Hz for minimum 10 minutes)
Allow non-electronics types to retrieve the data and modify the algorithm in
the field (I'm thinking USB or SD memory card)

Now I've done most of this before with PICs, but never all at the same time.
I'm thinking that I could segment the project and have a separate PIC manage
each task. Something like a PIC18FXX31 with it's quadrature encoder and
motor control hardware could easily handle the servo, another PIC to monitor
the sensors, one more to process the algorithm. Put them all on some type of
bus and add another to just sniff the bus and log the relevant data.

Sure, it's a plan - but is it a good plan?

There's obviously other options, even in the MChip family, a DSPIC or one of
the new PIC24s. Or I could just move on to something else ARM7, ARM9,
Freescale 56F8xxx, FPGA with soft core(s), PC104 SBC, etc, etc.

Thoughts?

-Denny

2006\02\13@044509 by Wouter van Ooijen

face picon face
> Sure, it's a plan - but is it a good plan?

I would prefer a one-chip solution. Make an estimate of the CPU time
needed (both PID calculations and hardware control), and then decide
what you need. There is a lot of choice even within Microchip's product,
but when you would need a dsPIC level chip I would personally prefer an
ARM instead. I would consider FPGA's only when you need something that
can be done easily in hardware and is realy too CPU-heavy to do on a
CPU.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\13@044623 by Alan B. Pearce

face picon face
>It will be on the car, mostly in the engine compartment
>(electrical noise and mass issues)

Electrical noise, yes, Mass - why would that be a problem?, I would have
thought temperature would be the other major problem.

>Primary task is to run a PID loop between a linear encoder
>and a brushless motor ~10mS update rate
>Monitor several sensors and perform an unspecified
>(complicated, possibly floating point) algorithm to control
>the position of the motor

Well that lot would look ideal for a dsPic to me - especially as they seem
to have a family of them with this style of problem in mind.

{Quote hidden}

I would have thought that a single dsPic could handle this lot with ease,
considering that many ECU units seem to use considerably less capable
micros. Use an I2C or SPI EEPROM for the logging, and have the log block
size the same size as the block size of the chip means that it would write
as fast as you could feed a block, then wait for the next block. Alternative
here would be FRAM which doesn't have the block or write time constraints.
Almost all the dsPics have CAN IIRC (some have 2 CAN ports) and with the DSP
core any of the calculations should be easy. IIRC there is a quadrature
encoder handler as well - it becomes a case of spending 2-3 hours at most
sorting through the dsPic options between the families, but I do get the
impression that one of the motor family would handle your requirements. And
with the PLL giving high internal clock speeds I doubt you would run out of
computing power.

2006\02\13@045724 by Bob Axtell

face picon face
I usually break it up into several PICs. The main PIC for Master
communications
and executive functions. Then each motor would control each main task,
communicated
to by RS232 serial or a proprietary scheme. A Master with two uarts is
helpful, and
one with a deep PGM array to allow a floating point math unit and
conversions.

The problem with a huge ARM (or whatever) is that no matter what is
processed, only
ONE task happens at a time. With multiple PICs, an AWESOME amount of
processing can be done simultaneously, such as positioning 3 different
motors. Even
if an ARM can run at 80Mhz, it  will be outprocessed by  3 peripheral
16F88s  at 20Mhz
and an 18F at 40Mhz.

The secondary PICs are extremely  helpful controlling stepper motors  or
DC motors with
quad tach positioning sensors, or controlling 12-bit D/A outputs. Each
secondary PIC
controls one motor or one DAC. Since each PIC has a unique communication
address
and shares a serial bus, there is no confusion. I'd use clone ICD2's to
handle the F88's,
and an MC ICD2 for the main processor.

--Bob



Denny Esterline wrote:

{Quote hidden}

--
Note: To protect our network,
attachments must be sent to
spam_OUTattachTakeThisOuTspamengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\13@051143 by Sean Schouten

face picon face
Hi Denny,

There is nothing wrong with dividing the workload over a couple of
PicMicros. Although I am no mission-critical embedded application
specialist, I do happen to know that they split a lot up into small
dedicated parts when it comes to certain mission critical applications in
the field; like in modern jets (military and commercial).

There is nothing wrong with using something more powerful. This is probably
a perfect opportunity to get started on something bigger, badder and louder!

Sean.

2006\02\13@053430 by Gerhard Fiedler

picon face
Alan B. Pearce wrote:

>> Allow non-electronics types to retrieve the data and modify the
>> algorithm in the field (I'm thinking USB or SD memory card)

This and the fact that it probably will be (has to be, considering that
they are "non-electronic types" :) floating point seems to be a critical
thing to look at. There probably needs to be some kind of limitation to the
complexity of the algorithm. (Or are you just talking about modifying the
parameters rather than the algorithm itself?)

> [...] dsPics [...] and with the DSP core any of the calculations should
> be easy.

I'm not familiar with dsPICs, but DSP often does not much good for floating
point calculations; they have a lot of power for integer array
calculations, though.

Gerhard

2006\02\13@061020 by Alan B. Pearce

face picon face
>Alan B. Pearce wrote:
>
>>> Allow non-electronics types to retrieve the data and modify the
>>> algorithm in the field (I'm thinking USB or SD memory card)
>
>(Or are you just talking about modifying the
>parameters rather than the algorithm itself?)

Well you would have to ask the original poster that, as I quoted him.

>> [...] dsPics [...] and with the DSP core any of the
>> calculations should be easy.
>
>I'm not familiar with dsPICs, but DSP often does not much
>good for floating point calculations; they have a lot of
>power for integer array calculations, though.

Which is what I suspect the OP will really need anyway. As has been
discussed many times on this list, when dealing with sensors it is not
really floating point that is required, but a wider integer, possibly
representing a fixed point value. IIRC the DSP engine is 40 bits wide.

2006\02\13@094114 by Denny Esterline

picon face
> >It will be on the car, mostly in the engine compartment
> >(electrical noise and mass issues)
>
> Electrical noise, yes, Mass - why would that be a problem?, I would have
> thought temperature would be the other major problem.

Mass is a lesser issue, I only mention it here to rule out most of the
industrial off-the-shelf  hardware that's designed for stationary
applications.

-Denny


2006\02\13@095021 by Denny Esterline

picon face
> >> Allow non-electronics types to retrieve the data and modify the
> >> algorithm in the field (I'm thinking USB or SD memory card)
>
> This and the fact that it probably will be (has to be, considering that
> they are "non-electronic types" :) floating point seems to be a critical
> thing to look at. There probably needs to be some kind of limitation to
the
> complexity of the algorithm. (Or are you just talking about modifying the
> parameters rather than the algorithm itself?)

Definitely the algorithm itself, but I anticipate that with some effort I
can reduce it to a broad case with coefficients and then just let them
modify the coefficients in the field. But at that point it would probably be
10-15 terms and floating point would be essential.

I'm secretly hoping that I can distill it to some sort of lookup table. Have
Matlab or Excel produce it and then transfer that to the system, but rough
calculations shows a table size of nearly a megabyte so that may not be an
option. Obviously no PIC can do that nativly, but if I use an SD card for
logging it may be possible to stash it there.


-Denny

2006\02\13@095601 by Larry G. Nelson Sr.

picon face
Multiple processors allow you to do specialized tasks but add to hardware complexity and possibly device communication problems. DSPIC is good for the math parts and fast. A little more to wrap your mind around but I like to think of them as PICs on steroids.
Larry


---- Denny Esterline <.....firmwareKILLspamspam@spam@tds.net> wrote:
{Quote hidden}

> --

2006\02\13@095612 by Denny Esterline

picon face
> >I'm not familiar with dsPICs, but DSP often does not much
> >good for floating point calculations; they have a lot of
> >power for integer array calculations, though.
>
> Which is what I suspect the OP will really need anyway. As has been
> discussed many times on this list, when dealing with sensors it is not
> really floating point that is required, but a wider integer, possibly
> representing a fixed point value. IIRC the DSP engine is 40 bits wide.
>

_I_ realize I can do the math without floating point, but that's not realy
the issue. This will never be a production product so an extra $10 for a
bigger proccessor is a total non-issue. But mechanical engineers (cough -
spit :-) will have to be able to understand what's going on and be able to
modify the algorithm. Floating point makes that a LOT easier.

-Denny

2006\02\13@102308 by Bill & Pookie

picon face
If time and money permits, try something new.  Expand yourself, have fun and
enjoy.

Bill

----- Original Message -----
From: "Denny Esterline" <firmwarespamKILLspamtds.net>
To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam.....mit.edu>
Sent: Monday, February 13, 2006 1:17 AM
Subject: [PIC:] How much can a PIC do?


{Quote hidden}

> --

2006\02\13@165114 by Gerhard Fiedler

picon face
Denny Esterline wrote:

>>>> Allow non-electronics types to retrieve the data and modify the
>>>> algorithm in the field (I'm thinking USB or SD memory card)
>>
>> This and the fact that it probably will be (has to be, considering that
>> they are "non-electronic types" :) floating point seems to be a
>> critical thing to look at. There probably needs to be some kind of
>> limitation to the complexity of the algorithm. [...]

For something like this, Forth would be quite good. Possibly some Basic
interpreter engines, too.

> I'm secretly hoping that I can distill it to some sort of lookup table.

If this is about a feedback control system, I'm not sure that makes sense
or works at all. A simple PID controller is easy enough to parametrize, but
you are indicating that they may want to experiment with something a bit
more elaborate, possibly with nonlinear portions and characteristics that
depend on the history. How would that work with lookup tables?

Gerhard

2006\02\13@213753 by Denny Esterline

picon face
>
> >>>> Allow non-electronics types to retrieve the data and modify the
> >>>> algorithm in the field (I'm thinking USB or SD memory card)
> >>
> >> This and the fact that it probably will be (has to be, considering that
> >> they are "non-electronic types" :) floating point seems to be a
> >> critical thing to look at. There probably needs to be some kind of
> >> limitation to the complexity of the algorithm. [...]
>
> For something like this, Forth would be quite good. Possibly some Basic
> interpreter engines, too.


Hmmmm.....



{Quote hidden}

Well, the PID loop would tightly wrap the encoder and the servo. It would be
responsible for making actual_location match desired_location and would be
an unchanging function of the mechanicals. The thought (and at this point
it's nothing more than that) is that I could parameterize the
desired_location as a function of the sensor variables. Think of an
n-dimensional array where one or more of the dimensions could include
historic parameters. Although with even just a few parameters the table
grows exponentialy.
With a spread of just twenty data points and 5 parameters the table exceeds
3MB, 6 parameters makes it 60MB. That might be doable if I can hold the data
in a SD card or something and calculate an index pointer, definitly not
doable if I have to read and parse all the data.

It also might be possible to do a hybrid lookup/calculate option. Several
smaller lookup tables that handle one or two parameters, then some more
strait forward arithmetic with those values.

Like I said before, the math is complex and unspecified. A large part of
this project is developing a reasonable way for non-software folks to
interract with that math. That particular aspect needs to be alot further
along before I build any hardware.

-Denny

2006\02\13@215251 by David VanHorn

picon face
> It also might be possible to do a hybrid lookup/calculate option. Several
> smaller lookup tables that handle one or two parameters, then some more
> strait forward arithmetic with those values.


Hmm.. In the Atmel ATMega128, I did some thermal compensation code that
might be similar to what you're getting to.

For each input parameter, I built a table of constants and used the AVR's
FMULT (fractional multiply) to compensate.

If I remember right, there were something like 16 variables involved, and 16
entries per variable.

The Mega AVRs also allow you to read and write code space a word at a time,
so you could easily over-write the table values with something else.

Overall horsepower is better than a PIC at equivalent clock, most
instructions are single clock cycle, some two, and there is no
paging/banking etc to deal with.

2006\02\14@010749 by Chen Xiao Fan

face
flavicon
face


> -----Original Message-----
> From: EraseMEpiclist-bouncesspam_OUTspamTakeThisOuTmit.edu
> [piclist-bouncesspamspam_OUTmit.edu] On Behalf Of Denny Esterline
> Sent: Tuesday, February 14, 2006 10:38 AM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC:] How much can a PIC do?
>
> Like I said before, the math is complex and unspecified. A
> large part of this project is developing a reasonable way
> for non-software folks to interract with that math. That
> particular aspect needs to be  alot further
> along before I build any hardware.
>

Looks a very typical university project. And perhaps the higher
level work is done in Matlab or similar tools. I guess DSP
(not dsPICs but those from AD or TI) might be better option
for this kind of project because of the higher level software.
Matlab supports quite some DSPs and higher end MCUs but not
anything from Microchip. And the system may need some MCUs,
so PIC still can be used for some tasks.

Regards,
Xiaofan

2006\02\14@055840 by Gerhard Fiedler

picon face
Denny Esterline wrote:

> Like I said before, the math is complex and unspecified. A large part of
> this project is developing a reasonable way for non-software folks to
> interract with that math. That particular aspect needs to be alot further
> along before I build any hardware.

I think I'd use some HLL interpreter (like Forth or Basic), at least for
that part, and let them program it normally; there are a number of them
around. That's probably pretty straightforward. There's the problem with
the timing of the programmable part, but you can measure that and do
something sensible if it's too long.

Gerhard

2006\02\14@082910 by Walter Banks

picon face
Another approach that has been used in problems like this is to create linguistic variables based on the the input crisp numbers and then define rules that manipulate the linguistic variables. The biggest advantage if you are using a PIC is all of the
area's of interest are normalized to a common data type that depends on the resolution requirements of the outputs usually a byte or word sized. A PID controller implemented with this approach is capable of handling non linear systems and requires about a
half dozen rules and half a K of code.

w..

Denny Esterline wrote:

> Like I said before, the math is complex and unspecified. A large part of
> this project is developing a reasonable way for non-software folks to
> interract with that math. That particular aspect needs to be alot further
> along before I build any hardware.


2006\02\14@092716 by Bill & Pookie

picon face
Sounds like a "universal Pic I/O" board would be useful,  The Pic board
would have a Pic and all the hardware necessary for the different sensors
and motors as well as other common input and output devices.  May even have
a prototyping area for those special needs.  The whole thing could be
incased in a "Ninja Turtle Shell".  This would allow easy replacement of
controllers and addition of sensors.

This would also be easier to program as you would gain knowledge of the
single board and accumulate a good "tool box" of Pic routines.

The Pic controllers could put the sensor readings into a convent form for
the base computer before sending to the base computer.  And receive single
and repetitive commands for the outputs from the base computer.

By having each Pic handle a small number of I/O this could be done in a
timely manner.

The base computer could be a PC that could be programmed by those that felt
a need without as much concern about the real time aspects of the network.
Maybe even have the base computer on the internet with wireless connection.

Bill

----- Original Message -----
From: "Chen Xiao Fan" <@spam@xiaofanKILLspamspamsg.pepperl-fuchs.com>
To: "Microcontroller discussion list - Public." <KILLspampiclistKILLspamspammit.edu>
Sent: Monday, February 13, 2006 10:07 PM
Subject: RE: [PIC:] How much can a PIC do?


>
>
>> {Original Message removed}

2006\02\14@153121 by Michael Park

picon face
Stop beating about the bush and just come out and say it: FUZZY LOGIC!
:)


{Quote hidden}

>

2006\02\14@170026 by Walter Banks

picon face
"FUZZY LOGIC"  The alternative general purpose solution
was running out table memory. A non-linear fuzzy logic solution
is flexible and requires few lines of code even for the general
solution. Even in the general case it can avoid the need for
floating point or for that matter signed int's.

FUZZY pid
  {
   IF Error IS LNegative THEN ManVar IS LPositive

   IF Error IS LPositive THEN ManVar IS LNegative

   IF Error IS normal AND DeltaError IS Positive
     THEN ManVar IS SNegative

   IF Error IS normal AND DeltaError IS Negative
     THEN ManVar IS SPositive

   IF Error IS close AND SumError IS LPos
     THEN ManVar IS SNegative

   IF Error IS close AND SumError IS LNeg
     THEN ManVar IS SPositive

  }

w.. :)


Michael Park wrote:

{Quote hidden}

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