Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

PSoC™ 5, 3 & 1 Forum Discussions

WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted
0 Likes
20 Replies
WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted

  Sorry, I hit too many backspaces and the web page posted!  No edit button on that one either.

   

  Any way, I wish to connect a VDAC output through an analog mux and stay inside the chip.  I've done some googling, and in the PSOC3 family, doesn't seem possible based on forum conversations.

   

   Is it possible with PSoC 5?   I would prefer the hardware control signals, but the AHwMux doesn't seem to work.

   

  I've been unable to do it with AmuxHW, I get "net xx is expected to connect to only one GPIO..."

   

 thanks in advance!

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

The analog muxes of PSoCs connect to GPIO pins only, What exactly do you want to perform, there might be a way out.

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
100 sign-ins 5 likes given 1000 replies posted

This simple example routed (NOT HW mux) -

   

 

   

   

 

   

The HW mux however only routes to GPIO. Note it says in datasheet -

   

 

   

Use an AMuxHw component when you need a signal to be switched in hardware. Currently, only the GPIOs can be multiplexed with this multiplexer

   

Emphasis on "currently".....

   

 

   

You could "effect" a workaround by using interrupts to control the

   

non HW mux to make it "look" like a HW mux.

   

 

   

Regards, Dana.

0 Likes
WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted

 Thanks, Dana.  

   

   That diagram is exactly what I want to do, except I need to control it from hardware rather than software, so I can get exact 10 us wide pulses.

   

   Yes, the "currently" in the hardware mux is the sticking pointer here.

   

    I have given up and routed out the GPIO pins and used the HW mux so  I can get an exact 10us wide pulse (using TC of a down counter).  

   

    I'm having issues with the one-shot mode not retriggering the down counter, but I haven't tried all the possibilites on software control of it.  I do not yet see an easy way of retriggering once the downcount has occurred once.

0 Likes
ETRO_SSN583
Level 9
Level 9
100 sign-ins 5 likes given 1000 replies posted

Take a look at this thread -

   

 

   

    

   

          http://www.cypress.com/?app=forum&rID=63168

   

 

   

Regarding 10 uS "exact". You might look at clock inaccuracies to get

   

an idea of how exact, and then consider using an ISR (and its latency)

   

with high priority to "effect" a HW mux. Just a thought.

   

 

   

Regards, Dana.

0 Likes
WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted

 I was able to get what I wanted by going outside the chip and using external pins.  With the following configuration, I get a pulse height based on the voltage I put into the VDAC.  I had to put an opamp follower on the VDAC, because the VDAC output sagged for about 3 us while the current through the R path to the outside world's new C,  charged up the destination capacitance (in my case, scope probes and a BreadBoard socket arrangement).  Once I put an opamp follower, the voltage transition was nice and sharp.  (The VDAC is essentially an IDAC feeding a resistor with a fixed current.  Therefore any abrupt transitions in C that it sees will cause the voltage to sag for a brief period of time, if the outside C's voltage is less than the voltage presented.  In this case, the voltage was ground, charging up to VDAC output level.)

   

   The reason  I could not get the One Shot Counter to work was because it requires a hardware reset signal to work the second time. The One Shot timer works the first time when Start() is called,which confused me.   I read enough of the Datasheet to get started, but not enough to finish.  (My fault)

   

    To have the OneShot timer work with TC staying high when terminal count is reached, you have to choose UDB.  At that point, you have to hook up Count to your counting clock (in my case 12mhz), and the clock has to be hooked to a true clock source (in my case 24mhz).     When you do this, Count does not have to be a clock source, it can be a digital edge.  The 24mhz clock then synchronizes to the system clock.

   

   In my project, I got a warning about 12mhz clock being asyncronous due to routing, but in this case, it is not a problem since the 24mhz clock is doing the synchronization.

   

  Update:  Sorry, the picture didn't make it, I've enclosed the .png 

0 Likes
HeLi_263931
Level 8
Level 8
100 likes received 50 likes received 25 likes received

When you sync a 12MHz clock to a 24MHz clock, you might introduce a lot of jitter. I don't think that you will loose pulses, but I think its a stretch. Its better to increase the master clock.

0 Likes
WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted

  Attached is the .png update.

   

  @hli, the reason I don't get clock jitter on this is due to the fact the 12mhz clock comes off of the 24mhz clock, and the 24mhz clock will always syncronize within one clock cycle.

0 Likes

Hi bro:

sorry to disturb you here,

