Anyone built something practical with Cyberkit-043 or CY8C4247AZI-M485 ?

[martys]

At $10USD and free debugger/IDE, seems at first a good deal, but the chip in quan. <25 has a  high cost ($8.27) and can't be breadboarded easily upon a solderless breadboard, so development is clumsy without using the very large Cyberkit-043

It takes  lots of wires messily connecting to a test solderless breadboard.

Is there a better MCU choice that offers as good MIPS (>16MIPs)
>16K or better SRAM
Easier to configure peripherals like A2D, timers,counters, PWM, etc.
A free, unlimited use of available  flash RAM
Having no code limitations of compiler/output code size
Offering a free Windows development IDE that isn't full of gotcha's and bugs?
Having the convenience of a DIP MCU package to be able to pop into a large prototyping breadboard?

Is there a better/easier/more practical way?



In short, has anyone succeeded in overcoming the obstacles of using the Cypress IDE to make something really practical and useful? 

I am trying to develop my own code for accomplish speech recognition and make custom products to aid the handicapped.

[ShowKemp]

At $10USD and free debugger/IDE, seems at first a good deal, but the chip in quan. <25 has a  high cost ($8.27) and can't be breadboarded easily upon a solderless breadboard, so development is clumsy without using the very large Cyberkit-043

Why did you choose to buy it at first place? Any special peripheral you wanted to use?

Offering a free Windows development IDE that isn't full of gotcha's and bugs?

Is there a better/easier/more practical way?

In short, has anyone succeeded in overcoming the obstacles of using the Cypress IDE to make something really practical and useful? 

What bugs and gotchas did you found?

Having the convenience of a DIP MCU package to be able to pop into a large prototyping breadboard?

Most of the small PICs and AVR are available in DIP packages, i think there's a LPC micro available in DIP package.

The cheapest microcontrollers i know of are the STM32 devices, but afaik there's none in a DIP package, but there's a lot of cheap development boards on ebay with a form factor to plug in a breadboard.
You can configure the peripherals with the STMCubeMX and there's a free IDE based in Eclipse to develop, OpenSTM32 or AC6.

[dferyance]

Very odd that you are concerned over the price for a large quantity of a development kit. It isn't intended to be used in your products; only the chip is and that always is tons cheaper.

The Cypress IDE has been much simpler and easier to use and get going with compared to many other free IDE's I've tried. Everything has bugs, but anything reasonably complex and capable takes some time to learn too.

[martys]

Dferyance:  Tons cheaper? The chip is USD 8.43 quan<25 (Mouser) and  Dev board is USD 10 +ship + tax

I would like to make 8KSPS voice input sampling/chan, so A2D with 2 or more (maybe up to eight) channels.

ShowKemp: Need to do fast math for FFT etc. on two or more inputs and do SW to do fast input level normalizing of different bandpass filter outputs, all done best at the same time(crunching voice band inputs to MCU from external filters/analog circuitry).

Need to store voice sampled vals for later crunching, 8-Bit by 16KB min raw sampled data and need to store the crunching results to complete the voice recog process, such as sampled interval probability val of match, etc.

Want to keep power consumption low as possible, of course. (I know this kind of processing has a power cost)

[Brutte]

Having the convenience of a DIP MCU package to be able to pop into a large prototyping breadboard?

Buy an evaluation board with 0.1" pins that matches a breadboard.

As for Psocreator - several years ago I did try to download their free IDE but unfortunately they required registration.

[martys]

ShowKemp: Maybe drifting for a moment off topic, but:
What are the shortcomings of the toolchain you mention?
Does the STM toolchain and IDE you've mentioned support on-the-fly C-code syntax error detect in the IDE, cheap debugging tools, code optimization?
What about programming these STM32's? Is this simple and cheap?

I found that Cypress docs are scattered in terms of content, date, each too specific or too general(for families of a chip type), and for each, updates abound, but always difficult to get all the design info needed for a project, so difficult to complete a design when there is so many data sheets, one or more for each peripheral, not finding most everything in one or two documents or appnotes was a big bad suprise and quite able to be confusing and hard to manage. Try to compile something and something is reported out of date, must download update, update can be incompatible, etc.

