Sziasztok!

Egy nem teljesen MSP-s problémával fordulnék hozzátok.
Adott egy ANSI kódolású txt file melyben ékezetes karakterek is vannak. Processingben írtam egy programot ami soronként beolvassa a txt file tartalmát, megjeleníti a sz.gép képernyőjén, és elküldi UART-on egy g2553-nak. Egyenlőre odáig jutottam, hogy a behívott szöveget megjelenítsem a képernyőn, de sajnos valamiért az ékezetes karaktereket nem akarja megjeleníteni. Igazából szerintem be sem olvassa. Ezért azt már meg se próbáltam, hogy elküldjem az adatokat a mikrovezérlőnek.
Hogy tudnám beolvasni az ékezetes karaktereket?
A fájlt a "loadStrings" parancsal olvasom be, a sorokat pedig "string tömbe" tárolom.

Ezekszerint rosszul fogalmaztam. A hiba nem az UART küldésben van, hanem a processing programban.
A processing programom egy txt fájlból olvas be sorokat, de az ékezetes karaktereket nem hajlandó beolvasni.

Ezen a fórumon is erről panaszkodott valaki. A válasz az, hogy a Processing / Java az UTF-8 kódolást "érti".

Talán ezek között találsz rá megoldást.

Köszönöm!

Sziasztok.

Ma megjött az F5529-es LaunchPad-em. /Azért érdekes, hogy a készlethiány ellenére megkaptam./ Egy kis problémám van a kártyával. Szerintem a TI-nek sikerült a világ legrövidebb USB kábelét párosítani ehhez a fejlesztőeszközhöz. A két dugót leszámítva, mindössze 19,7cm hosszú USB kábelt kaptam. (Lehet, hogy a raktárhiány a kábelre vonatkozik, és nem a LP-re?)

Szia!

Szerintem ezekhez ilyen kábel "jár" - a Stellaris launchpad kábele is ugyanekkora.
Az enyém tegnap érkezett meg.

Egyébként a szoftverfelhozatallal nem vagyok kibékülve - igaz, én Linux alól használnám.
Hiába van külön letölthető Linuxos "installer" is, pontosan ugyanazt csinálja, mint a Windowsos - ez alatt azt értem, hogy pontosan ugyanazokat is csomagolja ki - szinte csak Windowsos cuccokat (akkor meg minek)? Egyébként is, elég lett volna szimplán betömöríteni...

Egyedüli Linux alól (elvileg) működő firmware frissítési lehetőség ez a bizonyos Python kód. Ezt meg is próbáltam Linux alatt - látta az eszközt, el is kezdte a program betöltését (BSL módban), kinullázta az alap programot, majd hibával leállt. Grat.
Ugyanezt megpróbáltam Windows alatt is (habár ez egy virtuális gépen történt) - ez egy .exe kiterjesztésű file -, ugyanezzel a hibával állt le, gyakorlatilag tökéletesen ugyanúgy nem működött (XP alatt).

Van egy másik program is, mellette egy .bat file-lal, azzal még nem próbálkoztam.

...hát, mit is mondjak... jelen állapotában ez így eléggé "sovánka"...

Ma még nem foglalkoztam vele, de eléggé elment a kedvem tőle tegnap...

Neked sikerült működésre bírnod a BSL-t? Az ezFET-ről még nem is álmodom...
...pedig izgalmas dolognak tűnt ez az USB felületen történő programbetöltés/frissítés...

Még nem próbáltam. Nemrég hozta meg a futár.
Már tegnap megkaptam volna, csak a TI elfelejtette ráírni a telefonszámom a csomagolásra, és mivel nem voltam itthon a futár nem merte a szokott módon kézbesíteni. A "szokott mód" nálam ha nem vagyok itthon, a futár aláírja, és bedobja az udvarba. Ha túl nagyot dob, mire hazaérek a kutya szétrágja a dobozt.

Most végre sikerült életre keltenem az hw i2c kommunikációt egy g2553-on majdnem egy heti sz..kodás után. Igaz nem polling módban, hanem megszakításban. Sajnos még mindig nem sikerült rájönnöm, hogy mitől nem megy megszakítás nélkül az i2c. Pedig egy-két projektemben "tökéletesen", amiben már kételkedem, hogy tökéletes, működik.

Kíváncsi leszek, mire jutsz majd vele - főként a BLS-lel...

Egyébként az én I2C rutinom is megszakítást használ fogadáshoz, küldésnél viszont nem használok megszakítást.

Azzal az eszközzel amivel most kísérletezem, nekem már a küldés is csak megszakításból megy. De csak a 2xx3-as sorozattal. A 2xx2-es i2c rutinommal szépen működik.
Írtam Energiáben egy kis programot a beépített i2c rutinnal, és azzal sincs gond. Bár az is megszakítást használ.

Előkereshetem a sajátom, ha érdekel - ezt 430G2553-mal használtam, ezidáig gond nélkül.

