Sziasztok!

Van egy fejlesztésem PIC18F4520-as kontrollerrel és némi gondom támadt az I2C kommunikációval.
Assemblyben fejlesztek, az MSSP modult használom a kommunikáció vezérléséhez, a buszt 100kHz-en hajtom. A buszon a mikrovezérlő a master, rajta kívül két eszköz van, egy 24LC256-os EEPROM és egy MCP7940-es RTCC. A byte write és byte read mindkét eszközzel tökéletesen működik, a page write is ok, viszont a sequential read-del van egy olyan gondom, hogy 20 byte-ot még tudok olvasni egybe, de 21-et már nem. Ott akad el a dolog, hogy elküldöm az EEPROM-nak a control byte-ot, a címet, elkezdem olvasni a byte-okat és a végén amikor STOP-ot küldök a buszra, az MSSP modultól hiába várom a megszakítást, az életben nem érkezik meg... Nem tudom valaki találkozott-e már hasonló hibával, bemásoltam a kódból az ide vonatkozó részletet. Megköszönném, ha valaki vetne rá néhány pillantást és tudna mondani valami okosat!

Az I2C_DEBUG szubrutin csak annyit csinál, hogy az SSPSTAT, SSPCON1, SSPCON2 regiszterek értékét kiírja az LCD-re. Ezek az értékek egyébként még a STOP meghívása előtt normálisak SSPSTAT=0x88, SSPCON1=0x28, SSPCON2=0x20

A kódot fájlként csatoltam, mert érthetetlenné tördelte az oldal beépített szerkesztője

Sziasztok, már a korábban említett SainSmart 3.2" SSD1289 TFT kijelzővel elkezdtem foglalkozni,mégegyszer köszönöm a segítséget, még extra információ után kutakodva a neten, rátaláltam egy IC-re , amit az ilyesmi (nem ehhez volt) kijelzőkhöz lehet kötni, és akkor a mikrokontrollernek már csak ennek az IC-nek kell elküldeni azt, hogy mit akar kijelezni 1 pontba (tehát x,y 1 pontját lehet frissítgetni), ez nekem a mostani projectemhez sokkal ideálisabb lenne, nem tud valaki ilyen IC-t ajánlani, amit viszonylag könnyű beszerezni, és nem egetrengetően drága?
Egyáltalán valamelyikőtök foglalkozott ilyennel?
ÜdV!

Időközben megoldódott. A PIC18F4520-nak elég sok probléma van az MSSP moduljával (ld. errata). Ugyanazok a rutinok 18F46K22-vel hibátlanul mennek...

Üdv Néktek!

Elnézést, ha nem bogarásztam eleget a fórumtémákban, de megkérdezem:
belefutottam egy problémába - 16F1459 saját flash /program memória/ használat (írás) kb. 80 % ban hibázik. debug, debug, downgrade, debug láss csodát, hibátlan míg alap órajelen ketyeg
amint megpörgetem USB kommunikáció miatt, újra ostobaságok történnek a flash területen. Az adatlap nem kényeztet, a 123-as TIW paraméter értékén kívül semmi...

Látott már valaki hasonlót?

Olvasgatni kell az errata -t is.

Kösz Hp41C! Ezt valahogy nem találtam... szopóka... az USB leakad, ha elveszem tőle a fordulatot... még ha időzítéssel +old6ó lenne.

Az errata szerint az újabb revíziójú chipekben elvileg javítva van, ők is érezték, hogy ez azért nem kóser így.

Próbáltam ezt-azt. Sajnos az USB lelki világát nem ismerem túl mélyen. Van 5leted, mit tudok tenni a revíziós csere nélkül? Suspendet próbáltam a flash írás 4 MHz lassítás idejére, nem jött be /vagy rosszul csináltam/.

