PSoC: Field Apps Engineer for Infineon (former Cypress) here. Questions? - Page 1
Forum section: electronics / general

author: theFarmgineer
author_rank: Newbie
timestamp: November 06, 2021, 05:51:46 am
content: Greetings everyone,First: Be gentle. No company is perfect. I am human (last I checked). I am here to help.I worked for Cypress Semiconductor, which has been acquired by Infineon Corporation. I want to answer any questions you may have about our PSoC microcontrollers.My microcontrollers are the Programmable System on Chip (PSoC). My sales pitch?The PSoC chips are built as Microcontroller+ type chips. Think of an MCU that has something extra built in. Most of the time, that means-Universal Digital Block (programmable digital logic fabric like an FPGA),-Capacitive sensing, or-bluetoothWe have 3 active lines for PSoC:-PSoC4 - a 32-bit ARM M0+ processor-PSoC5 - a 32-bit ARM M3 processor with a lot of features (such as CAN!)-PSoC6 - A 32-bit ARM M4 & M0+ dual core processor with options for crypto, secureboot, and audio interfaces (I2S, PDM)That's what makes us different.Lets talk about what makes us better. First off, our programming tools WERE known to be very easy. All PSoC4 and PSoC5 chips can still be programmed on the old PSoC Creator. Its an IDE so easy and cute that I use it to teach high schoolers how to program MCUs. We recently released Modus Toolbox, which is all of the fancy Linux type command line interfaces that modern MCU programmers expect.What makes us worse:No comment, I would like to keep my job, thank-you-very-much.I don't see a lot of projects with PSoC, and that's a shame! It's a good chip. I liked using them long before I worked for them. If you want something Arduino easy, but fully functional, PSoC4/5 is your mate. (PSoC6 is for hardcore nerds only, at the moment).

author: nctnico
author_rank: Super Contributor
timestamp: November 06, 2021, 07:19:23 am
content: I've looked at Psoc datasheets a couple of times but as someone very well versed in the use of CPLDs and FPGAs it is totally unclear to me what is the capacity of the programmable logic. How many LUTs / registers? Without that information I have no idea on what to expect in terms of the complexity that can be handled by the programmable logic. No, I'm not going to waste my time by starting a dummy project only to find out that a device is way too large or way too small.

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2021, 08:12:10 am
content: I personally would not consider any device where you are forced to "program" using wizards with windows-only IDE.And yes, those wizards and all the documentation I could find are carefully crafted to conceal the actual capabilities of the device. And it feels like those capabilities are decreasing in newer devices, which makes me think the whole programmable thing is less than efficient in practice.I'd rather use something I can program using open tools. Horrendous closed tools are tolerated in FPGA world, there is no need to bring that misery into the MCU world.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 06, 2021, 08:25:30 am
content: What ataradov said.This is more like a suggestion than question, but if you want to widen your target audience, consider releasing simple, barebones cross-platform tools andexamplesshowing what you can do with these chipswithoutthe point&click tools. Show us what you can do when you have full low-level control. Because it's very likely you can do even more. It may be "difficult" for some, but definitely not difficult for many of us professionals.The first thing I do with any new architecture is look at all the complexity of the examples (like 10000 LoC, 30 file Hello World which fails to print "Hello World" because logging level is set incorrectly by default in the fancy logging library used to print that "Hello World"!), then look at the library sources, then decide I don't need or want any of that, and start from a blank file. Hey, it isn't a special snowflake after all, I can program it like any other device, and that's astrengthmissed by the marketing. After a week I can basically start doing whatever I want.Is this possible with PSoC? Can I skip all the BS and just start programming? I'm fine reading 1000 pages of technical documentation to achieve what I want, but I'm not fine playing with limiting tools. I want control.I.e., every vendor markets their easy and simple IDE. You can't compete here*. But you can give better low-level documentation than others. You can support non-vendor-lock-in workflows. You can decide not to hide information. This is where everyone seems to struggle more or less.*) edit: maybe you can, by offering easy tools that are actually easy and work much better than some ST Cube crap for example. I don't know, I don't need/use said training wheels. But I recognize many do. If you do this well, keep doing it. I'm not suggesting of making a marketing shift, just considering how to appeal to larger audiences; and marketing to actual professionals could lead into large orders. Training wheels, not so much.But if people think this is kind of microcontroller version of LabView, the market is going to be limited. The idea is good but not for everyone.

author: PartialDischarge
author_rank: Super Contributor
timestamp: November 06, 2021, 08:27:30 am
content: I use Psoc in all my projects. When I saw how fast and easy it is to program even with little experience and knowledge of the peripherals, plus the analog electronics always save me some trouble.I'm not wasting my time looking for hidden configuration bits in large datasheets, when the real problem is in the electronics and that is what I need time to spend on.Why are you saying that Psoc creator was good?

author: PartialDischarge
author_rank: Super Contributor
timestamp: November 06, 2021, 08:34:07 am
content: Quote from: ataradov on November 06, 2021, 08:12:10 amLong live assembly code!

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2021, 08:34:40 am
content: Quote from: MasterTech on November 06, 2021, 08:27:30 amThis ease of initial use will transform into frustration of not being able to achieve things you need later on as the complexity of the projects increases.Quote from: MasterTech on November 06, 2021, 08:27:30 amMost likely new IDE will be garbage, just like every new FPGA IDE in recent years. And of course you will be forced to use it as new devices are not supported in the old one. And if you had open tools, your workflow would not change, but now you are at the mercy of the vendor.

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2021, 08:35:36 am
content: Quote from: MasterTech on November 06, 2021, 08:34:07 amExactly. Some things are only possible in assembly, and having this option is critical for me.

author: PartialDischarge
author_rank: Super Contributor
timestamp: November 06, 2021, 08:41:31 am
content: Quote from: ataradov on November 06, 2021, 08:34:40 amNonsense. The device is limited by the speed and peripherals, which you choose from start, it is not like my suddenly the same product is going to need an FPGA instead of a uP.Also you have not used this devices so you DO NOT KNOW how capable they are, yet here you are teaching us all. If you don't like the IDE there are specific commands with which you can control de peripheral. And moreover you can access the internals of the device, Cypress publishes the TRM Technical Reference Manual with all the minor details.

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2021, 08:47:15 am
content: I'm expressing my opinion on why "I don't see a lot of projects with PSoC" and why I personally would not use it currently. If there are enough people like me, then the answer is obvious. Others may contribute other reasons. I'm not teaching anyone anything.It is very simple - a device that is this good must be used by a lot of people, so there is something stopping them from using it.There are a lot of Chinese devices with no documentation at all, yet there are huge communities around them. Really attractive and capable silicon will get attention.

