Szoftveres FIFO-ra gondolt, lásd például a PICula projektemben az RX_buffer és TX_buffer tömböket.

közben találtam ERRATA megoldást, erről szól, de ettől még nem működik.
A programot átírtam erre a javaslat 3. pontja szerint:

huha. Amikor a projektbe belekezdtem, a feladatban nem szerepelt kommunikáció külső eszközzel, de később lehet, hogy kell. A típus választást lényegesen leegyszerűsítettem. "Sok" I/O, és RTCC áramkör, (plusz egy kis kihívás vágy.)
A dugaszolhatóságot nem nehéz megoldani, 100 pin-es TQFP adapter, és hüvelysor.
Igazából készen vagyok. a kommunikációs részt nem akarom megírni most. Csak tudni szeretném, hogy mely lábakat is 'hagyjam" meg erre a célra, és hát befejezném a nyáktervet. Ja igen, most már nem ragaszkodok az USB-hez...

Szia!
A hibakezelést mindenképen tedd bele, nem árt ha akkor is ellenőrzöd, ha nincs is (nem is lehet) hiba. Ha véletlenül mégis előáll valami zavartól, akkor is talpra áll...

Ha majd más feladata is lesz a kontrollernek, egy vett karaktert nem tud azonnal feldolgozni, mire kiolvassa a vevő már a következő vételét megkezdte. A programod átviszi az adóba (ez is időbe telik) és megvárja amíg a kerekter adása befejeződik. Ezen idő alatt a vevő befejezi a vételt. Néhány karakter vétele után már előfordulat 1 karakter időnyi csúszás, akkor máris ráfutás lesz.

Egy memóriában kialakított néhány karakternyi tárolóra gondoltam. A vevő tölti, az adó kiveszi belőle, ha van (még) benne és elküldi. A megszakítási rutinnak nem kell várakoznia. Az előbb lertam, hogyan működik.

Közben megnéztem kerethibára és felúlírásra, de egyikre sem talált semmi.
Sajnos azt tapasztalom, hogy az RC2IF bit soha nem áll be.

Nekem gyanús a korábban már csatolt ERRATA szerinti USART beállítás esetleg segíthet a probléma megoldásában. Lehet rosszul értelmezem a dolgot, de megnéznéd, hogy jól gondolom -e, mert szerintem nem teljesen egyértelmű. Fent bemásoltam a kódot is aszerint ahogy én gondoltam.
Sajnos pollingos módszerrel sem tudok soros adatot figyelni, mert ahhoz is a RCxIF bitet kellene vizsgálni.
Nehezen hiszem hogy egy ilyen triviális dolog ne működjön, egyenlőre viszont tanácstalan vagyok.
A megszakítások engedélyezését az USART port konfigja utánra tettem.

Igazából még most sem tudjuk mi a feladat, mert mint ha nem akarnád elárulni! Addig pedig nem tudunk érdemben hozzászólni. Az USB-ről sem értetted meg ezek szerint mit írtunk. Jó az, csak nem arra, amire te akarod használni, legalább is amit erről írtál, arra nem biztos hogy jó. Nem is az USB-vel van a baj, sokkal inkább a PC-vel!
Írd le mit szeretnél (források jellege, források száma, regisztrációs igény stb.) Az nem érdekes pl., hogy a mamának a protkótartó pohár vízhőmérséklete, elég anyi, hogy egy hőmérő, amit regisztrálni kell 6 óránként, vagy percenként. stb..