I'm curious on the graph you post here and want to ask you some questions,

So I know the when using AmuxHW means that the input should be GPIO pins,

same to you, the control of the mux I need is hardware connections, so must use the AMUXHW

so base on your graph, you use VDAC to output the analog signal to one GPIO and then use some wire outside to connect it to another GPIO for the signal to input inside the chip, and then you can use the AmuxHW cuz it is a GPIO input and finally generate the pulse to output.

So I want to know if my understanding of your design is correct, cuz if it can work, seems that we can avoid the problems of AmuxHW restrictions.

Thank you

HAN

0 Likes

HAN,

This is duplicate post of PSoC4 thread

AMUX control problems

Besides, you have PSoC4 BLE, and this is PSoC5 forum.

If you had PSoC5, then yes, this solution using external pins would work. But if it would be PSoC5, othen other, more straightforward solutions available to switch polarity of IDAC, e.g. using hardware control or DMA.

/odissey1

0 Likes

Hi odissey:

thanks for your reply,

sorry to disturb and sorry for sending a PSoC 4 problems here.

Anyway,I just want to know one point, which is common in both PSoC 4 and 5, the problem of AMuxHW, which cannot directly connect a internal analog signal as an input. so I don't know if  user_463759797 has sucessfully completed his design using his method as mentioned in this graph.

BTW: in PSoC 4200BLE, the polarity of IDAC cannot be HW controlled, so here my design method are similar with him and wanna ask for sure. If any inconvinence, I will delete my reply. Thanks

Best rgds,

HAN

0 Likes

HAN,

Yes, using external pins with HW MUX works fine. The drawback is that many pins are wasted and extra routing eats analog wiring resources, which are limited.

To control PSoC4200 BLE IDAC polarity with "almost-hardware" timing, I would try to use DMA to set IDAC8 polarity register. I believe that in your case timing is not very fast, so it should work.

/odissey1

0 Likes

Hi odissey,

many thanks to your instant reply,

actually I only use it for this application so the waste of the analog resources can be neglected

Also thanks for advicing of using DMA, i will try it later.

Best rgds,

HAN

0 Likes
WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted

 There is a piece of info in the middle of the data sheet regarding the Down counter used as a One-Shot, restarting the countdown.  In that case, a hardware reset must be applied.  You aren't supposed to be able to do it from software.

0 Likes
HeLi_263931
Level 8
Level 8
100 likes received 50 likes received 25 likes received

When I understand that diagram right, you want to generate a 10µs pulse with V(vdac) once every 1ms. You generate that 10µs pulse with the counter, and then reset the counter from an ISR. The pulse then drives the HWMux.

   

Wouldn#t it be easier when the HWMux is driven from a PWM? Have it run with 24MHz, set the period to 24000 and the pulse width to 240. That gives you the wave form you need.

0 Likes
HeLi_263931
Level 8
Level 8
100 likes received 50 likes received 25 likes received

And yes, that one-shot mode with counter, timer and PWM is kind of tricky and non-intuitive. Whenever I need it I need to look into the data sheet and test whether it really does what it should.

0 Likes
WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted

 The 1ms was just a test fixture to give me enough scope presence to make it work.

   

The screen shot contains a *lot* of embedded, "oh, it works like this."  The software behind  it is similar.

   

.

   

The final product will be less periodic, and there will be multiple pulse producers with multiple pulse heights.

   

.

   

Thanks for your suggestions.

0 Likes
HeLi_263931
Level 8
Level 8
100 likes received 50 likes received 25 likes received

If you need the pulses to be generated under software control, using the one-shot mode is OK.

   

If you want to do that more automatically, I think there might be a solution involving a LUT and a DFF that can gate the clock into the Timer / PWM / whatever(an AND that gates the clock, a DFF to hold state, and a LUT to handle the different states - maybe the latter one is not needed even)

0 Likes
WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted

 Since the one shot mode requires a hardware reset, it could theoretically be done totally from hardware.

   

.

   

However, since the point is multiple pulse heights (and the rep rate is low, maximum 4khz), then having a software/hardware mixed solution is the path I have chosen.

   

.

   

There is more than one way to skin a pulse height!

0 Likes
HeLi_263931
Level 8
Level 8
100 likes received 50 likes received 25 likes received

Yes, thats the beauty of PSoC - there are multiple ways do solve problem, depending on your actual needs.

   

I tend to prefer hardware, since there is less chance to screw it up when its started working (in software a simple error in a completely different area can mess up whole programs).

0 Likes