Stránka 1 z 3
PIC16F877A a PIC16F627A zlobí UART
Napsal: 23 led 2011, 17:23
od walleyman
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 ...
Napsal: 23 led 2011, 20:19
od procesor
Pre zápisom do TXREG testovať TXIF
Toto nie je zaujímave
Napsal: 24 led 2011, 17:21
od walleyman
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.
Napsal: 24 led 2011, 17:39
od procesor
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.
Napsal: 24 led 2011, 18:14
od walleyman
EDIT: testování TRMT jsem úplně nahradil testováním TXIF pořád nic ... přikládám aktuální zdrojáky
Napsal: 24 led 2011, 18:44
od walleyman
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)
Napsal: 24 led 2011, 19:06
od Atlan
nechces si tam dat aj nejake casove odstupy....namiesto toho ze vsetko hned vysielas zarardom....
Napsal: 24 led 2011, 19:12
od walleyman
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ě ....
Napsal: 24 led 2011, 19:37
od procesor
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.
Napsal: 24 led 2011, 19:47
od procesor
To si nepochopil dobre.
Test TXIF sa robí pred zápisom do TXREG
Aby sa to ako tak rozbehlo 627 musí začať vysielať keď 877 je už po inicializácii. To zaistí to čo som písal skôr.
Napsal: 24 led 2011, 20:05
od walleyman
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
Napsal: 24 led 2011, 20:20
od Atlan
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...
Napsal: 24 led 2011, 20:28
od procesor
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.
Napsal: 24 led 2011, 21:44
od walleyman
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)
Napsal: 24 led 2011, 22:59
od procesor
Na môj vkus zložito porovnávaš prijatý znak na konštantu
Kód: Vybrat vše
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: Vybrat vše
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: Vybrat vše
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
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VYSILEJH
MOVF ADRESH,W ;do W je ulozena informace a MCU ji nasledne odesila pres UART ven
BTFSS PIR1,TXIF ;TESTOVANI ABYCHOM SI TXREG NEPREPSALI vždy pred zápisom !
GOTO $-1 ;
MOVWF TXREG ;presunout 8-bit hodnotu do registru TXREG (Bank0) => nacteni dat zacina vysilani
RETURN