author: PartialDischarge
author_rank: Super Contributor
timestamp: November 06, 2021, 08:51:03 am
content: Quote from: ataradov on November 06, 2021, 08:47:15 amYes you are, you should be asking questions about Psoc and its tools first. The OP is here for that, that is what an average intelligent person would do. Instead you are assuming what you don't know and reaching conclusions.By the way you can use assembly in Psoc Creator, but doesn't matter bc is not good enough for you.Quote from: ataradov on November 06, 2021, 08:47:15 amHow many people/companies use Psoc? You don't know, you are assuming againQuote from: ataradov on November 06, 2021, 08:47:15 amThe price has nothing to do with it right? lol

author: PartialDischarge
author_rank: Super Contributor
timestamp: November 06, 2021, 09:29:34 am
content: Quote from: nctnico on November 06, 2021, 07:19:23 amThe complexity is not much, the UDBs are there as a glue logic. For example the Posc 4200 has 4 UDBs and each has 2 12C4 PLDs. They are described in the TRM

author: wek
author_rank: Frequent Contributor
timestamp: November 06, 2021, 10:10:58 am
content: Quote from: ataradov on November 06, 2021, 08:12:10 am+1I do have usage cases which probably would fit PSoCs, yet wasn't able to judge whether they'd fit, despite having installed the IDE and tried to play with it. I may be exceptionally dumb.Quote from: ataradov on November 06, 2021, 08:12:10 amI'd rather use something which is properly documented. Tools you can then make or get made (although you could argue that those then effectively open source for you), or you can get away without any specialized tools.Yes, I did write jedec bitstream for PALs/GALs manually. Yes, I understand implications of complexity and understand difference between complexity and sheer size.Quote from: ataradov on November 06, 2021, 08:12:10 amIt's already here, AS, Cube, Harmony and kin. I understand the appeal and also reasons why those who use them do like them and usually can't be explained why are they bad. It's simply an entirely different group of users.JW

author: Siwastaja
author_rank: Super Contributor
timestamp: November 06, 2021, 10:32:29 am
content: This doesn't need to be either-or. As a company, you can support easy "get started quickly, finish typical projects in no time" mindset, but also expose the full capability of the devices for people who have experience working with classic barebones tools. It only requires decent documentation and some example code.As always, I see the familiar pattern: amateurs who love their training wheels get pretty excited when professionals desirean optiontoalsoenable professional and sustainable development patterns. We (who like to have control and stable tools) never try to force our workflow on anyone else, yet the opposite is really true as can be evidenced in MasterTech's strong reactions on ataradov's comments.Similarly, just a decade ago I had to actively shake people off who were trying to "convert" me into using Arduinos in professional electronic design. Thank <deity> this is no longer happening. But now I have to actively prove why using STM32CubeMX is not a good idea. Again, thank <deity> I now have a very good business relationship with a trustable long-term customer who does not waste my time in such bullcrap.Look, not everyone is good with MCU or FPGA architectures, so it's really good to have sugarcoated/simplified approaches to enable such use case; as MasterTech shows, he's apparently good with analog design but not very experienced on MCU/FPGA architectures. Yet he needs to get the job done. Problem is solved with a well-designed beginner IDE. And problem being solved is obviously only a good thing, a huge timesaver. And if I understood correctly, PSoC shines in this side, their IDE is likely much better and more stable* than ST's solutions, for example.*) stable not meaning "not crashing", but meaning it isn't fundamentally redesigned or completely ditched every two yearsA one-man-show who needs to design analog and digital sides all alone may significantly benefit from having the "training wheels" on the areas where their expertise is lacking.But if you think about market shares, don't forget* Real professional teams* Medium and large customersThis is actually a funny discussion because just two decades ago, the opposite was happening, MCUs were only for experienced professionals and people were asking better support to enable beginners to work with the products. Now we are evidencing an overshoot to the opposite direction, we apparently need to beg for classical professional workflows.Quote from: wek on November 06, 2021, 10:10:58 amAFAIK (my experience is limited to avoiding Atmel Studio and Cube) these are simple to avoid, just ignore their existence, no problem whatsoever. The only thing I'd like to see are beginner tutorials to work without these unnecessary tools; but I don't personally need such tutorials so I don't care, just that it'd be nice to have more people See The Light. Now companies actively push a wedge between classic professionals and beginners. The problem this causes is a difficult transition from a not-a-beginner-anymore-but-still-using-Cube to an actual tool agnostic professional. It doesn't need to be that way; simple example projects would suffice.The current state of affairs (everybody is using ARM) especially enables tool agnostic development avoiding vendor lock in, for example I'm working with STM32 and nRF52 series microcontrollers side-by-side and have not had to spend a single eye blink to install any extra software or learn to use any new tool. Thanks to acceptable register level documentation on both product series, I just start writing code.Since PSoC is also ARM based, I'd like to use it without installing anything, as well. All you need to do is to provide a user manual to explain peripherals, analog/digital blocks, memory mapped registers, routing matrix, and if the thing really is FPGA-level complex, i.e., requiring automated place&route, provide a simple executable program to do said routing from some well accepted HDL such as VHDL. But configuration from C code could also work out and provide significant benefit for those experienced with MCUs but not FPGAs.Since the user segment who would like to see this (e.g., ataradov and myself) are typically quite experienced, you don't need to spend much time enabling their wishes; we are fine with some omissions, reverse-engineering broken peripherals, we have had to work with ST documentation after all. You can still keep the easy point&click IDE the main focus. It is most of the work anyway if you do it well.

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2021, 06:33:09 pm
content: Ok, so I gave the datasheet and reference manual another read, and here is what I can gather. There are 4 UDBs in PSoC 4200. Each UDB has two “12C4” PLDs. Each PLD is one 4-LUT and one FF. So in the end we have 8 4-LUT + 8 FF. Plus you get 4 8-bit ALUs that are loosely tied to the logic elements. This is far cry from FPGA.In general, I'd like to see some examples of this logic being used in a way that is otherwise not possible with other MCUs on the market. Reference manual lists a few use cases, but I don't see anything special about them. If I wanted more timers, I'll just take a device with more timers. I often see logic like this used to implement quadrature decoders. But again, if my application needs fast quadrature decoders, I'd probably go with an MCU that has hardware blocks for that. You know they will be much better.A lot of MCUs today have some level of programmable logic. Even the recent RP2040's PIO controller is a great example of this. It is not exactly FPGA, but it much better approximates what those programmable logic peripherals are typically used for.I'd love to see a general purpose and easy to use combination of MCU+FPGA, but it has to be a real FPGA, not 8 configurable blocks.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 06, 2021, 07:11:24 pm
content: Freely routable analog blocks are interesting, though.Think about what a typical STM32 implements. You can route current measurement signal to the internal analog comparator (and route internal DAC to the reference input), which then can terminate a timer PWM cycle. You can also route the same signal to ADC. But the routing is almost fixed, there are just a few possible combinations.Still they cater like 99% of use cases.But for the remaining 1%, having more freedom in number, types and routability of analog blocks would make a real difference.Yet I have never designed in a PSoC because I fear the vendor lock in. It's not only lock in to a single vendor, it's also a lock-in to a mindset and tools. I'd do it if it offered significant benefits (i.e., other ways were significantly inferior or next to impossible), but in reality, I rather use a standard $2 ARM MCU plus a few $0.50 external analog chips. Now go ahead and convince me why I should invest time in PSoC!

