Ugh Post. Silicon Labs, Texas Instruments, Atmel, and Infineon

You will see “ugh” sprinkled throughout this post. It expresses dissatisfaction with the state or direction of offerings from companies. Hopefully, some clear thinking individuals with foresight can address and fix these ughs in the future. I will not hold my breath, and at my age, I may stop breathing soon anyway.

Infineon may soon be losing the race that Cypress started with the PSOC family. If PSOC processors were available at distributors, Infineon would be in a very good position at the top of the mountain. But, they are not available, in general. Their newer processors are generally available, but they don’t usually provide the fpga/cpld functionality needed for minimally sized boards used by weekend engineers. ugh.

Infineon Copying Others

In their latest offerings, Infineon has crippled its newer processors by reducing the number of UDB’s available (sometimes to 0). These processors have limited pin mapping functionality that totally brings to mind Atmel.

In addition, even for units with UDB’s, Infineon has sometimes not supported them in PSOC Creator. That IDE is the ONLY place you can configure the UDB’s free-style. (The PSOC 62 xxx 245 is NOT supported in PSOC Creator as of this writing late in 2022, but it does have UDB’s.)

TI has introduced Configurable Logic Blocks in their C2000 processor family, (TMS320F28xxx). These blocks can perform complex Look Up Table (LUT) functions, followed by Finite State Machine, followed by LUT functions. These CLB’s (called Tiles) are configured through a GUI that allows you to create equations for inputs (up to 4 per Tile, and up to 4 per section (LUT, FSM, LUT)). The tile outputs can be routed anywhere on the device. In addition to that, TI now allows the ability to map output pins with similar level of functionality as compared to the PSOC5LP.

Silicon Labs has, in their extremely inexpensive (as little as $1) 8051 family (EMF8BB5x) several CLU’s. These are blocks that have AND, OR, XOR, Muxing and a clocked Flip-Flop. I have yet to work with that processor family, but it looks intriguing. They also have Pin Mapping functionality.

Atmel has CLC’s which perform much the same functions as previously mentioned. That functionality is a bit more primitive; you have to implement in C or assembly code. Unfortunately Atmel charges a *lot* for their compilers in their free eclipse based development IDE, unless you can accept bloated code and minimal debugging information. Some forums did tests with their expensive compiler verses their free one. The expensive one reduces the code footprint by one-half, on average. Ugh. Not fun for the weekend engineer.

Infineon/Cypress Advantage is Still There

Infineon/Cypress’ main advantage in this race is their GUI Schematic Capture design environment, which creates Verilog code which is compiled by their Warp Verilog compiler and seamlessly integrated into their Board Support Package (BSP, or should I say, Psoc.S.P., PSP). So far, none of the other processor development environments support such a seamless, intuitive development environment. Even Infineon has abandoned the GUI schematic capture in their move to Modus Toolbox.

Eclipse. ugh.

Unfortunately, all of the above manufacturers use Eclipse as their development environment. Eclipse is ugly. It has been very unstable in the past. The way it mis-handles projects, text editing, and debugging is atrocious, in my opinion. But like Quigley, I can use it if I must.

For example, in testing the Atmel dsPic processor, I found that their Eclipse based MPLab’s breakpoints always were placed on the following line of executed code, even if that line was in a function call! Very disconcerting. It took a few minutes to understand the landscape. I felt it was straight from a bad Scifi show. Now, before the berating comments appear, please note I have used IDE’s since around 1980. There were good patterns in place long before Eclipse ever registered its presence in the ecosystem.

Open Source To The Rescue?

If the right people in the open source community get together, then a GUI can be created that allows schematic capture. Once that is done, the schematic capture can be compiled into essentially a PLD, or CPLD bit set which can be compiled into any of the above processors (including PSOC). At that point, Infineon will start to lose its edge.

This could be followed by something like a CLion clone, or QtCreator (which is fairly good at the moment), or even proprietary systems like VsCode. (VsCode is very good, and I generally don’t like M.S. tools. However, it generally breaks long standing GUI rules.)

I have yet to see any real interest for this direction in the open source community. This may be why Infineon is abandoning their push to make their processors with embedded dense CPLD units. I assume they see no economic upside, even though their competitors are heading in that direction. Like Motorola, they can be caught unawares and disappear from relevance.


There are now options for some level of logic driven outputs in embedded processors from manufacturers other than Infineon. If any of those manufacturers take the next step in the development environment world, they will get a very loyal following from the weekend engineering community.

Why do you think the AtMega units are in such high demand world wide? It is because of weekend engineers!

One Comment

Add a Comment

Your email address will not be published. Required fields are marked *