ATMega8 chybovost seriove komunikace

Dobry den,
hned na zacatek bych rad podekoval za tohle forum ktere mi uz dost pomohlo. Ovsem narazil jsem na problem který jsem tu nenasel. Jako prvni jsem zkusil provetrat “stryce googla”, ale nenasel jsem dostatecnou odpoved.

Problem je v tomhle:
mam ATMegu8(dale MCPu) pripojenou prez MAX232 k seriovemu portu v PC. Atmega je nastavena pro rezim 16MHz z externiho crystalu. Jako komunikaci sem pouzil rezim 19200 8N1. V MCPu jsem pouzil kod primo z datasheetu k atmega8 na webu atmelu kde v nainializuji UART a v nekonecnem cyklu ocekavam jeden znak a ten pak vratim zpet prez UART. Vsiml jsem si jednoho nedostatku jednou za cas znak poslany z PC dorazi do MCPu jako znak jiny. Proto jsem kod upravil tak, aby MCPu pokud nedorazi znak ktery ma dorazit vypsal jaky znak dorazil a zahlasi ze doslo k chybe. Chyba neni pravidelna a z cca 100znaku jsou 3. vadne.

Zatim jsem nasel:
ma existovat jakasi CRC kontrola ktera pomoci nake hodnoty a propocitani XORama odhalit(dokionce i opravit) nejake chyby v prenosu.

dalsi moznost jako chack sum ktera ma spocitat vsechny bity a odecist je se dvema kontrolnima na konci pokud je vysledek 0 preneseny byte je povazovany za 0.

Ptam se ktera z metod je pro atmega8 vhodnejsi a prosim pokud by jste meli material s teorii o kontrole chyb ci funkcni priklad budu moc rad.
Dekuji za vsechny rady

tohle bude nejspis zpusobeny lehce rozdilnyma frekvencema ci necim takovym…

moznosti kontroly je hodne: CRC - to se hodi spis pro vice bajtu, casto se pouziva CRC na zpusob XORovani vsech prijatych hodnot…

pak je tu parita - lichej vs sudej pocet jednicek

vsechny tyhle “veci” se posilaji jako soucast dat - hlavicky… napriklad [velikost_dat] [CRC] [typ] [data][data][data]… parita je jen pro jeden BIT (a myslim, ze je snad i “oficialni” soucasti UARTu, jist si tim nejsem).

A neresi se vhodnost pro mikrokontroler ale pro konkretni aplikaci :wink:

Pozr idata sheet mas tam tabulku Table 63. Examples of UBRR Settings for Commonly Used Oscillator Frequencies (Continued)

pri 16Mhz vycgadza chyba 0,2%. ty mas 3%.

POsielaj jeden znak normalne a potom ten isty invertovany…potom vies lahko zisti na primacej starne ci to doslo v poriadku.

Atlan: Ty % v tabulce neudávájí chybovost přenosu ale odchylku od cílové baudrate :wink:

tak vas zase zdravim. Dekuji za rady podle toho co jsem zjistil tak ta odchylka je normalni proto dneska zkusim jednu moznost posilani te normalni a invertovane hodnoty to se mi celkem libilo, ale vysledek asi budu resit CRC8 nebo CRC16 s tabulkou protoze muj robot bude ovladan ne znaky ale slovy :smiling_imp: . Az to zvladnu tak se to i pokusim preposlat sem na forum. Pro lidi co to nemeli ve skole to nemusi byt uplne jednoduse pochopitelne.

Nevim, jesli nebude crc zbytečně složité. Na takové jednoduché věci se často používá xor. Nebo budeš mít jen několik málo konstantních předem známých příkazů a crc předpočítáno?
Až budeš tvořit něco dalšího, zkus zvážit nějaký převodník USB-232. Dělá se jich dost, přenos je spolehlivější a dosažitelná rychlost nesrovnatelně vyšší :wink:

ono jde o to v mem projektu pouziju (bud Edimax router BR-6104KP, nebo mikrotik desku 4110 ta ma 300MHz ale jen jedno USB.) komunikaci s mikrokontrolerem budu resit prave prez seriovou linku kvuli jednoduchosti a hlavne linux v techdle deskach ma jista omezeni(u toho mikrotiku je vice mista ale i tak seriak je nejsnazsi)Mikrokontroler bude pouze vyhodnocovat data z cidel a podle prikazu resit modulaci pro serva(to uz mam vyresene). Pripadne vystup na LCD z celeho systemu. CRC chci i kvuli tomu ze planuju do budoucna oddelit casti s mikrokontrolerama na minimalne 2 (1 obstarava LCDvystup a serva), druha resi cidla komunikaci budu resit po I2P(snad se to tak pise - myslim komunikaci po 2 dratech a adresovanim). Budu odesilat nekolika slovni vety na sbernici takze tam uz CRC ma sve opodstatneni ty testy s jednim bytem byla pouze testovaci.

S tím routerem je to dobrá věc, sám mám jeden projekt s Edimaxem, jen ten arm mi dal zabrat. Ale k té chybovosti, tam mám VELIKE pochybnosti!! Nekde musi byt chyba, to neni vubec normalni. Je ten MAX232 se spravnymi kapacitami? A napeti jsi zkontroloval osciloskopem (dáva to těch ±10V)? Jsou propojené země dobře? Nebo nemáš moc dlouhý kabel na RS232 (víc než 3m)? Me ta komunikace jede bezchybně v mnoha zapojeních a mnohem vyššíma rychlostma! A na komujikaci s tím Edimaxem zadnej MAX232 nepotrebujes, naopak potrebujes napeti konvertovat mezi 5V a 3,3V (a invertovat signaly)!

Nebylo by lepší přijmutý znak převzít pomocí přerušení než čekat v nekonečné smyčce. Já ve své aplikaci přijímám 3 - 4 ticíce znaků najednou které po 64 ukládám do eeprom a zatím jsem na žádný špatně přijmutý znak nenarazil. Ale jedu jen rychlostí 9600.

tak jsem se zase po nejake dobe vratil k tehle hracce. Jelikoz me zacal tlacit cas a termin odevzdani me prace do skoly se blizi neuprosne zacal jsem resit komunikaci. Problem pravdepodobne byl ve spatne zvolenych kondenzatorech. Nekde sem nasel “spatny datasheet” kde meli byt kondiky 10uF ale na ten max232 co mam doma patri 1uF od te doby komunikace jede jak ma.

to Petr: prosim mohl by jsi nejak srozumitelneji pro zacatecnika vysvetlit co myslis tim prerusenim? (vim co je preruseni akorad nikde jsem nenasel ze by sel UART pouzivat jinak nez tim nacitanim po znaku.)

Jinak router edimax jsem nakonec nahradil RoaterBoard 411. Ma to 680MHz procesor jeden miniPCI slot a hlavne 64MB NAND pameti:-) rozmery to ma 105mmx105mm a je to plna MIPS achitektura takze na hokus pokusy jak delane

Samozrejme, ze z UARTU budes nacitavat spravu znak po znaku.
Ale program nemusi byt na UARTe zaveseny pocas celej komunikacie. Ak pride novy znak, nastane prerusenie (ak ho aktivujes) a odskok na presne dane miesto v programe. Po ukonceni spracovania znaku (po ukonceni prerusovacej rutiny) sa program vrati tam, odkial bol vytrhnuty z prace tymto prerusenim.