Ez igaz, de start + 8 bit + stop bitet visz át és a bit közepeknél vesz mintát a start lefutó éltől kezdve... azaz 10 bitet visz át, ami azt jelenti, hogy elég nagy hiba kell hozzá, hogy rossz értéket érzékeljen ( előző vagy következő bitbe mérjen bele!), nem 1,3 % !

De gondolj bele, egy több kilobájtos folyamatos adatcsomagról van szó. Az első startnál a közepén lesz a mintavétel, utána a lassabb vevő végigmegy a bájton a maga ütemében. Közben a gyorsabb adó nem vár, tehát a következő bájtnál már nem a bit közepén lesz a mintavétel, hanem kicsit arrébb. Aztán ezt a hibát addig göngyöli a rendszer, hogy egyszer egy bájtban lévő 0-át érzékel startnak vagy stopnak.
Egyébként nagyon egyszerű kipróbálni. Egy pic kell hozzá, meg egy Pickit2. Állíts be két eltérő sebességet és nézd meg mit kapsz.

Ezt nem tudom megmondani, de eddig amit teszteltem adat küldés és fogadást az mind működött, tehát elvileg jól szimulálja a kapcsolatot.
Az, hogy nagy sebességnél is, így tesz e, azt nem tudom megmondani..
Arra gondolsz esetleg, hogy a szimulátor kekeckedik velem, téveszt nagy sebességnél?

Hp41C: "Ráfutás történik"
Ez szinte biztos.
Csak nem értem hogyan lehetséges, hiszen a főprogram addig nem küld ki visszaigazoló adatot ameddig PIC nem végez a dolgával.
Ha végzet, csak utána, utolsó műveletként küldi ki a visszaigazolást PC-nek.
PC meg erre vár, ha érkezik akkor ismét küldi a soron következő adatot.
Nem értem, ha tartják a protokollt, akkor nem lehetne ráfutás.


Nem biztos, hogy jól értem, de az első adatokat sok esetben veszi, de random képes leállni az egész.

Közben gyorsan leellenőriztem úgy a programot, hogy egy Error változót tettem be a megszakításba az adatvesztések figyelésére.
Nincs adat vesztés, csatolom a képet.

Nos a következő a helyzet, hátha tudunk belőle következtetni valamire.
PC-s programban az adatküldéshez tettem be elsőnek 1ms-os késleltetést.
Ezzel valamelyest stabilizálódni látszót, de sokadjára csak sikerült neki leállni.
Majd megnöveltem 2ms-ra és stabilizálódott az adatfolyam, nem áll meg.

Ez nagyszerű is lenne kisebb adatcsomagok esetében, de már egy 16Kb vagy a maximum 1Mbit-es fájl átpréselése komoly időt venne igénybe.
Szóval a késleltetésnek nem szabad benne lennie.

Idézet:
„Az első startnál a közepén lesz a mintavétel, utána a lassabb vevő végigmegy a bájton a maga ütemében. Közben a gyorsabb adó nem vár, tehát a következő bájtnál már nem a bit közepén lesz a mintavétel, hanem kicsit arrébb. Aztán ezt a hibát addig göngyöli a rendszer, hogy egyszer egy bájtban lévő 0-át érzékel startnak vagy stopnak.”

Ez így valóban okozhatna hibát ( ezt is ki lehet olvasni kerethibaként!), de a kérdező ezt írta korábban:

Idézet:
„1. PC adat küldés PIC-nek
2. PIC adat fogadásának vissza igazolása (adat küldés PC-nek)
3. PIC feldolgozza az adatot
4. PC várakozik PIC visszaigazoló adatra
5. Ismétlés az elejétől.”

Így szerintem "ül", amit írtam !

1. A PIC18F442 -ben levő usart a Baud Rate 16 szorosával vagy 64 szeresével vezérel egy "Data Recovery" egységet. Adatlap Figure 16-4. Ennek feladata a Start bit felismerése és a további mintavételezés idejének beállítása. A "szinkronizáció" minden keretnél megtörténik. A hibát nem göngyöli tovább, hiszen a következő start érzékeléshez 16 ill. 64 szeres órajelet használ.

2. Elcsúszásnál az a kritikus, ha a startbitnél beállított idő az utolsó bit közepéről elcsúszik a bit elejére vagy a bit végére. Mivel 10 bit egy keret 8n1 formátumban és fél bitidő a legnagyobb csúszás, így maximálisan 5% órajel eltérés okozza a fenti esetet. 1,3% a bitidő 0.13 szorosának megfelelő elcsúszást okoz, ami bőven biztosítja a hibátlan vételt.


