Értem, köszi a választ. Elég olcsónak tűnik. De lehet, oogy igaz.

Az a hiba, hogy rossz helyre került a forrásállomány, s azt az IAR nem tudja értelmezni.
Az itt leírtakat próbáld meg követni! (természetesen az msp430g2231 helyett az msp430g2553-at válaszd ki, ha az van a kártyán!)

Köszönöm, átnézem.

Csatoltam egy LCD vezérlést, ami működni fog neked is szerintem.

Az icserny által írt kódot módosítottam kicsit, amikor elkezdtem foglalkozni az MSP430 kontrollerrel - ez ilyen formában fordul és működik GCC fordítóval is.

Az összes "láb" a P2 portra van definiálva; az adatbitek P2.4-P2.7, az LCD RS kivezetés P2.0 és E pedig P2.1

Az változtatott részek kommentben vannak...

Hello!
Sajna nem fordul le ez sem. Ezúttal valami CCS beállítás lenne a ludas? lcd.c és .h egyaránt hozzá lett adva.

No áthegesztem itt közben ezt az LCD-s progit, viszont ami kérdésem volna az az, hogy ugye az elején ott, hogy:

például #define LCD_E_DIR P2DIR_bit.P7 helyett #define LCD_E_DIR P1DIR_bit.P7 kellene ha eszerint drótozom össze?

Hülyeséget írtam elnézést. Csak fura volt a P2 elhelyezése kicsit ott fenn.

Ez így nem fordul le. Írnod kellene hozzá egy programot, ami használja az LCD könyvtári függvényeket.

Készül az új forrasztóállomásom PID vezérlés lesz benne. Még a nyáron be akarom fejezni.
Ilyen pákával. Publikus lesz bárki után építheti majd.

Hm... tanulság: kapkodásból születnek a hülye kérdések Meg se néztem a kódot így azt sem, hogy ebben konkrétan nincsen main csak látni akartam működik-e az LCD. Bár az fura volt, hogy sehol egy include az lcd.h-ra. Átírtam közben a Te programodat és fordul rendesen CCS-el is. Egyébként a write rutinban van valami elegáns mód az LCD_RS = cmd; sor kiváltására ahelyett, hogy:
?
Mert az általad használt makró ugye nem megy CCS alatt sajnos a fenti megoldásom meg kicsit "paraszt" szerintem

Egy 16 bites változóból szeretnék két 8 bitest.

A jobbra léptetés eredménye jó mindig kijön , a balra léptetés eredménye mindig 0 nem jön ki bármilyen számot adok meg t -nek. Ezt nem értem. Valaki fel tudna világosítani.

vagy



vagy



Mivel balra léptetéskor balról 8 darab 0 jön be ezért lesz b nulla nálad.

Szerintem ez így nem jó:
a=b=0;

Tévedtem jó az
a=b=0;

b = 0; //0
a = b; //0

Például így:

Nem igazán. S az a legrosszabb, hogy a port vagy portláb megváltoztatása esetén újra kell írni.

Ezen a problémán segíthet talán a következő.

Program elejére:


A kérdéses részen pedig:


Ezután a program első sorainak módosítása is elég - valamivel jobb talán így.

Futás szempontjából olyan mintha a kérdéses sorok módosulnának; fordítás előtt kerülnek behelyettesítésre ezek az adatok.

Sziasztok!
MSP430G2553-at programozok. És van egy programrész, ahol váratlanul reseteli magát a kontroller.
Egy switch case ágban a timer regisztereinek írása után. Valaki tudja, hogy mi okozhat ilyesmit?
Ha kell, leírom a programrészletet is. Azt olvastam, hogy akkor is lehet ilyen, ha a kontroller rossz címről szedi fel az utasítást, de a C fordító nyilván nem fog rossz címre irányítani.
Köszi előre is!

Egy kis plussz információ:
A parancs, amit végrehajtott, az a
TACTL ^= MC0; //timer indul
CCTL1 ^= OUTMOD_7;
regiszterállító parancs volt. De ha
TACTL = TASSEL_1 + MC_1 + TACLR; // timer megy
CCTL1 = OUTMOD_7;
Parancsot használtam, akkor elindult.
Mindkettőnek ugyanaz a hatása, ugyanarra állította volna a regisztert.

A parancsok előtt volt egy nem maszkolható megszakítás, és az beállított egy char változót, aminek a hatására lépett a fenti parancsokba.

Valaki esetleg tudja az okot?

Alapvetően nem értem, miért XOR utasítással szeretnéd beállítani a timered.

Másfelől a TACTL ^= MC_0 miért csinálja ugyanazt mint a TACTL = TASSEL_1 + MC_1 + TACLR ?

