na 19200bps končej tak ty 89S51 a spol…
Při tvym Xtalu 7.3728 bys moh až do 230.4kbps
a při 16MHz do 2Mbps
To asi ne… jesli se dobre pamatuju, tak pri obsluze 7-segmentovky buzeny posuvnym registrem jsem to tam tlacil rychlosti 2Mb/s 
Maximalni rychlost uartu x51 je stejna jako rychlost provadeni instrukci (Fosc/12 nebo Fosc/6 v X2 rezimu). Byl to ovsem mod 0 (synchro). Pri modu 1 jde dostat 62.5KBd/s
hmm… synchro… tim by šlo tlačit až 2.75Mbps… (při 33MHz taktu)
Nechci do toho kecat, ale když zapisuješ do nějakého 16.bit registru tak nejdříve zapsat high a potom až low !! Ajak koukám, tak to máš všude obráceně.
Start: ldi R16, low(RAMEND) ;Nastaveni stacku
out SPL, R16
ldi R16, high(RAMEND)
out SPH, R16
[code]ldi R16, low(UBRR)
out UBRRL, R16
ldi R16, high(UBRR) | (1<<URSEL)
out UBRRH, R16
[/code]
A hlavně jsem nepochopil proč máš na začátku
[code].ORG 0x000
rjmp Start
.ORG 0x030
Start: ldi [/code]
můžeš mi objasnit proč tam máš to org $30 ???
Díky
Ty seš si tim všim ale nějak jistý.
O tom že se do kteréhokolivb 16b registru musí přistupovat nejdřív H a pak L, jsem u stacku (například ještě nikdy neslyšel). Pokud to tak má být (nechci tvou radu odsuzovat), ale dokaž to.
To s tím UBRR funguje víc než spolehlivě, nevím v čem by tam měl být problém. (to samé se stackem).
Jinak, říkají ti něco vektory přerušení?
Asi jsi to nepochopil, ale všechny jsem je přeskočil, a vlastní program začíná až za nimi. Nebo je to taky chyba? 
Mám to tam třeba proto, že později když využívám přerušení, nemám tolik práce úpravami programu. Pokud to byla připomínka k tomu, že to zabere 60B místa navíc, tak s tím problém nemám, jelikož můj nejdelší program na AVR zatím nepřesáhl moc přes 100B.
EDIT:
V datasheetu se o pořadí ztápisu SPL a SPH nic nepíše. V simulátoru AVRstudia to taktéž funguje pro obě pořadí, takže to je s nejvyšší pravděpodobností jedno. O pořadí zapisování do UCSRC/UBRRH a UBRRL se tam také nepíše. V reálu to funguje pro obě pořadí, v simulátoru je u mega8 (nebo to bylo mega32?) chyba, a nefunguje to vůbec.
Tak ten přístup k 16bit. registrům je snad pro všechno stejný ne ?? Neříkám, že to vím na 100% ale dělám to u všeho a zatím stím nebyl problém. Lepší je “simulovat” přímo na MCU… To s tím vektorremm jsem pochopil tedy správně že sis posunul začátek programu … A takse na mě nezlob tedy no . jen jsem chtěl přispět
OK, vpohodě. Myslím že jediná zvláštnostz práce s 16b registry se kterou jsem se zatím setkal je u ADC, kde se musí datové registry číst ve správném pořadí, jinak dojde k chybě.
Program vždy nejdřív odsimuluju (pokud je třeba), apak programuji do MCU. S pořadím zápisu jsem zatím u ničeho neměl problém.
ALe aspoň dík na to upozornění, aspoň pro příště, až se to bude chovat nějak divně, budud aspoň vědět kde hledat problém v prvé řadě 
BTW: Zatím jsem se k otestování ADC v reálu nedostal 
Musím to někdy napravit).
Jinak dík, Honza
Na pořadí záleží jen tehdy, pokud se jedná o přístup k priférii přes temporary registr. Jedná se pouze o ADC a 16b timer, kde se vyžaduje číst nebo zapisovat 16b v jediném okamžiku, což jednou instrukcí nelze realizovat. Temp. registr je společný pro všechny periferie, takže pozor při používání přerušení.
Este raz a skusim pomaly.
Zaciatok komunikacie je detekovany prvou dobeznou hranou po zapnuti zariadenia a nastaveni UARTU. Vtedy mcu vie, ze prisla dobezna hrana start bitu. Resetne si svoj interny citac (s presnostou 1/32 dlzky trvania prijimaneho bitu) na sledovanie bitov uartu. Po dobe trvania 1/2 bitu (pri 9600Bd 52us) si otestuje, ci je vstupny signal este stale v nule (testuje to na viac krat, ale to teraz nie je podstatne). Ak ano, rozhodne sa, ze sa jedna o platny zaciatok prijmu noveho bajtu. Prednastavi si skenovanie nasledovneho bitu na 104us (zjednodusenie povedane).
O 104us otestuje hodnotu linky a stav vlozi do prveho bitu prijimacieho registra.
O dalsicjh 104us zarotuje prijimaci register, otestuje si hodnotu linky a nacitany stav vlozi do prveho bitu prijimacieho registra.
Toto zopakuje este 6x. Tak prijme 8 datovych bitov (samozrejme pri nastaveni na prijem 8 datovych bitov). Ak je v prenose este nastavena parita, vypocita paritu prijatych bitov a o dalsich 104us porovna vypocitanu hodnotu s prijatou. Ak mu sedi, este pocka dalsich 104us, oskenuje prijimaci pin a ak nacita log. 1 - platny stop bit, prehlasi bajt za priajty. V opacnom pripade vyhlasi chybu parity alebo ramca, alebo co uz mu len vyjde.
Ak sa prijimacia a vysielacia frekvencia bude lisit napr o 2%, potom pri prenose 8N1 sa testovanie stop bitu nebude odohravat presne v jeho strede, ale 20% trvania bitu od tohto stredu, cize miesto v polovici bitu (50% trvania bitu) az v 70%, pripadne v 30% trvania bitu (skoro v jeho tristvrtine). Tento posun je mozne este stale povazovat za bezpecny pri komunikacii cez UART. hranicny stav je v okoli 90-95% vzhladom na mozne skreslenie signalu pocas jeho prenosu na vacsie vzdialenosti.
Toto cele pre 9600Bd trva nieco nad 1ms.
Prijem noveho bajtu sa zacina zase dobeznou hranou - start bitom a cely proces zacina od zaciatku. To znamena, ze sa sledovanie bitov znovu zosynchronizuje a nedochadza k aditivnemu posunu skenovania bitu so vzniknuvsim predchadzajucim posunom.
Ak zacne komunikacia vypadavat po 5 minutach komunikacie, nema to ABSOLUTNE nic spolocne z rozsynchronizovanim prijmu v ramci jedneho bajtu pri nezhode taktovacich frekvencii oboch zariadeni mensej ako 2%.
To by muse zacat vypadavat pri prvom posielanom bajte. Akonahle prejde bezpecne prvy bajt, bezpecne prejdu aj dalsie bajty, lebo asynchronna komunikacia sa VZDY zosynchronizuje pri dobeznej hrane start bitu. On tam ten start bit v tej sprave presne na to je.
Tvrdenie, ze bez Xtalu pojde ‘mozno’ aspon synchronna komunikacia je dosledkom nepochopenia principu synchronnej a asynchronnej komunikacie.
Samozrejme, ze aj asynchronna komunikacia musi byt synchronizovana a to hned dvoma prvkami.
-
obe strany musia mat dohodnutu rovnaku prenosovu ryhlost a parametre komunikacie - pocet bitov, parita, pocet stop bitov
-
zaciatok komunikacie - prijmu bajtu - je vzdy synchronizovana start bitom
Na rozdiel od asynchronnej komunikacie synchronne komunikacie (napr.I2C, SPI) okrem datovych vodicov obsahuju este aj vodic CLK, ktory synchronizuje prijem/vysielanie kazdeho bitu samostatne.
Pri UARTE sa CLK neprenasa, preto sa v jeho pripade jedna o asynchronnu komunikaciu.
Vyhoda synchronnej komunikacie je v tom, ze podruzne zariadenia ako pamate, AD/DA prevodniky a co ja viem co, nemusia obsahovat vlastny zdroj presnych hodin na nacasovanie komunikacie. Druha dost dolezita vlastnost je moznost implementovat tieto synchronne rozhrania programovymi prostriedkami pricom nezalezi na tom, ze cas medzi dvoma zmenami CLK musi byt rovnaky. MCU si obsluhuje synchronnu zbernicu “ako mu vyjde”. To znamena, ze obsluha SPI moze byt kludne prerusovana cinnostou casovacov a UARTOM, mcu vzdy zapise/nacita spravne data i pri nerovnako trvajucich impulzoch CLK.
Atmel tvrdi, ze jeho interny RC je mozne nakalibrovat tak aby v sirokom rozsahu pracovnych teplot sa taktovacia frekvencia nelisila o viac ako o 2%.
Podla datasheetu, napr k ATmega8 si treba najprv vybrat zakladnu frekvenciu interneho RC oscilatora a to pomocou fuses CKSEL3…0
bud 1,2,4 alebo 8MHz.
potom sa hodnotou v OSCCAL donastavi v rozmedzi 50%-100% (min frekv) vybranej frekvencie pomocou CKSEL. OSCCAL je 8 bitovy register, tak urcite sa nebudu dat nastavit frekvencie s krokom 1Hz, ale v rozsahu 100% (1-2,2-4,4-8MHz)je 255 krokov, co je umoznuje nastavenie pozadovanej frekvenice cca na 0.5%. A tam sa uz daju najst frekvencie, napr 7.3728MHz, ktore maju velmi dobru toleranciu k beznym prenosovym frekvenciam az do 230.4kBd. To by malo hadam stacit.
Rozpisal som to preto tak podrobne, aby bolo jasne, ze ak sa niekomu zacne rozchadzat komunikacia po 5 minutach, musi hladat chybu inde ako v rozdielnych frekvenciach oboch zariadeni. Dufam, ze som to trochu objasnil, pripadne pomohol.
Martine, myslím že se to už řešilo a dořešilo. Myslím že je zbytečné to rozpitvávat dál. Chápu, jak je to s tím starbitem, vysvětlil mi to jeden známý, co je odborník na programovatelné obvody.
Je to přesně podle mé původní doměnky: Bity se musí testovat na vícekrát, tj že taktovací frekvence obvodů UARTU je ve skutečnosti vyšší než přenosová, aby obvody mohly provádět zákroky, jako například vícenásobné testování bitů a podobně.
Princip UARTU jsem pochopil správně, ovšem nikde se nepsalo o tom, že se bity testují vícekrát, a podobně.
“Tvrdenie, ze bez Xtalu pojde ‘mozno’ aspon synchronna komunikacia je dosledkom nepochopenia principu synchronnej a asynchronnej komunikacie.”
To že jsem řekl? Jestli jo, tak jsem plácnul pěknou kravinu.
S USARTEM na mě nechoď, o něj jsem se nikdy nezajímal, a mám u něj mnoho chybějících informací o jeho principu a podobně. ALe někdy se na něj určitě také podívám.
Chtě l bych zkusit připojit k MCU PS/2 klávesnici, kde funguje komunikace podobně jako USART, jak je to ale moc podobné zatím přesně nevím, a žbude čas, tak to prověřím.
OK
nejak som omylom znovu reagoval na Tvoj prispevok z “18 listopad 2008”
a mal som pocit ze sa ten problem vynoril znovu.
Este raz sorry 
Inak ked si robim sw UART, sledujem stred bitu iba jeden krat v strede. Z mojich skusenosti to pri rychlostiach do 19200Bd bohate staci i na vzdialenosti 1km. Ten signal nie je v strede bitu zdeformovany odrazmi na vedeni, len nabezne a dobezne hrany. Tie deformacie pri tak malych prenosovych rychlostiach nezasahuju o viac ako 15% ku stredu. Ale pokial viem, vsetky hw UARTY testuju ten stred na tri krat. Na samotny princip to vsak nema vplyv.