Fórum témák
» Több friss téma |
Köszi mindenkinek a kitartó meggyőzést.
Úgy döntöttem, hogy ha már ennyien azt mondjátok, hogy jobb lenne "valamit" berakni a kijelző meghajtására, akkor inkább maradok a shift register-nél (74hc595). (Sajnos ezzel is akad egy kis problémám, mégpedig, hogy nem találtam magyar forgalmazót, aki árulná TSSOP16, vagy DHVQFN16 tokozással.)
Az www.embedded-lab.com honlapon találtam egy érdekes projektet, amelyben DHT11 szenzorral hőmérsékletet és relatív páratartalmat mérnek, s az eredményt a PC jeleníti meg. Bár eredetileg ChipKIT kártyához írták (MPIDE), a korábban említett hordozhatóságnak köszönhetően könnyű volt átírni az MSP430 Launchpad kártyára és DHT22 szenzorra, Energia IDE környezetben. A PC oldali szoftver pedig Processing-hez készült, amelyben csak az adatbeolvasást és a soros port hozzárendelést kellett módosítani. Egy kicsit a kijelzéshez is hozzá kellett nyúlni, mert az általam használt DHT22 szenzor tizedfokos és tizedszázalékos felbontású. Az egyszerűség kedvéért a páratartalom kiírásánál lecsökkentettema betűméretet (48 pontosról 44 pontosra), így a tizedesjegy is kifért.
A programot Processing-1.5.1 és 2.0b08 alatt is kipróbáltam. Java SE 6 update 39 van telepítve. A csatolt állományok közül TRHlogger.zip a firmware (MSP430G2553-on futtatom, hardveres UART beállítással), Energia-val fordítható. A dht22.zip állomány pedig a PC-n futó alkalmazás (Processing-hez). A dht22 logger programban a legelső elérhető soros porton próbál kommunikálni a program. Ha szükséges, módosítsátok ezt a sort! Használjátok egészséggel!
Megnéztem a kijelzőm lábai megeggyeznek a videón bemutatottal,de hiába rakom össze a kapcsolást úgy ahogy bemutatja a videón lépésről,lépésre max azt érem el hogy világít egy 4-es a 3. kijelzőn.Nemértem mitől lehet ez,de még mindig arra a programra gyanakszom amit az után indít el hogy felprogramozza az mcu-t,mert neki is csak az után üzemel rendesen.Mégegyszer ha esetleg ezzel tudok egy kicsi segítséget nyújtani akkor berakom ide hátha többre mentek vele mint én.Én egyszerűen nem találom hol lehet a hiba.
Idézet: „amit az után indít el hogy felprogramozza az mcu-t” A videóban a programozás után nem indít programot, mert az a bizonyos program maga a programozás. Nem is a program lefutása után kezd el működni, hanem amikor lehúzza a programozó kábeleket (azaz amikor felszabadul a reset láb). Olvasd végig a cikket - a special design notesra különös tekintettel -, mert a video önamgában nem elégséges, és csak szenvedni fogsz.
Esetleg nem kéne a reset lábat leellenállásolni,habár a rajz nem mutatja,de én már másra nem tudok gondolni.(hozzátenném egy kissé kezdő vagyok a témában,ezért bocs a sok kérdésért)
Sziasztok.
Ma élesben el kellett indítanom a "kazán vezérlőmet", mert a mechanikus "bojler" hőfokszabályzó ismét megadta magát. Sajnos még mindig csak félig késznek mondható. Amiket most tud: MSP430G2553 QFN32 tok - Idő/dátum kijelzés (RTC) - Hőmérséklet mérés, kályhában, szobában. - Hőmérséklet mentés 10 percenként EEPROM-ba - Adat küldés PC-nek EEPROM-ból bluetooth-on, tárolás, és grafikon rajzolás céljából. (Szoftver: Processing 1.5, saját készítés) - Keringtető szivattyú ki/be kapcsolás - Huzat ajtó szabályzás. (A mechanika nincs kész) - Láng (tűz) figyelés. (foto tranzisztorral, komparátorral) - Akku fesz. figyelés. Amiket még tudni fog: - MCU (doboz belső) hőmérséklet kijelzés - Bojler fűtésrásegítés vezérlése - Töltésszabályzás. (Napelem->akksi) - Külső hőmérséklet figyelés. Az egység akksiról megy, melyet napelemmel töltök, jelenleg egy PB137-es segítségével. Mivel nyáron nem fűtünk, a program május 1-én mindent kikapcsol (LCD, hőszenzorok, stb..), és elmegy aludni a következő gombnyomásig (LPM4 mód). Ilyenkor az RTC se kap áramot, csak a beépített elemről. A visszakapcsolást követően, figyeli a szivattyú bekapcsolásokat, és ha egy hétig nem kell bekapcsolni a szivattyút, ismét elmegy aludni. Sajnos a programban még van pár kérdéses részlet, és tele van szeméttel (felesleges változók), de úgy tapasztaltam, és a tesztek is ezt bizonyították, hogy jól működik. Egy olyan hibát is észleltem, amire nemrég DecebaL fórumtársunk is rákérdezett, hogy ha hálózatról megy a szerkezet, és valami más fogyasztót bekapcsolok, akkor az LCD megbolondul, de a program fut tovább normálisan. De ezzel, a "zöld"energia felhasználás miatt nem foglalkoztam. Több kép.
Le a kalappal nagyon jól néz ki és a tudása is figyelemre méltó gratulálok, nagyon tetszik.
Sikerült megszürnöm a mágneskapcsolót azóta nem tudtam kiakasztani az lcdt. Csatoltam a szűrőt amivel sikerült megoldanom a problémát, hátha másnak is kell. Annyira jól sikerült a szűrés, hogy mikor bekapcsol, kikapcsol a mágneskapcsoló semmilyen "lökés" nem látható szkoppal.
Köszi.
Nálam máshogy jelentkezik/ett az adott probléma. A fejlesztés/tesztelés alatt, a kész áramkörre rá volt téve a Launchpad 4 nagyon rövid! (~2cm) vezetékkel (Vcc,Vss,RESET,TEST). Más, külső áramforrás nem volt az áramkörön. Ha pl. felkapcsoltam a villanyt (neon) a szobában, az LCD abban a pillanatban megbolondult. De más fogyasztónál (labortáp, levegős páka, stb..) is jelentkezett ez a probléma. Az érdekes számomra is az, hogy a program nem állt le, csak az LCD-n lettek össze-vissza karakterek, színek. Lehet, hogy nálam az USB tápját, (PC tápját) kellene megszűrni!? Vagy az összes fogyasztót a lakásban?! Az általad rajzolt szűrőt alkalmaztam a szivattyút kapcsoló relénél, hogy védjem a relé érintkezőit, csak én a varisztort kihagytam.
Sajnos régen nálam is jelentkezett ez villanykapcsolós mizéria, szkopon néztem elég nagy lökés volt látható. Nálam is kizárólag neon és energiatakarékos fénycsövek fel le kapcsolásával jelentkezett. A problémát az elektronika táp bemenetére kötött LC szűrő és a kijelzőre a táplábakra közvetlenül egy 100nF kondi oldotta meg.
Sziasztok!
Van egy launchpadom, ami ugye msp430G2xxx típusú kontrollerekhez való. Lehet e ezzel más msp430-as mikrokontrollereket programozni (és debuggolni), amiknek szintén van SBWTDIO és SBWTCK lába? (kétvezetékes Spy-Bi-Wire illesztő kivezetései). Az ötletem az, hogy a nyákon két ponton kivezetem ezt a két lábat, és rákötöm a launchpad megfelelő kimeneteire. Ez így menne? Köszönöm!
Sziasztok!
Van egy Arduino Nano mikrokontrollerem, ami eddig teljesen jól működött, de most feladta a szolgálatot, viszont szükségem lenne a helyettesítésére. Van is itthon 2 MSP430-asom, arra gondoltam, helyettesítem azzal. Két db szervót, és egy LED-et vezérelt az áramköröm, bemásolom a kódját. Melyik részeket kellene megváltoztatnom, hogy működjön MSP430-assal is?
Szia.
Még nem volt időm foglalkozni az Energia programmal, de a minap kipróbáltam a szervo vezérlő programját. Szerintem a Te programodban csak a ki és bemenetet kell beállítani az MSP430-hoz, ha az MSP-s szervo vezérlőt használod.
Akkor csak a lábak nevét elég átnevezni? AZ MSP-hez nem kell valami külön PWM-es átírás is?
Idézet: „AZ MSP-hez nem kell valami külön PWM-es átírás is?” Nem, hisz az Energia programban (ami az MSP-hez való) ugyanúgy megvan a "servo" függvény/ek. Lásd: Energia->Példák->Servo->Knob/Sweep. Azt kell/ene megnézned, hogy a servo függvény melyik Timert használja, hogy tudd melyik lábakra teheted ki a servo jeleket. (Ha jól emlékszem a Timer0-át használja.) De még egyszer hangsúlyozom, hogy nem foglalkoztam az Energiával, ezért azt sem tudom, hogy az I/O lábak minek vannak elnevezve. Annyit tudok, hogy a P1.0 lábnak lehet a RED_LED nevet adni, Pl: pinMode(RED_LED, OUTPUT); vagy pinMode(RED_LED, INPUT); de a többi..... A lényeg, hogy szerintem csak ezeket a sorokat kell megváltoztatni az MSP-nek megfelelően: myservo.attach(?); myservo1.attach(?); pinMode(??, INPUT); pinMode(??, OUTPUT);.. pl: pinMode(RED_LED, OUTPUT); Idézet: „AZ MSP-hez nem kell valami külön PWM-es átírás is?” Nem kell PWM átírás, mert nem hardveres, hanem szoftveres PWM-et valósít meg a szervó könyvtár. Ennélfogva a felhasznált láb elvileg bármelyik digitális kimenet lehet.
Az eredeti programban a 9-es és 10-es lábakon volt a szervó, ha jól néztem, az MSP esetében is ezekre a kimenetekre köthetem őket. Mellékelek egy képet, ami alapján ezt gondolom.
Egyelőre úgy szeretném megoldani, hogy a vezérlő S2-es gombának lenyomására működjön, ez ugye a P1.3-as, tehát az 5-ös láb. A programban az eredeti 2-es helyére írjam az 5-öst, vagy úgy írjam be, ahogy rendes MSP-s programozhásnál,
A fenti sorokban az 5 helyébe írj 1-et vagy 14-et, 2 helyett pedig írj 5-öt! Elvileg az mindegy, hogy 5 vagy P1_3, vagy PUSH2. Az is mindegy, hogy 1, P1_1, vagy RED_LED. Idézet: „nem hardveres, hanem szoftveres PWM-et valósít meg a szervó könyvtár” A "servo.cpp"-ben a Timer_A0-át használja. Vagy nem egyről beszélünk? Idézet: Igen, azzal generál megszakításokat. De a szervó kimeneteket DigitalWrite() függvényhívásokkal állítgatja.„A "servo.cpp"-ben a Timer_A0-át használja.” Mivel a 20 ms körüli periódusba 7-8 csatorna belefér, ennyit tud kezelni. Idézet: „De a szervó kimeneteket DigitalWrite() függvényhívásokkal állítgatja.” Áá, ezt nem figyeltem. Bocsi érte.
Köszönöm szépen! Ezek az MSP-k működnek úgy, mint a PIC-ek, hogy kiveszem az IC-t a programozóból, és beforrasztom egy NYÁK-ba, a helytakarékosság miatt?
Sajnos a TI megduplázta az MSP430 Launchpad árát ($4.30 -> $9.99).
Ezzel biztosan csökkeni fog a népszerűsége a hobbisták között. Szerintem így a Stellaris LaunchPad jobban megéri $12.99-ért, illetve a $10-os tartományban is lényegesen több kihívó akad más gyártóktól. (Bár továbbra is nagy előny a TI mellett az ingyenes szállítás.)
Sziasztok.
Szerencsétlenkedem a "Capture" modullal egy g2231-ben. Egy mintaprogram (slac015.zip -> fet140_ta_22.c) alapján, átfordítva g2231-re, próbálom egy tömbbe menteni a TACCR1 számláló adatait, későbbi feldolgozás céljából:
A gondom az lenne, hogy amikor a jel megérkezik, bemegy a megszakításba, és csak a tömb első helyére ír adatot, azaz capture_buffer[0]= TACCR1. A tömb összes többi (5) eleme nulla marad, pedig a számláló nincs leállítva. Miért? A program addig nem csinál semmit, amíg a tömb fel nem lett töltve adattal, ezt jelzi az "uart" változó. Ha megvannak az adatok, akkor Icserny SW uart függvényeivel elküldi az adatokat a PC-nek.
A megszakítási jelzőbit törlését nem kellene feltételhez kötni (az if-en kívül helyezd el)!
Valóban!
Köszönöm. Egy másik MCU-val (g2252) előállítottam, szkóp és freki mérő szerint pontosan 500Hz-et. Ezt mérem a g2231-el, a lenti programmal, és a kiírt eredmény "1974". Nem 2000 kéne legyen? Kiíró és számoló rutin:
Idézet: A g2231 frekvenciáját is próbáld meg ellenőrizni a frekimérővel és az oszcilloszkóppal. Lehet, hogy az pontatlan. „Ezt mérem a g2231-el” Idézet: „Lehet, hogy az pontatlan.” Nem lehet, hanem biztos. A kalibrált 1MHz, csak 981kHz-et jelent. Tehát ha pontos adatot szeretnék kapni, akkor valahogy pontosítanom kell ezt a frekit is? Szoftveresen meg lehet oldani, vagy külső kvarcot tegyek rá? Idézet: Szoftveresen korrekcióba vehető (szorzás 1000/981-el), de ez sohasem lesz pontos, mert a tápfeszültség és a hőmérséklet hatására folyton változik a frekvencia. „Szoftveresen meg lehet oldani, vagy külső kvarcot tegyek rá?” A hozzászólás módosítva: Márc 10, 2013
Végül is, ahogy számolgattam "elég pontos".
A szkóp/frekimérő szerint a bemenő freki 497,6Hz. Az MCU (g2231) által mért freki: TACCR1=1974= 1000000Hz/1974=506,58Hz pontosítva: 981000Hz/1974=496,96Hz, ahol már "csak" ~1Hz az eltérés. Így még egy jó kis frekimérőt is lehetne csinálni, de ez csak egy egyszerű fordulatszámmérő lesz, ami a "sok" matematikai" művelet miatt, tuti, hogy pontatlan lesz.
Senki nem próbálkozott még ilyennel?
Akkor rendelek egy sample-t, azt majd meglátom, hogy megy a dolog. |
Bejelentkezés
Hirdetés |