Greetings. I am attempting to drive a PrISM block from a potentiometer / ADC to control intensity of an LED load. I am new to PSoC internals so be gentle please. I am using the CY8KIT-043 - the CY8C4247AZI-M485.
I have successfully created the system layout using ADC + DMA + PWM and am impressed at the PSoC's simplicity. I have apparently run into a complexity wall when attempting to implement PrISM (which is needed to fulfill other low level dimming control requirements in the project). There is a nice ADC example for PSoC 5 but is apparently not portable back to the 4 series. I think I run out of resources.
Images of the currently working PWM system and the desired PrISM configuration are attached.
Is DMA the right way to go? What is the simplest route to control PrISM density / LED intensity from my analogue source please? I could look at other parts but I would need locate a low-ish cost dev board to build the first parts on.
I have attached my successful PWM project with a PrISM and ISR block randomly dropped on to it - intended to eventually replace the PWM. Any advice appreciated. 8 or 16 bit is good. I hope I am missing something obvious. Many thanks in advance for any assistance. Regards,
Solved! Go to Solution.
PSoC 4 MCU
From what I read on your thread you were facing resource over-run issue. But I could build the project you have attached without any problem after giving respective connections to the PrISM block. Could you please let me know what am I missing here?
Apologies to both responders for their prompt and valuable response - we had a covid incident and had to cease work for the summer - no offense intended.
1. Could you please indulge me and point me to the correct "respective connections to the PrISM block" as you call them. That is what I apparently cannot configure or initiate in code. As per my other response below I have experience in configuring and operating PRISM block as an analogue tool for an analogue end - I know what it does - but I am a PSoC novice. I can edit examples really well though. I do understand the capabilities of PRISM as a power control tool - what it does and why I would do it - it is the connection of the block in the system as connections on the screen and the control of the block in code and that I am stuck on. Any help or examples appreciated. What the connections should look like - what some code might look like.
2. How do I address a resource over-run issue as relates to DMA please? The bug presents almost like an old-school divide by zero error - at the extreme end of travel just before reaching its 100% full-on the system's PWM output drops to zero. I can see the PWM drop out with a scope. I assume the PRISM would see the same behavior form the control source.
There is currently no code used in the DMA connection as per the Cypress app note. My hope is that I can eliminate the strange behavior by adding some code or even by changing the actual means I use to get the analogue control to PRISM - like move to ADC - but it is currenlty so beautifully simple I love it. I like pots and I can happily use ADC to control the PRISM instead of DMA if you can point me to an example.
A million thanks for any words of advice you have.
Please check this old discussion about non-linearity issues of controlling LED with PRISM. In short, PWM control is more linear than PRISM.
Using DMA controlling LED is an overkill, it was intended for high-speed tasks.
There is better way to control LED using a rotary encoder instead of potentiometer. No DMA needed. This way the valuable ADC resource can be freed for other tasks. You can find simple community component QuadDecoder and demo projects, showing its use here
Apologies to both responders for thie prompt and valuable response - we had a covid incident and had to cease work for the summer - no offense intended.
Thanks but the PRISM is a necessity. Getting that working form a pot is my brief today. I am a hardware guy. PRISM is necessary in this project for its analogue properties at extreme deep dimming and its ability to extend the dimming depth before dropout. We are not seeking linearity as such but instead its analogue resiliency extreme dimming effects - which are related to its stochastic nature at the Vf dropout margin and the transient impedance of different array configurations of LEDs. I am not a software guy but am trying to learn. I have used PRISM successfully on other projects (as the hardware guy) and it makes a huge difference - also sidesteps patents and is amenable to follow equations in its dimming profile.
The micro is necessary only because the PRISM is necessary based on prior analogue experience. I hope that makes things more clear. I may take your advice on the decoder - this is also a longevity project though and we were planning on buying an amazingly expensive pot as the control - one with 2M++ operation rating to push the rotation lifetime out past the capacitor fail point. The actual knob must also do a hard analogue low voltage OFF for code compliance and service reasons - which comes built into the analogue pot as an analogue switch at the low end of the travel.
The only 2 tasks we maybe plan in the future are enabling Bluetooth and enabling capsense for proximity control - which I think I can do OK in the future with what I have now. Not a part of this spec anyway so although nice additional capability is not in the job brief today.
Very many thanks for this - I am extremely grateful for the support. I am going to investigate both suggestions now. The DSM is very interesting to me. If it doesn't work in this project I can think of many applications where DSM might be of use. I am going to test this now. Thanks again.
I updated and tested project using KIT-044. Please find updated project attached. You would need to re-assign i/o pins to run it on KIT-043. I recommend using a capacitor on the ADC input to clean up the noise, else some LED flickering may occur at ~0V threshold.