Volna egy kis gondom a g2552 soros kommunikációjával. Meg van a hardveres deffiniálásra az echo program. Azt felhasználva írtam meg a saját programomra a soros kommot. Az lenne a kérdés lényege, a kérdésemnek, hogy ha valamit betöltök a TX bufferbe azt minden egyéb instrukció nélkül elküldi a cuccos? Vagy van valami trükkje. Mert valamelyik fórum kolléga adott egy programot ami 1 byteot küld el. De a pc oldalon nem jelenik meg. Holott a debug nézertnél a TX bufferbe beíródik a szám.

LFXT1 ről akarom szedni a cuccot ACLK hoz g2553-on de nem eszi meg a beállításokat pedig az adatlapjáról szedtem. " XTS = 0, XCAPx = 0, LFXT1Sx = 3" van írva az adatlapjára de rinyál a fordító. Ezzel a beállítással elvileg megenne 32kHz esnél nagyobb kristályt is.

Sziasztok.
Egy újabb kérdés pergésmentesítés ügyben.
Az alábbi kis programot, egy mechanikus encoder (kép) jeleinek a feldolgozására írtam:

A kérdésem az lenne, hogy kell-e pergésmentesíteni az encodert, és hogy hogyan?
A program működik, ha lassan forgatom az encodert, de ha gyorsan, akkor össze-vissza számol.
Próbaképp ledeket akartam vezérelni vele, de a fent leírt hibába fulladt a dolog.

Sziasztok!

Ismét lett egy kis szabadidőm így azonnal visszatértem a mikrkontroller ismerkedéséhez oda ahol abbahagytam. Icserny cikkjében a két független pwm csatornával foglalkozó cikkrészlet volt már csak hátra, így azzal kezdtem. Sajnos viszont elakadtam mivel nem értek pár sort a programban miért kell ezt nekünk csinálni vagy miért éppen ezt teszi a program.
Az addig világos, hogy szabadon fut a számlaló (TAR ami lévén hogy 16 bites 65535nél csordul túl). Azt is értem, hogy a compare toggle módjával azt szeretnénk elérni, hogy a TACCR0 beírt értékkor ne csak a kimeneti jel állapota változzon meg, hanem egy magszakításban a TACCR0-hoz való érték hozzáadásával elérjük, hogy a következő átbillenés (kimenet jelének megváltozása) ne a számláló egység túlcsordulása után következzen be hanem hamarabb. Így manipulálva a toggle üzemmódot egyedi pwm frekvenciát tudunk előállítani.
A problémám csak azzal van, hogy a megszakításban mi csak értékeket adunk hozzá a TACCR0 regiszterhez és ez egy idő után meg fogja haladni a számláló álltal maximálisan elérhető értéket (65535) vagyis egy idő után nem fog megszakítás generálódni, sőt a kimenet sem fog változni, mert a számláló nem fog ilyen értéket elérni.
Nem tudom, mennyire értelmezem jól/rosszul a program sorait, sajnos a cikk ezen írott sorai még jobban megkavarnak. Egy kis segítséget kaphatnék, hogy hol értelmezen rosszul a sorokat vagy mi az a hiányzó elem ami miatt nem értem?

Az igaz, hogy mindig csak hozzáadunk, de a TACCR0 és TACCR1 regiszterek éppúgy 16 bitesek, és 65535 után tűlcsordulnak, mint a TAR regiszter. Tehát az összeadás után a nagy számból egyszer újra kis érték lesz... Az összeadások végeredménye mindig a 0 - 65535 közötti tartományban mozog.

Csak egy PIC24 példát tudok mutatni. Abban egy Timer-rel keltett periodikus megszakításban olvasom ki az encoder állapotát (mintavételezés). Tapasztalati alapon egy bizonyos encoder esetében 5 ms-ra kellett állítani a mintavételezés gyakoriságát, hogy ne legyen adatvesztés ha gyorsabban forgatom, de maradjon pergésmentesítés is.

Mivel a WDT-t úgysem használod, esetleg azzal is lehet periodikus megszakításokat kelteni, ha beállítható vele a kívánt gyakoriság.

Igazából az nem zavarna, hogy egy-két lépést kihagy, mert jelen esetben nem a pontosság a fontos. Egy érték beállítónak szánom, ami LCD-n jelenik meg. Ami zavar, az az, hogyha gyorsan forgatom, nem számol. (Még régebben csináltam egy hasonló programot PIC16-al, de ott fontos volt a pontosság. Az szépen működik, és mindegy neki, hogy milyen gyorsan forog a tárcsa.)
Olyan, mintha nem tudná a vezérlő felfogni a beérkező jeleket.

