Még annyi kérdésem lenne, hogy az ADC konverziónál az egyszerű mérésnél a legelső programban az ADC10MEM érték milyen érték?
Annyit értettem, hogy ez a referencia értékeke alapján egy érték, amiből visszalehet számolni a feszültséget, de itt mind egész számmal van megadva, azt meg lehet valahogy oldani, hogy ebből lebegőpontos legyen?

Az ADC 10 bites (tehát 0 és 1023 közé eső) egész számokat produkál, ennyi szintet tud megkülönböztetni. Lebegőpontos számot nem érdemes csinálni belőle, mert fölösleges nyűggel jár (az Arduino szerű Energiában azért néha elkövetjük...).

Értelmesebb dolognak tartom, ha az ADC-vel mért értékeket a kezelni kívánt kisebb egységben (pl. feszültséget mV-ban, hőmérsékletet tizedfokban) fejezzük ki (32 bites egész típusú változóban nem gond a tárolása, átlagoláshoz az összegzése).

Értem, köszönöm!

Még annyi kérdésem lenne, hogy a fordító ezt a hibát dobja ki minden beírás előtt (IAR), de a beírt kód az lefut.

Sat May 03, 2014 08:33:42: Invalid parameter(s) : (Configure) , mode=0x12, value=0x1
Sat May 03, 2014 08:33:42: Invalid parameter(s) : (Configure) , mode=0x12, value=0x0
Sat May 03, 2014 08:33:42: Warning: Failed to use emulated breakpoints

Megpróbáltam kis kóddal

P1DIR=BIT0+BIT5;
P1OUT=BIT5+BIT0;

Ennyi az egész program, de így is ugyan az.

Még annyit elfelejtettem, hogy a programot rendesen ráírja és működik is vele a kapcsolás,csak olyan furcsa, hogy írja.

Valamit nem állítottál el véletlenül az IAR Workbench Project Options menüjében?

A projekt option / FET debugger / breakpointsnál kivettem a pipát a use software breapointtól és így már csak egy hiba maradt, de az egész rendszer működik ugyan úgy csak furcsa, mert nem állítottam semmit.

Több napnyi szenvedés után rájöttem, hogy szemből fehér az egész kijelző, viszont hogyha kicsit oldalról nézem akkor megjelennek a karakterek, tehát a program működik már csak a kontrasztot kéne beállítani

Még annyi kérdésem lenne, hogy 16 lábas a kijelző az utolsó 2 az anód és a katód, viszont az oldalon is van két kivezetés amire A2 és K2 van írva, most azt is be kéne kötni?

Nem kell külön bekötni.

Az előző kérdésem semmis, 1,5 VEE mellett tökéletes képet kapok.

Köszönöm a segítséget működik tökéletesen!

A mondat első felén nem lepődtem meg, mert a G Launchpad "hivatalból" nem kezeli az MSP430f5529-est. A fordítottja viszont nekem működik. most próbáltam ki: CCS 6 alatt az MSP430f5529 Launchpad nekem programozza és debug-olja az MSP430G2553-at.

IAR-al próbáltam és nem ment az f5529-es LP-vel a G2xxx programozása. Ha jól emlékszem, egy g2231-est szerettem volna programozni.
Menet közben megoldódott az e430-Chronos problémám. Az IAR-ban a "linker" beállításnál kellett variálni és már működött is.
A "wireless update" viszont nem működik, bár a "fehér RF" kártyával senkinek nem működik, de ez engem sajna nem vigasztal. Találtam egy kis leírást a Ti-nél, hogy a "FET-Pro430"-al lehet frissíteni az RF kártyát, ami sikerült is, de az óra a frissítés előtt, újraindul.

Ja! A G Launchpad kártyával programozom a Chronos-t, és a Chronos programozójával lehet a G sorozatot programozni.

Helló!

