Ahhoz, hogy a lehető legnagyobb felbontást érd el, a timernek a lehető leggyorsabban kell számolnia, tehát az előosztásnak 1-nek kell lennie, az órajel meg adott. Ez azt jelenti, hogy 3MHz esetén a TAR inkrementálása kb. 1/3 us-onként történik. Ekkor "continous mode"-ban 2^16 lépésben jut el a TAR 0-tól 2^16-ig, és az órajel következő felfutó élére túlcsordul, tehát 1/3*(2^16+1) us lesz a timer periódusideje, ami nagyjából 21,85 ms. Ez majd' 2000x nagyobb mint a ciklusod lefutási ideje, tehát biztos nem fog túlcsordulni.
Ha "up mode"-ban akarsz számolni, akkor a TxCCRx-t úgy kell beállítanod, hogy a túlcsordulás periódusideje kicsit nagyobb legyen mint a ciklus futásideje. Utóbbi kb. 13 us, tehát legyen a timeré mondjuk 16 us, ekkor TxCCRx = 16*3-1 = 47.
De ennek nem látom különösebb értelmét, pontosabb nem lesz a mérés, a timer nullázása, olvasása ugyanúgy megoldandó feladat marad, és egy esetleg beeső megszakítás mérése nehezebb.

Szerintem nem kell egyet hozzáadni, mert 2^16-1 a legnagyobb beírható szám, tehát 2^16-ra már túlcsordul.

Nagyon szépen köszönöm. Sikerült kizökkentened a hülyeségemből.
Amúgy már írni sem tudok rendesen, mert a mért ciklusidőt is elírtam. Nem ~75kHz, hanem ~75Hz ami kb 13ms, de ez még mindíg belefér.
A lényeg, hogy amikor elkezdtem számolni, valami oknál fogva, én csak 8 bittel számoltam, de hogy miért, azt nem tudom.
A nullázást megoldom a programban, pl. így:

Hálás köszönet!

Igen, igazad van. Érdekes, éreztem, hogy valami nem kerek, de végig csak arra tudtam gondolni, hogy a legnagyobb szám után még kell egy órajel a túlcsorduláshoz. Arról pedig valahogy megfeledkeztem, hogy eleve nem tudok 2^16-t 16 biten tárolni. Magyarázom a bizonyítványom.

Ebben a nagy melegben nem csoda, ha a gondolkodás is megtántorodik...

Egy kis kiegészítés az LP-hez: 6 csatornás logikai analizátor, ha jól látom még fejlesztés alatt áll, de biztos nagy siker lesz.

Erről Mit gondoltok? Processing alapú Launchpad programozó. Egyenlőre 1.0 és 3 típusú uC-t támogat de működik. Nekem máris lenne egy kérdésem annak aki kipróbálja: A beállított 1S delay miért csak a fele körül van? Nem jó az órajel? Köszi.

Itt meg itt írtam erről. Új launchpaddal próbáltam, akkor automatikusan a 16 MHz-es DCO-ra állt be. Ha megadtam neki, hogy F_CPU = 1000000, akkor pedig az 1 MHz-re (de valamiért elkezdett nem működni a RESET gomb).

Azt a fenti beírásban már írtam, hogy INPUT helyett INPUT_PULLUP pin módot kell beállítani az új kártya SW2 gombjára.

Nekem a legfőbb gondom az volt, hogy az ADC-vel mért értékek ugrálnak, akkor is, ha az ADC beállítást egy-az-egyben a saját C parogramomból tettem. Majd ha időmilliomos leszek, akkor esetleg nekiállok turkálni a keretrendszer fájljaiban.

Amúgy pofásan megcsinálták, de azt ne feledjük, hogy ebben sem szimulátor sem debug lehetőség nincs.

Azoknak való akik arduinohoz vannak szokva. A programot még bőven fejlesztik és a legtöbb hibáról már tudnak is úgyhogy hátha ezt is megoldják. Nekem a régebbi kártyával nem volt gond a nyomógombbal.

Nem probáltam még, de tervbe van véve.

Ha negatív számból szeretnék pozitívot csinálni, a típuskényszerítés jó megoldás? Vagy van egyszerűbb megoldás?
Példa:

Nem jó, mert csak az értelmezést változtatja meg, s a kis negatív számból így nagy pozitív számot csinál.
Mi legyen a negatív értékekkel? Nullának veszed, vagy az abszolútértéke legyen az eredmény? Akármelyiket választod, elágazás nélkül (if) nem tudok megoldást. (Meg kell nézni a legfelső bitet, melynek 1 állapota negatív számot jelez).

A konkrét problémám, hőmérőnél az lcd-re való kiírás, de csak a negatív értékkel van bajom.
Hőszenzor: TMP36, 500mV=0Cfok, 100mV=-40Cfok, 1,75V=125Cfok.
Most így oldottam meg a mérést:

és így a kiírást:

Nokia lcd-re íratom ki.

