Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

transmisja z 51 do AVR

02 Gru 2003 17:18 2352 17
  • Poziom 23  
    witam
    napislaem sobie programik do przesylu danych. dane wysyla 89c2051 a odbiera 90s2313 i teraz jest prol\blem czasami jak wlacze ukald to za kazdym razem odrany bajt nie jest poprawny (czasami co 8 jest ok). ale programy sa napisane ok bo czasmi calosc dziala bez zadnych problemow. nie wiem co to moze byc. moze pomozecie ????

    pozdr kozak
  • Poziom 33  
    Jakie masz kwarce? Najprawdopodobniej problem polega na rozsynchronizowaniu transmisji (jak sie domyslam chodzi o UART'a).
  • Poziom 32  
    Mam podobną konfigurację, AT89c2051 robi funkcję klawiatury i wysyła po USART-e znaki do AT90s8515, który robi resztę roboty. Mam prędkość na 9600 w obydwu, z tym żę na 51 jest kwarc 11059kHz a w 8515 jest 7 z groszami. I nie zdażyło się jeszcze żeby kody klawiatury były inne od oczekiwanych. Fakt jest taki że obydwa procki zasilane są z tego samego napięcia. Nie wiem jak w twoim przypadku. Masz założone kondensatory na kwarczach ?? To może być powodem jak któryś z kwarców ruszy na owrtorze, to tak będzie wyglądało.
  • Poziom 23  
    wlanie nie jest to rs232 tylko moj wlasny standart transmisji. a najciekawsze jest to ze programy sa ok. wydaje mi sie ze albo ktorys z prockow jest uszkodzony albo w avr cos jest nietak z resetem bo jest taki myk ze jak wlacze zasilanie i dziala to juz przesyla bez problemu a jak nie zadziala za pierwszym razem to potem juz caly czas blad. jak pare razy wlacze i wylacze zasilanie to czasami dziala czasami nie. sprawdzalem juz wiele opcji wymienialem kondensatory przy kwarcach zastosowalem kondensator na resecie w avr , probowalem do progamu na poczatku wsptawic czyszczenie wszystkich rejestrow i nic.
  • Poziom 24  
    kozak_sc napisał:
    wlanie nie jest to rs232 tylko moj wlasny standart transmisji.


    okay, ale uzywasz sprzętowego UART'a czy nie?
  • Specjalista - oświetlenie sceniczne
    kiedys też miałem tak że jak sie "wsczeliłem" z wysyłką w odpowiednim czasie to wszystko chodziło. co prawda było to dawno- ale chyba cos z tej walki pamiętam

    1) sprawdz masy obydwu procków.
    2) ile wysyłasz bajtów z klawatury?. czy ilosc bajtów wysyłanych i odbieranych sie zgadza?

    w jakim jezyku są programy?
  • Poziom 24  
    jest jeszcze mozliwosc, ze procek nie zdazy przerobic danych przed odebraniem nastepnych. ale musisz podac wiecej szczegolow o programie, to cos sie pomysli...

    pozdro
  • Poziom 30  
    kozak_sc napisał:
    witam
    napislaem sobie programik do przesylu danych. dane wysyla 89c2051 a odbiera 90s2313 i teraz jest prol\blem czasami jak wlacze ukald to za kazdym razem odrany bajt nie jest poprawny (czasami co 8 jest ok). ale programy sa napisane ok bo czasmi calosc dziala bez zadnych problemow. nie wiem co to moze byc. moze pomozecie ????

    pozdr kozak


    Może źle ci się synchronizuje nadajnik z odbiornikiem? To znaczy, moze wczesniej zaczynasz nadawać a później odbierać i ci się odbiornik synchronizuje na innej pozycji (bierze bit danych jako bit startu)?
  • Poziom 23  
    ja zrobilem tak :

    nadajnik : (kwarc 12MHz)

    Glowna:
    jnb p3.3 ,nad1
    jnb p3.4 ,nad2
    sjmp glowna


    Nad1:
    mov A,#123
    acall send
    acall wait
    sjmp glowna

    Nad2:
    mov A,#251
    acall send
    acall wait
    sjmp glowna

    Wait:
    mov r2,#255
    Wait_sub:
    mov r1,#255
    djnz r1,*+0
    mov r1,#255
    djnz r1,*+0
    djnz r2,wait_sub


    ret



    Send:

    jnb p1.1,*+0
    clr p1.1
    acall sendin
    setb p1.1

    ret

    Sendin:
    mov B,#8
    Wykonaj:
    rlc A
    clr p1.0
    jc jedynka
    mov r0,#50
    djnz r0,*+0
    sjmp ok
    Jedynka:
    mov r0,#25
    djnz r0,*+0
    Ok:
    setb p1.0
    mov r0,#5
    djnz r0,*+0
    djnz B,wykonaj

    clr p1.0
    mov r0,#5
    djnz r0,*+0
    setb p1.0
    ret

    odbiornik : (kwarc 8MHz)

    .include "2313def.inc" ;dolacz plik z nazwami rejestrow


    rjmp reset ;skok procedury ustawiajacej wartosci poczatkowe
    rjmp odbior ;procedura obslugi przerwania INT0

    reset:

    clr r19

    ldi r27,RAMEND ;ostatnia kom. RAM
    out SPL,r27 ;zpisz wskaźnik stosu

    ldi r27,0b11111011 ;konfiguracja portow
    out ddrd,r27 ;port b wyjscia
    ;port d wyjscie int0(PD2) i int1(PD3) wejscia
    sbi portd,2

    ldi r27,0b11111111
    out ddrb,r27

    ldi r27,2 ;w R20 przechowywana jest informacja o konfiguracji T0
    out tccr0,r27

    ldi r27,0b01000000
    out gimsk,r27 ;wlacz przerwania INT0

    ldi r27,0b00001010 ;przerwania INT0 i INT1 wywolywane opadajacym zboczem
    out mcucr,r27

    sei ;globalne zezwolenie na obsluge przerwan

    glowna:

    ser r25

    wait1_1:
    ser r26
    wait_sub_1:
    dec r26
    tst r26
    brne wait_sub_1
    dec r25
    tst r25
    brne wait1_1

    in r16,portd
    ldi r17,0b01000000
    eor r16,r17
    out portd,r16

    rjmp glowna

    Odbior:
    ldi r20,8

    petlaodbiorcza:

    out tcnt0,r19

    bitwait1:
    sbis pind,2
    rjmp bitwait1

    in r21,tcnt0

    cpi r21,75

    rol r24

    bitwait0:
    sbic pind,2
    rjmp bitwait0


    dec r20
    tst r20
    brne petlaodbiorcza

    ; i teraz dane powinny byc w R24

    koniec:

    out gifr,r19
    reti


    -----------------------------------------------------------------------------
  • Specjalista - oświetlenie sceniczne
    nie wiem czemu zrobiłeś to "na okolo"- czemu nie urzyłeś sprzętowego UARTa?. nie wiem czy ktoś bedzie chciał analizowac ten kod. robiąc to na uartcie piszesz tylko (dla '51) MOV SBUF, DANA
    i już nic wiecej cie nie obchodzi! podobnie w AVR!. oczywiscie należy jeszcze na początku programu ustawic odpowiednio kilka bitów i wsio. moge ci pomuc w uruchomieniu uarta w 51. z twojego listungu nie wywnioskowałem ile przesyłasz danych za jednym "zamachem". Ale z tego co opisywaś jesteś blisko rożwiązania. jesli tych bajtów wysyłąśz kilka to moze AVR ci sie nie synchronizuje- tzn bajt nr 1 z 51 AVR traktuje naj 3... błąd ten w pewnych warunkach może sie zmieniać. moze wykorzystać jeszce jedną nużke, która była by informacją o numerze bajtu- pomyśla nad tym
  • Poziom 23  
    no wlanie ja bym tak zrobil jak bym mogl. bo rzecz w tym ze potrzebuje takiej transmisji zeby odbiornik odbieral poprawnie sygnal takze zanegowany !!! a w tym przypadku latwo to zrealizowac. a uart z programowo negowanym wejsciem ??? wlasnie chyba zade procek nie oferuje czegos takiego. moze zaproponujecie jakis inny system transmisji ???
  • Specjalista - oświetlenie sceniczne
    moźna zanegować cały wysłąny lub odebrany bajt :idea:
  • Poziom 23  
    tylko wez pod uwage ze transmisja uartem dziala tak ze jest uruchamiana okreslonym zboczem (czy poziomem nie pamietam) i w przypadku gdy sygnal bedzie zanegowany odebrany bajt nie zostanie zinterpretowany prawidlowo !!!

    ja zakladalem wczesniej ze to bedzie tak : do INT0 podlaczam sygnał do INT1 podlaczam not(sygnał) i teraz dane odbieram w moim systemie tak samo dla obu przerwan tylko ze albo z portd,2 albo z portd,3 w zaleznosci ktore z przerwan wystapilo pierwsze.
  • Poziom 24  
    w jakim celu przewidujesz mozliwosc negowania sygnalu?

    bo rozumiem, ze nie negujesz tresci (danych) tylko calosc, lacznie z bitami start/stop.

    moznaby jeszcze probowac taki trick: wpinasz bufor negowany i nie-negowany (trojstanowe) przed wejsciem UART i podpinasz je rowniez do intX. sygnal bramkujacy podpinasz do ktorychs nozek portu.

    jak to dziala? po prostu uklad budzi sie jako odbierajacy bez nagowania. sygnal INTx zareaguje np. na zanegowany bit startu i podlaczy w szereg negator, co spowoduje odbieranie czystego sygnalu.

    czyli generalnie przerwania analizuja czy nadchodzi normalny czy zanegowany sygnal, i ew. wpinaja negator.
  • Poziom 21  
    Jeżeli naprawdę potrzebujesz tak dziwnej odmiany przesyłania danych to działaj dalej. Ale jeśli masz przesłać set-, kilo- bajtów i nie jest to transfer krytyczny czasowo to wychodzenie poza UART jest niewskazane. Sam się dostraja do odchyleń w prędkości transmisji i robi to sprzętowo, więc po co wyważać otwarte drzwi? Jak ktoś zasugerował masz prawdopodobnie niezsynchronizowane oba proce - w 51 istnieje tryb synchroniczny do komunikacji pomiędzy wieloma procami, ale stosowałem to tylko dla kilku 51 i wymagany był naprawdę szybki transfer, nie jakieś tam klawiatury itp. Napisz co oba proce robią to coś poradzimy.
  • Poziom 23  
    no wiec tak
    51 nadaje dane ktore sa kluczuja zmiane polaryzacji zasilacza. do wyjscia zasilacza podlacza sie odbiornik (przez prostownik zasila avr a do int0 jest podlaczona bezposrednio jedna z linii) i niezaleznie od sposobu podlaczenia sygnal byl odbierany prawidlowo. jesli chodzi o ilosc przesylanych danych to potrzebuje przesylac paczki po 3 bajty.
  • Specjalista - oświetlenie sceniczne
    ja zapytam wiec jescze raz: jak masz rozwiązaną sprawe rozpoznawania odebranych bajtów w AVR- skąd on wie który bajt jest który?. Druga sprawa to taka że jesli urzywasz kilku przerwa, a miedzy innymi jedno z nich obsługuje twoja transmisje to sprawdz ich priorytety, być może w krytycznym momencie (zależnie od momentu resetu proca) któreś z przerwań nachodzi ci na te od transmisji- chociarz wątpie aby było to tak regularne ("albo chodzi, albo nie..."
  • Poziom 23  
    narazie przesylalem jeden bajt na probe i juz nie dzizla a co dopiero mowic o trzech !!! po drugie w obsludze przerwania najpierw mam cli czyli wylaczam prezrwania a zaraz przed reti zeruje rejest gifr i wlaczam polecniem sei. narazie probowalem przeslac 1 bajt bez urzycia dwoch przerwan. podlaczylem do int0 i jest tak za pierwszym razem odebrany bajt jest ok ale cos jest nie tak bo program nie wraca do petli glownej i nastepne bajty juz kicha !!!