Az előbbi utasítás első lefutásra be fogja kapcsolni az MC_0 által meghatározott biteket, második lefutásra pedig ki. Sőt, ha korábban TACTL-nek olyan érték volt megadva, amit MC_0 is használ (mármint az adott biteket), akkor teljesen más eredmény jön ki az egészből.
Bár mivel MC_0 értéke 0x0000, ezért az utasítás gyakorlatilag semmit nem csinál.

Az utóbbi utasítás viszont TACTL minden korábbi beállításától függetlenül állítja be a megadott biteket, no meg a számlálót is törli.

Teljesen más a kettő.

pl.

TASSEL_1 = 0x0100 = 0b0000000100000000
MC_1 = 0x0010 = 0b0000000000010000
TACLR = 0x0004 = 0b0000000000000100

Az első utasítás után eszerint 0x0114 (0b0000000100010100) lesz beállítva.

Ha a második utasítás mondjuk TACTL ^= MC_1, akkor:

Ha az először beállított 0x0114 lenne TACTL kezdeti értéke, az utasítás első lefutása után ez 0x104 lesz, második lefutás után pedig újra 0x114.

Így tehát nem jó.

-------------------------------------------------------------------
Az egyes műveletek, pl. TACTTL |= TACLR; felírhatók hosszabb formában is:
TACTL = TACTL | TACLR; - itt az egyik bemenetem TACTL, a másik pedig TACLR lesz, a kettő viszonyát vizsgálom.

Adott biteket így tudsz beállítani:
TACTL |= TACLR;

...és így tudsz kikapcsolni:
TACTL &= ~MC_1;

Előbbi egy vagy kapcsolat (megengedő vagy), ami kimenete csak akkor lesz 0, ha mindkét bemenet 0 - bármelyik bemenet 1, a kimenet is az lesz (tehát TACTL értékét változatlanul hagyja, viszont minden olyan helyen 1-be billenti, ahol TACLR is egy).

Utóbbi pedig és kapcsolat, ami csak akkor eredményez 1-est, ha mindkét bemenete 1. Ha csak az egyik is 0, a kimenet is 0.
Emiatt a kikapcsolandó biteket 0-ba kell állítani, azokat pedig 1-be, amt nem szeretnénk változtatni. Mivel az MC_1 a törölni kívánt bitek helyén 1 és a változatlanul hagyni szándékozottak esetén 0, azt invertálni kell. Erre szolgál előtte a ~ jelölés.
(A ~ tehát invertál, vagyis MC_1 minden 0 értéke helyett 1, minden 1 helyett 0 lesz.)
Így az és művelet végül azokon a helyeken, ahol eredendően 0 volt, a kimenetre is nullát ad. A többit szimplán "másolja" - csak ott lesz 1, ahol MC_1 eredetije 0 volt és a másik bemenet 1.

A XOR viszont kizáró vagy, ami csak akkor ad 1-et kimenetként, ha a két bemenet eltér.

Bocs a zavaros megfogalmazásért, de ez lenne a dolog lényege.

Tisztában vagyok a programozás alapjaival.
Azt is tudom, hogy miért használtam XOR-t. Azért mert minden esetben az adott biteket akartam megváltoztatni.
És az MC0 értéke nem egyenlő az MC_0 értékével. MC_0 tényleg 0, de az MC0 az az MC0 bit helyén egyes.

Az említett esetben meg azért lett a két művelet eredménye ugyanaz, mert az előzmények olyanok voltak (MC_0 számlálási mód és OUTMOD_0 kimeneti mód, TASSEL_1 órajelforrás), hogy ugyanaz legyen az eredmény a xor hatására, mintha közvetlen állítanám. Talán csak a TACLR lehet más, de az most nem érdekes.

Arra lennék kíváncsi, hogy miért resetelődik a processzor1

Ok, bocs. Az MC0 pedig valóban más.

Bár a XOR használatának okát most sem értem - talán a kódból kiderülne.
Ill. a kérdésedre is ez alapján lehetne tippeket adni véleményem szerint...

Amúgy lehetne akár a watchdog is, bár gondolom, ezt kikapcsoltad vagy kezeled...
Ill. ha valamiért elfogy a RAM, az is okozhat hasonló jelenséget.

Azért használtam xor-t eredetileg, mert amikor lefut az adott kódrész, akkor azt akarom, hogy azokat a biteket változtassa meg, függetlenül attól, hogy hogy álltak. De abban a speciális esetben, amikor az NMI bemeneten megszakítás történik, akkor az adott bitek éppen nullán álltak, ezért a XOR művelet után úgy állnak be, mintha közvetlenül írtam volna.