author: wek
author_rank: Frequent Contributor
timestamp: November 06, 2021, 07:48:24 pm
content: Quote from: ataradov on November 06, 2021, 06:33:09 pmSo did I.Quote from: ataradov on November 06, 2021, 06:33:09 pmNot quite. This is a PLD like a PAL. The AND/OR matrix is arguably more flexible than a LUT, at significant cost of silicon area. And there's a FF (plus some additional logic) per PLD output; there are 4 outputs per PLD, so there are 4*2*4=32 FF total.The detailed behaviour and intended usage of PLD is slightly different from PGA. Think difference between 8-bit mcu (limited arithmetic/addressing capabilities, clock-precise timing) vs. 32-bit mcu (huge math, wobbly timing). This is aimed at relatively small logic which you'd typically pull out with a bunch of 74xx.Yes, this caters for niche applications. As I've said, I do have usage case for this (and used uPSD3xxx for similar tasks in the past); but I was not able - even after re-read - to find out the exact routing constraints. Even information vital for "normal" programming is PITA to gather, having to combine DS + "Architectural TRM" with the "Registers TRM", and add some guesswork. UDB is obviously programmed through the miniscule "processor" ("working registers" of "datapath"); but the UDB internals are entirely undocumented so there's no way to do that outside the clicky.I'd like to see examples, too, but documentation is first.Quote from: Siwastaja on November 06, 2021, 10:32:29 amThe problem is in the "only".Chipmakers don't sell chips to engineers; they sell them to managers. And managers like to hear things like "rapid development", "free tools", "no skilled personnel needed", etc. That's where clickies (clickeys?) stem from primarily (and I do see the merits of them, if done properly, which they are not).Making the clicky is expensive and having done the task - selling chips - there's no justification for managers to spend money on documentation and example code (including application notes). And *good* documentation and *good* example code are VERY expensive. ST openly cited cost ("internal engagements") when refusing to provide decent examples.JW

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2021, 08:10:39 pm
content: Yes, I stand corrected. I see "From OR gate" signal going into the FF block from the AND/OR matrix. So you do get 32 FFs.From the community point of view, you just need to have an interesting product. Community made ESP8266 happen even with initially stolen SDK and no support at all. Yet the device itself had enough potential that it was worth reverse-engineering it. I personally don't see anything interesting in PSoC at this time to be worth doing it. It is a mid-range MCU with one potentially interesting peripheral. Publishing full documentation may make more people try it, and may be enough interesting use cases will be found to tip the balance.

author: Kleinstein
author_rank: Super Contributor
timestamp: November 06, 2021, 08:49:42 pm
content: Programmable logic is no good if it is documented. I have not much knowledge about PLDs, but to me this looks like too much to program / design totally by hand and to little to work well with a HDL. Especially with a slightly unusual arcitecture this would need it's own HLD compiler and environment. PLD usage depends a lot on the support and IDE.A little programmable logic is nice. Many µCs provides quite a few of the main uses already as special functions of the normal periphery ( e.g. break mode with timers).

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2021, 08:58:33 pm
content: Well, I may like spending time programming things by hand that may not be designed to be programmed by hand. Sometimes you have to do that, even with big FPGAs (for critical pars of the design, of course). You always have option to use whatever tools available. But if there is no documentation, you must use those tools.Also, with proper documentation you may see community come up with way better tools. As it was mentioned, tools are cost centers for silicon vendors, they get as little investment as possible to make a barely tolerable product. If purchasing managers don't get scared, then it is assumed that programmers will deal with it, they have no other options.

author: nctnico
author_rank: Super Contributor
timestamp: November 06, 2021, 10:55:03 pm
content: Quote from: MasterTech on November 06, 2021, 08:41:31 amThat is the problem right there: the datasheet gives no indication on the device's capabilities. What should give PSOC an edge over standard microcontrollers is the ability to create non-standard peripherals. But due to the lack of specs in the datasheet there is no way to tell what PSOC device would support a certain kind of non-standard peripheral. IMHO the Gowin FPGA devices with an embedded ARM core are a much safer choice.

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2021, 11:10:18 pm
content: With 32 FFs you will not be creating any non-standard peripherals anyway, apart from trivial stuff like CRC, which is included in any decent MCU as a standard block anyway. Just like with other MCUs (CCL on Microchip/Atmel, PLU on NXP) this is just a bit of configurable logic. Sure, it is the most advanced one, but it is still not all that useful. Calling it "FPGA" what gets you into trouble, like Tesla and their autopilot.And chances are that you need a bit of that logic, and your application also fits into the constraints of the rest of the MCU are even slimmer.That's why all the marketing is centered around magic wizard-based IDE. Hardware-wise those devices don't have much going for them.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 07, 2021, 12:17:33 am
content: Unfortunately - and this is just opinion here - those PSoC chips, although sounding interesting when they were released, have little appeal these days compared to what's available on the market...Having some embedded programmable logic is good, but as said above, here it's too little. You can do a lot more with NXP's FlexIO + Xbar, for instance. Otherwise their feature set is OK but nothing special.Also, same opinion as some others regarding dev tools. A quick look at the web site shows that you indeed offer some GUI dev tool, but no SDK? (I'm pretty sure the GUI tool uses some kind of library under the hood, as it generates codes which calls library functions, but in this case, it would be good to release said library as source code as others do, and document it, so we can use the chips without the GUI tool.)So yeah, I don't know. When I first heard of those PSoC a few years ago, I got interested - the promise of MCU + small embedded FPGA thing - but it turned out pretty disappointing in that regard, so...If you released something with a real block of FPGA fabric in there, programmable in HDL, with a decent number of logic cells, while keeping power consumption reasonably low (otherwise there are already solutions for larger FPGA + more powerful MCU on the market, such as the Zynq parts and such...), that could already be more interesting. Just a thought. You guys seem to be trying to target the "IoT" market, but it's already crowded and maybe, just maybe, you should try to target other markets...

author: PartialDischarge
author_rank: Super Contributor
timestamp: November 07, 2021, 08:46:23 am
content: Quote from: nctnico on November 06, 2021, 10:55:03 pmYeah, whatever criticism is valid at this point.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 07, 2021, 08:55:01 am
content: A few more opamps and comparators (4 and 4, respectively) than in the "usual suspects" (1-2 each). I understand sometimes this makes a difference, but in the "usual suspects", the opamps and comparators are directly usable with a few minutes of time spent without any special software or tooling. This is the problem as I see it. I can use the comparator in STM32 with zero extra effort and without to have install anything on my workstation, and the usage is directly visible, changeable, and documented in the C code itself. If I need two comparators, then I'm tempted to buy an external $0.20 comparator in some tiny SMT package.Some near $10 parts come with one 1MSPS 12-bit SAR ADC only. STM32F0 series (for $0.50 ea)startfrom this single 1MSPS 12-bit SAR ADC and the $10 models employ typically at least two separate 2-3MSPS 12- or 14-bit SAR ADCs.Am I missing something?

