Az ADC csatornák sorozatának konverziójára van konfigurálva, trigger után 2, 1, 0 csatorna sorrendben hajtja végre a konverziót, majd várakozik újabb triggerre.
Az MSC bit bebillentésével azt éred el, hogy amint befejezte az egyik csatorna konverzióját rögtön a következőre lép.
A konverziót az ADC10SC bit felfutó élére kezdi (a bit automatikusan törlődik). Tehát pl. a ADC10CTL0 |= ADC10SC; kifejezéssel.
A használható irodalom a FUG, szépen le van írva állapotgráfokkal együtt az ADC működése.
A kód elkezdi inicializálni a DTC-t is, természetesen annak is le van írva a működése.

Ha az MSC bit nulla, akkor minden konverziót külön el kell indítani. Ha MSC = 1, mint a példádban, akkor pedig csak egy triggerjel kell, arra lefut a teljes szekvencia, amit beállítottál.

A mikrovezérlő gyári mintaprogramjai között számos (kimerítő mennyiségű) mintapéldát találsz az ADC kezelésére.

Ha nem használod a DTC-t (ami tulajdonképpen az ADC DMA csatornája), akkor minden konverzió eredményét külön ki kell olvasni (a gyári példákban levő ADC10SA = 0x200; sorban a fix cím helyett a tömb kezdőcímét add meg!). Ha a DTC opciót használod, akkor közvetlenül belepakoltathatod egy tömbváltozóba az adatokat, úgy talán egyszerűbb lesz az adatfeldolgozás (átlagszámítás, miegyéb).

Az MSP430G2553 hardveres UART full duplex használatához portoltam a PICula projektemben kidolgozott szoftveres bufferelésű (gyűrű táras) és interruptos kezelésű uart_putc(), uart_getc() függvényeket.

Használata: A projektekbe fel kell venni a hw_uart_buf.c állományt, s a fenti függvényket használó fordítási egységekbe (pl. főprogram) be kell csatolni hw_uart_buf.h fejléc állományt.

Egy kis bónusz: IAR EW esetén ha felüldefiniáljuk a putchar() függvényt, akkor a printf() függvény is használható a kiírásra. Ugye, milyen egyszerű? Mintapélda:



Ha a printf() függvényt nem akarjuk használni, akkor a kiíratást a hw_uart_buf.c állományban definiált (itt már többször bemutatott) függvények segitségével is végezhetjük. Például így:


Megjegyzések:
1. Sajnos, a fórummotor nem engedi berakni a newline karaktereket, ezért NL-lel helyettesítettem!
2. Az IAR EW projekt opcióknál célszerű a printf függvény használatát "Auto"-ra állítani, hogy fölösleges formátumok kezelésével ne tömje tele a programunkat.

Sziasztok! Köszi mindkettőtöknek a segítséget. Valami még mindig nem tiszta. Átnéztem a FUG-ot meg a mintaprogramokat, de sehol sem találtam meg ami nekem kéne, és amiről icserny is írt.
Tudnátok egy programrészletet mutatni, hogy állítsam be a DTC-t úgy, hogy az ADC10MEM egy 2 elemű tömb legyen és azt a későbbiekben hogyan tudom kiolvasni egy x és y változóba? Köszönöm!

Ezt a programrészletet a kazánvezérlőmből szedtem ki.

64 konverziót csinál, és az értékeket az "adc_temp" nevű tömbbe menti.
Remélem ez segít.

Köszönöm, sokat segített!!

Ennyire ne spórolj a memóriával, mert ez csak 63 tömbelemet definiál! (Magyarázat: Nem a maximális indexet, hanem a tömbelemek darabszámát kell megadni!)

Nem spórolok, pedig már lassan kéne. Az eredeti programban, nincs meghatározva a tömb mérete. Most csak valamiért beírtam. De hogy miért......?

Az eredeti programban, nincs meghatározva a tömb mérete.
Pedig nagyon célszerű beírni:

Különben honnan tudja a fordító, hogy mekkora memóriát foglaljon? A 63-mal az a baj, hogy az ADC "túlír" rajta, s beleír egy másik változódba.