ok! egy szerverhotelnek a folyosóvilágítását újítom meg. Két üzemállapotot tud az első szakaszban, Nappali és éjjeli. Nappal állandó üzemű, éjjel jelenlét érzékelős, minden napra eltérő időszakok beállíthatóságával (jelenlegi állapot). Második ütemben a nappali időszak kettébontása, teljes és csökkentett fényerő jelenlét érzékelésre. Harmadik ütem (itt jön szóba a kommunikáció (szimplex is elég)) Egy ügyfél érkezésekor, ha a forgóvillán áthalad (beléptető rendszer, ezzel kéne kommunikálni) csak és kizárólag azon folyosó szakaszok világítanának melyen a legrövidebb úton közelítheti meg a területét.
Az információ amit a PC kiküld: az adott folyosó szakaszokat vezérlő bitek, Ez akár percenkénti változással. És ami kevésbé fontos így hát elegendő kiküldeni havi egy alkalommal az RTCC szinkronizálása, ez hat bájt (év, hónap, nap, Milyen nap, óra, perc)
A PC csak küld adatot, és erre vonatkozóan még nincs forráskód, mint említettem csak a lábakat akarom szabadon hagyni, hogy a jövőben ezt is integrálni tudjam.

Köszi! Na erre mondom én, hogy ezt nem bíznám PC-re, hanem az egészet egy PIC elviszi nevetve. Ha monitorozni akarod, hogy melyik zóna hogysmint, akkor elindítanád a monitor programot, és akár USB-n, akár soros porton(ez is bőven elég lenne) megnézed. A monitor program futhat is, nem is, PC-t leállíthatod, kicserélheted stb. a rendszer működik.

