IoT Wifi chipek

Fejlesztés

Most az tranzisztor IoT kor hajnalán szedjük már csokorba a fellelhető wifi chipeket. Amiket ismertek, írjátok le pár szóval előnyeit, hátrányait... okosodjunk egy picit.

Ami engem kifejezetten érdekelne, ha lenne ilyen:

  • legyen debugolható: pl swd interfacen. Ha leteszek egy töréspontot, akkor álljon meg ott a processzor. lássam milyen címen mi van, mi hova mutat.
  • legyen kb olyan supportja mint a nordic ble chipeknek. doksi, forum. ott adják a BLE stacket, te megírod a user programot, és kész. van erőforrás, van tárhely, szépen debugolható
  • legyen debugolható
  • legyen benne tárterület, hogy lehessen built in weboldalt csinálni
  • legyen debugolható
  • legyen uart interface, hogy másik MCU-val lehessen illeszteni
  • legyen debugolható
  • normális fejlesztőkörnyezetben pl IAR-ben lehessen rá fejleszteni.
  • azt írtam már, hogy legyen debugolható?

( kisg v | 2019. 05. 23., cs – 19:34 )

esp8266 ? Bár nem tudom hogy debuggolható-e. :)

FreeRTOS-sal kultúráltan lehet vele dolgozni.

( sza2king v | 2019. 05. 23., cs – 22:34 )

Azt hittem, hogy talalok olyan chipet, ami megfelel a fenti leirasnak, de azt ugy latom tevedtem.

https://www.silabs.com/products/wireless/wi-fi

Olyan, ami egy chipben WiFi es applikacios proci is, ugy latom nincs kozottuk.

A legtobb Network Co-processor, szoval valamilyen buszon egy kulso MCU-t kell illeszteni hozza.

Az elvarasokhoz legkozelebbi a WGM160, de az is gyakorlatilag egy WiFi NCP + egy app. MCU - itt az MCU reszre all az osszes feltetel amit irtal, de a WiFi stack az NCP-ben van, azt a reszt nem igazan tudod debugolni, bar az igazat megvallva, ha a stack jol meg van irva, akkor azert erre nincs is szukseg es csak az applikaciora kell koncentralni.

Amire meg celszeru odafigyelni ha mas 2.4GHz-es IoT jellegu dolgok (Zigbee, BLE, Thread) mennek a kozeleben (mondjuk annyira kozel, hogy ugyanazon a boardon, pl. gateway-t csinal az ember), hogy legyen PTA interface-e a chipnek (varazsszo: co-existence)

/sza2

--
Digital? Every idiot can count to one - Bob Widlar

Nem akarok stacket debugolni. A nordik ugy csinálta, hogy adott header fileokat, amiben megvolt minden ( is ) BLE kezeléshez szükséges dolog, flash íráshoz, uarthoz, stb, és azt használva elkészült az app. én csak interruptot kaptam pl advertisingról, vagy ha jött egy bájt az uarton. a linker fájlba meg megadtam, hogy a softdevicet (stacket) hova tegye. ezt aztán egy swd programozóval lehet betölteni. iarban még debugolni is lehetett, meglepően jól, néha azonban összeomlik a stack debug kozben, ezek az órajeles dolgok (pl spi is) érzékeny ha megáll a proci. de lehetett vele élni.van lehetőség professionális alkalmazást készíteni.

ezzel ellentétben az esp egy játékszer, én nem jöttem rá, hogy lehet rá fejleszteni, mert csak játszáshoz vannak előre írt kodok arduinoban. elképzelni nem tudom hogyan fejlesztették le azokat. gyárilag meg ott egy erős proci az espben, ami AT paracsokat kezel, és a külső mcunak is kell részben wifivel foglalkozni. holott elég lenne annyi, hogy uarton felküldi az mcu, hogy mennyé, nemennyé, ha kér tőle adatot az esp, azt oda adja.

------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?

