Založen: May 27, 2008 Příspěvky: 35 Bydliště: Jičín
Zaslal: ne leden 23 2011, 17:23 Předmět: PIC16F877A a PIC16F627A zlobí UART
Zdravím, nedaří se mi rozchodit komunikaci mezi těmito dvěma procesory, dle následujících zdrojáků, mám vyzkoušeno, že normálně UART funguje, ovšem když použiju tyto kódy, tak nic. Jedná se o obousměrnou komunikaci, kde se posílají data z AD prevodu, 16f627 vyšle číslo kanálu, pic16f877 přijme, provede příslušný ad převod a odešle dva Byty informací. Ty 16f627 přijme a uloží do paměti. Toto funguje, pouze když se ptám jen na jeden kanál. Když chci přenášet více kanálů za sebou, oba dva procesory jakoby umřou ... mohl by se někdo prosím kouknout na zdrojáky a poradit mi, kde je chyba ? Předem mockrát díky ...
Založen: May 27, 2008 Příspěvky: 35 Bydliště: Jičín
Zaslal: po leden 24 2011, 17:21 Předmět:
Před zápisem do TXREG testovat TXIF ? vždyť TXIF je v 1 dokud není TXREG přepsáno ... takhle to stojí v datasheetu. Když bych nejdříve testoval TXIF, tak se nikam nedostanu, jelikož TXIF bude pořád v 1.
Založen: Oct 02, 2009 Příspěvky: 5286 Bydliště: PO
Zaslal: po leden 24 2011, 17:39 Předmět:
Ak je TXIF=1 môžeš zapísať do TXREG. Okamžite TXIF padne. Opäť sa nastaví ak je TXREG prázdny a môžeš ho až potom naplniť.
TXREG sa automaticky prepisuje do vysielacieho po odvysielaní celého rámca t.j aj stopbitov.
Test na TMRT bit by bol dobrý iba ak pri ukončovaní (zákaz prenosu TXEN=0), aby sa neodstrihli posledné bity.
Je logické, že na riadenie prenosov postačujú RCIF, a TXIF.
Naposledy upravil procesor dne po leden 24 2011, 18:25, celkově upraveno 1 krát.
Založen: May 27, 2008 Příspěvky: 35 Bydliště: Jičín
Zaslal: po leden 24 2011, 18:44 Předmět:
JJ, to dává smysl, jenže v mém případě beze změny .... po zapnutí proběhne serie dat, ty mi 16F877 zobrazí na LED a oba procesory umřou, RX, TX permanentně v 1, (mám to vytáhnuté na osciláku)
Založen: May 27, 2008 Příspěvky: 35 Bydliště: Jičín
Zaslal: po leden 24 2011, 19:12 Předmět:
já měl za to, že zpožďovací smyčka před AD převodem by měla stačit ( 750us) ale zkusím mezi jednotlivé vysílání vložit třeba 1ms delay ... myslim, že jsem to už dokonce zkoušel, ale náhoda je blbec ... a já nejspíš taky, jelikož to bude tradičně v nějaký kravině ....
Založen: Oct 02, 2009 Příspěvky: 5286 Bydliště: PO
Zaslal: po leden 24 2011, 19:37 Předmět:
Po reštarte by sa mohli procesory navzájom zosynchronizovať. Na to nestačí sledovať bit povelu. Ja používam napríklad 0X55 a odpoveď 0XAA, aby bolo jasné obom stranám,že sú ready.
Potom nasleduje povel a odpoveď. Príjem musí mať kontrolu FERR a OVERR pre prípad poruchy, a obnoviť prijímač na oboch stranách
Vyzývateľ (627) po pretečení nejakého času bez odozvy by mal zopakovať prenos-povel (kanál), alebo zahájiť opäť proces synchronizácie.
V tomto tvojom systéme, ak nastane na ktorejkoľvek strane k chybe, tak sa to zatne.
Založen: May 27, 2008 Příspěvky: 35 Bydliště: Jičín
Zaslal: po leden 24 2011, 20:05 Předmět:
to si myslím, že bude asi můj problém, jelikož po vložení několika čekacích smyček se přenos jednou za několik resetů rozběhne, ovšem pouze na cca +- 5s a pak zase umře .. takže problé bude nejspíše ve výše zmiňované synchronizaci, zkusím to tedy ošetřit ... uvidím co z toho vypadne
Založen: May 10, 2004 Příspěvky: 4513 Bydliště: Košice
Zaslal: po leden 24 2011, 20:20 Předmět:
no ked som podobne nieco riesil softverovo.... tak jeden procesor nabehol skor ako druhy to znamenalo ze jeedn pin sa nahodil skor a druhy procesor to povazoval za zaciatok prenosu...a ked zacal skutocny prenos bolo tam o jeden bit viacej a nechodilo to.....
Cize si pozru ako mas nasatvene porty..aby nedochadzalo k nejakemu kvazi startu i ked pri hardw implementacii to asi nehrozi...
Založen: Oct 02, 2009 Příspěvky: 5286 Bydliště: PO
Zaslal: po leden 24 2011, 20:28 Předmět:
Prijímače musia stále sledovať RCSTA bity FERR a OERR. Musia ich opraviť, lebo prijimač sa pri poruche automaticky zatne. Postup je v popise PICka
Až potom sa sleduje RCIF.
Pred vyslaním prvého povelu je dobré len tak bez ukladania prečítať 2x RCREG, lebo do registru sa pri zapínaní a inicializácii druhej strany môžu dostať nejaké falošné data. Tým sa vynuluje FIFO. Inak sa stane to, že vyčítané údaje budú posunuté o jeden alebo aj dva byty.
Založen: May 27, 2008 Příspěvky: 35 Bydliště: Jičín
Zaslal: po leden 24 2011, 21:44 Předmět:
Tak 877 už mám, ještě dodělám 627, uvidím co to bude dělat ... přikádám zatím novej zdroják ... pro 877 ( obsahuje test na chyby příjmu, jejich vynulování, synchronizaci)
Založen: Oct 02, 2009 Příspěvky: 5286 Bydliště: PO
Zaslal: po leden 24 2011, 22:59 Předmět:
Na môj vkus zložito porovnávaš prijatý znak na konštantu
kód:
MENU
MOVLW 0X55
SUBWF VYBER,0 ;porovnaj ak W==VYBER>je zero v STATUS
BTFSC STATUS,Z ; Zero indikator
GOTO SYNCHRO ; nie call treba odpovedat 0xAA a ide START
MOVLW B'00000001'
SUBWF VYBER,0
BTFSS STATUS,Z
GOTO PRENOSK0
MOVLW B'00000010'
SUBWF VYBER,0
BTFSS STATUS,Z
GOTO PRENOSK1
GOTO START
Kedykoľvej sa prijme "synchro" znak odošle sa odpoveď a bude sa čakať nový povel.
kód:
SYNCHRO ;SYNCHRONIZACE (POSLI ZPET 0xAA) (POKUD 0x55 PRIJATO A BEZ CHYB)
BTFSS PIR1,TXIF ;TESTOVANI ABYCHOM SI TXREG NEPREPSALI
GOTO $-1 ;
MOVLW 0xAA
MOVWF TXREG
GOTO START ; bude sa cakat odznova povel alebo synchro
Pri vysielaní sa počká na prázdny TXREG
kód:
VYSILEJL
BSF STATUS,RP0 ;BANKA1 (ADRESL JE V BANCE 1 !!! )
MOVF ADRESL,W ;do W je ulozena informace a MCU ji nasledne odesila pres UART ven
BCF STATUS,RP0 ;BANKA0
BTFSS PIR1,TXIF ;TESTOVANI ABYCHOM SI TXREG NEPREPSALI
GOTO $-1 ;
MOVWF TXREG ;presunout 8-bit hodnotu do
registru TXREG (Bank0) => nacteni dat zacina vysilani
Časy uváděny v GMT + 1 hodina Jdi na stránku 1, 2, 3Další
Strana 1 z 3
Nemůžete odesílat nové téma do tohoto fóra. Nemůžete odpovídat na témata v tomto fóru. Nemůžete upravovat své příspěvky v tomto fóru. Nemůžete mazat své příspěvky v tomto fóru. Nemůžete hlasovat v tomto fóru. Nemůžete připojovat soubory k příspěvkům Můžete stahovat a prohlížet přiložené soubory
Informace na portálu Elektro bastlírny jsou prezentovány za účelem vzdělání čtenářů a rozšíření zájmu o elektroniku. Autoři článků na serveru neberou žádnou zodpovědnost za škody vzniklé těmito zapojeními. Rovněž neberou žádnou odpovědnost za případnou újmu na zdraví vzniklou úrazem elektrickým proudem. Autoři a správci těchto stránek nepřejímají záruku za správnost zveřejněných materiálů. Předkládané informace a zapojení jsou zveřejněny bez ohledu na případné patenty třetích osob. Nároky na odškodnění na základě změn, chyb nebo vynechání jsou zásadně vyloučeny. Všechny registrované nebo jiné obchodní známky zde použité jsou majetkem jejich vlastníků. Uvedením nejsou zpochybněna z toho vyplývající vlastnická práva. Použití konstrukcí v rozporu se zákonem je přísně zakázáno. Vzhledem k tomu, že původ předkládaných materiálů nelze žádným způsobem dohledat, nelze je použít pro komerční účely! Tento nekomerční server nemá z uvedených zapojení či konstrukcí žádný zisk. Nezodpovídáme za pravost předkládaných materiálů třetími osobami a jejich původ. V případě, že zjistíte porušení autorského práva či jiné nesrovnalosti, kontaktujte administrátory na diskuzním fóru EB.