Ööö... ezt már értem, de nekem ezen (link) a panelon a két szélén van egy X és egy Y oszlop is, amik nem folytonosak, hanem 5-ös tömbökben vannak. Na ezeket nem vágom még, hogy mihez, hogyan vannak kötve.

Bocsánat, azt kihagytam.
Azok pedig oszlopként vannak összekötve.

Köszi, értem. Egyenlőre egy hőmérő lesz, aztén ha működik a monitorozás, lesz még minimum 3 db, ehhez kell majd a panel.

Értem! Akkor a sorok is mind külön-külön vannak, illetve az X és Y oszlop is, és nincs további összeköttetés közöttük, pl. X oszlop és 1. sor között, igaz?

Igaz.

No akkor képben is vagyok. Köszöntem a felvilágosítást!
A héten nekiesek megírni a progit 1 hőmérőre. Kérnék egy tippet, mielőtt elmerülök a guglizásban: mintaprojekteket te hol szoktál nézegetni? Van kedvenced, vagy legjobban használható oldalad?

Csak halkan mondom, hogy van külön topik a dugdosós próbapanelről és van elektronka kezdő témakör is. Ne offoljuk már tele ezt a topikot ilyenekkel!

Ami kell azt mind megtalálod itt. Ha elolvasod a cikkeket amit az MSP-ről írt icserny, meg szemezgetsz, Topi AVR cikkeiből akkor érdekes projekteket tudsz összehozni és meg is érted őket.

Ne haragudj, de gondoltam itt relatíve gyorsan megkérdezem amit nem tudok és utána már tudok vele dolgozni, és csak a témához szorosan kapcsolódó kérdéseket feltenni. Minden esetre igyekszem ezentúl nem OFF-olni.

Icserny cikkei nagyon jók, sokat okultam belőlük már, érthetőek, remekül összeszedve a lényeg.

Sziasztok.

Hardveres UART-on (g2553), hogy küldjek egy tizedesig hőmérsékletet?
Most így oldottam meg, de szerintem ez nem annyira jó:

Ebben a hozzászólásban található a decimális kiírató függvényem javított változata. A kiíratás szempontjából közömbös, hogyha az sw_uart_putc() függvényt lecseréled egy hw_uart_putc()-re.

Már néztem, köszi. De sajnos valamiért a Processing, bluetoothDesktop-os fogadás nem akarja elfogadni az érkező adatokat.

A másik gondom, hogyha az eeproból küldöm el az adatokat, akkor ott nem csak hőmérséklet adat van.
Pontosabban:
Az eepromba eltárolok egy napi (24 óra) hőmérséklet adatot, úgy, hogy 12 percenkét az aktuális hőmérséklet kerül mentésre, plusz a nap, óra, perc. Ezt a Processing btd. readBytes(buffer) -el tudom fogadni, de ebből a rengeteg adatból még ki kell "válogatni" az időre vonatkozó adatokat, és a hőmérséklet adatokat, és azt megjeleníthetővé kell tegyem.

Ha a PC oldalon még értelmezni is akarod az adatokat, akkor nem kerülhető el, hogy valamilyen egyszerű protokollt kitalálj, vagy egy meglevőt átvegyél. A végtelen adatfolyamban valahogy jelezni kell, hogy mi micsoda, vagy hogy hol van egy rekord eleje/vége.

Persze persze. Ezt nagyjából értem. Az eeproba (24lc512) eleve úgy mentem el az adatokat. Két "page" egy nap. (azért kettő, mert a hőmérséklet tizedes nélkül kerül bele, és sajna az már két byte.) Itt rögtön az elejére kerül a dátum, idő, és utána a hőmérséklet adatok.
Tehát, ha pl. 10 nap után kérem le az adatokat, akkor is tudni fogom/(fogja a PC), hogy minden 256. byte után, új nap kezdődik. Azthiszem!

Sziasztok!

Próbálkoznék 16 MHz-es órajel mellett I2C-n olvasni egy RTC-t (DS1306) és SPI-n írni a kijelzőre (Nokia 3310/5110).

Mindezt úgy, hogy mindkettő USCI B0 modulra van kötve.

Az egész működik is mindaddig, amíg 8 MHz vagy annál kisebb a DCO frekvencia.
16 MHz-en is sikerül kiíratni az adatokat, de a kiíratás nem stabil, szépen lassan teleírja a kijelzőt (mintha nem pontosan ugyanoda pozícionálná a karakereket).

