PWM_32_V2 - Question about Resolution constant

Greg Glenn

I am considering modifying PWM_32_V2.spin so that any of the 32 pins can be used as PWM input at the same time that other pins are used as output.

It appears to me that the "Resolution" constant depends upon the amount of time it takes for the Main_PWM_Loop to execute, and if I were to add code to that loop to record input pulse lengths, I would need to time the loop (or add up the instruction cycles) and change "Resolution" accordingly.

Is this correct, or am I missing something?

Greg

Beau Schwabe

Greg Glenn,

I believe that's correct. I haven't looked at the code in awhile, but that sounds like an accurate description.

Mike Green

You could do what you want using the main PWM loop, but, depending on your needs, you may do better measuring input pulse widths differently. If you only need 1 or 2 channels of PWM input, you could use the cog counters to measure the actual pulse width and read out the cog counters during the main PWM loop. You might consider using a separate cog for measuring pulse widths on up to 32 I/O pins since you wouldn't need the overhead of the PWM output code. What kind of accuracy, precision, and reproducibility are you looking for?

Timmoore

This may be a useful starting point. It times up to 8 pins, I use it for rpm sensors for brushless motors but probably would work for your application.

Greg Glenn

Beau: Thank you for confirming.

Mike: My application currently uses the cog counters to measure pulses on 4 channels (pins). But I am doing that in one cog since I can't spare 4 cogs for PWM input. That requires the pulses come in sequentially and not overlap among the channels.

I want to be able to handle overlapping pulses on as many as 8 channels, from one cog, so I am looking at other approaches.

The way PWM_32_v2 generates pulses which can overlap among channels, seems like a nice way to do input as well. As for accuracy, precision, or reproducibility, I will have to work that out.

The 8us resolution of PWM_32_v2 is probably somewhat more coarse than what the cog counters are giving me now. The pulses I need to measure are servo-standard 1ms to 2ms width, so 8us resolution would only give me 125 steps, where I would prefer to have something more on the order of 1000 steps. I may end up doing the input in a separate object as you suggest, and limiting it to 8 channels instead of 32, to get the resolution I need.

Greg Glenn

Timmoore wrote: »

This may be a useful starting point. It times up to 8 pins, I use it for rpm sensors for brushless motors but probably would work for your application.

Hey, this does look like it should work. Thanks!

Timmoore

One thing to watch for, is I am using it in a noisy enviroment - its picking up the signals driving the brushless motors so it has some checks on the min/max periods allowed - you should check those make sense or if your signals are clean you could delete the checks.

Greg Glenn

Good to know. My circuit is also near a brushless motor and speed controller. I haven't had issues yet, but I will keep this in mind.

The pulses I am measuring are coming from an r/c receiver, which may protect me from noise somewhat.

Timmoore

This maybe better suited, it is for reading RC receiver signals. It originally came from someone else - sorry I have forgotten the name. I added using any start pin rather than pin 0 and I added a failsafe on 2nd pin since thats normally the throttle. if getstatus returns 0 the transmitter is off or out of range.

When I mentioned noise for the rpmsensor its because the sensor is tapping onto the brushless motor driving wires and counting the number of times the motor is driven a sec and dividing by the number of magnets the motor has. So any noise the ESCs have driving the motor, etc. get feed directly into the rpmsensor. I haven't had any problem with the RC receiver above even though they are close to the motor lines.

Greg Glenn

Thanks, Tim.

I notice that this requires the active input pins be within a contiguous block of 8 pins. Luckily, the four channels I use now are on pins 16, 19, 20 and 21, so I won't need to change my PCB, or the code.