Yes, you can tell. Why on earth you creating yet another ESP8266 development board? There are plenty of them already available. Just check NodeMCU, Wemos D1, Sparkfun, Adafruit modules, just to name a few.
The main reason is that I'm an idiot.
I wanted to access the bottom pins of the ESP12E/F Modules:
And didn't realize that it is already available on the NodeMCU v1.0 on my desk.
So I designed and built one:
At least it is a breakout board with access to the bottom pins, without the USB/Serial adapter, what can fit in my future projects.
Now a few words about why I want these pins.
On many forums people written about these pins, that they are useless, as used by the flash chip of the module exclusively.
I'm a stubborn person. I don't believe what they said. I want to try this out myself.
Now let see, what I intend to achieve with this board. I'll mark these as tasks during the following write up.
The main problem, that the ESP8266 has a capable CPU, easily programmable Wi-Fi, lot of flash to store code and data, but limited GPIO capability. Yes, you can use bus extenders, but it isn't the same.
Let see what GPIO we have.
First of all the GPIOs can be freely use:
GPIO4, GPIO5, GPIO12, GPIO13, GPIO14
It is five, not to much if you know that SPI or I2C also can only be mapped to here.
There is also the GPIO16 maybe free, but some reports written, that it may disrupt the reset process, and it is involved in the deep sleep.
Lets continue, what else we have:
GPIO1, GPIO3 can be use if we give up the serial port used for programming and serial messages, what is quite useful during the development phase or later diagnostics.
As I want to keep this functionality I will not play with it now.
GPIO0, GPIO2, GPIO15 are used during the bootup process. This means the GPIO0 and GPIO2 pulled up and the GPIO15 is pulled down during normal boot (it isn't true when you program it or booting from SD Card).
If you don't care the state of these pins during boot process and aware of the pull ups/downs later on, you can use them as outputs, but doesn't recommended to use as inputs, because it can disrupt the boot process.
I've a simple external circuit in my mind to overcome this. So mark this as
TASK#1
GPIO6-GPIO11 used by the onboard FLASH (the bottom pins).
Here is a small table, how they are connected:
GPIO6 CLK
GPIO7 SDO0 MISO
GPIO8 SDO1 MOSI
GPIO9 SDO2
GPIO10 SDO3
GPIO11 SDCMD CS
The connection to the FLASH is required all of the time, so these pins can not be used (freely).
The system allows two modes (maybe more, but we just talking about the most common ones used in the ESP8266): QIO and DIO.
In QIO mode all of the SDx pins are used. In DIO mode just the SD0/1. This means the GPIO9/10 remain free. Check if I can use them. So mark this as
TASK#2
In some documents I found some information of the HSPI remapping to the SPI pins of the flash. In theory if I use the CS of the HSPI for some external SPI peripheral (4 wire SPI), I can share the SPI between the flash chip and this external peripheral. Mark this as
TASK#3
According to the documentation the ESP8266 can boot from SD card instead of the internal flash. It would be interesting to figure out, how can this be achieved. So mark this as
TASK#4
This is all for now. I'd like to research the four tasks mentioned above, and write about the successes/failures.
