I was trying to follow along with this demo: Now the Arduino can send connections to the Jumperless over UART
but nothing was working … upon investigation, it seems Rev 3 does not tie the D0+D1 UART to the RP2040 via jumpers. Instead UART_Tx and UART_Rx nets from the RP2040 go into the crosspoint switches. If this is the case, is it no longer possible to have a nano board wire the Jumperless itself without custom firmware?
Hey James,
It should be able to do this, but I’ve written a lot of firmware since then and may have broke that feature without noticing.
The jumpers from that other post were just current limiting resistors that were a bit too high of a value to let a 3.3V part talk to a 5V part. If you got your Jumperless anytime in 2024, those will already be replaced with 0 ohm resistors from the factory. So you shouldn’t have to worry about that.
And yes, the UART lines and D0/D1 all go into the crosspoint switches, so when you control the Jumperless over UART, you have to tell it to also make the connections to UART by including
116-70, 117-71,
with the other connections you send.
Let me take a look and see what I did and hopefully get that fixed tonight or tomorrow.
Oh okay, it does actually still work, but the instructions are outdated.
Here’s how you do that now:
Some general info:
First off, I took out the firmware to flash the Nano from a single USB cable, so to flash the Nano, you’ll just need to plug it in with a second cable.
And when the Jumperless has the UART lines hooked up to the RP2040, it won’t be able to flash even from a second cable. The easy way to disconnect everything for flashing is to just send an ‘f’ in the menu.
Here’s what you do:
This is the test sketch for the Nano
void setup() {
pinMode(LED_BUILTIN, OUTPUT);
delay(3500);
Serial.begin(115200);
delay(1500);
}
int count = 1;
void loop() {
digitalWrite(LED_BUILTIN, HIGH);
delay(250); //if it sends commands too fast, the Jumperless can drop connections
digitalWrite(LED_BUILTIN, LOW);
delay(30);
Serial.write("f 1-");
Serial.print(count);
Serial.write(", "); //these 2 connections reconnect the UART lines so it's ready to send the next connection
count++;
if (count >= 60) {
count = 3;
}
}
Load that onto your Nano, it’s fine if it’s plugged into the Jumperless while you flash it, just send ‘f’ before you hit Upload to clear the UART connections.
So the Arduino should be flashing its LEDs showing that it’s sending stuff, but the Jumperless doesn’t know that it’s trying to send it commands because their UART lines aren’t connected to each other.
You’ll first need to tell the Jumperless the baud rate. So in the Menu, enter
u 115200
Now we should tell the Jumperless to hook up the UART lines so it can receive commands by sending (case insensitive)
f uart_tx-D0, uart_tx-D1,
or you can use the numbered defines to do the exact same thing
f 116-70, 117-71,
These are the numbered defines for the special functions if you want to save a super tiny bit of UART traffic
And if everything goes well, your Jumperless should look like this:
Tried again tonight and I was able to get it working. I moved on to a related setup and found a bit of a hiccup.
I’m using the following node file command to establish the connection to a peripheral:
f 3V3-1,D6-2,D5-3,D4-4,D7-5,GND-6,UART_TX-D0,UART_RX-D1,
I’ve found the ground connection doesn’t go through. If I permute the order of connections, whatever is beyond the 5th one only works about 1 in 10-20 times (resetting the MCU which sends this sequence at init time).
The code in savePreformattedNodeFile looks it has some timing dependencies that make it fragile. What is the serial RX buffer length in this implementation? At 115200 bps, a 10-bit symbol including start/stop bits takes 87 µs, so delaying 800 µs per read means 9 characters are buffered for every one that is read. I’m wondering if this is the cause of the flakiness I’m seeing.
If I wanted to bootstrap the UART connection, do I need to make my own firmware build? I’d like to have it wire the breadboard completely on its own once the power is connected.
That may actually be it, or at least some sort of timing issue like that. Especially because it reads in UART from the second core (on a much tighter loop) and then handles it on the first core, it might just need a “wait until it’s finished reading in data before handling it” kinda thing. Maybe if I put in some end sequence this would be less timing-dependent.
I didn’t spend that much time getting this feature to be rock-solid, so maybe I’ll take another look at it.
Or you can play around with the code and submit a PR. Let me know if you need any help getting that set up.
Also, possibly related but probably not,
This doesn’t look like it’s the cause of the issue, but scoot whatever you’re connecting one row over on the breadboard, row 1 (and the other 3 corners) can have issues with 3V3 and GND with other stuff connected.
f 3V3-2,D6-3,D5-4,D4-5,D7-6,GND-7,UART_TX-D0,UART_RX-D1,