Fórum témák
» Több friss téma |
Azért az Excel sem kutya. Hosszú évek átlaga alapján úgy tűnk, jobb, ha én adom meg a válogatási szempontokat. Az esetleges hibákat ki tudom javítani, nem úgy, mint a MAPS esetén.
A hozzászólás módosítva: Júl 11, 2017
Sziasztok!
XC8-ban próbálnék megírni egy egyszerű I2C kommunikációs csatornán keresztüli SSD1306 kijelző vezérlést. A problémám a következő, amit nem egészen értek, hogy miért nem jó és biztos én rontok el valamit, de nem jövök rá mit: 1) Felépül a kommunikáció szépen 2) van egy buffer tömböm, amiben elvileg a kép tartalma lenne, ez 1024 hosszú és csak számokból áll 3) amikor elküldeném a tömb tartalmát a kijelzőnek, akkor nem írja ki az I2C vonalra A tömb definiálása:
Ahol kiírnám az I2C vonalra (egyszerre kirakom rá egy lap tartalmát, ebből van 8db, ha fix értéket írok be, akkor az szépen kikerül, tehát a tömb körül van a gond):
Természetesen próbáltam simán a buffer[counter], a buffer[page*128+column], és ezek variációt is (a counter változó bevezetése csak azért lett, hogy hátha a szorzáson múlik a siker, de nem). Eredetileg persze nem is mutatót használtam a kicímzéshez, de az se volt jó. Ha viszont fix értéket (pl. 0b01010101) rakok be, akkor működik a kód és elküldi az értéket (próbáltam már, hogy a változók értékéből generált számot íratom ki, az is megy).
Akkor nem nagyon értem, miért nem spi-t választottál. Gyorsabb, és ellenőrizhetőbb lenne.
A problémád egy kicsit összetett. Elsőként azt kellene ellenőrizni, hogy az elküldött adat biztosan megérkezik-e abban a formában, ahogyan elküldted. Egy másik pic kellene a vonalra, ha i2c. Spi esetén vissza is kötheted. Ha az adatküldésbe biztosan nem kotyog bele config probléma, vagy áramköri parazita tényezők, akkor kell majd a kommunikációs protokolt előszedni. Ugye rendesen elolvastad az adatlapot? Idézet: Ezt hogy kell erteni? Nem megy ki semmi? Vagy mas megy ki? Van szkopod, hogy ranezz?„amikor elküldeném a tömb tartalmát a kijelzőnek, akkor nem írja ki az I2C vonalra” Eloszor is, ha a buf valtozod "int *", akkor nem byte-onkent fog olvasni, hiszen int pointer es nem char. Szolnia kellene a forditonak, hogy egy int pointerbe egy char pointert akarsz betolteni. Ez mindenkeppen egy hiba, de, ha probaltad a 'buffer[counter]' megoldast, akkor nem tudom, hogy mi lehet a problema. De a legegyszerubb mindenkeppen ez lenne:
Idézet: Minden bántás nélkül, ugye rendesen elolvastad a kérdésem?„Ugye rendesen elolvastad az adatlapot?” A kommunikációt Salea Logic kütyüvel nézem. Egész pontosan az történik, amit leírtam. Felépül a kapcsolat, rendben működik minden, de csak akkor, ha a cikluson belülre olyan dolgot teszek, amit vagy számolnia kell, vagy egy fix érték. Ha így teszek, akkor szépen megy a dolog, de ha a tömbből akarok beletenni valamit, akkor a ciklus végre se hajtódik, legalábbis a vonalon nem jön ki semmi. Magyarul még mindig azt mondom, hogy a tömb elemeinek a cikluson belülre kerülésénél van gond és azt nem értem ott mit ronthatok el, ami miatt nem megy?
Ez is megvolt, ebből lett a végén már a buffer[counter] megoldás...
És igen, úgy kell érteni, hogy semmi nem megy ki. végrehajtódik a ciklus előtti rész, de a ciklusmag nem. A hozzászólás módosítva: Júl 14, 2017
Ezt nem te rontod el, az biztos. Ilyenkor a disassebly lista sokat segit.
Próba újra.
Eléggé érdekes a programod
 Nem lesz jó vége,ha int-char típusokat ennyire kevered,hosszabb proginál meg sem találod a így a hibát. Biztos,hogy így megy a kijelző,ha nem tömbből teszed ki?Csak mert még a page benne van,de nem látom,hogy a 128-as ciklus után az is növelnéd,így az egészet szerintem csak 1 sorban fogja végigpörgetni. Bár én nem ezzel a SSD-vel dolgozom,hanem egy korábbi verzióval,aminek jó pár funkciója hasonló a tiéddel,de nekem másként sikerült kijelzésre bírni .amúgy a buffer[page*128+column] megoldás jó,de a int *buf -ot szeretnéd használni,akkor tedd át u char *buf -ra ,mert itt nem az értékét kell nézni,hanem,hogy milyen típusra mutat.Még 1 jó tanács,ameddig nem lépsz át bizonyos értékhatárokat,addig ne használj nagyobb változókat pl: a page,column lehetne simán char,unsigned char. Inkább csak unsigned,ameddig nem használsz negatív értékeket,így kisebb a hibalehetőség,max. majd ha sprintf-et használsz,ott majd sípol,hogy csak signed kell neki,de az más tészta.Na most már megyek aludni,mert holnap szülinapi buli lesz.
