Átszerveztem a programot, most 20 Mhz-en megyek, 9600-as BAUD-al. A helyzet a következő:
Néha, 5000-ből 1-2 invalid response hibával jelentkezik. Sajnos az adatforgalmat megnézve észrevettem, hogy a csomag első néhány bájtja hiányzik. A puffer mutatót jól kezelem, gyanítom, hogy az RTS vonal kapcsolgatása miatt lehet a dolog.
Max485-öt használok, hogyan javasolt az rts vonal váltása?
Most úgy van, ha bejött egy csomag, akkor meghív egy ellenőrző függvényt, ennek a függvénynek a visszatérési értéke határozza meg, hogy mit kell csinálni. Ha 0, akkor a csomag rendben ekkor állítom az RTS vonalat egybe, majd meghívom azt a függvényt, ami a választ készíti elő, ezt követően pedig válaszolok. Ha kiürült a küldő pufferem, RTS = 0.
Igy elkerülhető lenne a késleltetés az RTS vonal kapcsolgatása miatt.
De valami csak nincs rendben. Mindenképpen el szeretném kerülni a delay használatát, van valami javaslat?

Bár gondolom így van, de azért rákérdezek: az RTS vonalat akkor kapcsolod ki, amikor az utolsó bit is kiért, vagy pedig akkor, amikor a pufferből átkerül az adat a shift regiszterbe?

Sajnos a kábel hosszától függően mindenképpen szükséges időzítés a kommunkáció irányának megváltoztatása után, az első adatok előtt és az utolsó adat kijutását is meg kell várni...

Amikor kiürül a puffer, be van téve egy 3,5 karakter időt késleltető timer és utána kapcsolom ki.
Az elvileg majdnem 4 ms.

A késleltetés úgy gondoltam elég, ha a függvény meghívása előtt kapcsolom az RTS vonalat.
Az kb 4-500 us. A modscan scan rate most 1000 ms, de 400 ms-el próbálgattam.
A delay between polls pedig 200ms.

Szóval így:


Majd a reset_t0():


Ahol a reset_t0():


Bekapcsolni pedig:

Urak!

Ezzel a módosítással már szépen, hibátlanul működik.

Hogy tudnám ezt elkerülni? Valaki esetleg?

Ha belefér az időbe és nem a megszakításban várakozol, akkor maradhat így is, mert a fontos dolgok úgy is megszakítják.
A vonalak váltása időt igényel, ezt nem tudod elkerülni.

Értem. És mennyi a javasolt késleltetés? Nekem a DE RE össze van kötve és +Vdd-re van csatlakoztatva egy 4,7 K-s felhúzón keresztül és rá van kötve a PIC egyik lábára. Ti is így használjátok? Nem akarok visszaolvasást küldéskor...Mennyi késleltetés javasolt?

Most ilyen hibám érkezett (lásd csatolmány). Bár meg kell mondjam felturboztam a scan rate-t a modscan32-n 150 ms-ra. Ekkor jönnek ezek a hibák. Lehet, hogy ez már nem is az én vezérlőm hibája, hanem az RS232 - USB konverteré?

Meg lehet keresni a minimumot(kábelhossz (kapacitás, induktivitás) függő), de szerintem nincs értelme kihegyezni. Ha ettől nem lenne elég a sebesség, az régen rossz. Az RS485-nek, pontosabban az egyszerű soros vonalaknak nem a sebesség a legfőbb erősségük.

Ha jól látom lemaradnak az adatok, helyette újabb "fejlécet" küld el a PC? Hogyan detektálod ezeket az adatokat?
Mindenesetre érdekes, de ez nem biztos, hogy hardwer hiba. Az átalakítók is tudnak érdekesen viselkedni. Akkor lehetne ezt kiszűrni, ha lenne valós COM-od. Én vettem egy PCI kártyát...

Kezdem sejteni a dolgot. Tehát a PC küldi a csomagot és nem válaszol a PIC, ezért lejár a 150ms és jön a következő kérés. Ez lehet a PIC program hibája is, de lehet az átalakítóé is, vagy még mindig rövid az irányváltási idő. Persze egy fordulónak bele kell férnie a 150ms-be minden eshetőséggel...

Mármint miket?

Egyébként az irányokat egyszerűen úgy kezelem, hogy a slave mindig bemenet, kivéve ha fel van jogosítva a válaszra. Tehát ha küldeni kell, akkor irányváltás kimenet, időzítés vonal beálltára, küldés megkezdése megszakításban, utolsó bájt kiérkezésének figyelése, újra bemenetre váltás.

