Igen, nyugodtan mondhatod. Mi a jó büdös francért csinálsz mégegy ESP8266-os fejlesztőpanlet? Rengeteg van a piacon. Csak nézd meg a NodeMCU-t, Wemos D1-et, a Sparkfun, az Adafruit moduljait, csak, hogy megnevezzek párat.
A fő ok, hogy egy idióta vagyok.
Hottá akartam férni az ESP12E/F alsó oldalán található kivezetésekhez.
Csak azt nem vettem észre, hogy ezek már elérhetóek a NodeMCU v1.0-án ami ott kallódik az asztalomon.
Ezért terveztem és építettem egyet:
Ez legalább egy olyan minimális panel amin hozzáférek ezekhez a csatlakozásokhoz, nincs rajta az USB/Soros átalakító, így könnyedén illeszkedik a jövőben tervezett projectjeimbe.
Akkor most egy pár szót arról, hogy mihez akarok kezdeni ezekkel a csatlakozásokkal.
Rengeteg fórumon arról írnak, hogy ezek a lábak használhatatlanok, kizárólag a beépített flash tudja használni ezeket.
Én egy makacs alak vagyok. Nem hiszem el amit mondtak. Magam akarom kipróbálni.
Nézzük meg, mit szándékszom elérni ezzel a panellel. A továbbiakban számozott taszkoknak fogom jelölni az elérendő eredményeket.
Az alap probléma az, hogy amíg az ESP8266 egy igen nagytudású processzor, könnyen programozható Wi-Fi-vel, jó sok flash memóriával a programok és adatok tárolására, igencsak limitált a felhasználható I/O-k száma. Igen, lehet I/O extendereket használni, de az nem ugyanaz.
Nézzük meg, hogy miből főzünk:
Először is ezek a GPIO lábak állnak szbadon rendelkezésünkre:
GPIO4, GPIO5, GPIO12, GPIO13, GPIO14
Ez összesen öt, nem túl sok annak ismertében, hogy az SPI-t és az I2C-t is csak ide tudjuk kirendezni.
A GPIO16 még lehet, hogy szabad, de néhány bejegyzés szerint megzavarhatjuk vele a boot folyamatot, és szerepe van a deep sleep üzemmódnál.
Nézzük, hogy mi másunk van.
A GPIO1 és GPIO3 használható, ha feladjuk a soros portot amin a programozás zajlik és a diagnosztikai üzenetek jönnek rajta. Ezjól használható a fejlesztési időszakban, majd később diagnosztikai célra.
Miután azt a funkciót mindenképp meg akarom tartani, ezzel egyenlőre nem akarok foglalkozni.
A GPIO0-t, GPIO2-t, GPIO15-t a boot folyamat használja. Ez azt jelenti, hogy a GPIO0 és GPIO2 tápra, a GPIO15 pedig földre van kötve a normál indulás során (ez nem igaz, ha programozzuk az eszközt, vagy SD kártyáról indítjuk).
Ha nem törődünk ezknek a boot során lévő állapotával ésfigyelembe vesszük a fel és lehúzó ellenállásokat a későbbiekben akkor kimenetként használhatóak, ugyanakkor bemenetként nem ajánlott ezeket használni, mert megzavarhatják a boot folyamatot.
Van a fejemben egy egyszerű külső áramkör amivel ez kiküszöbülhető. Tehát jelöljük meg ezt TASZK#1
A GPIO6-GPIO11 a beépített FLASH memória használja (alsó oldali csatlakozások).
Itt van egy kis tábla, hogyan vannak bekötve:
GPIO6 CLK
GPIO7 SDO0 MISO
GPIO8 SDO1 MOSI
GPIO9 SDO2
GPIO10 SDO3
GPIO11 SDCMD CS
A flash-nek folyamatosan csatlakoztatva kell lennie, tehát ezek a lábak nem használhatóak (legalábbis nem szabadon).
A rendszer két üzemmódot enged meg (lehet, hogy többet, de itt most csak a két legsűrűbben használt ESP8266 flash módról beszélünk): QIO (négycsatornás) és DIO (kétcsatornás)
QIO módban az összes SDx láb használatban van, DIO módban csak az SDO0/1. Ez azt jelenti, hogy a GPIO9/10 szabadon marad. Nézzük meg, hogy tudom-e használni ezeket. Tehát jelöljük meg ezt TASZK#2
Bizonyos dokumentumokban azt találtam, hogy a HSPI interface-t rá lehet mappelni a flash SPI lábaira. Elméletben, ha a HSPI CS jelét használjuk külső SPI eszközt köthetünk ide (4 vezetékes SPI). Ezzel meg tudom osztani az SPI lábakat a flash és a külső SPI között. Jelöljük meg ezt TASZK#3
Az ESP8266 a dokumentáció szerint tud SD kártyáról bootolni a belső flash helyett. Érdekes lenne kitalálni, hogyan működik ez. Tehát jelöljük ezt is meg TASZK#4
Egyenőre ennyi. Ki akarom deríteni, hogy a fenti négy elképzelésem működik-e, és írni a sikerről/kudarcról.
Nincsenek megjegyzések:
Megjegyzés küldése
Megjegyzés: Megjegyzéseket csak a blog tagjai írhatnak a blogba.