Mikrokontollerezni szeretnék

Elektronika, Elektromos eszközök

Ki mire esküszik?

Igények:

  • lehessen használni alapvető I/O illesztésre, pl. LED villogtatás, de kicsit komolyabb dolgokat is hozzá lehessen tenni, pl. wifi
  • legtöbb célra házilag forrasztható legyen (tehát devboarddal együtt jön, esetleg breadboardba lehet rakni és kevés komponens kell mellé)
  • ne legyen olyan bonyolult, hogy OS kell rá, de olyan buta se, mint pl. régen a PIC16
  • ami a legfontosabb: kulturált fejlesztőkörnyezet (rendes csomagból települ, debug lehetőség, Linux alól)

Kifejezetten nem számítógép kell, tehát nem Raspberry és sok más ARM chipes cucc is kiesik. Amennyire gyors keresésből kiderült, ESP32 és Arduino a nagy versenyzők, de biztos van sok más is, és főleg tapasztalatok érdekelnek, hogy melyikkel kevesebb a szívás.

  • 2049 megtekintés

Azért írtam a debuggolás hiányáról, mert a kérdező "Igények" listájában szerepelt és ha valaki tanulni szeretne (vagy csak gyorsan haladni), a debuggolás nagyon sokat segít. Tudom, mert 20 évvel ezelőtt nekem sem volt debuggerem, és lassan haladtam mindennel: a kitűzött cél elérésével is és a tanulással is...

Ez változó. A gyakorlatban a debugger belövése szinte sose zökkenőmentes, gyakran vannak vele elsőre nem észrevehető nyűgök is.

Akkor jó a debugger, ha a mikrokontroller bizgetésével egyidőben tanulod a programozást is. Ha a kódolás már igazából gyerekjáték (mert lássuk be, a mikrokontrollerek kódja nem épp egy algoritmuselméleti diplomamunka; de ha mégis, akkor PoC rendes számítógépen amúgy is kellene előtte), akkor a printf, bár nem elegáns, de nem különösebben zavaró, inkább csak lassú(bb).

 

UPD: a masik, ami miatt a debugger kiesik, az az, hogy mikrokontrolleren gyakran kell idozites-erzekeny dolgokat muvelni - ott meg nem lehet suspend-elni, csak a printf jo.

Mivel mikrokontrollereken bármi lehet az stdout, úgy oldják meg, hogy a printf() callback függvénye a void putch(char c); oda meg az ember írhat például bufferelt I/O-t is, és akkor gyors lesz a printf(). Na persze akkor sem végtelen gyors, de legalább nem kell megvárni, amíg a karakterek kivánszorognak a soros porton, vagy az LCD-re, vagy akárhová.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Pontosan. És pont ez az egyik problémám az ATMEGA328-ra készült alap Arduino libbel, hogy a Serial.print bevárja ameddig kicsorognak a bájtok az UART-on, ezért bármilyen valós idejű dolognál felejtős. Az első dolgom minden programozásnál, hogy tisztességes UART libet csinálok. Kivéve, ha az online memóriadump alapon működő debugger amit csináltam elegendő a nyomkövetéshez.

Én nem vagyok software-es, így nekem sokszor nagyobb a tanulási görbéje annak, ha kész libeket használok. Legtöbb esetben megírom magamnak, ami kell, azt legalább ismerem, ha nem tetszik, javítok rajta. Nyilván nem USB stack-et írok, de bufferelt I/O-t bármikor. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

...vagy, amikor kliens-szerver kommunikáció megy mondjuk TCP/IP felett, amit nem lehet megakasztani.
Ha meg annyira időzítés-kritikus a dolog, akkor előkerül az oszcilloszkóp is...

Egyébként az STM32 debuggere mostanság elég jól működik különösebb szenvedés nélkül Linuxon STM32CubeIDE alatt.

Sohasem használtam debuggert, mert az időt nem tudom megállítani. Megszakításokat, DMA-kat, külső kommunikációs folyamatokat nem lehet megakasztani következmények nélkül. Mindig csak logolok, nekem annyi elég a hibakereséshez.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, ezeket nem igazán lehet debuggolni. Mondjuk egy szabályzást is érdekes lenne. :)
Jellemzően én is logolok (bufferelten), de azért segítség tud lenni egy debugger időnként - ha rendelkezésre áll az adott környezetben.

...és lehet bizonyos C kódrészeket PC-n is tesztelni.

( Nyosigomboc v | 2023. 10. 18., sze – 23:56 )

Kb. ezt a kettot ajanlottam volna en is, az ESP-nek vannak mindenfele boardjai wifivel, az Arduino meg eleg kenyelmes fejleszteshez. Ami jo lehet meg, az STM32, a 8 bites Atmeleknel valamivel tobbet tud, de arban hasonlo.