Ha egy egysegkent tekintesz az WGM160-ra, es az applikacio a lenyeg, akkor az eleg jol lefedi amit szeretnel, a debug gyakorlatilag az EFM32 Cortex M4 debugolasa, ami azert mar eleg stabilan mukodik mind IAR-ral, mind a Simplicity Studiobol (GCC, IAR). Ami hatrany lehet, hogy arban nem fog versenyezni az ESP* eszkozokkel.

Egyebkent en szemely szerint szeretem az ESP8266-ot, az Arduinos kornyezetben egyszeru (es nem battery powered) dolgokat szerintem tok jol es gyorsan (meg olcson) ossze lehet rakni belole. A kazanonk (rele kapcsolgatas) es a legkondi (infra) "okositasa" ESP-kkel lett megoldva (MQTT-n), a kapcsolat stabil, az uptime igen jo, kb. az aramszunetek eseten van ujraindulas (ami meg ~fel - 1 evente van egyszer), egyebkent stabilan mukodik (viszont nyilvan primitiv funkciok vannak csak megvalositva benne). Igaz a debugra en sem talatam egyszeru es jo megoldast, max UART/printf.

/sza2

--
Digital? Every idiot can count to one - Bob Widlar

( micsa v | 2019. 05. 24., p – 09:00 )

ami bajom van ezekkel az új boardokkal - általában - hogy kevés a pinek száma (az esp8266-nak 1 analog inputja van afaik, ).
szerintem még mindig nem kell temetni az arduino mega 2560-at ethernet shielddel.

de hogy az eredeti kérdéshez is szóljak: láttam ilyet, hogy egy arduino mega boardra rátesznek egy esp8266-os modult is, ezek nyilván tudnak kommunikálni: https://www.banggood.com/Wemos-Mega-WiFi-R3-ATmega2560ESP8266-32Mb-Memory-USB-TTL-CH340G-Compatible-For-Arduino-Mega-p-1205437.html?cur_warehouse=CN

az más kérdés, hogy mennyire jó wifit használni az iot kütyükre, security meg megbízhatóság szempontjából...

szerk: ami pedig a debuggolást illeti, én úgy szoktam "arduino-like" kódot írni (esp8266-ra és arduinora), hogy x86-oson fejlesztem/tesztelem, saját "abstraction layer"-t használva :)

Tudod, S in IoT stands for Security ;-)

Egyebkent e tekintetben a WiFi meg mindig a megbizhatobbak koze tartozik, rengeteg, kulonosen korabbi fejlesztesnel lesz@rtak a security-t, mondvan "ki akarna feltorni a homerot?" - szerencsere ez valtozni latszik, a gyartok egyre inkabb adjak a security tamogatast (mind hardver mind szoftver oldalon), meg terelgetik a nepet, hogy alkalmazzak is.

/sza2

--
Digital? Every idiot can count to one - Bob Widlar

( apal v | 2019. 05. 24., p – 09:32 )

AMW006

Szerintem ezeket mind tudja, de ketsegtelen hogy en az MCU + UART + TCP/IP stack reszet hasznaltam csak leginkabb. Eleg sokat hasznaltuk/hasznaljuk ezt, teljesen stabil, megbizhato joszag.

Mennyire stabilan lehet felcsatlakozni rá?
Én ESP8266-ot teszteltem, és annak a wifije addig stabil, amíg kliens. Amint csatlakoznál hozzá, mint szerverhez, rém könnyen eléri a maximális kapcsolatok számát, ami a gyakorlatban annyit jelent, hogy nem lehet elérni, mint szervert. Külön AP-ként még csak-csak, de ha wifi kliens, és úgy címzed meg, már gyakorlatilag használhatatlan.

"rém könnyen eléri a maximális kapcsolatok számát, ami a gyakorlatban annyit jelent, hogy nem lehet elérni, mint szervert"

Mivelhogy egy szálon szolgál ki HTTP-t, ha HTTP-n akarod elérni több kliensből is, akkor ne tartsd fenn a kapcsolatot, kérdezz, várd meg a választ és bontsd a kapcsolatot, az ESP oldalán meg gyorsan szolgáld ki a kérést, ne várasd.

