Now that DCmp V2.0 is released, I can now consider work on possible future enhancements.

Feature: Hysteresis

It has been suggested by another PSoC5LP enthusiast to add hysteresis to the threshold comparisons.

This would potentially allow for slow and noisy input signals to not cause as much comparison output chatter.  'Cleaner' outputs might allow for better HW and SW state machine control.

For example, you could use DCmp to create a PID controller.  This control could make decisions to control a heater element or a cooling element (like an air conditioning unit). 

Since the input would be a temperature sensor going through an ADC conversion, the input can be slow but also a bit noisy.  Too much comparison chatter on the threshold might cause the heating or cooling to rapidly get signals to turn on and off many times in a short duration.  This could cause the temperature control device to prematurely fail.

Adding sufficient hysteresis by updating the threshold after crossing it to a value above the input noise level should eliminate this effect.

Implementation Ideas

Method #1: Dual Thresholds

I could implement hysteresis by using the dual-threshold ability of the DCmp component.

For example, I could load the upper threshold into Thresh1 and the lower threshold into Thresh2. The comparison outputs would start with the upper thresholds.

As the signal crosses the upper threshold (Thresh1), DCmp would then use the lower threshold (Thresh2) for its comparison outputs.  If the signal goes below the lower threshold, the comparison outputs would now use the upper threshold.

Pros: This is the fastest hysteresis switching.   

Cons:  The design would lose the dual threshold dual-output set of comparisons.   Also, this forces DCmp into unsigned comparisons.  

Method #2: DMA Threshold Reloading

Once the input signal crosses the upper threshold, a HW signals the DMA to load the lower threshold into DCmp threshold register.  If the lower threshold is crossed, the upper threshold is loaded into the same threshold register via DMA.  

This can be done in a TD loop with the new values.

Pros: This method allows the DCmp to be used in all modes currently available since the threshold registers are reloaded.  This allows for signed comparisons.

Cons:  A DMA operation can take 8 to 10 BUS_CLK cycles to complete.  This would add latency to the hysteresis switching.   However in most cases this latency might not be a problem.  For example, if the input is being supplied by an ADC, it is highly possible that the hysteresis switching can occur before the next ADC conversion can finish.

I welcome your feedback as well as further enhancement suggestions.

Dear Receiver,

In the attached file, I use manual turning. But I meet two kinds of clock parameters make me feel confused.

1. "modulator clock frequency": how this parameter effect cap-sense performance ?! If I select higher clock or lower clock, what's the corresponding result ?! 

2. "sense clock frequency": how this parameter effect cap-sense performance ?! If I select higher clock or lower clock, what's the corresponding result ?! 

Besides, how to select the sense clock source ?! auto, direct, PRS8 and PRS12. how to select them in a proper way ?! 

In fact, I know these parameters are explained in the manual but I still feel so confused. So I asked my question in here.

Hope I can get your kindly feedback.

Thank you so much.

Hello all, 

Most of the data I'm trying to transmit seems to be going between the FX3 and the other chip just fine, but I'm periodically getting zero length packets seemingly coming from nowhere. I've been trying to debug this, but everything I've tried has been a dead end so far.

I'm trying to use the FX3 to connect an 8051 on our board with a host application on a windows PC. My setup is as follows:

• An 8051 that has the microcontroller business logic. 
  • It receives input from the host from GPIF-II addresses 1 (buffered) and 2 (immediate), sends responses on 3, and there's logging macros that use address 4.
  • It's mostly legacy code, except what I've changed to make it work with the FX3.
• The FX3 that's mainly passing data between the host and the 8051
  • I'm using the GPIF-II interface. The state machine I'm using is basically the async slave fifo interface provided as a sample, except that I've changed some of the pin numbers.
  • USB addresses 2, 4, 6, and 8 are connected to GPIF-II addresses 1, 2, 3, and 4 respectively.
  • I have an additional USB endpoint 10 that I'm using for debugging. Every time data a packet is added to one of the other buffers, I sent the contents and a little metadata to the host. This way, I can debug problems between the FX3 and the 8051 independent of the production app running on the host.
• On the Windows Host PC, I have the production app that's trying to use endpoints 2, 4, 6, and 8 to talk to the 8051. There's some other issues there that I still need to investigate, but it's at least able to consume data from the buffer so they never get too full.
• Also on the windows PC, there's a logger app that connects to endpoint 10, and formats and prints the packets that the FX3 has received from the 8051.

Now the problem I'm seeing is that, the 8051 sends a keepalive signal periodically to the host app, and every once in a while, we get a zero length packet as well.

Here's what I've tried in my investigation:

• I've set breakpoints in the 8051 code to check if the actual data we tell it to send really is zero, and it never gets triggered, so I can be sure that we don't ever try to send a ZLP. I've verified that the pins I'm using to communicate with the 8051 are only touched in the 4 read and write functions that I expect them to, so the breakpoints I mentioned should cover every situation.
• I've verified that the order in which the pins change to control the state machine is correct. That is to say to write to the buffer:
  1. SLWR = 0
  2. Write Data
  3. if this is not the last byte, SLWR=1 and go back to 1.
  4. If this is the last byte:
  5. PKTEND = 0
  6. SLWR = 1
  7. PKTEND = 1
• My coworker who designed the board suggested that timing issues could mean the state machine is in a different state than I thought it was, so I've done the following to check timing:
  • In the FX3 manual, it says the GPIF-II "Enables interface frequencies up to 100 MHz", which I assume means that it can change state at least once every 10ns. In the state machine, changing a single pin causes at most 3 state changes before it reaches a stable state, so I tried adding a 30ns delay after every time we change a pin. Then when that didn't make a difference, I added another 30ns just in case, but still no dice.
  • Then I tried adding a full 1ms delay for good measure after every time I changed a pin, which changed nothing either. I figured this would cover my bases if I was mistaken about how fast the state machine transitions.

