Próbáltam 9600-al. Most 19200-al megy, 47000 táviratból most kb. 10 hibás 1000 ms-os scan rate-el, slave response timeout most 200 ms, delay between polls 400 ms. így nagyon keveset hibázik. Ha leveszem 200 ms-os scan rate-el, slave response timeout 80 ms, delay between polls 140 ms, akkor több. De 19200-on 25-28 ms alatt el kellene küldje a PIC a választ (53 bájt) szóval ha a slave response timeout 40 ms lenne, akkor sem lenne szabad hibáznia.

19.2-n fel millisec egy byte. Ha ilyen sebesseg mellett adatvesztes van, akkor valami nagyon nem kerek. Biztos, hogy a DS chip olvasasa okozza a gondot? Mondom, szerintem a DS iras/olvasas maximum. 60us-ra tilthatja le a megszakitast. Az USART-ot ez nem kellene zavarja. Igazabol nem tudom, hogy pontosan mit csinal a teljes program, ezert nem szeretnek okoskodni, de gyanitom, hogy interruptos UART rx/tx es egy olyan DS chip kezlessel, ami tenyleg csak max. 60us-ra tiltja a megszakitast, meg lehet oldani a dolgot.
Az USART Rx csak teszi egy gyurupufferbe a bejovo adatot, nem csinal mast. Majd a foprogram elszedi onnan.
Az adast akar egy timer interrupttal is megoldhatod, nem feltetlenul kell az USART tx interruptot hasznalni. Tudod, hogy egy karakter 520us-ig tart, akkor 530us-onkent jon a Timer interrupt, es sorba kuldi ki a byte-okat, és meg az RS485 driver kapcsolgatast is levezenyli precizen, nem kell a foprogramot delay-ekkel terhelni. Igy is lassu a processzorod. (Ez DMX-es adoknal ez megszokott dolog, mert egyes regebbi DMX vevok nem szerettek, ha a byte-ok kozott nem volt szunet, igy 48..50us timer interrupt vitte ki a DMX csomagot. Magam is csinaltam ilyet PIC18-ra.)

A DS chiphez meg lehet csinalni egy state machine-t, amit ciklikusan hivogatsz a foprogramodbol, es az minden meghivasnal megcsinal egy lepest. Resetet csinal, kivisz egy bitet, vagy beolvas egyet. Es persze osszerakja a byte-okat, ellenorzi a CRC-t a vegen.

Én is azt javaslom, hogy iktasd ki a DS kezelését és fix adatokat küldj válaszul a MODBUS kéréseknek. Kíváncsi vagyok a hiba arányra...

Ez jó ötlet, kipróbálom!

A program lelke a Timer1. A main függvényben kontrol flageket vizsgálok, amennyiben igaz, úgy végrehajtom, egyébként nem. A flageket a megszakításban engedélyezem bizonyos számú megszakítás esetén.
Amennyiben jön egy karakter uarton, a megszakítás megvizsgálja, hogy az 1. bájt-e, vagyis egyezik-e a PIC címmel. Párhuzamosan fut egy timer is (timer0), amit minden fogadott karakter után resetelek. Ha túlcsordul, akkor jelzi, hogy nem jön több karakter és engedélyezi a távirat ellenőrzést (a főprogramban).
Megszakításban nem vizsgálok minőségre, se mennyiségre, kivétel az első bájt, a cím. Ha túlcsordult a timer0, akkor modbus flag=1, amit a főprogram kiértékel. Ha minden adat stimmel, akkor válaszol, amúgy nem.
(A kiértékelés közben létrehozok egy másik buffert, amibe átmásolom a bejövő usart tartalmát.) Emellett lcd-re iratok, természetesen ott nem tiltok megszakítást és hőmérsékletet is mérek adott megszakítás után. Szerintem a hőmérés a gond, mert az USART Rx és Tx is megszakításban van kezelve. Pl.: Elkezdem kiküldeni az adatokat, közben vagy beugrik a meres_flag vagy már eleve ott van. Na most közben mondjuk olvasok egy bájtot, vagy épp reset-et küldök. A megszakítást tiltom, majd engedélyezem. A modscan vár 1,5 bájtnyi időt, ezt túllépem és máris dobja a csomagot.
Amiket észrevettem teszt közben az, hogy ugye a modscan fehér alapon feketével jelöli a kiküldött táviratot, fekete alapon fehérrel a kapottat. És általában amikor hiba van, akkor ez vagy összemosódik, vagy lemarad a kapott táviratból néhány bájt, vagy előlről, vagy hátulról. Hogy ez most azért van, mert adás közben 1,5 bájtnyi idő túlcsordul és ezért a modscan újra kiküldi a csomagot, holott a PIC még küldené, csak éppen túllépte az 1,5 bájtnyi időt, vagy esetleg nem jól van kezelve az RTS váltás, nem tudom. Az RTS alapban mindig magas szintű, ha jött egy távirat és jó, akkor alacsony szintre váltom, majd engedélyezem a TX interruptot, ahol elküldöm az előzőleg a főprogramban feltöltött buffert. Ha elment az összes karakter, akkor RTS_OFF.
Szóval nem tudom mi van.