Ááá, akkor ezért nem működik normálisan a program. Mostanában, egyre több "alapvető" hibát nem veszek észre, és követek el.
Köszönöm a javítást!

Jól pofára ejtett engem az ADC "ismételt konverzió" módja! A korábbi szingli méréseknél a konverzió után egyszerűen pollinggal vártam a ADC BUSY jelzőbitjének megszűnését. Az "ismételt konverzió" módban azonban nem szűnik meg a foglaltság (pedig direkt nem folytonos módot konfiguráltam!). Sok kínlódás után végül a megszakításkérő jelzőbit figyelésére tértem át, azzal működik a dolog.


A teljes mintapéldát lásd a github lerakatomban! (4_cikk/4_ADC_multi_ref1)

Cikk is lesz belőle? Vagy még mindig nem működik rendesen a cikk szerkesztés?

Az IAR 5.51 mennyivel jobb, tud többet, mint az elődei? És milyen korlátozás van benne?

Az idén nem lesz.
Legfőbb előnye, hogy ez letölthető, az elődei meg már nem... Más különbség nem tűnt fel.Ez most egy próbaverzió (de már nem sok ideje van hátra), mert az egyik projektem már túllépte a memóriakorlátot.

Azt elfelejtettem mondani, hogy szeptembertől belecsöppentem a felsőoktatásba, s ha cikk nem is várható egyhamar, a Mikrokontrollerek programozása c. tantárgyi honlapomon az MSP430 tananyag menüpontban elérhetők a hétről-hétre szaporodó előadásvázlatok. A közérdeklődésre számot tartó példaprogramok pedig a https://github.com/icserny címen találhatók.

Számomra, mint kezdő amatőr hobbista, az oldalad maga a kánaán.
Gratulálok hozzá!

Sziasztok.

IAR-ban, nem értem ezt a hibát:

Létrehozok/nák egy tömböt, ("uint16_t tömb[256];") és ebbe szeretném bemásolni az I2C-n érkező adatokat, USCIAB0TX magszakításban:
ISR: .... tömb[256 - rx_count] = UCB0RXBUF; ....
Miért " túl nagy a segmens definíció"? Ha kiveszem megszakításból a beolvasást, nem szól egy szót sem.

Ez 512 bájt, lefoglalja a teljes RAM-ot.
A megszakításnak is van helyigénye a RAM-ban, mert el kell mentenie a megszakított program állapotát. De már nincs hová....

Köszönöm szépen.

Így már világos, hogy a "char tömb[210]" miért engedi még meg.
Akkor már csak azt kell kitaláljam, hogy hogyan írjam ki az I2C-n érkező adatokat UART-ra, megszakításban. Legfeljebb majd a PC-re marad a feldolgozás.

Sziasztok!

Az MSP4302452 három különböző I/O portjára közvetlenül rá köthetek három ilyen ledet: led. ?

Köszi!

Közvetlenül sohasem, csak áramkorlátozó ellenálláson keresztül. S az áramot a mikrovezérlőhöz kell szabni, az a korlátozó tényező.

A 3x20 mA határesetnek tűnik, a kimeneti feszültség ilyenkor már leesik (ez akkor érdekes, ha a mikrovezérlő más kimeneteit közben logikai kimenetnek használod). Az adatlap szerint ugyanis az összes portlábon kivett áram nem lehet több 48 mA-nél, ha el akarod kerülni a 10 %-osnál nagyobb feszültségesést ( 3V-on -0.3V).

Szóval az alkalmazástól is függ, hogy mit engedhetsz meg. Ha zseblámpa lesz, akkor nem látom akadályát. Ha kényesebb az alkalmazás (ahol a LED csak jelzőfény), akkor viszont nem kellene teljesen (20 mA) kihajtani LED-eket.

Köszi!

A mikrovezérlőt fényerő szabályozásra használnám, a programot a PWM ről szóló cikk 8_2. alapján raktam össze. Timer_A-t be tudom állítani két kimenetre, de három lábra sehogy nem jön össze.
Ha van tippetek, szívesen várom!

A cikkben szereplő MSP430G2231-gyel szemben az MSP430G2553 mikrovezérlő két darab Timer_A3 modult tartalmaz. A második modul (Timer1_A3) mindhárom Compare csatornája kivezethető a Port2 lábakon. A pwm_cont példa alapján lehet elindulni, s összehozható három hardveresen vezérelt PWM.

