PSOC 6 Dual Arm Core embedded

[danadak]

Thought it might be of interest to forum, see brochure -

https://community.cypress.com/community/psoc-6/content?filterID=contentstatus%5Bpublished%5D~category%5Bpsoc-6-brochure%5D


http://www.eetimes.com/document.asp?doc_id=1331471





Regards, Dana.

[hendorog]

Any idea if this will support wifi - I think it was mentioned in one of the promo videos but not sure if I got that right.

Iot without wifi doesn't seem to be particularly useful to me, but I can see lots of uses for a psoc which does have it.

[aandrew]

I really want to like PSoC. I've done some fairly intense designs with them, but until they change a couple of absolutely critical areas I won't recommend them for any work I do.

• Windows-only environment. You can build the code anywhere (it's just regular old GCC after all) but the configuration must all be done in the GUI, the schematic entry (see below) must be done in the GUI, and the synthesizer (for building custom UDB code) is a windows-only app.
• generated code is rather poor. This isn't a Cypress-only thing. I find the STM32 CubeMX code to be crap, as also the NXP code. I am convinced they give this work to the interns and as long as it builds, it's considered good to release. Obvious areas of demarcation aren't present (leading you to modify the generated code, ugh) and examples are often obvious, leaving the tricky bits to be painfully learned through trial and error.
• Schematic entry for programmable logic is a non-starter. They do allow you to write Verilog, but you still need the GUI to wire things up. The GUI is pure shit too; pick up a wire and it helpfully "optimizes" it for you. Trying to move bits around leads to shorted nets and all your carefully-named nets get reset to autogenerated names. They need to drop this and allow us to design the entire application -- from front to back -- through the command line, likely with Verilog. It'd be nice to have VHDL as well, but let's get out of the idiocy of pointy clicky draw schematics to describe hardware first.
• stingy UDB offering: I *really* like the idea of the UDBs, even if they are 8-bit only (see next point). Unfortunately every time you start to get to doing something interesting with them, you run out of resources! It'd be nice to have at least 64, if not 256 UDBs to really allow the hardware to accelerate the MCU.
• anemic UDB datapath -- I didn't see anything specifically calling out a UDB change here, so I am left to assume the UDB datapath is still stuck at 8 bits wide. WHY?!
• poor fitter reports; timing problems? the reporting is only slightly more helpful than guessing at how to solve the issue. I'm used to Altera's extensive reporting to help me solve any timing closure errors. With PSoC it's very much guesswork.

Now that's the bad. Like I said I really do want to like these devices. They have some really nice points:

• bog-standard ARM Cortex -- no funny business! Regular tools, regular debuggers. No need for proprietary adapters or software. This is *HUGE*.
• Built-in USB 2.0 FS; It'd be nice to have an FX2LP/FX3 SIE in there to at least get 480Mbps with an external PHY, but for 90% of applications, FS does a handsome job, and their libraries aren't terrible. It's not like Cypress doesn't have the knowledge here either; their FX2LP and FX3 are pretty much *the* standard in high speed USB interfacing.
• UDBs. I love them. They are truly underappreciated. Each one of them has a little processor inside; it's a little like a mini GPU shader. These are very tricky to get the hang of, but can do some nice offloading combined with the ability to DMA directly in and out of a UDB.
• Decent analog. This is often overlooked. The 5LP has a pretty nice set of ADCs, programmable voltage and current DACs, PGAs, continuous-time/switched capacitor blocks and some flexible routing. I'm always finding areas where these can solve some interesting problems "in the box", saving me external componentry.
• any pin, (almost) any function -- this is another HUGE benefit. The "almost" bit is really only limited to USB and some of the higher current analog. The rest of the features are completely agnostic about which pin they go to. Anyone who's done any kind of peripheral-heavy MCU design knows the benefit of being able to route any signal anywhere.

I really am on the fence with these parts. The PSoC6 looks great, it truly does, but I've not seen any indication that they've addressed any of the cons listed above, which means the PSoC6 will be even more infuriating to design with, which is a real shame. I really think they have a winner with the PSoC line, but their tools are what prevents me from embracing it with both arms.

[hendorog]

Usually appliance type or  gateway type IoT devices may integrate WiFi WLAN because there is power permanently available for the power hungry protocol, the higher cost / complexity of WiFi devices may be acceptable for those products, and somewhere at least a bridge to LAN / WAN / WLAN must be made for many use cases.  But rarely will the battery powered / energy harvesting type IoT nodes support WiFi WLAN because of cost and energy requirements which are not suitable for sensor nodes powered by small batteries.  So those devices use other protocos like BLE,  Thread, 6LowPAN, COAP, MQTT and then centralized gateways bridge the local area low energy IoT net to a longer range / internet / WAN network using WiFi or Ethernet or LORA or GSM / LTE or  something.   

WiFi would mostly be useful for consumer residential or maybe some business / industrial applications as a gateway.
Not too many IoT networks use mostly WiFi since that can be complex to secure / administer and is expensive.
 

Any idea if this will support wifi - I think it was mentioned in one of the promo videos but not sure if I got that right.

Iot without wifi doesn't seem to be particularly useful to me, but I can see lots of uses for a psoc which does have it.

Yes I understand, and I certainly see the likes of LORA being of interest as well.

Mainly I was thinking of applications which have power available- e.g. smart switches, lights and energy monitoring in a house - and some energy harvesting ones where slow sampling/low comms duty cycle is acceptable. e.g. monitoring the moisture/humidity levels under the house.

For many applications, gateways will be a major PITA as every company/product will need a different one. So anything which is standardised (wifi) or connects directly to a WAN is more interesting in my book.

[janekm]

Usually appliance type or  gateway type IoT devices may integrate WiFi WLAN because there is power permanently available for the power hungry protocol, the higher cost / complexity of WiFi devices may be acceptable for those products, and somewhere at least a bridge to LAN / WAN / WLAN must be made for many use cases.  But rarely will the battery powered / energy harvesting type IoT nodes support WiFi WLAN because of cost and energy requirements which are not suitable for sensor nodes powered by small batteries.  So those devices use other protocos like BLE,  Thread, 6LowPAN, COAP, MQTT and then centralized gateways bridge the local area low energy IoT net to a longer range / internet / WAN network using WiFi or Ethernet or LORA or GSM / LTE or  something.   

WiFi would mostly be useful for consumer residential or maybe some business / industrial applications as a gateway.
Not too many IoT networks use mostly WiFi since that can be complex to secure / administer and is expensive.
 
(snip)

That's mostly true, but there are some battery-powered use cases where data doesn't need to be transmitted in "near-realtime" where WiFi is the easiest option because of existing infrastructure. Think building monitoring type of setups.
If you only power up the wifi interface once a day (hour) you can still get perfectly respectable battery life. The administration hurdle is real though.

[danadak]

@aandrew

Serious question, some background.

I started coding UPs in 1972, minis like PDP8, 11, Teradyne, Sentry,
various UP, and in all cases command line tools. Back in 70's I kept
thinking I have a computer in my hands, why in gods name would I
want to do anything but graphics, why all the tedious typing.....

Since then I have been avoiding command line where ever possible. the
combination of tedium and my short memory for commands and options,
keep me always command line avoidance.

For you, what are the redeeming values to command line vs drag and drop
and GUI interface ?

On another matter your comment about PSOC API code, I agree that some of
it is definitely non-optimal, then again some is. I always thought what drove it
is what we all face, time to market. I wrote test code for ICs for some years,
and some of it was tight, had to be so I was allotted the time, other was frankly
rushed. Test time = $$$$ was what drove the decision. If we were going to make
100,000 of some part, we did not care, if 10,000,000 we counted mS.


Regards, Dana.

[capt bullshot]

For you, what are the redeeming values to command line vs drag and drop
and GUI interface ?

Command line based dev tools usually is strongly related to "keep everything as human write and readable text source code".
Say VHDL / Verilog for the programmable logic, C (or whatever language) for the software code, some config / constraint files for e.g. pin mapping and timing and a makefile based receipe to build the project from scratch in one command to be typed by you, usually just "make".
The whole bunch of source code including the receipe would then be checked in to your favourite versioning tool.
To build the project, you ensure to have all required tools installed, check out the project, "cd project_directory", "make". Lay back and see the makefile doing all the work.
Once you're at this point, you'll really appreciate not having to start an IDE, open the project, find the "compile button", remember some important project settings and where are the dialog boxes to do all the clickety to correctly set the options ...
Especially if you are using different compilers / IDE for different processors. No need to remember all their special options, just type "make" and use your favourite code editor.
Most important for many environments is: using human read/writeable source and config files together with an appropriate versioning tool, you are able to trace all changes from each version to any other version of your projects in every aspect of the project.

[aandrew]

I started coding UPs in 1972, minis like PDP8, 11, Teradyne, Sentry,
various UP, and in all cases command line tools. Back in 70's I kept
thinking I have a computer in my hands, why in gods name would I
want to do anything but graphics, why all the tedious typing.....

Interesting. I don't think I know any embedded software developer who prefers to use an IDE; not MPLAB, not Eclipse. Large software (think huge Java or C++ apps) yes... hundreds of classes spread over dozens of files, managing dependencies, etc., but for even large embedded jobs... not so much. Many people prefer a helpful editor, but a full blown IDE with all its "helpful" autocompletion and code generation and its own internal databases for generating an equivalent to a Makefile... it's just another layer of abstraction that when (not if, when) it breaks, costs the developer multiple hours of frustration to try to figure out.

Since then I have been avoiding command line where ever possible. the
combination of tedium and my short memory for commands and options,
keep me always command line avoidance.

I don't see the command line as extraneous typing. That's what Makefiles are for. (command line options? those are all specified once in the Makefile; I just type "make flash".) I prefer to have a solid understanding of what happens when I ask the computer to build the software. A nice editor (sublime text for me, as well as vim) is all I want in that regard. I don't want the polished "build" button that obscures what's going on behind the scenes. I need to be able to get in and fix it when (again when, not if) it breaks. There's a LOT less time spent fixing a broken Makefile than a broken Eclipse build, let me assure you.

Specifically with PSoC Creator though... I gave a fairly detailed list of grievances above. The IDE is *not* good. It's buggy, particularly the schematic editor. I *will* admit that basing PSoC Creator on VS rather than Eclipse is a slight bonus in my book, but the fact that it's a single-OS solution is still a huge issue for me. Yes, I can run it in a VM; that's not the point. I run Altium in a VM only because I'm not quite ready to make the plunge to KiCAD, and Eagle has all but abandoned their product since 6.x and now with Autodesk trying to permanently park their hand in my pocket... forget it. PSoC creator isn't good enough for me to willingly accept its failings and recommend their parts.

BTW: are you the Dana from the PSoC forums who's helped so many people (myself included) over the years?

For you, what are the redeeming values to command line vs drag and drop
and GUI interface ?

• Consistency. GUIs like to change things on you for no good reason. Command line doesn't seem to suffer the same fate, although there's no real reason why it couldn't do the same.
• Automation. It's a *royal* pain in the ass to try to integrate a GUI into any kind of automated build/test framework. You can run mouse macros, but see the previous point for why it doesn't work well.
• Accessibility. I can ssh in from the living room or from around the world, even over poor quality connections, and have very little impact on my ability to work.
• Multi-Platform. It's a LOT easier to have a cross-platform set of tools that are command line based
• Resource Use. Similar to accessibility, I can run it much more easily in a VM or build server. RDP/VNC work, but aren't nearly as nice as a screen/tmux session over ssh. Also, I can work just as easily from command line on a little laptop screen as I can from my dual monitor workstation.
• File Formats. Plain text files are *easily* manipulated. I can back them up, diff them, script bulk search or edits... Most GUIs take the lazy way and serialize the GUI objects and write an incomprehensible blob to disk and call that the project. There's no reason GUIs can't write text files, but they generally don't, PSoC Creator included.
• Documentation. Most GUI help systems have devolved into idiotic videos or screenshots, making it much more difficult to quickly search or manually scan for the keywords that are interested in. This is a growing problem with all vendors, IMO.
• Understanding. I alluded to this several times, but hiding everything behind GUI dialogs and opaque binary formats prevents the developer from understanding the system. When something breaks, it's much harder to fix. You simply have no visibility into how the pieces fit together and work with each other. How many times have you had a non-trivial project that fits perfectly into the GUI's workflow?
• Flexibility. I also hinted at this in the other points, but PSoC Creator's use of schematic-entry-only connection of the UDBs/analog blocks is a *terrible* disservice to what PSoCs can do. You're hamstrung with a GUI that second guesses you because it's pandering to beginners.

I worked on a microscopy project which used multiple PSoC4 and PSoC5LPs across a half dozen cards and the motherboard. The schematic entry was the worst part of it. Multiple pages, and a *poor* quality GUI made this an awful, awful process. It would have been so much easier to connect things up in a VHDL or Verilog block, throw the equivalent of a constraints file and a timing file at it and let it go. The FPGA guys figured this out more than a decade ago. I can appreciate Cypress wanting to have a schematic entry for the simple stuff, but the lack of a plain text netlist/project file smacks of laziness or hubris (nobody will need to use anything but the schematic entry box) on the part of the design team.

On another matter your comment about PSOC API code, I agree that some of
it is definitely non-optimal, then again some is. I always thought what drove it
is what we all face, time to market. I wrote test code for ICs for some years,
and some of it was tight, had to be so I was allotted the time, other was frankly
rushed. Test time = $$$$ was what drove the decision. If we were going to make
100,000 of some part, we did not care, if 10,000,000 we counted mS.

While I hear what you are saying, I absolutely do not agree. Cypress wants to sell millions of these devices. I can understand a beta-quality release, but it's been years since the equivalent of a HAL has been written, and very, very little has been done to improve the quality of it. This auto-generated and library code is what their potential customers are working with, and lack of testing or documentation being out of sync is not acceptable. They spent millions doing their due diligence for the hardware design and tapeout before committing the design to fab... there is no reason why they should not put similar care into the design of the code they are expecting their customers to use with their devices. The same goes for the Cypress developer forums... They did a significant refresh a few years ago but it's still a horrible, horrible experience. Look at what Nordic did with their devzone. THAT is an easy to use, easy to read, easily navigable primary technical support forum!

Cypress has great products. I love their FX2LP/FX3 devices. I love the idea behind the PSoC series. Cypress seems very stubbornly stuck in "real devs only use Windows and GUIs" mode (even with the FX2/FX3) and IMO it's hurting their bottom line.

[jnz]

I'd be interested if they were including CAN Bus in the serial comms, but I don't think they are looking over the initial data.

[aandrew]

The PSoC5LP had CAN, I made extensive use of it in the past.

[splin]

Anybody know when these will be available to buy and what the pricing might be? The Q1 2017 roadmap document says an NDA is required for PSOC 6 information.

Are low cost/free development tools and programming/debugging interfaces available?

[Carl47D]

Anybody know when these will be available to buy and what the pricing might be? The Q1 2017 roadmap document says an NDA is required for PSOC 6 information.

Are low cost/free development tools and programming/debugging interfaces available?

Hi,
According to this question on the PSoC6 EAP Community (login required) the documentation will be available in ~2 weeks, dev kits will be out around late August, and yes they are planning in do a prototyping kit with the PSoC6, don't know what sub-family they will use.

[danadak]

@aandrew, yes, same danadak over at PSOC Forum and PSOC Developer.com Sent a lot of guys and
gals off the cliff over there

Found your comments on IDE interesting, I claim not to be an IDE expert, that's why the comments
you raised caught my eye.

BTW, I thought the APIs were manually written, not some auto generated stuff, other than the GUI input
gnerated changes tot he basic API. I take it thats what HAL is ?  Shows you how IDE clueless I apparently
am. I looked at more than one API when having speed issues, found some terrible stuff, and also
some canonical stuff, or at least I could not do better in ASM (that's not saying much )

When learniung C I diod some testing several years back to see what got generated. Very dependent
on vendor/compiler I found. In one case using PSOC 1 running out of 32K even the typing differences
allowed me to regain almost 4K. Which to you point maybe had I looked deeper and understood make
better might have found more. I promptly used up the 4K......

Many people prefer a helpful editor, but a full blown IDE with all its "helpful" autocompletion and code generation and its own internal databases for generating an equivalent to a Makefile... it's just another layer of abstraction that when (not if, when) it breaks, costs the developer multiple hours of frustration to try to figure out.

You are right, the GUI makefile settings can be cryptic if not well documented. And there is usually bloat
in startup auto generated files. But increasingly I find getting the design done vs in deep understanding
of all those processes is, shamelessly, a welcome outcome. Especially in light of large amounts of FLASH
and speed good enough. If I was doing medical life support or space work or stuff that affected human
safety I would pay more attention. But I have a sizable case of ADD so that would not be a good idea....
life support that is.

My command line comments largely out of IC test work on PDP8 and Teradyne systems. Really got fed up
doing manual makes all the time, paper tape, ugh, and scripting was not effective/complete as an option.
Plus lack of decent editors, more keyboard effort.

For sure abstraction is a tradeoff, one that needs or should require a better understanding of impact.
Maybe I am too trusting...But then so is C, our confidence in it 40 years of use maybe removes most
doubt. But then the individual compiler issues that arise, chiseling away at confidence.

Probably best learning experience I could have is do a simple one off, make, and look at EVERYTHING
produced.  Might be a good learning experience.

Sounds like I should re-examine my outlook, but then in a rush to implement ideas I have rattling around
in my head will I find the time or will the siren call of implementation win out as it has done so far as you
can see. Or maybe make is now so simple I have completely missed the boat.

Thanks for taking the time to respond. I am still learning.


Regards, Dana.

[firehopper]

saw a post on the price of the 6 eval board $75 supposedly

[timb]

The WiFi is interesting to me, as I'm actually working on designing a WiFi PSoC module right now (I'm combing a PSoC 5LP and CC3100 on a tiny little board, as I've had need for a PSoC with WiFi in some recent projects, so I figured I'd create my own module).

[poorchava]

I really worry about the pricing. I really do like PSoCs, but the larger ones are too expensive for what they have to offer IMO. Actually the one found on PSoC5 devkits is like 16€ + VAT a piece from usual sources. This generally buys you an upper-range 200MHz+ STM32F7 chip with shitload of different advanced peripherals or a Spartan6 FPGA, not a general purpose microcontroller.

[Carl47D]

There are some application notes drafts popping out (login required):

* PSoC6 Dual Core
* PSoC 6 BLE Hardware Design Considerations Power

[Neganur]

I really worry about the pricing. I really do like PSoCs, but the larger ones are too expensive for what they have to offer IMO. Actually the one found on PSoC5 devkits is like 16€ + VAT a piece from usual sources. This generally buys you an upper-range 200MHz+ STM32F7 chip with shitload of different advanced peripherals or a Spartan6 FPGA, not a general purpose microcontroller.

Well the thing is that those PSoC have UDB's and analog parts integrated which can make them quite attractive compared to 'general purpose microcontroller' if it fits you application. The price is ofc a good point as they cost a lot even in volume.

I've been disappointed by the performance of the opamps in there though and you get very little info on it (no proper data, no spice model etc.).