Go Down

Topic: Multi-channel High Frequency PWM with registers and phase shift capabilities (Read 11225 times) previous topic - next topic

tonytt98

Greetings...

Would like a multi-channel (4 or more) square wave generator with phase shift capabilities in each channel in an Arduino Due Library that would work along side with a IC2 20x4 LCD, buttons and rotary encoders. Capable of hz up to hi frequency mhz. Not worried to much about accuracy or jitters while adjusting frequency of these channels via buttons and rotary encoders.

Is this possible and what kind of high frequencies could I achieve within these 4 channels?

Thanks,
Tony

antodom

Hi there @tonytt98,

Have a look to pwm_lib available at:

 https://github.com/antodom/pwm_lib

The library provides two kind of objects associated with each PWM channel: pwm and servo objects. As those objects abstract the PWM channels available on the micro controller, using pwm_lib you can use, at most, eight independent pwm_lib objects in your application, each one with its own PWM characteristics (PWM signal period and pulse duration). In its current version, the maximum period for PWM signals you can get using pwm_lib is a period of 0.798915048 seconds (minimum frequency of 1.251697539 Hz). The maximum frequency you can get is the one provided by the hardware. I see no problems even to get to 1 Mhz but in this case the resolution of the duty will be limited to 84 clock ticks, at 2 Mhz 42 ticks, etc.

Have a look to the examples which come with pwm_lib.

I hope it helps.
------------
antodom

HermannSW

Hi antodom,

today I installed your tc_lib the first time and played with your action_test sample and reduced it successfully to the absolute minimum:
https://twitter.com/HermannSW/status/753885871305322496

Then I wanted to try pwm_capture_test, but got a compile error on missing pwm_lib. So I downloaded and installed pwm_lib, stopped and started Arduino IDE (1.6.4) and got another compile error.

Next I tried  Examples > pwm_lib > basic_test  demo and got same compile error:
Code: [Select]

basic_test:41: error: variable or field 'change_duty' declared void
basic_test:41: error: 'pwm_type' was not declared in this scope
basic_test:41: error: 'pwm_obj' was not declared in this scope
basic_test:42: error: expected primary-expression before 'pwm_duty'
basic_test:43: error: expected primary-expression before 'pwm_period'
variable or field 'change_duty' declared void


So it seems to be a problem of pwm_lib, should pwm_lib work with 1.6.4 IDE?
(I checked my platform.txt, and "-std=gnu11" is in place.

Hermann.
αβ, xy & L₁/L₂ positioning systems w/ 2 28BYJ48 steppers:
https://forum.arduino.cc/index.php?topic=649769.0
Caterpillar robots:
https://forum.arduino.cc/index.php?topic=462107.msg3482895#msg3482895
https://stamm-wilbrandt.de/en/Raspberry_camera.html

antodom

Hi there @HermannSW,

This is a weird problem that I fixed in my last commit to pwm_lib, related to how the IDE generates the final .cpp files out of the .ino files. Specifically when it generates function prototypes declarations from functions found in .ino files. Here it happens to be a problem with C++ function templates, which is the case with pwm_lib.

Are you using the last version of pwm_lib?. If not, download or git pull the project again. The problem should be solved this way. If you have the last version, and it does not compile, that's another thing, and I will need more info to have a deeper look. I have installed here arduino-1.6.7 (Ubuntu trusty 14.04.4) and it compiles correctly.

By the way, the standard C++ flag is "-std=gnu++11", no "-std=gnu11".

I hope it helps.
------------
antodom

HermannSW

Hi antodom,

I just downloaded pwm_lib .zip file from github again and verified that I did use the latest library.

Here is cpp.flags line from my platform text:
Code: [Select]
$ grep cpp.flags .arduino15/packages/arduino/hardware/sam/1.6.8/platform.txt
compiler.cpp.flags=-c -g -O3 {compiler.warning_flags} -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -MMD
recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} -mcpu={build.mcu} -mthumb -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} {compiler.libsam.c.flags} {includes} "{source_file}" -o "{object_file}"
$


