Új kütyük – MSP430G2 Launchpad, PicKit2, dsPIC33

Újabb beszerzési kör után a címben szereplő eszközök birtokába jutottam, így immár ezeket is tanulmányozhatom.

TI MSP430G2 Launchpad MSP430G2553 mikróvezérlővel

MSP430G2 LaunchPad
MSP430G2 LaunchPad

A “kisebb ellenállás” a Texas Instruments MSP430G2 fejlesztőkártyájával valósult meg, (sajnos a PIC-el ellentétben) a TI Code Composer szoftver azonnal működött a kártyával; fordított, írt, debug-olt, ráadásul hardveresen! Elsőként egy üres (önmagára ugró jmp), semmit nem csináló kód felprogramozása történt meg az MSP430G2553 mikróvezérlőre, majd a LED villogtatás sem váratott magára sokáig. Kicsit szokni kell az új eszköz némileg eltérő (de a régi C64-es 6502/6510-hez azért kicsit talán közelebb álló) Assembly nyelvjárást, de némi próbálkozás után a 16×2 karakteres LCD-t is sikerült beüzemelni rajta, így a “Helló Világ!” üzenet is hamar elkészült. Érdekes, de egyben izgalmas ennek a chipnek a programozása, sokkal több címzésmóddal, sokkal szabadabb adatmozgatásokkal rendelkezik, mint az ATmega, de egyben sokkal szerényebb utasításkészlettel is rendelkezik, mely talán a hardveres egy óraciklusos 8 bites szorzás hiányának kivételével amúgy nagyon kényelmesen használható. Végre van regiszterrel indexelt címzésmód, ami a tömbszerű elemek Flash és SRAM-ból való olvasását teszi egyszerűbbé, és a 16 bites regisztereket nagyon könnyű megszokni. Sajnos a szorzást külön szubrutinban le kell majd programozni (ahogy pl. az ATmega esetén az osztást kellett), aminek leginkább az a hátulütője, hogy mintegy 30-40 óraciklus szükséges egy 8 bites szorzási művelethez. Szerencsére a HF teljesítmény-analizátoros kódnál négyzetre-emelések vannak, amit akár előre kiszámolt táblázatból is olvashatjuk az előbb említett regiszterrel történő indexelt címzéssel, így bár 512 bájt Flash-t elpocsékolunk konstansokra (8 bites minták esetén legalábbis), de újra egy órajeles műveleti időben vagyunk. A/D konvertere jóval gyorsabb, mint az ATmega chipeké, 200MSps sebesség mellett 10 bites felbontást kapunk, mely akár multiplex módban 2 audio csatorna mérésére is alkalmas lehet, akár még a 100kHz körüli mintavételi frekvencia mellett. Remélhetőleg ezzel már kezelni tudom az ATmega-val készült teljesítmény-analizátor apró mintavételezésre visszavezethető hibáját, pontatlanságát, így tehát elsőként ezt a projektet fogom átmigrálni erre az eszközre, és ezen folytatom a fejlesztését.

PicKit2 programozó és dsPIC33

Sajnos ez a vonal bizonyult makacsabbnak, már ami az eszköz “magamévá tételét” illeti. Itt egyelőre sajnos még egy üres végtelen ciklust se sikerült a chipre égetni, sőt még lefordítani se anélkül, hogy ne hányná tele hibaüzenetekkel a képernyőt a fejlesztőszoftver. Nagyon morbid, már-már parajelenségnek számító dolgok történtek, pl. az MPLAB X egyszer úgy gondolja, hogy nem kompatibilis a választott dsPIC33FJ64MC802-I/SP a PicKit2-vel, csak a PicKit3-al, máskor meg úgy gondolja, hogy mégiscsak kompatibilis vele. A fejlesztőszoftver égető programja amúgy felismeri a dsPIC chipet, pontosan kiírja annak típusát, lehet törölni a chipet, de nem lehet írni/olvasni. Külön méreg volt amúgy, hogy a PicKit2-höz mellékelt karos IC-foglalatos adapter a dsPIC-hez nem jó, sajátot kellett rögtönözni, pákászkodni kellett már a legelején. Mivel az időm nagyon kevés és így értékes, ezért ezt a kevés és értékes időt nem haszontalan kínlódással kívánom eltölteni, hanem hasznos munkával, kódolással, tanulással, fejlesztéssel. És mivel ebben az MSP430 jobb barátnak bizonyult, így most azzal folytatom a munkát. Azonban a dsPIC-et se kell örökre a fiók mélyére temetni, mert ár/érték arányban egy hallatlanul jó eszköz, többszörösen túlteljesíti a hasonló árú vezérlők képességeit! Sokkal jobb A/D konverterrel rendelkezik, ill ellátták még audio minőségű D/A konverterrel is. A 16 bites architektúrán túl rengeteg IIR/FIR/FFT gyorsító hardveres megoldást is tud, mint pl. hardveres 16/32 bites szorzó és osztó művelet, kétcsatornás memóriavezérlő (x-y olvasás, ami egy óraciklus alatt beolvas egy-egy soron következő értéket, amiket aztán szorzó-összegző műveleti egységre küldi, az eredmény pedig 40 bites regiszterben épül fel, és mindezt körkörös (modulo) címzés mellett), valamin van még DMA vezérlőnk a D/A és A/D perifériákhoz, meg még ki tudja mi minden, amit még nem néztem… Egyszóval ezen tényleg élmény lesz majd digitális jelfeldolgozást programozni, amikor sikerül hadrendbe állítani!

