Mastodawn

Simple DIY Electronic Music Projects Aug 14

Arduino with Multiple Displays – Part 3

Whilst messing around a little more with my Arduino with Multiple Displays – Part 2, I’ve optimised the code a little and found out a bit more about these displays!

In this part, I’m actually using a PCB that can hold four displays, powered by a Waveshare Zero device. More on that here: Waveshare Zero Multi Display PCB Design.

Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!

These are the key Arduino tutorials for the main concepts used in this project:

If you are new to microcontrollers, see the Getting Started pages.

Parts list

A Waveshare Zero format board or similar
4x 0.96″ ST7735 60×180 SPI TFT displays.
Built Waveshare Zero Multi Display PCB
Breadboard and jumper wires.

Recall that I’m using displays that look like this – note the order of the pins.

Although even with displays that look exactly the same, it appears there can be differences in how they are used software wise. More on that later.

The Circuit

For two displays, I can reuse the circuit from Arduino with Multiple Displays – Part 2. For more displays, it is possible to cascade more displays using jumper wires, but I’ve used my PCB.

The pins to be used for various Waveshare Zero boards is covered in part 2.

The Code

Whilst using these displays, I found that the colours can be inverted in some of them compared to others. Typically, I’ve found that I might have to use either of the following two options to drive them correctly:

tft.initR(INITR_MINI160x80);
tft.initR(INITR_MINI160x80_PLUGIN);

These represent different Adafruit displays as before, but they generally work for me.

However there is another thing to watch out for. These displays are 16-bit colour displays, which means each colour value is a 16-bit word with red, green and blue elements represented by 5, 6 and 5 bits. This means two of the colours have a resolution of 0 to 31, and one has 0 to 63.

But the ordering seems different for different displays. The default Adafruit library appears to assume RGB ordering, but my displays seem to be BGR. This means that if I use the provided short-cuts for colours, the red and blue elements are swapped.

Consequently, I defined my own colours along with a macro to allow me to provide RGB values and turn it into the device-specific 16-bit value as required.

In the following, I define the bit-shift number for each of red, green and blue and the use that in a macro “ST_COL”. Red and blue are the 5-bit colours and green is the 6-bit colour.

// Format is 16-bit 5-6-5 B-G-R
#define RBV 0
#define GBV 5
#define BBV 11
#define ST_COL(r,g,b) (((r&0x1F)<<RBV)|((g&0x3F)<<GBV)|((b&0x1F)<<BBV))
#define ST_BLACK ST_COL(0,0,0)
#define ST_WHITE ST_COL(31,63,31)
#define ST_BLUE ST_COL(0,0,31)
#define ST_GREEN ST_COL(0,63,0)
#define ST_RED ST_COL(31,0,0)
#define ST_YELLOW ST_COL(31,63,0)
#define ST_MAGENTA ST_COL(31,0,31)
#define ST_CYAN ST_COL(0,63,31)

I’m also building up to seeing if I can drive more than four displays, so I’ve also changed the code to allow me to iterate across a number of displays.

#define NUM_TFTS 4
int tftTypes[NUM_TFTS] = {
INITR_MINI160x80, INITR_MINI160x80,
INITR_MINI160x80, INITR_MINI160x80,
};

int tftCS[NUM_TFTS] = {SPI_SS, 6, 5, 4};
#define TFT_RST 7
#define TFT_DC 11

Adafruit_ST7735 *tft[NUM_TFTS];

void setup() {
int rstPin = TFT_RST;0
for (int i=0; i<NUM_TFTS; i++) {
tft[i] = new Adafruit_ST7735(&MySPI, tftCS[i], TFT_DC, rstPin);
rstPin = -1;
tft[i]->initR(tftTypes[i]);
tft[i]->setRotation(3);
tft[i]->fillScreen(ST_BLACK);
}
}

