Limits on CYCLE_TIME_US vs. SAMPLE_US? #5

Open
beli-sk opened this Issue May 5, 2013 · 4 comments

Comments

Projects
None yet
4 participants
@beli-sk

beli-sk commented May 5, 2013

As I played with modifying CYCLE_TIME_US and SAMPLE_US defines in the code, I couldn't get it working with pretty much anything that doesn't equal to exactly 1000 samples per cycle.
For example I got it working with CYCLE_TIME_US=2000 and SAMPLE_US=2, but I kept getting kernel OOPSes with CYCLE_TIME_US=1000 and SAMPLE_US=10 which should be 100 samples per cycle. I didn't find any set of working values equivalent to anything other than 1000 samples per cycle.
Are there any known limits on the values of CYCLE_TIME_US and SAMPLE_US apart from getting SAMPLE_US too low?
I'd need to lower the period below 1000ms and a resolution of 100 samples per cycle would be sufficient.
Thanks for any hints.

@sarfata

This comment has been minimized.

Show comment
Hide comment
@sarfata

sarfata May 7, 2013

Owner

Hi, Thanks for the feedback. I got a very similar problem reported on the blog:

  1. I changed "#define CYCLE_TIME_US 10000" to "#define CYCLE_TIME_US 5000". As expected, when pi-blaster starts it indicates PWM freq=200Hz, PWM steps=500, but it doesn't work.

There is probably something weird going on here. I need to take a deeper look. Thanks for opening an issue!

Owner

sarfata commented May 7, 2013

Hi, Thanks for the feedback. I got a very similar problem reported on the blog:

  1. I changed "#define CYCLE_TIME_US 10000" to "#define CYCLE_TIME_US 5000". As expected, when pi-blaster starts it indicates PWM freq=200Hz, PWM steps=500, but it doesn't work.

There is probably something weird going on here. I need to take a deeper look. Thanks for opening an issue!

sarfata pushed a commit that referenced this issue Nov 14, 2013

@christf

This comment has been minimized.

Show comment
Hide comment
@christf

christf Jan 12, 2016

I am seeing the same behavior: Frequency is reported but setting echo "17=1" does not cause the connected LED to light up. I changed CYCLE_TIME_US=2000 and SAMPLE_US=2

when the default settings are applied (10000 and 10 respectively) it works

christf commented Jan 12, 2016

I am seeing the same behavior: Frequency is reported but setting echo "17=1" does not cause the connected LED to light up. I changed CYCLE_TIME_US=2000 and SAMPLE_US=2

when the default settings are applied (10000 and 10 respectively) it works

@benkrall

This comment has been minimized.

Show comment
Hide comment
@benkrall

benkrall Mar 11, 2016

This also happens to my system, using a RPi B+

The output only seems to work when the CYCLE_TIME_US / SAMPLE_US == 1000

I am not sure how to investigate why but it means I cannot actually set the PWM frequency unless there are 1000 steps to sample.

This also happens to my system, using a RPi B+

The output only seems to work when the CYCLE_TIME_US / SAMPLE_US == 1000

I am not sure how to investigate why but it means I cannot actually set the PWM frequency unless there are 1000 steps to sample.

@benkrall

This comment has been minimized.

Show comment
Hide comment
@benkrall

benkrall Mar 11, 2016

If it's expecting 1000 integer samples can I just go in there and put in some code that will interpret the frequency into 1000 steps even if some of those steps don't change the duty cycle due to the timing granularity?

I am struggling to figure out where this would even happen in the pi-blaster code...

If it's expecting 1000 integer samples can I just go in there and put in some code that will interpret the frequency into 1000 steps even if some of those steps don't change the duty cycle due to the timing granularity?

I am struggling to figure out where this would even happen in the pi-blaster code...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment