Teensy 4.x + ESP32 Stack
- Thread starter KenHahn
- Start date
wwatson
Well-known member
Along time ago in a place we tested several codecs from the Arduino-Teensy-Codec-lib. We had SD, MSC and littlefs which included the four devices on the PJRC memory board and others working:
This is the working list from one of my libraries:
It has been a while since I ran this stuff on the Teensy but everything worked. I believe @mjs513 was also involved with it
Code:
// LFS fixed block device index numbers.
#define LFS_DRIVE_QPINAND 28
#define LFS_DRIVE_QSPIFLASH 29
#define LFS_DRIVE_QPINOR5 30
#define LFS_DRIVE_QPINOR6 31
#define LFS_DRIVE_SPINAND3 32
#define LFS_DRIVE_SPINAND4 33
Code:
#ifdef AUDIOPLAY
#include <Audio.h>
#include <play_sd_mp3.h>
#include <play_sd_aac.h>
#include <play_sd_flac.h>
#include <play_FS_wav.h>
#include <play_FS_raw.h>
AudioPlaySdMp3 playMp31; //xy=154,78
AudioPlayFSWav playWav; //xy=154,422
AudioPlayFSRaw playRaw; //xy=154,422
AudioPlaySdAac playAac; //xy=154,422
AudioPlaySdFlac playFlac;
// GUItool: begin automatically generated code
AudioOutputI2S i2s1; //xy=1023.0000076293945,500.00000286102295
AudioMixer4 mixer1; //xy=625.0000038146973,393.00000381469727
AudioMixer4 mixer2; //xy=626.0000038146973,490.00000381469727
AudioMixer4 mixer3; //xy=811.0000076293945,571.0000038146973
AudioMixer4 mixer4; //xy=816.0000057220459,655.0000038146973
AudioConnection patchCord1(playWav, 0, mixer1, 3);
AudioConnection patchCord2(playWav, 1, mixer2, 3);
AudioConnection patchCord3(playMp31, 0, mixer1, 1);
AudioConnection patchCord4(playMp31, 1, mixer2, 1);
AudioConnection patchCord5(playAac, 0, mixer1, 0);
AudioConnection patchCord6(playAac, 1, mixer2, 0);
AudioConnection patchCord7(playFlac, 0, mixer1, 2);
AudioConnection patchCord8(playFlac, 1, mixer2, 2);
AudioConnection patchCord9(mixer1, 0, mixer3, 0);
AudioConnection patchCord10(mixer2, 0, mixer4, 0);
AudioConnection patchCord11(playRaw, 0, mixer3, 1);
AudioConnection patchCord12(playRaw, 0, mixer4, 1);
AudioConnection patchCord13(mixer3, 0, i2s1, 0);
AudioConnection patchCord14(mixer4, 0, i2s1, 1);
AudioControlSGTL5000 sgtl5000_1; //xy=385,688.0000038146973
// GUItool: end automatically generated code
static int playFileType = 0;
#endif
mjs513
Senior Member+
Wow that brings back memories - a long time ago now almost forgotIt has been a while since I ran this stuff on the Teensy but everything worked. I believe @mjs513 was also involved with it
Mcu32
Well-known member
But that got me in the mood to build my own new streaming player for AAC and MP3. I still have a board with an ESP and a screen, plus a DIY I2S add-on board I can plug in. Or maybe I’ll do something with that cheap C3… I’ll take a look. Over the winter. But none of that belongs here.
Ken, I think your project is great. Even if the Teensy isn’t really necessary A nice technology study.
Ken, I think your project is great. Even if the Teensy isn’t really necessary
A nice technology study.
KenHahn
Well-known member
Thank you Frank…. I think
And to be fair… The ESP32 is also not needed for the Internet Radio to run at my desk since it can just run from a browser window. But of course, that is not why any of us are on this forum.
To state what I think is obvious to everyone, there are apps that benefit from or in some case require the processing power that the Teensy offers. Adding WiFi or Bluetooth capability could be a great feature to layer on top whether it be via the upcoming dedicated SF board or by slapping an ESP32 on it as we are doing here.
The difficulty, of course, is in coming up with an example that ‘requires’ the brute power of Teensy and can make use of the wireless capability of the ESP32 that is also accessible enough to reasonably play with and share on the forum as has been done on this thread, which frankly has been quite fun.
There is probably a challenge there for someone to come up with the framework for such a project.
Maybe we could create a joint Teensy forum project. Something like creating an entry into BattleBots as that could certainly use the power of the Teensy and the wireless capability of the ESP32, but ideally one that doesn’t require machining titanium, or mortgaging homes to build it.
Whatever the project ends up being we will probably need more horsepower, so 1GHz Teensy 4.1/ESP32 stacks for the win.
And to be fair… The ESP32 is also not needed for the Internet Radio to run at my desk since it can just run from a browser window. But of course, that is not why any of us are on this forum.
To state what I think is obvious to everyone, there are apps that benefit from or in some case require the processing power that the Teensy offers. Adding WiFi or Bluetooth capability could be a great feature to layer on top whether it be via the upcoming dedicated SF board or by slapping an ESP32 on it as we are doing here.
The difficulty, of course, is in coming up with an example that ‘requires’ the brute power of Teensy and can make use of the wireless capability of the ESP32 that is also accessible enough to reasonably play with and share on the forum as has been done on this thread, which frankly has been quite fun.
There is probably a challenge there for someone to come up with the framework for such a project.
Maybe we could create a joint Teensy forum project. Something like creating an entry into BattleBots as that could certainly use the power of the Teensy and the wireless capability of the ESP32, but ideally one that doesn’t require machining titanium, or mortgaging homes to build it.
Whatever the project ends up being we will probably need more horsepower, so 1GHz Teensy 4.1/ESP32 stacks for the win.
Mcu32
Well-known member
Yes, that's fair
I would suggest a general interface between the ESP32 and the Teensy.
I haven't checked the pins on the Teensy yet. That still needs to be done. On the ESP, they are freely assignable.
An interface similar to that of the ILI9341.
SPI (10-40Mhz (80?)) transmission in both directions. CS high for data. D/C to switch between command and data. Possibly an additional ESP output line for “Wait” (high when the ESP is processing a command and low as soon as it’s finished).
It would be interesting to check whether this is possible with the available pins on teensy.
This interface could be used for all types of Wi-Fi and Bluetooth transmissions and would be universally applicable. All that would be needed then is a single, always-valid software program on the ESP
. i.E weather, webradio or bt audio or whatever on Teensy with the ESP as "dumb" wireless device.
I think Kurt proposed something like that, too.
I would suggest a general interface between the ESP32 and the Teensy.
I haven't checked the pins on the Teensy yet. That still needs to be done. On the ESP, they are freely assignable.
An interface similar to that of the ILI9341.
SPI (10-40Mhz (80?)) transmission in both directions. CS high for data. D/C to switch between command and data. Possibly an additional ESP output line for “Wait” (high when the ESP is processing a command and low as soon as it’s finished).
It would be interesting to check whether this is possible with the available pins on teensy.
This interface could be used for all types of Wi-Fi and Bluetooth transmissions and would be universally applicable. All that would be needed then is a single, always-valid software program on the ESP
. i.E weather, webradio or bt audio or whatever on Teensy with the ESP as "dumb" wireless device.
I think Kurt proposed something like that, too.
Last edited:
mjs513
Senior Member+
@KenHahn - @Mcu32
Got kind of curious about some more good projects between the Teensy41/C6 - probably extends to other boards. If you want to take a look:
was curious about the audio one so asked it to give me the whole package. If I get some time may implement it if someone doesnt beat me to it - in middle of 2 other projects/debug issues.
Got kind of curious about some more good projects between the Teensy41/C6 - probably extends to other boards. If you want to take a look:
was curious about the audio one so asked it to give me the whole package. If I get some time may implement it if someone doesnt beat me to it - in middle of 2 other projects/debug issues.
kd5rxt-mark
Well-known member
Ken (et al):
Although I don't have immediate plans for any short-term implementation, I do have a project that I believe would directly benefit from the T4.1/ESP32 stack. My TeensyMIDIPolySynth (TMPS) has been "finished" (several times, LOL) for more than a year. It currently uses sliders & buttons on an RA8875 7" display for controlling everything (e.g. 12-poly, VFO, filters, envelopes, LFO modulators, mixers, reverb, & ladder filter). That size display does impose some limitations on how many controls can be painted on the screen at one time. Back when I was actively working on the project, I contemplated implementing a network-based solution for being able to control everything remotely via a browser. Although this approach could do some good towards alleviating the size/space problem, I just hated to force the operator into a "must have ethernet to get a bigger display" situation, so I never did pursue this approach.
This new T4.1/ESP32 stack capability opens up the possibility of using a locally hosted & ESP32 generated AP-based control interface (no WiFi actually required, although that could effectively be used as well) by way of a browser on another device (PC, etc.). In addition to enabling duplicate system control, this capability could also be used to support saving & restoring configurations (currently limited in number, as they are stored in Teensy emulated EEPROM).
Following along on this thread, I recently purchased a couple of stacks (T4.0 & T4.1, both with stacked C5s) to play with. I, for one, think that the sheer availability opens up endless possibilities, and I appreciate the work that has gone into refining the interface between the two processors. I am perfectly comfortable with the shared serial port between the two processors, as my TMPS includes both a T4.1 (responsible for the display, hostMIDI, conventional DIN MIDI, USB-MIDI) & a T4.0 (responsible for all audio operations, both analog & via USBaudio), & these two processors currently intercommunicate (control & status both directions) via a 500kbps shared serial port.
Thanks to everyone !! I am truly enjoying watching the flow of invention . . .
Mark J Culross
KD5RXT
KenHahn
Well-known member
I agree in concept if working on a project from a clean slate.
With the architecture being discuss on this thread (other than the Arduino side barbs), whether it is the Teensy/ESP32 stacks or something like the Mini baseboard, we are limited to a serial interface simply because there isn't a physical connection to the Teensy SPI pins. On the stacks, the ESP32 has great flexibility in muxing the SPI pins around as you know, but the Teensy unfortunately not so much.
The original goal of these stacks was to try to come up with a scheme where the ESP32 had minimal impact on the Teensy I/O (serial fit that requirement) and the fact that it was sitting on top of the Teensy could be completely ignored if it was not needed for a project in order to make it as flexible as possible (all edge pins have no bootstrap functionality and default as inputs).
At 4Mbps, the serial link is probably adequate for most typical applications. In theory, the ESP32 AT command set can be modified to work on at least some of these mini ESP32s like the C3 so that it offered Teensy side programming only if needed. At a minimum I think you need to change the serial pin configuration files to line up with the Teensy since you can't change them in software. I don't think that Espressif has ported the AT command set to the C6 architecture yet. Not sure about the C5, but probably not.
The upcoming SparkFun adapter is more in-line with your thinking and it uses a SDIO interface along with a serial port for Bluetooth and will be programmable from the Teensy side only using the QNEthernet library which will be a huge plus.
I don’t know if you have looked at that thread as it’s pretty long and started quite some time ago but has gained steam lately. It starts to get interesting about here if you haven't seen it: https://forum.pjrc.com/index.php?threads/call-to-arms-teensy-wifi-true.77099/post-369064
The downsides to that approach vs the one here are going to be that it uses a lot of Teensy pins; prevents the use of things like the Audio Adapter; doesn't support 5Ghz; is a somewhat intrusive full length+ adapter; and will undoubtedly be more expensive. Those might still be the right tradeoffs for a WiFi intensive application that requires optimum performance.
mjs513
Senior Member+
Decided to play with this a little bit so it does work - but since I am not an audio person probably could be better. I used the protosupplies mini-dev platform - cant seem to find my Rev D audio boards....was curious about the audio one so asked it to give me the whole package. If I get some time may implement it if someone doesnt beat me to it - in middle of 2 other projects/debug issues.
Default link to web interface: http://teensy-synth.local/
Cheers
Mike
wwatson
Well-known member
I have a XAIO ESP32 C6 and I have been trying to find out what programming environment is being used to program it with the @KenHahn comm testing examples. Using the Arduino ESP32 programming environment with this code:
I get these warnings:
Any info would be helpful
Code:
// Slave (Block-Stream Echo)
// ESP32-C6
//#define RX1 D7 //GPIO17 Teensy 4.1 is connected to serial port #1
//#define TX1 D8 //GPIO19
#define RX1 D2 // Use these instead if you want to use Teensy Serial1
#define TX1 D1
#define TEENSY_SERIAL Serial1
const unsigned long TEST_BAUD = 4000000; // Target link speed
const size_t BLOCK_SIZE = 64; // Packet size
uint8_t slaveBuffer[BLOCK_SIZE];
void setup() {
// Disconnect unused I/O to avoid possible pin conflicts with Teensy
gpio_reset_pin(GPIO_NUM_0);
gpio_reset_pin(GPIO_NUM_17);
gpio_reset_pin(GPIO_NUM_19);
gpio_reset_pin(GPIO_NUM_16);
gpio_reset_pin(GPIO_NUM_18);
gpio_reset_pin(GPIO_NUM_20);
gpio_reset_pin(GPIO_NUM_21);
gpio_reset_pin(GPIO_NUM_22);
gpio_reset_pin(GPIO_NUM_23);
// Assign 4096-byte buffers to avoid overflow at higher speeds
TEENSY_SERIAL.setRxBufferSize(4096);
TEENSY_SERIAL.setTxBufferSize(4096);
// Serial.begin(115200);
TEENSY_SERIAL.begin(TEST_BAUD, SERIAL_8N1, RX1, TX1); //Port connected to Teensy 4.1
}
void loop() {
// Wait until the hardware buffer holds an entire chunk of data
if (TEENSY_SERIAL.available() >= BLOCK_SIZE) {
// Read the chunk natively into memory
TEENSY_SERIAL.readBytes(slaveBuffer, BLOCK_SIZE);
// Blast the chunk directly back down the TX hardware FIFO pipeline
TEENSY_SERIAL.write(slaveBuffer, BLOCK_SIZE);
}
}
Code:
Compiling sketch...
/home/wwatson/.arduino15/packages/esp32/tools/esp-rv32/2601/bin/riscv32-esp-elf-g++ -MMD -c @/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12/flags/cpp_flags -Wall -Wextra -Os -Werror=return-type -DF_CPU=160000000L -DARDUINO=10819 -DARDUINO_XIAO_ESP32C6 -DARDUINO_ARCH_ESP32 "-DARDUINO_BOARD=\"XIAO_ESP32C6\"" "-DARDUINO_VARIANT=\"XIAO_ESP32C6\"" -DARDUINO_PARTITION_default "-DARDUINO_HOST_OS=\"linux\"" "-DARDUINO_FQBN=\"esp32:esp32:XIAO_ESP32C6:JTAGAdapter=default,CDCOnBoot=cdc,PartitionScheme=default,CPUFreq=160,FlashMode=qio,FlashFreq=80,FlashSize=4M,UploadSpeed=921600,DebugLevel=none,EraseFlash=none,ZigbeeMode=default\"" -DESP32=ESP32 -DCORE_DEBUG_LEVEL=0 -DARDUINO_USB_MODE=1 -DARDUINO_USB_CDC_ON_BOOT=1 @/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12/flags/defines -I/home/wwatson/Arduino/ESP32_C6_Test -iprefix /home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12/include/ @/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12/flags/includes -I/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12/qio_qspi/include -I/home/wwatson/.arduino15/packages/esp32/hardware/esp32/3.3.12/cores/esp32 -I/home/wwatson/.arduino15/packages/esp32/hardware/esp32/3.3.12/variants/XIAO_ESP32C6 @/tmp/arduino_build_387356/build_opt.h @/tmp/arduino_build_387356/file_opts /tmp/arduino_build_387356/sketch/ESP32_C6_Test.ino.cpp -o /tmp/arduino_build_387356/sketch/ESP32_C6_Test.ino.cpp.o
/home/wwatson/Arduino/ESP32_C6_Test/ESP32_C6_Test.ino:8:9: warning: "RX1" redefined
8 | #define RX1 D2 // Use these instead if you want to use Teensy Serial1
| ^~~
In file included from /home/wwatson/.arduino15/packages/esp32/hardware/esp32/3.3.12/cores/esp32/Arduino.h:202,
from /tmp/arduino_build_387356/sketch/ESP32_C6_Test.ino.cpp:1:
/home/wwatson/.arduino15/packages/esp32/hardware/esp32/3.3.12/cores/esp32/HardwareSerial.h:207:9: note: this is the location of the previous definition
207 | #define RX1 (gpio_num_t)4
| ^~~
/home/wwatson/Arduino/ESP32_C6_Test/ESP32_C6_Test.ino:9:9: warning: "TX1" redefined
9 | #define TX1 D1
| ^~~
/home/wwatson/.arduino15/packages/esp32/hardware/esp32/3.3.12/cores/esp32/HardwareSerial.h:231:9: note: this is the location of the previous definition
231 | #define TX1 (gpio_num_t)5
| ^~~
Compiling libraries...
Compiling core...
/usr/bin/env bash -c "echo -DARDUINO_CORE_BUILD > '/tmp/arduino_build_387356/file_opts'"
Using previously compiled file: /tmp/arduino_build_387356/core/variant.cpp.o
Using precompiled core: /tmp/arduino_cache_350247/core/core_6288f7990a95f877337b799e912e5a9c.a
/usr/bin/env bash -c ": > '/tmp/arduino_build_387356/file_opts'"
Linking everything together...
/home/wwatson/.arduino15/packages/esp32/tools/esp-rv32/2601/bin/riscv32-esp-elf-g++ -Wl,--Map=/tmp/arduino_build_387356/ESP32_C6_Test.ino.map -L/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12/lib -L/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12/ld -L/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12/qio_qspi -Wl,--wrap=esp_panic_handler -Wl,--wrap=esp_bt_mem_release -Wl,--wrap=esp_bt_controller_mem_release -Wl,--wrap=_ZN4chip11DeviceLayer8Internal10ESP32Utils13InitWiFiStackEv -Wl,--wrap=_Z21esp_matter_mem_callocjj -Wl,--wrap=_Z22esp_matter_mem_reallocPvj -Wl,--wrap=_Z19esp_matter_mem_freePv @/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12/flags/ld_flags @/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12/flags/ld_scripts -Wl,--start-group /tmp/arduino_build_387356/sketch/ESP32_C6_Test.ino.cpp.o /tmp/arduino_build_387356/core/variant.cpp.o /tmp/arduino_cache_350247/core/core_6288f7990a95f877337b799e912e5a9c.a @/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12/flags/ld_libs -Wl,--end-group -Wl,-EL -o /tmp/arduino_build_387356/ESP32_C6_Test.ino.elf
/home/wwatson/.arduino15/packages/esp32/tools/esptool_py/5.3.1/esptool --chip esp32c6 elf2image --flash-mode dio --flash-freq 80m --flash-size 4MB --elf-sha256-offset 0xb0 -o /tmp/arduino_build_387356/ESP32_C6_Test.ino.bin /tmp/arduino_build_387356/ESP32_C6_Test.ino.elf
esptool v5.3.1
Creating ESP32-C6 image...
Merged 3 ELF sections.
Successfully created ESP32-C6 image.
python3 /home/wwatson/.arduino15/packages/esp32/hardware/esp32/3.3.12/tools/gen_esp32part.py -q /tmp/arduino_build_387356/partitions.csv /tmp/arduino_build_387356/ESP32_C6_Test.ino.partitions.bin
/usr/bin/env bash -c "[ ! -d \"/tmp/arduino_build_387356\"/libraries/Insights ] || python3 \"/home/wwatson/.arduino15/packages/esp32/hardware/esp32/3.3.12\"/tools/gen_insights_package.py /tmp/arduino_build_387356 ESP32_C6_Test.ino \"/home/wwatson/Arduino/ESP32_C6_Test\""
/usr/bin/env bash -c "[ ! -d \"/tmp/arduino_build_387356\"/libraries/ESP_SR ] || [ ! -f \"/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12\"/esp_sr/srmodels.bin ] || cp -f \"/home/wwatson/.arduino15/packages/esp32/tools/esp32c6-libs/3.3.12\"/esp_sr/srmodels.bin \"/tmp/arduino_build_387356\"/srmodels.bin"
/home/wwatson/.arduino15/packages/esp32/tools/esptool_py/5.3.1/esptool --chip esp32c6 merge-bin -o /tmp/arduino_build_387356/ESP32_C6_Test.ino.merged.bin --pad-to-size 4MB --flash-mode keep --flash-freq keep --flash-size keep 0x0 /tmp/arduino_build_387356/ESP32_C6_Test.ino.bootloader.bin 0x8000 /tmp/arduino_build_387356/ESP32_C6_Test.ino.partitions.bin 0xe000 /home/wwatson/.arduino15/packages/esp32/hardware/esp32/3.3.12/tools/partitions/boot_app0.bin 0x10000 /tmp/arduino_build_387356/ESP32_C6_Test.ino.bin
esptool v5.3.1
Wrote 0x400000 bytes to file '/tmp/arduino_build_387356/ESP32_C6_Test.ino.merged.bin', ready to flash to offset 0x0.
/usr/bin/env bash -c "echo '--flash-mode dio --flash-freq 80m --flash-size 4MB'>'/tmp/arduino_build_387356/flash_args'&& echo '0x0 ESP32_C6_Test.ino.bootloader.bin'>> '/tmp/arduino_build_387356/flash_args'&& echo '0x8000 ESP32_C6_Test.ino.partitions.bin'>> '/tmp/arduino_build_387356/flash_args'&& echo '0xe000 boot_app0.bin'>> '/tmp/arduino_build_387356/flash_args'&& echo '0x10000 ESP32_C6_Test.ino.bin'>> '/tmp/arduino_build_387356/flash_args'"
/bin/cp -f /home/wwatson/.arduino15/packages/esp32/hardware/esp32/3.3.12/tools/partitions/boot_app0.bin /tmp/arduino_build_387356/boot_app0.bin
/home/wwatson/.arduino15/packages/esp32/tools/esp-rv32/2601/bin/riscv32-esp-elf-size -A /tmp/arduino_build_387356/ESP32_C6_Test.ino.elf
Sketch uses 263038 bytes (20%) of program storage space. Maximum is 1310720 bytes.
Global variables use 14180 bytes (4%) of dynamic memory, leaving 313500 bytes for local variables. Maximum is 327680 bytes.
defragster
Senior Member+
Almost like that was seen here - given 'redefine' conflict I just didn't use those #define's in the .begin()?
Mcu32
Well-known member
Guys... the compiler literally says where it's defined.
HardwareSerial.h, "for convenience"
u could try #undef RX1 before
HardwareSerial.h, "for convenience"
u could try #undef RX1 before
Code:
// Default pins for UART1 are arbitrary, and defined here for convenience.
#if SOC_UART_HP_NUM > 1
#ifndef RX1
#if CONFIG_IDF_TARGET_ESP32
#define RX1 (gpio_num_t)26
#elif CONFIG_IDF_TARGET_ESP32S2
#define RX1 (gpio_num_t)4
#elif CONFIG_IDF_TARGET_ESP32C2
#define RX1 (gpio_num_t)10
#elif CONFIG_IDF_TARGET_ESP32C3
#define RX1 (gpio_num_t)18
#elif CONFIG_IDF_TARGET_ESP32S3
#define RX1 (gpio_num_t)15
#elif CONFIG_IDF_TARGET_ESP32C6
#define RX1 (gpio_num_t)4
#elif CONFIG_IDF_TARGET_ESP32H2
#define RX1 (gpio_num_t)0
#elif CONFIG_IDF_TARGET_ESP32P4
#define RX1 (gpio_num_t)11
#elif CONFIG_IDF_TARGET_ESP32C5
#define RX1 (gpio_num_t)4
#elif CONFIG_IDF_TARGET_ESP32C61
#define RX1 (gpio_num_t)8
#endif
#endif
#ifndef TX1
#if CONFIG_IDF_TARGET_ESP32
#define TX1 (gpio_num_t)27
#elif CONFIG_IDF_TARGET_ESP32S2
#define TX1 (gpio_num_t)5
#elif CONFIG_IDF_TARGET_ESP32C2
#define TX1 (gpio_num_t)18
#elif CONFIG_IDF_TARGET_ESP32C3
#define TX1 (gpio_num_t)19
#elif CONFIG_IDF_TARGET_ESP32S3
#define TX1 (gpio_num_t)16
#elif CONFIG_IDF_TARGET_ESP32C6
#define TX1 (gpio_num_t)5
#elif CONFIG_IDF_TARGET_ESP32H2
#define TX1 (gpio_num_t)1
#elif CONFIG_IDF_TARGET_ESP32P4
#define TX1 (gpio_num_t)10
#elif CONFIG_IDF_TARGET_ESP32C5
#define TX1 (gpio_num_t)5
#elif CONFIG_IDF_TARGET_ESP32C61
#define TX1 (gpio_num_t)29
#endif
#endif
#endif /* SOC_UART_HP_NUM > 1 */mjs513
Senior Member+
@wwatson
Looking back at our weather app stuff I never ran into the issue because I specified RX2:
Don't believe there is anything special about speficing the pin names. Probably can even use
and then
TEENSY_SERIAL.begin(TEST_BAUD, SERIAL_8N1, teensy_rx, teensy_tx); //Port connected to Teensy 4.1
Looking back at our weather app stuff I never ran into the issue because I specified RX2:
C++:
#if defined(ARDUINO_ESP32C3_DEV)
#define RX2 20 // Connect to Teensy 4.1 TX
#define TX2 21 // Connect to Teensy 4.1 RX
#elif defined(ARDUINO_XIAO_ESP32C5)
#define serialPort Serial1
#define RX2 12 //Serial5 TX on T4.1
#define TX2 8 // Serial5 RX on T4.1
#elif defined(ARDUINO_XIAO_ESP32C6)
#define RX2 1 //Serial5 TX on T4.1
#define TX2 2 // Serial5 RX on T4.1
#endifDon't believe there is anything special about speficing the pin names. Probably can even use
C++:
#define teensy_rx 1
#define teensy_rx 2TEENSY_SERIAL.begin(TEST_BAUD, SERIAL_8N1, teensy_rx, teensy_tx); //Port connected to Teensy 4.1
KenHahn
Well-known member
On the ESP32, the ability to arbitrarily remap all the pin functions is both a strength and a source for confusion. Even the same processor like the ESP32C6 comes in many different module pin configurations with different GPIO brought out to the edge pins to do the exact same function.
For instance in the config file above, this line is OK for some of the larger variants, but GPIO 4 is not even brought out on the tiny XIAO modules. It uses GPIO 17 as the default RX1 pin.
@mjs513 suggestion to just stay clear of using the same RX1/TX1 name is probably the easiest solution. Or be like me and treat compiler warnings the same way as I treat speed limit signs. I see them go by, but I don't pay much attention to what they are telling me ;~)
For instance in the config file above, this line is OK for some of the larger variants, but GPIO 4 is not even brought out on the tiny XIAO modules. It uses GPIO 17 as the default RX1 pin.
Code:
#elif CONFIG_IDF_TARGET_ESP32C6
#define RX1 (gpio_num_t)4@mjs513 suggestion to just stay clear of using the same RX1/TX1 name is probably the easiest solution. Or be like me and treat compiler warnings the same way as I treat speed limit signs. I see them go by, but I don't pay much attention to what they are telling me ;~)
Mcu32
Well-known member
No Problem
Just take it as a hint that the compiler is telling you where to look. Regardless of the microcontroller.
Well, the warnings do serve a purpose. That's the only reason they exist
I even use -Werror. That way, warnings are treated as errors, and I don't miss a thing. In the end, that often saves me a lot of time.