Sziasztok.Az lenne a kérdésem hogy az msp430 g2231-Ic-vel lehetne-e 2X16LCD-re óra perc másodperc kijelzéssel egybekötve?A felső sorba pedig valamilyen dátumhoz valami emlékeztető szöveget kiiratni vele.Ha ez megoldható.A válaszokat előre is köszönöm.

Sziasztok.

Egy számomra érthetetlen problémába ütköztem, és nem találom rá a megoldást.
A kazánvezérlő programom tesztelése során, észrevettem egy hibát, melyet az eeprom (24lc512) írásánál csinál a program, és nem tudok rájönni, hogy miért nem csinálja az amit mondok neki. Röviden a lényeg: Az eepromban tárolok két hőértéket (k_fok, v_fok), 2x2 bájtban, melyek ~12 percenkét kerülnek mentésre. Az eeprom minden második oldalának első bájtjaiba az idő/dátum kerül beírásra (prg. részlet). A gondom a második változó (v_fok) beírásánál van, ugyanis azt valamiért nem akarja végrehajtani a program, és nem tudok rájönni, hogy miért. Azért nem értem a dolgot, mert a "v_fok" változón kívül minden adatot szépen elment az eepromba, időt, dátumot, k_fok-ot.
Bár a program részletből szerintem nem derül ki semmi, de azért berakom:

És két analizátor kép:

Szia!
Kíváncsiságból felcserélném a 16. és 19. sort. Vajon akkor a k_fok nem kerül kiírásra?!

Ezt még nem próbáltam. Azért furcsa a jelenség, mert mindkét sor, változó, egyforma. A k_fok és a v_fok is int típusú. Elsőnek azt hittem, hogy az eepromba nem tudok egymás után ennyi adatot bevinni, de erre nincs utalás az adatlapban, és ha csak a két hőértéket írom/nám be, tehát az idő/dátum kimarad, akkor se írja be a másodikat, csak elkezd valamit csinálni az i2c vonalon (v_fok kép).

És ha a 19. sor után is berakod a 20ms delayt? (bár lehet hülyeség, mert nem tudom mi történik a 20. sortól.)

Köszi. De...inkább leírom.

A k_fok kép = 16. sor, a v_fok kép = 19. sor. Közte látszik a 20ms késleltetés, (a kép jobb oldalán, [T1-T2] = 20.26....ms). Tehát, kiküldi az eepromnak a k_fok adatot, vár 20ms-ot, és elkezdi kiküldeni a v_fok adatot, csak azt nem fejezi be, (hozzáteszem, hogy a program nem áll le, ugyan úgy fut tovább, és ha eltelt a 12 perc, ismét beírja a k_fokot, és a v_fokot nem.). Ez látható a két analizátor képen, csak ha egy képen lenne, akkor nem lehetne értelmezni, ezért van kettőn.
Ebből adódik, hogy a 19. sor után már értelmetlen a késleltetés, mivel a 19. sorral van baj. Egyébként, a 19. sor után visszatér a program, a főciklusba, ahol engedélyezi az előzőleg letiltott port2 megszakítást, töröl egy-két változót, stb...

Az I2C buszon van olyan eszköz vagy kimenetnek konfigurált láb ami hardver ütközést okozhat? (Le- vagy felhúzás, amikor nem kellene?) Más okot nem tudok, ami miatt elakadna (v_fok esetében) az első bájt kiküldése.

Van más eszköz, de nem okoz ütközést. Legalábbis azt hiszem. Az SDA-n van egy LCD (SPI), és az i2c-n van még egy RTC. De ha az eeprom művelet megy természetesen minden tiltva van, máskülönben az első adatot sem írná ki az eepromba. Ezenkívül az eeprom törlésével, laponként, és az olvasásával sincs semmi baj. A törlést úgy csinálom, hogy laponként feltöltöm 0xff-el. Szó nélkül megcsinálja. (Már PicKit2 -vel is ellenőriztem, hátha az olvasás a rossz, de nem, minden második 2 bájt 0xff.)