void loop() {
for (int i=0; i<NUM_TFTS; i++) {
unsigned long time = millis();
tft[i]->fillRect(10, 20, tft[i]->width(), 20, ST_BLACK);
tft[i]->setTextColor(ST_GREEN);
tft[i]->setCursor(10, 20);
tft[i]->print(i);
tft[i]->print(":");
tft[i]->print(time, DEC);
}
}

Each instance of the display code is now created dynamically and stored in an array which can then be iterated over when it comes to putting things on each display.

Notice how the reset pin definition is set to -1 after the first initialisation. This ensures that subsequent instantiations won’t reset displays that have already been set up.

The final code actually allows up to eight displays to be included by setting NUM_TFTS at the top to two or four.

The GPIO usage being assumed is described here: Waveshare Zero Multi Display PCB Build Guide.

Find it on GitHub here.

Closing Thoughts

Approaching the code in this way allows me to experiment more easily with more than four displays.

If my PCB works as I’m hoping I should be able to cascade them to get eight displays – assuming the Waveshare Zero is up to driving eight of course.

Kevin

#arduinoUno #define #esp32c3 #ESP32s3 #rp2040 #st7735 #tftDisplay #WaveshareZero

sounddrill

Jul 27

Really enjoyed attending the lioncircuits x pcbcupid hackathon on 26th July 2025(Yesterday/Saturday!)

Didn't get a chance to show the final pic so here's a mockup we made early on to visualize what it will look like!

We made a "Guardian of the Nursery", a tiny "Absurd Buddy"! Basically a fun little stick robot that you put into a plant to measure its water intake. Just the right amount, not too much, not too little, also depends on the temperature and humidity around.

Didn't get a chance to make a companion app but that's okay! Here is our submission: https://guardian.layogtima.com/

The brains of this project was a PCBCupid Glyph C3, an ESP32 dev board. Check it out if you wish at https://shop.pcbcupid.com/product/gd001/

Update: We won 3rd prize!

#hackathon #pcbcupid #lioncircuits #hardwarehackathon #electronics #esp32 #esp32c3

diyelectromusic Jul 20

More multi-SPI display messing around. This time using Waveshare Zero format boards, finding a common way to drive them from a RP2040, ESP32S3 or ESP32C3.

I hadn't realised SPI on the ESP32S3 was so complex!

(or that finding some common physical pins across the range required so much software messing about too).

https://diyelectromusic.com/2025/07/20/arduino-with-multiple-displays-part-2/

#WaveshareZero #RP2040 #ESP32C3 #ESP32S3

Simple DIY Electronic Music Projects Jul 20

Arduino with Multiple Displays – Part 2

As I mentioned in my last post on Arduino with Multiple Displays I’m going to look at other microcontrollers too. This post takes a wander through my Waveshare Zero and similar format boards that each support one of the RP2040, ESP32-C3 or ESP32-S3.

Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!

These are the key Arduino tutorials for the main concepts used in this project:

If you are new to microcontrollers, see the Getting Started pages.

Parts list

A Waveshare Zero format board or similar
2x 0.96″ ST7735 60×180 SPI TFT displays.
Breadboard and jumper wires.

Once again I’m using displays that look like this – note the order of the pins.

The Circuit

All circuits are a variation on the above, requiring the following ideal connections:

DisplayFunctionRP2040ESP32-C3ESP32-S3BLKBacklight control
(not required)N/CN/CN/CCSChip select
One per display.5 or any SPI0 CS1010DCData/Command888RESReset1499SDAData (MOSI)3 or any SPI0 MOSI6 or 711SCLClock (SCLK)2 or any SPI0 SCLK4 or 612VCCPower3V33V33V3GNDGroundGNDGNDGND

For the explanations of the pin choices, and what it means for the code, see the following sections.

ESP32-S3 Zero

In the Arduino IDE, using board ESP32-> Waveshare ESP32-S3-Zero.

There are several SPI buses on the ESP32-S3, but they have fixed uses as follows (see the ESP32-S3 Technical Reference Manual Chapter 30 “SPI Controller”):

SPI 0: Reserved for internal use.
SPI 1: Reserved for internal use.
SPI 2: General purpose use – often called FSPI in the documentation.
SPI 3: General purpose use – often called SPI or SPI3.

