Ezzel az átalakítóval az a baj, hogy nincs kivezetve rajta a DTR és az RTS vonal. Az ESP feltöltő szoftver pedig ezeket használja arra, hogy elindítsa a bootloader-t.
Ha csak AT parancsokkal akarod használni, akkor is érdemes megtanulni firmware-t frissíteni rajta. Mire ideér Kínából, már sokkal újabb AT parancsértelmező is elérhető hozzá.
A másik probléma pedig az, hogy 3,3 Voltos kimenete nem tudja ellátni árammal az ESP modult. Mindenképpen külső tápot kell adnod neki. Vagy teljesen máshonnan adsz neki 3,3 Voltot, vagy az átalakító 5 Voltjából csinálsz 3,3-at. Legyen rajta puffer kondenzátor is. Ja, és az ESP táp bemenetről ne felejtsd le a hidegítő kerámia kondenzátort. 100 nF jó lesz. A CH_PD lábat és a RESET lábat inkább egy 10 kOhm ellenálláson át szokás Vcc-re húzni. A GPIO_0 és GPIO_2 szintén legyen 10 k-val Vcc-re húzva. Azt mondják, jót tesz a stabilitásnak, ha ezek nem lebegnek.
először csak a soros adaptert tedd rá a gépre. amíg az nem látszik egy új sorosportként az eszközkezelőben, nincs értelme továbblépni.
jó kis szívás az ilyen kínai usb sorosportokat beüzemelni. lejjeb a dx-en a kommentekben írják hogy nem cp2102 hanem prolific pl2303 chipes, és ott azt mondják a PL2303_Prolific_GPS_1013_20090319.exe nevű driverrel megy. először tedd fel a drivert, utánna dugd be, akkor normálisabban megtalálja a windows.
Hogyan oldanátok meg egy pár egymástól kb. 6 méterre lévő, de gipszkarton fallal ellátott rendszer távirányítását a lehető legegyszerűbb módszerrel (hifit kellene távirányítai gombnyomással, csak Mute/Unmute szintjén). Infra elvileg megoldható a vevő oldalon, de ahhoz kicsit ügyeskedni kell a megfelelő kódsor meglelése végett.
IR adó és vevő oldal is van a fiókban, de vezeték nélküli cucc szinte semmi (illetve ami van, az fejlesztőkártya, BT-n meg nem feltétlenül ügyködnék ilyen erős vassal (MT LinkitOne).
Ma megérkezett a 2db sainsmart nano, a korábban már tárgyalt módszerrel átégettem a bootloadert, most uno-ként működik a wdt, a fűtésvezérlőben folyik a teszt élesben.
Kezdő Arduino-s vagyok (azért nem ez az első áramköröm, de még van mit tanulnom...) .
Szóval van egy Mega 2560-om, amivel most különböző hőmérsékleteket és páratartalmat nézek. Ezeket az adatokat most SD kártyára mentem, és ezt szeretném most egy mysql adatbázisba menteni.
Vettem egy ESP8266 wifi modult, amivel szeretnék a hálózatomra kapcsolódni és egy itt található NAS adatbázisába tölteni az adatokat...
Találtam is mintaprogit és kötési rajzot az ESP8266 és a MEGA 2560 összekötésére amit meg is csináltam, de azt mondja a hogy a modul nem válaszol...
Szóval tudnátok segíteni, hogy kezdjem a hibakeresést, vagy mi lehet a bibi?
Az elágaztatásról van szó! Debug okok miatt pl. sok infót küldünk ki Serial.print(), Serial.println(), vagy Serial.prinf() segítségével. Ezek vagy csak egyszerűen karakterként megjelennek a soros port Tx lábán, vagy komoly feldolgozás, formázást követően. Tehát az Tx láb nagyon sok irányból és sok előfeldolgozás után jelenít meg adatokat, amiket aztán egy egyszerű soros monitor programmal bárhol megnézhet az ember. (Miért érdekes ez? mert pl egy float változó egyszerű kiirása mögött is komoly átalakító folyamatok vannak, mire pl 6 számjegyű, tizedesponttal ellátott ASCII formában jelennek meg a Tx lábon) Mindez a Tx adópufferbe betöltött adatokból történik. Ha meg lehetne találni azt az (esetleg 1 konkrét sort amelyik ténylegesen a Tx pufferbe írást végzi, bármely irányból jött is a kérelem a Tx portra írásra) akkor ott talán a Tx bufferbe írás után azonnal be lehetne iktatni egy új utasítást, amely egy másik pufferbe is ír.
A cél hogy a Tx porton megjelenő infók egy másik pufferből bármikor kiküldhetők legyenek bárhova, pl Ethernet kártyán keresztül bárhova. Tehát most nem tárolási kérdésről van leginkább szó.
Az eddigi turkálásaim szerint a Tx buffer írását a ..Program Files (x86)ArduinohardwarearduinoavrcoresarduinoHardwareSerial.cpp végzi! Ebbe kellene belepiszkálni ha nincs jobb ötlet.
Én még nem próbáltam. Úgy olvastam, hogy egy vagy két sort át kell írni a bootloaderben, és onnantól kezdve működik.
A flash-t csak a bootloader írhatja. Ezért lehetővé kell tenni, hogy a normál programodból meghívd a bootloader egy funkcióját. Tulajdonképpen meghívod a bootloader memóriaterületen tárolt függvényt két paraméterrel, mit és hová akarsz írni. A rendszer pedig hagyni fogja, mert az adott kód a bootloader részen helyezkedik el.
Attól függ, mennyi adatról van szó (mintavételezés gyakorisága, minősége) és azt hogyan, mennyi idő után és milyen biztonsággal akarod kiolvasni.
Beépítve kettő alternatíva van:
-- SRAM -- ez az alap operatív memória, hátránya, hogy kicsi (2 kB az alap) és resetkor vagy áramkimaradáskor törlődik. A módszer kb. annyi, hogy egy kvázi végtelen méretű mátrixot nyitsz és ebbe írogatod be az adatokat (2 kB-ba nem sok fog beleférni),
-- EEPROM -- ez az MCU saját belső EPROM-ja. (Elvileg) bárhányszor írható, olvasható, kikapcsolás után is megmarad. Hátránya, hogy elég kicsi (1-4 kB).
(A Flash nem játszik, ugyan létezik és nem is kicsi, de szoftverből nem tudsz bele írni.)
Külső megoldások lehetnek többek között:
-- EEPROM -- mint a belső, csak kábelezni kell. Elvileg feltornászható egészen kellemes méretre is, elvben 4 MB környékére.
-- SD kártya -- nagy vonalakban végtelen lehetőségek, mindent megőriz, ha van kártyaolvasó a PC-den, akkor megfelelő formátumban kiírt fájl olvasható rajta.
-- felhő -- pl. plotly, ez viszont már IoT kategória és úgy hardveresen, mint szoftveresen erős bástya kell mögé.
Van valami ötletetek rá, hogyan lehetne a mindenféle Serial.print() kiírásokat, melyek a soros portra kimennek, majd megjelennek IDE Serial monitorán, eltárolni egy átmeneti bufferba?
Valahogy a Serial.print() kimenetét, ami a soros TX bufferbe ír, hogyan lehetne meggyőzni, hogy a TX bufferbe kiírással egyidőben ugyanabban a sketch-ben lévő, egy másik bufferbe !! is !! berakjon minden általa kiküldött bájtot.
