Need lots of I/O, what to do?

[sparksflying]

Hello All,

I am trying to design a bulk battery discharger/analyser. I want it to be as simple as possible, so will be discharging using constant resistance (instead of the normal CC)

Basically, every cell will have it's own ceramic discharge resistor in series and I will measure the the voltage of every battery using the ADC in the micro controller (I'll use an 8-Bit PIC)

Ideally I want this device to handle at least 20 batteries at a time.

To test the voltage of each cell I will switch each battery onto a common ADC bus one at a time. This would require one ADC pin and 20 I/O pins. I also want the MCU to disconnect the battery once it is at low-voltage, this will require another 20 I/O. All the switching is done with MOSFETs.

I am already using 41 pins at this point and the MCU only has 36 I/O (44 pin PIC). None of the projects I've done so far have needed this much I/O, so I'm a bit lost.

I had an idea of using 7400 series chips, decoder/s to select each of the 20 batteries (74Hc154) and bistable transparent latches (74HC75) to keep the battery connected until disconnection is needed.

Logic chips are pretty outdated though, how would you do something like this now?

Thanks!

[Ian.M]

Maybe rethink your design?  If you add a PIC12F1572 per cell, all communicating with your master PIC via an open drain serial bus (so it *MAY* also need a 'jellybean' small signal MOSFET, if the port open drain feature doesn't play well with the USART), you can PWM the cell discharge MOSFET. then all it needs is an inductor, a catch diode and a cap to smooth out the pulsing current to implement fully programmable constant current, constant resistance or constant power discharge.  It would be extensible to over 250 cells,  (above that you'd run out of 8 bit addresses for the serial bus and probably encounter fanout problems) .

 At under $0.60 for the PIC12F1572, its probably going to be no more expensive and may even be cheaper than the mess of logic and analog signal switching you are contemplating. There'd also probably be a cost saving if you are getting  PCBs made as 10x small boards usually works out cheaper than 1x large board of 10x the area.

[fcb]

Use SIPO's for relay control, so these could be CD4094B's or a 74 equivalent driving ULN2803A's, or there are serial input relay drivers (UCN58somethingfrommemory).

Probably also use Nchannel MOSFET's instead of relays, easier drive, could be cheaper, etc..

I'd also use CD4051 or 74 equivalents to scan the cells, probably would sense both terminals of each battery, then either use a diff amp, or a differential configuration on the ADC - depends on how accurate you need to be.

[daqq]

Logic chips are pretty outdated though, how would you do something like this now?

Why has no one told me!?

I am already using 41 pins at this point and the MCU only has 36 I/O (44 pin PIC). None of the projects I've done so far have needed this much I/O, so I'm a bit lost.

Analog muxes exist, both serially controlled or GPIO controlled. You can save a lot of GPIO by using this:
http://www.analog.com/en/products/switches-multiplexers/analog-switches-multiplexers/adg1606.html
or any of the other muxes available.

When you are low on digital output pins, consider shift registers (74HC595 and similar), of which you can cascade as many as you want.

[sparksflying]

Thanks for the replies!

Maybe rethink your design?  If you add a PIC12F1572 per cell,
...
It would be extensible to over 250 cells,  (above that you'd run out of 8 bit addresses for the serial bus and probably encounter fanout problems) .

I think I'll go the multiple MCU route, but have a slightly larger chip that handles a few batteries. I've used the 14 pin PIC16F1503 before (so have a bit of stock) and will link them all together using I2C. I really like the idea that it can be extensible to many more cells without too much work. 

[danadak]

How about the one MCU route, see attached screenshot PSOC.

This only uses part of the device resources.



For me what stands out is -

1) Routability
2) Fast 12 bit SAR A/D and slow 20 bit DelSig
3) DFB (Digital Filter Block) that is dual channel, handle FIR or IIR filters, or DFB
can be used as a GP fast processor block, similar to RISC block
4) MSI logic elements GUI based and/or the UDB Verilog capability. Eg. the FPGA
like capability
5) Onboard Vref
6) IDAC, VDAC, OpAmps (up to 4), comparator, mixer, switch cap, analog mux....
7) LCD,  COM, UART, I2C, I2S, One Wire, SPI, Parallel, LIN, CAN, BLE, USB
9) Custom components capability, create with schematic capture or Verilog
10) DMA to offload processes like filters, COM, Display
11) ARM M0 (PSOC 4) or M3 (PSOC  5LP) or 8051 core(PSOC 3) or M0+/M4 dual core PSOC 6
12) Extensive clock generation capabilities
13) All components supported by extensive prewritten APIs