a PC muszáj, hisz a beléptető rendszer azon fut 0-24-ben, az rögzíti a kiadott beléptető kártyákat, így csak onnan származhat az infó, hogy mely folyosók aktívak (mely bitek állapotát kell a mikroprocesszornak megváltoztatnia. (nem igazán szeretnék monitorozni, azért is írtam, hogy egy irányú kapcsolat kell. a beléptető rendszer gyártója talán még ebbe az integrációba sem fog belemenni :s) tehát a processzor végzi a dolgát és ha, jön egy IT akkor a vele érkező bitváltozási "utasítást" végrehajtja. ehhez kellene egy protokoll (az rs485 meg is tetszett) és, hogy mely lábak szükségesek hozzá...

Ja értem. Milyen jelet tud kiadni a PC-n futó program és milyen porton? Hogy fog előállni a jeled a PIC felé? A PIC USART-al a soros jeleket nem nehéz fogadni, azzal nem lesz gond, én inkább a forrás kompatibilitását kétlem, hacsak nincs gyári csatonája hasonló dolgokra. A PIC-en a TX és az RX lábak kellenek. Nézd meg a kiválasztott PIC adatlapjában.

A szoftveres rész még a jövő zenéje. Egyenlőre az áramkört akarom "konyhakészre" legyártani. És ha később igénybe akarják venni ezt az opciót akkor összeütöm rá a szükséges forráskódot (butitott verzió).
Viszont azt hiszem, hogy a kérdésemre a választ megkaptam.

Köszönöm.

Ez már off, de ha nincs outputja a gyári programnak, akkor nem tudsz hozzá programot írni. Ezt csak azért írom, mert ha ez így lenne, akkor felesleges áramkört építeni. Érdemes előtte ezt kiderítened!

Watt írja: . Na ez azért nem teljesen igaz, még akkor sem ha nekem korábban egy tucatkor már sikerült.
Totál érthetetlen problémák előtt állok.
Az egyik, hogy az USART ot Low prioritású megszakításban szeretném használni, de ha nem engedélyem High prioritást nem lesz megszakítása.



Másik dolog, pedig, az, ha egyszer elérem, hogy a megszakításrutinba bekerüljön az USART kilép belőle, de egyből vissza is lép, és végrehajtja az ott lévő kódot. Tudom, a flag törlését az RCSTA reg olvasása megteszi, elvileg azzal sincs bajom. Csuán egyetlen karaktert küldök neki, és azt várom, hogy pontosan egyszer küldje azt vissza ne végtelenszer.
Mindez egy RS485 illesztőhöz készül.
Igyekeztem az Rx oldali hibákat is lekezelni, ahol alkalmaztam az ERRATA SPEN bittel kapcsolatos javaslatát. Próbáltam a Tx oldalon a megszakításjeltő (TXxIF) bitet figyelni de az sem hozott eredményt. Mivel csak egyetlen karakter küldök és vennék nem kell elvileg számítanom buffer megtelésre, és emiatti FIFO kialakításra.

Először is:

Azaz ha a 7. bit nulla, akkor minden INT tiltott. Nézd meg az interrupt logikai kapcsolási rajzát is, ott is jól látszik.

2. Ha használod a prioritásos megszakítást, akkor éremes lekezelési pontot létrehozni mindkettőnek ,akkor is, ha az egyiket nem használod. Hibakereséskor érdemes oda egy LED-et tenni, hogy lásd, nem fut-e rá valami, amit nem állítottál jól be.

3. A küldés előtt kell és utána is, megvizsgálni, hogy szabad-e a puffer.

4. Az RS485 driver irányváltása után kábelhosztól és drivertől függően várakozást kell beiktatni, különben csonkolódhat a csomag.

5. Az RC1IF-et csakazértis hagyd békén.

6. Az USART hibáit szép lekezelni, csak a hibák keletkezésekor nem mindig fut USART megszakításra a program. Ezért Timer megszakításban érdemes ezeket lekezelni, illetve időtúllépésekkor, ami ugyanaz...

7. Találgatni tudok, mitől, ragadhat be a megszakításba, talán azért, mert az adó a fogadott bájtot szintén visszaküldi valami miatt. Próbáld ki, hogy a Main: előtt kezdeményezel egy küldést, beindul-e a folyamat. Ha igen, akkor a kiküldött jel visszatér. Ez lehet elektronikai hiba is!
A másik, hogy a küldő nem egy bájtot küld, te meg összvissza forgatod az adás és a vétel irányt közben.
Végül de nem utolsó sorban, a PIC RX lábát fel kell húzni 1k-val Vdd-re! Ha ezt nem teszed, irányváltáskor zavarjel ül rá.

Jogos a megszakítás dolog. Eddig még mindig egyszerre használatam mindkét prioritást Most csodálkoztam rá, hogy valóban a 7. bittel minden INT et lehet tiltani, és nem csak a HIGH prioritást, szemben a 6. bit Low INT tiltás/engedélyezéssel. Valóban a kapcsolási rajzból jól látszik ez.
A többi érthető. Az RS485 egyébként már működik, az adó (PC) adott egymás után 2 karaktert, pedig nem tehette volna. Elővettem egy korábban épített áramkört és azzal adtam, erre rögtön meggyógyult.
Javaslatod hasznos a felhúzóellenállás tekintetében, mert mikor nagy impedanciássá válik a kimenet, elkezdhet lebegni, és a vevő képes bármit összeszedni. (igaz ez távolság, beállítás, kapacitások, időzítések, dekóder IC típus, környezeti zaj, stb függvénye)

Sziasztok!

Szeretném használni MPLAB szimuláció alatt a "Register Trace" funkciót a soros adás tesztelésére. A kiválasztott regiszter a TXREG lenne ( annak megállapítására, hogy a programom milyen adatokat küld ki ), a kiválasztott fájl pedig a projekt mappában lévő soros_ki.txt fájl. A szimuláció eredményeképpen semmi adat nem íródik a fájlba, noha a program működik, mert az "UART IO" ablakban megjelenik az üzenet ( és áramkörben is működik!). A csatolás, mentés, fordítás szerintem jó, mert egy másik regisztert kiválasztva (pl. PORTB ) annak az adatai lementődnek!

Az MPLAB két régebbi verziójával próbáltam: 8.70-es és 8.77-es, de egyiknél sem működött.
Még egy észrevétel: a file tartalmát csak külön nézegetővel lehet megnézni, mert az MPLAB alatt az egyébként sikeres mentés eredménye (pl. PORTB ) sem jelenik meg, ha megnyitom a projektben a txt-t ( frissítettem is, újramegnyitással ).

Van-e valami beállítás, amire nem figyeltem ?!

Előre is köszönöm a segítséget!

Steve

Szia!
"Debugger / Settings" menüpont "Uart1 IO" fülén az "Output to file" választása. Itt lehet megadni az állomány nevét is.

Szia!

Az OK, de a Kónya-féle könyv 3.kiadásában is említi ezt a módszert és nekem nem sikerül működésre bírni... Akkor ez most nem él ( a User Guide is tartalmazza, a TXREG-et ki lehet választani --> bug ?! ) ?!

Steve

Szia!
Úgy nézem a 8.88 -ban sem működik a Register Trace a TXREG -re.

Köszi, gondolkoztam rajta, hogy felrakom...

Viszont próbáltam, amit javasoltál ( eddig nem használtam a file-ba írást, kevés adattal csak a képernyőre küldtem ) és a képernyőn jó, de file-ba írásnál 8 v. 9. karakterből csak az utolsó 2 jó ( képernyőre íratva, ill. valóságban jól működik! )! Mi lehet az oka?


Steve

Ingyenes XC32++ fordító a 32 bites PIC -ekhez
Please note that this compiler is the Free Edition and will not build in PRO or Standard mode.

A szimulátorral szerintem valamit elböktek, egy sima TRIS és LAT állítgató programnál beírja az értéket, de ha átváltok másik fülre és vissza, ki vannak nullázva a regiszterek (bár ez lehet, hogy az MPlabX hibája). Kipróbálás szintjén csináltam vele még egy sima absztrakt osztályos-virtuális függvényes-öröklődéses dolgot, a szimulátor szerint rendben volt. Kíváncsi vagyok, lehetséges-e 16 bites vagy akár 8 bites PIC-ekre C++-t hegeszteni.

Régen, még az MPLAB 7.x idejében, volt IAR C/C++ for PIC18. A BoostC++ pedig talán még most is kapható.

Igazából úgy értettem, hogy az XC8 és 16 compilerekben vajon lesz-e ilyen lehetőség. Ha korábban már mások megcsinálták, és bevált, akkor elvileg lehet gazdaságos C++ fordítót készíteni kis PIC-ekhez is.

Minnél "fejlettebb" emberközelibb egy fejlesztői környezet, annál ócskább programot fordít. Erre jó példa a kis kirándulásom a Flowcode területére, ami nagyon kényelmes és gyors a fejlesztés oldalon, szinte mindent meg lehet oldani vele, de akkora programot készít, hogy alig fér bele abba a PIC-be, amibe C nyelven még a memória negyedét sem töltöttem meg kb. kétszer akkora programmal! Szóval szerintem ezért nincs és nem lesz C++. Nem ad annyival többet és a C tökéletesen illik egy mikrovezérlőhöz, ha asm szemlélettel programozzuk, mert azért a C-vel is el lehet szállni, ha nagyon a gyári könyvtárakra támaszkodunk és a PC-n bevállt módszereket erőltetjük kényelemből...

Teljesen igaz, de a bonyolultabb programokat átláthatóbbá teszi, és emiatt a fejlesztési idő csökkenhet (meg a váratlan leakadások száma is).

A váratlan leakadásokra nem biztos, hogy ellenszer !
Steve

Következetes és pontos programozással azért elérhető (és cél is), hogy már fordítási időben kiderüljenek a hibák (itt olyasmire gondolok, hogy a nyelv keretein belül ki kell használni a lehetőségeket: minimálisra szűkíteni a scope-ot, használni a const kulcsszót, stb). Amennyire én látom, a C++ szemléletével ezek a lehetőségek jobbak.

Szerintem nem a fordítási időn belül kiderülő hibák a problémák fő forrása, hanem a tesztelés, a gyakorlat során kiderülők okoznak nehézséget ! Azt meg egy magasszintű, a lényeget eltakaró programnál nagyon nehéz megtalálni!
Konkrét példa ( bár nem FlowCode ): az egyik ismerős CAN-t használt MicroC-vel és nem működött. Hosszas vizsgálódás és jelanalizálás után kiderült, hogy egy bitet nem kapcsol be a gyári függvény! Na én ezekre gondoltam!
Steve