Nem egészen értem, hogy tudnám beállítani az SPI kommunikáció órajelét, ugyanis látszólag ha variálni próbálok, "összeomlik" a rendszer, ill. a kiírás.

Az I2C inicializációja így néz ki jelenleg:
Ha minden igaz, a 16 MHz-es órajelet így leosztom 100 kHz-re, ami jónak is tűnik.

Az SPI viszont ilyen jelenleg:
Tehát így 8 MHz-es DCO-val működik.

Ha UCB0BR0 értékének 2-t írok, a kijelző nem működik.
Ha BCSCTL2 DIVS_2 vagy DIVS_3, akkor sem.

DIVS_1 esetén ha jól gondolom, az SPI órajele 16 MHz DCO mellett 8 MHz, 8 MHz-en pedig 4.

Hogyan lehet beállítani az SPI órajelét? Nem értem azért ezt.
A DIVS osztó növelése miért nem működik?
...vagy nem emiatt "szemetel" a Nokia kijelző 16 MHz-en?

Talán holnap "okosabb leszek", mára (vagy mi ez) elég volt ennyi, azt hiszem.

Tippje esetleg valakinek? Elnéztem valamit?

Ha UCB0BR0 = 0x01; helyett nagyobb számot írsz, annak működnie kell. Nem lehet, hogy a bájt kiküldés körül van valami probléma?

Szia.

Elsőnek. Működik együtt a kettő stabilan, (i2c, spi) sőt....

A programodban felesleges a "BCSCTLx" regiszterekkel játszani, mert az i2c órajelét le lehet osztani két regiszterrel (UCB0BR0,1), az SPI meg mehet 16MHz-en.
I2C órajel:

Azt sajnos nem tudom/értem, hogy Icserny mire értette a "Ha UCB0BR0 = 0x01; helyett nagyobb számot írsz", de nálam így megy 16MHz-n az SPI.

Egyszóval, én is csak azt tudom mondani, mint Icserny fórumtársunk, hogy máshol lesz a hiba.

Köszönöm a válaszaitokat.

Jelenleg ez a két inicializáció:


Az I2C-nél azért akartam leosztani, mert javasolták egy helyen (és végülis miért ne osszam le hardveresen, ha lehet), csak azt nem értettem, ez az SPI-nél miért kavar be.
Ezért kapcsoltam át más osztóra az SPI initben, mert egyébként nem működött az SPI.

Alacsonyabb frekvencián működik is együtt az I2C és SPI tökéletesen, csak 16MHz-en van gondom.

Jelenleg úgy állok, hogy ha pl. 8MHz-es DCO-nál próbálkozom változtatni az SPI órajelén, akkor UCB0BR0 = 0x03-ig működik a rendszer, fölötte (0x04 és afölött) nem.
16MHz-en ugyanez a helyzet, csak szemetel is a kijelző.

Mondjuk van még egy tippem - szerintem ez az a mikrokontroller, amivel már múltkor is vacakoltam a belső hőmérő kiolvasásával is, az ugyanis nem működik benne.
(Tehát a kódom akkor jó volt mint kiderült, csak a kontroller adott vissza hülyeséget.)
Tehát lehet, hogy van ennek még más gondja is... hmm.

A kijelző meghajtását itt csatolta valaki, azt vettem át.
Kiíratásnál tűztem be várakozásokat, az nem hatotta meg. Csatoltam a hozzászóláshoz.

Én raktam fel, és úgy emlékszem, hogy megy/ment 16MHz-en is.

( A P1SEL/SEL2-öt is felesleges kétszer inicializálni. Egyszer a portok inicializálásánál elég.)

Nem csoda. Az adatlap szerint a Nokia5110 LCD vezérlője max. 4.0 MHz-es SPI frekvenciával dolgozik. A késleltetés ezen nem változtat.

Ezt mondjuk nem egészen értem, mert a 3310-es lcd-je is PCD8544-es vezérlőt tartalmaz (azt hiszem), és az megy 16MHz-en.

Bár ahány darab annyi féle. Volt, hogy két, látszólag egyforma 3310-es LCD, nem ment ugyanazzal a vezérlőprogrammal, csak ha az inicializálásnál változtattam az értékeken.