https://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=true

http://www.cypress.com/documentation/code-examples/psoc-345-code-examples

Great video library

Attached component list.  A component is an on chip HW resource.

Free GUI design tool with schematic capture, "Creator". Components have rich API library attached
to each component. Compilers free as well.

PSOC 4 is low end of family, consider 5LP parts as well. PSOC 4 also has arduino footprint boards (pioneer) as well. PSOC 6 dual core M0+/M4.

https://www.elektormagazine.com/labs/robot-build-with-cypress-psoc

http://www.cypress.com/products/32-bit-arm-cortex-m-psoc


https://brightcove.hs.llnwd.net/e1/uds/pd/1362235890001/1362235890001_5241352463001_2606504288001.mp4?pubId=1362235890001&videoId=2606504288001



Regards, Dana.

[danadak]

Basic kit to get started ($10) -





http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and


One caution, this low end board does not bring out all pins, so I am not sure
you could do all 20 analog channels and get them routed. But its a great start.
The PSOC CY8CKIT-050 does bring out almost all pins.





http://www.cypress.com/documentation/development-kitsboards/cy8ckit-050-psoc-5lp-development-kit



Regards, Dana.

[David Hess]

Decoders like the 74138 and 74154 are one option where only one output is selected at a time.  They can even be driven by a counter to reduce the needed binary signals to two, one clock and one reset.

Serial I/O expansion with 74594s or cheap high pin count PICs is another option.  A 74HC594 costs 7 cents per bit and a PIC comes out to 5 cents per bit or less.  I like this solution because the I/O expanders may be placed where they are needed to ease signal routing.

A decoding matrix of 32 transistors can convert 10 outputs to 32 outputs.

[danadak]

I was able to route this on low end part, PSOC 4. Compromise is
no USB, less UDB digital blocks for GP logic, no DelSig or DFB
(Digital Filter).....


Board for this is Arduino footprint ($25) -


http://www.cypress.com/documentation/development-kitsboards/cy8ckit-042-psoc-4-pioneer-kit







Or the $ 4 board -


http://www.cypress.com/documentation/development-kitsboards/psoc-4-cy8ckit-049-4xxx-prototyping-kits






Regards, Dana.

[Kalvin]

Buy Arduino Nano board, two 16->1 analog muxes 74HCT4067 or similar, 3 x 74HCT595 8-bit shift registers + 3 x ULN2003 relay drivers or similar. With a 5V Arduino you can measure the battery voltage directly using the muxes, and driving the relays using the 74HCT595 and ULN2003 is very simple. If you do not want to use relays, you can use MOSFETs instead, thus you do not need ULN2003s either.

[tszaboo]

MCP23017 or MCP23S17. Because you only want to have one programmable part in your project. And they are too easy.

[sparksflying]

MCP23017 or MCP23S17. Because you only want to have one programmable part in your project. And they are too easy.

I never knew these existed This is basically what I'm programming the other MCUs for. I just need to work out how to use them... Thanks

[tszaboo]

MCP23017 or MCP23S17. Because you only want to have one programmable part in your project. And they are too easy.

I never knew these existed This is basically what I'm programming the other MCUs for. I just need to work out how to use them... Thanks

