Tartalom:
- Raspberry Pico lábkiosztás és műszaki adatok
- Telepítés
- Első programfeltöltés, bootsel gomb
- USB eszköz nem felismerhető hiba javítása
- Pédaprogram belső hőmérővel
- Soros monitor eltérései Arduino-oz képest
Eddig elég jól elvoltam az Arduino nano és Uno alaplapokkal és az ATMega vezérlőkkel. Azonban a Forint gyengülésével jelentősen emelkedett ezeknek az eszközöknek az ára a magyar boltokban, és kínai kedvenceinknél is. Anno vettem nano alaplapot 600 (!!) Ft-ért, immár 2-3000Ft. A magyar boltokban meg 4000Ft körül vesztegetik. Ezért kezdtem keresni olcsóbb megoldást. Több alaplapot is megrendeltem és mostanában kezdenek megérkezni. A rendelésnél szempont volt, hogy az alaplapra az Arduino IDE-vel készíthessek programot, esetleg meglévő kódjaimat használhassam. Nincs túl sok időm ezért csak most jutottam oda, hogy vegyek egy nagy lélegzetet és belevessem magam az ismeretlenbe. Első áldozatom a Raspberry PI Pico lett. Sikerült szállítással együtt bruttó 2000Ft-ért beszerezni. Nem az eredeti alaplapot rendeltem, hanem VCC-GND Studio YD-RP2040 alaplapját. Ez volt olcsó. Féltem tőle, de egyenlőre úgy tűnik megy a szekér!
Az alaplap főbb részei láthatók a képen, van rajta 2Mb flash memória és egy RGB led is a RP2040 processzoron kívül.
A szokásos pinout ábra:
Az alaplap legfontosabb tulajdonságai (Figyelem, a kontroller 3.3V-os):
- MCU – Raspberry Pi RP2040 kétmagos Cortex-M0+ mikrokontroller (133 MHz órajel, 264 KB SRAM, 2 MB flash)
- USB 1.1 Type-C port tápellátáshoz és programozáshoz
- GPIO (3x 12 bites ADC 500 Kbps-ig, 2x UART, 2x I2C, 2x SPI, 16x PWM)
- 2x programozható nagysebességű I/O (SD kártyához, VGA-hoz stb.)
- 3.3V I/O feszültség
- Hibakeresés – 4 tűs Arm Serial Wire Debug (SWD) port
- BOOTSEL gomb, (USB csatlakoztatáskor megnyomva meghajtóként jelenik meg a flash memória)
- NRST reset gomb, USER gomb
- Felhasználói LED (GP25 kivezetésen WS2812 címezhető soros led),
- 1x 64 bites időzítő 4x riasztással (Interrupt),
- RTC óra (MCU órajelet használja, megszakítással működik, tápfesz kimaradáskor újra be kell állítani, nincs külső elem táplálás)
- Tápegység – 5V USB Type-C porton vagy 2–5 V DC VSYS kivezetésen keresztül
- Méretek – 53 x 21,5 mm
Ennek az alaplapnak kétféle alaplapkezelő könyvtárat is találtam. Ha a szokásos módon az Arduino IDE Eszközök / alaplap:… / könyvtár kezelő menüpontjában a kereső mezőbe beírom, hogy „pico”, alapból csak egy használható könyvtár jelenik meg:
Ha van már alaplap kezelőnk, akkor azonnal fel is másolhatjuk az első működő programot az alaplapra. Hogy melyik legyen? Hát a klasszikus blink program a példák közül. Szerencsére ezen a programon semmit nem kell változtatni, azonnal működni fog. Az alaplapra történő első feltöltés azonban kicsit speciális módon történik. Ha bedugjuk az USB portba, akkor a Windows fel sem ismeri mint eszközt (így emlékszem vissza az első csatlakoztatásra, de akkor még nem figyeltem erre, azóta meg már felismeri). Szóval első lépésben úgy kell bedugni, hogy legyen benyomva a BOOTSEL gomb. Ilyen állapotban megjelenik az alaplap egy flash meghajtóként, mintha egy pendrive lenne! Ekkor az Arduino IDE-ben töltsük be a blink programot (File/Példák/Basic/Blink). Az eszközök menüben alaplapnak válasszuk ki Az „Arduino Mbed OS RP2040 Bords” alaplap csoportból a „Resoberry Pi Pico”-t.
Most kattinthatunk a feltöltés gombra. A feltöltés sikeres lesz (remélem) és ezt követően már megjelenik egy olyan sorosport a Windows-ban, amit a portok közül ki is tudunk választani:
Ettől a pillanattól kezdve, ha bedugjuk az eszközt, akkor létrejön a sorosport, és megy a feltöltés a BOOTSEL nyomvatartása nélkül is. Egy hiba miatt, amiről kicsivel lejjebb írni fogok, rátöltöttem egy új firmware-t az alaplapra. Sajnos nem emlékszem, hogy az eredeti gyári firmware-el mit csinált, de a mostani újjal egy pillanatra felugrik a Windows intéző ablaka, amiben megmutatja a csatalakoztatott meghajtó tartalmát, és egy-két másodperc múlva el is tűnik és kiírja az Arduino IDE, hogy feltöltés kész. Jó, hogy így történik, mert nagyon kényelmetlen lenne minden feltöltés lőtt kihúzni és újra visszadugni. Azt vettem észre, hogy egy klasszikus Arduino Nano esetén a sorosport száma változik attól függően, hogy melyik USB portba dugom be. Ennél az alaplapnál azonban nem, nálam mindig a 11-es port jön létre, függetlenül az USB csatlakozótól.
Még érdemes megnézni a BOOTSEL megnyomásával történő csatlakoztatáskor megjelenő drive tartalmát:
INFO_UF2.TXT tartalma:
UF2 Bootloader v3.0
Model: Raspberry Pi RP2
Board-ID: RPI-RP2
Ha pedig az INDEX.HTM-ra kattintunk, akkor annak rendje módja szerint egy weboldalon találjuk magunkat, ahol rengeteg információt tudhatunk meg többek között a Raspberry PI Pico-ról is.
Boldogan kezdtem használni ezen tudás birtokában az alaplapot! Olvasgattam a neten és észrevettem, hogy van az RP2040 chip-en belső hőmérő. Nosza kezdjük használni. Persze a példa programok között, amit ehhez az alaplapkezelőhöz adtak, alig van valami. Találtam azonban C-ben írt mintapéldákat, amik segítségével kisebb-nagyobb kísérletezgetéssel sikerült megírni a programot.
Forrása:
//A mérés elve az, hogy megmérik az ADC-vel az alaplap egyik diódájának feszültségét, ami függ
//a hőmérséklettől. Annyit tudunk erről, hogy a szilícium dióda nyitófeszültsége tipikusan 706mV,
//a dióda hőmérséklet függése pedig 1,721mV/Celsius fok (egy fok emelkedés, 1,721mV-al növeli a nyitófeszültséget.
const float felbontas=0.80566; //az ADC felbontása voltban 3300mV/4096=0,80566mV (3.3V tápfesz az 3300mV)
//A processzor belső alaplapi diódájának feszültsége 27fokon 706mV
//A dióda 1fok változásra 1.721mV változással reagál (hőmérséklet növekedésre a fesz csökken)
//nálam 22fok hőmérsékleten a mérés eredménye adc_read()->869.
//Ez dióda feszültségben 869*0.80566=700mV
//Tehát a hőmérséklet 700-706=6 (6mv-al kevesebb, mint a dióda
//feszültsége 27fokon), vagyis 6/1.721=3,48fok
//A processzor alaplapi hőmérséklete 27-3.48=23.52 fok.
//Épp tél van, a lakásban 22fokra szabályoz a termosztát
//tehát ez akár igaz is lehet.
float homerseklet;
void setup() {
Serial.begin(115200);
//ADC konfigurálása. Ezt az utasítás sorozatot egy mintapéldából vettem, amit C++-ban írtak, de nem Arduino IDE
//környzetben. Ennek ellenére működik.
adc_init();
adc_set_temp_sensor_enabled(true);
adc_select_input(4);
}
void loop() {
Serial.print("ADC eredmény:");Serial.println(adc_read()); //mérünk egyet az ADC-vel, és kiírjuk az eredményt
homerseklet=27-(adc_read()*felbontas-706)/1.721; //kiszámoljuk a hőmérsékletet az ADC eredményéből
Serial.print("Temp:");Serial.println(homerseklet);
delay(1000);
}
Látható, hogy nem az Arduino IDE környezetben megszokott utasításokból épül fel a program. Pl. Arduino nano esetében még nem láttam adc_select_input() és adc_read() függvényeket. Ennek ellenére a program működik. Boldogság! Hőmérőnek elég nehezen használható, mert a chip belső szilícium lapkája picit melegebb mint a szoba, nálunk 22 fokos szobahőmérsékletnél 30 fok körüli értéket mért. Ha megfogtam az újammal, kb. 34-35 fokig emelkedett a hőmérséklet.
Miközben a neten keresgéltem a fenti forrás alkatrészeit, kiderült, hogy van egy másik alaplapkezelő is! Ennek telepítése kicsit macerásabb, mert első lépésben a Fájl / Beállítások menüpontot kell elindítani. A megjelenő ablakban az alaplap kezelő URL-ek sor végén kell a kis kocka alakú ikont megnyomni, és beilleszteni a már meglévő alaplap kezelő URL-ek mögé vagy közé az alábbi sort:
https://github.com/earlephilhower/arduino-pico/releases/download/global/package_rp2040_index.json
Ha ekkor megismételjük az alaplap kezelőben a keresést, akkor egy másik alaplapkezelő könyvtár is megjelenik:
Mindkét alaplap kezelő könyvtárat kipróbáltam. A második, nevezzük „Philhower”-nek, sokkal jobban tetszett, mert nagyon sok kezdőnek is használható példaprogramot is hozott magával. Azonban nem csak ez okozta a szimpátiámat. Az első alaplapkezelővel történt egy incidens! A lefordított programba olyan programsort írtam, ami szintaktikailag helyes volt, de nemlétező kivezetést adtam meg. Nevezetesen pont a belső hőmérséklet érzékelővel kísérleteztem, és mivel azt olvastam, hogy a 4. ADC-re van belül a chip-ben rákötve, beírtam: analogRead(4). Ez nyilvánvaló hülyeség, mert a 4-es láb nem analog bemenet, de nem gondolkodtam, csak cselekedtem. Mint tudjuk ez nem célszerű sorrend. Ennek hatására teljesen elvesztettem a modult. Többé nem lehetett rátölteni semmit. Ha bedugtam az USB portba, a Windows azt írta ki, hogy az eszköz nem felismerhető! A BOOTSEL gombbal láthatóvá vált a flash, de azon kívül semmit nem csinált. Mint kiderült, ez egy hiba, amire van megoldás. A netet túrtam egy darabig, amíg megtaláltam. Valószínűleg a Philhower könyvtár használatakor is előfordulhat, ezért közzé tenném a megoldást még most az elején, hogy ne kelljem másnak is keresni (nomeg nekem se legközelebb).
„USB eszköz nem felismerhető” hiba javítása:
A javításról videó itt: https://www.youtube.com/watch?v=AT_4p6Aecow
Link a javító csomag letöltéshez: https://drive.google.com/file/d/1aPxh6wQMQ8DqqGY1vgz7uWMim40DIhRa/view
A javításhoz a következőket kell tenni:
- A javító csomagot kibontani.BOOTSEL gombot nyomva tartani és bedugni az alaplapot az USB-be.
- A megjelenő flash drive-ra (meghajtóra) másolni a kibontott állományból az flash_nuke.uf2 állományt (ez a javított firmware)
- Az USB meghajtó rövid időn belül eltűnik, majd újra megjelenik
- Az USB-ből kihúzni az alaplapot
- Bedugni újra, és ekkor újra megjelenik a drive a BOOTSEL megnyomása nélkül. A Windows nem jelez felismerhetetlen eszközt. Többször is elrontottam az alaplapot szándékosan, és egy alkalommal ennél a pontnál nem jelent meg a meghajtó. Azonban a BOOTSEL gombbal kierőszakoltam, hogy megjelenjen, és ettől a szabálytalanságtól függetlenül a további lépések működtek.
- Rámásolni a másik állományt, és kihúzni az USB-ből
- Visszadugáskor már felismeri a Windows az USB eszközt és betelepíti soros portnak:
Ekkor már az Arduino IDE is látja a sorosportot (előtte nem látta, csak azokat, melyeket eddig is látot, pl fizikai sorosport, bluetooth által megjelenített sorosport stb.):
- Ekkor Első feltöltés előtt újra BOOTSEL gombot nyomni, mert sima soros porton keresztül nem tud feltölteni. Ekkor ugyan nincs soros port, mégis feltölti valahogyan. Ugyanez történt amikor a megvásárolt alaplapot először használtam. Feltölttés után már a további feltöltésekhez nem kell BOOTSEL, de más portot mutat majd a Windows
Ekkor már újra lehet normálisan BOOTSEL nélkül feltölteni a programot, ahogy a hibás állapot előtt csináltuk!
Térjünk vissza az újonnan megtalált Philhower alaplapkezerlőre. Jó sok mintapéldát hoz magával, például ennel az alaplapkezelőnél így néz ki az alaplapi hőmérsékletmérő használata:
//A mérés elve az, hogy megmérik az ADC-vel az alaplap egyik diódájának feszültségét, ami függ
//a hőmérséklettől. Ez a program a "Philhower" féle alaplap kezelővel lett fordítva!
float homerseklet;
void setup() {
Serial.begin(115200);
}
void loop() {
Serial.print("Alaplap hőmérséklet:");Serial.println(analogReadTemp());
delay(1000);
}
Ugye mennyivel szebb és egyszerűbb!? A hőmérsékletet konvertálni sem kell, közvetlenül celsius fokban kapjuk meg az eredményt az analogReadTemp() függvénytől! Meg kell jegyeznem, hogy az a Philhower kezelő nem fordítja le a feljebb található programot, mert nem ismeri fel az adc_select_input() és adc_read() függvényeket. Az elsőre letöltött „Arduino Mbed OS RP2040 Board” alaplap kezelő pedig nem ismeri fel az analogReadTemp() függvényt. Úgy tnik számomra, hogy az alaplap kezelő könyvtárak a rendelkezésre álló alapvető nyelvi elemeket is meghatározzák. Nyilván mindkettő ismeri a szabvány C++ nyelvet, de más kiegészítő hardver specifikus függvényeket szolgáltat. Számomra eddig ez sem volt teljesen egyértelmű, bár így utólag teljesen logikus!
A Philhower alaplapkezelő jóval több Pico alaplap változatot támogat. Elég csak ránézni a kiválasztható alaplap típusok sokféleségére. Szerencsére az általam vásárolt VCC_GND Stúdió Pico változat teljesen szabványosnak tűnik, és a Raspberry Pi Pico alaplappal működik:
Míg a legelső alaplapkezelőben gyakorlatilag semmit nem lehetett beállítani, a Philhower már számos beállítási lehetőséggel rendelkezik:
Még egyiket sem próbáltam ki, egyelőre örülök, hogy működnek a dolgok. Az Arduino UNO esetében is hónapok teltek el, míg felismertem, hogy ezek a beállítások fontosak lehetnek.
Eddig még csak két programot próbáltam írni az YD-RP2040 (híjuk röviden Pico-nak), de máris tapasztaltam egy jelentős különbséget az Arduino Nano-hoz képest az alaplap és a PC kommunikációjában. Az Arduino Nano Uno stb. alaplapokra egy külön serial USB átalakító chip-et építettek. Ezért amikor a PC-n megnyitom a soros portot (pl. elindítom az IDE-ben a soros monitort, vagy elindítok egy külön programot mint a puTTY), akkor ez a chip rögvest egy reset jelet is szolgáltat az ATMega chip-nek. Ez nagyon jó, mert ezzel a vezérlőbe töltött program azonnal elindul, és lehet nézegetni a program futását legelőről. Mivel az RP2040 chip-be beleépítették az USB vezérlőt, és érthető okból itt nincs reset, kicsit kényelmetlen módon viselkedik a soros monitor az IDE-ben. A program feltöltése után a program elindul. Ha ekkor elindítom a soros monitort, nincs reset, így csak bekapcsolódhatok az eseményekbe, ahol az éppen tart. Ha megnyomom az YD-RP2040 alaplapon a reset gombot (mert ezen van a klasszikus Rasberry Pi Pico alaplappal szemben), akkor a program újraindul, de a soros monitor elveszíti a kapcsolatot. Tehát a soros monitort el kell indítani újra, és már megint csak az események közepében vagyunk. A program indulásakor esetleg serial.Print()-el kiírt dolgokat nem láthatjuk, hacsak nem tökéletesek a reflexeink, és nem tudjuk 0 másodpercen belül indítani a soros monitort. Próbáltam, nem megy! Egyetlen megoldást találtam, ha fontos a kezdeti jelenségek megfigyelése, hogy beraktam a setup()-ba egy kb 5 másodperces delay()-t. Nekem ez már elég volt egy soros monitor elindításra, és mindent láthattam, ami érdekel.
Más megoldás is lehetséges, mert ráköthetünk a Pico fizikai kivezetéseire (serial TX, RX) egy külső USB soros átalakítót, amit ha nem húzunk ki a soros portból, akkor folyamatosan regisztrálni fogja az eseményeket. Pont így működik az időjárás állomásom hetek óta egy puTTY programmal. Így naplózom azokat a nagyon ritkán előforduló hibákat, amiket nem tudok előidézni, csak megvárni az előfordulásukat!
Azonban fel lehet ezt fogni más szemszögből is. Az Arduino Nano esetén nem lehet úgy elindítani egy soros monitort, hogy nem induljon újra a program. Hát itt lehet. Amikor csak eszembe jut! A program fut, fut és akkor csatlakozok be az eseményekbe, amikor csak akarok. Ha újra kell indítani, arra meg ott a reset gomb és az 5 másodperces delay() lehetősége. Már ha kell! Így az tán arra jutottam, hogy jobb ez így, bár az esetek többségében valóban kényelmetlen!
Most következnek számomra a dolgos hétköznapok. Elég sok furcsaságot tapasztaltam a fentebb bemutatott mintaprogramok használata során, az anomáliákat még meg kell fejtenem. Sorban ki kell próbálnom az alapvető építőköveket, hogyan működnek a számomra még szokatlan 3.3V környezetben. Arra számítok, hogy nem lesz probléma, hiszen a legtöbb modul 3.3V-5V tartományban működik. De pl. az FRAM jelenleg csak 5V-os kivitelben áll rendelkezésemre. Szerencsére már készülök egy ideje az átállásra, és beszereztem egy fél zsák 3.3V <–> 5V kétirányú szintillesztőt! Az Arduino laboromnak kikiáltott próbapanelemről nem fogom még egy darabig leszerelni az Arduino UNO R3-at, de jó sokat kell majd dugdosni a vezetékeket, amikor hol ide, hol oda kell dugdosni a 2×16 LCD kijelzőmet stb, és a tápfeszekre is figyelni kell!
Azért vannak még lényeges különbségek, nem lehet csak úgy egyszerűen cserélni a két alaplapot. Amennyiben a kivezetéseket kimenetnek használjuk, jóval kisebb azok terhelhetősége. Az adatlap megadja a magas kimeneti feszültség minimális értékét a különböző kimeneti áramokra. 2,4,8,12mA értékeket említ beállítástól függően. Nem pontosan értettem meg, hogy ez alatt mit ért, minden esetre a maximális áram 12 mA-nél biztosan nem lehet nagyobb egy kimenetnek beállított kivezetésen. A chip teljes áramfelvétele pedig nem lehet több 50mA-nél. Ezek az adatok még csak első ránézésre születtek, nem tuti! A led-ek 2mA-nél már elég jól világítanak, más nagy fogyasztó pedig nincs a látókörömben, így ebben nem látok megoldhatatlan problémát!
A bemenetek felhúzó ellenállásai is más nagyságrendbe esnek. Az adatlap fel és lehúzó ellenállást is említ, de még nem jutottam oda, hogy a lehúzó ellenállás bekapcsolásának módját megismerjem. A fel és lehúzó ellenállások értéke egyarán 50-80Kohm közötti érték. Ez esetleg hosszabb vezetékek esetén kevés lehet, így erre is érdemes figyelni. A másik lényeges eltérés a sebesség! Alap órajel 133Mhz. Azért ez már nyolcszorosa az ATMega chip-ek órajelének. Lesznek modulok, ahol ez gondot fog okozni. Pl. léptetőregiszterek, optocsatolók ennél sokkal kisebb sebességekre képesek. Tehát ilyen modulok esetén foglalkozni kell a SPI busz sebességével stb.