Ezen jót múlattam....
A PICkit2 2.61.00 programban szoftverrel van megoldva a soros vétel / adás. Nézd csak meg, hogy hova csatlakozik a PGD ill PGC vonal. A RA2 és RA3 lábakra. A belső UART pedig a RC7 - RxD és RC6 - TxD.
Első módosításom volt a TxD láb felszabadítása, egy komparátorral az RxD -re vezetni a PGD vonalat. Így a PICkit2 1.4V -os jelszintű kapcsolatot is kezelni képes akár 115200 Baud -ig.
Annyi viszont elérhető a PICkit2 UART tool -jával, hogy a felhasználói Baud beállítással 9600 helyett 9120 illetve 10080 közötti értékekkel próbáljunk a küldeni adatot a PC -n 9600 Baud -dal működő soros vonalának (szint illesztéssel).

Idézet:
„A hibát nem göngyöli tovább, hiszen a következő start érzékeléshez 16 ill. 64 szeres órajelet használ.”

Igaz, legfeljebb a STOP idő rövidül vagy nyúlik egy kicsit a byte-ok között!

Közben észrevettem, hogy nem pontosan ugyanarról írunk. Szinkronhiba. Én az eredeti felvetés (min. 16kb adatfolyam) alapján jegyeztem meg mellékesen, hogy ahhoz komoly pontosság kell. Egy bájton értelemszerűen nincs ez a hiba. Úgyhogy mindkettőnknek igaza van, csak éppen a probléma más-más stádiumában járunk.

A Pickit pont azért jó UART játékokra, mert szoftveresen kezeli a dolgot. Vagyis egészen egzotikus Baud értékeket lehet megadni és így tesztelni az eltérő sebességek közötti driftet.
Arra céloztam, hogy eltérő Baud értékeket beállítva és binárisra konvertálva az adó és a vevő értékeit, úgy lehet látni a csúszást, mint egy logikai analizátoron.


Csak hát Péter, (mint jeleztem) 3,5%-os hibával használja az USART-ot, amihez ha a PC program hozzácsap még egy keveset, hibahatáron lehet.

A többi evidencia és ugyanaz a félreértés benne, amit az előbb írtam, ti. én végig ping-pong nélküli, folyamatos adatfolyamról beszéltem, nem egy bájtról.

Valójában nem is pár byte-ról van szó, hanem maximum 8Mbit hosszúságú adatról.
Ha csak pár bájt kellene nem pattognék a dolgon

Az előbb visszavettem a sebességet 9600-ra és persze mindent ennek megfelelően állítottam be, hogy elkerüljem az esetleges elcsúszást.
Ezt az értéket azért elég pontosan be lehet állítani szóval ennek az elcsúszásnak a hibáját ki is lehet zárni.
Sajnos ugyan úgy megakad az adatfolyam.

Nem fogod megúszni a buffereket...
Az alábbi kéen egy 18F2550 egyszerre tart kapcsolatot USB -n és UART -tal a PC -n futó programokkal, közben veszi a DCF adást, kezeli az infra távirányítót és még az időt is számolja (a dátumból a hét napját is). Meg sem kottyan neki...

A PIC vette az első karaktert, és beírja a TXREG -re majd megvárja, míg az adó elküldi. Azonban a PC ez alatt az idő alatt beküldhet két adatot is. Az elsőt már akkor elkezdte venni a PIC, amikor az előzőt az RCREG -be tette, a másodikat pedig a TXIF -re való várakozás alatt. Az RCIF kiszolgáló rutin szépen kiolvassa a második adatot is és felülírja a még fel nem dolgozottat a Result nevű változóban.

Pontosan ezért írtam, hogy vegyél fel egy vételi buffert és abba sorban tedd bele a vett adatokat. Az előbb linkelt képhez tartozó PIC programban az UART vételi és adási puffer 64 - 64 byte.

Van rá lehetőséged, hogy leteszteld a PC-s programom? (Vagy bárkinek)
Egyszerre 0x20-tól 0x32-ig küld egy sorozatot.
Port kiválasztássávalt azonnal küldi az adatot.
Valamilyen Microsoft keretrendszer kell majd a futtatáshoz.
Bár nem biztos.
Közben kipróbáltam benjami programját és az övével is ugyan ez a bibi.