author: PartialDischarge
author_rank: Super Contributor
timestamp: November 07, 2021, 09:03:40 am
content: Overall this is a funny thread. Non-users of a product telling you not to use it, basically because it is too low speced for your needs and you need a Zync not a Psoc, or whatever nitpick. Comment such as "this is far cry from FPGA" are quite insightful in that it reveals that bashing a product main reason is to show-off and portray how expert the haters are. This product is too few for them and they know much better.It reminds me of Mac vs Pc discussion in which Mac haters point that a Mac has not PCI slots and no the latest processor and bla bla bla, yet they conveniently forget that the SW makes the difference in a Mac vs Pc, which last time I checked it still pure trashcan rubbish in a Pc.Psoc has a nice variety of ICs from small packages to large TQFPs, from 24 to 80MHz, with added analog and programmable digital glue hardware PLUS the Psoc Creator which allow for quick development of general use control solutions with very fast time to market, in which I don't even need to read a datasheet to generate a PWM with dead time, and you can all self-called experts ignore this point but this tool makes 80% of the reason why I use Psoc.I even did program a very demanding application in terms of formulas to be evaluated in a Psoc 5 to find the position of a magnet in space with 4 3D magnetometers:

author: fourtytwo42
author_rank: Super Contributor
timestamp: November 07, 2021, 09:48:56 am
content: I looked at using PSOC several years ago in a power converter where I was having trouble with the micro-controller PWM subsystem. As an experienced fpga/pld user i was hoping the psoc would solve my problems but unfortunately not. They have buried the functionality with stupid application software and as a result do not even document the capabilities. Pity, they came up with a good useful device that filled a market niche and then let the marketing goons destroy it. Had it been any good I could have used it in many other applications too, there loss.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 07, 2021, 09:53:42 am
content: Quote from: MasterTech on November 07, 2021, 09:03:40 amNo one said that. You are literally the only one who's forcing your way of thinking to others and derailing the discussion into fruitless battle. Cut it and let us talk. I'm sure the OP from Cypress can take it, and we can make this afruitfuldiscussion if you let us. Look, even if you are, not everyone else is a fanboy. Many of us are really experienced in using whatever parts from whatever manufacturer. Technical details matter. Thank you in advance.

author: dgtl
author_rank: Regular Contributor
timestamp: November 07, 2021, 12:08:10 pm
content: Let me give my insight of PSoC as I have been trying it out for both professional and hobby stuff. I haven't touched PSoCs for a couple of years now, so if things have changed then correct me.In my opinion the real strength is the UDB, otherwise it is just a microcontroller as any other. If i'd like to get full gpio multiplexing, there are cheaper microcontrollers with that (LPC15?). For the most of the designs, the modern mcu-s have plenty of peripherals and having a spare uart makes pin muxing much more simple, there is no need to go full matrix. The peripherals are just cheap and plentyful. The partially universal serial peripherals (ie UART capable doing SPI etc) or even the even more universal SAMD sercom make more sense than making serial ports in UDB. Gaining the universalness of trading uarts for timers is not worth it for me. It's 2021 and the price of a transistor on silicon die is not that expensive anymore to worry about the cost of unused peripherals. Perhaps if there would easy ways to work with the existing UDB designs, it would be more useful to hack a feature in here and there, in case I'd need some quirk for an existing peripheral. But for this to work out, the stuff should be oriented to hard-core low-level developers, unlike it now is.The PSoC creator software has had a lot of work put into it and is probably one of the most polished vendor ide-s out there. But it does not fit me. First, none of my machines run windows, except a virtual machine used for things like that. Also, it contains too much point-and-click for my liking. Give me good documentation of register level peripherals and I can handle the rest, like with all the other Cortex-M microcontrollers. It is not special, it is just another Cortex-M. In the Cypress case, I need to know another framework pushed on me. What all the APIs look like, what they do in hardware etc. This stuff may suit for Arduino-like users and it is a very important step of getting more professional at it, but that is already behind me. There have been some hacks that revealed the built-in ROM stuff in the PSoCs, which show what Cypress has been hiding from the user with unusually high efforts and all of this makes me feel that they don't like the users to step outside of their comfy gui wizard thingy and that is just too much limitations for me.Why not just provide a simple Makefile project to compile with gcc? The designs to put into UDBs as simple C source, that just write the config registers in uart_init() to configure the UDBs and have a very thing example on top of it? Flash and debug it via OpenOCD using whatever tools I already have?Where the UDB really shines is making custom peripherals for obscure interfaces. For example if you need a 1-wire slave port. Or driving a lot of WS2812 led chains in parallel. As usual, those use cases can either be handled by throwing more cpu power on it and just bitbanging the whole thing in software (ie via timer IRQs etc). Going the route of custom peripherals needs a lot of specialized know-how. It is fun in the sense of solving a challenging technical puzzle, but usually not worth financially. When going that deep into the PSoC, you're out of the shiny gui wizard territory. The UDB is not an fpga, it is just too small to write HDL and let the tools synthesize it. It works only when using both parts of it (PLD, datapath) and this means manually designing your controller for that exact system. It is a fine puzzle - the documentation is difficult and the needed know-how is quite deep to be good at it. You really need to visualize the datapath internals at the lowest level and map your function to it. At some point, the tools start getting in the way and not letting some configurations be entered that were possible via documentation (it was some years ago, perhaps things have improved). In any case, the GUI does not seem to help much, i'd rather write some files and let a tool to compile them. Finally, I'll need to figure out the software interfacing for that component, that is another puzzle through all those APIs and miles of not-so-well documented auto-generated stuff. I did get my stuff working, but I do not feel that I'd do this for any commercial work.I cannot figure out the usefulness of the PSoC:* Strength: Cool hardware, that could be hacked at very low level - but the software on top of it is dumbed down* Strength: Making custom hardware interfaces - but it is so damn hard, that bitbanging in software on much more capable mcu makes more sense* Strength: Standard Cortex-M microcontroller - but is hard to use the same stuff that works on the rest of them...

