Train Departure Board (v2)

Posted <2025-01-02 Thu 15:15> by Aaron S. Jackson.

Back in March I wrote about getting the train departure board at Nottingham Hackspace displaying messages. The messages are mainly from Discord but periodically reverts to a "normal" train departure board for a minute or so. With that circuit, I had intended to be able to drive both sides of the display, but it did not work like that, likely due to reflections on the long(ish) ribbon cables. So I decided to do a version two!

The new board uses 74HC541D buffers (one per side), which also perform level shifting up to 5V (which the display prefers). Doing that alone though didn't seem very interesting. For the Jasmin Displays I managed to get a WizNet W5500 working on the board, avoiding WiFi, but still using an off the shelf Arduino (Uno R4) as the controller. To challenge myself a little further, I decided to stick the whole arduino on the same board. So, this new circuit does the following:

It adds buffers to allow both sides of the display to work
It adds a WizNet W5500, so it can have ethernet instead of WiFi
It became the Arduino
Also: to see if I analogue ports work, I added some pin headers for the display's internal LDR sensor. This is now reported to MQTT.

If I'm honest, I was expecting this to fail, but thought it would be an interesting learning experience. It very nearly did, but I was able to figure out the issue and everything is working great. Here are some photos to prove it. One side of the display is more yellow than the other.

And here's a photo of the board, with ethernet, power and the ribbon cables attached.

So, what mistakes did I make? The first is that I forgot that these things requires bootloaders and couldn't figure out why I wasn't able to see the MCU from my computer. After reading the data sheet, it became clear that I needed to tie a pin to ground during startup so that it enters dfu mode. After soldering on a temporary bodge wire, I used rfpc-li to flash the bootloader as described in the Arduino GitHub:

rfp-cli -device ra -port $portname -p dfu_minima.hex

And then I was able to flash the code for the departure board firmware. Great! But there was still one more issue: I couldn't talk to the WizNet chip. While I was designing this board, I looked at the open source schematics for the Minma board, but once I got to the stage of hooking up the WizNet stuff I referred to an image showing the "arduino uno r4 pinmap" (straight from DuckDuckGo image results). That image refers to the internal pin names from the Arduino Uno R4 WiFi board, not the Arduino Uno R4 Minima board.

The R7FA4M chip actually has two SPI busses, but for compatibility between the two Arduino boards, only one is made visible from the Arduino APIs. On the WiFi variant, the first SPI bus is used for talking to the ESP32 and the second SPI bus is exposed to the pin headers. On the non-WiFi variant, the first SPI bus is exposed to the pin headers and the second bus is ignored.

After some mutilation to the internal Arduino APIs I was able to get it working. This is what I did to variant.cpp:

  { BSP_IO_PORT_03_PIN_03,    P303   }, /* (9) D9~  */
//{ BSP_IO_PORT_01_PIN_12,    P112   }, /* (10) D10~ */
  { BSP_IO_PORT_01_PIN_03,    P103 }, // 10 asj
//{ BSP_IO_PORT_01_PIN_09,    P109   }, /* (11) D11~ */
  { BSP_IO_PORT_04_PIN_11,    P411   }, // 11 asj
//{ BSP_IO_PORT_01_PIN_10,    P110   }, /* (12) D12 */
  { BSP_IO_PORT_04_PIN_10,    P410  }, // 12 asj
//{ BSP_IO_PORT_01_PIN_11,    P111   }, /* (13) D13 */
  {BSP_IO_PORT_01_PIN_02,     P102 }, // 13 asj

but it turns out there is a better way! You can create your own board variants and store them in your Arduino folder. So I now have my own tree for custom boards on sourcehut. The amount of duplication between this and the Minima board is a bit sad, I'd like to try and condense that at some point, but it works well enough for now, and is far better than going in and tweaking the Minima code.

So, we now a working process and working WiFi. I just got back from the Hackspace, and I was happy to find that the buffer stuff works well too (and as you will have seen from the photos above), both sides of the display are working nicely. I feel a bit bad retiring the old board, but it does free up an Arduino (which was a Christmas present from 2023…)

I think the display is really cool, I love seeing it show messages, indicate which doorbell was rung, show how many trains have been cancelled, etc. It's fun. The changes made for this board were a good test and I'm very glad it's all working. It's definitely the most complicated board I've made so far.

Wanting to leave a comment?

Comments and feedback are welcome by email (aaron@nospam-aaronsplace.co.uk).

Tags: electronics