Biztos, hogy más megoldás nincs, mint hogy az eszköz "eltűnik" arra az időre, amíg flash-t akar írni. A suspend emlékeim szerint a host felől kezdeményezett állapot, amely addig tart, amíg az eszközt meg nem szólítja újból a host. Mivel az eszköz nem tudhatja, hogy mikor szólítják meg, erre nem alapozhatsz.

UART-al szeretnék egy kis kommunikációt megoldani több PIC közt. Tudtok valami jó, magyar nyelvű leírásról ami az UART-ról szól?

Bővebben: Link A Goooooogle találta az "aszinkron adatátvitel" keresésre...
Ha nem szeretnéd a kontrollerek jelentős kapacitását lekötni a hibátlan adatátvitelre, akkor bufferelt megoldást valósíts meg. Többször leírtam már ebbe a topikba is.

Köszi, ezt én is megtaláltam. Csak én assembly-ben programozom majd, és konkrétan az érdekelne hogy maga a PIC UART modulja hogyan működik, hogyan kell beállítani, Hova kell a küldendő adatot bemásolni, hol kapom a beérkezett adatot stb. Bár közben eszembe is jutott hogy a Kónya-féle könyvben ha jól emlékszem írnak róla részletesen. Ki is nyomtattam gyorsan az adott részt (mert a könyvem most pont kölcsönbe van adva egy barátomnak) aztán most tanulmányozom.

Na, itt egész jól leírták a dolgokat! Egy kérdésem van amire még nem találtam választ sehol. Egyszerre lehet adni és venni is? Azaz mi történik akkor ha épp küld ki a PIC adatot és közben érkezik is egy adat?

Lehet adni és venni egyszerre, az adó és a vevő függetlenül működik. Persze a formátum (8 vagy 9 bit) és a sebesség közös.
PIC Uart kezelés

Lehet adni és venni, de nem úgy, hogy megvárom, míg beér a vétel összes adata, majd menézem mi jön válaszban, mert akkor lebarad a fele! Bájtonkénti adás-vétel megszakításból mindkettő és pufferelés, indexelés, hibakezelés, CRC kezelés, stb.
A modul működését pedig legjobban számomra az adatlap rajza mutatja meg. Ebből az is kiderül, hogy két egymástól különálló hardver egység dolgozik, azaz tud full duplexet.

Köszönöm a válaszokat! Még annyi hogy menni fog az UART belső oszcillátorral? Vagy mindenképpen kvarcot tegyek a PIC-re?

Illetve: Pufferelés, indexelés, hibakezelés, CRC kezelés stb.?
Pufferelés alatt azt értitek hogy mikor bejön egy adat akkor csak gyorsan kimásoljuk valahova mondjuk egy mutatóval, majd a következőt stb és mikor megjött asz összes bájt akkor szabad csak feldolgozni?
Indexelés alatt nem tudom mire gondolsz watt.
Hibakezelés, CRC kezelés... Miért, lesz hiba? Ha ugyan olyan sebességet állítok be az adó és a vevő PIC UART-jában és egy darab vezetékkel összekötöm őket akkor csak nem lesz hiba. Gondolom én.

--> Igen. Nem muszáj kivárni az összes adatot, ha van közben időd a feldolgozásra, de ez feladattól függ!
--> mutatóval történő kezelés !
--> attól még nem együtt mennek, de nem valószínű, hogy ebből hiba lesz, hanem az összekötő vezetéken fellépő zaj hatására is lehet bittévesztés ( kiszajú környezetben vagy nem kritikus feladatnál nem kötelező, de ha mondjuk "rakétát indítasz" , akkor nem árt vele vigyázni! ) !!