There are C libraries for it. Some of them will be labeled with Arduino.
To be clear, these are pre-programmed microcontrollers. And other manufacturers make similar ones too, TI, NXP just to name two.

[mariush]

There are I/O expanders with even more I/O pins, for example this Cypress part with 60 I/O pins, 16 of which can be configured as PWM outputs  (8 bit pwm sources) : https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/CY8C9560A-24AXI/428-2017-ND/1640248

But there are cheaper solutions, like PGA9505 (40 i/o for <4$) : https://www.digikey.com/product-detail/en/nxp-usa-inc/PCA9505DGG118/568-11941-1-ND/5221872
or maybe more convenient parts like TCA6424 (24 i/o for ~1.5$ and easy to solder) : https://www.digikey.com/product-detail/en/texas-instruments/TCA6424ARGJR/296-27844-1-ND/2411683

You should also consider the one mcu per battery some more as it may simplify circuit board layout A LOT. You can probably do a circuit board with just two layers, but if you go to a 4 layer circuit board, all the savings you do with these i/o expanders may be lost.
A PIC16F1503 is 0.7$ if you buy 100 and has internal voltage reference, 10bit adc, i2c

Or you have the Silicon Labs EFM8BB10F2G , 36 cents each if you buy 100 ... 12bit adc, 16 i/o , 8mhz, i2c, smbus, spi, uart , 2KB flash , 256 bytes ram internal oscillator : https://www.digikey.com/product-detail/en/silicon-labs/EFM8BB10F2G-A-QFN20/336-3162-5-ND/5115719

You could use one of these for a set of 4 batteries since it has enough I/O, so you'd only need 5 such chips for 20 batteries.

[mikerj]

Why not use a micro with sufficient I/O and analog inputs to start with?  An STM32 with >20 analog and >20 digital I/O won't be very expensive.  If you don't fancy soldering the packages, then use one of the many Nucleo boards.

[fcb]

If you're familiar with the PIC - it would be madness not to use a PIC (unless you want to learn another system).  As I highlighted in my earlier post - i'd use I/O expansion.

You can build this with as little as 4 i/o (3 digital outputs and 1 analog input).

Here's how to do it with the minimum number of good old fashioned logic IC's, a few ULN2803A's and a PIC:
3x CD4051B 8:1 muxes, these are connected to your batteries to be sampled. The ABC select lines are tied together as is the analog I/O on the 4051. The enables go to the PIC seperatly.
3x CD4094B SIPO's, the 8 outputs of these connect directly to 3x ULN29803A's - these drive your relays.  Daisy chain the 4094's (see data sheet), you only need three PIC lines now.

So on your PIC you are now using:
A (mux select)
B (mux select)
C (mux select)
MUXOUT (analog input on PIC)
EN1-8 (analog 1-8 group select)
EN9-16 (analog 9-16 group select)
EN17-24 (analog 17-24 group select)
DATA (4094 data)
CLOCK (4094 clock)
STROBE (4094 load)
Total: 9 outputs, 1 input

You can reduce the pin count by 6, if you add another 4094 and use this to drive the A/B/C/EN1-8/EN9-16/EN17-24 lines, but you'll probably have plenty of I/O spare on all but the smallest PIC's. If you've got more analog inputs then you could read each 4051 and reduce the pin count by 1 by tieing all the 4051 enables high.

If you want to protect against accidental discharge, processor issues, etc.. connect all the ENables on the 4094's together and drive with whatever flavour of safety circuit you want.

Logic might be old school, but it's robust, cheap, easy to use and along with the PIC's will be around long after the PSOC's have gone EOL.

[sparksflying]

You should also consider the one mcu per battery some more as it may simplify circuit board layout A LOT. You can probably do a circuit board with just two layers, but if you go to a 4 layer circuit board, all the savings you do with these i/o expanders may be lost.
A PIC16F1503 is 0.7$ if you buy 100 and has internal voltage reference, 10bit adc, i2c

I'll definitely be sticking to PIC as this project is meant to be fast and easy (Complex projects always seem to sit half done on the shelf...).

My main chip will be the PIC16F1939, 44pin TQFP. I've used it before so have the config all setup and layout ready.

As for multiple MCUs or I/O Expanders, I don't think it should matter as the I2C bus will need to join them all anyway.

[jmelson]

Serial-controlled analog multiplexers are available, such as the  MAX335.  That will solve your ADC-bus switching.  You could probably also use them to switch the gate for the power-switching transistors, too.  You probably only need 3 pins to run all the MAX335's.

Jon

[sparksflying]

Serial-controlled analog multiplexers are available, such as the  MAX335.  That will solve your ADC-bus switching.  You could probably also use them to switch the gate for the power-switching transistors, too.  You probably only need 3 pins to run all the MAX335's.

Jon

Nice, but they are like $10ea...

[suicidaleggroll]

Serial-controlled analog multiplexers are available, such as the  MAX335.  That will solve your ADC-bus switching.  You could probably also use them to switch the gate for the power-switching transistors, too.  You probably only need 3 pins to run all the MAX335's.

Jon

Nice, but they are like $10ea...

https://www.digikey.com/product-detail/en/texas-instruments/CD74HC4067SM96/296-9226-1-ND/376978
$0.88 for a 16:1.  Need more than 16 channels?  Cascade them.

[RoGeorge]

Use an analog MUX: e.g. 32:1 +/- 2.5V for analog
http://www.analog.com/en/products/switches-multiplexers/analog-switches-multiplexers/adg732.html

[danadak]

One other possibility is to use PSOC 4 BLE family, then you could Bluetooth the data/status to a
phone/tablet.

Attached example is single channel you could mod to 20 channels, and choose a part with the
additional I/O.

Then your main effort becomes the host side app programming.


One part does it all.


Regards, Dana.

[cdev]

There is no reason to use any of those fancy solutions because you only need to get a reading very infrequently.

[thermistor-guy]

...
You should also consider the one mcu per battery some more as it may simplify circuit board layout A LOT...

I have heard of this approach taken in a military battery charger, with a master mcu making sure that the slaves are performing correctly.

[tszaboo]

People suggesting to buy Cypress or Maxim parts are obviously high on something.

[danadak]

Cypress PSOC does not fit every design.

But as a designer, if you you give me some elements from 3 worlds,
CPU, Analog, FPGA, then  you solve a number of my past designs
that otherwise would have needed several parts.

Anytime I can compress # parts used (cost, reliability, EMC), use a
tool spanning routing, custom component creation, near complete
signal chain implementation, modern core CPU, then I am high on PSOC.

And now we have dual cores with all this, lest I forget DSP in many as well.

Cypress PSOC does not fit every design.

But in many of my designs, and customers I worked with, PSOC was an
excellent choice.



Regards, high Dana.

[james_s]

Cypress and Maxim have both offered some interesting and unique parts. They do tend to be rather expensive but that's not always the case and sometimes the cost is not a problem for something made in small quantities. If I can buy a part that costs 3x as much but saves me several hours of my time then in many cases it's worth doing that.

As far as IO pins, I've long been a fan of the 74HC595, cheap and readily available, a string of those can give you as many output pins as you want while requiring only 3 IO pins on the MCU. They're frequently used to drive the columns on those scrolling LED message signs.

[danadak]

One has to evaluate total system cost when making choices. From piece
part price thru manufacturing costs, otherwise one is being delusional.

But yes, the high end parts, with multiple A/D and DSP and large fabric
are expensive if you are looking for a $2 part or less. However if you add
up costs of all the capabilties still beats hacking out of multiple parts. Partly
because that approach wastes silicon due to redundant interface silicon area,
I/O device sizing. Much less needed when all onchip.

But the low end can be < $ 1 and still have some fabric, and some analog.