Előzőben csatoltam a teljes proteus projektet is, hátha valamit nem veszek észre..
Bár már elvileg minden úgy van ahogyan kell legyen..

De át tudom tenni MPLAB-ba is ha az jobb. (csatoltam)

Nálam ez a PC-s program nem indult el, sem 64bites Win7, sem 32bites XP alatt, pedig mindkét gépen volt COM port a gépen.

Mit ír ki? Valami keret rendszer kell hozzá.
Win7 64Bit-esem van..

A mellékletben a hibaüzenet képe

Win 64-es alkalmazás és kell hozzá "Microsoft Net Framework 4.5" keretrendszer.
Elvileg innen tölthető: Bővebben: Link

Én is mindig Rx - Tx buffert használok a kommunikációhoz. Az Rx buffer használatának okát értem pl ráfutás hibák elkerülése végett. Persze a buffer is betelhet de az egy másik történet.
Viszont Tx buffert azért használok mert minden ajánlás szól róla. Ugyanakkor nem értem miért van rá is szükség. Ott nem tudok ráfutásos TXREG írás hibát elkövetni, mert az monitorozható.
Akkor miért is kell a Tx buffer?

Tx buffer? Pl. azért mert a programod el szeretne küldeni mondjuk 23 bájtot. Ha buffer van gyorsan belesöpri és már megy is tovább a programod a többi dolgát elvégezni. Buffer nélkül? Akkor meg ott várakozhat amíg az utolsó bájtot is be nem taszigálta a TX-be.

Egy vett üzenetre lehet egy több karakteres válsz is. Ha nincs TX buffer, a feldolgozás elakad addig, amíg a válasz utolsó karakterét is elküldte az UART. Ha van buffer, a várakozás leválik a feldolgozásról, a küldés nem fecsérel el CPU időt. A válasz karaketrei bekerülnek a TX bufferbe, onnan egy kicsike megszakítás kezelő elküldeti, ahogyan az adó tudja...

Nálam se nem és nálam az összes .NET fent van a Visual Studio miatt, de system.io.filenotfoundexception hiba kód arra utalhat, hogy nincs meg egy DLL fájl az exe mellet nincs valami dll fájl?

Ne haragudjatok srácok, hogy túráztatlak benneteket ..
Tiszta bugyuta vagyok, hogy azt nem csomagoltam mellé.
Itt szívók vele egy órája egy másik gépen, hogy mi lehet és eszembe sem jutott, hogy a dll-t hiányolja
Már kicsit el vagyok kámpicsorodva az UART miatt, hogy már 1 hete küzdök vele és csak nem akar összejönni és még előttem a memória kezelés..

Működése:
Port csatlakozás után azonnal küldi az adatokat, jelen esetben : 0x20-tól 0x32-ig.
Ha lefutott, akkor megszakítjuk a kapcsolatot majd újra kapcsolódunk, akkor ismét lefut az adatküldés sorozat.

Ezt a programot te írtad?

Persze. Tudom nem nagy szám de egyelőre elég lesz. Majd kicsit kibővíteni.

Én összedobtam egyet gyorsan. Remélem működik. (proteusba ment)

Szerk.: a send special-al jelöltem, hogy 0x20-0x32 ig aztán kapcsolatbontás kapcsolódás és 0x10-0x32 újra.

Mit kell néznem, ezt produkálja, 115200-ra állítottad a comport baudrate-t?
Amúgy egyel visszább ott a teljes proteus projektem abban meg tudod nézni a kódot is amit írtam hozzá.

x jelentése: annyiszor valósult meg a főprogramban a feltétel vagy is ennyiszer észleli az adatot
Size: ennyiszer volt megszakítás.
Result: ez az utolsó adat amit beolvasott
Hiba: ha nincs vagy hibás adat érkezik

Sziasztok!
Kell-e módosítani a PIC18F2550 hid bootloader projektben a linker scripten valamit ha PIC18F2550-hez szeretném használni? Ugyanis felismeri a bootloader program, de törlés közben lefagy, és ha újra rádugom az USB-re akkor már nem is indul el többet a bootloader.

Húú ezzel én is szívtam anno, ha jól tudom akkor a memória területet le kell foglalni a HidBootlader-nek. Azt hiszem ehhez van is külön linker állomány, azzal működnie kellene.