Szia!
Nem tudom milyen PIC-et akarsz használni (én a 18F családot javaslom), az UART a FOSC-ról megy, tehát amilyen órajelforrást használsz, azzal fog menni az UART is. Ha lehet, külső kvarcról járasd a PIC-et, mert a belső oszci ilyen célokra (tapasztalataim alapján) pontatlan, sok vele a "nyűg" (adó - vevő oldalon nem biztos hogy egyezni fog a frekvencia, és magas baudnál rossz adatokat fogsz kapni, nagy lesz a hibaszázalék). Mivel tökéletes kommunikáció nincs, ezért itt is lehetnek hibák, amit flagbitekkel lehet lekérdezni, pl. az RCSTA regiszterben a FERR (Framing ERRor), és az OERR (Overrun ERRor). Ezek 1-be állnak, ha vételnél hiba keletkezik (pl. overrun: "ráfutás" - ha túl gyorsan jön az adat). Szóval vételnél ezeket mindig figyelni kell (vagy legalábbis illik), és aszerint eljárni (várni, "eldobni" a beérkező adatot.. stb).
A pufferelést jól írtad, végülis az indexelés is ide tartozik, vagyis az adat elhelyezkedése-címzése a memóriában. A CRC az adatfolyamban van kódolva, ami végülis egy kódolás-dekódolás, szerintem egyszerűbb átvitelhez felesleges. Vannak egyéb, egyszerűbb kódolások (pl. manchester).

Ha a PIC belső oszcillátora 1-2% pontosságon belül van, akkor az elég lehet. Ha rosszabb, akkor kell a kvarc.

Sziasztok!

Tudnátok mondani ötleteket, hogy lehetne megvalósítani a következő motor vezérlését?!
Motorvezérlés PIC-el...

Ezt sok sok delay-el oldottam meg, mert ennyit tudtam. Viszont most már van végállás kapcsoló és le kellene tudni állítani a szerkezetet. Viszont a sok delay miatt ki kell várni a programban mire leellenőrzi a bemenetet és történhetne bármi is.

A léptető motor vezérlésére írtam egy függvényt amit meghívogatok ha mondjuk azt szeretném, hogy felfelé menjen... De szintén ki kell várni míg felmegy, és hiába jön az érzékelőről jel, figyelembe se veszi addig.



Ez a léptető motor pontosan 64 lépéssel leteszi a fejet amit mozgat.

Jó, mondom akkor csináljuk meg interruptal.


Ez eddig oké, mert szépen elindul lefelé a fej... De hogy lehet megállítani, majd várakozni és felvinni a fejet, majd jobbra menni és a végállásal leállítani a szerkezetet? Eddig a delay-el kivártam az időt, meghívtam a le(); fel(); függvényt és 64 lépésben vitte a motort, kész.

De ha interrupt van, hogy lehet időzíteni?

Milyen megoldások léteznek arra, hogy "realtime" figyelje az érzékelőt is és ha végálláshoz ért álljon le?
delay-ek nélkül?

Remélem érthető a problémám.

Szia!
Pl. használod a PIC Timer modulját, ami a programtól függetlenül "jár", és tud megszakítást is generálni. Pl. a folyamat előtt törlöd a Timer regisztereket (pl. TMR1H, TMR1L), majd elindítod a timert, aztán a programban figyeled a megszakításjelző bitet.

Ismét köszönöm a válaszokat! Mint írtam soha nem volt még dolgom semmilyen PIC-ek közti kommunikációval ezért nem igazán tudom hogyan szokás ilyesmit megvalósítani mint amit én szeretnék. De már egy hete töröm rajta a fejemet és mostanra összeállt egy szerintem nagyon jó ötlet, ezt osztanám meg veletek és kérdezném hogy ez szerintetek működhet-e:

A panelmérőmet fejlesztem tovább és arra gondoltam hogy jó lenne ha össze lehetne kapcsolni két panelmérőt és azok optocsatolós leválasztás útján kommunikálhatnának egymással. Elküldözgetnék egymásnak hogy mit mértek és az egyik panelmérőn lenne csak LCD és ott jelezné ki mind a két panelmérő által mért feszültséget és áramot. A cél az, hogy így kettős tápegység esetén egy kijelzőről leolvasható legyen mind a két táp feszültsége és árama. Vagy mivel a panelmérő III már AC-t is fog tudni mérni, akár hálózati kapcstápok hatásfokának mérése is megoldható lenne egyetlen ilyen kis műszerrel. Sőt, arra gondoltam hogy maximum akár négy panelmérőt is össze lehetne így kapcsolni, ha esetleg valaki négyes tápot épít. Az optocsatolós leválasztás miatt mind a négy labortáp galvanikusan független maradna, persze mind a négy panelmérőnek külön tápellátás kell.

Először szoftveres megoldáson gondolkodtam, leginkább azért mert nincs már egyetlen szabad lába sem a PIC-nek, legfeljebb csak az ICSP csatira kivezetett három. Ezek viszont gondoltam magamban biztos nem kommunikációs perifériákhoz tartoznak. Aztán megnéztem az adatlapját a felhasználandó PIC18F25K80-nak és marha nagy szerencsém van mert a programozói lábak egyben az RX-TX lábai is az UART modulnak. Szuper!
Ekkor kezdtem el gondolkodni magán a kommunikáción hogy az hogyan is történjen. Először mindenképp egy mester-szolga rendszerű dologban gondolkodtam ahol van egy mesternek kinevezett panelmérő (PIC) és ő kérdezgeti le a másik panelmérőt (vagy panelmérőket). De gondoltam mi van akkor ha az user véletlen egynél több panelmérőt állít be mesternek? Mondom jó oké, akkor legyen az a mester amelyiken a kijelző van. Na és mi van ha mindegyiken van kijelző? A másik dolog pedig hogy ki fogja 'vezényelni' a kommunikációt? Az, amelyiknek a tápfesze előbb feláll és sikerül elindulnia a PIC-nek? De mi van ha a következő áram alá helyezéskor meg a másik éled fel hamarabb? És honnan tudják a panelmérők hogy a sorban ki hol helyezkedik el, melyik jön melyik után? Oké, akkor nevezzük el, sorszámozzuk fel vagy véletlenszám-generátorral adjunk valamiféle neveket a panelmérőknek de az sem jó mert mi van ha azonos lesz a név? Illetve van még egy probléma hogy a kommunikációnak működnie kell akkor is ha csak két panelmérő van össze kötve, de akkor is ha négy. Vagy esetleg három. (Négynél több nem kell szerintem, az már bőven elég.)

És így jött az ötlet hogy a kommunikáció két panelmérő közt csak egyirányú legyen, de azok egy körbe lennének kötve. Azaz négy panelmérő esetén az "A" küldené az adatot a "B"-nek, a "B" pedig a "C"-nek, a "C" a "D"-nek, majd a "D" az "A"-nak. Noha így a kommunikáció egyirányú, mégis a körbe kötés miatt közvetve eljut minden adat mindenkihez. Ugyanis úgy nézne ki a dolog, hogy amikor az egyik panelmérő, legyen mondjuk a "B" mér egyet (fél másodpercenként egyébként) akkor elküldi azt a "C" panelmérőnek. De nem csak azt amit ő most mért, hanem azokat az adatokat is amit az előző két panelmérőtől ő kapott! Tehát a "C" meg fogja kapni a "B"-től a "B", az "A" és a "D" mérési eredményeit is. És ez így menne szépen körbe-körbe. Persze mindegyik panelmérő tudni fogja hogy mikor adatcsomagot kap akkor az első adat az előtte lévő műszeré, a második adat a kettővel mögötte lévőé, a harmadik adat pedig a hárommal mögötte lévő műszeré. Persze most csak mi neveztük el őket A, B, C és D-nek, ők nem tudnak róla hogy ki kicsoda. Mindegyik önmagát "A"-nak tekinti. És a "B" a mögöttest jelenti számukra, a "C" a kettővel mögötte lévőt, a "D" pedig a hárommal mögötte lévőt. Persze ennek folytán ha mind a négy panelmérőn van LCD kijelző akkor a kijelzések nem lesznek azonosak, de ez nem is fontos.
És itt jön az hogy mi van ha nem négy, hanem csak három vagy kettő panelmérő van? Három panelmérő esetén az "A" az adott panelmérő saját mérési eredménye lesz, a "B" a mögötte lévőé, a "C" pedig a kettővel mögötte lévőé. "D" panelmérő jelenleg nincs, az a jelenleg "A"-nak nevezett saját mérési eredménye lesz! Csak nem a mostani hanem az előző. Két panelmérőnél pedig értelem-szerűen az utolsó két vett adat lesz a sajátjuk. Ezt már szoftveresen, menüből az user simán be tudja állítani hogy az utolsó vagy az utolsó kettő adatot ne jelezze ki az LCD-re.

