Open dlkeng opened 1 year ago
Hi @dlkeng :coffee: :wave:
It looks like you've got some test program already. Could you please share it?
Cheers, Alex
Hi Alex,
The PWM_Test Arduino sketch can be downloaded from my Dropbox at the following link: https://www.dropbox.com/s/drrnjofrbacpwjl/PWM_Test.zip?dl=1
This program is command-line driven from the Pico's USB COM port. Enter "help" to show a list of available commands.
Dan
What are you compiling this sketch with? I've got the same 3.5.4 version that you claim to have:
arduino-cli core list | grep mbed_nano
arduino:mbed_nano 3.5.4 3.5.4 Arduino Mbed OS Nano Boards
Compiling via
arduino-cli compile -b arduino:mbed_nano:nanorp2040connect -v PWM_Test
ends with
/home/alex/projects/arduino/PWM_Test/PWM_Test.ino:35:2: error: #error "Missing Raspberry Pi Pico board definition!"
#error "Missing Raspberry Pi Pico board definition!"
^~~~~
Used platform Version Path
arduino:mbed_nano 3.5.4 /home/alex/.arduino15/packages/arduino/hardware/mbed_nano/3.5.4
This is because you are using the wrong #ifdefs, should be this instead:
-#ifdef ARDUINO_ARCH_MBED_RP2040
+#if defined(ARDUINO_ARCH_MBED_NANO) && defined(ARDUINO_NANO_RP2040_CONNECT)
Compiling for Raspberry Pi Pico fails with different errors
arduino-cli compile -b arduino:mbed:pico -v PWM_Test
...
PWM_Test/commands.ino:522:17: error: 'analogWriteFreq' was not declared in this scope
analogWriteFreq(duty);
^~~~~~~~~~~~~~~
PWM_Test/commands.ino:522:17: note: suggested alternative: 'analogWrite'
analogWriteFreq(duty);
^~~~~~~~~~~~~~~
analogWrite
PWM_Test/commands.ino:534:17: error: 'analogWriteRange' was not declared in this scope
analogWriteRange(duty);
^~~~~~~~~~~~~~~~
PWM_Test/commands.ino:534:17: note: suggested alternative: 'analogWrite'
analogWriteRange(duty);
^~~~~~~~~~~~~~~~
Please provide a working test sketch including a details description of which tooling you used how to compile it.
Alex,
I am compiling this on a Windows 10 Pro machine in the Arduino IDE Version 1.18.13 using "Arduino Mbed OS RP2040" V3.5.4.
The original supplied code included the #defines so that I could use the Pico or the Pico W and either the Arduino Mbed core or the Philhower Arduino-Pico core. I get no compiler errors. I don't use the CLI so maybe the GUI IDE is adding defines that the code was looking for.
However, to simplify things, I have changed the PWM_Test code to remove all of the #defines and associated #ifdefs to compile for the Arduino Mbed core, which is where the issues are occurring. You can get this version from my Dropbox at the following link: PWM_Test2
Also included in the download is the executable: PWM_Test2.ino.uf2 This can be copied to the Pico's file system with the BOOTSEL process in case you still have problems compiling in your environment.
Dan
The mystery has been uncovered. Apparently we (Arduino) are splitting the support for the RP2040 Pico into a separate deployed core arduino:mbed_rp2040
.
This is how to install/compile using arduino-cli
:
arduino-cli core update-index
arduino-cli core install arduino:mbed_rp2040
arduino-cli compile -b arduino:mbed_rp2040:pico -v PWM_Test2
Hi @dlkeng I believe I've fixed one of your issues (the one with PWM not working after configuring a GPIO), see #620 .
I'll attach an UTF2 file of your test application compiled with the new core here: can you please test it?
Alex,
Yes, I can confirm your attached UTF2 file appears to correct the operations of Issue 2 and Issue 3 of this problem report.
Dan
Thank you for the confirmation. I've got another file for you to test, this one should eliminate issue 1:
Edit: This is related to https://github.com/arduino/mbed-os/pull/30/files .
Alex,
Yes, I can confirm your latest UTF2 file fixes the Issue 1 of this problem report. All items now appear to be corrected.
Thanks, Dan
Thank you :wave: :rocket:
Hi, @aentinger I just came into same issue on Giga and looked into the library, I noticed that it is the not set status of digitalPinToGpio(pin)
and digitalPinToPwm(pin)
, which makes both the digitalWrite
and analogWrite
functions only change the output of that certain Mbed pin object but not the output method to the correct one. I just notice this pull request and wondering why it is still not merged into the main branch while it solved this issue more than a year ago?
Thanks for the help.
Arduino Mbed OS RP2040 for Raspberry Pi Pico - Version 3.5.4
In exploring the use of analogWrite() and digitalWrite() on the Raspberry Pi Pico using Arduino, I have discovered some strange behaviors when switching between those modes on the same GPIO pin.
Operational Issues:
Issue 1:
// always start from known state
// pin GP2 starts at 25% PWM output
// pin GP3 starts 50% PWM output, but GP2 stops it's PWM output
Work-around:// pin GP2 now restarts with 75% PWM output
This appears to be due to the setting of the companion pin causes the CC register counter compare value for the 1st pin to be set to 0. In the above example, reversing the order of the pins (i.e. GP3, then GP2) still shows the same problem. Once both pins are outputting a PWM signal, either one can be modified without affecting the other pin's output.Issue 2:
// always start from known state
// pin GP2 starts PWM output
// pin GP2 digital output high
// pin GP2 fails PWM output
Work-around:// re-activate pin GP2 PWM output
// change pin GP2 PWM output
// pin GP2 fails digital output, but remains PWM output
This appears to be due to not automatically changing the pin's function from PWM to SIO. Any subsequent changes to the pin's digital or analog output also requires changing the pin's mode manually.Issue 3:
// always start from known state
// pin GP2 digital output high
// pin GP2 starts PWM output
// pin GP2 fails digital output, but remains PWM output
Work-around:// pin GP2 digital output low
// change pin GP2 digital output high
// pin GP2 fails PWM output, but remains digital output
This appears to be due to not automatically changing the pin's function from SIO to PWM. Any subsequent changes to the pin's digital or analog output also requires changing the pin's mode manually.It was expected that the analogWrite() and digitalWrite() functions would always automatically take care of ensuring the correct function mode was set for the associated GPIO pin. Instead, it appears that this only the case on the first instance of using those functions for a GPIO pin.