author: PartialDischarge
author_rank: Super Contributor
timestamp: November 07, 2021, 12:51:11 pm
content: Quote from: Siwastaja on November 07, 2021, 09:53:42 amI'm the only one here giving useful info about Psoc and correcting your misconceptions, who knows what it is good for and what it is not for. You're all just bashing it, and still haven't even been able to praise it for a certain number of applications.Quote from: Siwastaja on November 07, 2021, 09:53:42 amSnowflake much?. You're saying whatever you want, that you are an expert and bla bla. Keep at it, I don't mind.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 07, 2021, 01:38:15 pm
content: In any case, this thread already shows why the market share for PSoC is what it is and stays that way;We have approx. 8 quite experienced professionals happy working with many different product families and tools reporting:* They want better documentation about internals* They want freedom from Windows-only point&click interface* They don't see large enough difference to other microcontroller families which also offer routability and configurabilityAnd then we have one hobbyist(?) fanboy who reports using PSoC for every project(!), ridicules usage of assembly language, ridicules experts calling themselves experts, and gets butthurt when others do not agree. (Really, I don't care about the brand the slightest, and am not interested inbashingany microcontroller series. My mind does not work that way.)It must be nice to have a product nice enough to create fanboyism - it doesn't happen with all silicon manufacturers at all! But at the same time, on silicon business, it does not generate much cash flow. You are not Apple or Tesla.This 8:1 ratio of comments also translates into the customer base. As long as the main target audience for PSoC are those who cannot afford learning to work with microcontrollers "the classic way" andneeda Labview-like interface, it stays quite niche. To compare, Arduino is highly successful but they are not a silicon company, they took an existing microcontroller and "dumbed it down" at PCB module level.And don't get me wrong, this isnotto say to abandon the pointy-clicky. Apparently, according to the comments I have heard earlier too, it's very good in its own genre and directly responsible for all the successful business in that segment. If you re-do it, the risk is you lose part of the existing customers, too.But at the same time, trusting in your successful workflow only, is a limiting factor for growth.Another limiting factor might be the disappointing nature of the HW itself. Not saying it's bad, but marketing and fanboys make it sound even better than it actually seems to be. Sure, it's quite flexible, but many others have become better as well within the traditional product segments without any big words. The bar is set higher today for the "baseline product"! You can't afford being just "a tad" better. Traditional MCUs handle 99% of projects just fine. You need to be able to handle significant part of the remaining 1%, and for that to happen, the products need to really shine.If you want to see how you can get free routability of IO and ease of register level use in the same package, look at the Nordic Semiconductor products. Look at the manual to see how easy it is to configure a peripheral in whatever pins and DMA it.Make your products even more capable and give barebones documentation (doesn't need to be polished; as ataradov says, we are fine reverse-engineering a bit if the HW is good) and I'm sure you can get more market share. Especially now as it seems you can't buy STM32 in next 12 months anyway, now it's good time to compete. And I'm sure all of us "critics" wish very best for PSoC product line because really, it's always great to have options.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 07, 2021, 06:17:41 pm
content: Do not waste too much time replying to "flamewar" posts...As it is, the OP themselves clearly stated:QuoteSo experienced people giving the OP some possible reasons (and why they themselves wouldn't consider those products) sounds like something the OP (and possibly Infineon) could benefit from.To add to what we said, interestingly here, the OP seems to be targetting the typical "Arduino" users, which are a majority of hobbyists. So no wonder there is misunderstanding here. The vendor may have a GUI-based dev tool that might be good for hobbyists (although even that point remains to be seen: I'm not even convinced of that), but the PSoC products were never marketed for hobbyists (and this would be way too small of a market for Cypress/Infineon anyway). So how can you wonder why they have a hard time finding their market? As I said, first thing would be to really define your markets and then design products accordingly... Do not reduce my (and others') opinion to "those chips are bad", this is absolutely not what anyone said here. Just that I do think there's a market problem here. Take it or leave it.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 07, 2021, 06:30:40 pm
content: To widen the market (to get "more projects"), I see exactly two possibilities:1) Widen towards the "Arduino hobbyist" direction. This isn't negligible market anymore, most companies now take this seriously. As far as I understand, the current Windows tooling is quite suitable for Arduino folks. So to reach them, you'd need to add two vital things:* Visible guerilla marketing, coming up with stories why Arduino hobbyists need or want PSoC.* Very affordable simple boards/modules, similar to the Arduino boards. A $10 PCB with your $5 MCU, with USB connector, regulator, and pins brought out. $15 TOPS! With good availability, consider selling direct on a web store with free shipping, or getting a partner to do it for you. Many beginners are not comfortable ordering from Digikey.2) Widen towards the professional electronic design direction. This is larger market obviously but surprisingly, more fragmented because different sizes and types of companies work in very different ways. Depending on the company, you need to:* Reach out to the managers and ignore engineers; and/or:* Reach out to the engineers and ignore managers,If you do the latter, you will find some very thankful engineers and theremightbe some synergy between hobbyist and professional segment (but don't count on it). This means exactly implementing the points already well explained in numerous posts in this thread, I'm not going to rephrase them.Whatever you do, don't reinvent your point-clicky because apparently many people like it. There are only risks involved.

author: ataradov
author_rank: Super Contributor
timestamp: November 07, 2021, 06:47:47 pm
content: Many companies tried to shoehorn their product into Arduino-like environment, most failed (including Atmel/Microchip with anything that is not ATmega and SAM D21 to some extent).The primary thing I want to see here is unique things I can do with the programmable logic part, since this is the only distinguishing part of this device. If there are cool use cases, then there is something to talk about. If we are still talking about trivial stuff like quadrature decoders, then no need to bother. It has to be something that is impossible to do otherwise. If it is just something to compensate shortcomings of the device, and others have it as a native feature, then I'll just use other devices.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 07, 2021, 07:16:16 pm
content: GUI-based (AKA "RAD") tools are meant to either appeal to beginners/hobbyists (and not all of them!) or *some* managers that might be sold the idea that firmware development will be so much faster and will require fewer (and, let's admit it, less qualified) engineers. But it's a rabbit hole. You end up paying the consequences of driving a project using less qualified people, and just postpone the inevitable maintenance issues down the line. Maintaining firmware developed with GUI tools can often become a nightmare, and things get even worse if said tools have evolved in between and are note quite compatible anymore. Then you'll do the dance of trying to get ahold of an older version, which might not run on currrent OS versions. Etc.Oh and still something to consider: even though Arduino in general is not particularly made for professional use, it's still entirely programming-based. It's not without its own flaws, but is still based on C++. If Arduino had been based on point-clicky stuff, I'm not sure it would have taken off and gotten as popular as it is now. So that's another thought.

author: poorchava
author_rank: Super Contributor
timestamp: November 07, 2021, 11:24:50 pm
content: My question would be: why is it so crazy expensive? I mean in lower volumes for the price of 1 PSoC5, which is something like 67/80MHz CM3, I can get TWO 480MHz STM32H7s (ok, I would be able to, if they were available at all, but PSoC5 are unavailable either).The programmable logic aspect is nice. Dev tools are also nice, But every time I had an opportunity to use one, the cost was just prohibitive.Is this the same stupid sales tactic / politic that Wurth Elektronik uses (aka - retail prices even in 1k quantities are 2...3x higher than actual prices u get after speaking to a sales rep?)As for the GUI, I don't really understand the hostility against it (and against various HALs, driverlibs, etc). If you don't like it or you can't accomplish what you need, or the performance sucks nobody is preventing you from banging the registers.We actually use code generation GUIs for various chips (mainly STM32 and TI C2000) and it just cuts NRE time/cost down. And believe me when I say it: engineers at our company are as far from 'Arduino crowd" as one can possible be.I don't really understand the "windows-only" argument. Linux is dead as far as serious engineering goes. Almost all reasonable CAD software runs under Windows. Plus all the "Linux is free if your time is worth 0" stuff. Maybe it's good for web development or something, but I really don't see how Linux is relevent to Electronic/Electric/Mechanical engineering/CAD.1 instance when I found PSoC useful (well, actually it was a PRoC, so no programmable logic, there are PSoCs with BLE integrated into them) was making a simple and cheap gizmo that communicated over BLE. This was probably the only part family that had a simple to use toolchain where I could just add some simple logic to the radio without adding a separate MCU to blink a led and talk with RF over [insert some serial interface here].I have to say, that analog peripherals are not that bad on PSoC5 - I mean the ADC performance is similar to STM32 and just a bit worse than C2000. Not bad if you compare it against stuff like some PIC18s that had 12-bit ADC with +/-13 LSB INL+DNL and ENOB of ~8. Opamps with 2mV ofset and RRIO and 2MHz GBP are not bad either, at least for some rough measurements (I'm in precision T&M industry, so I'm probably a bit biased...)

author: ataradov
author_rank: Super Contributor
timestamp: November 07, 2021, 11:39:32 pm
content: Quote from: poorchava on November 07, 2021, 11:24:50 pmThis is the whole point here. You can't bang anything as the logic block is not documented at all on the low level. And if you are not using this part for the logic block, why are you using it at all? There are so many parts out there that are better in pretty much all respects.

author: poorchava
author_rank: Super Contributor
timestamp: November 07, 2021, 11:51:31 pm
content: Quote from: ataradov on November 07, 2021, 11:39:32 pmWell, neither are most programmable logic devices. Most FPGAs that have hard blocks use GUI to configure them. Bitstream etc is also not documented, aside from some simple iCE40, that somebody reverse engineered. Most software nowadays has GUI...

author: ataradov
author_rank: Super Contributor
timestamp: November 08, 2021, 12:13:20 am
content: Quote from: poorchava on November 07, 2021, 11:51:31 pmBut none of them need GUI. Vendor tools work from command line (under at least Win and Linux) and everything can be described using HDL. And documentation is sufficient to write code that would instantiate a standard IP. And nobody is thinking that it is a good idea either, hence the reverse engineering attempts.Here we have a completely different case. There is no immediately apparent reason to use PSoC, and poor documentation does not help the case.And comparing that 32 FF logic unit to FPGA makes no sense either. In no way this is anything like FPGA.

author: nctnico
author_rank: Super Contributor
timestamp: November 08, 2021, 07:05:26 am
content: Quote from: ataradov on November 08, 2021, 12:13:20 amI don't think there is a standard which says how many flipflops an FPGA needs to have in order to be called an FPGA. What is more important is to have a uniform flow. The PSoC tools seem to support using VHDL and Verilog so that should allow to re-use existing code on a PSoC. I typically use VHDL for tiny CPLDs as well just because it gives me a standard workflow to use programmable logic devices. But in the case of PSoC there is no clear information in the datasheet (using standard programmable logic metrics like LUTs, product terms, registers, etc) to indicate how much resources are available for use as programmable logic.Quote from: poorchava on November 07, 2021, 11:24:50 pmEven Gowin has a Linux version of their software nowadays. If you look more carefully you'll see every major vendor of programmable logic has a Linux version available of their tools. I doubt they made that just for fun. So yes, having a Linux version available for the software is a big plus to win design-ins.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 08, 2021, 08:13:10 am
content: Factis, even though many if not most professional design houses use Windows exclusively (and that does work, I have evidenced it myself), noteveryonedoes that, especially when the main focus of the design team is insoftware(possibly stack of firmware and higher level processing).HW CAD (SolidWorks, Fusion, Altium...), sure, happens mostly in MS Windows. This doesn'talwaysmean firmware development happens, too.Here's the catch: the more niche your product segment, the higher the chances the development cycle doesn't use MS Windows. Sure, MS Windows might be behind 95% of firmwares, but most of them are those super generic products that just use some very basic STM32F0..STM32F4 device. Those wouldn't buy PSoCanyway.Now if your product is totally exceptional and you can't live without, everyone can accept MS Windows. But when competition is more dire, completely artificial limitations like this is one bullet point more in the pro/con list.So this is great example of sacrificing market share by limiting choices.Cross-platform software development is considered standard practice today. If you have competent developers, you can support all major OS's with not much cost overhead. The wider market pays back in no time.

author: PartialDischarge
author_rank: Super Contributor
timestamp: November 08, 2021, 08:41:34 am
content: Quote from: poorchava on November 07, 2021, 11:24:50 pmThat is the main problem with Psocs. Fortunately the products I develop are not cost sensitive so +-5€ is fine, and long ago I decided that I didn't want to have any more than necessary time spent on the SW since the HW is the difficult part.Happy I was the day I deleted Code Composer Studio.

author: poorchava
author_rank: Super Contributor
timestamp: November 09, 2021, 08:32:36 pm
content: Quote from: MasterTech on November 08, 2021, 08:41:34 amWell, my job is specialist T&M gear for power industry and related fields, so cost Is also not the primary issue here. Bute as one of my friends, who is quite well-off said: "rich or not, I'm not gonna pay $100 for a cabbage". It's the same here - radio chips seem to be the only justifiable part of that portfolio, as they don't require expensive sw tools to develop code for. The other stuff is just too expensive too justify.The only use case for those that I can imagine, is if you need to make something REALLY small, yet can't go into custom silicon. Then maybe having some logic and analog integrated into a single chip makes sense.I recall a show at Electronica Munich, I think 2016 or 2019, where they made a line follower robot with something like 5 lines of code. Nice, but commercially irrelevant.As for Code Composer: I use TI's C2000 DSc's... Those parts really leave others behind when it comes to digital SMPS and power quality analysis. Compiler produces very high performance code. In general for DSP-ish applications (filters, FFTs, smps/motor control) A 100MHz C2000 performs better than STM32F7 @ 216 Mhz. But the toolchain, IDE and documentation are some different dimension of garbage... They are improving now, but it's still really painful when compared to STM32 IDE, or even MPLAB

author: westfw
author_rank: Super Contributor
timestamp: November 10, 2021, 12:14:54 am
content: I'll have to admit to being relieved/happy when the PSOC4 started including "standard peripherals" like USART and SPI, instead of requiring that those be built out of the logic cells. That made it a lot easier to start at a "general purpose part" view, and see "what else" could be done, rather than guessing what might be "left over."

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: November 10, 2021, 06:07:11 am
content: One feature I would like to see which would come for free once the programmable analog and digital hardware are exposed to the programmer is on the fly reconfiguration of the analog subsystem. My line of work (at a small remote sensing research group) requires some hardware whose functions are not fully defined when deployed. Being able to reprogram the analog interconnect without a reflash would be a great help.The PSOC5's programmable analog and digital blocks combined with an ARM core are a good match for many of the boards I design, and the ability to assign special functions (including analog) to any pin greatly simplifies my board layouts. However, none of this matters right now since I can't buy any devices (repeatedly quoted > 1 year lead times), so looking hard at alternatives.While PSOC Creator is quite nice, I would love it if I could stick with my IDE of choice (vim and Makefiles). The cysch blob and xml also don't play nice with version control (though this is better than, say Xilinx ISE since user preferences are in a separate xml file that isn't version controlled). I can't really do a diff between today's cysch and yesterdays to see what changed.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 10, 2021, 08:38:14 am
content: The great feature in modern general purpose MCUs like STM32 series is, their analog blocks and signal routing is controlled by memory mapped control register writes and hence accessible from C(++), ASM or whatever you are writing the application in. This also makes dynamic reconfiguration a total no-brainer, you don't even think about it being dynamic reconfiguration, it just is.This is also why I don't use Cube-like code generation. They generate long piece of initialization code which is then in the beginning of the application. Of course you can divide it in parts, shuffle it around and so on, but then you lose the simplicity of autogeneration, need to understand that autogenerated code, maintain it, and this is more work than writing more minimalistic code yourself.I'm surprised if PSoC analog block routing cannot be configured runtime, or if it is more difficult than it needs to be. Is this true?Really, look at the nRF series, how they implemented full free IO matrix. You write port and pin number in a register and bang, it's connected. One obvious line of code that directly shows the pin number:UART1->PSEL.TXD = 0<<5 | 27; // connect UART TX to pin 27 of port 0.Seeing PSoC series really doesn't implement FPGA level of complexity, what is preventing this approach to be offered? If the internal registers are not designed as cleanly as nRF did, then simple wrapper functions could be offered, they would also work as documentation and examples.

author: JPortici
author_rank: Super Contributor
timestamp: November 10, 2021, 09:45:22 am
content: Quote from: poorchava on November 07, 2021, 11:24:50 pmFrom time to time i have to dig out old libraries/AN from various manufacturers and they usually come in a prepackaged EXE file instead of for example a zip archive.The exe file is more often than not difficult to open because it requires some component not available since XP or, even worse, it's a 16 bit executable.The problem with "windows only" solutions is that they usually are closed and/or lack in documentation, which means that when the one click solution won't be mantained anymore you will be screwed.I tend to not use radios from silabs for this very reason. Before you can start using the goddamn chip you have to load a binary blob with no documentation whatsoever, not even on what you have to do to start the chip.More or less as with screens you have to get an autogenerated project and dig though the code and the macros

author: bingo600
author_rank: Super Contributor
timestamp: November 10, 2021, 09:54:58 am
content: Lot's of info & questions here.The only thing i miss is that theOPwould answer some of them.WasOPjust a "Catalyst" from marketing ??/Bingo

author: RoGeorge
author_rank: Super Contributor
timestamp: November 10, 2021, 09:57:39 am
content: Quote from: poorchava on November 07, 2021, 11:24:50 pmThat is so not true it reminded me about Kupamanduka concept.https://en.wikipedia.org/wiki/Kupamanduka

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 10, 2021, 11:05:02 am
content: Quote from: poorchava on November 07, 2021, 11:24:50 pmUnless you doseriousengineering, like distributed stress FEM analysis (mechanical engineering) or fluid flow analysis (chemical/process engineering) or use custom code for finding optimal routing patterns (electrical engineering), and similar. You either do that stuff on your desktop PC, or you use a cheap Linux cluster (with expensive Nvidia cards) to do it one or more orders of magnitude faster, leaving you with a functional desktop machine to do other useful stuff at the same time.As far as I understand it, only the middle to low end engineering houses are Windows-only; the ones that do mostly the same jobs again and again for different customers, and not anything really new.Among the current 500 largest computing clusters, there are 500 running Linux and 0 running Windows or anything else. There is a reason for that, and it isn't that "Linux does not cost any money". Microsoft has spent a lot of money subsidizing attempts to crack the 500, and the amount of hardware they needed to get comparable performance was so ridiculous even they gave up. Even Azure runs on Linux. (I do not have statistics on engineering houses, so I grabbed the ones I know, that cover the top 500 HPC clusters.)Fact is, for pure computation tasks, Linux is much more efficient than Windows is, no matter how much you prefer Windows.I've done HPC for a living, and even maintained a mixed set of Windows, Linux, and Mac OS (pre-X) desktop workstations quite successfully, so I'm not your typical "Linux fanboi". I use whatever tool is suitable for the task. And Tux is only my mascot, not my idol. Whenever I build a new desktop for myself, I almost always get a free Windows license on top (simply because retailers include it when you buy a specific component set; it's difficult to avoid paying the 'Microsoft tax'), sopriceisn't one of the reasons why I use Linux exclusively. I do often help others port their proprietary stuff between Linux and Windows/Macs, but mostly on the Linux side.I compile C and C++ for avr, x86-64, various arm, aarch64 (64-bit arm), and mipsel_24kc (ramips); and these are currently best supported by GCC and LLVM/clang. Intel C compiler collection generates better code for x86-64, but I'm just fed up with the shenanigans it used to do to explicitly hobble AMD64 code when running on AMD processors, so I don't nowadays bother with it; the hassles are not worth the gains, especially now that Intel-AMD processor battles are heating up again.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: November 10, 2021, 03:05:08 pm
content: Quote from: Siwastaja on November 10, 2021, 08:38:14 amIt is nice at the early stages of a project - it's easy to get up and running quickly without trudging through a ton of initialization code. Later on though, one can't easily use tools to find/document changes, that's what I feel is the shortcoming. An interesting half-way approach is taken by ChibiOS HAL - the init code is table driven. You stuff the parameters into a struct and pass it to the pre-written init code. As long as you trust their HAL code, this approach is the best of both worlds since the GUI tool that you use at the early stages can write out the config struct, and then it becomes part of your version-controlled code. Any manually edited changes are visible to the VCS and it's easy enough for the GUI tool to parse the source file containing the init struct if you ever go back to it.Quote from: Siwastaja on November 10, 2021, 08:38:14 amI can only speculate, but their argument may go along the lines of FPGA vendors that opening up the config registers reveals too much of their internal design details. Thanks for the pointer to the nRF series, will check them out.The UDBs shine when implementing bits of glue logic. Often, the timers and capture hardware offered by a micro doesalmostexactly what I want. With the UDBs, I can add a bit of glue logic to make that happen, and if I messed up it's easy to reconfigure it without a board respin. Configuring the UDBs at the register level would be quite painful, much easier with a GUI tool, or HDL (latter preferred). The funny thing is that it looks like Cypress internally uses an HDL of some kind, during the build process one can see messages to that effect. Cypress had been in the PLD business for several decades and their HDL tools are robust (if a bit quirky - remember Warp?), so it's puzzling that they lock out end-users.Quote from: JPortici on November 10, 2021, 09:45:22 amThis used to be Windows' strength - backwards compatibility at all costs. When that cost started to include security, people took notice and they've now started reversing the trend. With Linux, if I have a dev tool that needs a specific kernel or distro, it's easy to spin up a VM or docker to host it. Doing so with Windows needs a license, verification, authentication bla bla and you've become an IT expert by the time you're done.Quote from: Nominal Animal on November 10, 2021, 11:05:02 am