Na és még annyi ötletem van ezzel kapcsolatban, hogy valójában nem is három adat kell hogy keringjen hanem négy. Miért? Azért, mert akkor betehetek egy UART-USB átalakítót a körbe úgy hogy ráakasztom bármelyik pic TX-ére és máris az egészet rá lehet kötni számítógépre és ott szépen monitorozni lehet az összes panelmérő mérési eredményeit.

Nos ez az ötletem. Próbáltam átgondolni alaposan hogy ez működhet-e, esetleg lehet-e benne valami módon gubanc. Például ha a panelmérők nem szép sorjában küldik az adatokat egymásnak hanem össze-vissza (erre elég nagy esély van, mert a sorrend az lesz ahogy a panelmérők felélednek). Ez elvileg szerintem nem lehet gond. A másik dolog pedig hogy mi van ha valamelyik sűrűbben küld adatot mint a másik. Ezt még nem sikerült teljesen átlátnom hogy ilyenkor mi történne, de amúgy teljesen ugyan az a szoftver fut majd mindegyik PIC-ben és a mintavételek (és egyben az adatküldés) pontosan 500ms-onként történnek majd mindegyik panelmérőben. Ráadásul kvarc oszciról. De elvileg hogyha a kvarcok közti idő különbség összege eléri az 500ms-ot (ami szerintem irtó sok idő lehet amúgy, bár ki kellene számolni) akkor megtörténik az hogy valamelyik (a leggyorsabb) panelmérő kétszer küld adatot míg a többi csak egyszer. Ilyenkor lehet hogy kieshetnek a szinkronból és elcsúsznak az értékek. De ezt a részét még nem gondoltam át teljesen, illetve előfordulhat még más hibalehetőség is a gondolatmenetemben. Nos, pontosan ebben kérném ki a véleményeteket!

Biztosan működhet a dolog, ha jól ki van találva, de én raknék bele valami szinkronizációt, hogy tudja a kijelző egység, milyen érték kihez tartozik.
Most hirtelen még annyi jut eszembe, hogy az optocsatolónál vigyázz a baudra, nálam 56kbps fölött már nem vitte jól át az adatot a 4N25 és társai (6N137 már jó volt), de mondjuk ide nem is kell nagy sebesség.

Pont ezt mondom hogy nem lehet tudni melyik adat melyikhez tartozik, csak olyan szinten hogy:
- "én adatom, most jött az A/D-mról"
- "mögöttem lévő panelmérő adata, ez érkezett az UART-on legutóbb kapott adatcsomag első adataként"
- "kettővel mögöttem lévő panelmérő adata, ez érkezett az UART-on legutóbb kapott adatcsomag második adataként"
- "hárommal mögöttem lévő panelmérő adata, ez érkezett az UART-on legutóbb kapott adatcsomag harmadik adataként"

Igen, itt nem kell gyors adatátvitel. 500ms-onként kell majd úgy számolom kb 30 bájtot küldözgetni, igazából marhára ráér mennyi idő alatt. Nem is tudom mi a leglassabb sebesség a pic UART moduljánál, majd megnézem.