Még csak a "Kiterjesztett pontosságú műveletek" c. részig jutottam el a PIC-kwik-ben. Igaz a PICCOLO-t és a PICula-t kihagytam, mert a PIC18 valahogy nem tud lekötni.

Ó hát persze, így már tiszta sor. Köszönöm.

Ilyen problémám már nekem is volt. Egy fordulatszámlálót csináltam a g2211-ből fototranzisztor és infraled segítségével. Először azt hittem nem reagál elég gyorsan a tranyó a váltásokra, de végül a magas alacsony szint érzékelésével volt a baj. Nem tudott kölünbséget tenni köztük mikor nagy volt a fordulatszám és egyszerűen nem számolt. Szórakoztam kicsit a a led meghajtásával, illetve a feszültségosztóval és összejött.
Esetleg ha szükséged van rá megtudom osztani a programkódot én is lcd-re írattam ki.

Nálam lehet, hogy a rotary encoder-rel van a baj. Néztem szkópon, és össze vissza jelet ad ki, ha gyorsan tekerem. Nem a megszokott A B négyszögjel jön ki belőle, hanem menet közben mindenféle tüskéket rak bele, és a vezérlő ezt is érzékeli, és ezért bolondul meg.
Ha nem titkos, megoszthatod a kódot. Szerintem szívesen látja mindenki.

Igazából ez eléggé félkész projekt még (vagy inkább csak negyedkész). Icserny cikkjéből lett összeollózva és hülyére kommenteztem, mert akkor kezdett összekavarodni az egész a fejemben. Ha kész leszek vele teljesen, közzéteszem. Az elv amúgy az, ami itt pár sorral lejjebb elhangzott, hogy wdt megszakítás során történik az aktuális fordulatszám kalkulációja.

Úgy néz ki, hogy megoldódott az encoder problémám.
Kísérleteim során, egy furcsa dologra lettem figyelmes. Szkóppal figyeltem az encoder álltal kiadott jeleket, és ilyenkor teljesen normálisan működött, nemhagyott ki, nem ugrált össze-vissza, stb... Ha viszont levettem a szkópot megbolondult. Ezután beraktam egy RC tagot (1k,100nF) az encorder elsődlegesen figyelt lábára, (jelen esetben P2.3) és jelentőssen javult a helyzet, de még mindíd nem volt az igazi. Újra szkóp, jel figyelése. Azért nem volt az igazi, mert a 100nf kondi nagyon eltorzította a jelet. Az áttörést úgy értem el, hogy az RC tagból az ellenállást kivettem, a kondit 1nF-ra cseréltem, és az encoder másik lábára is raktam egy 1nF kondit. Így most, az alábbi kis progival, szépen működik az encoder, gyorsan, és lassan is. (csak a lényeget rakom be)

