microReticulum as used on the LilyGo T-Beam SUPREME
John Poole
ee8b42a020
In the “full main.cpp” I gave you, dumpSdPins() did this:
pinMode(SCK, INPUT_PULLUP);
pinMode(MISO, INPUT_PULLUP);
pinMode(MOSI, INPUT_PULLUP);
…and you were calling dumpSdPins("after-idle-clocks") inside tryMountWithBus(), after bus.begin() and the 0xFF idle clocks, but before SD.begin().
That means: right before SD.begin(), you were accidentally turning the SPI pins back into inputs. The card then can’t respond, so you get endless:
sdCommand(): Card Failed! cmd: 0x00
f_mount failed: (3) The physical drive cannot work
That matches your new log perfectly.
|
||
|---|---|---|
| docs | ||
| exercises | ||
| external | ||
| firmware/fieldtest_beacon | ||
| img | ||
| shared/boards | ||
| tools | ||
| .gitignore | ||
| .gitmodules | ||
| CMakeLists.txt | ||
| LICENSE | ||
| README.md | ||
microReticulumTbeam
microReticulum For Field Testing With LilyGo T-Beam SUPREMES
Field Testing Only. Used to specially program a group of T-Beams, each having the others' contact information and keys, which are then deployed in the field with people moving about to capture what was successfully sent and received and at what coordinates. Data is stored on SD cards and then retrieved at the end of the test an dumped into a PostgreSQL databse for analysis.
Dependency Direction
This repo is migrating from external/microReticulum to external/microReticulum_Firmware.
Goal:
- Reuse upstream T-Beam SUPREME integration work in
microReticulum_Firmware. - Avoid reimplementing already-solved board integration (PMU, SD, RTC, GPS, LoRa setup).
Status:
- Migration plan is tracked in
docs/microreticulum_firmware_migration.md. - Existing exercises remain functional during migration.