PSOC 4200 (not DS, Not BLE)

Posted On October 10, 2022

The PSOC 4200 part, especially the CY8C4245 part, is *barely* a PSOC. It has 4 UDB’s in it, which will allow you to put in a 16 bit PWM and a Pulse Stretcher. This will cost 1/2 of the available UDB’s. It is still more than other vendor’s processors allow, but it is a babe in the crib compared to the PSOC5.

The 4200DS and 4200 BLE PSOCs do not have all the Analog portions, and nor the UDB portions. My experimenting with them was more or less a failure.

PSOC4 issues

The PSOC4 started the trend towards Cypress being a “me too!” processor company. However, since it is supported by the PSOC Creator, it is still way ahead of the offerings from Silicon Labs, Atmel, Etc.

What makes the PSOC 4 so painful to use for the weekend engineer (and for a Fortune 500 company) is that you *cannot create the schematic and route the pc board ahead of your firmware development.* I tried that. It failed.

I admit I was spoiled by the PSOC5. I was able to follow some simple guidelines and route the traces on a board, with the full expectation it would work without having to be re worked. Any issues were fixed by re-routing using the Schematic Capture and Pin Assignments capabilities of PSOC Creator. PC Board fabrication could happen at the same time as firmware development occurred.

PSOC4 Layout Experience

To get the PSOC4 routed, I had to populate the PSOC Creator schematic (and its internal connections) with the components I needed and do a build. That failed over and over. I did cheat and bring in a schematic for a PSOC5. It failed immediately, and I had to remove 2/3 of the sheets to get some of the functionality to fit.

The conclusion to be drawn is that I will have to have different boards for different functionality, rather than a single software configurable board. 4 UDB’s are simply not enough for multi-functional work.

Initially, I could not use a UART, a PWM, and a Pulse stretcher. Once I removed the UART and forced it into an SCB (and had to settle for the “automatic” pin layout that cannot be changed), I was able to get the UART functionality back into the PSOC 4. Pin assignment now stuck for those pins.

Analog Inputs

According to the 4200 data sheet, any pin can be analog, digital, LCD, or CapSense. That is extremely misleading. On the PSOC5, it is absolutely true, but you do give up some current drive capability by routing an OpAmp output away from its dedicated out pin. On the PSOC4, you cannot route an OpAmp output where-ever. You must route it out its dedicated pin. I don’t consider that meaning that any pin can be analog. I means any pin can possibly be an analog output, it is the luck of the draw.

In addition, the other analog inputs failed to route where I desired them. I eventually had to give up and allow the automatic router to work. That meant that I was unable to choose what the output or input pins were for that PSOC Creator Schematic. Therefore, the physical board trace routing will most likely have to change if the PSOC Creator schematic changes. Just like the other vendors. Ugh.

I had much the same issues for the Digital Section, but by that time I had given up. The end result of that is it took me about 3 days of testing routing issues, and going back and forth between the 2 sided board layout and the PSOC Creator schematic to get a functional, routed build.

My last “new” board with the PSOC5 was done in 30 minutes because I started with an older board and added features. For this board, it only vaguely resembles the previous board that had the PSOC5 on it. Everything had to move if it was able to stay on the board. Everything else is gone, and those features cannot be used, even though the functionality inside the PSOC4 is roughly the same as the PSOC5 for this particular job.

I started with an older board for the PSOC4 also, but I had to remove features to get it to fit into the PSOC4. That was acceptable and expected. The delay was not due to removing features, but due to not being able to assign anything by hand and have it compile and build with the smaller feature set. You can only hand specify the Pins on the PSOC4 in very few instances.

PSOC Creator Still Shines

Even so, the PSOC Creator build environment worked. It built. It created the API’s. It compiled without issues. I was able to bring up and use all the components almost immediately. Not So With SiLabs. Not So With Atmel. Those environments still required tweaking after I did the initial pin assignments and tried to build. Ugh. I still haven’t finished with those boards, nor with a skeleton build for those MCU’s.

BTW, I have designed and finished shipping systems with 8080, Z80, COP400, 6805, 68HC11, Ti4030, and 80386 embedded processors. So, yes, I can handle the complexity issues. But saving development time is the name of the game today.

A Measurable Difference

Even though the PSOC4 and PSOC6 processor families are “me too” processors, with not much to differentiate them from the competition, the use of PSOC Creator will make a difference for you. If the PSOC family is supported in PSOC Creator, understand that the development environment will reduce your development time by half or more for simple first time projects. The reduction in time gets even better if you can use a PSOC5 or (if an 8 bit CPU is enough) the PSOC3 due to their flexibility in routing signals.

Granted, once you have built a compiling, working environment for SiLabs, Renesas, Atmel, or T.I., the additional work to bring up a new design is much, much less. At that point it is comparable to a first time build and deploy on the PSOC Creator.

Fini

Sometimes a diamond is created. Often, the developers that follow those teams say, “Not Invented Here, it must be junk!” I believe abandoning the UDB’s and routing facilities of the PSOC5 is one of those situations. The current engineers don’t understand the engineering beauty of what was created, and they refuse to duplicate those wonderful features.

Enjoy!