The electronics work. If I move the red wire from a21 to a20, the LED lights up.
I cannot get pin D3 (GPIO15) to read the signal from a21 (the switch). I have tried moving to D4(GPIO 16) and D5 (GPIO 17) with no luck. This should be something really simple so I'm really stumped.
The code is below:
from machine import Pin
readpin=15
thepin=Pin(readpin,mode=Pin.IN,pull=Pin.PULL_DOWN)
while True:
print (thepin.value())
What am I missing?
(there are spaces in front of the print- it isn't showing up in the post).Preformatted text
@StefanL38 , Arduino sponsor micro python they just don't have a specific forum for it yet. "Programming Questions" seems like a good choice for the OP's topic, that would be a moderators decision, no matter what the Arduino forums are a valid place for the question.
I fixed my problem. WHY this is the fix eludes me. The code that works is:
from machine import Pin
readpin=15
thepin=Pin(readpin,mode=Pin.IN,pull=Pin.PULL_DOWN)
pinvalue=0
while True:
if not thepin.value()==pinvalue:
if thepin.value()==1:
print("pressed")
else:
print("not pressed")
pinvalue=thepin.value()
There's no particular reason. Because it was the only pin I cared about?
My solution code is clearly not optimized. It would be better to
while True:
if not thepin.value()==pinvalue:
pinvalue=thepin.value()
if pinvalue==1:
print("pressed")
else:
print("not pressed")
All I was trying to do was have the pin read an electrical signal. For some reason my original code failed and this code worked. The only thing I can think of is that for the RP2040 in Python, sending output up the serial bus (the print command) somehow interferes with the pin reading code. Reducing the number of prints seems to have solved the problem.
In my opinion this is a wild speculation that has no fundament
I have looked up some code-examples that read in a button
they look like this
from machine import Pin
import time
led = Pin(28, Pin.OUT)
button = Pin(14, Pin.IN, Pin.PULL_DOWN)
while True:
if button.value():
led.toggle()
time.sleep(0.5)
how about testing this code? exactly this code including IO-pin 14
Then change this code
a.) to do excessive serial.printing
b.) change to IO-pin 15 with toggling LED
c.) change to IO-pin 15 with serial printing
Help me understand your code.
Where is GPIO Pin 14 on the RP 2040?
Can I change pin 28 to pin 25? Because Pin 28 on the RP 2040 is an analog pin on the other side of the board necessitating that I rewire the board to what I see is no value?
Why is this code a valid test of excessive serial printing and where would the print commands go to test that? Why is a delay of 500 milliseconds (sleep(0.5)) relevant to the test?
If you want code to do lights turning on and off (what this code seems to want to do) based on a succession of button pushes, I've already done that- kind of moved on from this exercise.
from machine import Pin
readpin=15 #GPIO 15 is pin D3
LEDpin=25 #GPIO 25 is pin D2
lightstate=0
switchpin=Pin(readpin,mode=Pin.IN,pull=Pin.PULL_DOWN)
theLED=Pin(LEDpin,mode=Pin.OUT)
def buttonpressed(thepin): #The interrupt function
global lightstate #Each odd press of the button switches
if lightstate==0: #lightstate from 0 to 1
lightstate=1 #Each even press switches lightstate
else: #from 1 to 0
lightstate=0
switchpin.irq(trigger=Pin.IRQ_FALLING, handler=buttonpressed)
#This is the interrupt
while True: #continuously loop
if lightstate==0: #send current to the LED if lightstate is 1
theLED.off() #otherwise do not send current
else:
theLED.on()
However if you have the Arduino Nano RP2040 connect, it is all together a different matter. This is the data sheet for this. Nano Connect Data sheet
You will note that this board contains two processors the Raspberry Pi RP2040 and a dual core 32-bit Arm® Cortex®-M0+ to make Internet of Things projects with Bluetooth and WiFi connectivity thanks to the U-blox® Nina W102 module.
So you do not get native access to all the RP2040 pins. While this is summarised in the data sheet you need to look at the schematic to see what RP2040 pins are brought out to what pin numbers on the Connect. Nano RP2040 connect-schematics.pdf (584.5 KB)
In your case GPIO 14 is not brought out to the edge connectors, but is used as the SPI1 CLK input to the WI-FI chip. So you can't access this GPIO pin on the Nano Connect.
Note that the RP2040 only has four native A/D inputs and yet the Nano connect offers eight A/D inputs. These extra ones are derived from the WI-FI chip and is why GPIO 14 ( amongst others) on the RP2040, is used internally and not available for you.
Do not think the Nano Connect is simply a RP2040 and a separate Arm® Cortex®-M0+ it is not and should not be treated as such. I think that is where you are going wrong with your code.
Yes I have an Arduino Nano RP2040 Connect (it is featured in the screenshot of the original post). Apologies for the imprecise language. I was asking the question since the recommendation I was replying to specifically asked me to test pin 14 with a pushbutton, which as you note can't be done.
Do not think the Nano Connect is simply a RP2040 and a separate Arm® Cortex®-M0+ it is not and should not be treated as such. I think that is where you are going wrong with your code.
What does this have to do with the code I demonstrated to work and the code I demonstrated did not work?
To recall, the code that does not work basically looks like this:
while True:
print (thepin.value())
The code that works looks like this:
while True:
if not thepin.value()==pinvalue:
if thepin.value()==1:
print("pressed")
else:
print("not pressed")
pinvalue=thepin.value()
A bit of a guess, but the first code prints on every loop whereas the second only on a button press or release. The first would quickly fill up the print buffer and serial output would lag some amount of time from when the button is pushed.
Maybe it is working, but the serial out response isn't close to immediate so it looks "unresponsive"?
I suspect you are right. This is very different interpreter(?) behavior from doing the equivalent in Arduino C++ with (for example) a MKR 1000 over the serial monitor. I'm used to being able to track data stream behavior. Not being able to do that requires some rethinking.
For anyone asking, "So why not use C++?" the answer is the Arduino Nano RP2040 Connect includes a microphone. Eventually I want to try experimenting with speech to text on this board, and that is going to be much easier done with Python. For now, I'm running through a bunch of exercises with standard sensors, the WiFi, etc. to understand the board and I am learning doing these standard exercises in Python doesn't just require using new syntax, but also a different way of thinking about the same problems.
It doesn't help that Python for the Arduino Nano RP2040 Connect (sorry that is such a mouthful) is incredibly poorly documented.
For what it's worth, I tried the first code example on an ESP32 NodeMCU board (MicroPython v1.19.1) and see a lag of around 30 seconds between switching the button and seeing the output change, so I think the print buffer hypothesis makes sense. If I add a "time.sleep(0.1)" to slow the print loop down enough that the serial port can get data out of the serial buffer as fast as the processor wants to put it in, the terminal log looks more like one would expect.
Grumpy_Mike isn't wrong about Python being slower than C/C++ but the MicroPython implementation for ARM processors includes a capability to compile code segment to machine code for improved performance. This is explained in posts here and here.
If it were my project, I'd work through the algorithms on a PC in Python first, even if I knew the final microcontroller implementation would be C/C++.
@MrMark
Thank you for taking the effort.
I presume the work through algorithms bit is in reference to Grumpy_Mike as I am obviously coding this in Python.
Beyond what MrMark is saying (there are ways to improve Python speed performance at production), you are assuming the "huge factor" (noticeably vague term, but I will assume this is machine level versus human experience level) in speed is relevant to the user requirement. In many cases, this difference in speed is not something we care about. There are all kinds of reasons for this. One simple reason is an IoT device is often part of a system, and the speed of a specific IoT prototype may not be on the critical path of the experimental system. Also, there might be a desire to get the experimental system to a working stage where the actual time to finish the system process is less important than showing the system process CAN work NOW. We need to monitor content in a lake, because we know some event is going to happen soon, but the actual analysis of the data is going to be in a couple of months. Our data stream capture doesn't have to be at the microsecond level. That's a scenario calling for a quickly developed, accurate prototype that doesn't have to be fast.
Furthermore, I am finding my first run Micropython code often runs FASTER than my first run C++ code simply because there's less overhead fiddly bits I am writing inefficiently. Now, as I refactor my Micropython and C++ code, the C++ code becomes much faster. I've been experimenting with WiFi connections. My first run C++ sockets are ridiculously fragile, and slow. My first run Python ones work and because I need to code little overhead and my first run code is clunky, it runs smoothly.
I would also highlight that if speed was always an overriding concern, we'd reject C++ in favor of chip-specific assembler.
Note I am not trying to shill for Python. I code in a variety of languages. I cannot categorically state the speech to text I intend to do with Python will end up not having a performance issue. But, I have done speech to text with Python at the PC/Raspberry Pi Model 3 level and have not (for my purposes) had a performance issue.
No my experiments with outputting a wave sample data using Micro Python on an PR2040, was limited to about 800 samples per second. Nowhere good enough for speech.
Still it is your project and I am only offering advice from my own personal experiments.
Good luck with this. I will not reply to this link again.
