PSoC 5, 3 & 1 MCU

[Anonymous]

        Has anyone had any experience modifying a component that's part of Cypress' component catalogue?   
   
I need to create a version of the quadrature decoder that has a true 24 or 32 bit counter.   
   
The standard PSoC Creator install seems to be missing a project file so it can't be modified as if it were a "custom library".   
   
Any help is appreciated,   
Steven   

[MarkS_11]

        Best way is to import the component )from CyComponentLibrary) into your own design project or library. You do this from the Components tab in the Workspace Explorer. Right-click on the project and select Import Component. Then make your future projects dependent upon that library.   
   
Note that the imported component "masks" the one in the library so I also recommend placing it in you own area of the the catalog. You do this from the properties of the symbol - right click on white space, select Properties and edit Doc.CatalogPlacement (just deleting what's there will move your copy into a new Catalog tab called "Default").   
   
-- mgs   

[MarkS_11]

        Oh yes, the PSoC Creator 110 training (and the add'l modules there) might be good for you too.   
   
-- mgs   

[Anonymous]

        Thanks for the tips.   
   
It turns out that modifying the stock components is no small task. Adding the additional logic is easy enough but tweaking the generated code and UI elements to utilize the new design proved to be more work than I can budget.   
   
I'm still searching for a way to close the timing window between when the 16 bit quadrature counter over/underflows and the interrupt is serviced. During that small interval, the reading is invalid -- and terribly wrong -- off by 64k. I don't want to learn first-hand what the Toyota engineers are experiencing...   
   
Thanks again,   
Steven   

[MarkS_11]

        That's a shame but feel free, if you change your mind, to ping me with questions on modifying symbols and writing APIs for components.   
   
Do we (Cypress) have a good understanding of the problem in our QD? Has it been reported through TightLink? There is not much info in this thread and I am asking because, of course, I would like to make sure we get the original component defect fixed!   
   
-- mgs   

[Anonymous]

        I wouldn't say that there is a problem with the design. It works as intended. On my feature wish list would be:   
   
I wish there was the option of consuming the hardware to produce a true 24 or 32 bit counter.   
   
I wish it was more clear that the current QuadDec 24 and 32 bit versions relied on software to implement the upper bits. For some applications the timing window isn't a problem and hardware resources may be tight.   

[HuEl_264296]

 yfs,

       

people shouldn't be pinging you with e-mails about such a fundamental part of the PSoC design process. This stuff should we well and publically documented.

       

Hugo

[Anonymous]

Hi - I would have "pinged" you if I had been able to 😉

   

I am migrating a number of PSoC 1 designs to PSoC 3, and one UM in particular is giving me a headache - this is the PWM.. On PSoC 1 it is easy to write a value to the compare register which is only loaded / updated at TC.. But I have found no easy way to do this with the PSoC 3 PWM.

   

I am only just starting to use PSoC 3 (I have developed extensively using PSoC 1, and am a CYPros) and can see the huge benefits inherent in the new devices, and with time I am sure these issues will fall into place - but I do find the lack of such a fundamental function on the PWM component quite a surprise - I have tried using DMA, but even with this there are glitches on the PWM output.

   

Is it possible to direct me to documentation I need? - Or even better, is it possible for Cypress to create a library of components which behave in the same way as the standard UM's available for PSoC 1. I have a client who cannot understand why I am having problems implementing the PWM's on this new, far more advance part - doing the whole job on PSoC 1 took me a day, I have now spent 3 simply trying to get the PWM's to behave!

[ETRO_SSN583]

The PSOC 3 PWM has an API, PWM_WriteCompare(), so I am not sure

   

what the problem you are having is ?

       

Regards, Dana.

[Anonymous]

My humble apologies!

   

Yes, I could see that there was an API to write the compare register - but this wrote the value directly.. and as I have the pwm running continuously caused glitching ..

   

I believed that the PSoC 1 pwm UM was different - that the compare value was updated at TC and not instantly after writing.. Going back to PSoC Designer I find that my new (PSoC 3) code behaves exactly the same when ported (with the required changes) to the PSoC 1.. It also updates instantly and glitches!

   

Its been 3 years since I did anything serious with the PSoC (been out of action following heart failure) and 5 years since the project I am now moving to PSoC 3 was done - I guess I need to go back and more carefully see how I managed to avoid glitching with that design -

   

Sorry for this distraction - but your answer did help me to look again at the problem in a strange way..  I felt quite indignant (LOL) and was going off prove that the PSoC 3 pwm component didnt do what the PSoC 1 pwm UM could! 😉

   

Thanks!