Sometimes the two SPI buses are called VSPI and HSPI but I think that is really terminology from the original ESP32 rather than the ESP32-S3.

The ESP32 Arduino core for the Waveshare ESP32-S3 Zero variant defines the following:

// Mapping based on the ESP32S3 data sheet - alternate for SPI2
static const uint8_t SS = 34; // FSPICS0
static const uint8_t MOSI = 35; // FSPID
static const uint8_t MISO = 37; // FSPIQ
static const uint8_t SCK = 36; // FSPICLK

By default the Adafruit libraries will use the boards default SPI interface, as defined in the variants.h file – i.e. the above.

When it comes to assigning SPI devices to GPIO there are a few considerations (see the “ESP32-S3 Technical Reference Manual, Chapter 6 “IO MUX and GPIO Matrix”):

In general, any GPIO can be mapped onto any SPI function. However…
Some GPIO have special “strapping” functions so are best avoided.
Some GPIOs have a default SPI function that bypasses the GPIO MUX routing, so allows for better performance (see section 6.6 “Direct Input and Output via IO MUX”).

From my reading of the reference manual I believe the following are default “non-MUX” SPI connections:

In the previous table, where SPI3 is mentioned, then the entry for “Direct IO via IO MUX” is set to “no”, so I’m guessing that isn’t available.

But now we can see why the Arduino core is using GPIO 34-37, but we can also see that GPIO 10-13 would be an alternative (fast) option too.

The problem is that not all of GPIO 34-37 are broken out on a Waveshare ESP32-S3 Zero, so I need to use the alternative pinouts. Aside: this makes no sense to me that these are the defaults in the Waveshare ESP32-S3 Zero’s “variant.h” file, but anyway…

To use a different SPI interface requires using a constructor that passes in an initialised SPI instance. There is an example in the ESP32 core for setting up multiple SPI buses here: https://github.com/espressif/arduino-esp32/blob/master/libraries/SPI/examples/SPI_Multiple_Buses/SPI_Multiple_Buses.ino

This leads to the pins as defined in the previous table, and the code below to setup one of the displays.

#include <Adafruit_GFX.h> // Core graphics library
#include <Adafruit_ST7735.h> // Hardware-specific library for ST7735
#include <SPI.h>

#define SPI_SS 10
#define SPI_MOSI 11
#define SPI_SCLK 12
#define SPI_MISO 13
SPIClass MySPI(FSPI);

#define TFT_CS SPI_SS
#define TFT_RST 9
#define TFT_DC 8
Adafruit_ST7735 tft = Adafruit_ST7735(&MySPI, TFT_CS, TFT_DC, TFT_RST);

void setup() {
MySPI.begin(SPI_SCLK, SPI_MISO, SPI_MOSI, SPI_SS);
pinMode(SPI_SS, OUTPUT);
tft.initR(INITR_MINI160x80_PLUGIN);
}

ESP32-C3 Zero

In the Arduino IDE, using board ESP32-> ESP32C3 Dev Module.

Again there are several SPI buses on the ESP32-C3, with the same fixed uses as follows (see the ESP32-C3 Technical Reference Manual Chapter 30 “SPI Controller”):

SPI 0: Reserved for internal use.
SPI 1: Reserved for internal use.
SPI 2: General purpose use – sometimes called GP-SPI in the documentation.

The ESP32-C3 also has a very similar SPI arrangement to the ESP32-S3, in that whilst any pin can be configured for SPI usage, there are certain hard-wired optional arrangements that bypass the GPIO routing matrix.

The faster (direct to IO MUX) pins are as follows (more here):

CS0 – 10
SCLK – 6
MISO – 2
MOSI – 7

Curiously, the general ESP32-C3 Arduino variant defines them as follows:

static const uint8_t SS = 7;
static const uint8_t MOSI = 6;
static const uint8_t MISO = 5;
static const uint8_t SCK = 4;