Cypress example projects show a design philosophy that seems so proud to be able to do something without using any C-code!

Example videos by Cypress last usually are <3mins, but engineers know the devil is always in combining the small details.

I have serious problems sometimes understanding C-compiler detected errors of my code using the Cypress IDE and have trouble working with their low instance limits of modules needed to used as peripherals.

That being said, has anyone found the Cypress MCU/dev. environment  mentioned to be capable/desirable to make a viable product, to do something really practical?

It is no big deal to dim  the light of a LED or to be able detect your hand near a dangling wire on a pin with their chip(the sample first apps), but what about serious applications?

[ShowKemp]

ShowKemp: Maybe drifting for a moment off topic, but:
What are the shortcomings of the toolchain you mention?
Does the STM toolchain and IDE you've mentioned support on-the-fly C-code syntax error detect in the IDE, cheap debugging tools, code optimization?
What about programming these STM32's? Is this simple and cheap?

Yes the IDE syntax error detection, the debugging tools (STLink) are the cheapest debugging tool i know of (check ebay).
You can program the STM32 working directly with the registers, or use the code generated with the STMCubeMX tool, or use libopencm3 for example.

I found that Cypress docs are scattered in terms of content, date, each too specific or too general(for families of a chip type), and for each, updates abound, but always difficult to get all the design info needed for a project, so difficult to complete a design when there is so many data sheets, one or more for each peripheral, not finding most everything in one or two documents or appnotes was a big bad suprise and quite able to be confusing and hard to manage. Try to compile something and something is reported out of date, must download update, update can be incompatible, etc.

Yes, every peripheral have a datasheet, that's one of the things i like from the Psoc IDE, reading a 20ish page long pdf instead of a 1000 page TRM is easier for me.

Cypress example projects show a design philosophy that seems so proud to be able to do something without using any C-code!

I think that's the selling point of the psoc devices, doing most of the project using the programmable logic instead of C. that's why they are more expensive, the programmable logic.

Example videos by Cypress last usually are <3mins, but engineers know the devil is always in combining the small details.
I have serious problems sometimes understanding C-compiler detected errors of my code using the Cypress IDE and have trouble working with their low instance limits of modules needed to used as peripherals.
That being said, has anyone found the Cypress MCU/dev. environment  mentioned to be capable/desirable to make a viable product, to do something really practical?
It is no big deal to dim  light for a LED or to be able detect you hand near a dangling wire on a pin with their chip(the sample first apps), but what about serious applications?

I'm a hobbyist, can't help you with "serious" applications, the learning curve is steep but once you understand the work flow psoc is very easy to use.


