1 pic or 2 or even 3?

[TimB]

Hi All

One of my long standing project is actually working YAY!!!!! And I'm looking now at how to turn it into a product.

Currently I have one Pic doing 80% of the grunt work. Its is basically a 20khz interrupt and the rest some simple monitoring code and calculations. Its only a pic18f13k22 (running at 64mhz). Still have code space left but the ram is all gone.

Now to do the other 20% I need more ram 2K+

The end product may need a GLCD front end so now I am pondering my options

1 Leave the 13k22 to do the grunt work and then farm out the 20% to another chip that may also handle the display

2 Use a Bigger device with more CPU power (I use floats a lot, 32bit accuracy is fine) and farm out the UI handlining to another device

3 Use 3 pics!

Note that The GLCD UI may not be needed but it will need some outside world connection eg 4-20ma or some form of BMS network connection.

I'm looking to build it onto one board. Perhaps I should think about going over to Pic32 now and supercharge it with 100mhz pic. Or maybe I can get more out of one 64mhz Pic18fxxx and leave the GLCD to a dedicated display board.

One more thing is that the product may be a 2 function product. Expensive with Function A and more expensive with Function A + B. It would be good to just use one board but may go for 2 variants.

Any thoughts and why appreciated..

Tim

[John Lawton]

It may depend on the likely production volume and how critical is the build cost.

Putting everything on one chip may be cheaper for production but may mean more development work and cost whereas farming out tasks to other micros may prove easier and cheaper to develop.

[TimB]

Thanks John

Very low volume.... And moving to a Pic32 will cost me many many hours

Tim

[JonW]

If the volume is that low then i would keep it simple and go modular with dedicated multiple MCU.  You can then add functions quickly without needing to touch the main MCU code structure.  Modular design is also great for fast changes and upgrades/repair too.  We have a number of products with 4 MCU in a single design, having multiple smaller processors simplifies the tasks, keeps the code efficient, fast and eases the PCB layout and layer count.

[John Lawton]

Agreed. However if you use multiple PICs then updating them from the main chip if using a bootloader is a challenge (it can be done) so ideally you need to get the code on the other chips as right as possible.

[TimB]

Thanks

I did some analysis on the amount of time the CPU was really working as apposed to just waiting for some timers to flag or some work in the interrupt.

It turns out its not working that hard.

I think with a bigger rammed CPU and carful timing of the work required I can get all the basic code running in one pic and just TX the resultant data out to a device to handle the UI or the 4-20ma BMS coms stuff

[tumbleweed]

An 18Fx7Q43 will get you 128K flash/8K ram with somewhat minimal code changes except if you use hardware I2C. If you need that I'd switch it to software I2C if you need that much ram.

Multiple processors can create a real headache when it comes to debugging and code updates. Many times it takes as much code to do the processor interfaces than it "saves". Adding features usually requires updating more than one processor, so now you have to worry about matching versions.

Been there, done it. I'd recommend keeping in one processor if at all possible.

[keytapper]

I'd like to add an observation. In the industrial environments a programmed device has at least two separated intelligent units, one is the PLC/CNC and one is the HMI. So for one instance the HMI may be useful or not installed, but the main control is there and safely running.

So for the UI, I think they come in a fashion with their own intelligent chips and just a simplified interface will suffice as HMI (SPI is a winning option), then the main grunt work may be one MCU or more depending on the complexity of the project.

Splitting down in modular fashion is easier to troubleshoot and repair. Whereas a single unit would add complexity and more hard to pin point where the fault started.
In a complex machine I saw hundred modules linked by an Ethernet interface, which may allow locating modules close to the working area.

[tumbleweed]

Splitting down in modular fashion is easier to troubleshoot and repair. Whereas a single unit would add complexity and more hard to pin point where the fault started.

That sounds good but I'm not sure I agree. If there's more than one thing involved you have to figure out which is at fault, and that can definitely make it more difficult.

If there's only one it's pretty simple. Replace it, done.

There are times when multiple processors are called for but in my experience it's never made things simpler.

[Gamboa]

Hi,

My experience is that if you can put it all in a single PIC it's better. If you need computing power and speed you can go for a dsPIC33. They are powerful and fast machines with lots of Flash and RAM.

Regards
Gamboa

[JonW]

I think each application has to be analysed as there is no right or wrong answer to this question.  In our case, in one application 4 x $0.03 16 pin MCU's are far better than a single device as cost and RF isolation is by far the most important factor and we don't have the luxury of flash based processors. In other products we go for balls out speed and pack everything we can into a much larger processor. Your product may have a standard interface or feature set that is fitted at a later stage and cost/size/procurement issues are priority thus multiple MCU may be a better option.   For low cost bespoke applications modular designs may have the advantage and can enable fast turnaround and upgrades without having to spend too much time on the coding, porting to new MCU can be very time consuming and has the potential to introduce errors in the code. In many of the high volume products we manufacture the risk introduced in changing a processor or even updating firmware is avoided at all costs to remove any chance of a widespread failure, plus the overhead of testing, reliability and approvals must always be considered.

[Stephen Moss]

In general whether to go for a modular system or not and how beneficial it is depends on many factors...

• If you have a large design team development can be quicker as a different individual can work on each model so they are developed in parallel
• If the end product has many modules repairs can be cheaper and less wasteful as you are only disposing on the defective module, not a lot of otherwise good circuitry of an all-in-one design
• Multiple PICs could be simpler to code for and debug as you don't have one massive program to deal with
• The end product can be cheaper and more tailored to individual customers need by only fitting the module they need

Whereas an all-in-one PCB maybe cheaper to make and you don't have any extra cost or potential reliability issues of PCB-PCB interconnects.

For this individual case it has been shown that the current PIC apparently has cycles to space and so a similar device but with more RAM could potentially run the display UI without the UI being blocked by the other functions thereby slowing its response to user input or the UI blocking other functions itself.
Consequently, I would say that whether to go for one PIC or multiple PICs really comes down to whether there is likely to be any significant advantage of one over the other with regards to potential blocking and resulting impaired performance if the UI is implemented, if not then a single larger device could be more cost effective for low volumes than multiple PICs (depending on which devices are used).

Although just to muddy the waters a little there are now Dual core PICs, I don't know what the price difference would be but if it is not prohibitive, they have the required amount of memory and are not overly difficult to use they may be worth considering as if a UI needs to be added later it could also be set to run on the second core.     

[TimB]

Thanks all

I have been going back and forth over this. The overriding issues that the CPU has to be moved from the location I had it. It was on a small board 56mm x 56mm on the top of the apparatus. While it was handy there, as I had a number of connections making a direct connection to it. It was a liability and would need replacing if the module had to be replaced. 

I have to store pertinent info about local settings so will do that on a local board and pass out the probe lines etc via a connector to the main board. I decided that it makes replacement of calibrated parts easier. I just need to plug a new module in and not replace a whole board as well.

I think now that I can do the majority of the CPU crunching stuff on the one pic. I will just TX out the results for the UI board to display.

Another very handy point from the input I have had is I realised that I actually can reduce parts to make my system 100% solid state. No probes in water etc and no valves just electronics + sensors. Well at least one variant.

That is what I love about asking questions here you lot have a very deep knowledge base and all that helps me make the better decisions.

Many thanks

Tim

[Pic-ignorant]

Hey all,
If a multi pic board was chosen, I'm curious to what method of communication between the on onboard pics would be best?

BR
John

[John Drew]

Hey all,
If a multi pic board was chosen, I'm curious to what method of communication between the on onboard pics would be best?

BR
John

Gday John,
I reckon I2C. Less pins, fastish, most PICs have the peripheral, and master/slave easy enough to do. Use hardware and interrupts for little impact on the main code.
I2C was designed for that purpose.
Cheers
John

[Stephen Moss]

Hey all,
If a multi pic board was chosen, I'm curious to what method of communication between the on onboard pics would be best?

BR
John

That would probably depend on whether you need to transmit and receive a lot of data and whether each device has to be able to control the comms bus or if it will be a call and response (Master/Slave) system.
If you need to both transmit and receive a lot of data then SPI would probably be better than I2C as you can do both simultaneously thereby reducing the time the devices are handling in the comms instead of doing other things.