Update 2017.01.02

dsPIC33 project fájlok
dsPIC33 project fájlok

A dsPIC-el annyit sikerült elérni, hogy most már forognak a programok.  Az volt a megfejtés, hogy a projekt fájljai közé fel kell venni egy .gld és az include direktívában szereplő .inc fájlt is, mert úgy tűnik, nem tudja a fordító, hogy hol vannak ezek az amúgy beépített dolgok. Ugyanakkor a dsPIC33 továbbra se irható/olvasható, kizárólag a felismerés, és a törlés működik. Lehetséges, hogy tényleg nem jó hozzá a PicKit2-es programozó… Az MSP430 projekt, amibe oly sok bizalmat fektettem, most megakadt. Pedig már működik rajta az LCD meghajtó kód, az ember azt gondolná, hogy nagyobb buktát már esetleg csak az ADC beállítása jelenthet, hát nem! A rendszeróra beállításainál teljesen elvesztetettem az uralmam a chip felett, sehogy nem tudom külső 16MHz (ill alternatívaként egy 12MHz) külső kvarccal működésre bírni. A fellelt információk nagyon szűkszavúak, még az angol nyelvű is. Még Youtube videókat is kerestem, de nem sikerült megoldani a problémát. Egy fórumon azt írta valaki, hogy ez a chip külső kvarc esetében csak kisfrekvencián megy, legfeljebb 50kHz-ig; a készlethez adott 32768Hz-es kristállyal pl. működne. (Ezt azért még ki fogom próbálni!) De ami még ennél is kaotikusabb, az a kalibrált belső RC óra. Megírtam a LED villogtató kód késleltetőjét úgy, hogy a LED 1s ütemben villogjon, ha az órajel 16MHz. A kalibrált 16MHz-re állítva 4s ideig fényes a LED, 4s sötét. Ebből 2MHz órajel következik… Még bizarrabb, ha 1MHz-re állítom, ekkor a LED felveszi a kb 1s ütemet (0.5s fényes, 0.5s sötét), de nem pontosan, kb 10 villanás után már nem azonos fázisban villog egy óra másodperc-mutatójával. Már az is abszurd, hogy a kisebb frekvencián lett gyorsabb a CPU! (*ez a rejtély megoldva, ld lejjebb) Van azonban új fejlemény is! A vásárolt csomagban nem csak a fenti néhány dolog szerepelt, mindig szoktam egyéb anyagokat is venni. Így végülis belekerült a kosárba két PIC mikróvezérlő is, egy PIC16F690-I/P és egy PIC18F14K22-I/P. Utóbbi chipnek kicsit utánanéztem az ADC képességeinek, és úgy fest, alkalmas a terhelésanalizátoros feladatra, 66.7kSps maximális sebességet tud 10 bites felbontásban papíron, hivatalosan, overclocking nélkül! Az ATmega hivatalosan csak 15kSps, és erős overclock kell, hogy 48kHz-en menjen, ami nagyon nem tesz jót a mintavételezés pontosságának, precizitásának. Egy szó mint száz, most ezt a chip-et bűvölöm a régi MPLAB (tehát nem az X-es) fejlesztő-környezetben, és a LED villogtatás, valamint külső kvarcos oszcillátorbeállítás már meg is van. Mondjuk elég morbid egy Assembly nyelvezete van ezeknek a régebbi PIC-eknek, minden általam eddig látott nyelvjárástól idegen, mi több, szinte már vadidegen! A chip regiszter felépítése se semmi, átlapozandó memórialapok (BANK-olás), egy és csakis egy W nevű regiszter, a verem csak visszatérési címeket kezel, ha mi is akarunk adatokat vermelni, akkor szoftveresen kell adatvermet csinálni, vagy egy a LED villogtatáskor tapasztalt érdekesség, hogy a fordító nem tudja kezelni a számrendszereket, mindent hexadecimálisnak vesz! Látszatra elfogad egy pl 0b11111111 formájú bináris alakot, vagy egy külön jelölések nélküli decimálisnak szánt számértéket, de ezeket minden esetben hexadecimálisnak értelmezi. (update: erre közben fény derült, B’11111111′ alakban lehet megadni!) Nem is csoda, hogy kezdetben nem az a láb kezdett villogni, amit én beállítottam bináris számmal… Sajnos nem egy élmény ezen a platformon assemblyben programozni, de azért vállalkozom a dologra, ha minden jól megy, akkor szépen átmigrálom rá a HF terhelésanalizátor kódját. De mivel ezt a cuccot szokni kell keményen, így sajnos nem egyik napról a másikra…