Feldobhatod, bár nem hinném, hogy túl nagy különbség lenne a többi hasonló progihoz képest. Én szóról-szóra úgy csináltam, ahogy a FUG írja, de ennek ellenére nem működik.

A kértyára épített EZ-FET mellett nemigen lesz rá szükség. Az EZ-FET egyébként nemcsak programozásra való, hanem hardveres nyomkövetésre/hibavadászatra.

Az úl Launchpad érdekessége, hogy egy USB HUB-ot is tartalmaz, így egyetlen kábelen mehet a target áramkör és a FET USB kommunkikációja, sőt, az EZ-FET által biztosított nagysebességű USB-UART kommunikáció is. Az azonban ráfaragás, hogy a kártya tápfeszültségeit is a HUB menedzseli, s nem ad addig tápfeszt a többi áramkörnek, amíg a HUB és a PC között le nem zajlott az enumeráció. Így a kártya csak PC-hez csatlakoztatható, az ún. USB töltőkről nem fog működni.

A rémhírek szerint a CCS új változatában a memőriakorlátos fordító mellett lesz egy ingyenes (és korlátozásmentes) GCC fordító is (gondolom, ugyanaz, ami az Energiában is benne van). Nem lenne rossz, ha ez a GCC-ben debuggolással együtt működne...

Természetesen nagy különbség nem igazán lehet közöttük.
Egyébként korábban már feltettem ide.

Ez nálam tökéletesen működött ezidáig.

Megjelent az Energia újabb kiadása! Bővebben: Link
Ebben már támogatott az új MSP430F5529 USB LaunchPad kártya is, bár ezzel vannak még gondok. Az MSP430F5529 teljes memóriájának kihasználáshoz ugyanis 20 bites címzést kell használni. Ezt még nem tudja kezelni az Energia, tehát egyelőre csak a a 16 bites címzéssel elérhető 64 kbyte elérésére van lehetőség.

Természetesen az alapvető programozásnak (meg persze debug és hasonlóknak) az EZ-FET-en keresztül kellene mennie, bár ehhez még jó volna, ha előkerülne valami Linux alatt is működő megoldás - addig nekem nem ér annyit, hogy Windowst telepítsek az elsődleges gépemre (nem központi kérdés ez jelenleg).

A BSL-en azért csillant fel a szemem, mert egyfelől alapvetően nem az 5529-es launchpaden jár az eszem (az fejlesztésre és tesztelésre jó természetesen), hanem olyan, vagy ahhoz hasonló MCU-val saját áramkör létrehozásán, ott viszont nincs mellette az EZ-FET. Persze spy-bi-wire és a launchpad segítségével fel tudom azt is programozni, az USB felületnek viszont meg lehet az az előnye, hogy viszonylag egyszerűvé válik egy adott eszközre utólag szoftverfrissítést feltenni (programozó nélkül), esetleg egy másik rendszer részeként egyszerűen megoldható lenne afféle "in-system programming" megoldással utólag javítani a rajt futó kódon... Jó lenne akár ARM-os eszközről is felprogramozhatóvá tenni...

Az USB HUB jó ötlet rajt (nem kell külön kiépíteni a programozónak és a programozott MCU-nak is egy USB csatlakozót - és dugdosni a panelon), ez tetszik.
Erről a tápproblémáról olvastam, hogy panaszkodtak már néhányan és javítást kérnének emiatt...

A GCC fordító jó hír, már csak azért is, mert Linux alatt azt használom - talán kevesebb problémám lesz így vele... bár eddig is az eszköz elérése volt alapvetően problémás...

Egy kis érdekesség (részemről).

Tehát a Processing karakter kódolásával volt egy kis problémám. Icserny fórumtársunk válasza alapján egy kis kutatásba kezdtem e-téren. A Java "minták" alapján elkezdtem kiegészíteni a kódomat, de az ékezetes karaktereket nem sikerült megjeleníteni.
Mivel a txt fájlból behívott adatokat én szerkesztettem, jegyzettömbben, ezért egy egyszerű próba ként a teljes fájl tartalmát átkódoltam UTF-8-ba. Az átkódoláskor az ékezetes karakterek helyén "?" jelentek meg, amiket átírtam az eredeti ékezetes karakterre. Ezután ismét beolvastam Processingben a txt fájlt, ami már UTF-8 kódolású volt, és láss csodát, megjelentek az ékezetes karakterek, mindenféle plusz programozás nélkül.
Tehát a lényeg, hogy csak a fájl kódolását kellet megváltoztatni.
Bár még rengeteg dolgot nem értek a témával kapcsolatban, de a lényeg, hogy működik.

Sziasztok!

Valaki értelmezné nekem ezt a rajzot Bővebben: Link A kapcsolás egy ledes óra lenne, instructables oldalon találtam. Tisztába vagyok a multiplexelésel ezért sem értem a kapcsolási rajzot, konkrétan a digitek kapcsolgatása illetve hogy mit jelent az a K K felirat. Én úgy vélem hogy elírás lehet...