Lehet kombinalni is, az ESP8266 alapbol olyan firmware-rel jon, aminel a wifi sima UARTon keresztul elerheto. Bar az ESP joval erosebb, szoval felesleges melle egy kisebb mikrokontroller, de ha nem akarod azt is megtanulni, es keves projectedhez kell wifi, ez is egy lehetoseg.

A strange game. The only winning move is not to play. How about a nice game of chess?

Uhm, ez kicsit osszetettebb.

Alapvetoen az ESP -khez van egy sajat ESP framework. Ritka bonyi amugy, semmihez sem hasonlit. Anno csinalt nehany jofej ember egy lib-et, ami gyakorlatilag 100%-ban arduino SDK kompatilitast ad az ESP SDK felett.

Erdekessege, hogy ha ESP-n arduino "SDK" -t hasznalsz, akkor az ESP libek is elerhetoek, tehat tudsz pl. thread-et inditani meg mutex-elni.

 

En is arduino SDK-t hasznalok a portabilitas miatt, meg mert tenyleg _nagyon_ egyszeru (imadom az ilyeneket), es legfokepp, elkepeszto mennyisegu lib van arduino SDK-hoz, kvazi barmilyen aliexpress-es komponenshez van, neha tobb is :)

en vscode + platformio -t hasznalok egyebkent, nagyon jo.

Persze, pongyolán fogalmaztam (szándékosan). Teljesen igazad van, amire utalni akartam csak, hogy nem feltétlenül kell az arduino-hoz képest sokkal másabbat megtanulni (esp framework-öt), sokminden megoldhato esp-re az arduino ide-ben 'arduimo tudással'.

Poén, hogy az új arduino nano esp32 alapú:-)

vscode + platformio  már kicsit bonyibb talán kezdőnek, cserébe pl. a debug nagyon hasznos lehet ESP-prog board-dal

( locsemege v | 2023. 10. 18., sze – 23:57 )

Én most munkához PIC32MZ sorozatból használok. Megszerettem. Nem kell hozzá oprendszer, elég sok a FLASH (2 MiB) benne ahhoz, hogy eleresztheted a fantáziádat C-ben, nem tudod teleírni. Én egy műszert megírtam benne, aztán még a tárhely töredéke van kihasználva. A RAM az már feszesebb, konkrétan 512 kiB, de azért az is elég, pláne, ha ésszel csinálja a dolgait az ember. Például lehetőleg pointert adsz át, nem egész buffereket, meg ilyesmi. 32 bites MIPS architektúra. Van hozzá Harmony, sajnos megúszhatatlan, mert a hardware nem egyszerű. Ha az initen túlvan az ember mondjuk egy hónap alatt, a többi gyerekjáték. :D

Ha viszont egyszerűbbre vágysz és assembly-ben programoznád, akkor PIC16 sorozat, ha C-ben, akkor PIC18 szerintem. PIC16-ot is lehet C-ben, de hamar tele fog szaladni a FLASH is és a RAM is. A PIC18 utasításkészlete alkalmasabb a C-ből való fordításra.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én is használtam ilyet, de az MPLAB X IDE felér egy büntetéssel. A legutóbbi IDE, amit használtam Netbeans alapú volt, és iszonyat lassú, a debuggolás kínkeserves... Alig vártam, hogy leszedhessem a gépről...

A többi ARM magos MCU gyártó Eclipse alapú ingyenes IDE-t ad, azok között is van jobb-rosszabb... Az STM32-hez adott IDE az STM32CubeIDE használható (szerintem).

MPLAB X IDE felér egy büntetéssel

Tudom, ennek ellenére használom Intel N4200-val szerelt notebookon is, illetve Ryzen 7-tel szerelt desktop gépen is. Nyilván ez utóbbin egész jól használható. Az viszont valóban kellemetlen, hogy nem kevés alkalommal exception-nel indul a fejlesztői környezet, a syntax highlight néha nem működik, egyes library-kat nem lát, így azt hiszi, hiányzik #include, de a legkellemetlenebb, amikor indulás után belehal valamelyik process-ébe, s bezárás után pkill java paranccsal tudom rendezni a sorait, majd próbáljuk meg újra.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( VaZso v | 2023. 10. 19., cs – 00:23 )

Én STM32-t és ESP32-t nézném meg, mindkettőhöz találni fejlesztőpaneleket.

( apal v | 2023. 10. 19., cs – 00:30 )

Szerkesztve: 2023. 10. 19., cs – 08:21