Update 2017.10.19 – MSP430 kalibrált órajel parajelenség megoldva!

Hát, bizony tanulságos, hogy ennél a kontrollernél mennyire kell vigyázni a címzésmódokkal. Nekem alapjábavéve tetszik, hogy szinte már kényesen meg kell adni a címzésmódokat (közvetlen, abszolút, indirekt, indexelt stb) mert így sokkal következetesebb, hogy honnan jön az adat és milyen módon. A kalibrált órajelek megadásánál pedig egy ilyen félreértelmezés okozott problémát. Az ember első felindulásból azt hinné, hogy a kalibrált értékek közvetlen értékek formájában kerülnek be a kódba. Persze belegondolva ez marhaság, mert pont azért kalibrált, mert minden eszköznél kicsit más, az adat nem a közvetlen operandus, hanem egy regiszterbe van gyárilag beégetve. Így hát nem a #-jellel kell megadni a címzését, hanem az abszolút címzésnek megfelelő &-jellel hivatkozunk arra a regisztercímre, ahonnan vesszük. Előbbi esetben ügyebár az az adat, ami a #-jel után szerepel, operandusból kerül át regiszterbe, abszolút címzésnél pedig lényegében egy memóriacímet adunk meg, mely az adatot tartalmazza, azaz regiszterből másolunk egy másik regiszterbe. Nézzük tehát, hogy sikerült ezt nekem szépen benézni! Az Assembly kódban a 16 MHz-es kalibrált értéket így írtam be:

mov.b   #CALDCO_16MHZ,&DCOCTL
mov.b   #CALBC1_16MHZ,&BCSCTL1

Ebből a fordító ezt a gépi kódot generálta:

40F2 10F8 0056
40F2 10F9 0057

Kipróbáltam a LED villogtatást C-ben, ahol jól működött. C-ben az órabeállítás így fest:

DCOCTL = CALDCO_16MHZ
DCOCTL = CALDCO_16MHZ

Ebből pedig ezt a gépi kódot állította elő a fordító:

42D2 10F8 0056
42D2 10F9 0057

Látjuk, hogy a kettő nem egyezik. Az operandusok amúgy rendben vannak, de az utasításkód eltérőek. Próbaképp bevittem az Assembly forráskódjába a C-ben generálódott kódokat .word direktíva segítségével:

.word 42D2 10F8 0056
.word 42D2 10F9 0057

És lőn, működik a mutatvány! A két gépi kód között a különbséget a címzésmód okozta. Ha így viszem be az Assembly kódba a két sort, akkor már tökéletesen működik: (pirossal kiemeltem a lényeget)

mov.b   &CALDCO_16MHZ,&DCOCTL
mov.b   &CALBC1_16MHZ,&BCSCTL1

Na akkor egy probléma kipipálva. 🙂

Update 2017.10.22 – MSP430 téglásodás megelőzése

Egy apró tapasztalat, tanács lenne csak az MPS430-al kapcsolatban. Többször jártam úgy a napokban, hogy egy hibás kód miatt (nevezetesen elrontott veremhívás miatt) összeomlott a kód futása. A probléma csak az volt, hogy ilyenkor a chip programozása is meghiúsult. Ilyenkor LaunchPad Reset gombját nyomkodva, közben a fejlesztőszoftveren az írás újbóli kísérletét végző gombot is nyomkodva egy idő után végül sikerül a javított program beégetése. Mindenesetre sajnálatos tapasztalat, hogy ilyenkor hajlamos az eszköz betéglásodni, azonban a jelenség kivédhető! Amíg a kód rendellenesség nélkül fut, addig a programozó meg tudja szakítani azt, és programozás módba tudja vezérelni a mikróvezérlőt. Megoldás: tegyünk a kód elejére egy 2-4s időtartamú indítási késleltetőt. Ha hibás a kód és ezért betéglásodna az eszköz, akkor is, a Reset utáni 2-4s időben még működik, és képes fogadni a programozó akaratát. Természetesen, ha már un. Release állapotba került a programunk, akkor eltávolítható belőle ez a késleltető kódrészlet:

; -----------------------------------------------------------
;  Indítási késleltetés (kifagyásvédelem)
; -----------------------------------------------------------

	mov.w	#163,r8 ; =5.0863*cpuclk[MHz]*delay[s]
	dec.w	r7
	jnz	$-2
	dec.w	r8
	jnz	$-6

 

Vélemény, hozzászólás?