IAR legújabb verzióját használom, szerintem szólna, ha elfogyna a RAM. Én néztem az adatlapból a lehetséges RESET okokat, de nem következik be egyik sem.
A watchdog timert lekezelem.

Kicseréltem a kontrollert, a másik is ezt csinálta.

Sziasztok.

Lehet, hogy a meleg, vagy a fáradtság teszi, de egy kis számolási zavarba keveredtem....

Egy program ciklus lefutási idejét szeretném mérni, egy Timer segítségével, de nem értem az eredményt:
SMCLK = 3.4MHz
Timer A0 = SMCLK/4, folyamatos számolás 0xffff-ig Timer IFG bebillentése túlcsorduláskor.
( TA0CTL = TASSEL_2 + ID_2 + MC_2 + TACLR; )

A ciklus elején:
loop_time = TA0R;
Ta0R = 0x00;

A ciklus lefutása után, a "loop_time"=8757.
Számításaim szerint, ha jól számoltam, ez kb. 97,065Hz. De...Beraktam a ciklus elejére egy parancsot, hogy billegtessen egy kimenetet, ellenőrzés céljából. (P1OUT ^= BITx)
A kimeneten mért freki viszont csak 48,4-8..Hz, tehát kb. a fele.
Miért van ez? Vagy mit nem értek?

Ez azért van, - ha belegondolsz - minden esetben mikor az utasítás végrehajtódik akkor a kimeneted szintet vált. Vagyis a frekvenciamérést alapul véve egy periódushoz két jelváltás szükséges. Tehát egy tökéletes frekvencia felezőként funkcionál most a kimenet.


Kitöltés garantált 50% !!!
Remélem tudtam valamit segíteni ebben a gatya rohasztó hidegben.......

Ba.....Tényleg.
Hálás köszönet.
Akkor a valós, Timer által adott adatokkal számolok...

Hosszas vajúdás után (kb. 5 hónapja kezdtem hozzá) megszületett az Energia IDE-t bemutató cikkem. Használjátok egészséggel! Sajnos ebbe a terjedelembe (kb. 70 A4-es oldal) sem fért bele egy részletes referencia, ezért a gyári függvények leírását az Arduino dokumentációjából kell hozzáolvasni.

Nagyon jó, kitűnő cikk!
Köszönjük szépen.

Egy kis észrevétel, illetve tapasztalat.
Ha valaki jó szervó motor vezérlést akar, ne használja az Energia program servo függvényeit. Inkább írjon egy jobbat....
Tapasztalatok: A minőségi (Futaba) szervók folyamatosan rángatnak, nem állnak meg az Energia függvénnyel.
Egy RC brushless motor vezérlőhöz meg egyáltalán nem alkalmas, pedig az is "servo" jeleket igényel.

Gratula, jó cikk és ugymond vonzza a kezdöket mert inspiráló.

Ha jobbat tudsz írni, akkor a "gyárit" is ki tudod javítani. Azonban valószínű, hogy nem a függvénnyel, hanem az elvvel van probléma: a hardveres interrupt kiszolgálásban szoftveresen matatott kimenettel nem lehet pontos időzítést elérni. Ha például egy megszakítás kiszolgálása folyik, amikor a timer túlcsordul, akkor addig nem érvényesülhet a megszakítás, amíg az előző kiszolgálása be nem fejeződik. Ez okozhat egy kis csúszkálást (jitter) az időzítésben, ami "reszketeggé" teheti a szervót.

A tisztán hardveres időzítés jobb volna, de abból nem sok kimenet áll rendelkezésre.

Nekem az ADC-vel van gondom (korábban valamikor említettem már), de hiába cserélem le a függvényt a sajátomra, akkor is ugrándozik a kiolvasott érték. Ennek még nem találtam meg az okát.

Már megtettem, de sajnos az 555-ös szervó vezérlésnél nincs jobb.
Arra, hogy pontosan mi a hiba, a mikrovezérlős szervó vezérléssel, még nem jöttem rá teljesen, de addig már eljutottam, hogy az időzítések pontossága egyáltalán nem számít.
Több "gyári" RC vevőből kijövő szervó jelét mértem. A periódus 17-25mS között változott, a minimum pulzus 0,7-1,1mS, a max pulzus 1,7-2,1mS. A jel pedig olyan "tüskés", hogy nem hittem a szememnek...
Ha lesz egy kis időm, csinálok pár szkóp képet.

Az ADC függvénnyel még nem foglalkoztam.
Most egy kicsit hanyagolnom kellett az elektronikát egy tanfolyam miatt, de holnap lesz a záróvizsgám, és utána lesz időm "visszazökkenni" a régi kerékvágásba...