Ez a próba megvolt, az eredmény ugyan az. Mint írtam, elég sok variációnál járok már, hogy az éppen beírt változatban nem volt egyforma a típus, az előfordulhat.
Amik eddig mind ugyan azt az eredményt hozták:
... Ezek azok, amik most hirtelen az eszembe jutottak. Ha viszont fix értéket raktam be, akkor kikerült a vonalra, pl.
Hétfőn újra nekifogok, mert elfelejtettem hazahozni a cumót, s majd jelentkezem, ha sikerült valamit alkotni.
Igen, növelem a page-t  A kijelző meg valóban érdekes jószág. Kell neki egy rakás parancs, hogy beinduljon (erre már kész az init() fv. és működik is szépen), majd a grafikus memóriájának feltöltését úgy eszi meg, ha egyszerre egy egész page van neki odaadva (maximum egy page, ezt akár több részletben is oda lehet neki adni), s minden ilyen adatömlesztés előtt ki kell rakni a vonalra a címét, illetve a 0x40 utasítást, hogy tudja, most ömlesztve jönnek majd az adatok. Az érdekesség dologhoz csak annyit, hogy amíg fejlesztés közben van, addig nem szeretem külön szétszedni külön függvényekre, hanem jobb szeretem kipróbálni hogyan működik, s csak utána kirakni. Majd a cél az lesz, hogy ez a kódrészlet egy void megjelenit(); függvénybe fog bekerülni, s a többi csak a buffert fogja módosítgatni. Meg persze másik I2C eszköz is kerül majd rá (szenzor), aminek az értékeit kell majd kiírnia.
Ugyan ilyen kijelzőt használok, csak SPI vonalon.
Szerintem a C fordítód egyszerűen csak gagyi, és nem tud megbirkózni a nagyobb tömbök indexelésével, aztán lefagy miatta. Ha az történik, azt nagyon egyszerűen igazolni lehet. Írj egy másik programot, tölts fel abban is 1024 elemű tömböt mondjuk 0-1 értékekkel, ugyan úgy rakd bele a kettő for ciklust, és függvénybe küldd be paraméterként a kiolvasott értéket (legyen átadva a kiolvasott érték függvénynek). A meghívott függvényben meg valami delay-vel (mondjuk 0.2 sec) rakd ki led-re a kapott értéknek csak a legalsó bitjét. Ha működik a program, villogni fog a led kb másfél percen keresztül. Ha elakadt, akkor meg se fog nyikkanni - és akkor dobd a kukába azt a C fordítót.
Láthatnánk a linker vezérlő állományodat és a változóid deklarációját?
Ezt a Page-et láttam,de az csak a 'kép' adatain fut végig,amit kiküldesz.De én arra gondoltam,ami a kijelzőnél léptet,ha te azt mondod,hogy bemehet az összes egyszerre,akkor tárgytalan a kérdésem.
A kijelzőnek az van beállítva, hogy amikor a page végére ér, akkor automatikusan léptessen, így nem kell külön kérni a léptetést tőle.
Holnap reggel, mikor a kezem ügyében lesz, feltöltöm kompletten az egészet.
Üdv!
Hasonló problémám volt nekem is I2C-vel SH1106-os OLED kijelző + BME280 szenzor párosításával. Nálam a kommunikáció akadt le, már pontosan nem emlékszem, de a STOP bit körül volt a gubanc. A megoldás az lett, hogy megírtam magamnak a hardveres I2C függvényeket és az ömlesztett adatküldést hanyagoltam. Nézz rá még egyszer logikai analizátorral, hátha nem vettél észre valami anomáliát. A LED kapcsolgatás is sokat segít az elakadás helyének megtalálásában. Nálam mindez 18F4550-en és BASIC alatt történt, de ebben az esetben, lehet ez lényegtelen.
A komplett projekt a mellékletben.
Ez jelenleg azt csinálja, hogy a pointer megkapja a tömb első elemének a címét, azt ki is írja szépen az I2C vonalra, viszont cserébe nem inkrementálja a pointert, így mindig ugyan azt az első értéket írja ki (ez most 0x00, de tesztként a tömb első elemének mást beadva szépen mindig az került ki a kijelzőre) .
Pedig az .lst file-ban szepen latszik (1387. sortol), hogy inkrementalja a 'buf' valtozot.
Menet közben sikerült kipróbálni csak a sima tömbkezelést is?
Sajnos annyi dolgom volt nap közben, hogy még nem jutottam el odáig. De ha "kidobhatom", ahogy fogalmaztál, akkor az nagy szégyen lenne a Microchip XC8 1.31 verziójára...
Szégyen vagy sem, próbáld ki, és azonnal ott egy bizonyíték országnak-világnak feketén-fehéren és teljesen félreérthetetlenül. Ha az eredmény elmarasztaló, akkor cefet nagy cég létükre volt merszük a sokadik update után is hulladékot gyártani, és olyasmiért a nyilvános meghurcolás a minimum, amit megérdemelnek. Ha nagyobb darab cég, majd nagyobbat puffan, amikor pofára zuhan
A hozzászólás módosítva: Júl 17, 2017
Szia!
Próbáltad kivenni változóba a tömb aktuális elemét mielőtt paraméterként átadod?
A hozzászólás módosítva: Júl 17, 2017
Igazából már azt is szégyennek tartom, hogy a peripherial library csak az 1.34-es verzióig csapható hozzá. Az aktuális verzióhoz ha letöltöd a legutolsó változatot belőle, akkor kapásból összeakad és tákolni kell, hogy egyáltalán forduljon. Mondhatjuk erre, hogy használhatom helyette a code composer nevű csodát, igen ám, de ez a mikroproci nem támogatott benne, így kiröhög és mégse mehet.
Szóval van mit szégyelnie ennek a cégnek is, de ettől még nem fognak a falnak menni
Persze nem az én dolgom, de minek egy 8 bites pic-hez az új fordítót használni? Ha harmonyznál 32 biten, azt még meg tudnám érteni (és jót röhögnék a naivitásodon, hogy elhitted, működni fog
 de az egy teljesen másik sztori), de 8 biten mi a fenének játszol tövismadarat? Miért nem jók a régi mla project példák + régi 8 bites fordító?
Kipróbáltam, az se volt jó.
Viszont eszembe jutott, hogy kezeltem én már tömböt (igaz akkor pic12f629 volt az áldozat) és megnéztem ott mi volt a diferencia. A nagy különbség az volt, hogy ott konstans tömbjeim voltak, így gondoltam kipróbálom mi történik, ha ide is beteszem azt a bizonyos const szócskát... Meglepetés! Pont azt rakja ki, amit a tömbben kap! Na már "csak" azt kell megfejteni, hogy vajon mi a fenét ronthat el a fordító ilyenkor? (Mert hát a konstans az azért konstans, mert az nem módosul, így tehát az nem maradhat.) Cserébe, ha a tömb konstans, akkor nem kell pointerrel címezni, lehet direkt is, akkor is működik. Na erre varrjon gombot az ember  |
Bejelentkezés
Hirdetés |