I am using 1.6.4 IDE because I read and experienced myself that 1.6.5 and 1.6.6 are worse. Can you please try with 1.6.4 IDE? (I have installed several IDEs concurrently)

Hermann,
αβ, xy & L₁/L₂ positioning systems w/ 2 28BYJ48 steppers:
https://forum.arduino.cc/index.php?topic=649769.0
Caterpillar robots:
https://forum.arduino.cc/index.php?topic=462107.msg3482895#msg3482895
https://stamm-wilbrandt.de/en/Raspberry_camera.html

antodom

Hi again Hermann,

You were right, in Arduino IDE 1.6.4 the thing did not compile. Now it works, I have made a fix for both libraries, tc_lib and pwm_lib. Update both with their last versions and check if everything compiles correctly, and please tell me :)

Best.

------------
antodom

HermannSW

Hi antodom,

thanks that you fixed the issues.

Now both, pwm_lib basic_test as well as tc_lib pwm_capture_test, do compile and run.

Two comments in pwm_capture_test seem to be wrong:
Code: [Select]
#define PWM_PERIOD_PIN_35 500 // tenths of usecs (1e-8 secs)
#define PWM_DUTY_PIN_35 50 // tenths of usecs (1e-8 secs)


Based on the reported runtime results I would say that 1e-8 is correct, but it should be "hundredth".