I find with tool capabilities not only do I save time but board area for sure,
and glue logic elimination. And pulling in analog just that much more reduction.
In fact some designs require no software other than one liners to issue start
command to module(s). Intelligent DMA capability enables full HW solutions in
some cases.

And routability, when all this stuff is pulled onchip that leaves tons of I/O
for interface to real world, not a bunch of I/O wasting external logic. Just a
thought.

PSOC is not best choice for every design, just many designs.


Regards, Dana.

[nctnico]

Hello All,

I am trying to design a bulk battery discharger/analyser. I want it to be as simple as possible, so will be discharging using constant resistance (instead of the normal CC)

Your setup is way too simplistic. Think about voltage drops in cables and if you want any precision then you'll also need good 12bit ADCs (IOW not the crap stuff from Microchip) and 0.1% references. Also think about voltage spikes when MOSFETs are opened. Wires and resistors will have some inductance.
For lots of digital I/O use the SPI interface together with parallel/serial shift registers like the TPIC6C595, 74xx595, 74xx165

[tszaboo]

PSOC is not best choice for every design, just many designs.

I love these delusional PSOC cult on this forum. Every single thread with a microcontroller, they de-rail, with "oh do this with a PSOC".
" I have a design, we've been working on it for 4 years" - "You should change to PSOC, WALL OF TEXT"
While Cypress provides shit support, impossible to buy in the EU, and all they did was integrating some 10 cent opamps and one thousand's of an FPGA, and they charge double for that.
Well done people. You are (plural, the cult of PSOC) like the Jehovah's Witnesses. Nobody cares what you have to say.

[danadak]

Do the end to end cost analysis, cost of engineering time,
board area, reliability, connections, reference, analog precision
needed........some conclusion will be PSOC, some not.

Agree, on chip opamps not state of the art. But in OpAmp shipments
stuff like LM324 like grunge parts still the principle volume in industry.
And auto zero type techniques, correlated double sampling techniques,
mitigate some of that. Small FPGA, for sure its small. Look at the number
of threads on this forum where designers want small FPGA, small amounts
of logic to add to designs. Reason for success of single gate logic families.

PSOC is not for all designs, just many.

No one is claiming PSOC is the god of solutions. But sound engineering
has shown it has its place.

Every single thread with a micro controller, they de-rail, with "oh do this with a PSOC".

That is a BS statement.


Regards, Dana.

[tszaboo]

Do the end to end cost analysis, cost of engineering time,
board area, reliability, connections, reference, analog precision
needed........some conclusion will be PSOC, some not.

No, you achieved, that none of my projects will be with PSOC.

Every single thread with a micro controller, they de-rail, with "oh do this with a PSOC".

That is a BS statement.


Regards, Dana.

Oh, really? You copied the same bullshit statement 40 times already to this forum. Without changing anything. It is called spam.

Re: Need lots of I/O, what to do?
Re: circuit that measures phase precisely?
Re: STM32F4 with external simultaneous ADC (see? Nobody asked about PSOC, you brought it up anyway in a ST topci)
Re: Best way to start moving away from Arduino?
Re: ARM - easy way to start with
Re: MCU Slection: need lots of input captures (also CAN and EXT. Temp Range)
Re: What happened to XR-2206 Funct. Gen. IC and XR-2212 Precision PLL

should I go on? STOP SPAMMING.

[danadak]

Every single thread with a microcontroller, they de-rail, with "oh do this with a PSOC".

That is a BS statement.

[nctnico]

Every single thread with a micro controller, they de-rail, with "oh do this with a PSOC".

That is a BS statement.

No, it is not. Nandblog does have a point here.