--
https://iotguru.live

Böngészővel érném el az oldalt, nincs nagyon ráhatásom a kapcsolat bontására. (Sima html oldal, semmi további erőforrás, sem css, sem js, sem kép.) Betölti az oldalt, és utána elvileg bont. A gyakorlatban meg mégis szar.
Ha AP az ESP, akkor is néha nehézkes a felcsatlakozás az AP-re. Konzolon ilyenkor írja, hogy max connection, de persze ez egy új AP, tehát elvileg még semmilyen kapcsolata sem lehetne. Ha felcsatlakozott már, akkor elég stabil.
Ha wifi kliens az ESP, akkor meg szinte esélytelen, hogy elérjem az ESP szervert.
Valahol fejtegették, hogy mi ennek az oka, de nem vigasztal. Szívesebben használnék olyat, amihez megbízhatóan lehet kapcsolódni egy böngészővel, és nem a felhasználót kell kitanítani, hogy hogyan kattintson.

Már ütköztem ebbe a problémába. Az ESP-n a tcp queue length kicsi, és egyszerre csak egy kérést tud kiszolgálni. Ha a böngésző a főlap betöltésekor sok (>5) kérést kezd el a szerver felé, akkor lesznek olyanok amire a szerver már nem válaszol, mert a tcp queue-ba se fér bele.

Találtam egy megoldást, ami nekem bevált:

- megírtam a frontendet react + blueprintjs
- minify-oztam, ebből az egész frontendre lett kb. 6 állomány amit be kell töltenie
- írtam egy olyan programot, ami kielemzi a lefordított minify-ozott frontend kódot, és generál hozzá egy javascript főprogramot, ami a következőket teszi:

- fogja az összes frontend-hez szükséges file-t
- mindegyikre lefuttat egy GET ajax kérést SZEKVENCIÁLISAN tehát megvárja amíg befejeződik az egyik, és csak utána kezdi a másikat
- eközben kirak a user-nek egy progress bart amin látszódik hogy hol tart
- miután az összeset GET-elte egyszer, redirect-el a valódi főlapra
- a valódi főlap is GET-eli őket, de addigra a cache-ben vannak és azok a kérések nem jutnak el az MCU-ig
- a frontend és a backend (MCU-n futó API) közötti kommunikáció pedig egyértelműen javascript kód AJAX hívásokkal, amik lehetőleg egymás után futnak le.

Az egész minify-ozott kód általában 2MB alatt van, ráfér egy ESP-re. A web szerver részénél meg csak annyi dolgod, hogy a statikus file-ok GET kérésére visszaadsz egy max-age header-t hogy biztosan cache-be kerüljön

Ez a megoldás egészen megbízhatóan működik, és csilli villi reszponzív React-os admin oldalakat lehet vele gyártani, amik simán ráférnek egy 600 forintos ESP-re.

( tovis v | 2019. 05. 24., p – 21:22 )

Érdekes téma.
OFF: Az egész WiFi -vel az a bajom hogy nagyon misztikus az elérhetősége.
Mint kicsi, beágyazott rendszerek kommunikációja egy amúgy roppant telített rendszerekben, nem tűnik szerencsésnek. A beágyazott rendszerekhez inkább a 433MHz -et gondolom járhatónak - persze nem kamera. A Lora ráadásul akár kilométeres távolságban is működik, míg a WiFi a szabályok áthágása nélkül legfeljebb néhány tíz méter.

* Én egy indián vagyok. Minden indián hazudik.

Nem arra valo. Sok helyen van kiepitett wifi (haz/iroda), az ottani eszkozok tavvezerlesere teljesen jo. Mar ha nem kritikus a dolog.