STM32 mikrokontrollerekhez a Nucleo sorozat. Mindent tud azok kozul amit irsz, sőt, van egy plusz extra featuraja amit ugyan nem irtál de nagyon jó (avagy ha megszokod és nincs akkor már hiányzik): van benne beepitett programozo interface (ST-Link, nyilt cucc) _és_ emellett USB-n a programozo mellett kapsz egy virtualis soros portot is ami a cél-mikrokontroller egyik U[S]ART portjara rá van kötve. Ezekbol a Nucleo-kbol  van mindenfele méret a 16k flash - 1k RAMtól kezdve a sok mega flash - sokszáz k RAM-ig, és bare metal módon is jól programozhatóak.  

Minden van hozza linux alatt: arm-none-eabi-gcc, newlib, binutils, openocd. Ezutobbi gdb-vel is osszekotheto. 

A PIC16 nem feltetlen "buta" onmagaban de a memoriabankozasos technikaja miatt nem igazan C/C++ barat, mondjuk ugy. Szoval ha C/C++/barmi-ami-nem-assembly a cel akkor mindenkeppen valodi folytonos cimtartomanyu eszkozt nezz, ne bankozosat.

Az STM32 Nucleo-ra +1: az STM32CubeIDE-vel jól lehet debuggolni. Ez alatt azt értem, hogy ha leállítod a program futását és nyomsz egy "step"-et, akkor nem kell 5-15 másodpercet várni, amíg meg is történik a művelet. (A Xilinx FPGA-s soft processzoroknál, MPLAB X IDE-nél, meg még egy-két másik IDE-nél is volt ilyen élményem: borzasztó.)

Az STM32CubeMX-el lehet generálni egy függvénykönyvtár környezetet és projektet, amit be lehet tölteni az STM32CubeIDE-be és el lehet indulni. Hátránya: alapból ebben nincsenek Arduino library-k, kevesebb információ, segítség a neten.

> van egy plusz extra featuraja amit ugyan nem irtál de nagyon jó (avagy ha megszokod és nincs akkor már hiányzik): van benne beepitett programozo interface

Hát pedig én azt hittem, hogy ez manapság már magától értetődő, de a debugger kapcsolatból minimum következik. De akkor vegyük úgy, hogy ez is követelmény :).

> A PIC16 nem feltetlen "buta" onmagaban de a memoriabankozasos technikaja miatt nem igazan C/C++ barat, mondjuk ugy.

10+ éve PIC-eztem, és már nem tudtam volna nevén nevezni a dolgot, de ja, az kellene, hogy rendes C menjen vele.

Hát pedig én azt hittem, hogy ez manapság már magától értetődő, de a debugger kapcsolatból minimum következik. De akkor vegyük úgy, hogy ez is követelmény :)

Nem feltetlen, mert miert pont UART, miert pont egy, es hogyan oldod meg azt kvazi-felhasznalobarat modon hogy mi van akkor ha arra a lab-parra is valami mas funkciot kotnel ra inkabb ha arra van szukseg... Meg ugye lasd Arduino, ott sincs emlekeim szerint (foleg a kicsiken, ahol csak egy sima egycsatornas FTDI illeszto van). De ettol fuggetlenul igen, azokon a dev boardokon amikkel jatszottam mostanaban (Nucleo sorozat, MSP430/Launchpad, ICE40HX boardok, Xilinx Digilent boardok) mar mind van ilyen. Meg sajat cuccokra is teszek hasonlo okokbol :)

10+ éve PIC-eztem, és már nem tudtam volna nevén nevezni a dolgot, de ja, az kellene, hogy rendes C menjen vele.

A PIC-ben az a nehez hogy van hozza ugyan C fordito de nagyon unhatekony a lesz kod. Az AVR-ekkel osszehasonlitva nekem ugy tunt hogy pointer-dereferenciat tartalmazo "atlagos" programok eseten a kodmeret kb 3x nagyobb, de meg ha nincs is annyi intenziv pointer-aritmetika a kodban akkor is azert kellemesen-merhetoen nagyobb. Meg ugye egy csomo minden mas is korlatoz (veges hw stack es a stack framing ugrik be elsore ami a paging/bankozas mellett meg olyan hogy nem teszi igazan C/C++ baratta a cuccot). 

Valojaban olyan MCU-t erdemes nezned amire egyszeru-de-nagyszeru oprendszereket tudsz portolni - pl. FreeRTOS-t - es mar letezik hasonlo portja ottan. Persze ez nem azt jelenti hogy muszaj oprendszert hasznalnod, de egy eleg indikativ dolog hogy tudsz oprendszert hasznalni ha akarsz.

( bazso | 2023. 10. 19., cs – 06:21 )

Wemos d1 mini, ESP-32-Cam

Informatikus vagyok, elektronikát próbáltam megszeretni az egyetemen, mert amúgy az építés vonz, de nem lettünk barátok. Ez a két cucc megoldotta a kérdést, már csak program kellett hozzájuk és a perifériák illesztése. Egy hosszabb este elég volt az első sikerélményhez. 