From the Technical Reference manual, we can see that the default Arduino definitions above, do not support the non-routed, direct-to-IO MUX pin mappings, which from the table below do indeed map onto GPIO 2, 6, 7, 10.

In terms of using a Waveshare ESP32-C3 Zero, both combinations would be supported on the broken out GPIO, so from a software point of view, the Adafruit libraries could be used “as is” with the default mapping, or with a custom SPI definition (as shown above) with the more bespoke, but faster, mapping.

RP2040 Zero

This is using the (unofficial) RP2040 core from here: https://github.com/earlephilhower/arduino-pico, where this is an entry: RP2040 -> Waveshare RP2040 Zero.

The RP2040 has two SPI peripherals and the SPI functions are mapped onto specific sets of GPIO pins. This gives a range of flexibility, but not arbitrary flexibility. The board definition file for the Waveshare RP2040 Zero provides this as a default:

// SPI
#define PIN_SPI0_MISO (4u)
#define PIN_SPI0_MOSI (3u)
#define PIN_SPI0_SCK (2u)
#define PIN_SPI0_SS (5u)

#define PIN_SPI1_MISO (12u)
#define PIN_SPI1_MOSI (15u)
#define PIN_SPI1_SCK (14u)
#define PIN_SPI1_SS (13u)

Note that the SPI1 pins for the Waveshare RP2040 Zero are not all on the standard header connections, some are on the additional pin headers across the bottom.

Using a bespoke configuration is possible using a series of calls to set the SPI pins as shown below.

SPI.setRX(SPI_MISO);
SPI.setCS(SPI_SS);
SPI.setSCK(SPI_SCLK);
SPI.setTX(SPI_MOSI);
SPI.begin(true);

To use pins for SPI1, replace SPI above with SPI1. As long as this happens prior to the call to the Adafruit libraries, everything works fine.

A Common Option

It would be nice to find a set of physical pin connections that I know would always work regardless of the board in use: RP2040, ESP32-S3 or ESP32-C3.

With careful noting of the RP2040 limitations, I think that is largely possible with the following. Even though the GPIO numbers are different, the physical pins are common on all three boards.

DisplayFunctionWS PinRP2040ESP32-C3ESP32-S3BLKBacklight control
(not required)N/CN/CN/CCS1Chip select
Display 1H2 P6GP5GP9GP10DCData/CommandH2 P5GP4GP10GP11RESResetH2 P9GP8GP6GP7SDAData (MOSI)H2 P8GP7GP7GP8SCLClock (SCLK)H2 P7GP6GP8GP9VCCPowerH1 P33V33V33V3GNDGroundH1 P2GNDGNDGNDCS2CS Display 2H1 P9GP14GP5GP6CS3CS Display 3H1 P8GP15GP4GP5CS4CS Display 4H1 P7GP26GP3GP4

A couple of notes:

I’ve avoided pins 1-4 on header 2, as the ESP32-C3 can’t use them for SPI and they support either the UART or USB.
I’ve had to include a MISO (SPI RX) pin in each configuration too, so I’ve just picked something that can be ignored. For RP2040 that has to be one of GP0, GP4 or GP16 however, which could clash with either the UART, the above configuration for DC pin, or the onboard WS2812 LED, but there isn’t much that can be done.
I’ve allowed three consecutive pins on the first header for optional additional CS pins for displays 2 to 4.

Here is the full set of configurable code for the above:

#include <Adafruit_GFX.h> // Core graphics library
#include <Adafruit_ST7735.h> // Hardware-specific library for ST7735
#include <SPI.h>

//#define WS_RP2040_ZERO
//#define WS_ESP32C3_ZERO
#define WS_ESP32S3_ZERO

#ifdef WS_RP2040_ZERO
#define SPI_SS 5
#define SPI_MOSI 7
#define SPI_SCLK 6
#define SPI_MISO 4 // Not used
#define SPI_BUS SPI
#define TFT_CS1 SPI_SS
#define TFT_CS2 14
#define TFT_CS3 15
#define TFT_CS4 26
#define TFT_RST 8
#define TFT_DC 4
#endif

