Fix ESP8266 for Octopus PRO v1.1/H723 #26992
Conversation
|
I see the test pipeline fails because it's expecting the ESP32 when enabling the wifi. In this case what I'm doing is to run Marlin in the BTT Octopus PRO and using SERIAL_2 to communicate over wifi with ESP3D (version 2) (Excuse the lack of a proper pcb. I just had the module around. Put some double sided tape, and soldered the pins to on a proto board to simulate MKS or BTT style esp board) I need to run the esp_wifi init method, but I won't be using OTA updates nor web support, nor esp3dlib custom commands parser. |
dc740
changed the title
Yes. You’d normally flash these modules with ESP3D so they’d run their own firmware. Then you’d enable the associated serial port and Marlin would communicate via serial without needing to enable |
|
Also, please don't break ESP32 WiFi / ESP3DLib support 😄 I don't think Luc could deal with us breaking support again since I just fixed it in #26822. |
|
In that case, I don't know what's the right way to proceed.
Maybe expanding marlin with yet-another-configuration-flag to allow
external wifi modules independent of those boards? I assumed the generic
WIFISUPPORT flag would let me run the init code for the module and the
esp3dwifi flag would expand on to specific boards that run on esp3dlib.
What would be the right way to use an esp8266 or esp32 as add-on? Right now
the octopus board works fine with my modification (I haven't used it yet,
but it does work). I'd hate to have a custom marlin version just for that
purpose.
The other alternative would be to modify the hardware to have all these pins set by default and soldered in their definitive status, and Marlin would not need to be modified to initialize them, but then if I ever want to enable SPI communication or swap to another firmware, I'd have to revert the HW modifications.
|
|
@thisiskeithb there are an awful lot of non-ESP32 pins files which include So what is the state of things then? WIFISUPPORT used to work (meaning perform the various pin initializations in Has that been broken since this commit way back in 2020 that moved those library inclusions from the There was another commit just a few weeks before that which clearly shows it was intended to compile and do things on non-ESP32 environments. The comments from the PR for this mention it fixing issues on the SKR Pro. Well this just gets more and more interesting the deeper you look. @ellensp has already logged information about this issue in #26624... |
|
OK, it seems this is way bigger than I expected. Lets keep this MR open, and continue the discussion in #26624 |
|
The net change in this PR is now limited to defining a |
|
Just adding support for this pin does not solve the underlying issue, which is that it tries to pull ESP32 dependencies into non-ESP32 builds. |
… when That shouldn’t be enabled since you’re expected to flash the ESP3D firmware to the Wi-Fi module directly and it’ll communicate with Marlin over an enabled serial port. |
This entire init function is inside an |
|
This goes back to the entire/main issue of what is "Wi-Fi Support" outlined in #26624. |
|
I ordered the official btt wifi module to evaluate the port usage. Should
be arriving in a week. My initial guess is that it is also required because
reprap firmware also sets gpio15 and it's more documented on their source
code too.
Regarding the init function. It is required to be present when these boards
are used as add-on. Otherwise the pins that define the boot mode won't be
set and it will simply fail to boot. No matter how the module is flashed,
these pins are used by the bootloader. (You can also double check how they
handle it in other firmwares)
I will send a second PR addressing the wifi support flag over the weekend.
There is no need to include all those libraries when using the module as
add-on either. So importing them when enabling WIFISUPPORT is overkill.
They are only needed in the other use case.
I understand the original intention of the flag was different (wifi support
meant running in an esp32 based boards) but it needs to change if we want
Marlin to support boards like the btt octopus or any other board that has
wifi as a module and it's not esp based.
El mié, 24 abr 2024, 5:23, Keith Bennett ***@***.***>
escribió:
… This goes back to the entire/main issue of what is "Wi-Fi Support"
outlined in #26624 <#26624>
.
—
Reply to this email directly, view it on GitHub
<#26992 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEFM2CKCLUNXERJYWAMZ6DY64QU5AVCNFSM6AAAAABGRACPNOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZTHE2DAOJQGQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I’ve used BTT’s Wi-Fi module (labeled ESP8266 on the PCB and ESP-12S on the metal shield on the top) flashed with ESP3D on an Octopus board without an issue. The only thing I had to enable was a serial port and ESP3D on the Wi-Fi module could communicate just fine. |
|
Using current minimum diff without WIFISUPPORT:
diff --git a/Marlin/Configuration.h b/Marlin/Configuration.h
index 72ec272..4e479ed 100644
--- a/Marlin/Configuration.h
+++ b/Marlin/Configuration.h
@@ -68,7 +68,7 @@
// Choose the name from boards.h that matches your setup
#ifndef MOTHERBOARD
- #define MOTHERBOARD BOARD_RAMPS_14_EFB
+ #define MOTHERBOARD BOARD_BTT_OCTOPUS_PRO_V1_0
#endif
/**
@@ -79,7 +79,7 @@
*
* :[-1, 0, 1, 2, 3, 4, 5, 6, 7]
*/
-#define SERIAL_PORT 0
+#define SERIAL_PORT -1
/**
* Serial Port Baud Rate
@@ -92,7 +92,7 @@
*
* :[2400, 9600, 19200, 38400, 57600, 115200, 250000, 500000, 1000000]
*/
-#define BAUDRATE 250000
+#define BAUDRATE 115200
//#define BAUD_RATE_GCODE // Enable G-code M575 to set the baud rate
@@ -101,7 +101,7 @@
* Currently Ethernet (-2) is only supported on Teensy 4.1 boards.
* :[-2, -1, 0, 1, 2, 3, 4, 5, 6, 7]
*/
-//#define SERIAL_PORT_2 -1
+#define SERIAL_PORT_2 3
//#define BAUDRATE_2 250000 // :[2400, 9600, 19200, 38400, 57600, 115200, 250000, 500000, 1000000] Enable to override BAUDRATE
/**
@@ -2931,7 +2931,7 @@
// RepRapDiscount FULL GRAPHIC Smart Controller
// https://reprap.org/wiki/RepRapDiscount_Full_Graphic_Smart_Controller
//
-//#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
+#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
//
// K.3D Full Graphic Smart Controller
diff --git a/platformio.ini b/platformio.ini
index 76200cb..7f4f73c 100644
--- a/platformio.ini
+++ b/platformio.ini
@@ -13,7 +13,7 @@
[platformio]
src_dir = Marlin
boards_dir = buildroot/share/PlatformIO/boards
-default_envs = mega2560
+default_envs = STM32F429ZG_btt
include_dir = Marlin
extra_configs =
Marlin/config.ini
Screenshot from the ESP3D interface after sending M115: I've also tested this BTT ESP module on an Octopus Max EZ and it works as expected. |
|
wow, those are very interesting results. Then the module either has a newer chip version (remember I found this module in a drawer, I think I bought them when they started to become popular years ago), or the module already has CS to GND, so it always boot into Run mode. Nice. I can't wait for the module to better understand this. I want to see the differences in hardware. (then I will check the datasheets. It's been a busy week) This means that the MR can be merged for now. I will still need to keep wifisupport enabled for the init code to run on my current setup, but that's expected. I will leave the rest of the discussions on #26624 |
|
MKS' ESP8266/ESP12S modules work the same way, so I think all of the ESP modules from these OEMs work without the changes in this PR. The older generic ESP8266/ESP-01 modules (with 8-pins) also work fine on older motherboards when flashed with ESP3D and enabling a valid serial port in Marlin. |
I hesitate to agree because this is for a one-off/custom module and not standard hardware. We already get repeated support questions related to standard ESP8266/ESP12S/ESP-01 modules from MKS & BTT and whether |
|
the 8 pin ones don't expose GPIO15 at all, so it comes pulled down by default. I keep wondering why reprap does initialize this port, and why I was the first one to hit this case (or if others simply assumed it was not compatible). My only theory so far is that newer chips don't have this requirement. But that's just a guess. I will dig into this over the weekend. I don't want to waste anyone's time. |
|
For reference, the documentation states that GPIO15 must be pulled down in order to boot: This explains why RepRap is already doing it. It's the right thing to do. But I will just wait for the module to arrive to check if they are pulling GPIO15 down on hardware, or they let it floating and it just boots for no apparent reason and my quick and dirty protoboard just exposed the issue. |
Testing BTT's ESP8266/ESP-12S module here & I can access the ESP3D UI with with just 3.3V and GND connected (comms with motherboard obviously doesn't exist). GND and CS pin don't appear to have continuity on the module or motherboard, so maybe they're just floating. 🤷♂️ |
|
Hi, I got the module on the email this morning. The newer chips already have a resistor to ground, this is why the BTT and MKS modules are booting fine. Here is what I read on ESP-07S And this is the schematic I use to flash the old one (plain ESP2866MOD) that doesn't come with GPIO15 pulled low by default: I will add a 10k resistor on my module so this MR can be closed. I still wonder if we should also pull GPIO15 down to follow the documentation instead of leaving it to the hardware implementation. All in all, this has been sorted out and we now have all the information required. The ESP modules booting process is really something. |
I don't think it makes sense to add this change for a single motherboard, especially since the issue only exists with a non-standard ESP install. ESP modules from each board vendor are designed to work without the change. The great debate about what "WIFISUPPORT" means will continue in #26624... |
Description
Add ESP8266 support for the Octopus PRO board. I tested it on the H723 version.
From what I could see in the BTT store, only the ESP-07S is sold for the Octopus Pro, however, the ESP8266MOD from the picture can be used as-is by making sure GPIO15 is properly set for the normal boot mode. Of course we are using it from the serial port instead of SPI as other firmwares, but it's still very handy.
Boot modes are defined by setting GPIO0,GPIO2 and GPIO15. The thing is, SOME boards don't need GPIO15, but others do. Which I assume is the reason not many people hit this bug. (more details below)
This is a board I had from many years ago:
Turns out the pinout is compatible with ESP 07S and ESP12, but these must have something different than the barebones 8266 from the picture, because the BTT store sells it as supported while the 8266 is listed for the SKR 2 only. The board is currently working as expected after my changes though.
Regarding boot modes.
(I found this on the internet, I didn't read the datasheet.)
Considering GPIO[0-2-15], then:
0-1-0: flash mode (for programming it)
1-1-0: Normal boot from flash (the mode we want)
0-0-1: boot from SD
The bug is that GPIO15 is not LOW, so the board hangs in the bootloader "waiting for the host".
After making these changes I was able to connect to the web server and the display shows the output from the ESP commands (like the IP it has been assigned)
Regarding the features.ini change:
The issue is that we need WIFISUPPORT in order to run the pins setup and restart the ESP8266, but it was trying to compile a lot of libraries that (AFAIK) are only required when you use the actual ESP as the main system. I was able to compile the firmware by removing the unneeded dependencies.
Requirements
ESP8266.
Benefits
Adds support for the ESP8266 on the Octopus Pro v1.1
Configurations
Just enable WIFISUPPORT
Related Issues
None that I could find.