author: Bassman59
author_rank: Super Contributor
timestamp: November 10, 2021, 05:29:59 pm
content: I would like to thank the Cypress/Infineon engineer for offering to help with the devices.As usual the thread devolved into irrelevant discussions about the quality and usability of the tools and a rehash of that same discussion about every vendor's tools, so perhaps the original support offer got lost.Would I use these devices? Sure, if they fit well with a product design's needs. It's the same idea as the XMOS processors: cool idea, but would they work for a particular design? My current work is 100% FPGA, no embedded processors or suchlike, and this is driven by design requirements and nothing else.

author: mjs
author_rank: Regular Contributor
timestamp: November 10, 2021, 06:45:39 pm
content: PSoC1 devices had detailed description of analog routing and registers. And it definitely was possible to change those at run time. After learning the deep internals, it became possible to do fun stuff using switched capacitor filtering etc. for synchronous detection, filtering and so on. But boy, was there a steep learning curve.. I did a whole EEG system with 50/60 Hz band stop filtering, ADC and communications using a rather cheap PSoC and some low noise opamps (TLC2264) for preamp.

author: andyturk
author_rank: Frequent Contributor
timestamp: November 10, 2021, 07:37:30 pm
content: Wow, the opinion to experience ratio here is rather high.I spec'd a PSoC5LP for a medical device controller a few years ago. It's in production now, but the quantities are rather small. Cost of the silicon was never an issue as there are some very spendy RF parts in the build and whatever I put on the control board was cheap by comparison.The main requirements I considered at the time were needing 16-bit ADC inputs for the main control function, a variety of less precise analog inputs for monitoring various parts of the system, and a few DAC outputs. We also needed a USB controller. The control board is less than 3 square inches, so board space was a factor too. I'd played around with various PSoC mcus before, but this was my first commercial design with a PSoC.A lot of people bitch about the IDE, and I did too early on. But since I don't use it for much beyond I/O routing and configuring UDB-based logic, I don't spend a lot of time in it. The IDE has a "Generate Application" feature which emits all the framework code and a minimal main.c that initializes everything. I just compile all that stuff as-is (i.e., without changing the generated source) and call it from my code which lives apart from the PSoC Creator project. A small piece of Makefile magic moves the Cypress generated main() out of the way so my own C++ main() can be in charge:Code:# This magic is a target-specific makefile variable definition which# adds an additional preprocessor macro to rename the "main" function# to "cypress_main", but only when compiling main.c## This allows cxx_main.cc to contain its own definition of main() which# is only used for C++ builds.#$(OBJ)/main.o : CFLAGS += -Dmain=cypress_mainAll my code is C++14, sits on an RTOS and calls the generated API only when necessary. In that respect it's not too different than what you get from other mcu vendors. A slight wrinkle is that the names you use in the IDE for the various peripherals end up being part of the API that's generated, so there's an extra dependency that can be annoying at times. But in the end, it's not really a problem.One nice feature of the silicon is the wide power supply range. I was able to fix a hardware design issue by simply running the mcu at a slightly higher voltage (3.6V). That wouldn't have been possible for other mcu's that top out at 3.3V. My favorite thing is the fully routable GPIO (and analog). It's super handy to be able to tweak the "schematic" in the IDE to route a copy of some signal I'm debugging out to a debug pin. No soldering, no 30 gauge kynar wire, just recompile and probe that debug pin on my 'scope.At first I thought the UDB stuff would be a big win. It's not bad, but it turned out to be less useful than I thought. Mostly, I ended up using UDBs to control timers, analog muxes and DMA transactions, essentially creating the same kind of machinery that's built into other vendors' ADCs by default. I probably spent more project time learning how to get my custom PSoC5 ADC to DMA stuff working than I would have figuring out another vendor's one-size-fits-all ADC API.In the end, I think PSoC5 is an interesting and useful part. However, it's awfully expensive for what you get (even before COVID-19 shortages). If I had this project to do again, I'd probably use a STM32G4, since I like the LL APIs and ST's reference manuals usually do a good job at the register level.