#ifdef WS_ESP32C3_ZERO
#define SPI_SS 9
#define SPI_MOSI 7
#define SPI_SCLK 8
#define SPI_MISO 0 // Not used
SPIClass MySPI(FSPI);
#define TFT_CS1 SPI_SS
#define TFT_CS2 5
#define TFT_CS3 4
#define TFT_CS4 3
#define TFT_RST 6
#define TFT_DC 10
#endif

#ifdef WS_ESP32S3_ZERO
#define SPI_SS 10
#define SPI_MOSI 8
#define SPI_SCLK 9
#define SPI_MISO 1 // Not used
SPIClass MySPI(FSPI);
#define TFT_CS1 SPI_SS
#define TFT_CS2 6
#define TFT_CS3 5
#define TFT_CS4 4
#define TFT_RST 7
#define TFT_DC 11
#endif

#ifdef WS_RP2040_ZERO
Adafruit_ST7735 tft1 = Adafruit_ST7735(TFT_CS1, TFT_DC, TFT_RST);
Adafruit_ST7735 tft2 = Adafruit_ST7735(TFT_CS2, TFT_DC, -1);
#else
Adafruit_ST7735 tft1 = Adafruit_ST7735(&MySPI, TFT_CS1, TFT_DC, TFT_RST);
Adafruit_ST7735 tft2 = Adafruit_ST7735(&MySPI, TFT_CS2, TFT_DC, -1);
#endif

void setup() {
#ifdef WS_RP2040_ZERO
SPI_BUS.setRX(SPI_MISO);
SPI_BUS.setCS(SPI_SS);
SPI_BUS.setSCK(SPI_SCLK);
SPI_BUS.setTX(SPI_MOSI);
SPI_BUS.begin(true);
#else
MySPI.begin(SPI_SCLK, SPI_MISO, SPI_MOSI, SPI_SS);
pinMode(SPI_SS, OUTPUT);
#endif

tft1.initR(INITR_MINI160x80_PLUGIN);
tft2.initR(INITR_MINI160x80_PLUGIN);
tft1.setRotation(3);
tft1.fillScreen(ST77XX_BLACK);
tft2.setRotation(3);
tft2.fillScreen(ST77XX_BLACK);
}

void loop() {
unsigned long time = millis();
tft1.fillRect(10, 20, tft1.width(), 20, ST77XX_BLACK);
tft1.setTextColor(ST77XX_GREEN);
tft1.setCursor(10, 20);
tft1.print(time, DEC);
delay(100);

time = millis();
tft2.fillRect(10, 20, tft2.width(), 20, ST77XX_BLACK);
tft2.setTextColor(ST77XX_MAGENTA);
tft2.setCursor(10, 20);
tft2.print(time, DEC);
delay(400);
}

Closing Thoughts

It is a little annoying that these great boards don’t share a re-usable, common pinout in terms of naming and positions, but I guess that isn’t the main focus for these systems.

Still, it seems that a common hardware pinout can be made that supports many displays, which is great, as I’d really like to get a number of them onto a PCB!

Kevin

#arduinoUno #esp32c3 #ESP32s3 #rp2040 #st7735 #tftDisplay #WaveshareZero

Habr Jul 3

О контроллере батареи ИБП (часть 2)

О сколько нам открытий чудных ... Судя по результатам голосования и комментариям к предыдущей статье , к вопросу контроля АКБ у самых простых ИБП есть некоторый интерес. Данная статья - продолжение данной темы. Сейчас прототип собран на макетной плате (токовый шунт к которому подключено два АПЦ). Измеритель напряжения и тока INA3221, как рекомендовали в комментариях, я решил не использовать, так как дискретность его измерения 8мВ сравнима с дискретностью 12-ти битного АПЦ в обычном микроконтроллере (для ESP32 получается точность измерения около 6мВ).

https://habr.com/ru/articles/924614/

#ибп_для_дома #акб #контроль_АКБ #интернетвещей #iot #esp32 #esp32c3