A képen...

Modscan32-vel. Figyelem, mikor hibázik, majd printscreen.

Én is ugyanígy.

Volt ott valami 3,5 karakteridő várakozás az adás utáni vételre váltás előtt is, nem? Vagy elnéztem...

Igen, az eredetiben volt, de már átírtam így:



De így is van egy-két hiba. Mostmár eléggé bosszantó...

A megszakításban való küldést így oldom meg:

És így hívom meg:

Hát hasonlóan kezeled.
Ez miért jobb, mint a delay?

Illetve itt nem használsz késleltetést?

Nem jobb, csak mindegy. Egyébként függvényhívás nélküli várakozás. Nem szeretem a C függvényeit...

A TX1_cik akkor lesz nagyobb, mint a Data_TX1_Size(adathossz), ha már kiment mindegyik bájt. Az utolsó bájt kilépése után még egy megszakítás fog történni, ekkor már nincs mire várni. while-t, vagy bármilyen várakozást megszakításba tenni nem illik, még ha egy karakternyi időről is van szó, ami egyébként rengeteg utasítás helyét emésztené fel...

Ez nem lehet igaz!!!! 2000-3000 üzenet hibátlan, utána be-becsúszik 1-2 hibás újra. Egyszerűen nem értem. Akkor ezt vegyem ki?

Mi a gond azzal, hogy néhány csomag elvész? Ez alapértelmezés egy wifinél, még is működik...

Ha ide akkor jön be a megszakítás, miután az utolsó adat kiment, nincs szükség a TRMT vizsgálatára.

A TX megszakítás akkor jön, ha a Tx buffer regiszter üres, az utolsó karakter akkor ment el, ha az utolsó karakter betöltése után a TXSTA regiszter TRMT bitje 0 értékű lesz. Egy "üres" adó (jó régen nem kellett küldeni semmit sem) egymásután két karaktert képes átvenni, az első egyből átkerül a léptető regiszterbe, a másodikat pedig a buffer tárolja. Ebből az jön ki, hogy az utolsó karakter betöltése után a TXIF akkor lesz ismét 1 (megszakíáskérés), ha a karakter átkerült a Tx léptető regiszterbe. A vonalat pedig csak ez után akkor lehet vételre kapcsolni, ha a TRMT jelzőbit is 0 lesz. Sajnos a TRMT nem okoz megszakítást.

Nem vitaképpen, mert ezen nem lehet, de akkor hogyan létezik, hogy hibanélkül működik?

Akkor ezek szerint mégiscsak jól tettem, hogy benne van. Nemde?

Nem akarok olyan programot írni,a mit nem értek, miért működik / nem működik.
Meg szeretném érteni, mit rontok el. Csupán ennyi lenne. Amúgy ha megnézed a kódot,
Vagyis beállítja a kimeno_puffer.UARTIntTxBufferEmpty egybe, de csak a következő ciklusban vizsgálja meg:

Nem tudok erre mit mondani. Nekem működik. A te megoldásodat nem teljesen látom át, mert sok a felesleges sallang. De ettől még működnie kéne, ha hibátlan. Nem stílustanulmányt kell írni, csak egy jó programot.

A felvetés szerint egyébként a programom nem működhetne, mert az utolsó bájt a CRC alsó bájtja. Ha nem várnám meg míg kiér, soha nem lenne elfogadva CRC hiba miatt. Márpedig ha tényleg úgy működik ahogy Hp41C leírta, nem működhetne, mert 19200-on kb. fél msec egy bájt ideje, a kikapcsolás viszont usec nagyságrend alatt van.
Érdekelne, hogy mi miatt tud működni egy elvileg lehetetlen működés!

Kipróbálhatnád, hogy kikommenteled a TRMT sort, mi történik!? Ez csak fél perc...

Igazából annyira nem akartam megbonyolítani, van egy puffer tele jelző, egy puffer üres jelző, egy puffer adat számláló, meg egy adatmutató. A puffer tele jelzőt, puffer üres jelzőt ki lehetne hagyni, mert egy if-el kiderülne, de így oldottam meg. Holnap kipróbálom kikommentelve azt a sort, de azt hiszem volt már úgy, hogy nem volt benne és nekem is működött csak több hibám volt.