Amint látod, csináltam TIMER0 időzítőhöz megszakítást...

De nem jól működik, mert túl gyors még a legnagyobb prescale osztással is. Ezért indítottam még egy számlálót (t), és szeretném (y) változó értékét egyesével növelni majd a switch case-ben lépésenként kiadni mit csináljon. De össze vissza ugrál. Nem tudom megoldani... Biztos van valami más megoldás, egyszerűbb, jobb. De gőzöm sincs hogyan tovább. Ez a bajom.

Első olvasásra egyszerűnek tűnik, de ha jobban belegondolunk, elég összetett a feladat (bár lehet csak én bonyolítom túl szokásomhoz hívően ). Végig gondoltam, mi lenne ha teljes kört alkotnának, de csak belegabalyodtam...
Csatoltam egy képet, melyen van egy lehetséges verzió. Itt minden küldés után törölni kell értelemszerűen a beérkező adatok számlálóját.
Van még rá biztos sok jó megoldás, de most hirtelen ez jutott eszembe.

A rajzod jó, így gondolom ahogy a rajzon van.

Na, akkor egyre gondoltunk, csak bekavart ez a körbe kapcsolós dolog.
Viszont minden elemnek tudnia kell, hány elem van összesen, és ő maga hanyadik. És akkor így elég az első elemnek beállítani 500ms-ot, a többi meg csak vár, ill. küld, ha érkezett adat.
Gondolom egy panel több byte-ot küld, mondjuk 4-et, és akkor a négyesével lesznek szétválasztva a vett adatok. De ez már részletkérdés. Sőt, akkor egyértelműen azonosítható is mindegyik, hisz mondjuk minden 5. byte az adót azonosítja.
De persze ha valami gebasz van, akkor borul az egész, ezért nem árt belerakni valami időalapú "reset"-et, hogy ha mondjuk x ideig nem jön adat, akkor álljon alaphelyzetbe a panel.

Bocsi, csak kissé zavaros a program, és nem is látni, hol figyelné a végállást.
Szerintem először gondold ki, hogy is fog működni, esetleg papírra (vagy PC-n) rajzold le a folyamatábrát, és csak utána írd meg a programot. Persze lehet programírás közben rájösz, hogy az úgy nem is jó, ezért tervezésnél arra is gondolj, hogy fog ez a valóságban menni. De hát ilyen a fejlesztés...
A motorvezérlésnél, meg mondjuk a végállást úgy is meg lehet oldani, hogy olyan lábra rakod a végálláskapcsolót, ami tud megszakítást generálni. Így a motor mozgató rutinnál, figyeled ezt a flag bitet, vagy a megszakításban nézed a lábhoz tartozó flagbitet, és aszerint jársz el (pl. törlöd a timert, és "jelzel" a motorvezérlő szubrutinnak egy változóval.. stb.

Köszi!

Egyelőre még nincs is benne a végállás figyelése. Már ott elakadtam, hogy eddig ezzel simán letettem a tárgyat 64*4 lépésben a léptetőmotorral... DE OTT A DELAY ami meghatározza a gyorsaságát a léptetőmotornak.

Ezt hogy lehet másképpen megoldani úgy, hogy benne van az interrupt és a timer?!

A feladat amúgy amit csinálni kell egyszerű lenne elméletileg, mert a végállás kapcsoló csak a kocsit mozgató szerkezet egyik és másik végén van. Bárhol hozzáér le kell állni a jobbra és balra mozgató motornak és letenni majd felvenni egy alkatrészt. A jobb és bal irány egy DC motor. Az sima ügy, mert csak kiküldöm merre menjen. De a léptető motor már gázos, mert azon nincs érzékelő, csak annyit tudok tenni, hogy (64*4) 256 lépéssel lemegy vagy feljön.