Az if(pos > BIT...... feltétel, csak azért van benne, mert a vezérlő P1.0-7 lábára raktam 8db ledet, ezzel figyelve az encoder működését.

Az alábbi kóddal az a problémám, hogy BIT4-en folyamatosan 1.01 MHZ a frekvencia és 50% a kitöltés, függetlenül a TA0CCR2 értékétől.
Azt szeretném, hogy a BIT4 -en 75% legyen a kitöltés.
A Proci típusa 2452.
Van valakinek ötlete?

Megoldás:

He-he, ebbe a hibába már én is beleestem.

Köszi már vagy 3 órája szívok vele. Ha nem írod meg, nem tudom mikor jöttem volna rá.

Én két napig szívtam vele, mire Icserny fórumtársunk felvilágosított, hogy az adatlap vége fele, valahol, megtalálható a PxSEL leírása.

Sziasztok.
Viszonylag még kezdő vagyok az MSP430-programozásában és volna egy projekt amit minél hamarabb meg kellene valosítsak. A projekt egy fontos része a következő:
egy wireless vagy bluetooth (amelyikkel egyszerűbb)modullal le kellene olvassam egy gps-ről a mozgásban lévő jármű sebességét. A problémám az, hogy nem tudom egyáltalán lehetségese ez, ha igen akkor megkérem azokat akik dolgoztak hasonló projekten segítsetek hogyan induljak el.
Előre is köszönöm a segítséget.

A GPS moduloknak tudtommal van soros kimenete, a Bluetooth eszköznek pedig soros ki/bemenete. Ha összekötöd őket, akkor már mehet is az adás, MSP430 sem kell hozzá. Jól értettem a kérdésedet?

Lehetségesnek lehetséges Szerintem mindenféleképpen kell egy vezérlő, mert be kell konfigurálni a bluetooth és GPS egységet is. Ajánlatos megnézni hogy milyen kommunikációs csatorna áll rendelkezésre a két modulnál, mert ha az UART-ot lefoglalod a GPS-nek akkor ugye a Bluetooth modult már nem tudod vezérelni ha az is UART-os (ezek száma persze függ a vezérlő típusától is).

Üdv ujra mindenkinek. Kis kényszer pihenő után megint itt .

Kérdésem a következő van egy fotodiódám,infra kaput akarok csinálni, de adc-vel még sosem foglalkoztam , aki már állított be adc-t mspben jelezze már felém , hogy ezt miképpen kellene, kb ilyen 300mv-t kellene mérni.

Ha vissza lapozol, akkor találsz egy, általam írt egyszerű voltmérő programot. Abban benne van, a szerintem legegyszerűbb ADC beállítás. Ha csak 300mV-ot szeretnél mérni, akkor külső ref.feszt javaslok, de ha nem a pontosság a lényeg, akkor állísd be a ref.feszt 1.5V-ra (FUG).

Sziasztok.
Tanácsokat, ötleteket, keresek egy feladat megoldásához.
Egy nagyon egyszerű, "Ne hagyd el a táskád" szerkezetet szeretnék csinálni. Tudom, első (hallásra), kicsit furcsa.
A lényeg: (elsőnek egy kis mese) Édesapám rendszeresen elveszti a táskáját. Mindig lerakja valahova, és elindul nélküle. Mindannyian tudjuk, hogy ez mindenkivel előfordul, de vele sajnos mindig, és a legfurcsább helyeken. Sajnos ez a táskaelhagyás már nagyon sok pénzbe kerül nek/em/ki.
Gondolatban kitaláltam egy egyszerű szerkezetet, és ennek a megvalósításában szeretnék segítséget kérni tőletek.
Valami olyasmire gondoltam, hogy két vezérlő lenne összekötve bluetooth-on keresztül, és ha az egyik nem tudna a másiknak valamit!? küldeni, akkor hangjelzést adna. Az adó, és a vevő is, egy-egy 3,6V 360mAh-ás akksiról menne, ami azt jelentené, hogy az energiatakarékos módban, akár több hétig is üzemelne, feltöltés nélkül. Persze tudom, hogy mi van ha lemerül az akksi, vagy lehagyja az adót, vagy ?. Ezekre is vannak már megoldásaim, de azt most nem részletezném. Nem az érdekel, hogy, minek, meg hogy úgyis, vagy ez meg az, stb. Az érdekelne, hogy ez így megvalósítható-e, (bluetooth-al) vagy van-e valami jobb, olcsóbb, könnyebb megoldás.

Anyám mikor kicsi voltam belekötötte a kabátomba egy madzaggal a télikesztyűm, hogy ne veszítsem el soha ha leveszem. Bár ez nem tudom mennyire jó megoldás egy táska esetében.

Bluetooth-al is megoldható, de szerintem egy egyszerű RF adó-vevő pár olcsóbban kijön. 5-20 másodpercenként megpingeled a "táskát" és ha nem jön válasz akkor riaszt. Persze itt figyelembe kell venni hogy a két pingelés közötti időt, mert az végülis reakcióidő a táska elhagyásának észlelésére. A pingelési időközök rövidítésével ez az idő csökkenthető, de ugye ez több energiát emészt.

Való s igaz. Az RF modulra nem is gondoltam. Azért a bluetooth-ra gondoltam, mert van itthon pár db HC-05-ös modulom, és egyszerű dolgozni vele. Én 1 perces periódusokra gondoltam, s a két periódus között elmehet aludni a vezérlő. Az 1 perc bőven elég, mert talán egy perc alatt nem felejti el, hogy hol volt, és nem lesz túl messze a táskától.

1 perc szerintem sok, mert leszáll a buszról és hopp csipog, az meg már 50m-re jár(tapasztalatból tudom :S ). 20 másodperc szerintem célszerű.
Ha van modulod akkor ugye nem kell kiadni pénzt RF-re. Kérdés az hogy a Bluetooth modulok mennyi energiát fogyasztanak, nem kell-e újra konfigurálni őket minden ébredésnél, ha esetleg ott is megszünteted a tápfeszültséget energiatakarékosságból. Mondjuk a bluetooth megoldás mellett szól az hogy ott viszont nem kell foglalkozni a zavarvédettséggel, RF modulok érzékenyebbek rá a nyílt frekvencia sáv miatt.

Lényeg a lényeg. Szerintem egy egyszerű "Ping" szoftver tökéletesen megteszi, szerintem energia takarékos is.

Ha valami szoftver hiba miatt lefagy a proci van rá lehetőség lekezelni? Tehát ha valami oknál fogva lefagy újraindítsa a programot.

hát első körben azt mondanám hogy watchdog , de akkor ugye minden újra indul.

Szoftver hiba miatt nem fagy le a proci, legfeljebb nem azt csinálja, amit szeretnél.