cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC™ 6

SaKu_291986
New Contributor II

As PSoc6 does not have a glitch filter component, can anyone let me know the alternatives?

0 Likes
1 Solution
Len_CONSULTRON
Honored Contributor II

CaKu,

Your circuit above is a replacement for the LUT approach.

Here is a 5 register LUT solution to a deglitcher.

The input_unfiltered goes through each of the register stages.  The input_unfiltered MUST remain true for each register stage of the filter to get to the output_filtered as true.  (Active high logic.  Active low logic can be implemented with the appropriate logic inversion.)

This implementation using the LUT can be scaled down by reducing the number of inputs (and output to input feedback connections).  It can be scaled up by allocating another LUT.

Attached is the LUT logic table used exported as a .csv.  You can see the logic is VERY simple.

Len

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

13 Replies
Rakshith
Moderator
Moderator

Hi SaKu_291986​,

You can use the lookup table PSoC Creator component with Register Outputs option enabled to implement the glitch filter in PSoC 6. Please refer to the Lookup Table Component Datasheet for further information regarding the component.

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B
Len_CONSULTRON
Honored Contributor II

SaKu,

If you're looking for a simple debounce circuit, it is available for the PSoC6.  The debounce circuit is a Glitch filter with only one signal depth.

pastedImage_0.png

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
CaKu_4284131
Contributor II

I've been using ones like this:

pastedImage_0.png

but I want to try that Lookup Table approach.

0 Likes
Len_CONSULTRON
Honored Contributor II

CaKu,

Your circuit above is a replacement for the LUT approach.

Here is a 5 register LUT solution to a deglitcher.

The input_unfiltered goes through each of the register stages.  The input_unfiltered MUST remain true for each register stage of the filter to get to the output_filtered as true.  (Active high logic.  Active low logic can be implemented with the appropriate logic inversion.)

This implementation using the LUT can be scaled down by reducing the number of inputs (and output to input feedback connections).  It can be scaled up by allocating another LUT.

Attached is the LUT logic table used exported as a .csv.  You can see the logic is VERY simple.

Len

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

CaKu_4284131
Contributor II

I wonder about the trade-off between number of stages vs. frequency. Say, five stages at  1 kHz vs. two stages at 400 Hz. I guess you'd have a larger "sampling error", but I doubt it would be noticeable to a human pushing a button.

One use case I'm thinking of is a four key keypad in my design that currently takes up a page of flip flops and gates. Maybe I could simplify that.

0 Likes
Len_CONSULTRON
Honored Contributor II

CaKu,

It is more HW efficient to use 2 stages @ 400 Hz rather than 5 stages @ 1KHz.

If you're just looking for a switch debounce and want to VERY HW efficient, you can use a SW debouncer.  No HW stages used!   This is the common approach for those processors that don't have the HW flexibility of the PSoC.  In the SW approach you can use an interrupt or event better poll the input.  In this approach you can have as many stages as you'd like.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
CaKu_4284131
Contributor II

I am using interrupts, but without HW debouncing, I got "storms" of interrupts. This is a FreeRTOS application, and there are lots of other things happening, such as BLE and data logging, so SW debouncing is less than ideal. Incidentally, I have a prototype based on the PSoC® 6 BLE Pioneer Kit (CY8CKIT-062-BLE) (https://www.cypress.com/documentation/development-kitsboards/psoc-6-ble-pioneer-kit-cy8ckit-062-ble​), and one of the GPIOs I'm re-purposing for a keypad input (had to pull some resistors) happens to have a capacitor on it, and that one behaves pretty nicely without other debouncing.

0 Likes
Len_CONSULTRON
Honored Contributor II

CaKu,

My preference is to use HW where ever possible and practical even if it can be implemented in SW.  The PSoC gives the user extra HW (via UDBs and Datapath elements) to customize to minimize SW intervention.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
CaKu_4284131
Contributor II

Len wrote:

My preference is to use HW where ever possible and practical even if it can be implemented in SW.  The PSoC gives the user extra HW (via UDBs and Datapath elements) to customize to minimize SW intervention.

I agree, but I don't want to add parts to the bill of materials if I can avoid it.

0 Likes
Len_CONSULTRON
Honored Contributor II

CaKu,

I agree 100%.   That's why I like the PSoC products with internal UDB and Datapath resources.  Using the TopDesign to create schematics of the logic and analog components, I can create HW state machines to minimize SW intervention allowing for more CPU idle time.  All this also allows me to minimize external BOM costs and minimized external wiring.

An additional benefit is that if I see a better way to implement the HW state machine (eg. changing to a DMA-driven scheme) I can make the changes in the TopDesign and the SW probably without having to add anything externally or having to rewire anything.

Len

Len
"Engineering is an Art. The Art of Compromise."
odissey1
Honored Contributor II

CaKu,

Here I made a software denounced for PSoC5/4.

ButtonSw32: button switch debouncer component

It utilizes polling with vertical counters algorithm and consumes very little clocks (typ. 50 ticks every 1-2 ms). Works well with manual buttons. It hasn't been tested with PSoC6 or RTOS, but you can copy the code, as it not much there.

/odissey1

CaKu_4284131
Contributor II

BoTa_264741 wrote:

Here I made a software denounced for PSoC5/4.

ButtonSw32: button switch debouncer component

It utilizes polling with vertical counters algorithm and consumes very little clocks (typ. 50 ticks every 1-2 ms). Works well with manual buttons. It hasn't been tested with PSoC6 or RTOS, but you can copy the code, as it not much there.

Very nice! Since I am using FreeRTOS, that gives me an idea that I could use the Tick Hook Function (https://www.freertos.org/a00016.html​) to implement something like this. But I would need bigger counters, since the tick frequency is 1000 Hz.​

EDIT: Actually, now that I think about it, I could probably use a Software Timer (FreeRTOS - RTOS software timer functionality and features description) to get a callback at 100 Hz.

0 Likes
SaKu_291986
New Contributor II

Thank you one and all for your glitch filter alternatives!!!

0 Likes
Top labels