Amire oda kell figyelni a vásárláskir, hogy a lapon alapból legyen usb, ami egyben megoldja a programozás és a táp kérdését, a LED villogtató "hello world" így az első 10 perc ismerkedés után már működött. Egyszer belenyúltam egybe usb nélkül, hát azzal sem lettünk barátok.

Abszolut +1

Egyszer belenyúltam egybe usb nélkül, hát azzal sem lettünk barátok.

Ali-n van CH340 alapu USB<->serial adapter; amelyik lapkan van ilyen 5 tuskes "serial header", oda ra lehet kotni.

De 100% egyetertek, igy anno 2023-ban vegyel siman usb-s lapkat es kesz. Ma mar egy esp32 is par eurobol megvan.

> elektronikát próbáltam megszeretni az egyetemen, mert amúgy az építés vonz, de nem lettünk barátok

Nálam is ugyanez. Egy LED-et tudok ellenállással méretezni és forrasztani, meg egy szájbarágós adatlap alapján be tudok kötni egy kristályt kondikkal, de ennél komolyabb dolgokhoz inkább előre gyártott breakout board meg buszok kellenek, mert ennél jobban nem tudok most belemerülni.

( dlaszlo | 2023. 10. 19., cs – 08:48 )

Kifejezetten nem számítógép kell, tehát nem Raspberry és sok más ARM chipes cucc is kiesik.

Itt gondolom nem a raspberry pi pico-ra gondolsz, hanem a raspberry pi 3-4-5-re pl., A pico is jó lehet neked.

Az STM32-hez pl. a blue pill. Érdemes rá bootloadert tölteni, szerintem alapból nincs rajta.

( laysoft v | 2023. 10. 19., cs – 09:30 )

Szerkesztve: 2023. 10. 19., cs – 09:42

Én is valamilyen ESP-t javaslok, méghozzá NodeMCU firmware-el. Ezt azért szeretem, mert van egy írható filerendszere, így nem kell minden apró változás után nulláról újra flash-elni az egész kütyüt, elég csak a módosított file-t felülírni. Nagyon kényelmes, van egy build rendszer is, itt látható mennyi perifériához van hozzá modul.

Nálam az a menet, hogy WemosD1-el elkészül a project, aztán megy ESP-01-be, eddig az elég volt mindenhez. Ezzel működnek a szenzoraim, meg a villanyórára dugott cucc, ami soros porton kommunikál a mérővel. Mindegyik project-be beteszem a telnet modul-t, így ha a WIFI-re kapcsolódás megy, akkor a végleges helyén, soros port nélkül is tudok módosítást végezni a kódon, nem kell lehúzni az ESP-t, rádugni pc-re, flash, majd vissza a helyére.

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

Én sokáig (10+ évig) használtam NodeMCU-t a saját kis házi kütyüimhez, de kinőttem. Nálam a HTTP szerver és az MQTT kliens együtt nehezen fért el. Csak azért nem sajnálom, hogy használtam a NodeMCU-t, mert már tudom, hogy ha jól szeretnéd kihasználni a szűkös erőforrásokat akkor C/C++-ban programozod az ESP-t, nem script-nyelven.

Flash-elés után is megmaradó fájlrendszer az Arduino keretrendszernél is van. A távoli firmware upgrade is megy az Arduino library-kkal  HTTP-n keresztül.

( persicsb | 2023. 10. 19., cs – 09:49 )

Miért nem ajánlotta még senki az Raspberry Pi Pico W-t? Rendes ARM Cortex-M0+ mikrokontroller, a boardon van Wifi (2.4 GHz 802.11n) és Bluetooth 5.2. 

Meg sok feladathoz ágyúval verébre. Nekem is van egy project-em, ami pico-val készült, mert kényelmes voltam, de nagyon hajlom rá, hogy átírom ESP-re. Pazarlás, hogy ott figyel a raspberry-n egy komplett grafikus rendszer, ami csak egyszer az elején volt használva.

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

( asch v | 2023. 10. 19., cs – 11:51 )

Szerkesztve: 2023. 10. 19., cs – 11:58

Az STM32 Nucleo boardon nekem is bejött a beépített ST-Link és UART Out Of the Box működik Linuxon. És a toolok is mind free and open source-ok. STM32 debuggolást én csak kereskedelmi környezetben próbáltam eddig (Keil), de elvben megy Eclipse-be építve például ingyenes eszközökkel, ha összerakod.

Én az Arduino szoftver rétegét nem kedvelem, mert azért mikrokontrollerezik az ember, hogy real-time legyen, viszont az Arduino ennek folyton útban van. De amire elég, arra jó mert egyszerű elindulni.

