M5Stack Cardputer Adv
- Implemented mostly by @Szetya in #7985
- This is NOT the "Meshtastic For Cardputer-Adv" on M5Burner, that firmware is closed source currently in violation of Meshtastic's GPLv3, and M5Stack said "There is no open source code yet, we are still optimizing", see #7989 and the discord for more info
- Whether or not they will opensource and upstream their "optimizations" will remain to be seen, in the meantime I thought I'd open a PR with @Szetya's code since it atleast makes the device work so we can do our own community work on it, I for one want to improve keyboard support for it like in #7989 (feel free to merge either one of these PRs first, I will update the other accordingly with the keyboard improvements for Cardputer Adv shortly after)
- I do not have a device myself to test, am acting as a proxy between someone who does (my friend and youtuber sn0ren) to get feedback
- What I heard is "it works" from sn0ren and @Szetya mentioned sound is not working yet and also that they need to agree with @mverch67 on which display driver to use
- Apologies for opening the PR myself when I had little to do with the development, I just wanted to get things moving to then improve the keyboard for this device too, but feel free to close and open another PR yourself if that works better
- Needs https://github.com/meshtastic/protobufs/pull/776 merged first and then an update to protobufs submodule to match the merged commit
🤝 Attestations
- [x] I have tested that my proposed changes behave as described.
- [ ] I have tested that my proposed changes do not cause any obvious regressions on the following devices:
- [x] Heltec (Lora32) V3
- [ ] LilyGo T-Deck
- [ ] LilyGo T-Beam
- [ ] RAK WisBlock 4631
- [ ] Seeed Studio T-1000E tracker card
- [ ] Other (please specify below)
- [x] LilyGo T-Lora Pager
- [x] M5Stack Cardputer Adv
Thanks for putting the PR up.
Afaik the module for the Cardputer Adv doesn't have a TCXO, should it need #define SX126X_DIO3_TCXO_VOLTAGE 1.8?
I made my own module using a Ra-01SH and I had to remove that for it to work.
@WillyJL Could you correct the capital letters "n," "o," and "k"? I was careless and wrote them in lowercase, which I noticed later. Thank you. 😉
Would it be possible to remove the GPS_BAUDRATE definition, to let the autodetection find the right baudrate instead of a static one?
Would it be possible to remove the GPS_BAUDRATE definition, to let the autodetection find the right baudrate instead of a static one?
Yes, it works, but boot time takes much longer. You may need to change the GPS baud rate using the u-center program.
Would it be possible to remove the GPS_BAUDRATE definition, to let the autodetection find the right baudrate instead of a static one?
Yes, it works, but boot time takes much longer. You may need to change the GPS baud rate using the u-center program.
That makes sense, ended up using ubxtool from gpsd to change it to 115200 :)
Enable Screen Options. Screen color and brightness. I increased the minimum brightness value from 64 to 80 because the LEDs did not turn on at 64. (I haven't been able to deal with the sound yet. With an MCLK value of -1 for ES8311, should it automatically use the internal clock signal?) MenuHandler.zip (MenuHandler.cpp formatting did not occur.)
You need to set MCLK to any free GPIO.
You need to set MCLK to any free GPIO.
I tried, but there is no sound. (extra variant is a copy of the T-LoRa pager). If I select a free GPIO, at least I don't get an error message from the audiodriverlogger.
INFO | 18:26:16 19 [Router] externalNotificationModule - Notification Module (Buzzer)
If MCLK is -1, I receive an error message.
E (13499) I2S: i2s_check_set_mclk(266): mck_io_num invalid
E (13499) I2S: i2s_set_pin(314): mclk config failed
must be able to use the internal MCLK. https://github.com/pschatzmann/arduino-audio-driver/blob/c8e422b590848359243a529a29fa15bbaec08e3f/src/Driver/es8311/es8311.c#L303
Well, I managed to fix the sound.
- The DAC_I2S_DOUT and DAC_I2S_DIN pins had to be swapped.
- The MCLK pin cannot be -1.
- Some extra initialization from M5Unified. (Is it necessary or not?! I haven't tried it without it.)
However, it seems that the message melody is not playing all the way through. Also, the status of notifications - buzzer actions in the BaseUI menu has no effect on it. The only thing missing, if it makes sense, is the BMI270 IMU.
// audio codec ES8311
#define HAS_I2S
#define DAC_I2S_BCK 41
#define DAC_I2S_WS 43
#define DAC_I2S_DOUT 42
#define DAC_I2S_DIN 46
#define DAC_I2S_MCLK 0 // Not connected, dummy PIN. It has no effect on the push button.
#define DAC_I2S_MCLK 0 // Not connected, dummy PIN. It has no effect on the push button.
Note that it does have an effect on the push button in case the device goes into powersave/light sleep. In case a message arrives and the user presses the button while the sound is playing the firmware will crash. This is because the button GPIO is an input GPIO but the audio module will program it as output GPIO.
#define DAC_I2S_MCLK 0 // Not connected, dummy PIN. It has no effect on the push button.
Note that it does have an effect on the push button in case the device goes into powersave/light sleep. In case a message arrives and the user presses the button while the sound is playing the firmware will crash. This is because the button GPIO is an input GPIO but the audio module will program it as output GPIO.
PINs 45 and 47 are available. You can assign them to these. Of course, if you have any suggestions or advice, I will take them into consideration and proceed accordingly. You have given me lots of useful advice and information so far.
#define DAC_I2S_MCLK 0 // Not connected, dummy PIN. It has no effect on the push button.
Note that it does have an effect on the push button in case the device goes into powersave/light sleep. In case a message arrives and the user presses the button while the sound is playing the firmware will crash. This is because the button GPIO is an input GPIO but the audio module will program it as output GPIO.
#define DAC_I2S_MCLK 45 // Not connected, dummy PIN It works perfectly. @mverch67 Thank you for all the advice and tips!
Another suggestion if you actually want to be able to use i2c devices using the grove port, since the standard i2c lines get covered by the lora cap:
// Custom port I2C1 or UART #define G1 1 #define G2 2
// Secondary I2C for external sensors #define I2C_SDA1 G2 #define I2C_SCL1 G1
Another suggestion if you actually want to be able to use i2c devices using the grove port, since the standard i2c lines get covered by the lora cap:
// Custom port I2C1 or UART #define G1 1 #define G2 2
// Secondary I2C for external sensors #define I2C_SDA1 G2 #define I2C_SCL1 G1
I deliberately did not define it. However, I wanted to make it visible as information. Precisely so that there would be a choice. The default I2C is available on the CAP port. (It can be set to UART2 during runtime. However, if I reserve it for Wire1, the UART2 option will be lost. It can still be changed to Wire1 later if necessary. But as I mentioned, Wire is available on the pin header.)
I have a Cardputer ADV + LoRA Cap and I'd love to help any way I can. Is checking out your feat/m5stack-cardputer-adv branch the best way to start building/testing this before contributing to the effort?
Another suggestion if you actually want to be able to use i2c devices using the grove port, since the standard i2c lines get covered by the lora cap: // Custom port I2C1 or UART #define G1 1 #define G2 2 // Secondary I2C for external sensors #define I2C_SDA1 G2 #define I2C_SCL1 G1
I deliberately did not define it. However, I wanted to make it visible as information. Precisely so that there would be a choice. The default I2C is available on the CAP port. (It can be set to UART2 during runtime. However, if I reserve it for Wire1, the UART2 option will be lost. It can still be changed to Wire1 later if necessary. But as I mentioned, Wire is available on the pin header.)
Unfortunately if you have a M5 LoRa Cap attached, you cant access the standard I2C lines, I wonder if there's a UI option suggested to gave a second set of I2C pins?
Unfortunately if you have a M5 LoRa Cap attached, you cant access the standard I2C lines, I wonder if there's a UI option suggested to gave a second set of I2C pins?
That's true. Although I don't know why you would need a Wire bus? Maybe a BME280 would fit. Or you could replace the connector with a pin header and there would be room for further expansion on top of the CAP (photo)?!
Unfortunately, I don't know if it would be possible to define a custom Wire1 bus. But similarly, it would be very good for UART configuration. For example, as an option in the telemetry menu.
I got it all working in my fork but I'm not great at github, feel free to look, i used m5's env pro bme688, and i got the accelerometer to wake the screen.
That's true. Although I don't know why you would need a Wire bus? Maybe a BME280 would fit. Or you could replace the connector with a pin header and there would be room for further expansion on top of the CAP (photo)?! Unfortunately, I don't know if it would be possible to define a custom Wire1 bus. But similarly, it would be very good for UART configuration. For example, as an option in the telemetry menu.
I have the M5stack ENV.IV (BMP280/SHT40) hooked up to my grove port currently, which I then attach with LEGO connectors to the back, using the I2C_SDA/SCL1 setup... Interesting thought modifying the CAP though
I got it all working in my fork but I'm not great at github, feel free to look, i used m5's env pro bme688, and i got the accelerometer to wake the screen.
Looking at your fork, you can definitely simplify the wire1 stuff, with the following in the varient.h file #define I2C_SDA1 G2 #define I2C_SCL1 G1
I'm testing your IMU BMI270 stuff now
I got it all working in my fork but I'm not great at github, feel free to look, i used m5's env pro bme688, and i got the accelerometer to wake the screen.
Looking at your fork, you can definitely simplify the wire1 stuff, with the following in the varient.h file #define I2C_SDA1 G2 #define I2C_SCL1 G1
I'm testing your IMU BMI270 stuff now
I was experimenting yes, if the normal way works ok ignore that, feel free to mess with what I have but I can't take credit as I got a bit of help to get that working XD
I have the M5stack ENV.IV (BMP280/SHT40) hooked up to my grove port currently, which I then attach with LEGO connectors to the back, using the I2C_SDA/SCL1 setup... Interesting thought modifying the CAP though
The Wire1 solution is ingenious. This way, the port remains usable even when nothing is connected to it. I tried it as UART2 for a standalone UI. It's a crazy solution, but it works. 😂
I've been testing this for a few weeks on my ADV. Took it to downtown Austin during the ACL Music Festival. Made plenty of contacts. Overall the build is stable, but for some reason the battery isn't charging in my Cardputer while running it. It'll say 100% while plugged in and just die when I unplug it now. Switched over to my NEMO firmware and the battery is charging fine so doesn't appear to be a hardware issue. That's the only thing I've seen that's amiss so far.
FYI, I've submitted some changes to this PR at: https://github.com/WillyJL/meshtastic-firmware/pull/1
FYI, I've submitted some changes to this PR at: WillyJL#1
would be nice if ESC key (#0) would be also included to the context-aware key set