author: westfw
author_rank: Super Contributor
timestamp: November 11, 2021, 12:11:12 am
content: QuoteYou saw Questions?? I saw lots of opinions, and some complaints, but I think the closest thing I saw to a question was "why is it so crazy expensive?", which is not the sort of question that a Product Engineer can answer. (maybe also "will we ever see tools for linux?")(I went to a PSoC training session once. One of the other attendees commented: "so you're expecting the people who do the HW design (and set up the progammable logic) and the people who do the SW design to actually share an IDE project? That's not the way my company works!" An "interesting observation" (though I gather that many of the people HERE are the sort who would do both themselves.)

author: wek
author_rank: Frequent Contributor
timestamp: November 11, 2021, 07:55:04 am
content: Quote from: westfw on November 11, 2021, 12:11:12 amOK so let me rephrase my rant: What is the exact routing of UDBs to pins, and how exactly are UDBs configured?JW

author: Bassman59
author_rank: Super Contributor
timestamp: November 11, 2021, 08:15:56 pm
content: Quote from: westfw on November 11, 2021, 12:11:12 amWhile I think most of us herehavehandled both the FPGA part and the microcontroller part of our designs, what I see from all of the vendors regarding embedding micros in an FPGA is that indeed the FPGA person does the hardware and a micro firmware person does the micro. The tools generate the drivers and the address maps and all of it and present it to a software IDE (Eclipse, for example) with which the micro firmware person is expected to be familiar.And to be fair, I think that's reasonable.Now if the PSoC tools don't have the two halves separate in some sense, and if indeed the micro firmware is done in the same environment as the hardware, well, yeah, that's ... kinda weird. I can't imagine how that might work for source code control.But my impression at looking at PSoC over the years is that it's primarily a microcontroller with the special sauce of some small amount of configurable hardware, more like a CPLD gaffer-taped onto the micro. It is not, nor is it I think intended to be, a competitor to a Zync or even any FPGA with an embedded micro (hard or soft core).