Egyszerűbb feladatokra én Arduino UNO-t szeretek használni (ATMega328p), mert már jól ismerem és van belőle egy rakás itthon. A toolchain pedig avr-gcc+Makefile kézzel+avrdude, tehát Arduino nélküli. Ugye te írtad, hogy ennél újabb dolgot akarsz, de mégis érdemes megfontolni szerintem már csak az ezer létező példa miatt is.

Használtam a legújabb ATtiny Series0/Series1 csipeket is, az tetszik benne, hogy minden benne van magától, csak tápot kell rákötni és működik. Felületre forrasztani sem kunszt, mert annyira nem kicsi a legnagyobb változat. Hestore-ból lehet DIP illesztőt is venni hozzá. A tápra kell egy kondit tenni, azt én még az illesztőre teszem, és utána már bedugom breadboardba, 5V neki és már működik is! A beépített rezonátora elég pontos az UART-hoz is. UART-tal lehet programozni, és egy UART illesztőt lehet használni fejlesztés közben, aztán amikor kész a cucc, akkor 1 darab csip van csak beépítve. Debuggert ehhez sem használok, de csináltam hozzá egy trükkös rendszert, amivel a debug interfészen keresztül pollozza és megjeleníti a változók, vagy akár a periféria regiszterek értékeit egy konzol ablakban. Ezzel a módszerrel a legtöbb programhoz egyáltalán nem kellett UART loggolást se csinálnom.

Ha pontos időzítésekre van szükséged, akkor sokszor a kisebb egyszerűbb csipek jobban teljesítenek mint a modernebb nagyobbak. Például az interruptba lépés gyorsabb, az óra alrendszer jobban átgondolt, és alkalmasabb szinkron vezérlésre. Ezért a választás a feladattól is függ, nem olyan egyszerű, hogy újabb->jobb.

A toolchain pedig avr-gcc+Makefile kézzel+avrdude, tehát Arduino nélküli. Ugye te írtad, hogy ennél újabb dolgot akarsz, de mégis érdemes megfontolni szerintem már csak az ezer létező példa miatt is.

Ez hogy "a toolchain lehet egy sima gcc + makefile + programozo" teny inkabb azert lehet fontos ha a kollega jo IDE-t keres, mert ugye ebben az esetben biztos hogy talal(hat)sz hozza jo es testreszabhato IDE-t. Forditva, ha csak a gyarto sajat IDE-jet hasznalhatod, akkor nagyon meg van kotve a kezed. Eszi, nem eszi, nem kap mast, ha az szar es/vagy unhatekony akkor az szar es/vagy unhatekony (lasd: Microchip/PIC/MPLAB, amit fentebb is emlitettek).

Ha pontos időzítésekre van szükséged, akkor sokszor a kisebb egyszerűbb csipek jobban teljesítenek mint a modernebb nagyobbak. Például az interruptba lépés gyorsabb, az óra alrendszer jobban átgondolt, és alkalmasabb szinkron vezérlésre. Ezért a választás a feladattól is függ, nem olyan egyszerű, hogy újabb->jobb.

Igen, ez hatarozottan igy van. A Cortex-M-es ARM magoknak hatarozottan koltseges az interrupt belepes/kilepese. Konkret timing analysis szinten csak Cortex-M0-ra vannak adataim igy fejbol, ott is 16+16 orajel, es afole jon meg a szoftvernek a context mentese-visszallitasa igy desszertnek. Ehhez kepest mondjuk egy RISC-V, nagyjabol ugyanaz a performance/komplexitas szinten levo cuccnal meg 2 orajel alatt megvagy befele meg kifele is (gyk egy unconditional J koltsege az egesz). AVR-nel meg 3 orajel befele, 4 orajel kifele, pont annyi mint egy CALL. Persze az ARM-nel ezert a sok oraciklusert cserebe megnyered azt hogy a fuggvenyhivas (E)ABI az ugyanaz lesz mint az interrupt handler interfacing... dehat valamit valamiert. 

Igen, a Cortex-M specifikáció miatt menteni kell regisztereket már az IRQ belépés előtt. Az AVR viszont beléphet minden nélkül. Persze ezt kihasználni előnyként főleg akkor tudjuk, ha meg tudjuk úszni az IRQ handlerben is a regiszterek stackre mentését, ami nem triviális C-ben programozva. De szerintem ha 1-2 regisztert mentünk és visszaállítunk még akkor is megmarad némi előny.

Egy A7-es procit is programoztunk, ott egy belépési pontja van minden IRQ-nak és emiatt még el is kell belül ágazni aszerint, hogy mi jött. Ezzel már rengeteg a kötelező overhead sajnos.

Persze ezt kihasználni előnyként főleg akkor tudjuk, ha meg tudjuk úszni az IRQ handlerben is a regiszterek stackre mentését, ami nem triviális C-ben programozva.