О контроллере батареи ИБП (часть 2)

Хабр

Show thread

diyelectromusic Jun 29

Part 6 pairs the Synth module with a XIAO expander for some simple IO.

https://diyelectromusic.com/2025/06/29/xiao-esp32-c3-midi-synthesizer-part-6/

#XIAO #MIDI #ESP32C3

Simple DIY Electronic Music Projects Jun 29

XIAO ESP32-C3 MIDI Synthesizer – Part 6

Expanding on my previous posts, I thought it might be interesting to see how I might be able to add some additional IO to the MIDI Synth. This is an exploration of some options there.

Part 1 – Getting started and getting code running.
Part 2 – Swapping the ESP32-C3 for a SAMD21 to get USB MIDI.
Part 3 – Taking a deeper look at the SAM2695 itself.
Part 4 – A USB MIDI Synth Module using the SAMD21 again as a USB MIDI Host.
Part 5 – A Serial MIDI Synth Module using the original ESP32-C3.
Part 6 – Pairs the Synth with a XIAO Expansion board to add display and potentiometers.

Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!

These are the key tutorials for the main concepts used in this project:

If you are new to microcontrollers, see the Getting Started pages.

The Synth Grove Connector

One option to immediately explore for me was the Grove connector on the Synth – highlighted by the blue rectangle in the photo below. I’m thinking at this stage of the XIAO Expander Module (more here) and how that might give some options for easily hooking up to the Synth.

There one obvious issue with this, and one not so obvious issue.

First, of course, there is no access to this connector through the case. My initial thought was to simply remove the PCB from the case and use it as a stand-alone board. On initial inspection it seemed that there were two screws holding it down. Not so, a more thorough inspection (after remove the two screws and still not being able to remove it), revealed a third screw underneath the “light pipe” for the LEDs.

Unfortunately that light pipe is pretty well wedged into the case making removal particularly tricky. But without removing the light pipe, it isn’t possible to get to the screw at all.

I did wonder about making a hole in the 3D printed case. A better option might be to get hold of the published 3D print files and add a hole and make my own (they are available via the product page).

But both options would probably end up changing the original case somehow – even if printing my own, I still need to get the original PCB out somehow and that brings me back to the light pipe issue.

The second issue isn’t quite so obvious. In that photo we can see that the pins for the Grove connector are labelled as follows (top to bottom):

The UART on the XIAO expander board, which I’d like to use, is labelled:

Checking in with the Synth schematic, the connector is wired as follows:

SYS_MIDI connects to the MIDI_IN pin of the SAM2695, so actually connecting “TX to TX” in this instance should be ok.

5V might be an issue though, as it really does look like (to me) that it really means 5V – it is the input to the TPL740F33 that generates the 3V3 power signal, as well as feeding the amplifier directly. The datasheet of the TPL740F33 does seem to imply that if receiving 3V3 it can still generate 3V3 so it might be ok? The amplifier obviously won’t be as powerful though running off 3V3.

Anyway, for now, instead I’ve just opted to use the GPIO again, wired into the expansion sockets with the XIAO removed.

At the XIAO expander end, I’ve used the additional pins rather than the Grove connector, as they support a 5V output.

The downsides to this approach:

I’m not using the Grove connectors, which would have been really neat.
I have no access to the four buttons on the XIAO MIDI Synth.

But I do now have access to two I2C Grove connectors, a GPIO Grove, and the RX part of the UART Grove too as well as the on-board display.

If a XIAO SAMD21 is used, then the previous code for USB to the Synth can be used directly – see XIAO ESP32-C3 MIDI Synthesizer – Part 2.

If the XIAO ESP32-C3 is used, then an additional serial MIDI connection is required. This can be connected to the Grove UART connector (using the RX pin, and leaving TX unconnected) or the RX pin of the additional 8-way pin header on the expansion board. Then the code from this will work directly: XIAO ESP32-C3 MIDI Synthesizer – Part 5.

Adding a Display and Program Control