I suspected that maybe there's noise or something changing the PKTEND pin long enough to trick the state machine into sending a ZLP, but my coworker has already dismissed that notion. He's the hardware guy, so I can't really make him check it, and he didn't leave a way to attach a scope or anything to the pin, so wouldn't be easy.

If anyone has any suggestions of what might be going wrong, or ideas for other things I could test, I'd love to hear them.

I've created a new component for the PSoC5 that can be used in place of the Infineon Digital Comparator component in many cases.

My new component DCmp has many advantages over the Infineon component and when used with DMA as the data loading, can be very fast (~ 4 Msamples/sec)

Although the Infineon Digital Comparator is the fastest solution it comes at significant costs.  The DCmp component can save on PSoC resources as well as provide additional features.

The table below compares the two components side-by-side.  I've highlighted in RED what I believe to be the better advantage.

I've also provided a Demo project with 3 variations that demonstrate the abilities of DCmp.

The project was created for the CY8CKIT-059 but can be ported to other evaluation/kits or your own design.

Requirements:

• PSoC Creator 4.2 or higher
• PSoC5LP.

I have upgraded my DCmp (Digital Comparator) component to V2.0.   The upgrade still provides a very low PSoC resource allocation.

It now has the ability to use HW-routed inputs for faster comparisons.  I've been able to achieve up to 1/2 the BUS_CLK frequency in comparison decisions.  

It still has the DMA and CPU access to inputs and comparison thresholds.

It also has improved API calls and component datasheet documentation.

There are some fixes for issues that might occur with the original DCmp release.

Requirements:

• PSoC5LP
• PSoC Creator 4.2 or higher.

Demo Project

I've included the DCmp component  in a Demo project to display its features.

Future Enhancements

It has been suggested that a hysteresis function might be useful. (Ie. Once a threshold is crossed, the threshold is changed to prevent slow and noisy inputs from comparison output chatter.)

I have some ideas about how to implement hysteresis.   I will start another thread to discuss ideas.  I'd appreciate your contributions.  Future-Enhancements-to-DCmp-component 

Note:  This has been a very educational endeavor.  I've learned my things about using Verilog as well as the excellent UDB architecture supplied on the PSoC5.

Dear supporter

I want to translate the following KBA(KA-03531), please confirm to my work.

https://community.infineon.com/t5/Knowledge-Base-Articles/SPOC-2-How-to-handle-the-EDD-and-EDO-pins-when-they-are-not-used-KA-03531/ta-p/350992

Best Regards.

Yutaka Matsubara

Hello,

the code for the temperature sensor DS18B20 works fine using only the display. But when I add the BLE code, I can't get it to work, it disconnects before receiving the temperature value. I have tested the same BLE code with another max30102 sensor and it works perfectly.
Can you help me?

Thank you

Dear supporter

I want to translate the following KBA(KA-03315), please confirm to my work.

https://community.infineon.com/t5/Knowledge-Base-Articles/What-are-the-minimum-required-external-components-for-LITIX-Basic-KA-03315/ta-p/350994

Best Regards.

Yutaka Matsubara

Hello together,

I'm a bit confused. So I have drawn the gain-curves of the LLC converter. And they look fine on the nominal frequency scale:

In the diagram the numbers in the legend are the amount of load with 1 being 1500W at 100V output load. The formula used are:

Mg = 1/sqrt(Qe**2*(-fn + 1/fn)**2 + (1 + 1/Ln - 1/(Ln*fn**2))**2)
with fn=fsw/fr; Ln=Lm/Lr; Qe=sqrt(Lr/Cr)/Rac; Rac=8*Vout**2*n**2/(pi**2*Pout)

But when i determine the resonant frequencies for different Loads (graphically determined - cross checked with calculation) and draw the gain-curves across the switching frequency the area of the frequency range is way off than the desired 500kHz resonant. It's some where between 169819Hz -298807Hz.

The NullMg represents the gain-curve for the Null Load case.
The MaxiMg represents the gain-curve for the Maximal Load case, which is here the 1500W. 
The FullMg represents the gain-curve for the Full Load case.

I was expecting a wider range when plotting the gain-curves with the  resonant frequency for each load. Due to the relation between the resonant frequency and the load. But I did not expect such a big deviation.

Is this big deviation normal, or is maybe something with my fundamentals flawed?
Thanks for any advice.

PS: I used Ln=6; Qe=0.4 to determine the resonant circuit.

It should be noted that I know that choosing a smaller Ln results in a narrower frequency range, but additionally it results in increased conduction losses and decreased commutation losses.
Additionally a big Ln results in a big Lm, which is needed to keep the ZVS.

Hello everyone,
I'm customizing Android 6 to fit a SoC that comes with muRata LBEE5KL1DX (CYW4343W).
I successfully embedded Cypress Linux WiFi Driver Release (FMAC) [2022-03-31].
NVRAM file comes from muRata repository, firmware and clm_blob files come from the above archive.
If an access point uses (WPA2-PSK) either TKIP encryption only or its combination, Android sometime takes till 2~3 minutes sometime within few seconds to acquire a dynamic address and establish the connection.
If an access point uses (WPA2-PSK) AES encryption only, Android always connects it within few seconds.
I digged in calling kernel module in this way

     insmod /system/lib/modules/brcmfmac.ko debug=0x00108414

but I didn't achieve good results.
Using TKIP encryption, the board sometime has to receive several dozen of DHCP offers before establish a connection. Using AES encryption, radio quickly connects 10/10 times. The same behaviour using different access points (Sitecom, Digicom, Netgear).
What you think about ?

Thanks in advance for whatever help and best regards.
Alessandro