Ugy latom hogy a gcc azert nem general annyira rossz kodot, bar persze lehet(ne) hatekonyabban nehany esetben is. Foleg ha SBI/CBI-re visszavezetheto az egesz. De ha ennyire ki van centizve a dolog akkor igyisugyis marad a naked handler + assembly :] 

( gazsiazasz | 2023. 10. 19., cs – 14:14 )

esp32: debug nincs, wifi van bt van, ram 520k

stm32 nucleo: debug van, wifi nincs, bt nincs, ram lofasz

rpi pico w: debug nincs, wifi van, bt van, ram 260k

STM32L476=Ultra-low-power Arm® Cortex®-M4 32-bit MCU+FPU, 100DMIPS,
 up to 1MB Flash, 128 KB SRAM, USB OTG FS, LCD, ext. SMPS

Az adatlap szerint 128 KB SRAM van az MCU-ban. Elég sok STM32-höz lehet külső SRAM-ot, SDRAM-ot csatlakoztatni, de azokat akkor sem triviális beindítani, ha az SDRAM IC rajta van a PCB-n. Szerintem először a belső SRAM-ot használd.

Szerk: a 128 KiB SRAM nem összefüggő. 96 Kbyte a 0x2000 0000-s, 32 Kbyte a 0x1000 0000-s címen érhető el. Ez kezdőként kicsit zavaró lehet, mert #pragma-val, section attribútummal vagy valamilyen linker varázslással lehet innen foglalni memóriát.

Egyébként ilyen STM32L476-os Nucleo-m nekem is van, ha ilyet veszel segíthetek. Ezen kívül van még 4-5 Nucleom, Cortex-M7, Cortex-M7F-ig. Én ár/érték arányban az NUCLEO-F722ZE-t tartom legjobbnak: 512 KiB flash ROM, 256 KiB RAM van benne és most bruttó 10 ezer HUF a Farnell-nél.

Szerk: a STM32F722-ben is van valami kavarás, de a linker fájlom szerint összefüggő a 256 KiB RAM.

( joco01 v | 2023. 10. 19., cs – 16:59 )

Szerkesztve: 2023. 10. 19., cs – 17:00

Köszi a sok választ. A developer experience alapján az STM32 Nucleo tűnik a legjobbnak.

Úgy látom, hogy ez ráadásul kompatibilis Arduino perifériákkal is (pl. ebbe a lapba bele lehet tenni ezt a wifi modult). De az ST-nek vannak saját perifériái is. Gondolom, hogy ebből többet is egymásra lehet tenni.

Még egy kérdés. Kell-e valamire figyelni, ha pl. egy ilyen kijelző modult akarok rátenni? Remélem, nem nagyon kell kompatibilitás miatt aggódni (jelszintek/pinek első ránézésre stimmelnek). Nem kifejezetten Doomozni szeretnék rajta, de kíváncsi vagyok, hogy van-e olyan teljesítményű STM32, ami ezt meg tudja hajtani.

Igen, a Nucleonak Arduino kompatiblis pin headerje van, ami Arduino shield 3.3V kompatibilis (ami 5V-ot vár, vagy 5V-ot ad az nem lesz jó), az kell hogy működjön vele. Úgy tudom a szoftvert is meg lehet Arduino IDE-n belül írni - én nem csináltam ilyet.

A kijelzőre: ehhez a kijelzőhöz egyetlen kép a memóriában 480x320x2=307200 bájtot foglal el. Ha nem fér el a teljes kép egyszerre, akkor macerásabb kezelni mintha elférne. És a teljes kép frissítéséhez ennyi pixelt át kell tolni a data vonalon, ami idő. Emiatt én inkább monokróm kijelzőt szoktam mikrokontrolleren használni, ezt: https://www.hestore.hu/prod_10036444.html 8192 pixele van. Ennek a képét az ATMEGA328 és az Attiny1624 is kezeli "fejben" - 1024 bájt. Szövegesen 4 sor fé el rajta. Egyszer kimértem, több mint 20FPS-sel tudom frissíteni az interrupt vezérelt SPI libbel amit faragtam hozzá. Az I2C változatot is használtam, teljesen hasonló.

> Ha nem fér el a teljes kép egyszerre, akkor macerásabb kezelni mintha elférne.

Egy Arduino Uno rev3-ban csak 2 KiB RAM van. Ezen a videón látszik, hogy soronként rajzolja a képet, de a már kirajzolt rész nem tűnik el, nem villog. Valahol el van tárolva, talán magán a kijelző modulon?

Igen, a kijelzőnek van egy memóriája, amiben egy frame-et tárol, és onnan frissíti a képet folyamatosan. Szerintem van olyan is, amin van double buffering. Az, hogy az egész memóriába fér, akkor kényelmes, ha random módon akarsz rajzolni. De meg lehet lenni enélkül is, csak bizonyos műveletek bonyolultabbak lesznek és minden lassabb lesz. Én saját rajzoló könyvtárat is csináltam, emiatt az egyszerűségre törekedtem.