Nem szép dolog, hogy az átlagolást nem kettő hatványa szerint csinálod! (16 vagy 32 minta esetén az osztás jobbra léptetéssel megoldható).

A negatív számokat én a kiíratásnál ellenőrzöm, az if(data<0) { sign='-'; data = -data;} sorban.

Unsigned változó esetén így kellene: if((a=b)>32767) a= 65536-a; (Itt a az unsigned16 b pedig az előjeles változó)




A te kódrészleted számomra értelmezhetetlen, mert a változó típusokat nem adtad meg benne.

Tudom. Ez még csak egy "gyosan összehá...t" program. Majd még pontosítok rajta.
Valóban lemaradtak a változótípusok, bocsi.
Íme:

Még ezen is finomítani kell.

Szerintem ennyi kell:


De lehet, hogy jobban jársz, ha hozzám hasonlóan a kiíratásba teszed.

A neg_fok változód fölöslegesnek látszik lenni.

Köszönöm a segítséget.
Megnézem mind a kettőt.

Volt egy kis időm, és megnéztem mind a két programrészletet. Lehet, hogy ezt egy az egyben felhasználom, a szoftveres UART-al együtt, ha nem gond.
Ennél "fok = -fok" viszont nem értek egy utasítást. illetve az asm megfelelőjénél:


Más:
A LPM4 módnál, minden modult (ADC10, TIMER, stb...) ki kell kapcsolni, hogy 1mA alatt legyen a fogyasztás?

Ha működik, akkor nem gond.

A szoftveres UART-tal sok gondom volt Win7 alatt (lehet, hogy a Bluetooth szoftvere is bekavar), s most úgy tűnik, hogy a 9600 Baud sebességet valamivel jobban szereti, mint a 2400-at. Megjegyzem ez a Launchpad USB-UART átalakítójának a sara, mert ha a mikrovezérlőt egy másik konverterhez (CP2102) kötöttem, akkor sohasem volt gondom. a gond itt azt jelenti, hogy bekapcsoláskor min. 2-5-ször, néha többször is újra kellett csatlakoztatni, hogy menjen a kapcsolat, és a Windows is a megadott adatsebességre szíveskedjen beállítani a virtuális soros portot.

Az időzítésen is hangoltam egy kicsit (megnyújtottam a bitidőt), de csak érzésre, mert műzseres mérést nem végeztem. A csatolt program G2452-höz vagy G2553-hoz való, de az ADC kalibrációs adatok szimbolikus neveit deklarálni kell a fejléc állományban mert kihagyták belőle (legalábbis az általam használt kiadásban). Itt most 9600 bit/s az adatküldési sebesség.

A kérdezett gépi kódok: az inv utasítás komplementál (invertál), az inc pedig eggyel megnövel. Ez a kettes komplemens képzés módja, ez felel meg a fok = -fok utasításnak.

Köszi.
A szoftveres UART-tal, bluetooth-ra (HC-05) szeretném küldeni az adatokat, de még át kell néznem, hogy meg tudom-e valósítani.
Mégegyszer köszi.

Megvan!
Az ADC10 modult, vagy csak egyes részeit ki kell kapcsolni, hogy valóban alacsony fogyasztás legyen a LPM4-es módban.

Csak azért írom le, hogy más ne szenvedjen, és ne egye az ideg egy fél napig!

Miután sikerült "felfognom" félig, Icserny fórumtársunk SW_UART programját, elkezdtem próbálgatni, egy g2252-esel. A terv az lenne, hogy egy HC-05-ös bluetooth modul segítségével, adatokat küldjek a PC-re. Első körben elővettem a HW UART programom, amit a HC-05-höz készítettem g2553-ra, mert abban van HW UART. Összekötözgettem őket, elindítom a progit, és a hypert.-ben szépen megjelenik a szokásos "Hello World" szöveg. Mivel minden rendben ment, kicseréltem a mikrovezérlőt egy g2252-esre, rákötöttem a P1.1-es lábra a HC-05 TX lábát! Azért a TX lábat, mert a hardveres UART-nál a TX-TX és az RX-RX lábakat kell összekötni, és így megy a kommunikáció, amit régebben itt a topikban fel is vetettem, mert furcsa volt, hogy nem keresztbe kell kötni. (HC-05 bt adatlap = 1 PIN = TX, 2 PIN = RX) Tehát vezérlő a helyén, összekötve a bt modullal, jöhet a program. Bemásoltam Icserny programját, kitöröltem belőle ami nekem nem kell, (analóg rész), és jöhetett az első kísérlet. Gondoltam először megnézem az LP-n keresztül, hogy él-e a kapcsolat, ezért a hypert.-ben a launchpad COM portját állítottam be. TX jumper fenn, és az adatok első indításra jöttek, szépen, mintha hardveres UART lenn. Minden rendben, jöhet a bt modul. TX jumper le, drót a P1.1-es lábra, hypert. bt-re állítva. Indítom a progit, és................ semmi. "Se kép, se hang"....... Közben....., eltelt a nap fel..... Hosszas próbálkozás, vezérlőcserélgetés, PC oldali szoftver cserélgetés, és minden létező hiba kizárása után, véletlenül jöttem rá, hogy a bluetooth modul RX lábába kell bedugni a P1.1 azaz a TX lábat.
És ezzel szívtam egész délelőtt. Mert a gyártók nem tudnak kitalálni, egy olyan szabványos jelölést amit mindenki be tud tartani. Felháborító!

