Need lots of I/O, what to do?

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