Arra kell figyelni, hogy a Nucleo 3.3V-os feszültséget szeret az I/O portokon, míg a klasszikus Arduino Uno 5V-al ment. (Egyes Nucleo-kat át lehet jumperelni 1.8V-ra, gondolom ez az I/O feszültséget is változtatja, de utána kell nézni.)

A 3.3V-os I/O miatt a shield-ek kapcsolási rajzát érdemes tanulmányozni, hogy visszajuthat-e 5V az I/O-ra, mert az kinyírhatja az adott I/O-t, vagy az MCU-t.

Igen, a shield-eket lehet tornyozni. Nagyobb fogyasztású shield-eknél lehet probléma a táppal, az USB 2.0-ás portból a szabvány szerint 500 mA-t lehet kivenni. De át lehet jumperelni a Nucleo-kat, hogy pl. a VIN-ről kapjon tápot. Ha valami nagyobb frekvenciával (10-20 MHz felett) működő dolgot építesz, gond lehet még a sok csatlakozásból és a hosszú vezetékekből, amik a shield-ek miatt alakulnak ki. Ezeket a klaszzikus tüskesorokat nem sok MHz átvitelére találták ki.

ha pl. egy ilyen kijelző modult akarok rátenni? 

Hat, ha egy Arduino/ATMega jellegu MCU meg tudja hajtani ezt akkor egy STM32 rohogve :) Nagyjabol a legbeleposzintubb STM32-esek vannak olyan szinten mint a kozepes-nagy ATMega-k. Szoval a teljesitmeny miatt nem aggodnek. Viszont csatlakozom az elottem szolokhoz mert jelszint (3.3V vs 5V) miatt mar annal inkabb aggodnek. Vannak ugyan az STM32-es IC-knek olyan "bankjai" amik 5V-toleransak (pl a CAN_RX CAN_TX labacskai), de az elegge kontroller-fuggo, masreszt meg akkor sem baziroznek erre. 

( kisg v | 2023. 10. 22., v – 14:28 )

Szerkesztve: 2023. 10. 22., v – 14:28

Én az ESP32-C6 -ot javaslom, mert ebben már RISC-V mag van és a wifi + BLE mellett már Thread / Zigbee radio is van benne. 

A hivatalos DevKit tök szépen bepattan egy szabványos breadboardba (mi BB830-cal használjuk), és drótozhatsz össze bármit, amit akarsz. Az ESP-IDF tényleg professzionális fejlesztőkörnyezet, nem egy Arduino szintű játékcucc.

Az ára nagyon baráti, szerintem érdemes lehet többet venni belőle (2-3), és akkor az egymás közti kommunikációt, mesh network építést is tudod próbálgatni. 

Amin OS fut, azt semmiképp nem nevezném mikrokontrollernek. Ezzel az erővel lehtne venni egy mini-ITX alaplapot, vagy egy router-t, amire fel kell tenni egy OpenWRT/LEDE-t, aztán készen vagyunk. Csak ezek egyike sem mikrokontroller.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem itt valami félreértés van. Nem csak a BSD, a Linux meg a Windows OS. Vannak beágyazott rendszerre készült OS-ek, amik általában csak ütemezőt, semaphore-, event-, mutexkezelést tartalmaznak, minden más a fejlesztőre hárul (nincs fájlrendszer, TCP/IP stack, stb.). A munkám során ilyen OS-ek szoktak futni a mikrokontrollereken: FreeRTOS, SafeRTOS, ThreadX, uCOS-II, uCOS-III, MQX, Keil RTX, RTXC Quadros, Sciopta, stb. És ezeken kívül van még egy rakással.

A FreeRTOS-t elvileg futtathatod 8051-esen is, legalábbis létezik a FreeRTOS-nak 8051-es portja, de GHz-es Cortex-A9-esen is futhat.

Ez olyan, mint amikor valami elveszíti közpénz jellegét. Szerintem amire OS-t tesznek, az elveszíti MCU jellegét. Amire hivatkoztam, az éppen a FreeRTOS volt. Az MCU-kban az a pláne, hogy mindent magadnak csinálsz az inittől a zamatos részekig. Bár nyilván nem szívesn implementál az ember pl. USB vagy TCP/IP stack-et, de akár a libc dolgai - pl. memset(), memcpy(), printf() - is jöhetnek valamilyen előre létrehozott könyvtárból.

Bár értem, hogy hardware-es megközelítéssel azért MCU valami, mert egy rakás periféria van a CPU köré rakva a chipen.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A mikrokontrollert a hardver teszi azzá, ami. Szoftvert vagy oprendszert írhatsz bármire, hiszen a linux egy üres gyufásdobozonis fut. ;)