Ha kilometeres irodarol van szo, akkor nem ez az idealis.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Szerintem a WiFi-nek is megvan a maga helye a beagyazott rendszerek teruleten. 5+ darab nagysagrendben, szenzorokat amik 10 percenkent kuldenek egy 16 bites erteket es CR2032-rol kell mennie 2+ evig, azt en sem csinalnam WiFi-vel ;-)

Nem kotozkodeskepp, csak nem ertem a 433MHz kulonlegesseget. Van meg jo par ISM sav, ahol lehet forgalmazni (169MHz, 868MHz, 915MHz, stb.). Nekem a szenzorok epp 434MHz-en mennek, aminek az oka az, hogy ezen a frekin szepen mukodik pincetol a padlasig (meg ilyen radio boardbol volt annyi, hogy tele tudtam szorni a hazat), de siman lehetne 169Mhz is, a terjedes valoszinuleg meg jobb is lenne).

A LoRa-ra ha jol tudom (legalabbis Europaban) 868MHz-et hasznalnak.

/sza2

--
Digital? Every idiot can count to one - Bob Widlar

A WiFi-nek van egy olyan előnye, hogy vannak rá cél eszközök, mint amilyen az ESP8266, ESP32. Ebbe összeintegrálták az adót, a vevőt, az átjárást az internet felé, programozható MCU-t és még sok minden mást. Ha pusztán a rádiótechnikát nézed, akkor valószínűleg lennének olyan frekvenciák és átviteli módok, amik előnyösebbek a WiFinél, jól meghatározott célokra. De ez csak egy szempont a sok közül. Ha például maradunk a 433Mhz-nél: az már igaz, hogy vannak olyan adó modulok, amiket készen lehet kapni. De abban nincs vevő. Ha szükséged van mindkettőre, plusz még neked kell hozzáadni egy MCU-t, akkor előjönnek másféle problémák. Mert ezeket készen előre gyártott modulokból is összerakhatod, de akkor saját panelt kell tervezned és legyártatnod. Plusz a mérete is nagyobb lesz, és még sorolhatnánk. Összességében drágább lesz, mint egy készen kapható modul amibe bele van integrálva a kommunikáció, az MCU sőt akár az akkumulátor is. Természetesen a saját tervezésnek is van létjogosultsága - ha az általad említett "ritkán adatot küldő" szenzorból le kell gyártani 1 millió darabot, akkor simán megéri sajátot tervezni. Hatékonyabb is lesz, meg olcsóbb is. De ha csak egy otthoni vagy kisvállalat projektről van szó, ahol 20-30 szenzort kell kihelyezned, akkor ott már valószínű, hogy a legköltséghatékonyabb megoldás egy olyan modul használata, ami beépítve és integrálva tartalmazza az összes szükséges funkciót (vagy legalábbis a legnagyobb részét). Ha az összes szempontot egyszerre figyelembe veszed, akkor a WiFi használata vagy egy nagyobb méretű elem lehet az egyik kompromisszum, amit érdemes bevállalni.

Nyilván ez csak egy okoskodás, konkrét tanácsot csak konkrét problémára lehet adni.

( cadmagician | 2019. 08. 12., h – 08:54 )

ESP32-WROOM

ez a jó választás. megcsináltam a fejlesztőkörnyezetet, igaz, debug csak uart print van, meg nagyon lassu a felprogramozás, de a full AT parancskészlet megmarad, bővíthetem saját parancsokkal, és saját logikát tudok beletenni, és saját fájlrendszer is van. plusz megcsináltam már, hogy AT parancsra webservert indit, most a belebuildelt weboldal kiszolgálás ajön, majd adatokkal való feltöltés. és akarok beletenni periodikus adatküldést, hogy a hostról levegyem ezt a logikát, a host csak az adatokat passzolja át AT parancsokkal, minden egyéb web dolog meg házon belül. => adatfelküldés szakosan.

50-60 perc c kodolás, build és jellemzően fut, jól dokumentált, sok példával. az arduino kódolást el kell felejteni, kokányolás ehhez képest. majd a JTAG debugot kéne kiprobálni...


------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?