Kipróbáltad?

Sajna csak holnap lesz rá lehetőségem, de ígérem, jelzek, miután kipróbáltam.

Már komolyan kíváncsi vagyok az eredményre!

Még egy óra, míg végzek, de tiszta ideg vagyok!!!

No, a helyzet a következő:
Ha letiltom a meres_flaget, vagyis egyáltalán nem mérek, csak a többi dolgot csinálom, akkor hibátlan a modbus 30000 üzenetből mind jó. Csináltam már azt is, hogy csak 1x futtatom le a mérést, utána nem. A modbus kérést hamarabb elindítom, mint a PIC-et, akkor miután inicializál a PIC a rá következő kérések is mind hibátlanok addig, míg el nem kezdi kiolvasni a ds-eket. Ott hibázott 1x, utána már egyet sem.
Ha mérek, de nem tiltom a megszakítást, akkor is van hiba(?), 30000-ből 50.
Eléggé érdekes a jelenség.

Legalább egyértelmű mi okozza. Amikor nem tiltod a megszakítást, milyen a mérés?
Érdekes, hogy megszakítás nélkül is hibázik. Biztosan mindenhol kivetted a megszakítás tiltást?

Tele van CRC hibával. Viszont a hiba most nem "összemosódás", vagyis invalid response to modbus query, hanem modbus timeout.

Én ezt a problémát próbálnám megoldani megszakítás tiltás nélkül. A gond, hogy nem könnyű regisztrálni az 1wire jelalakját, pedig jó lenne, hogy a határokon belül tudd tartani az értékeket, azaz lásd a hatást, ha változtatsz. Tárolós szkól jól jönne, esetleg PICKit2-t használni erre.

Van szkóp is, meg fogom nézni vele, mi megy ki a ds-re, illetve a modbusra. Viszont most néztem, hogy 120 ms-os lekérdezési sebességgel eddig hibátlan a modbus (1200 üzenetből eddig mind jó).

Sziasztok!
Tudnak olyat csinálni a rendszergazdák linux vagy ubuntu rendszer alatt, hogy ha én el akarom hozni az órán programozott fájlokat, akkor amikor felmásolom a pendrive-ra, átkódolják, hogy ne tudjam megnyitni? Sima .c programról lenne szó, de krixkrax van benne. Csak bizonyos fájlok vannak így "elrontva". Pl. a main.c~ tökéletesen olvasható, meg a .txt is, viszont a .h, .c, a kiterjesztés nélküli fájlok, és minden, amiből vissza tudnám a programom fejteni, nem értelmezhetőek. Van ötletetek? Arra gyanakszom, hogy ez direkt van így, mert az első órákon írt program minden egyes fájlja tökéletes, viszont a következőtől kezdve már kódolt. A csatolt fájl egy egyszerű számológép lenne. Mellette a main.c~ fájl tökéletes...
Találtam egy ilyet egy fájlban, lehet ez lenne a kulcs?

Barátom ez betalált ide nagyon......

Egyébként elvileg megoldható linux alatt ez a titkosítás dolog de ez szerintem nem az. Egyszerűen megsérült a file mert nem írta ki a pendrive-ra az egészet és időközben kihúztad.
Legközelebb add ki a sync parancsot és unmount-old a PEN-t mielőtt kihúzod úgy nem lesz baj.