I already have some code that has done this for a XIAO on an expansion board here XIAO SAMD21, Arduino and MIDI – Part 6.

But for this to work usefully with the Synth module, I need to adjust the routing so that MIDI goes from USB to serial, but the program change messages are also sent via serial to the synth module. That has already been address in previous parts, to I just need to merge the code with that from XIAO ESP32-C3 MIDI Synthesizer – Part 4.

This is the result.

There is a bit of jitter on the analog pot, but that is only because I’m using the original fairly simplified algorithm to detect changes. If I was fussed about it, I’d reuse the averaging class from Arduino MIDI Atari Paddles. And to be honest, a capacitor on the pot would probably go quite a long way too…

As a test, I also powered the device from the Grove UART port connecting it as follows:

Expander GND – GND Synth
Expander 3V3 – 5V IN Synth
Expander TX – RX/D6 Synth
Expander RX – N/C

And this all worked fine. So I think a Grove to Grove lead would work fine if I had access to the Synth’s Grove port.

This does mean that the exact same code can work with the M5 Synth module using a Grove to Grove lead. The downside of this, even though it is a lot simpler in connectivity terms, is that there is now external audio out like there is on the XIAO Synth.

For completeness the same code can be used with the XIAO ESP32-C3 and serial MIDI, see the photo at the start of this blog.

To turn off all USB handling in the code, the following must be commented out:

//#define HAS_USB
//#define SER_TO_USB
//#define MIDI_USB_PCCC

For other parts of the code, the Arduino abstraction for A0 maps over to the ESP32-C3 fine. The only thing to watch out for is the increased analog resolution from 10 to 12 bits, but a call to analogReadResolution(10) drops that back to the expected 10 bits.

Oh and the Serial port to use is different:

XIAO SAMD21: Serial1
XIAO ESP32-C3: Serial0

Find it on GitHub here.

Closing Thoughts

If I can be bothered, it would be nice to actually display the General MIDI voice name on the display. The SAM2695 also has its MT-32 mode, so having some means of selecting that might be interesting too.

And so far I’ve largely only messed about with driving it on a single MIDI channel, so there is a lot more that could be done there.

Kevin

#controlChange #esp32c3 #midi #programChange #SAM2695 #samd21 #usbMidi #xiao

Simple DIY Electronic Music Projects Jun 27

XIAO ESP32-C3 MIDI Synthesizer – Part 2

After an initial play with the XIAO ESP32-C3 MIDI Synthesizer the first thing I wanted to try was to swap out the ESP32-C3 for something else, just to see what could be done.

Part 1 – Getting started and getting code running.
Part 2 – Swapping the ESP32-C3 for a SAMD21 to get USB MIDI.
Part 3 – Taking a deeper look at the SAM2695 itself.
Part 4 – A USB MIDI Synth Module using the SAMD21 again as a USB MIDI Host.
Part 5 – A Serial MIDI Synth Module using the original ESP32-C3.
Part 6 – Pairs the Synth with a XIAO Expansion board to add display and potentiometers.

The XIAO range of boards support a range of options and Adafruit’s QTPy boards are also pin-compatible. For me, I have the following as possibilities:

XIAO SAMD21
XIAO RP2040
QTPy SAMD21
QTPy ESP32-C3

I also already have a range of projects that have looked at some of the above: https://diyelectromusic.com/tag/xiao/

So before I get too far into what the SAM2695 itself can do, I thought I’d try a few alternative options right from the start. This post looks at how to use the XIAO SAMD21 to support USB access to the Synth.

Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!

These are the key tutorials for the main concepts used in this project:

If you are new to microcontrollers, see the Getting Started pages.

XIAO SAMD21 as a USB Device

My CircuitPython USB to Serial MIDI Router uses a XIAO SAMD21 in USB Device mode, so replacing the ESP32C3 with a SAMD21, should allow it to be used as a USB MIDI device.

The principle is exactly the same as the previous project but instead of a serial MIDI interface connected to the XIAO UART, it is connected directly to the SAMD21.

This should work just as well with a QTPy SAMD21 too.

There are two options for USB MIDI device support:

Using CircuitPython: e.g. CircuitPython USB to Serial MIDI Router – Using CircuitPython.
Using Arduino: e.g.
- XIAO SAMD21, Arduino and MIDI – Part 4 – Using Arduino or TinyUSB.
- XIAO USB Device to Serial MIDI Converter – A simpler option for Arduino.

Using CircuitPython

The following steps are required for the CircuitPython version which, when it works, is the simplest:

Set up the XIAO SAMD21 for CircuitPython as described here: https://wiki.seeedstudio.com/Seeeduino-XIAO-CircuitPython/
Install the adafruit_midi libraries into the lib folder
Use the code from here and save it as code.py: https://github.com/diyelectromusic/sdemp/blob/main/src/SDEMP/CircuitPython/USBUARTMidiRouter.py
Reboot

When I first tried this, everything hung up. It turned out that the XIAO needs to use board.LED_INVERTED as the built-in LED label. Once that was updated all was good.

I also, as a precaution, added the following to boot.py:

import usb_hid, usb_midi
usb_hid.disable()
usb_midi.enable()

But this is probably unnecessary for the XIAO SAMD21.

The XIAO pops up as a USB MIDI device called “CircuitPython Audio” and any MIDI commands (such as note, Program Change, or control messages) sent to the device are forwarded directly onto the SAM2695 synth.

Whilst this is the simplest way to do this, it isn’t the most performant! Will a lot of notes (like my Rite of Spring example) some MIDI messages might not be accurately processed in time and others might get lost.

Using Arduino

It just so happens that the code I used for XIAO SAMD21, Arduino and MIDI – Part 4 “just works”. It is a little over the top, in that it sets up three serial ports, so will almost certainly clash with something else on the synth, but it does work if no buttons are pressed!

Use the code from: https://github.com/diyelectromusic/sdemp/tree/main/src/SDEMP/XiaoSimpleUSBMIDIMerge

Download this using the “Seeeduino XIAO” board setting in the Arduino IDE and it should appear as a USB MIDI device called “Seeed XIAO M0” or something like that.

Performance wise, this passes the Rite of Spring test very well.

Alternatively, the code from XIAO USB Device to Serial MIDI Converter focusses more directly on the USB to serial conversion and includes an option for serial to serial routing too, which is more useful in this particular case.

XIAO SAMD21 as USB Host

In the post XIAO SAMD21, Arduino and MIDI – Part 5 I used the SAMD21 as a USB host. By providing an external power supply this allow the use of a USB MIDI controller with the SAM2695.

To plug anything in however will require an adaptor or two. This needs to go from an original “USB A” plug to a USB-C socket. For me, this involved using a “USB-C to USB-micro” adaptor and then a “USB OTG adaptor” as shown below.

Then I needed a 5V power source, so I cheated and use the 5V and GND from the original XIAO ESP32-C3 that I’d replaced with the XIAO SAMD21 and just jumpered them across to 5V and GND from the breakout headers on the synth.

I stayed away from the code I used as part of XIAO SAMD21, Arduino and MIDI – Part 4 directly, but instead used one of the sample applications from the SAMD21 USB Host Library.

I turns out the “USB_MIDI_Converter” sketch works really well. This can be found here: https://github.com/gdsports/USB_Host_Library_SAMD/blob/master/examples/USBH_MIDI/USB_MIDI_converter/USB_MIDI_converter.ino

Closing Thoughts

Similar tricks should also be possible using the RP2040 based boards, and as already mentioned it is also possible to use the Grove connector. One of the options for Grove is as a UART, and this is supported, for example, on the original XIAO breakout board: https://wiki.seeedstudio.com/Seeeduino-XIAO-Expansion-Board/

I believe the UART Grove socket would connect directly to the Synth Grove connector allowing use of the synth from the expansion board too.

Kevin

#esp32c3 #midi #SAM2695 #usbDevice #usbHost #xiao