Én ugyanezzel a kijelzővel úgy jártam el, hogy hardveres SPI-kezeléssel, két byte-ban küldöm el az adatokat. Tökéletesen, gyorsan és hibátlanul működik.

Egyébként ha jól emlékszem, itt is megírtam anno.

Amúgy a fent alkalmazott trükk előtt érdemes szerintem megnézni, miként reagál az eszköz a következő két megoldásra:
- mindegy, mit küldök, de az utolsó kilenc bit a helyén legyen (afféle shift-regiszter-szerű kezelés)
- az első kilenc bit a helyén legyen, a többi lényegtelen

Az STE2007-nél az utóbbi működött, mivel az adatlapja szerint a nem teljes bitsorozatot egyszerűen eldobja (és valóban).

Én úgy vélem, ez jobb megoldás a bitzsonglőrös bűvészkedésnél.
(Elmenti a portállapotokat /3 byte/, letiltja az SPI-t, birizgálja a biteket, engedélyezi az SPI-t, visszatölti az állapotokat, elküldi a maradék 8-bitet SPI-on és visszatér... ha van más mód, én ezt inkább kerülném.)

Én egy PCF8833-as (phillips) meghajtóval rendelkező LCD-vel kísérletezem. Ennél a "9. bit"-el döntöm el, hogy adatot vagy parancsot fogok küldeni.
Az első kísérleteimben én is két bájtban szerettem volna elküldeni az adatokat, ahogy Te is írtad, "az első kilenc bit a helyén legyen" módban, de a kijelző meg e nyikkant. Ezért inkább maradtam a P1SEL ki-bekapcsolós módszernél. Egyébként az SPI-t nem kapcsolgatom ki-be, és a port állapotot sem mentem el. Egyszerűen, csak az adott kimenetek funkcióját változtatom meg:

G2553-nál mekkora a legnagyobb beállítható szabványos UART baud rate 16MHz-en? A FUG szerint 460800. Ez lehetséges? Ha igen, egy CP2102-en, hogy tudom beállítani ezt a sebességet? A Windows csak 230400-ig engedi.

Valószínűleg a CP2102-höz telepített driver szabja meg a beállítható maximális értéket. Nálam pl. többet is megenged. Az egy másik kérdés, hogy az USB-UART protokol konverter figyelembe veszi-e a beállítást, vagy sem. Például a Microchip mintaprogramja egyszerűen figyelmen kívül hagyja a 115200 fölötti értékeket.

Egyszerűen nem bírom beállítani a CP2102-t nagyobb sebességre. Már letöltöttem a gyártó honlapáról a legfrissebb drivert és a "CP210x AN721" programot, de azzal sem bírom feljebb vinni. A 2553-as megy 460800-as sebességen. Ellenőriztem logikai analizátorral is.

Üdv!

Lenne egy rövidke kérdésem. Lehet a kontroller lábait belsőleg hidalni? Úgy értem hogy például kap valamilyen jelet (digitális) a P1_0-án és ugyan ezt adja ki -lehetőleg minél kisebb késleltetéssel a P1_2-n? Viszont ha szükséges akkor ezt meg lehessen bontani a programban, és módosítani (korrigálni) a kimenő jelet? Gyro stabilizátorhoz kellene.

Tudtommal nem lehet. Esetleg az analóg komparátor be- és kimenetét lehet felhasználni ilyen perverz célra, de nézd meg a sebességét az adatlapban!

Nem tudom, pontosan mit szeretne a kérdező, de esetleg adott lábra beállít egy-egy interrupt-ot, megírja hozzá a rutint és abból kapcsol egy másik kimenetet, ill. ha mégsem másolni szeretne, hanem beavatkozni, akkor megteszi... ha mást nem...

UART-on fogadok egy stringet amit egy tömbben tárolok. Szeretném ezt a stringet egy LCD-re kiíratni karakterenként. Eddig nincs is semmi problémám. A problémám az "strlen" függvénnyel van.
Elméletileg a fogadott string végén a '\0' szerepel és a strlen eddig számol, de valamiért nem akar működni nekem ez a számlálás:


Hogy tudnám ezt a kiíratást megoldani?

Az strlen nem számítja be a záró nulla kódot. Az nem értem, hogy az i változót miért 5-tel növeled?

