7 Replies Latest reply on Mar 25, 2020 1:23 PM by AnEy_1336741

    "It is not recommended to use PSoC5 for newer products" - Why?

    AnEy_1336741

      In an answer to one of the latest questions in the PSoC5 community, I found the statement above. Is there more information around that?

       

      There are for sure applications, that can not be done with PSoC4 nor with PSoC6. I am using much of the vast amount of building blocks of the 58 and still wish to have more. None of the other PSoCs is suitable. I would have to use two or three PSoCs to do the same, but without the flexibility and the ease of use.

       

      Are there other users with similar thoughts?

      And how does the roadmap for PSoC5 look like?

       

      Thank you!

        • 1. Re: "It is not recommended to use PSoC5 for newer products" - Why?
          GaneshD_41

          Hi

           

          Yes. Cypress wants to encourage all its customers to use the latest products from our side like PSoC4 and PSoC 6. However this statement is valid only if you are able to build your complete application and meet your requirements with PSoC 4 or PSoC 6.

           

          PSoC 4 uses Cortex M0/M0+ cores which consumes low power compared to higer Cortex M cores. PSoC 6 family is a dual core M0+ and M4 which is mainly targeted for low power and high performance applications.

           

          Also, PSoC 4S and 6 families have advanced IPs like CapSense which give much more SNR than PSoC 5. PSoC4 family has inductive sensing supported part also.

           

          Also in firmware development side PSoC6 can be programmed using Eclipse based IDE called Modus toolbox 2.0. Also, the PSoC 6 has PDL which is not available for PSoC 5. The PSoC 4 PDL will be available soon.

           

          So, you are welcome to use Cypress PSoC 5 if it suffices your application requirements. There will not be any problem.

           

          If possible, please let us know the application you are aiming for. We will check if it is done by single PSoC4/6 family device.

           

          Thanks

          Ganesh

          • 2. Re: "It is not recommended to use PSoC5 for newer products" - Why?
            AnEy_1336741

            Hello Ganesh!

             

            Thanks for answering!

             

            As a PSoC-enthusiast from the very first PSoC1 on, I always have an eye on everything new in that family. So, I also studied the datasheets of PSoC4's (I started my design with a 4200, but had to shift to PSoC5LP) and the new PSoC6, as I'm always looking for something with even more building blocks and flexibility. But until now, I couldn't find that.

             

            I attached the current internal schematic of my design. The whole application is an interface for test automation in the automotive area. I started this one in 2016 and it grows and grows. Next steps should include changing the SAR-ADC-sample-rates to maximum and feeding the data through the DFBs, adding two more DACs as wave-DACs to overcome the limitation with the muxes in front of the SAR-ADCs, where also the analog outputs are located, a PRS for providing a random bit stream and a shift register for programmable bit streams which both should be connectable to the CHx_out-pins. The PSoC sits on a mainboard with four extension slots, where one is now equipped with 32 optoMOS-relays. Some more extensions will come. Interface to those are I²C,SPI and the small parallel bus in the bottom right corner of the interface page. The first page, named "Analog" shows on its left side the eight inputs (each has its own frequency-compensated voltage divider at the outside), where each one has its own comparator. The six outputs are also used to get the state of a rotary switch and two single switches for power-on configuration purpose.

            I think, that this Multi Purpose Module named device would not have come to life without PSoC5LP. Even more, as development resources for non-automotive devices are very limited in our company.

            For me, a PSoC59LP or PSoC5XC with more routing capability, buffers included in the SAR-ADCs and more SC-features from the old PSoC1-world, just to mention some ideas coming from working with the PSoC58LP, would complete the picture of a one-for-everything PSoC. More processing power would also be nice, but not for the price of reducing the supply voltage of the analog part to 3.3V, as that means loosing a part of the noise margin.

            For the Creator, I could imagine some more standard components for supporting all on-chip capabilities. Analog filter, power monitor (the on-chip, not for external regulators! It existed for the FM's but never supported PSoC5LP ...), LIN (what happened to the prototype?) and more capabilities of the SC-block, just to mention some.

             

            If you need to analyse an archive of this project, then please ask me within private email.

             

            Thank you and bye,

            Andreas

            • 3. Re: "It is not recommended to use PSoC5 for newer products" - Why?
              LePo_1062026

              Andreas and Ganesh,

               

              I'm in agreement with Andreas.  I too have designed with and appreciated the ground-breaking foresight of the PSoC1.  Even now, without resorting to designing my own ASIC, the PSoC5 has the "top-of-the-line" HW flexibility to optimize the performance of my designs by creating complex HW state-machines that unburden the CPU.

               

              It appears that Cypress may have "dead-ended" the PSoC5 product line.  They continue to make advancements on the PSoC4 and PSoC6 product series. Great.  Maybe they see the PSoC5 architecture as a 'niche' to HW/SW enthusiasts such as us.  However, maybe they see the PSoC5 this is a market with limited potential.

               

              This is why others like myself have contributed additional libraries and components to this family.  It is an attempt to help other see the greater potential of the PSoC5 and PSoCs in general.

               

              Len

              (I'll get off my soap-box now ...)

              • 4. Re: "It is not recommended to use PSoC5 for newer products" - Why?
                AnEy_1336741

                Hello Len!

                 

                Where shall we put contributions to know-how, libraries, components …? It's not easy at all, to retrieve information in the community, as there's a lack of structuring. Is there an external wiki? I have a small but growing collection of how-to's I've put into a local tool, which has tree-based structuring.

                 

                Thanks and bye!

                Andreas

                • 5. Re: "It is not recommended to use PSoC5 for newer products" - Why?
                  BoTa_264741

                  Andreas,

                  what is the purpose of the logic blocks on pp. 2-3? Rotary encoders?

                  /odissey1

                  • 6. Re: "It is not recommended to use PSoC5 for newer products" - Why?
                    LePo_1062026

                    Andreas,

                     

                    The contributors have placed examples, libs and components in-line to specific discussion threads.  This addresses the poster's immediate issue but is sometimes harder to locate.

                     

                    Many of us have contributed to Community Code Examples .  It is not specific to the PSoC5 but this is the only Forum intended for code sharing.  Maybe Cypress can point us to a better Forum.

                     

                    Len

                    • 7. Re: "It is not recommended to use PSoC5 for newer products" - Why?
                      AnEy_1336741

                      Hi Odissey1!

                       

                      Pages 2 and 3 are mainly meant for masking out secondary signals. Dsig1A and Dsig1B (for example, there are four identical blocks) are parts of a differential signal, which is pulse width modulated. The signal which is first in time is fed through to the EXOR, and the other one is masked out for the time of the measurement. This is for preventing ringing from distorting the logic signal at the output.

                      The Control_Regs are just for switching parts on and off.

                       

                      Andreas