http://opalkelly.com/

Author Topic: PSOC 6 Dual Arm Core embedded  (Read 1439 times)

0 Members and 1 Guest are viewing this topic.

Offline danadak

  • Super Contributor
  • ***
  • Posts: 1254
  • Country: us
  • Reactor Operator SSN-583, Retired EE
« Last Edit: March 20, 2017, 12:29:48 PM by danadak »
 
The following users thanked this post: evb149, newbrain

Offline evb149

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: PSOC 6 Dual Arm Core embedded
« Reply #1 on: March 20, 2017, 01:04:04 PM »
Thanks, very interesting.  I would be very interested to work with the PSOC 62 / PSOC 63 / PSOC 65 kits / modules / chips when the chance occurs, and the BCM WICED devices also..
 

Online hendorog

  • Frequent Contributor
  • **
  • Posts: 705
  • Country: nz
Re: PSOC 6 Dual Arm Core embedded
« Reply #2 on: March 20, 2017, 01:07:05 PM »
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.
 

Offline evb149

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: PSOC 6 Dual Arm Core embedded
« Reply #3 on: March 20, 2017, 01:23:28 PM »
Looks to me like the PSOC 63 is integrating Bluetooth low energy and can be attached optionally to an external WICED WiFi IC to support WiFi.  Several of the WICED BCMxxx devices cover WiFi and some also Bluetooth.
It will be interesting to see how the BCM line they acquired from Broadcom evolves along with the PSOC BLE line they made before that time.

 
 

Offline evb149

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: PSOC 6 Dual Arm Core embedded
« Reply #4 on: March 20, 2017, 01:36:06 PM »
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.
 

Offline aandrew

  • Regular Contributor
  • *
  • Posts: 111
  • Country: ca
Re: PSOC 6 Dual Arm Core embedded
« Reply #5 on: March 20, 2017, 01:43:52 PM »
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.
 
The following users thanked this post: chickenHeadKnob, evb149, helius

Online hendorog

  • Frequent Contributor
  • **
  • Posts: 705
  • Country: nz
Re: PSOC 6 Dual Arm Core embedded
« Reply #6 on: March 20, 2017, 03:00:42 PM »
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.
 

Offline janekm

  • Supporter
  • ****
  • Posts: 356
  • Country: gb
Re: PSOC 6 Dual Arm Core embedded
« Reply #7 on: March 20, 2017, 03:11:36 PM »
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.
 

Offline danadak

  • Super Contributor
  • ***
  • Posts: 1254
  • Country: us
  • Reactor Operator SSN-583, Retired EE
Re: PSOC 6 Dual Arm Core embedded
« Reply #8 on: March 21, 2017, 01:08:31 AM »
@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.
 

Offline capt bullshot

  • Regular Contributor
  • *
  • Posts: 221
  • Country: de
Re: PSOC 6 Dual Arm Core embedded
« Reply #9 on: March 21, 2017, 01:45:42 AM »
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.
Safety devices hinder evolution
 

Offline aandrew

  • Regular Contributor
  • *
  • Posts: 111
  • Country: ca
Re: PSOC 6 Dual Arm Core embedded
« Reply #10 on: March 21, 2017, 03:21:02 AM »
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.

Quote
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?

Quote
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.

Quote
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.
 
The following users thanked this post: helius, capt bullshot

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 331
Re: PSOC 6 Dual Arm Core embedded
« Reply #11 on: March 21, 2017, 03:43:50 AM »
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.
 

Offline aandrew

  • Regular Contributor
  • *
  • Posts: 111
  • Country: ca
Re: PSOC 6 Dual Arm Core embedded
« Reply #12 on: March 21, 2017, 04:12:12 AM »
The PSoC5LP had CAN, I made extensive use of it in the past.
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 383
  • Country: gb
Re: PSOC 6 Dual Arm Core embedded
« Reply #13 on: March 21, 2017, 04:19:16 AM »
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?
 

Offline evb149

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: PSOC 6 Dual Arm Core embedded
« Reply #14 on: March 21, 2017, 04:33:58 AM »
No idea when it'll be out.  In my experience Cypress PSOC BLE stuff usually is pretty good coming out fairly quickly (same year, maybe even 6 months or so) after announcement and data sheets being published publically.  And that is to general distribution.  I imagine that companies that they are actually directly working with already have samples or will have them a few months before everyone else.
You can see when the data sheets are put online and also when the bluetooth certifications are listed, that means they're close and should be available in a quarter or two.  Then again they did have problems with the PSOC 5    so I guess some unforseen delay is possible.  If the BLE versions are to be productized like the PSOC 4 BLE ones were then at some point they will likely also have modules that carry FCC / CE / DOC / BLE qualifications and precertifications with PSOC 6 ICs inside and some kind of PCB integrated antenna.  In the past the raw IC silicon was available a few months before the  modules  were available in general distribution.  Maybe there will be similar progress this time also?

Low cost kits?  Yes, probably.  They put out a $10 PSOC 5LP kit, $3 PSOC 4 kit, $10 and $15 BLE shield boards, and a $49 PSOC/PROC 4 BLE devkit including a kitprog programmer two different BLE  shield boards, a base board to interface the PC and programmer to the shields over USB.  And they have several other PSOC 4M and so on kits in the $25-$49 range.
So unless strange changes happen I think the PSOC 6 kits will be in the same general range though I have no specific confirmation of that.
The kitprog programmer is pretty much everything you need for PSOC 5LP / PSOC 4 programming and debugging,, maybe even PSOC 3 also.  They have a dedicated MiniProg 3 or whatever    version programmer that was like $79 but mostly the low cost kits use integrated kitprog that can be in some kits detached and used as a general programmer or on others can be wired to other targets anyway.


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?
 

Offline Carl47D

  • Contributor
  • Posts: 9
Re: PSOC 6 Dual Arm Core embedded
« Reply #15 on: March 21, 2017, 06:19:22 AM »
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.
 

Offline danadak

  • Super Contributor
  • ***
  • Posts: 1254
  • Country: us
  • Reactor Operator SSN-583, Retired EE
Re: PSOC 6 Dual Arm Core embedded
« Reply #16 on: March 21, 2017, 08:50:40 AM »
@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......

Quote
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.
« Last Edit: March 21, 2017, 12:53:26 PM by danadak »
 

Offline firehopper

  • Frequent Contributor
  • **
  • Posts: 272
  • Country: us
Re: PSOC 6 Dual Arm Core embedded
« Reply #17 on: March 21, 2017, 10:37:26 AM »
saw a post on the price of the 6 eval board $75 supposedly

Offline timb

  • Super Contributor
  • ***
  • Posts: 2307
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: PSOC 6 Dual Arm Core embedded
« Reply #18 on: March 21, 2017, 10:55:18 AM »
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).
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1481
  • Country: pl
  • Troll Cave Electronics!
Re: PSOC 6 Dual Arm Core embedded
« Reply #19 on: March 23, 2017, 07:18:19 AM »
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.
I love the smell of FR4 in the morning!
 

Offline Carl47D

  • Contributor
  • Posts: 9
Re: PSOC 6 Dual Arm Core embedded
« Reply #20 on: March 25, 2017, 06:18:59 PM »
There are some application notes drafts popping out (login required):

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

Offline Neganur

  • Supporter
  • ****
  • Posts: 865
  • Country: fi
Re: PSOC 6 Dual Arm Core embedded
« Reply #21 on: March 25, 2017, 09:03:56 PM »
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.).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf