#esp32c3 — Public Fediverse posts

TinyGo + ESP32C3 / ESP32S3 のネットワークアクセスはこのリポジトリです。
#tinygo #esp32c3 #esp32s3

tinygo-org/espradio: TinyGo package for using the ESP32 radio for WiFi/Bluetooth wireless communication. Work in progress.
https://github.com/tinygo-org/espradio

ついに TinyGo + ESP32C3 で http.Get() ができるようになりました。現時点は http のみで ESP32C3 と ESP32S3 のみ。今後よりサポートが進んでいくと思われます。楽しみ。とりあえずサクッとつながるので気持ちいい。
#tinygo #esp32c3 #esp32s3

#WeActStudio hat jetzt auch einen #ELRS Receiver mit #ESP32C3 + #SX1281 in der Produktpalette für 7.99EUR
https://de.aliexpress.com/item/1005010539158146.html

My plan for the day is to see if I can turn these components into something that makes noise, following @todbot's CircuitPython synthio tutorials

https://github.com/todbot/CircuitPython_Synthio_Tutorial/tree/main?tab=readme-ov-file

#CircuitPython #synthio #ESP32C3 #weeknotes

Lilbits: World’s smallest ESP32 dev board, GMK’s first Panther Lake mini PC, and XBMC 4.0 for the actual Xbox

Valve’s upcoming Steam Machine is a cross between a mini PC and a game console. And while the nearly cube-shaped device has a pretty basic design, it’s also made to be customizable: Valve demonstrated a couple of swappable face plates when the company unveiled the Steam Machine and now third-party companies are starting to tease accessories.

Meanwhile an independent developer has designed an […]

#devBoard #esp32 #esp32C3 #gmk #gmkEvoT2 #jsaux #kodi #lilbits #miniPc #pantherLake #pegork #pegorkF32 #steamMachine #xbmc #xbox #xboxFullScreenExperience

Read more: https://liliputing.com/lilbits-worlds-smallest-esp32-dev-board-gmks-first-panther-lake-mini-pc-and-xbmc-4-0-for-the-actual-xbox/

Possibly-Smallest ESP32 Board Uses Smallest-Footprint Parts https://hackaday.com/2025/11/19/possibly-smallest-esp32-board-uses-smallest-footprint-parts/ #Microcontrollers #miniaturized #devboard #smallest #esp32c3

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:

• Arduino with Multiple Displays
• https://emalliab.wordpress.com/2025/07/19/small-microcontroller-displays/

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” shifting the value to the correct place in the 5-6-5 format. Red and blue are the 5-bit colours and green is the 6-bit colour, so in each case I take the most significant bits which means each colour can still be defined in terms of 0..255 RGB values.

// Format is 16-bit 5-6-5 B-G-R
// Allow 0..255 in component values, by only taking
// most significant bits (5 or 6) from each value.
//   bbbbbggggggrrrrr
#define ST_COL(r,g,b) (((r&0xF8)>>3)|((g&0xFC)<<3)|((b&0xF8)<<8))
#define ST_BLACK   ST_COL(0,0,0)
#define ST_GREY    ST_COL(64,64,64)
#define ST_WHITE   ST_COL(255,255,255)
#define ST_BLUE    ST_COL(0,0,255)
#define ST_GREEN   ST_COL(0,255,0)
#define ST_RED     ST_COL(255,0,0)
#define ST_YELLOW  ST_COL(255,255,0)
#define ST_MAGENTA ST_COL(255,0,255)
#define ST_CYAN    ST_COL(0,255,255)

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

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:

• Arduino with Multiple Displays
• https://emalliab.wordpress.com/2025/07/19/small-microcontroller-displays/

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:

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.

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

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

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:

• Getting Started with the XIAO MIDI Synthesizer
• XIAO SAMD21, Arduino and MIDI
• XIAO SAMD21, Arduino and MIDI – Part 6

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):

• NC
• TX
• 5V
• GND

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

• RX7
• TX6
• 3V3
• GND

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

First steps with the XIAO ESP32-C3 and SAM2965 based Synth module.

https://diyelectromusic.com/2025/06/26/xiao-esp32-c3-midi-synthesizer/

#MIDI #XIAO #ESP32C3 #SAM2695

Собираем удобный CAN bus сниффер с интерактивной консолью за $3

Привет, Хабр! Протокол CAN сейчас широко распространён не только в автомобильной сфере, но и на предприятиях, в различных самоделках, и даже в Средствах Индивидуальной Мобильности (контроллеры VESC, например). В ноябре прошлого года я сделал для себя удобный инструмент для анализа CAN и отправки фреймов, сейчас же хочется сделать код опенсорсным и рассказать о самом проекте.

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

#espidf #esp32c3 #esp32 #freertos #C #can_bus #can_шина