I have looked at the PSOCs a couple of times but they just don't resonate well with me. Sure you can create lots of different peripherals but it is totally unclear to me how much resources there actually are available. It seemed to me I'm better off with a microcontroller with fixed peripherals. Because NXP ARM controllers share the same peripherals between the lowest and highest end devices (unlike ST's ARM devices!)  I can re-use the low levels drivers across their entire range. I think this gives me the same flexibility as a PSOC in the end.

[danadak]

In the tool is a page generated of resources used, resources remaining. In fact
latest rev of tool has summary of that on main design page.

Insofar as device to device same peripherals, the PSOC has both fixed peripherals
and UDB based. In both cases their APIs same from one part to the other, in the
main.

Every single thread with a micro controller, they de-rail, with "oh do this with a PSOC".

Not "Every single thread" has a PSOC comment on it, that is a fact.

The quoted statement is BS.


Regards, Dana.

[nctnico]

In the tool is a page generated of resources used, resources remaining. In fact
latest rev of tool has summary of that on main design page.

The problem with that is that it makes it impossible to determine whether a PSOC will be able to do what I want or not during the part selection stage because in the end the PSOC resources are limited. I don't want to make a PSOC design only to find out it doesn't fit. I rather use a list with fixed peripherals on a product comparison sheet.

[tszaboo]

Every single thread with a micro controller, they de-rail, with "oh do this with a PSOC".

Not "Every single thread" has a PSOC comment on it, that is a fact.

The quoted statement is BS.


Regards, Dana.

I guess you lack the time to do that...
But seriously, you should get a hobby or something, because CTR+V-ing the same thing over and over again is getting old.
Unless you get payed to do this.

[danadak]

The personal stuff and unfounded assumptions I will not respond to. Inappropriate for the forum.

Unless you get payed to do this.

Answer is no, wished I did.


Dana.

[danadak]

I rather use a list with fixed peripherals on a product comparison sheet.

Thats an excellent point, I will look into this. Each "component", an onchip resource, lists in
its datasheet resources used. So to your point a table of fixed resources also would be
helpful. Then UDBs can augment that. Almost needs a selector guide that you check off
what you want, and guide interprets where UDB resources are also needed and tells you
that.

One way of handling this would be to contact FAE and have them do a quick schematic
work up to see whats needed.


Regards, Dana.

[danadak]

nctnico, I forgot, the resources table shows both fixed and UDB assets used.

Attached pic, also shows summary on design page.


Regards, Dana.

[nctnico]

I rather use a list with fixed peripherals on a product comparison sheet.

Thats an excellent point, I will look into this. Each "component", an onchip resource, lists in
its datasheet resources used. So to your point a table of fixed resources also would be
helpful.

What would be helpfull is a list with all the combinations of peripherals supported at the same time in a specific device. At least that would allow for a quick selection based on standard peripheral requirements.

One way of handling this would be to contact FAE and have them do a quick schematic
work up to see whats needed.

I rather not hand of my design work to an FAE. Besides that I usually spend less than an hour on selecting a device so by the time an FAE responds the PCB design is already done.

[danadak]

"all the combinations" leads to a factorial combinatorial problem that
explodes the matrix.

I think the approach is define how many of what you need, subtract the fixed
assets listed in datasheet/tool, then by peripheral look at UDB resources needed
(in its module datasheet) and do a simple summation.

I have contacted VP of Engineering with idea for a tool to do this, lets see what
he says.


Regards, Dana.

[technix]

If all you are using are outputs driving relays, try a chain of TPIC6B595 shift register on SPI bus. TPIC6B595 is high power version of 74HC595 with open drain outputs capable of higher current and voltage. Multiple TPIC6B595’s can be simply daisy chained so the entire chain occupies only one chip select on your MCU’s SPI hardware. Just insert a 74LVC1G17 in the clock line once a few shift registers to reshape the clock signal, keeping the signal integrity high.

Alternatively I would suggest you to scale the project down to a 1-cell unit, but implement some kind of multi-drop communication like I2C, RS485, RF (Wi-Fi or nRF24L01+) or Ethernet for the control signals and status reports.

P.s. why is the PSoC wall of text here again? I don’t think the MCU architecture solves anything here.

[danadak]

P.s. why is the PSoC wall of text here again? I don’t think the MCU architecture solves anything here.

1) PSOC has auto scanning A/D and fairly good reference onchip, +/- .1%.
2) PSOC has ARM core to address interface needed.
3) PSOC has onboard analog mux to handle the number of channels needed.
4) PSOC has the required # I/O for design.
5) PSOC has GUI design tool to perform schematic entry and onchip routing.
6) PSOC has ability to use standard logic elements or create custom logic and route it for the ancillary non standard design specific requirements.
7) PSOC has intelligent DMA, offload mundane tasks from CPU.
............................