A kapcsolást megépíttem úgy hogy a C seg. kihagytam és helyette a digitekre kötöttem, egyébként a nyomógombos résszel nincs gond


Cikk: Bővebben: Link

Köszönöm,előre is.

Nos, ez egy érdekes rajz az biztos. A kijelző közös katódos, de az a "KK" jelzés valamelyik két szegmenst jelölné és nyilván a tranyós mókolás a katód meghajtásához van. Ezt igencsak elnézhették, lealábbis a rajz közlést. Vagyis nincs más megoldás mint kisakkozni a progiból - ha van külön - a bekötést. Amennyiben nincs akkor lehet tippelgetni.

Ha kell még help, csak "keress" nyugodtan.......

A digiteken lévő feliratozás hibás.

A c szegmensként jelölt kivezetés lesz a GND, meg gondolom, a P-vel jelölt is az.

A többi kivezetés pedig a hét szegmens + decimális pont, valamilyen sorrendben...
Tehát a két k-is egy-egy szegmens lesz a 7+1 közül.

Nem tudom, mennyire tér el a hétszegmenses kijelzők bekötése, de talán ez referenciának jó lehet. (Nálad a GND lesz a common a rajz alapján.)

Sziasztok,
nagyon érdekelne a mikróvezérlők világa és szeretném én is megtanulni a programozását, használatát. Megtudnátok mondani, merre induljak? Az eddig olvasottakból még nem tudtam eldönteni, hogy Arduino vagy TI Ins. (MSP) felé. Amit tudnom kéne majd: motorok vezérlése (max 12 V), LCD (nem grafikus) és egy pár érzékelő használata. Segítenétek elindulni?

MSP430 LaunchPad:
16 bit, 16MHz, 16KB prog. memória, 512 bájt ram, 8 digit I/O, 8 analog I/O.
Arduino UNO Atmega328:
8 bit, 16MHz, 32KB prog. mem., 2KB ram, 14 digit I/O, 6 Analog I/O.
MSP LaunchPad ~$10.
Arduino UNO ~$30, ~$10-20 a Kínai "klón". (De Kínait nem biztos, hogy érdemes megvenni!)
MSP430g2553 ~500Ft
Atmega328P ~1000Ft

Köszönöm szépen VaZso8 és röntgen segítségét, működik.

Sziasztok.

Nem foglalkoztam még vele, és nincs kedvem kísérletezni/tönkretenni az alkatrészeket, ezért inkább kérdezek.
Adott két egyforma SPI buszos LCD kijelző. Meg lehet azt csinálni, hogy pl. inicializálásnál mindkét LCD "chip select" lábát engedélyezem? Tehát, egyszerre inicializálja a két LCD-t. Vagy mikor mindkét LCD-nek ugyanazt a bájtot kell küldeni, akkor egyszerre küldjem ki?
Hardveres SPI, g2553.

Ha az adatvonal csak az egyik irányba van bekötve (SIMO vagy MOSI, tehát az MCU kimenő vonala), akkor természetesen igen. Akkor lenne csak gond, ha visszafele irányba egyszerre kezdene válaszolni a két LCD...

Köszönöm.
Természetesen az LCD részéről nincs küldés, csak fogadás.
Így legalább jelentősen felgyorsul a programom.

Én már csináltam 2 db 3310 -el működik.
Inicializáláskor mindkettőnek engedélyezem a CS-t és egyszerre inicializálom. Utána mindkettőnek és külön-külön is küldöm az adatokat attól függően melyikre mit akarok írni.

Siemens telefon színes kijelzőket szeretnék meghajtani, és rengeteg infó van, ami mind a két kijelzőn meg kell, hogy jelenjen.
Első körben külön-külön küldtem az infót, de rengeteg időt vesz igénybe, és az sem tetszett, hogy egymás után jelentek meg az adatok.
Holnap kipróbálom egyszerre kezelni őket.

Sziasztok.

Hardveres 9 bites SPI-t szeretnék megvalósítani egy g2553-al.
Az elképzelésem:
1: kikapcsolom a P1SEL,SEL2-őt
2: BIT7 (MOSI) magas vagy alacsony
3: BIT5 (SPI CLK) magas
4: 1uS várakozás
5: BIT5 (SPI CLK) alacsony
6: P1SEL,SEL2 visszakapcsolás
7: HW 8 bit SPI ....

Ez így működhet? Esetleg még a portok aktuális állapotát lementeném.

Ha ez megnyugtat, van, aki hasonlóan csinálta. Bővebben: Link

Á, ezt még nem láttam (igaz ilyen irányú keresést még nem végeztem). Köszi.
Nekem is nokia lcd-hez kell, csak a típusa más. Menet közben kipróbáltam, és jól működik.