Tudom, hogy nem számolja bele a záró nullát, odáig számol, de nekem eleve meg sem számolta a tömbben lévő karaktereket.
Úgy nézem, hogy a hiba a tömb definiálásánál van, ugyanis "uint8_t" -nek definiáltam, és az strlen csak "char"-ként tudja megszámolni.

Mert nem figyeltem oda.
Mivel karakterenként íratom ki a szöveget, ezért minden karakter után 5 helyett 6 pixellel arrébb kell rakni a "kurzort", csak eredetileg a "i" változó a tömb helyérték meghatározására szolgált. Most e-célból beraktam még egy változót. De így nem tetszik...

A cél az lenne hogy van egy távirányítású hajóm. (MSP vezérlésű vevő, adó) Normál modban egy az egyben át kellene ereszteni a bejövő PPM jelet a szervóra, de ha átkapcsolok, akkor a kontrollerre kötött gyorsulásmérővel korrigálja a hajó billegését (mechanikailag meg van oldva a dolog). Csak ilyenkor a bejövő jelet kellene korrigálni a gyorsulási adatokkal.

Nem tudom, vajon mennyire elég a feldolgozási sebesség hozzá - elsősorban a korrigált adatok generálására gondolok /ha jól sejtem, elég sokat kellene számolnod hozzá/; bár azt sem tudom, milyen gyors jelekről van itt egyáltalán szó... esetleg két kontrollerrel?

Hmm, érdekes ez a dolog.

A sebesség még csak-csak elég lenne, de a gyorsulásmérős dolog nem fog működni. Legalábbis önmagában egy gyorsulásmérővel.

Ezen már én is agyaltam, lehet hogy kellene mellé egy gyro szenzor is, hogy érzékelje az aktuális pozíciót.

Már így is több kontroller teszi a dolgát, különböző részekre bontva funkció szerint, tehát plusz egy már nem lenne gond.

Nem lehet, hanem biztos. Csak gondolj bele, hogy mit fog csinálni az egy gyorsulásmérő. Röviden.....nem kiegyensúlyozza, hanem felborítja a hajót.
Olcsó, és egyszerű megoldás: MPU-6050. Accelero+gyro egyben.
Ha kell mintaalkalmazás, mely hasonló dolgot csinál, nézd át ezt.
A fájlok között megtalálod a forrásprogramokat is.

Meglepődnél ha azt mondanám sok az a $20? Egyébként van itthon gyrom, csak gondoltam hátha nem kell.

Tudom, hogy nem feltétlen megfelelő forrás, de itt pl. jócskán $20 alatt lehet maradni vele - cirka $3.13-ért elküldik, modulként kiépítve.

Ez nem is rossz. Lehet hogy rendelek egyet.

Egyáltalán nem lepődök meg. (a mai világban mi nem sok!?....)
De félreértettél. Én az MPU6050-re értettem, hogy olcsó megoldás (ebay ~$2-3=500-700Ft).
A linket csak a program miatt raktam be, hogy lásd, gyro nélkül nem fog menni.

Igen, értem. Ez így nem sok egy gyro-ért. A SparkFun-on $30-okért adják őket.

Sziasztok!

Adott egy tömb, melyben elmentek egy stringet. Ezt a stringet szeretném kiíratni LCD-re, de a kiíratás módjával akadt egy kis elméleti zavarom.
Tehát, tételezzük fel, hogy a string, ez a hozzászólásom. Ezt úgy szeretném kiíratni az LCD-re, hogy úgymond nyelvtanilag helyes legyen. Tehát a sor végéhez érve kezdjen új sort, és ne úgy kezdje az új sort, hogy pl. "kettévág" egy szót, hanem a szóköznél válasszon el.
Odáig elméletben eljutottam, hogy ugye adott az LCD szélessége és magassága, adott a betű mérete, tehát el tudom választani a sorokat egymástól.
Ez kb így nézne ki:
- megszámolom a string karaktereit az "strlen" függvénnyel
- elosztom az LCD szélességét a betű méretével, jelen esetben 132/6. (LCD 132x132 pixel)
- így 22 karaktert írhatok ki egy sorba.
A problémám az elválasztással van. Hogy keressem meg, melyik szóköz áll a legközelebb a 22. karakterhez?
Pl. így nem jó:
Hogy keressem meg, mel
yik
így kellene:
Hogy keressem meg,
melyik

Azt értem, hogy benne vannak a vezérlőkarakterek, de egy többen, hogy állapítsam meg, hogy melyik (0x20(szóköz)) van a legközelebb a 22. karakterhez?

Tehát a fenti tömbben szereplő string kiíratását, a "3". szóköz után, új sorba kellene kezdeni.

1. Ha a szöveg hossza < 23, akkor nem kell foglalkozni vele.
2. Ha a 23. karakter nem szóköz, akkor visszafelé lépkedsz, amíg szóközt nem találsz. Ez a "legközelebbi".
3. Ha visszalépkedésnél eljutottál a szöveg elejére, és nem volt szóköz, akkor muszáj megtörni a szöveget, mert nem fér ki. Pl. "Reformátuskovácsházáról"

Köszönöm.

Összeállítottam egy "kisebb" függvényt, de elakadtam annál a lehetőségnél, hogy mi van akkor ha több sorba kell írni, tehát a string (tömb tartalma) nagyobb mint két sor. A csatolt függvény csak egy sort figyel, és szerintem egy kicsit túlbonyolítottam.

Másik kérdésem: Ékezetes karakter, hogy tudok küldeni/fogadni UART-on? Processingben írtam egy teszt programot, és azzal szeretnék ékezetes karaktereket küldeni.

Az ékezetes karakter probléma megoldódott. Megint nem figyeltem oda, és kihagytam az LCD kiíró rutinból.


Beszkennelek egy X szöveget, a PC oldali programmal soronként behívom, és UART-on elküldöm az MSP430-nak, ami kiírja az LCD-re.
Lehet, hogy egyszerűbb lenne a szkennelt szöveget átszerkeszteni, de több oldalt sok idő. Ezért egyszerűbbnek látom, ha ezt a feladatot az MSP430-ra bízom. Csak arra nem gondoltam, hogy ennyire bonyolult lesz megírni ezt a "kis" rutint.

Ha megszakításban használom az UART-ot, és pl. az i2c-t, tehát az USCIx modult, akkor két külön megszakítási vektor kell? Vagy egy, és abba döntsem el, hogy melyik okozta a megszakítást?
Ha kettő kell, honnan tudja majd a program, hogy melyik vektor mihez tartozik?

Igen. Például az MSP430G2553 adatlapja szerint (Table 5. Interrupt Sources, Flags, and Vectors) az USCI_A0/USCI_B0 RX/USCI_B0 I2C status egy közös vektoron osztozik. Gondolom, az UCA0RXIFG és az UCB0RXIFG vizsgálatával kell eldönteni, hogy ki/mi okozta a megszakítást (az I2C státuszvizsgálathoz nem tudom, mit kell nézni). Hasonló a helyzet a USCI_A0/USCI_B0 transmit/USCI_B0 I2C receive/transmit vektorral is.

Köszönöm.

Készítettem két "könnyen" becsatolható állományt, UART és I2C-hez, és mindkét állomány megszakítást használ, a küldéshez és a fogadáshoz egyaránt. Viszont ha mindkét állomány kell egy programban, akkor már nem lehet külön-külön kezelni a megszakításokat, így nincs is értelme a két külön állománynak.

Még egy nemigazán idevágó kérdésem lenne.
Tesztelek egy X programot amiben soros kommunikáció van. Külső terminal ablakban figyelem az eseményeket, ami addig jól is működik amíg nem nyúlok hozzá a programhoz. Magyarul nem fordítom újra. Ezt követően a terminál ablak már nem tud kapcsolatot teremteni a soros portal. Kiírja, hogy a X port használatban van! Próbáltam "külső" USB UART" konverterrel, és csak a Launchpad-el is, de nem áll helyre a kapcsolat. A kérdés az lenne, hogy lehet a Windows-ban, újraindítás nélkül "resetelni" az adott soros portot? Ha újraindítom a gépet akkor minden helyreáll egészen a fent leírtakig. Próbáltam több programban is és az eredmény ugyanaz, tehát nem a kommunikációval van a hiba.