Üdvözlet! Érdeklődni szeretnék hogy Debian wheezy-n van e olyan program amivel lehet PIC-re írni c nyelven kutakodtam googleba de nem sokra jutottam van valakinek valami ötlete?

MPLABX működik Linuxon is, Java kell hozzá. mplabx alá pedig fel tudod rakni a C fordítókat, amire szükséged van.

Sziasztok!

Hogy is van C-ben az hogy egy függvény paraméterét nem lehet (a függvényen belül) megváltoztatni? Mert mintha olvastam volna valahol, de nem emlékszem hogy hol. Aztán akkor nem foglalkoztam vele, mert akkor úgy tűnt hogy mégis lehet, de most megint mintha nem menne:


A Nop(); -on állva, VertAxis nem 0x30AD.

Ha érték szerint adod át a paramétert, akkor ha meg is változtatod a függvényben, akkor is a hívó oldalon nem fog megváltozni.



Itt a függvényhívás után a b változó értéke továbbra is három marad.

Ha viszont ezt írod:


Akkor itt a b értéke már 4 lesz a függvényhívás után, mert nem érték szerint adtad át a változót, hanem a változó memóriacímét adtad át, és a függvényben pedig az adott memóriacímen levő tartalmat növelted meg 1-el.


A kódodat próbáld így:

Ok, köszi, első két példád tiszta. Viszont én egy mutatót adnék át paraméterként, és a függvényen belül ezt a mutatót változtatnám meg. Tehát nem az értéket, ahová a mutató mutat, hanem magát a mutatót.
Tudom, ennek igy (angol billentyűzeten hol van a hosszú iiiii?) látszólag nem sok értelme van, hiszen akkor minek adtam át ha úgy is felülirom, mégis szeretném felülirni, persze nem igy egyszerűen egy konstanssal.

A fuggveny bemeno parametereit pontosan ugyanugy megvaltoztathatod, mint barmelyik valtozojat a fuggvenynek. Es meg is valtozik:

Debuggolok. Breakpoint a 5. sorban. VertAxis a 0x30AD memória címre kéne hogy mutasson. Kérdés, hogy miért nem? Nem értem... Helyette az a cím van benne, amit függvény hívásakor beletettem. Tudom hogy a kódnak ebben a formában nincs értelme, ráadásul mivel páratlan a cím, amikor felhasználom, majd address trap lesz belőle, de attól még működnie kéne.
Optimalizáció kikapcsolva. MPLAB X XC16.

Így próbáltad már?


VertAxis nem is lesz 0x30AD, hanem *VertAxis-nak kell annyinak lennie.

Szerintem a típuskonverzióval lesz ott valami.
Próbáld direkt beletenni a 0x30AD-t.
Vagy deklaráld eleve mutatónak a valami-t.

Ha jól láttam, nem a valami címét akarja beletenni, hanem az értékét...

Lehetséges, de akkor meg az uInt valami = 0x30AD; deklaráció nem stimmel...

Végül is ad egy értéket az uint változónak, majd próbálja uint* típusra konvertálni a mutatóba töltés előtt. Az a gyanúm, hogy a fordító ezt nem eszi meg, bár logikusnak tűnhetne.
A másik probléma esetleg az, hogy az átadni kívánt változó páratlan, olyan uint cím meg nincs, ha jól tudom. Meg kéne neki próbálni páros címmel is, lehet, hogy működne...

Szerintem azert nem az van benne, mert az optimalizacio (annak ellenere, hogy kikapcsoltad) igy latja jonak. Probald ki, hogy az 5. sor nem egy Nop(), hanem egy kulso fuggveny meghivasa a VertAxis parameterrel. pl: func(VertAxis); Es ott sem az a kerdes, hogy a VertAxis valtozo erteke mi lesz, hanem az, hogy a func() fuggvenynek mit ad at. Ha a 0x30ad-t, akkor minden rendben. De biztos lehetsz benne, hogy ez a kod igy teljesen jo. A (cast)-olas es az ertekadas teljesen szabalyos, mindet jol irtal. Egyetlen dolgot nem tudok, hogy ezen a PIC-en lehet-e int pointer paratlan erteku.

Igen, az értékét tenném a mutatóba, hogy a 0x30AD memória címre mutasson. Délután kipróbálom páros címmel is. Azért tettem közé a "valami" nevű változót, mert direktben sem működött: