Fórum témák
» Több friss téma |
Hosszú kínlódás után, félig sikerült megoldani az i2c problémámat.
A megoldás egyszerű volt, kivettem az eeprom írást a megszakításból. Most szépen beírja az adatokat, időt, k_fok változót, és a v_fok változót is. Bemásolom az összes adatot egy tömbbe, és úgy írom ki az eepromba. Program részlet:
Berakok még két file-t. A "data.txt", a Processing által fogadott (uC -> bluetooth -> Processing), és elmentett adatok, a másikat a Saleae Logic-ba kell berakni.
Sziasztok.
Ha UART-on küldök adatokat, hogy jelezzem a PC-nek, hogy nem megy több adat? Processing-ben próbáltam így:
de nem jó, mert ha az egyik adat "10" akkor megáll a fogadás. Van erre valami egyszerű módszer?
Szia!
Adatok végét nem tudod jelezni karakterrel ( ha előfordulhat, tehát nincs kizárva!). Ilyenkor megadod pl. a darabszámot ( ez lehet előre megadott pl. fix 16 vagy változó, az adatsorozat elején megadva ) és annyi karaktert vársz ( időlimittel! ), végén CRC ellenőrzéssel! Steve A hozzászólás módosítva: Nov 28, 2012
Köszi!
Ettől féltem! Most mindkét programot (uC, PC) át kell variálnom. Nem lesz egyszerű.
DOS konvenció szerint ASCII szövegfolyamnál a Ctrl-Z kód a fájlvége jel. Ha szöveges információt küldesz, akkor ilyen máshol nem lesz benne, tehát használhatod a kívánt célra.
Az MSP430G2xx3 gyári mintapéldák (slac485a.zip) C alkönyvtárából hiányzik a Readme lista. Itt küldök egyet, amelyet a forrásfájlok fejlécéből generáltam.
Sziasztok.
Egyszerűen belehülyültem a típuskényszerítésbe, illetve, hogy egy tömbből az adatokat kiírassam a képernyőre a Processing-gel. Tehát, a g2553 elküld egy rakás adatot a PC-nek, melyeket rögtön elmentek egy file-ba. Ha kellenek az adatok, akkor behívom a file-ból, és berakom egy átmeneti tárolóba, tömbbe, ami (int) típusú (inbytes). Ebből a tömből kellene kiíratni az adatokat a képernyőre, de már teljesen belebonyolódtam..... Ha így iratom ki, akkor kiírja,
de nekem nem kell a szöveg. Az csak a próbák alatt kellett. Ha viszont kiveszem a szöveget, akkor természetesen összeadja a tömb adatit, és kiírja az eredményt.
Hogy tudnám ezt megoldani?
probáltad? elég gányolásnak tűnik, meg nem is ismerem a nyelvet, de én így probálnám
Köszi.
Az 1. sor eszembe sem jutott, az 5. sor meg azt írná ki ami az " " -jelek között van. Időközben megtaláltam a Processing "help"-jében a megoldást. Rosszul használtam az "str"-t. Egyenlőre (próbaképp) lemásoltam az ott közölt mintát, és azzal szépen működik,
de majd ezt is át kell írjam ha több adatot kell feldolgozni.
Pihent agyú emberek MSP40 Launchpadon bitbillegtetéssel működtetett USB kommunikáció összekalapálásán dolgoznak. Bővebben: Link
Sziasztok!
Szeretnék segítséget kérni! Adott egy SAGA RF távirányító amiben egy MSP430F149 vezérlő van, a kérdésem az volna, hogy milyen eszközzel tudnám csatlakoztatni Pc-hez. Ugyanis, létezik hozzá gyári interfész kábel és szoftver ebből a szoftver az meg van, de a kábelt horror áron adják, ezért kellene valamilyen okos megoldás. Megköszönném ha valaki tudna segíteni!
Hello!
Esetleg ha van kedved építeni egyet: Bővebben: Link
Szia!
Kedvem az van csak nem tudom melyik lenne a jó megoldás , ha mondjuk ezt megépíteném akkor hogyan tudnám csatlakoztatni a távirányítóval? Mivel annak csak 6 tűs csatlakozója ("J4 to writer") adatott: 1.: DVSS/AVSS 2.: P1.1/TA0 3.: --- ? 4.: RST/NMI 5.: DVCC/AVCC 6.: TCK Ezek vannak kivezetve a csatira. A hozzászólás módosítva: Dec 6, 2012
A kérdőjeles kivezetés nem a P2.2 lábhoz csatlakozik véletlenül? Ha igen, akkor a Boostrap Loader (BSL) jön számításba. Bővebben: Link
Igen odamegy, átnéztem még egyszer a rajzot. Ezt találtam nem rég : MSP430 BSL Programmer . Igazából kész cucc is jó lenne csak ne lenne nagyon drága.
Szerintem erre a célra bármelyik 3,3 V-os jelszintű USB-UART(TTL) protokol konverter megfelel, amelyiken kivezették a leírásodban feltüntetett "modemvezérlő" RTS és DTR jeleket is. Pl. CP2102, PL2303 vagy FTDI kábel. Bővebben: Link
Köszi , akkor megpróbálom valamelyiket beszerezni!
Az olcsóbbak közül a mellékelt képen látható CP2102 típust ajánlom, ezen kétoldalt minden fontos vezérlőjel ki van vezetve. Figyelem: az RST nem tévesztendő össze az RTS-sel! Az RST jel a CP2102 moduloknál a CP2102 lecsatlakoztatására való!
Elegánsabb (és valamivel drágább) az FTDI TTL-232R-3VR kábel, ami elsősorban akkor ajánlható, ha a csatlakozó tüskesor mérete és a jelek sorrendje illeszkedik a kábel hüvelysorához.
A TXD és RXD kimenetek passzolnak az MSP430 P1.1 és P2.2 lábaihoz? ( bocs ha hülyéket kérdezek de nem vagyok otthon ebben a témában )
Meg kell nézni a MSP430F149 adatlapját, meg az áramkörödet, hogy mekkora tápfeszültséget használ. Feltételezem, hogy a 3,3 V körüli jelszintet szereti. Az itt belinkelt képen látható UART-TTL átalakítóval az a gond, hogy nincs rajta sem az RTS sem a DTR jel kivezetve.
Sziasztok.
Már az idegösszeomlás szélén/benne vagyok. Két hete vacakolok a 24lc512-es EEPROM normális írás/olvasásával, ami végre sikerült is. Én voltam a figyelmetlen  , és nem olvastam el rendesen az adatlapot, emiatt az adatok össze-vissza íródtak az EEPROM-ban.Most, hogy végre jó, beütött egy olyan hiba, amire nem találok magyarázatot. Az EEPROM-ból kiolvasott adatokat, "egyből" elküldöm az UART-on a PC-nek, de valahonnan??? az UART küldésbe megjelenik egy bájt (255), és nem tudom honnan kerül oda! Az adat küldés:
A lényeg: Elsőnek elküldöm UART-on, hogy hány bájtot fogok küldeni, utána az I2C-n kapott adatokat másolom az UART bufferbe. (Az RX változót, csak próbának raktam be.) Ez a programrészlet és a fogadó program is szépen működik, de miután elküldöm a küldendő bájtok számát (2 bájt), valamiért még egy bájt kerül küldésre, aminek az értéke 255. De honnan? Miért? A két kép: "eeprom_1" (i2c SDA) kiküldi a beolvasandó oldal címét, és szépen elkezdi az olvasást, ahol az első bájt értéke 0x15. "eeprom_2" (UART uC TX) 0x01,0x01 a küldésre kerülő bájtok száma (257) -> 0xff ??? ezt nem értem, hogy kerül ide? -> 0x15 az i2c-n beolvasott első bájt. Bocs a hosszú hsz.-ért.
A 27. és 31. sorok közötti részben elindítod az I2C olvasást, de nem várod meg, hogy beérkezzen az adat. Lehet, hogy ebből jön a hülyeség (255 vagy akármi). A második bájttól kezdve ez akár jó is működhet, hiszen a kiírás lassabb, mint az olvasás, de a ciklus elején garantáltan rossz az időzítés.
Mellesleg célszerű volna készíteni egy uart_putc(), egy i2c_write() és egy i2c_read() függvényt, kiegészítve az összes várakozással, hibalehetőség vizsgálatával és lekezelésével, s akkor nem kellene ezzel foglalkozni minden egyes karakter kiküldésekor vagy beolvasásakor. Tegnap próbáltam ki az első I2C programomat, s ne tudd meg, mit szenvedtem, mire rájöttem, hogy a felhúzással van a baj (a boltban 4,7 k Ohm helyett 4,7 Ohm-osakat csomagoltak, emiatt egy bivaly sem bírta volna lehúzni a buszvonalakat alacsony szintre).
Köszönöm szépen.
Megnéztem debugg módban a Register/Special Function alatt az UCB0RXIFG-t, és valóban később billen be 1-be. Beraktam egy 1ms-os késleltetést, de nem itt volt a baj! A helyzet annyiban változott, hogy nem 255-öt küldött, hanem mást. A fő gond, nem értem, hogy miért, a 9. sor után volt, illetve oda kellett berakjak egy 5ms-os késleltetést. Tehát, kiküldök az UART-on két bájtot, várok, és csak ezután indítom el az i2c műveleteket. Az analizátor adataiból kiderült, hogy azt a bizonyos két bájtot nem rögtön küldi el, hanem később, és szerintem ebből lett a galiba.
Így nem rak be egy fölösleges bájtot sem. Viszont az i2c olvasás indítása utáni 1ms-os késleltetést nem látom (eeprom_2 kép). A PC által fogadott adatok a "data.txt"-be kerültek, végre minden adat a helyére. 1-6. adat, idő/dátum, ami 128 bájtonként ismétlődik, a többi hőmérséklet érték 2 bájtban elmentve. ("progi kép" a félkész PC program) Idézet: „Mellesleg célszerű volna készíteni egy uart_putc(), egy i2c_write() és egy i2c_read() függvényt,” Az biztos, hogy szebb, jobb, takarékosabb, és célravezetőbb lenne, de ehhez sajnos az én tudásom még nagyon a béka "hátsórésze" alatt van. Egyébkén a két hetem arra ment rá, hogy több bájtot küldtem egyszerre a 24lc512-nek, és csak a 256. bájtot figyeltem, és ezután volt csak STOP. Ezért a 128. bájt küldése után elkezdte felülírni az első bájtokat, addig míg nem jött egy STOP. Azt a részt nem olvastam az adatlapban, hogy minden lap végén kell egy STOP. Pedig már itt is elhangzott.
Sziasztok!
Ismét segítséget kérnék, mert nem jutok 1-ről a 2-re: Hiába googlizok, nem találok C nyelvű mintát, de még parancsot sem, ami jó lenne IAR-hoz arra, hogy kommunikáljon az MSP430G2553 és egy közvetlenül rákötött DS18B20, ami a panelról kapja az áramot, de nem parazitában. Azt már tudom, mit hova kell kötni, meg ha minden igaz, meg is van a hőmérséklet kiolvasásának a menete, csak éppen nem tudom ezt C-ben megfogalmazni, mert nem tudom hogyan lehetne 1-wire-ben kiküldeni a hőmérőnek a parancsot (pl. CC), majd visszaolvasni, ugyanazon a porton/tüskén(az adatlábán) keresztül. Mert ugye van egy adatláb, amin kétirányú kommunikáció zajlik felváltva. Most akkor menet közben állítgassam hogy a panel lába amire a hőmérő adatlába csatlakozik, az bemenet vagy éppen kimenet? Már itt gondban vagyok. Aztán, hogyan kérdezem meg tőle, mi a 64 bites egyedi azonosítója, majd erre a válaszát hogyan tudom visszaolvasni? Állítólag nem is lehet 1-wire-ban megoldani, másvalaki szerint viszont meg lehet. Szóval, nem megy, parancsok vagy mintaprogram kellene nekem. Milyen paranccsal, hogyan definiáljam és paraméterezzem? rx_byte, tx_byte kell hozzá? Vagy más? Vagy tényleg nem lehet? Akkor mit csináljak? Térjek át másik protokollra, mondjuk UART vagy SPI? Vagy váltsak IAR-ról CCS-re? Utóbbiban úgy olvastam, van definiálva 1-wire. Mit javasoltok? A hozzászólás módosítva: Dec 17, 2012
Idézet: Hát persze! Enélkül nem megy a kétirányú kommunikáció egy vezetéken.„Most akkor menet közben állítgassam hogy a panel lába amire a hőmérő adatlába csatlakozik, az bemenet vagy éppen kimenet?” Ez a leírás például megfelel? A hozzászólás módosítva: Dec 17, 2012
Sziasztok.
Egy program szervezés/felépítéssel kapcsolatos kérdésem lenne. Rövid programelőzetes: Egy régebbi projektemet szeretném kiegészíteni, egy plusz funkcióval. A program egy egyszerű hőmérő, ami két analóg szenzor által mért értéket jelenít meg egy nokia lcd-n. Ebben a programban/projektben, "számomra" csak annyi a különlegesség, hogy az egész hardver, egy 1,2V 2200mA-es AAA akksiról megy, amit egy 2V 500mA-es napelem tölt, és ezt a uC felügyeli. A kijelzés nem állandó, csak akkor mutatja a hőmérsékletet, ha "megnyomunk egy gombot" (ami nem gomb). A mikrovezérlő, ha nem kell kijelezni a hőmérsékletet, LPM4-es módban van (tehát mélyen alszik). Azt szeretném megvalósítani, és ebbe a programba beépíteni, hogy ha "jelzés" érkezik, akkor SW UART-on küldje el az aktuális hőmérsékleteket. A mikrovezérlő egy g2452-es. Az elgondolásom: SW UART fogadás, a Timer_A Capture modul segítségével, ami megszakításban felkelti a uC, vagy nem kelti fel? Ezt a részt nem igazán értem! A lényeg az lenne, hogy nem kellene teljesen felébreszteni a uC-t, mert nem kell a kijelzés, csak az ADC, és a SW UART RX TX. Az ADC használja a megszakítást, ezért nem tudom, hogy ha Capture modult használom megszakításban, akkor abból mehet az ADC megszakítás? Remélem érthető, mert már én sem értem , hogy mit is írtam.(pedig nem is iszom alkoholt)
Köszönöm!
Ezt a leírást én is megtaláltam, csak nem értem a következőket benne: - Az onewire.h hivatkozható IAR-ban, tehát benne van és szépen működik? - Hol találok arról leírást, hogy a belinkelt példánál, mi alapján paraméterezi fel a függvényeket? Pl. onewire_write_byte(&ow, 0xcc); Valamint, honnan tudja hogy ha az &-el az ow-ra hivakozom, akkor neki input vagy output lesz az irány? Minden parancsot onewire_write_byte-al ad ki és ezzel is olvassa be, nem kéne lennie beolvasó függvénynek, pl. onewire_read_byte? A hozzászólás módosítva: Dec 17, 2012
Szia.
Idézet: „Az onewire.h hivatkozható IAR-ban, tehát benne van és szépen működik?” Nem. Ezt a függvényt be kell csatolni a programodba. A függvények helyét is megadta a szerző! Amúgy szerintem nagyon jól fel van kommentezve a program.
Köszi! Ezt hogy nem vettem észre eddig...
 . Úgy látom, van read függvény is, szóval ezt is benéztem, kell nekem álmosan kódokkal foglalkozni. Átbogarászom, jónak tűnik így elsőre blikkre.Viszont elég hosszú a kód, meg lehet ezt írni ennél rövidebbre?
LPM4 módban nincs órajeled, tehát a Timer Input Capture módjának sincs sok értelme. De egy átalános célú I/O lábbal is ébresztheted a mikrovezérlőt, nem kell hozzá semmi trükközés, csak engedélyezni kell a megszakítást és be kell állítani, hogy le- vagy felfutó élre működjön.
Idézet: Hát a szoftveres UART-ot akkor ki fogja megcsinálni?„A lényeg az lenne, hogy nem kellene teljesen felébreszteni a uC-t” Idézet: Ez hogy fér össze a min. 1.8V-os tápfeszültség specifikációval? „az egész hardver, egy 1,2V 2200mA-es AAA akksiról megy” |
Bejelentkezés
Hirdetés |