Anyway, I never was able to get any run without overrun+stopped, even with 5ms period (period=500000/duty=250000):
Code: [Select]
=======================================================================
[PIN 35 -> PIN 2] duty: 0.000 usecs. period: 0.000 usecs. [overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 2500.000 usecs. period: 5000.000 usecs. [overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 0.000 usecs. period: 0.000 usecs. [overrun][stopped]
=======================================================================
...


What is needed to get a valid period reported for each measurement?

Hermann.

P.S:
I asked my oszilloscope for delay=50000 with duty=5000, the scope confirms below output, and confirms 1e-8 (50000 is 500us). Not sure why the duty is increasing and loops then:


Code: [Select]
=======================================================================
[PIN 35 -> PIN 2] duty: 50.000 usecs. period: 500.000 usecs. [overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 100.000 usecs. period: 500.000 usecs. [overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 149.976 usecs. period: 500.000 usecs. [overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 200.000 usecs. period: 500.000 usecs. [overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 250.000 usecs. period: 500.000 usecs. [overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 299.976 usecs. period: 500.000 usecs. [overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 350.000 usecs. period: 500.000 usecs. [overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 400.000 usecs. period: 500.000 usecs. [overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 450.000 usecs. period: 500.000 usecs. [overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 0.000 usecs. period: 0.000 usecs. [overrun][stopped]
=======================================================================
αβ, xy & L₁/L₂ positioning systems w/ 2 28BYJ48 steppers:
https://forum.arduino.cc/index.php?topic=649769.0
Caterpillar robots:
https://forum.arduino.cc/index.php?topic=462107.msg3482895#msg3482895
https://stamm-wilbrandt.de/en/Raspberry_camera.html

antodom

Hi again Hermann,

Thanks for the feedback :)

You are completely right with the hundredths, I have already fixed the error on comments, in both tc_lib and pwm_lib.

As to the overruns, they do happen even at 5 msecs. periods, it is what the hardwares says. But even in that situation you can measure correctly the frequency and period. When period and duty are zero, that means that the capture object was not able to measure correctly any of them.

Well, to try to avoid the overrun status when you create the capture object you can provide a maximum number of overruns before stop capturing until you call member function restart(), get_duty_and_period() or get_duty_period_and_pulses().

When you have fast signals, this freezes the CPU, this is why when there are many overruns the capture object stops. You only need several periods correctly captured to measure duty and period rightly. With the pulses unfortunately is another story, you will lose many.

Capture objects' member function config() has a second parameter with by default is 100 (the capture is stopped when 100 overruns are detected), you can provide with this second parameter a greater value if you do not want the capture object to be stopped. 100 is a good value according to my experience.

As to the example if you have a look to template function change_duty() (it is in a #define because of the fix for compiling basic_test.ino), there, the duty of the pwm is changed modularly, this is why you observe the duty changing and looping in the oscilloscope. This behavior is what the example pretends.

I hope it helps.




------------
antodom

HermannSW

Hi antodom,

thanks for the explanations.

I don't know what I am more happy to see, being able to measure 6MHz frequency with your "tc_lib/examples/capture_test" sketch, or being able to generate 6MHz(!) with a simple "blink" program on the Raspberry Pi Zero.

OK, let me describe step by step.

Yesterday I did buy Kolban's book on Raspberry Pi although you can just download it for free, and it is really worth the money, I will dig especially into chapter "Arduino programming for the Pi" soon, which will just compile all Arduino Sketches and libs for Raspberry Pi by the RasPiArduino project on Github:
https://twitter.com/HermannSW/status/756225040169988096

Yesterday I learned that wiringPi library allows to program GPIO pins very similar to Arduino:
https://twitter.com/HermannSW/status/756244206251835392

This is the main loop of "wiringPi/examples/blink.c" example generating 1KHz:
Code: [Select]
for (;;)
  {
    digitalWrite (LED, HIGH) ; // On
    delay (500) ; // mS
    digitalWrite (LED, LOW) ; // Off
    delay (500) ;
  }


And this is what what "tc_lib/examples/capture_test" says about it:
Code: [Select]
========================================================
ticks per usec: 42
max capture window: 102261126 usecs.
========================================================
...
...
********************************************************
--> [PIN 7 -> PIN 2] duty: 0.000 usecs. period: 0.000 usecs.
********************************************************
--> [PIN 7 -> PIN 2] duty: 500115.976 usecs. period: 1000233.000 usecs.
********************************************************
--> [PIN 7 -> PIN 2] duty: 500115.976 usecs. period: 1000233.000 usecs.
********************************************************
--> [PIN 7 -> PIN 2] duty: 500115.976 usecs. period: 1000233.000 usecs.
...



This is how Raspberry Pi Zero and Arduino Due are connected (GND--GND and GPIO17--D2, both have 3.3V limit on pins):


Next I realized that wiringPi lib, like Arduino Due, has delayMicroseconds() command:
https://twitter.com/HermannSW/status/756251151612387328


This little diff generated a frequency of 24KHz:
Code: [Select]
$ diff examples/blink.c blink.c
43c43
<     delay (500) ; // mS
---
>     delayMicroseconds (20) ;// uS
45c45
<     delay (500) ;
---
>     delayMicroseconds (20) ;// uS
$


This is "tc_lib/examples/capture_test" output:
Code: [Select]
...
********************************************************
--> [PIN 7 -> PIN 2] duty: 21.238 usecs. period: 42.214 usecs.
********************************************************
--> [PIN 7 -> PIN 2] duty: 20.714 usecs. period: 41.714 usecs.
********************************************************
--> [PIN 7 -> PIN 2] duty: 21.024 usecs. period: 42.000 usecs.
********************************************************
--> [PIN 7 -> PIN 2] duty: 21.024 usecs. period: 42.000 usecs.
********************************************************
--> [PIN 7 -> PIN 2] duty: 20.714 usecs. period: 41.714 usecs.
...


Finally I commented out the delayMicrosecond() calls, and that resulted in a 6MHz frequency by this nearly trivial "blink.2.c":
Code: [Select]
#include <stdio.h>
#include <wiringPi.h>

// LED Pin - wiringPi pin 0 is BCM_GPIO 17.

#define LED 0

int main (void)
{
  printf ("Raspberry Pi blink\n") ;

  wiringPiSetup () ;
  pinMode (LED, OUTPUT) ;

  for (;;)
  {
    digitalWrite (LED, HIGH) ; // On
//  delayMicroseconds (20) ;// uS
    digitalWrite (LED, LOW) ; // Off
//  delayMicroseconds (20) ;// uS
  }
  return 0 ;
}


This is "tc_lib/examples/capture_test" output, very stable:
Code: [Select]
...
********************************************************
--> [PIN 7 -> PIN 2] duty: 0.095 usecs. period: 0.167 usecs.
********************************************************
--> [PIN 7 -> PIN 2] duty: 0.095 usecs. period: 0.167 usecs.
********************************************************
--> [PIN 7 -> PIN 2] duty: 0.095 usecs. period: 0.167 usecs.
...



Summary:
  • tc_lib has no problems capturing >1MHz frequencies
  • connecting Raspberry Pi Zero and Arduino Due is easy
  • Raspberry Pi Zero with wiringPi library is cool and much "Arduino like"
  • next step: "Arduino programming for the Pi"


Hermann.
αβ, xy & L₁/L₂ positioning systems w/ 2 28BYJ48 steppers:
https://forum.arduino.cc/index.php?topic=649769.0
Caterpillar robots:
https://forum.arduino.cc/index.php?topic=462107.msg3482895#msg3482895
https://stamm-wilbrandt.de/en/Raspberry_camera.html

HermannSW

Before "next step" I investigated how fast I could make digitalWrite().
Like on Arduino Due this should be possible by looking up the source code and doing GPIO writes directly.


And it was possible, a bit bumpy, and this code should only be used on a Raspberry Pi Zero, and only if you really really need to speed up digitalWrite():
Code: [Select]
#include <stdio.h>
#include <wiringPi.h>

// only for Raspberry Pi Zero, and only for GPIOxy, 00<=xy<=31
//
volatile unsigned int *GPSET=NULL, *GPCLR=NULL;
unsigned int GPIO17 = 1<<17;

// LED Pin - wiringPi pin 0 is BCM_GPIO 17.

#define LED 0

int main (void)
{
  printf ("Raspberry Pi blink\n") ;

  wiringPiSetup () ;
  GPSET = getGpio()+7;
  GPCLR = getGpio()+10;

  pinMode (LED, OUTPUT) ;

  for (;;)
  {
    *GPSET = GPIO17;
    *GPCLR = GPIO17;
  }
  return 0 ;
}


I did compile this source with -O6 to get the maximum on Raspberry Pi Zero:
Code: [Select]
pi@raspberrypi:~/wiringPI-b0a60c3 $ gcc -O6 fast.c -o fast -L/usr/local/lib -lwiringPi

getGpio() is not available in wiringPi library, so I had add it:
Code: [Select]
pi@raspberrypi:~ $ diff wiringPi-b0a60c3.orig/wiringPi/wiringPi.h wiringPi-b0a60c3/wiringPi/wiringPi.h
100a101
> extern volatile unsigned int *getGpio(void);
pi@raspberrypi:~ $
pi@raspberrypi:~ $ diff wiringPi-b0a60c3.orig/wiringPi/wiringPi.c wiringPi-b0a60c3/wiringPi/wiringPi.c
1480a1481
> volatile unsigned int *getGpio(void) { return gpio; }
pi@raspberrypi:~ $



I did use the same setup as in previous posting, and took a sample of 2760 tc_lib measurements.
  • 1482 times "period: 0.024 usecs" got reported, which corresponds to 41.66MHz.
  • 1278 times "period: 0.048 usecs" got reported, which corresponds to 20.83MHz.


On average this corresponds to  1/((1482*0.024+1278*0.048)/2760) = 28.48MHz.


So I think the Raspberry Pi Zero generated frequency 28MHz(!), and Arduino Due did measure that (on average) -- really impressive!

Hermann.
αβ, xy & L₁/L₂ positioning systems w/ 2 28BYJ48 steppers:
https://forum.arduino.cc/index.php?topic=649769.0
Caterpillar robots:
https://forum.arduino.cc/index.php?topic=462107.msg3482895#msg3482895
https://stamm-wilbrandt.de/en/Raspberry_camera.html

antodom

Hi again Hermann,

Thanks a lot for all the testing you have done with tc_lib.

Only one comment in relation to your last testing for measuring how fast you can generate a digital signal on the Pi Zero, and specifically the conclusions. From my experience, I think that the real frequency was 41.66 Mhz at least, the other measurements result from not detecting the pulse falling edge, and getting the next one which belongs to the following pulse. That is why it measures half that frequency. A oscilloscope will clarify things here, but I would say that this frequency is too fast for capturing all pulses, using the DUE.

Best.



------------
antodom

HermannSW

Hi antodom,

I wanted to know the frequency, but my 30$ oscilloscope is too slow for that.

But things can be clarified in software, and I can now confirm 26.21MHz.

This is modified fast.2.c to measure 1 million loops and determine overhead of the 1 million loops:
Code: [Select]
#include <stdio.h>
#include <wiringPi.h>
#include <sys/time.h>

// only for Raspberry Pi Zero, and only for GPIOxy, 00<=xy<=31
//
volatile unsigned int *GPSET=NULL, *GPCLR=NULL;
unsigned int GPIO17 = 1<<17;

// LED Pin - wiringPi pin 0 is BCM_GPIO 17.

#define LED 0

#define N 1000000  // deterne runtimes for 1 million loops

int main (void)
{
  struct timeval tv0,tv1,tv2;
  int i;

  wiringPiSetup () ;
  GPSET = getGpio()+7;
  GPCLR = getGpio()+10;

  pinMode (LED, OUTPUT) ;

  gettimeofday(&tv0, NULL);
  for(i=0; i<N; ++i)
  {
    *GPSET = GPIO17;
    *GPCLR = GPIO17;
  }
  gettimeofday(&tv1, NULL);
  for(i=0; i<N; ++i)
  {
  }
  gettimeofday(&tv2, NULL);

  printf("\n%ldus\n",
    1000000*(tv1.tv_sec-tv0.tv_sec)+tv1.tv_usec-tv0.tv_usec);

  printf("\n%ldus\n",
    1000000*(tv2.tv_sec-tv1.tv_sec)+tv2.tv_usec-tv1.tv_usec);

  return 0 ;
}


This is compile and run:
Code: [Select]
pi@raspberrypi01:~/wiringPi-b0a60c3 $ gcc -O6 fast.2.c -o fast.2 -lwiringPi -L/usr/local/lib/
pi@raspberrypi01:~/wiringPi-b0a60c3 $ sudo ./fast.2

38152us

1us
pi@raspberrypi01:~/wiringPi-b0a60c3 $ sudo ./fast.2

38155us

2us
pi@raspberrypi01:~/wiringPi-b0a60c3 $



Overhead of 1 million loops is just 1us, so this gives the MHZ generated:
Code: [Select]
$ bc -lq
1/((38152-1)/1000000)
26.21163272260229089669



The nice thing with this measurement is that it confirms tc_lib's averaged measurement!

The difference to 28MHz seems to come from rounding errors, 0.0024us should be 42MHz and not 41.66MHz.


Perhaps you may want to add that as new functionality to tc_lib for more precise measurement of frequencies between 1MHz and 42 MHz? Getting averaged frequency (and duty) not only for the last measurement, but for a specified number of measurenents (eg. 1000). Perhaps that feature is already available in tc_lib?


Hermann.
αβ, xy & L₁/L₂ positioning systems w/ 2 28BYJ48 steppers:
https://forum.arduino.cc/index.php?topic=649769.0
Caterpillar robots:
https://forum.arduino.cc/index.php?topic=462107.msg3482895#msg3482895
https://stamm-wilbrandt.de/en/Raspberry_camera.html

antodom

Hi again Hermann,

You are right estimating the frequency of the signal generated with the Pi using the average, specially if the signal has no constant frequency and period. But to know really until which frequency is possible to use the DUE (the ATSAM3X8E), and in turn, tc_lib, would be interesting to try to feed it with a PWM constant signal. Wouldn't that be possible using the Pi?.

In relation to provide tc_lib with the ability to measure average frequencies and periods, it is easy to do it using tc_lib as it is, you only have to accumulate the readings of periods and frequencies in an array. The thing is tc_lib was devised to measure pulse duration (duty) and period of digital signals, not necessarily constant, in an instantaneous way. In this manner you can measure instantaneous velocities of rotary axes of motors, etc.

Best.
------------
antodom

HermannSW

Hi,

Quote
... The PWM device on the RPi is clocked at a fied base-clock of 19.2MHz ...
https://books.google.de/books?id=iftUDAAAQBAJ&pg=PA263&lpg=PA263&dq=raspberry+pwm+19.2+MHz&source=bl&ots=6NHyRsjhd7&sig=Ju0dUDcEpChI
yso8iwZ6I38fYwA&hl=de&sa=X&ved=0ahUKEwjh7c79iZzOAhVGMBoKHWW0CLUQ6AEISTAF#v=onepage&q=raspberry%20pwm%2019.2%20MHz&f=false


So PWM on RPi can generate a maximum of 19.2MHZ, much less than the 26MHz the simple RPi program was able to generate.


>  But to know really until which frequency is possible to use the DUE (the ATSAM3X8E), and in turn, tc_lib, would be interesting to try to feed it with a PWM constant signal.
>
Perhaps someone reading this has a PWM generator that can generate up to 42MHz frequency? If so, can you please try whether tc_lib is able to determine say 38MHz on average as described above?

Hermann.
αβ, xy & L₁/L₂ positioning systems w/ 2 28BYJ48 steppers:
https://forum.arduino.cc/index.php?topic=649769.0
Caterpillar robots:
https://forum.arduino.cc/index.php?topic=462107.msg3482895#msg3482895
https://stamm-wilbrandt.de/en/Raspberry_camera.html

HermannSW

Hi antodom,

I looked into Rasperry Pi Zero PWM more closely now and did test your pwm_capture_test. PWM0 is on GPIO pin 18, so I connected that to Due D2, and GND to GND.

The formula for Raspberry Pi Zero PWM frequency is "19.2MHz / pwmClock / pwmRange".

As a first test I started with 10KHz because that is what I can verify with my small USB oscilloscope.
These are the Pi Zero GPIO commands:
Code: [Select]
pi@raspberrypi01:~ $ gpio -g mode 18 pwm
pi@raspberrypi01:~ $ gpio -g pwm-ms
pi@raspberrypi01:~ $ gpio -g pwmc 960
pi@raspberrypi01:~ $ gpio -g pwmr 2
pi@raspberrypi01:~ $ gpio -g pwm 18 1
pi@raspberrypi01:~ $
pi@raspberrypi01:~ $ bc -lq
19200000/960/2
10000.00000000000000000000


And here is photo of oscilloscope verifying the 10KHz:


I added the output of period in ticks and ticks per us to your programs output line.
For pwmc=48 (corresponds to 19.2/48/2=200KHz) this is the line from pwm_capture_test, and 210 ticks @42MHz are exactly 5us:
Code: [Select]
[PIN 35 -> PIN 2] duty: 2.500 usecs. period: 5.000 usecs. period2: 210.00 ticks: 42.00[overrun][stopped]


Since 6 is a divisor of 210 I tried pwmc=8 next (corresponds to 19.2/8/2=1.2MHz) and period2=35 matches that:
Code: [Select]
[PIN 35 -> PIN 2] duty: 0.405 usecs. period: 0.833 usecs. period2: 35.00 ticks: 42.00[overrun][stopped]


Finally I set pwmc=2 (corresponds to 19.2/2/2=4.8MHz) and the output are lines with period2 being 8 or 9. From 17 samples 4 were 8, and the average measured frequency is 1/((13*9+4*8 )/17/42) = 4.79MHz!
Code: [Select]
[PIN 35 -> PIN 2] duty: 0.071 usecs. period: 0.190 usecs. period2: 8.00 ticks: 42.00[overrun][stopped]
=======================================================================
=======================================================================
[PIN 35 -> PIN 2] duty: 0.119 usecs. period: 0.214 usecs. period2: 9.00 ticks: 42.00[overrun][stopped]



For some reason setting clock divider to 1 does not work with pwm_capture_test. So either 19.2/1/2=9.6MHz is a tainted frequency for pwm_capture_test, or the Pi Zero PWM documentation is wrong wrt pwmc=1 being allowed.

Hermann.
αβ, xy & L₁/L₂ positioning systems w/ 2 28BYJ48 steppers:
https://forum.arduino.cc/index.php?topic=649769.0
Caterpillar robots:
https://forum.arduino.cc/index.php?topic=462107.msg3482895#msg3482895
https://stamm-wilbrandt.de/en/Raspberry_camera.html

Go Up