i had some problems understanding some of your questions (i'm not a english native speaker). may be someone else can help you with:

I have serious problems sometimes understanding C-compiler detected errors of my code using the Cypress IDE and have trouble working with their low instance limits of modules needed to used as peripherals.

[andyturk]

Dferyance:  Tons cheaper? The chip is USD 8.43 quan<25 (Mouser) and  Dev board is USD 10 +ship + tax

I would like to make 8KSPS voice input sampling/chan, so A2D with 2 or more (maybe up to eight) channels.

ShowKemp: Need to do fast math for FFT etc. on two or more inputs and do SW to do fast input level normalizing of different bandpass filter outputs, all done best at the same time(crunching voice band inputs to MCU from external filters/analog circuitry).

Need to store voice sampled vals for later crunching, 8-Bit by 16KB min raw sampled data and need to store the crunching results to complete the voice recog process, such as sampled interval probability val of match, etc.

Want to keep power consumption low as possible, of course. (I know this kind of processing has a power cost)

The Cypress IDE is fine. It’s GCC under the hood anyway.

However, CY8C4247 is a wireless/rf chip, and you didn’t mention BLE or anything like that in your goals. It’s also a Cortex M0, which is not what you want for FFTs.

Based on what you said you’re building, you’ll likely want something with lots of SRAM for buffer space and a good DSP library. In the ARM family, a Cortex M4F would work well. Check out some of the STM32 discovery boards that have a more capable processor and a couple of microphones. That way, you can focus on the firmware first and not get stuck messing with an analog front end.

Check out Segger’s Embedded Studio for a good IDE. I think it may be “free” for educational/non-profit projects.

[Bruce Abbott]

In short, has anyone succeeded in overcoming the obstacles of using the Cypress IDE to make something really practical and useful? 

Sadly, no. It kept wanting to upgrade and I got sick of waiting over an hour for it do so, so I stopped at V3.2. Then every time I tried to work on a project the IDE would lock up after a few minutes, so I gave up and wiped it off my hard drive.
 
Sorry Cypress, but I have better things to do with my life than waste time wrestling with your crappy bloatware!

[martys]

BruceAbbott: You've experienced the same problems I've encountered with the Cypress IDE.

andyturk, Thanks, I'll take a look at the Segger's IDE.

ShowKemp: Thanks for the tip, I'll take a look at the STM toolchain ideas.

blueskull:  I see you've been buying the PSOC5LP-059 kits by the tens: Can you mention a useful project  instance or two? Perhaps I bought the wrong chip to do something useful with.

What do you mean by " just wack those gun stick boards to actual projects"? How do you solve QFN soldering problems this way?

In short, have you then succeeded in overcoming the obstacles of using the Cypress IDE/MCU's to make something really practical and useful? 

[martys]

evb149: I really thank you for taking the time to offer so many ideas. I have spent a bit of time to flesh out what the SW needs to do for voice recognition by researching different SW approaches to solve this problem. I am also using a Win PC to capture voice samples and analyze them using a sound editor like Cool-Edit Pro.

I don't know if I could afford the time to try to achieve my goal with a race horse chosen to pull the cart and then after have to figure out how to morph down the race horse into a mini-mule and hope to get similar results.

 A big horse like a raspberry pi wouldn't fit into the product I have in mind by an order of magnitude. I need pony or mini-poodle or better  yet,  maybe a jumping spider sized MCU HW.

Cost of the product to make and its size are big factors here. Most importantly, I think accomplishing any specific goal by using a  minimalistic approach adequate to achieve a desired result is the best approach.

blueskull: Thanks! There is a big difference between gum and gun.

But to go back to my original question here:

In short, anyone  care to mention an instance where they've succeeded in overcoming the obstacles of using the Cypress IDE/MCU's to make something really practical and useful? 

[danadak]

The price at the Cypress store is $ 3.60 for 1.     

http://www.cypress.com/search/parts/CY8C4247AZI-M485



The price for the high end 5LP board is $ 10.     

http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and


In 2011 Cypress had shipped to date > 1,000,000,000 PSOC parts

http://www.cypress.com/news/cypress-approaches-1-billionth-psoc-programmable-system-chip-unit-shipment



Regards, Dana.

[Bruce Abbott]

Care to name a few besides no Linux support?

Akamai Download manager


PSoC Creator 4.0 Released!

October 13, 2016

By Mark Saunders

Regular Start Page readers will have noticed that we are discontinuing support for Windows XP and Windows Vista next year. PSoC Creator 4.0 (and all updates we make to it) will continue to support those platforms but the next major software release will not. Note that PSoC Programmer shall continue to support those OS.

Reminder - Discontinuing Support for Windows XP and Vista

December 08, 2016

By Mark Saunders

I posted this a while ago but wanted to remind you that, in 2017, we shall be discontinuing support for Windows XP and Windows Vista in PSoC Creator. Microsoft has discontinued support for these Windows platforms and is not maintaining compatibility with them in the .NET framework. PSoC Creator support shall be maintained fully for all public releases in 2016 and early 2017 but the first major feature-based release shall discontinue support entirely.

Will PSOC Creator 4.1 run on Windows XP 32bit?

The application itself seems to be running fine. However when I plug in the kit, Windows is not finding the driver for "Cypress KitProg2". I can't find the driver in any of the downloads. Any advise, please? I have CY8CKIT-041-40XX.

Correct Answer
by user_1377889 on Oct 24, 2017 10:44 AM

One of the following Windows platforms is required:

Windows 7 and Windows 7 SP1 (32- and 64-bit supported)
Windows 8 and Windows 8.1 (32- and 64-bit supported)
Windows 10 (32- and 64-bit supported)

[hendorog]

Care to name a few besides no Linux support?

Akamai Download manager


PSoC Creator 4.0 Released!

October 13, 2016

By Mark Saunders

Regular Start Page readers will have noticed that we are discontinuing support for Windows XP and Windows Vista next year. PSoC Creator 4.0 (and all updates we make to it) will continue to support those platforms but the next major software release will not. Note that PSoC Programmer shall continue to support those OS.

Reminder - Discontinuing Support for Windows XP and Vista

December 08, 2016

By Mark Saunders

I posted this a while ago but wanted to remind you that, in 2017, we shall be discontinuing support for Windows XP and Windows Vista in PSoC Creator. Microsoft has discontinued support for these Windows platforms and is not maintaining compatibility with them in the .NET framework. PSoC Creator support shall be maintained fully for all public releases in 2016 and early 2017 but the first major feature-based release shall discontinue support entirely.

Will PSOC Creator 4.1 run on Windows XP 32bit?

The application itself seems to be running fine. However when I plug in the kit, Windows is not finding the driver for "Cypress KitProg2". I can't find the driver in any of the downloads. Any advise, please? I have CY8CKIT-041-40XX.

Correct Answer
by user_1377889 on Oct 24, 2017 10:44 AM

One of the following Windows platforms is required:

Windows 7 and Windows 7 SP1 (32- and 64-bit supported)
Windows 8 and Windows 8.1 (32- and 64-bit supported)
Windows 10 (32- and 64-bit supported)

No surprises there, it is very normal for new software to only be supported on a limited and current range of OS's.
XP was good, but it came out in 2001. You can't seriously be critical for them to call time on that. Vista, well, it had a nice name. It was the off sequence release that nobody used.

IIRC Eclipse can be used for PSoC development, and the programmer for programming. I think some tasks still need to be done on the Windows software though which is a bummer.

[Bruce Abbott]

I wouldn't be surprised if Win10 will be the only supported platform by many other apps.

Windows 10 sucks and I refuse to use it. Sales of Windows PCs are going down and vendors who lock themselves into Microsoft products can expect a shrinking market.

BTW Windows 10 goes into extended support in 2020, which is less than 2 years away.  I hate to think how crappy the next version will be...

[ShowKemp]

From a post on the Cypress forum:

Hi Bill,

As user_65461 mentioned, you will need VM software to run Creator on a MAC. We don't have support and don't plan to support Creator for MAC OS. However, with our future tools, we are planning to support MAC OS and other OS's. Be on the look out for new tools from us in the 2018 year.

Thanks and let me know if you have other questions!
Regards,
Michi Yoneda (Cypress engineer)

What However, with our future tools, we are planning to support MAC OS and other OS's. Be on the look out for new tools from us in the 2018 year. means?

What do you think those tools can be?
With those future tools available, will you give PSoC microcontrollers another try?

I´m guessing you will only need the arm-none-eabi toolchain installed on your development machine, and kitprog have support on openocd already, even a Cypress engineer is adding support to PSoC6 devices on openocd so i guess they will use openocd as the programmer (or you can use a jlink which have support for psoc devices).

[hli]

Back to the original question - can make something useful? Sure you can. Based on a video from w2aew showing a using a '555 and two OpAmps I went and did the same with a PSoC4 (a CY8C4245). And yes, you can solve something like this without needing software, just the pure PSoC hardware is enough. Apart from the needed passives and a diode, of course. I wanted to also do the follow-up showing a transistor curve tracer, but never had the time for it
If this is to small for your likes: my first PSoC project was a 2-channel 1Msps scope+8 channel logic analyzer (up to 32k samples depending on what you sampled), with LCD GUI and SUMP desktop connectivity, and quite some triggering capabilities. Apart from the LCD this did not need any external components, just a single PSoC5 chip. Unfortunately I never came around writing everything down in detail, but I have a video of it somewhere.

Compared with other MCUs the PSoC is still my go-to prototyping platform. You are so much faster in setting up something that starting a VM with W7 (or W10) is worth it. The component setup is simple (no need to learn strange CMSIS APIs just to set up I2C or something like that), ans the APIs that you need to use are mostly simple and straightforward. Documentation is always a mouse click away, no need to search in 1000 page documents (like for Atmel or TI) which only scatter the needed information in many places anyway.

As for the criticism above:
- component updates: Cypress can and will fix errors in their components, just in software, without new silicon. If you want to live with the errors, fine, they will not force you to update. You can also choose to live with 20 page erratas from other MCUs.
- XP support / 32bit: well, you can stay with GCC and vi. Anything else will stop supporting this platform probably sooner than later for their current products. And they are right - using a platform where you will never ever get any security bugfixes and which is connected to the internet should be a criminal offense now.
- Akamai: you are not forced to use it. The last time I did was like 5 years ago or so (because I clicked in the wrong place).
- download size: compare it with CCS, MPLABX, Attolic and the likes, and they are not that much smaller. Creator switched (with 4.1 IIRC) to a more incremental model where you get component updates, board support packages and examples only when you need them.

[Bruce Abbott]

using a platform where you will never ever get any security bugfixes and which is connected to the internet should be a criminal offense now.

Since Microsoft refuses to supply patches for older versions of their OS, who are the real criminals - the users, or the manufacturer who refuses to fix their unsafe product?  If they were a car manufacturer the answer would be obvious...

And despite the latest OS's being purportedly 'more secure', new vulnerabilities are constantly appearing. For example:- 
Meltdown

The Meltdown and Spectre vulnerabilities are considered "catastrophic" by security analysts.[9][10][11] The vulnerabilities are so severe that researchers initially thought that they could not be true... The exploit is viable on any operating system in which privileged data is mapped into virtual memory of unprivileged processes, which includes most major operating systems for the affected CPU architectures.

Frankly, it's scary - to think that this major security flaw has been lurking for years in all Intel CPUs from Pentium Pro up, but only now discovered - or has it? I have no confidence in the ability of Intel and Microsoft to keep their latest products secure.

Creator switched (with 4.1 IIRC) to a more incremental model where you get component updates, board support packages and examples only when you need them.

That's good to know. Unfortunately Cypress already cooked their goose with me...

[danadak]

Was that an open source project or a proprietary one.

If former I would love to take a look at project., code etc..


Regards, Dana.

[hendorog]

using a platform where you will never ever get any security bugfixes and which is connected to the internet should be a criminal offense now.

Since Microsoft refuses to supply patches for older versions of their OS, who are the real criminals - the users, or the manufacturer who refuses to fix their unsafe product?  If they were a car manufacturer the answer would be obvious...

And despite the latest OS's being purportedly 'more secure', new vulnerabilities are constantly appearing. For example:- 
Meltdown

The Meltdown and Spectre vulnerabilities are considered "catastrophic" by security analysts.[9][10][11] The vulnerabilities are so severe that researchers initially thought that they could not be true... The exploit is viable on any operating system in which privileged data is mapped into virtual memory of unprivileged processes, which includes most major operating systems for the affected CPU architectures.

Frankly, it's scary - to think that this major security flaw has been lurking for years in all Intel CPUs from Pentium Pro up, but only now discovered - or has it? I have no confidence in the ability of Intel and Microsoft to keep their latest products secure.

It's only scary if someone was operating under the mistaken assumption that perfect security is possible. Like someone thinking that their house is perfectly secure, or their car could never be stolen because it has an unhackable wireless key fob.

Security is imperfect, always was, always will be. Same goes for anti-virus software.

This may well be the largest vulnerability that nobody ever knew about, but I am damn sure it won't be the last one discovered.

The point being made is that you are better off with an OS which gets security fixes than one that does not. Applying the fixes simply reduces the time your computer is exposed. Since you are concerned about security, then logically you should run an OS for which you can get security fixes.

[julianhigginson]

As in real physical life, in computer life security is a process (or an ideal state). Security is not an absolute thing you can just posses.

If the value to violating your security is high, then there will always be more and bigger threats to your security, and so there will always need to be more and bigger countermeasures to those threats.

And the complexity of an OS running on a preemptive thread executing multi pipe-lined hardware is *far* too great for anyone to understand all implications and side effects... (hell, I'm surprised computers work at all, with the crap they do) So yes, bugs will exist and until we can formally prove every possible application use case with every possible application code running on an entire OS release running on formally proven hardware, they always will.

In some ways that "heartbleed" SSH bug was way worse than the latest preemptive execution side effect hack.. that was a bug in fully open source code for a major active project that was always in use and updated. And it had an enormous hole right in the middle of it for like 15 years and NOBODY NOTICED (or at least nobody who wanted to fix it noticed....)

So yeah, I find it weird that people insist on using 10 and even 20 year old proprietary software expect it to be updated for free.

AFAIK (though don't claim to be an expert here)  win10 is not going anywhere - it's going to the osX model of updates from now on. As in it'll perpetually be win10, but major version updates will be released. hence the recent "creators update"...

[Bruce Abbott]

the complexity of an OS running on a preemptive thread executing multi pipe-lined hardware is *far* too great for anyone to understand all implications and side effects... (hell, I'm surprised computers work at all, with the crap they do) So yes, bugs will exist and until we can formally prove every possible application use case with every possible application code running on an entire OS release running on formally proven hardware, they always will.

Thanks for admitting that running the latest OS doesn't necessarily make you any less vulnerable. Meanwhile, I have been running XP for over 10 years and never got hit by any malware. And the longer I keep using it the less vulnerable it becomes, because even cybercriminals are dropping 'support' for it. 

But if I want to be really secure I can always crank up the old Amiga 1200. No Intel code can touch it, nor Word or Excel macros, not even Javascript (browser support too limited). Security through obsolescence!     

So yeah, I find it weird that people insist on using 10 and even 20 year old proprietary software expect it to be updated for free.

Firstly I am not talking about 'updates' but only security fixes. The cost to Microsoft is probably minimal - but they won't do it because they are trying to force me into buying Windows 10. Sorry Micro$oft, not going to happen! Linux is the way forward for me now - and I bet I am not alone...

I have noticed that more and more developers are now using Linux or Macs. Open source software is mostly Linux-based, and most chip manufacturers are providing multi-platform IDEs. Vendors who buck the trend may see their popularity and market share decline. 

AFAIK (though don't claim to be an expert here)  win10 is not going anywhere - it's going to the osX model of updates from now on. As in it'll perpetually be win10, but major version updates will be released. hence the recent "creators update"...

If true that really sucks. Hardly surprising though - Microsoft don't seem to understand just how sucky their 'ultimate' OS is.

[hli]

Was that an open source project or a proprietary one.
If former I would love to take a look at project., code etc..

Let me dig up the code, I will attach it to the blog post.

[martys]

Thanks hli, finally at least one answer to my OP!

But looking on what you've accomplished with the similar and less powerful PSoC chip, the same thing could be so easily done using a 8051 chip or just about any 8-bit PIC chip, this idea only requires only one 8-bit port to create a 3 or 4-bit D to A convertor, just by using a R/2R resistor network to get the 8-steps shown in the ramp generator. Only a few lines of C-code required and can be compiled in DOS using a DOS text editor to create a very short C-source file.

No need for an oversized super-powerful gum-stick Cypress ARM core MCU dev. board here!

So, is your solution practical?

[mikeselectricstuff]

At $10USD and free debugger/IDE, seems at first a good deal, but the chip in quan. <25 has a  high cost ($8.27) and can't be breadboarded easily upon a solderless breadboard, so development is clumsy without using the very large Cyberkit-043

It takes  lots of wires messily connecting to a test solderless breadboard.

Is there a better MCU choice that offers as good MIPS (>16MIPs)
>16K or better SRAM
Easier to configure peripherals like A2D, timers,counters, PWM, etc.
A free, unlimited use of available  flash RAM
Having no code limitations of compiler/output code size
Offering a free Windows development IDE that isn't full of gotcha's and bugs?
Having the convenience of a DIP MCU package to be able to pop into a large prototyping breadboard?

PIC32MX1xx ticks all those boxes ( including DIP package)