Akkor neked köszönöm a feltöltést.

Lehet, ez az LCD nem bírja ezt a frekit - mondjuk van itthon még egy, majd megnézem azzal is.



Persze, ez még nem a letisztázott kód.
Egyelőre az nem tiszta, miért nem sikerült visszavennem az SPI frekijét.

Köszönöm az utánanézést.

Tehát a fenti hozzászólásomnál a 8 Mhz-es DCO melletti 4 MHz-es SPI korrekt lehet, 16MHz-es DCO mellett kúszik fel 8 MHz-re, amit jogosan nem szeret.

Ezért gondoltam, hogy ha az SMCLK órajelét nem kettővel osztom, hanem néggyel, akkor működnie kellene.
Ennek ellenére a kijelző meg sem nyikkan ezzel a beállítással sem 8 MHz, sem 16 MHz DCO mellett.

Ez volt furcsa nekem - tehát valamit rosszul értelmezek és emiatt nem jók a beállításaim, vagy legalábbis nem értem, miért nem sikerül az SPI frekit belőnöm amellett, hogy az I2C freki jónak tűnik.
Mondjuk jó lenne megmérni.

A kijelzőnek 2 MHz-es SPI órajellel is működnie kellene, nem?
...mert akkor fogalmam sincs, 8 MHz DCO mellett BCSCTL2 |= DIVS_2;-vel miért nem megy, ami SMCLK=DCO forrás esetén 8 MHz/4=2 MHz órajel lenne értelmezésem szerint és az SPI-nél is SMCLK van kiválasztva.
Legalábbis itt vagyok megkavarodva.

Ha jól rémlik a FUG-ból, az SPI freki ugyanúgy működik mint az I2C.

UCB0BR0 4; = SMCLK / 4 = 16MHz / 4 = 4MHz
UCB0BR0 8; = SMCLK / 8 = 16MHz / 8 = 2MHz

stb...
De mivel az SPI-vel még keveset foglalkoztam, nem vagyok benne biztos.

Hmm - meg kellene azért nézni másik kontrollerrel is.

UCB0BR0=4 már nem volt jó neki...

A PCD8544 adatlapjában ez áll: Serial interface maximum 4.0 Mbits/s. Ettől függetlenül lehet, hogy megy nagyobb frekvencián is, de az már kívül esik a specifikált (és garantált) tartományon.

Megpróbáltam egy másik kontrollerrel, ott is hasonlóképpen viselkedik.
Kicsit mintha stabilabb lenne a megjelenítés (talán kicsit alacsonyabb lehet az órajel), de szemetel így is a kép (csak lassabban).

Egyszerűen nem tudom normálisan visszaosztani az SPI órajelét... :S

A Family User's Guide-ból:


Mégis, UCB0BR0 értékét növelve a kijelzésem elhal és nem látom az okát...

Hmm - a másik kijelzőn nem látom ezt a szemetelős effektust, de ez még nem ad magyarázatot arra, láthatólag miért nem tudom megfelelően beállítani az SPI órajelét.

UCB0BR0 = 4 esetén nem kapok képet a kijelzőmön (ezen sem).
Tehát a program ilyenkor is fut, csak nem látok semmit.

Az SPI órajelén kívül viszont nem kellene másnak változni és UCB0BR0 = 3 esetén még jó.
Nem értem.

Sziasztok! Tudnátok segíteni mi lehet a baj? Egy turbonyomás mérő órát csináltam. 0-5V-nak a bemeneten megfeleltettem 0-2,5 értéket a kijelzőn. A feszültség osztó összesen 250k-ohmos.
A kapcsolás működött próbapanelon, átrakva ide eleinte semmit nem csinált, ill folyton resetelt. A resetet 15k-val a tápra húztam, az megoldotta a gondok egy részét. Olyan mintha az ADC nem csinálna jól valamit. A videón a potit lentről feltekerem, majd újra le. Látszik is, hogy mutatná a 2 feletti értéket, de mégse... mindig visszatér 1,7 1,8 érték köré, és nem tudom miért. A TEST és Xin Xout lábakkal mit kellene csinálnom?

Bővebben: Link

Az lehet, hogy túl hosszú a kábel, amin a szenzor lesz? Pedig árnyékolt kábelt használtam direkt.

Köszi szépen:
uli