SWOT (Small Wall of Text)


Regards, Dana.

[Ian.M]

Alternatively I would suggest you to scale the project down to a 1-cell unit, but implement some kind of multi-drop communication like I2C, RS485, RF (Wi-Fi or nRF24L01+) or Ethernet for the control signals and status reports.

Yes, as I said in reply#1.   I proposed using an open drain serial bus to minimise the cost per cell, but there is no reason why any other multi-drop bus or medium couldn't be used.    There are other advantages of one MCU per cell:
* It makes the software design much easier - get one node  right and test it thoroughly and it scales easily to a large number of nodes.
* It makes it relatively trivial to support testing individual cell capacity of series connected battery packs - draw power for the node from the cell being tested, and optoisolate the comms bus, which only needs two optocouplers if you stick with an open drain or collector serial bus. 

* Then there's the costs - a larger, more complex PCB takes more time to design and debug, a lot more to prototype and more time to assemble.   Repeating a simple board N times is far more cost effective for a one-off, and the odds are all the PCBs will cheaper as well, due to the typical pricing structure of most prototyping-friendly PCB manufacturers. 

* Cost of mistakes: Its simple enough for one or two nodes to be fully breadboardable, and to be able to check every pin against the proposed layout so there shouldn't be any gross layout goofs that render the boards totally unusable, and the odds of you FUBARing *all* the boards is much much lower (unless you do something dumb and try to reflow them all in an untested DIY reflow oven and carbonise the lot of them) compared to the risks of fubaring a far more complex one-off board.

Everyone touting advanced MCUs with high levels of analog integration is loosing sight of the difference between a commercial product and a one-off hobby project - namely the number of units you expect to amortize your fixed costs over.  The O.P. appears to be doing a hobby project, and has already got a PIC toolchain.   Although there are some low cost options for development boards with integrated programmers for many of the alternatives that have been proposed, you cant get a discount on the time to learn a new architecture and toolchain.  The O.P's already invested that in 8 bit PICs - its a sunk cost.   

[nctnico]

Alternatively I would suggest you to scale the project down to a 1-cell unit, but implement some kind of multi-drop communication like I2C, RS485, RF (Wi-Fi or nRF24L01+) or Ethernet for the control signals and status reports.

I strongly advise not to go for a multi-microcontroller solution because getting the communication working reliable (I mean really reliable 24/7/365) is very hard. You basically create a bunch of asynchronous processes which don't always know what the other is doing.

[Ian.M]

That's why you avoid wireless and Ethernet, make it master-slave and give each slave a unique address.  Slaves only respond if commanded to by the master, and if you don't try to implement any fancy slave discovery protocol, just poll all the limited pool of possible addresses for an ACK, its not that hard to avoid unpredictable behaviour.

[technix]

Alternatively I would suggest you to scale the project down to a 1-cell unit, but implement some kind of multi-drop communication like I2C, RS485, RF (Wi-Fi or nRF24L01+) or Ethernet for the control signals and status reports.

I strongly advise not to go for a multi-microcontroller solution because getting the communication working reliable (I mean really reliable 24/7/365) is very hard. You basically create a bunch of asynchronous processes which don't always know what the other is doing.

Most nodes don't really need to know what other nodes are doing. RS485, Wi-Fi and nRF24L01+ requires CSMA/CD to be reliable, I2C is a master/slave system, and for Ethernet you can assume a fully switched full duplex network and just shoot packets away.