Amit locsemege ír, a memset(), memcpy(), printf() - azok olyan implementációk, amelyek magasszintű nyelv és gyakran számítógépszerű perifériák felhasználását sugallják.

Pedig nem mondhatod, hogy egy klaviatúrában NEM mikrokontroller van, vagy egy 30B ram+512B flash kiépitettségű, vagy akár egy 4 bites eszköz NEM mikrokontroller. Sajnos a fejlesztőeszközök milyensége sem perdöntő.

Ehhez képest az i80186 is mikrokontroller, hiába lehet blőle Windows futtató pécét építeni.

A mikrokontroller környezetet főként az integrált perifériák adják, de azok a lib-ek, amelyeket úgy valósítottak meg, hogy operációs rendszer-szerű rendszerhívásokként használhatod, az inkább az embedded rendszerek felé mutat. Pl. egy egyszerű programban nem feltétlenül szükséges az usb-t legalább kettős buffereléssel használni, hiszen nem multitasking operációs rendszert futtatsz. Az se baj, ha a printf() nem thread-safe. :-D

A "mikrokontrollerezni szeretnék" számomra azért tréfás, mert első a feledat és ahhoz választunk mikrokontrollert. Ehhez a nézethez a PIC családok a legjobbak, bár az a topicnyitónak büdös.

(Kiegészítés: Manapság azt választjuk, ami van a boltban és legalábbb az egy éves gyártás darabszámát fedezi. ;))

Ezzel nagyon egyet tudok érteni. 

Szerintem ha egy FreeRTOS fut is a mikrokontrolloren az még mikorokontroller. Úgyanúgy tudnod kell mit csinálsz és nagyon tisztában kell lenned HW-rel. 

 

Azzal is nagyon egyet tudok érteni, hogy feladathoz választunk kontrollert(illetve ami kapható). 

Bár az otthoni hobbiban én már elfogatam, hogy ESP+Arduino-val nagyon könnyen és gyorsan lehet megcsinálni egyszerű dolgokat, de munkában éles környezetben az arduino no-go.

Otthonra van is állandó jelleggel pár ESP32-s boardom, ha kell valami csak előkapom és mehet.

 

Egyébként vannak free, reentrant(thread-safe), szépen configolható és megírt printf library-k. 

> Szoftvert vagy oprendszert írhatsz bármire

Én ezt úgy mondanám, hogy mindenre lehet, de nem mindenre kell OS. Mondjuk a Linux pont egyre válogatósabb, hogy min fut el.

> A "mikrokontrollerezni szeretnék" számomra azért tréfás, mert első a feledat és ahhoz választunk mikrokontrollert.

Nincs feladat, ez hobby, játék. Elég jól körbehatárolható a scope szerintem. És ehhez kaptam jó ajánlásokat, szóval a többségnek sikerült értelmeznie.

> Ehhez a nézethez a PIC családok a legjobbak, bár az a topicnyitónak büdös.

Ez azért nem jó a feladathoz, mert több munka és kevesebb élmény :).

Ha Ethernetre és Wifire megelégszel egy UART-Wifi, vagy egy UART-Ethernet modullal, akkor pedig lehet, hogy tényleg jobban jársz egy PIC-kel. (És lehet, hogy van Ethernetes vagy Wifis PIC is, nem ismerem.) Én az AVR-es ATTiny Series 1 sorozattal vagyok így mint Bucko, szerintem az a legtutibb. Sokszor az egyszerűbb a jobb, azzal lehet gyorsabban haladni. A bonyolultabb processzor jobbnak tűnik agészen addig, amig először nem találkozol valami UFO jelenséggel, amit csak úgy lehet megérteni, ha elolvasod a többszáz oldalas doksikat az ARM bugyrairól. Például csak az IRQ alrendszere is elképsztő bonyolult már egy STM32-nek is. Ehhez képest a 8 biteseket ezerszer könnyebb felfogni, hogy mi történik és miért. Én is erre beszélnélek rá inkább.

( redman | 2023. 10. 24., k – 08:30 )

ESP32 bármelyik board (köztük a Wemos D1 mini klón is), amit USB-n rá tudsz dugni a számítógépre.
VSCode, PlatformIO. Nagyon szép build file-t is lehet írni a projekthez, a lib függőségek is meghatározhatók, így bárhol lefordul utána.

Kis Python ismerettel kibővíthető a build folyamat és csodákat tudsz művelni vele.

A Bluetooth és a Wifi elérhetőség miatt nem is kell plusz eszköz adott esetben, hálózati dolgok implementálásával simán el lehet indulni, mondjuk egy okosizzót http-n vezérelni. 

https://www.redman.hu