Hey Johnathon, Finally someone did something about this. I'm re-doing all my ESP32 projects with your Header, and removing all the USB UART's from my projects.
Great idea. I implement the esp programming header as a tag connect tc2030 for two reasons. First, it does not need a physical connector. Second it is a "singe sided" connector. But for one-offs the price of the cable is a bit high.
I'm usually done with 3 pins - RX/TX/GND (GND for correct reference). IO0 is exposed as tact switch button and is also used to trigger WiFi config mode in application (general purpose button). Power is delivered via power-only USB port. If you want to flash device, simply connect USB2Serial converter, press and hold tact switch and then connect power. This has some disadvantages, as it requires user to handle that manually, but I'm only using this for initial flash or recovery from bootloop in case of crashes - usually flashing via OTA.
Sounds great, i'm onboard, i have a few boards I'm working on currently so will adopt this standard. I'll create a header for EasyEDA when i get a moment too.
Looking forward to ESPFlash coming to future ESP8266/ESP32 boards... a 'simple' standard that makes all the necessary connections available in one place. I have the ESPFlasher programmer, just need some boards to use it with! :D
I use the same but with vcc and gnd flipped, because you do not always need vcc, so its on the end not in the middle. auto reset pins go on the other end the gnd end.
It is wEsp I think , I used it because it nests from 2 pin to 6 pin, tx only, manual rx tx, auto tx rx, all with optional vcc, you could even stick a 5 pin nest with remote reset also
Probably too late now that it's been published, but any reason not to make the 2-wide footprint compatible with something that's already standard? The SWD footprints for ARM already have a strong foothold.The pin names are different, but mapping VCC/ESP_RX/ESP_EN/ESP_IO0/GND/ESP_TX onto VCC/SWDIO/nRESET/SWCLK/GND/SWO gives you enough compatibility that connecting the wrong debugger won't hurt anything (assuming VCC is 3.3v instead of 5v), and it's easier to make use of existing ecosystem around ARM, vendors already make the cables, there's also overlap to JTAG connections, third party derivatives like the 0.05" tag-connect devices, and the 10-pin SWD (adds GND/GNDDetect/NC/NC) connection; it also makes it easier to go back and forth between ESP and ARM (and potentially Risc-V, which would be expected to be compatible with ARM where there's no reason not to be).
That would be really nice, but because Espressif themselves already make the ESP-PROG with its 2x3 header I didn't want to deviate from that. It's the closest thing we have to an "official" programming header standard for ESP chips.
@@SuperHouseTV Ahh, I missed that somehow. I think I took the video as "Espressif makes an official connector, but no one uses it so we'll just ignore it" which seems completely unrelated to what you'd actually said. Even going to a 2x5, adding to the edges like you're doing for the 1x4->1x6 header would still keep it from playing nice with ARM SWD. Another chance for edge connectors with debug-edge.io/ ?
I was wondering what came of this project. I must say in the meantime that I came to basically exactly the same conclusions, including 3.3V power and separate 1x6 and 2x3 layouts, and especially that the espressif 2x3 0.05" connector is the best one to implement onboard. For the programmer board, I think that the jumper option for 5V, 3.3V or no power is a idea, on balance. Especially the option for no power so that it's safe to connect with external power to the target board anyway. The main reason I'm against requiring 5V power on the header is that there are plenty of applications where you don't want a 5V-to-3.3V regulator on the target board. However, having 5V as an option might be useful in some cases.
Labelling is a very important point, thanks. In my EAGLE footprints it has "ESPFlash" next to it, but labels will depend on board space. What I should do is expand the page with the header definition to include examples of labels.
As you are going to be powering the board while programing, so what are you looking at power wise for you programer? I use a 3 pin header alot as the board will be powered by it's own supply so I only need 0V, TX, and RX. I get around this by having a set of different programing cables. I think there are too many ways that are out in the wild so any change is going to be hard.
Hi Jonathan, Thanks for the amazing video and helpful info. I have two question 1-What platform do you use for home automation.(i.e. Home Assistant) 2-Can you please share the link to purchase that rack-mount plastic enclosure you used in SuperHouse #25 video.(I can not find it)
I can't order the ESPFlasher because I live in the USA and you aren't shipping out of country. Is there another way to order one? If not how do you take your github schematic and board design and have a PCB manufacturer make them? I get an error on the schematic that the libraries used aren't available.
man, even FTDI adapters are not standard: some are GND, TX, RX, some are GND, RX, TX - I thought it was only me having the issue but it seems it is a big one ;-)
Hi Jonathan, Thanks for mentioning the work I did related to this with the wESP32 in your video! I like your XKCD reference as well, I think it's applicable here. :) What I still don't understand is how you deal with feeding 3.3V into a board that may already be supplying 3.3V itself (or not, in which case you reverse bias its regulator). In my experience most regulators are not very happy with this situation. This is why my header supplies 5V through a diode, which can be diode OR'ed with any other supply through a diode, and then gets regulated by the board's own 3.3V regulator. Would you explain how you deal with this? It doesn't cause issues?
Thanks for making the wESP32, it's a great board! I usually use a linear 3.3V reg for final supply, even if I use a SMPS to drop a higher input voltage (say 12V) down to 5V first. Linear regs are typically quite happy being back-powered. In the case of a board that can't handle power being supplied externally, such as an onboard 3.3V SMPS that doesn't have backpower protection, I'd treat that as a special case and leave the 3.3V pin disconnected on the ESPFlash header on the target board. Then you'd *have* to use the onboard power supply while it's being programmed, rather than use power from the programmer.
Another reason to go for a 5V input on the header is that you may have the 3v3 regulator close to where it is being used and not trying to get 3v3 @ peak currents of upto 500 mA (short surges during RF calibration on the ESP's) through flimsy thin dupont wires and connectors which not always make the best contact. Also a lot of programming boards you may buy nowadays seem to be competing with eachother to find the voltage regulator with the lowest allowed max. current. So even if people try to use this "ESPflash" header by making their own jumper cable, you still have to deal with flaky voltage regulators. @Patrick, I love the slight offset you used for the programming header to make it stick without soldering. I will also start using that on my own boards for ESPEasy board designs as it may also be useful for quick testing of sensors without soldering and using extra headers.
Power supply capacity is a very good point. I should add a note on the spec page so suggest that any implementations of the programmer should include up to 600mA available on the 3.3V line.
How do I solve the GPIO 00, 02, etc HIGH at boot of esp8266? The relays connected to these pins flicker at boot. I am trying to make a smart switch that use 4 relays and 4 switches. But out of the usable pins, only 5 are 'safe pins'. How would one connect 4 switches taht could be in either on or OFF state and relays too. Please help.
You could use ADC0 with a resistor ladder to put all the buttons onto a single input pin. Or use GPIO0, 2, 16, and ADC0 for inputs (active low) and still have GPIO4, 5, 12, 13, and 14 available.
@@SuperHouseTV In case of GPIO0,2,16, if the switch position is low, then the boot would fail. So those would not be ideal for input. I was thinking of putting some circuit on them to use with relays so that they dont flicker at boot. As I understand, these pins are HIGH for about 200ms at boot. I read about adding capacitor across the optocoupler of relay, but it didn't work.
ITEAD are very aware that reflashability is the reason they became popular in the first place. They went to the trouble of adding "DIY mode" with a jumper to simplify reflashing, so they seem quite supportive of it.
As you were explaining the 4 different options, I was thinking he needs an adapter, and voilà there it is.
Hey Johnathon, Finally someone did something about this. I'm re-doing all my ESP32 projects with your Header, and removing all the USB UART's from my projects.
YEEEEEESSSSSS! I'm just an end user, not a board developer, but I heartily support this!
Great idea. I implement the esp programming header as a tag connect tc2030 for two reasons. First, it does not need a physical connector. Second it is a "singe sided" connector. But for one-offs the price of the cable is a bit high.
Nicely done! Well thought out design. I look forward to using it on my projects. Thanks!
Thanks George!
Thank you very much. Hoping they do as you suggest.
I'm usually done with 3 pins - RX/TX/GND (GND for correct reference). IO0 is exposed as tact switch button and is also used to trigger WiFi config mode in application (general purpose button). Power is delivered via power-only USB port. If you want to flash device, simply connect USB2Serial converter, press and hold tact switch and then connect power.
This has some disadvantages, as it requires user to handle that manually, but I'm only using this for initial flash or recovery from bootloop in case of crashes - usually flashing via OTA.
So nice
Another awesome video!
Sounds great, i'm onboard, i have a few boards I'm working on currently so will adopt this standard. I'll create a header for EasyEDA when i get a moment too.
That's great, thanks Colin! I'd love to have the footprint available for more CAD formats.
Looking forward to ESPFlash coming to future ESP8266/ESP32 boards... a 'simple' standard that makes all the necessary connections available in one place. I have the ESPFlasher programmer, just need some boards to use it with! :D
great video, Now I feel that esp32 is more cost-effective.
I use the same but with vcc and gnd flipped, because you do not always need vcc, so its on the end not in the middle. auto reset pins go on the other end the gnd end.
I should add that to my spreadsheet of header variations.
It is wEsp I think , I used it because it nests from 2 pin to 6 pin, tx only, manual rx tx, auto tx rx, all with optional vcc, you could even stick a 5 pin nest with remote reset also
Love the idea, My only concern is on the 2x3 is GND and 3.3v are right next to each other and too easy to short if probing when testing
True, but that pinout was set by Espressif years ago so I just went with what they already had.
Probably too late now that it's been published, but any reason not to make the 2-wide footprint compatible with something that's already standard? The SWD footprints for ARM already have a strong foothold.The pin names are different, but mapping VCC/ESP_RX/ESP_EN/ESP_IO0/GND/ESP_TX onto VCC/SWDIO/nRESET/SWCLK/GND/SWO gives you enough compatibility that connecting the wrong debugger won't hurt anything (assuming VCC is 3.3v instead of 5v), and it's easier to make use of existing ecosystem around ARM, vendors already make the cables, there's also overlap to JTAG connections, third party derivatives like the 0.05" tag-connect devices, and the 10-pin SWD (adds GND/GNDDetect/NC/NC) connection; it also makes it easier to go back and forth between ESP and ARM (and potentially Risc-V, which would be expected to be compatible with ARM where there's no reason not to be).
That would be really nice, but because Espressif themselves already make the ESP-PROG with its 2x3 header I didn't want to deviate from that. It's the closest thing we have to an "official" programming header standard for ESP chips.
@@SuperHouseTV Ahh, I missed that somehow. I think I took the video as "Espressif makes an official connector, but no one uses it so we'll just ignore it" which seems completely unrelated to what you'd actually said. Even going to a 2x5, adding to the edges like you're doing for the 1x4->1x6 header would still keep it from playing nice with ARM SWD.
Another chance for edge connectors with debug-edge.io/ ?
Interesting, I haven't seen Debug Edge before! Thanks for the pointer.
I was wondering what came of this project. I must say in the meantime that I came to basically exactly the same conclusions, including 3.3V power and separate 1x6 and 2x3 layouts, and especially that the espressif 2x3 0.05" connector is the best one to implement onboard.
For the programmer board, I think that the jumper option for 5V, 3.3V or no power is a idea, on balance. Especially the option for no power so that it's safe to connect with external power to the target board anyway. The main reason I'm against requiring 5V power on the header is that there are plenty of applications where you don't want a 5V-to-3.3V regulator on the target board. However, having 5V as an option might be useful in some cases.
Also call out a silk screen standard or logo, maybe just “Esp32Flash” would be good? Guess I should redesign my header and programmer now:)
Labelling is a very important point, thanks. In my EAGLE footprints it has "ESPFlash" next to it, but labels will depend on board space. What I should do is expand the page with the header definition to include examples of labels.
As you are going to be powering the board while programing, so what are you looking at power wise for you programer? I use a 3 pin header alot as the board will be powered by it's own supply so I only need 0V, TX, and RX. I get around this by having a set of different programing cables.
I think there are too many ways that are out in the wild so any change is going to be hard.
My version of the programmer has a 3.3V regulator and takes power from USB.
Hi Jonathan, Thanks for the amazing video and helpful info. I have two question
1-What platform do you use for home automation.(i.e. Home Assistant)
2-Can you please share the link to purchase that rack-mount plastic enclosure you used in SuperHouse #25 video.(I can not find it)
I can't order the ESPFlasher because I live in the USA and you aren't shipping out of country. Is there another way to order one? If not how do you take your github schematic and board design and have a PCB manufacturer make them? I get an error on the schematic that the libraries used aren't available.
man, even FTDI adapters are not standard: some are GND, TX, RX, some are GND, RX, TX - I thought it was only me having the issue but it seems it is a big one ;-)
Hi Jonathan,
Thanks for mentioning the work I did related to this with the wESP32 in your video! I like your XKCD reference as well, I think it's applicable here. :)
What I still don't understand is how you deal with feeding 3.3V into a board that may already be supplying 3.3V itself (or not, in which case you reverse bias its regulator). In my experience most regulators are not very happy with this situation. This is why my header supplies 5V through a diode, which can be diode OR'ed with any other supply through a diode, and then gets regulated by the board's own 3.3V regulator. Would you explain how you deal with this? It doesn't cause issues?
Thanks for making the wESP32, it's a great board! I usually use a linear 3.3V reg for final supply, even if I use a SMPS to drop a higher input voltage (say 12V) down to 5V first. Linear regs are typically quite happy being back-powered. In the case of a board that can't handle power being supplied externally, such as an onboard 3.3V SMPS that doesn't have backpower protection, I'd treat that as a special case and leave the 3.3V pin disconnected on the ESPFlash header on the target board. Then you'd *have* to use the onboard power supply while it's being programmed, rather than use power from the programmer.
Another reason to go for a 5V input on the header is that you may have the 3v3 regulator close to where it is being used and not trying to get 3v3 @ peak currents of upto 500 mA (short surges during RF calibration on the ESP's) through flimsy thin dupont wires and connectors which not always make the best contact.
Also a lot of programming boards you may buy nowadays seem to be competing with eachother to find the voltage regulator with the lowest allowed max. current. So even if people try to use this "ESPflash" header by making their own jumper cable, you still have to deal with flaky voltage regulators.
@Patrick, I love the slight offset you used for the programming header to make it stick without soldering.
I will also start using that on my own boards for ESPEasy board designs as it may also be useful for quick testing of sensors without soldering and using extra headers.
Power supply capacity is a very good point. I should add a note on the spec page so suggest that any implementations of the programmer should include up to 600mA available on the 3.3V line.
How do I solve the GPIO 00, 02, etc HIGH at boot of esp8266? The relays connected to these pins flicker at boot.
I am trying to make a smart switch that use 4 relays and 4 switches. But out of the usable pins, only 5 are 'safe pins'.
How would one connect 4 switches taht could be in either on or OFF state and relays too.
Please help.
You could use ADC0 with a resistor ladder to put all the buttons onto a single input pin. Or use GPIO0, 2, 16, and ADC0 for inputs (active low) and still have GPIO4, 5, 12, 13, and 14 available.
@@SuperHouseTV In case of GPIO0,2,16, if the switch position is low, then the boot would fail. So those would not be ideal for input. I was thinking of putting some circuit on them to use with relays so that they dont flicker at boot. As I understand, these pins are HIGH for about 200ms at boot. I read about adding capacitor across the optocoupler of relay, but it didn't work.
Do sonoff and other manufacturers actually want you to reflash their devices?
ITEAD are very aware that reflashability is the reason they became popular in the first place. They went to the trouble of adding "DIY mode" with a jumper to simplify reflashing, so they seem quite supportive of it.
Can't you just put a cellular modem into each lightswitch and update it Over The Air? (jk)