PSOC5, PSOC3, and a Pic, dsPic Surprise

Posted On September 26, 2022

The Cypress branch of Infineon does not trumpet an interesting fact. A PSOC5LP package and a PSOC3 package are interchangeable.

So, if you have a PSOC3, you can drop a PSOC5LP in its place and rewrite the code. Or, Vice Versa.

The main problem you will have going back to a PSOC3, from what I can tell, is the PSOC3 has a maximum of 64 KB of flash. The Ram is also limited to 32KB.

Also, the PSOC3 contains an 8051 with enhancements. It is a single cycle processor in the PSOC3, technically making it share a characteristic with a RISC (Reduced Instruction Set Computer) processor. As an example, the Intel x86 family are CISC (Complex Instruction Set Computer) processors.

Processor Types

A CISC processor will take many clock cycles to complete an instruction. However, these instructions may indeed do a lot of work. For example, in one instruction, a CISC machine can take an address , add to it another register address times 4, use that result to index into memory, read the value, add 1 to it, and store the result into another register. That takes a minimum of 4 instructions in a RISC machine. The CISC processor will consume many clock cycles (sometimes 20 or more) before the instruction is finished. The RISC processor uses one clock per instruction. It is usually faster than a CISC machine for simpler instructions.

The good thing about this for the CISC, is one RAM (Random Access Memory) fetch is done every xxxx clock cycles. Since ram is 2 to 10 times slower than the processor, this keeps the processor from having to wait for the next instruction. In a RISC architecture, the processor can be held up waiting for the next instruction. However, a particular kind of memory designers created helps with this problem.

This memory is called Cache Memory. It runs at processor speed and usually holds enough program instructions to make the processor 80% to 95% efficient in running code. External memory is also improved. The current DDR5 will transfer 5 bytes of Sequential RAM for every clock cycle. The list of tweaks goes on and on.

If the Cache Ram is around 16,000,000 (16K) bytes, then the efficiency of the processor approaches the 90% mark when running a single program. More Cache Ram only benefits you if you run an Operating System (Windows, Unix — a.k.a. Linux, OSX, BSD), where each running program needs its own set of 16K of cache. A hardware memory manager comes into play at that time. Etc., etc., etc.

Efficiency of Assembly

If you are writing assembly language, you can code very efficiently. The size of the program can be optimized to fit in a relatively small amount of space when compared to RISC.

I once wrote code in assembly for an embedded 80386 which utilized this approach. It fit inside the processor’s 16 byte instruction cache (yes, 16 bytes). It was able to transfer data from ram to an I/O port at DMA level speed since the only external accesses were for transferred data.

(I had to do this; the DMA unit on that version of Intel’s processor was badly implemented and would drop, gain, or duplicate bytes depending upon where it was in its state machine if you stopped and restarted it.)

However, almost no one writes assembly today. They write High Level Code. And that is why CISC processors don’t work as well for most purposes as RISC processors. To explain why, I feel the need to give some (personal) background for this statement.

I have written assembly language for around 14 different processors. I generally only do that for time or space critical situations. It is similar to being beat with a wet noodle. Very messy. Ugh. So I am familiar with many concepts of assembly language and processor microcode engines (which implement the processor machine code instructions). Large fleas have smaller fleas to bite them, and so on, ad infinitum. (If you don’t understand the context of that obtuse reference, search for processor microcode.)

Higher Level Languages Today

Today, my “assembly” language of choice is C. The original definition (K & R “C” Language) is so simple it it can be implemented using a recursive parser with a few restrictions. The “small C compiler” comes to mind, and can be searched for on the Web.

I have taken the small C compiler and ported it to the 6800 processor family for a hobby. Just a few hours and I was finished. I have also written a 6805 assembler. Assemblers generally don’t need complex parsers.

What I learned from that process is this: High level languages take the language’s statements and translate the statements into assembly language statements using simpler patterns called templates.

This assembly language is compiled (assembled) into binary object files, which can be linked using a program that creates a binary file which can be loaded (with a loader program) directly into the processor memory. (Sometimes the loader program “relocates” the binary to fit at the address(es) available.)

In order to make life easier for the High Level Language compiler generator programs, each “kind” of High Level statement uses a template to generate the assembly language output. This output is assembled into a loadable binary data stream stored in a file. Because the template exists, the compiled CISC machine program often repeats templates, and does not utilize a processor’s full instruction set. Most of the time, the simple instructions consume more RAM space. Therefore, the CISC architecture does not often benefit the user (with exceptions).

The exceptions to the above statement include compiler optimizers. These optimizers have names such as peephole, redundant code, dead code elimination, loop nest optimization, etc. The true list is huge. However, for most code, especially for embedded code, these optimizers are not in play.

The reason embedded code generally goes lightweight on optimization is because embedded code has to assume this is the first time it has looked at memory locations. Otherwise, an optimized variable which has changed could be ignored. Bad news. Also, optimization changes code execution timing compared to code compiled as debug code. Worse news, in some cases.

Back To The PSOC3, PSOC5LP Discussion

One of the pitfalls of replacing a PSOC5 with a PSOC3 is the fact the ARM is a RISC processor with many registers. This means code that fits in 64K of Flash on the PSOC5 may not fit in 64K of Flash on the PSOC3. Also, its speed of execution is different at the same clock speed due to the smaller size of its registers.

So, be careful. Lightweight IOT applications can move back and forth from the PSOC3 to 5, but heavier applications will simply not fit in the PSOC3. I can’t tell you which ones will, you will have to test for yourself. If you can go to an 8051, and can change the PC Board, other options exist for today, to some extent.

The Pic and dsPic Family

MicroChip has surprised me. They have introduced their dsPic family (and kept their Pic family). The Pic family can operate at 5 volts (which newer Infineon parts cannot handle). In addition, several Pic family units are still in stock at distributors.

In addition, their dsPic family include Opamps, comparators, DAC’s, and A/D units. Since Infineon is going away from the PSOC UDB’s and Any Pin to Any Pin switch matrix for digital and analog simultaneously (as is available in the PSOC3 and PSOC5), there is no longer an overwhelming reason to select the PSOC processor family past the PSOC5. Reading the latest PSOC family data sheets and pinouts shows they look exactly like the Microchip/Atmel data sheets. Infineon is now a “me too” company for their new designs.

The thing that Pic and dsPic don’t have is the UDB framework of the PSOC3/5. Neither does (most of) the latest offerings from Infineon! So, if you can go with a newer PSOC unit, you may also be able to go with a PIC, possibly with great cost savings, and with part availability!

Fini

It is sad to see a marvelous SOC sub-family (the PSOC3/5) not being available at distributors for new designs. The newer PSOC 6x parts have many issues in the small business world. Not 5 volt compatible. Few or No UDB’s. Some are not supported in PSOC Creator 4.4. Cannot be put into designs which will be exported from the U.S.A. unless an exemption is obtained from the U.S. Government. (Granted, this license is usually easily obtained, but — paperwork.) The list goes on.