Elnézést a regényért, de legalább levezettem a délelőtt felgyülemlett ideget.

Átérzem a problémádat, én is jártam még ígyebbül is. Leértékelt gps modult vettünk, kifutó darab volt már évekkel ezelött is, gyári dokumentáció elég kevés, az is zavaros... Lényeg a lényeg 2 soros port volt rajta, mert tudott volna modemet is kezelni, természetesen fél napi szenvedés után gondoltam rá, hogy lehetséges hogy mégsem az elsődleges porton probál kommunikálni kifele.

Tanulság a te történetedből is, mielött a hardver vagy szoftver hibáját keresnénk a bekötést kell megnézni, ilyenkor az első hogy az RX-TX-et meg kell cserélni vagy ki kell mérni melyik melyik. Egy multiméterrel meg lehet nézni a sorosport leírása alapján, ez egyik mindig magas szinten van.

Hardveres UART-nál a (régi) Launchpad kárty TxD jelzésű kivezetése valójában az RxD bemenet. Nem ez tévesztett meg?

Nemhiszem, mert az (új) Launchpad kártyánál is úgy kell bekötni, hogy Tx-TX, RX-RX. Sőt, még régebben próbáltam a FRAM kártyával (fr5739), és ott is, a P2.0 (TXD) ment a HC-05 TX lábára, a P2.1 (RXD), meg az RX lábra.
Szóval nem értem.
Viszont a lényeg, hogy eme kis hiba leküzdése után, a szoftveres UART programod tökéletesen működik, a bluetooth-al, és a Launchpad-al egyaránt.
Köszönet érte.

Nekem az új Launchpad kártyán nincs jelölveTXD meg RXD kimenet, hanem UART felirat van helyettük. A lényeg: a TXD kimenet szoftveres UART esetén P1.1 lábon, hardveres UART esetén pedig a P1.2 lábon van.

Az RXD bemenet pedig a fordítottja: szoftveres UART esetén a P1.2 láb, hardveres UART esetén pedig a P1.1 láb.

Ebben igazad van. Én a jumpereket néztem, és ott a TXD=P1.1, RXD=P1.2. Bár már abban sem bízok, mert ugye el lehet forgatni HW UART, vagy SW UART állásba.
Én úgy vettem észre, az elektronikai jelölések terén, hogy két szabvány van. Az első, a "nemzetközi", a második a Kínai. (Nem rosszindulatból mondom!)

Így működik az új Launchpad kártya átkötéseinek forgatása

Az új Launchpad kártya dokumentációja (slau318b) szerint:
piros - a mikrovezérlő P1.1 lába (szoftveres UART esetén ez TxD, hardveresnél RXD)
kék - a mikrovezérlő P1.2 lába (szoftveres UART esetén ez RxD, hardveresnél TxD)
zöld - az USB-UART átalakító vevője (RX)
sárga - az USB-UART átalakító adója (TX)

Fentiek alapján érthető, hogy szofveres UART esetén a piros-zöld és kék-sárga átkötések kellenek, mert így TxD - RX, Rxd - TX összekötések lesznek.

Hardveres UART esetén pedig, az elforgatás után piros-sárga és zöld-kék átkötések lesznek, ezek biztosítják az RxD - TX illetve TxD-RX összekötéseket.

Ez így érthető. Köszi.
Mondjuk ami még zavar, az az, hogy miért ragaszkodik mindenki a szoftveres UART-nál a P1.1/P1.2 vagy P1.5 lábakhoz. Én most a szofveres UART-ot a P2.5-ön vezettem ki (az általad írtat, g2452).
De kezdek rájönni, hogy ez az egész programozás egy nagy szívás. Most épp a Processing szívat, annak is az androidos, bluetooth része. Egyszer sikerült kapcsolatot teremteni a HC-05 + g2452-vel (még tegnap), és azóta csak a hibákat szórja, úgy, hogy a programon nem változtattam, csak egy újraindítás volt.
De ez már nem ide való.
Mégegyszer köszi a kimerítő magyarázatot.

Üdv mindenkinek!

MSP430G2211-el kellene megoldanom egy feladatot és felmerült egy olyan probléma hogy lehetséges egyes kimenetek szembekötése egymással. Nah most nézegettem az adatlapot, de ott nem szerepel az hogy most a kimenet Totem Ploe, Open Collector vagy Tri-state.
Valaki tud ebben tanácsot adni, hogy ha szembe kötöm a kimenetet károsodni fog a vezérlő? Előre is kösz!