Annyi problémám lenne még a kijelzővel, hogy a lábakat átkötöttem a P2es portra P2.0-P2.3 D4-D7 és az E a P2.4 és az RS a P2.5 a program felső részében átírtam a portoknak a számát és a writenál ((val&0xF0)>>4) és ((val&0x0F), itt megcseréltem az alsó és felső tartományt.

Az lcd megjeleníti a szöveget és jó is, csak ha resetet nyomok, akkor valami hülyeséget ír ki, ha pedig még egyszer megnyomom, akkor már jól írja ki és ez így megy, egyszer jó, egyszer nem és nem tudom, hogy mi lehet a gond.

Sziasztok!

Megjött a 430BOOST-SHARP96 kijelző, amit akciósan lehetett kapni. Az a gondom, hogy a fényképeken fehér alapon fekete a kijelzés, de a valóságban fehér alapon ezüst. Ez így normális? Más is rendelt esetleg ebből a kijelzőből?

Nekem is pont ez a kisebbik gondom vele (tegnap jött meg). Igen, fényképen jobban mutat...

A nagyobbik bajom meg az volt, hogy kevés szoftver van hozzá. Végül itt találtam hozzá szoftvert (Energia könyvtár). Igaz, csak szöveges módban jelez ki, de az MSP430G2553-tól nem is várok többet, s egy nagyobb RAM-mal rendelkező kártyán majd tovább lehet lépni.

Amint a képeken látható, megvilágítástól és nézőponttól függően változó a kontraszt. (Az első két kép vakuval készült, a harmadik vaku nélkül)

A szoftveres hiányosságok pótolhatóak, de az hogy alig látom ami a kijelzőn van, az nagyobb baj és nem tudom hogyan lehetne javítani a helyzeten. A gyári demo nekem úgy tűnt, hogy grafikus módban hajtja a kijelzőt, rajzol vonalakat, négyzetet, kört stb. és a MSP430G2553 procin megy. A függvénykönyvtárak letölthetőek a TI oldaláról. Még annyi, hogy nekem piros a panel, nem zöld.

Így van, én is azt fényképeztem. De a RAM hiánya miatt a flash memóriában állítja össze a képet, úgyhogy túl sokszor nem érdemes futtatni, mert a flash véges számú újraírást bír ki.

Én majd az 5529 Launchpad kártyán vagy a Tiva C Launchpad kártyákon szeretném használni. De valószínűleg nem a gyári grlib könyvtárral.

Sziasztok!

Korábban kinlódtam Ubuntu alatt az msp430 Launchpad kártyával, mert COM porton nem jött vissza adat.
Az Ubuntu fórumon se jutottunk semmire. Annak ellenére sokat szenvedtem, hogy tudtam visszatérek Debian-ra.
Így is lett, és a mellékletben lévő readme.md-ben szereplő utasításokkal 1,5s alatt megoldódott.

Kernel bug a bűnös.
Ugyanis ha nagyon friss kernelre is cserélünk akkor sincs benne a patch.
Azért raktam ide, hogy sok keresgéléstől és idő pocséklástól megfosszam a többieket
Debian 7 Wheezy : OK de mennie kell alatta is.

További szép napot...

Szia!

Bennem eddig fel sem merült, hogy gond lenne vele.
Debian Squeeze és Wheezy alól használtam /habár ezen a gépen nem a gyári kernel van fent/, nem volt gond - Win alatt is panaszkodtak, hogy nem túl jól használható ez a soros port, nekem csak annyi tűnt fel, hogy csatlakozás után célszerű 10-20 másodpercet várni, utána mindkettő (a soros port és maga a Launchpad elérése is) jól működik.

Remélem, ez a kernel bug el fog kerülni.

Sziasztok!

LEnne egy kérdesem , kicsit megakadtam a házi játékszerem fejlesztésében.
szereztem egy 3.2"-s kijelzőt és azt próbálom vezérelni, a kijelzés megy nagyon jol raltive gyors is 2Hz körül (msp430tol nem is olyan rossz), de a touch interface az nem akar életre kelni, ha valaki esetleg használt már touch felületet az megirhatná nekem hogy miképpen menene.

Köszönettel Balázs

Az MSP530G2 Launchpad USB-soros kommunikációja valakinek működik Linux alatt? Nálam most OpenWRT van kéznél (TP-Link WR703N zsebrouteren fut!). Itt csatlakoztatásnál megjelenik egy /dev/ttyACM0 eszköz, az 'stty -F /dev/ttyACM0 speed' parancsra azt mondja, hogy 9600, de 'cat /dev/ttyACM0' parancsra se kép, se hang... Windows alatt természetesen működik.

Az MSP430F5529 Launchpad kártya esetén más a helyzet, mert itt két, vagy három eszköz jelenik meg.
/dev/ttyACM0 az EZ-FET csatornája, ezt nem érdemes matatni
/dev/ttyACM1 az EZ-FET által biztosított USB-UART protokol konverter, ez működik (*)
/dev/ttyACM2 akkor jelenik meg, ha az MSP430 saját USB csatornáját a firmware USB CDC eszközként használja. Ez is működni látszik.

(*) A működés kb. 16 óra folyamatos üzem után valamiért elakad. Nincs pedig sok bízva rá, bizonyos időközönként ki kellene nyomni két számot.

Csak érdekesség képpen: PIC18F4550 USB CDC eszköznek felprogramozva szintén /dev/ttyACM0 néven jelenik meg, s egyelőre működni látszik...

A "professzionálisabb" USB-UART átalakítók saját drivert (kernel modult) igényelnek, s /dev/ttyUSB0 néven jelennek meg. Ilyen a SiLAB CP2102, a Prolific PL2303HX és az FTDI FT232

Helló!
Nálam (archlinux) ugyanúgy mejelenik, ha rákötöm az usb-re a /dev/ttyACM0 eszköz.
Rev.1.5 Launchpad, 2553-as mikrovezérlő.
Energiával felprogramozom az Examples - 1 Basics - AnalogReadSerial mintát.
Ezt csak szoftveres UART módra jumperelve tudom megtenni!
Viszont így a soros porton nem látszik semmi.
Usb-ről lehúz, átjumperel hardveres UART-ra, ezek után megy a serial kommunikáció:
'cat /dev/ttyACM0'
'screen /dev/ttyACM0 9600'
'minicom -b 9600 -D /dev/ttyACM0'
vagy akár az energiával is!

Nekem működött rendesen a soros kommunikáció Linux (Debian) alatt.
A cat paranccsal is bejöttek az adatok, de szívesebben használom hozzá a screen programot - így kétirányú kommunikációm van, és a program indításával együtt paraméterezhető a baud rate és egyéb részletek is.

Nem volt vele semmi gondom, bár hosszú ideig nem üzemeltettem egyhuzamban.

Köszönöm a visszajelzéseket. Az internetes keresgélésből úgy tűnik, hogy a Linux-szal ellentétben az OpenWRT esetében senkinek sem sikerült Kernel modul patkolás és újrfordítás nélkül kommunikálni az MSP430-G2 Launchpaddal. Én végül is egy PL2303 mellett kötöttem ki, s a Launchpad helyett egy próbapanelon összedobott MSP430G2452 alapú alapkapcsolást használok (van egy 3,3 V-os stabilizátor, s a Reset láb fel van húzva egy 22 kOhm-os ellenállással. A mikrovezérlő egy DHT22 szenzor segítségével hőmérsékletet és relatív páratartalmat mér.

Az Energia projekt a TRHlogger.ino állományban található.
A TP-Link WR703N eszköz a ThingSpeak.lua bugyuta program segítségével fogadja az adatokat és továbbítja a ThingSpeak szervernek. Az eredmény ezen a címen látható.

A ThingSpeak.lua program listája:

Sziasztok!

Új vagyok ebben a topicban, és a segítségeteket szeretném kérni. Csináltam egy keresést tiemrekkel kapcsolatban, de nem találtam még ehhez hasonlót, amire nekem lenn szükségem.

Egy kétfásizú LLC konverthez szeretnék vezérlést készíteni MSP430 segítségével, mivel a CMOS kapukból felépített vezérlésem nem vált be.
A vezérlőnek létre kell hoznia összesen négy jelet, amelyek párosával komplementerk bizonyos holtidővel. Szóval például A 10 us periódus 4,5us kitölés B jel ugyanez csak 5us-el eltolval.
A két pár között 90 fok fáziskésésnek kell lennie, tehát modnjuk alapesetben 2.5us.

Addig eljtutottam, hogy nekem szükségem van 2 darab Timerre 3 db CC regiszterrel. A két Timer szépen elindul, és szolgáltatja a komplementer jeleket. TAxCCRy regisztereket beállítotam, majd TAxCCTL1= OUTMOD_2 és TAxCCTL2 = OUTMOD6.
Azt is meg tudtam oldani, hogy a második Timer elindítása előtt annak TAR regiszterébe egy számot írva bizonyos lépéssel késleltessem azt. Így a két egymástól 90 fokban eltolt vezérlő jel elindul.

A probléma ott kezdődik, hogy nekem frekvenciamodulálnom kellene, tehát variálni a periódust, a holtidőd. Ez eddig oké, átírom a CC regisztereket. Az első probléma az, hogy a family leíársa írja, hogy a Timerek CC regisztereit nem célszerű futás közben írni, mert galiba lehet. Szkópon én láttam galibát, de milyen galiba történhet ekkor?
A nagy probléma ott van, hogy a két timernek egymásl fix 90 fok késésben kell lennie, nem fix lépésnek.

Több lehetőségen gondolkodtam:
- egyik opció az volt, hogy TA0-nál toggle/set toggle/reset módokat alkalmazok, de a másiknál set/reset reset/set. Ezzel létrejön mindig a 90 eltérés, de így csak pont 50% kitöltésű jelet állítható elő, mivel set/reset módnál minimum 50%, reset/set módnál pedig maximum 50% kitöltés érhető el.

- a másik opcióaz, hogy írok egy algoritmust, ami tologatja timert.
Elsőnek próbaképpen beadtam a TA0R++ parancsot, ami megleépő módon tolta a Timert. Mivel ezt sehol nem láttam, és gondolom ettől is lehet galib (pont átlép egy CC regiszttert, mert a Timer főórához képesti aszinkron működése miatt kettőt lép egy ciklus alatt), megkérdeznélek titeket, hogy alkalmazható -e ez?
MÁsik lehetőség az, hogy a Timert egy pillanatra leállítom azzal, hogy MC-3-ról MC0-ra váltok, majd vissza. Ennek az előnye az, hogy amikor megállítom akkor gyorsan átírom a CC regisztereket, majd az új frekire a két timer újraindítási ütemézésvel 90 fok késésbe nyomatom a timereket. Persze ha a CC futás közbni írása nem okoz galib, akkor elég csak az egyik timernek pauset inteni.

Remélem érthető volt a problémám, és ti tudtok tanácsot adni, hogy ezt hogyan oldjam meg.

Bocs, hogy a mikrokontrolleres fórumban pont ellene dolgozom
Kiváncsiságból elgondolkoztam, hogy lehetne megoldani mikrokontroller nélkül.
Ha megelégszel 40/60 kitöltési tényezővel (a példádban 4,5/5,5 mikrosec volt), akkor egy darab 4017 és egy darab 4043, ami neked kell. 4 darab RS flip-flop, amiknek az R és S lábait a 10-es számláló megfelelő lábaira kötöd. Kell egy külső órajel és reset jel a 4017-hez.
Ha a 4 kimeneti jel A, B, -A, -B resetkor 0-ra kell álljon, akkor kell még 8 dióda is, mert az SR flip-flopok reset lábaihoz oda kell vezetni a külső reset jelet is.
Még egyszer bocs az offtopicért...

A menetközbeni frissítéssel az a probléma, hogy ha lekésed pl. a reset eseményt, akkor egy teljes periódusra bekapcsolódik a kimenet (a "lélegző LED" esetáben a nulla körüli fényerőnél pl. zavaró felvillanások keletkeznek, de egy H-híd vezérlésénél ennél nagyobb tragédiát is lehetnek...). A nagyobb MSP430 vezérlőkben van Timer_B tipusú időzítő is, annál kettős buffereléssel megoldódik ez a probléma, mert hardveresen szinkronizálva kerül sor a tényleges beírásra. Az MSP430F5529, vagy az FR5*** sorozatú mikrovezérlőknél van ilyen periféria.

A frekvenciamodulációnál nem egyszerűbb, ha a bemenő jel frekvenciáját változtatod meg? A DCO oszcillátor is hangolható, de esetleg egy Timer is feláldozható (az Output Compare kimenet frekvenciája hangolható a CCR regiszter tartalmának módosításával), hogy változó frekvenciájú jelet adjon a PWM vezérlésre használt másik Timer bemenetére. Csak egy dróttal össze kell kötni az első Timer kimenetét a másik Timer bemenetével...

Az előbi vezérlés egy 4046-os VCO-t használt, utána pedig egy 4018 frekvenciosztót. Ez képes volt előállítani a jelet, azonban sok baja volt:
- mivel a a végén kb 50-300kHz közötti jel kell, ezért gyors CMOS-t kell használni (300kHz-hez 1.2MHz kell), ami mivel gyors baromira érzékeny a zajra. Kétoldalas náyk, mindkét oldalt teliföld kellett a stabil működéshez
- a holtidő beállítás problémás volt. Azt találtam ki, hogy a CMOS után egy RCD tag állítja be a holtidőt (után schmidt-trigger bemenetű gate meghajtó jött). A prolbéma az volt, hogy a CMOS kimeneti impedanciája szór, ezért minden egyes áramkört trimmelni kellene. Kettő az volt, hogy jó lenne állítható holtdiő a frekvencia függvényében. A haramdik az, hogy a gate meghajtó drága.

Az MCU elvielg tudná a a variálható holtidőt, és az MCU után tudok alkalmazni két bipoláris tranzisztorral push-pull gate meghajtást, ami jóval olcsóbb a gate meghajtó IC-nél, és így az MCU plusz árát visszafogja. Szumma az ár kb ugyanannyi, és a nyákigény fele. Plusz a zajérzékenység jelentősen csökken.

Szóval már most ott tartok, hogy MCU-val több előnye lenne, mint CMOS kapukkal.

Ez egy jó ötlet, elgondolkodom rajta. Mivel így maradhat a fix modnjuk 20 taktusnyi késés, az mindig ugyanannyi fázist fog jelenteni. És mivel nagy időfelbontás a holtidőben úgyis nagy frekvenciáknál kell.


Csak így már három Timer kell, ami G szériánál cak a 2755-2955 meg társainál van. Bár ott van Timer B is, ahogy nézem.

Olyat ötletem is támadt, hogy mi lenne, ha futna egy Timer, ez előálíltja a két komplementer jelet holtidővel. Nem lehet olyat csinálni, hogy egy második timer nem csinál mást, csak a timerben adott takusok számával az előbbi jelet eltolja?

A DCO oszcillátor hangolása a szkópos méréseim alapján nagyon jól működik. Kiszámoltam úgy, hogy a 16MHz-re legyen mondjuk 200kHz max freki, és ez egészen lemegy 100kHz-ig, úgy hogy közben a DCO 8 MHz-re lemegy.
Figyelni kelett a arra, hogy a DCO-nál a DCOx értékek ugrása után RSELx-t is változtatni kell, de átfedés van a tartományok között. De ezt megoldottam, így:



Első lépés kipipálva a 90 +/-5 fok fáziskülönbség végig megvan a szépen. Most már csak annyi a szépséghiba, hogy a frekvencia cöskkenésével így nő a holtidő. De nekem pont fordítva kellene, így lényegében továbbra is módosítani kell a capture/compare regisztereket.

Arra gondoltam, hogy ezeket úgy célszerű módosítani, hogy amikor a CCR0 kimenete pont vált az up/down módban. Erre beállítható egy megszakítás, és ekkor biztonságosan átírhatók úgy a regiszterek, hogy a compare esemény még elég távol van, így biztos nem történik gebasz.
Létrehozok szerintem egy váltotót aminek lesz három értéke.
A megszakítási eseménynél megnézem a változó értékét, és amennyiben 0, úgy nem csinál semmit. Amennyiben 1, úgy növeli a holtidőt, amennyiben meg 2 úgy csökkenti a holtidőt.
Ehhez az ötlethez mit szóltok?

Amúgy kísérleteztem a két timer leállításával és megállíátásával a timerek tologatására, és a 90 fok szinkron megtartására, de ez nem járt sikerrel. Megbízhatatlan volt, nem volt visszafigyelhető.

Ellneben a DCO módosítás mindig garantálj a 90 fok csúszást, ha egyszer a timert úgy indítom el. A holtdiő variálása meg nem járhat szerintem nagy bajjal, ha így oldom meg.