logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Mega8 i MM5453N przez SPI w asemblerze

elvis921 12 Mar 2009 22:57 984 2
  • #1 6274370
    elvis921
    Poziom 11  
    Witam
    Mam problem z komunikacją między Megą8 i MM5453 (sterownik wyświetlacza 7-seg; można powiedzieć że to rejestr szeregowo-równoległy).
    Z dokumentacji Link wnioskuję że komunikacja powinna być poprawna dla SPI CPOL=0 i CPHA=0. Tak więc podłączam Mosi do data in, SCK do clock in, R i C takie jak w dokumentacji. Kod obsługi SPI wzięty z dokumentacji ATmegi (nieco poszerzony.
    
    .NOLIST
    .INCLUDE "m8def.inc"
    .LIST
    .def acc= r16
    .def maska = r17
    .cseg
    
    
    
    .org 0x0 
    rjmp start
    
    .org 0x40
    
    start:
    
    ldi acc, 0b11111111 	;
    out DDRD, acc
    
    
    ldi acc, 127 ;
    out SPL, acc ; ustawienie wskaˇnika stosu na 127
    
    
    reset:
    LDI R16,100	;
    LDI R17,10	;
    LDI R19,0 ;ZAWSZE 0 - DO POROWNANIA PRZY WAIT!
    
    LDI XL,0B11101111
    OUT PORTD,XL
    LDI R18,40 ;REGULACJA CZASU ~10*CZAS W SEKUNDACH
    RCALL WAIT
    LDI XL,0B11111111
    OUT PORTD,XL
    LDI R18,10 
    RCALL WAIT
    
    
    
    Rcall SPI_MasterInit
    
    
    ldi r16, 0b0000100
    rcall SPI_MasterTransmit
    
    ldi r16, 0b00000000
    rcall SPI_MasterTransmit
    
    ldi r16, 0b00000000
    rcall SPI_MasterTransmit
    
    ldi r16, 0b00000000
    rcall SPI_MasterTransmit
    
    ldi r16, 0b00000000
    rcall SPI_MasterTransmit
    
    rcall spi_wait
    
    
    
    
    ;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++==
    
    LDI XL,0B11100111
    OUT PORTD,XL
    LDI R18,100;REGULACJA CZASU 10*CZAS W SEKUNDACH
    RCALL WAIT
    
    LDI XL,0B11111111
    OUT PORTD,XL
    LDI R18,10 ;REGULACJA CZASU 10*CZAS W SEKUNDACH
    RCALL WAIT
    
    
    
    
    
    rjmp reset
    
    ;+===========================================================
    
    spi_wait:
    LDI XL,0B1110111
    OUT PORTD,XL
    LDI R18,5;REGULACJA CZASU 10*CZAS W SEKUNDACH
    RCALL WAIT
    
    LDI XL,0B11111111
    OUT PORTD,XL
    LDI R18,5;REGULACJA CZASU 10*CZAS W SEKUNDACH
    RCALL WAIT
    ret
    
    
    
    
    
    SPI_MasterInit:
    ; Set MOSI and SCK output, all others input
    ;ldi r17,(1<<DD_MOSI)|(1<<DD_SCK)
    ;out DDR_SPI,r17
    
    ldi acc, 0b00101000 	;
    out DDRB, acc
    
    ; Enable SPI, Master, set clock rate fck/16
    ldi r17,0b11010011
    out SPCR,r17
    ret
    
    
    SPI_MasterTransmit:
    ; Start transmission of data (r16)
    out SPDR,r16
    Wait_Transmit:
    ; Wait for transmission complete
    sbis SPSR,SPIF
    rjmp Wait_Transmit
    
    ret
    
    WAIT:
    L1:
    DEC R16
    CPSE R16,R19
    RJMP L1
    DEC R17
    LDI R16,167
    CPSE R17,R19
    RJMP L1
    DEC R18
    LDI R16,167
    LDI R17,80
    CPSE R18,R19
    RJMP L1
    RET
    .EXIT
    


    Właśnie w SPI_MasterInit te 3 zakomentowane linijki zastąpiłem inną (AVRStudio nie wiedział co to jest DD_MOSI, DD_SCK ). Po wielu godzinach walki udało się w ogóle zauważyć że mega cokolwiek wysyła do MM. Jednak nie można powiedzieć że są to dane które chciałem wysłać. Raz jest to to co chciałem, po drugim obiegu całego programu czasem jest to coś innego, czasem się wiesza... ( wcześniej po wysłaniu kolejnych bajtów mrugałem diodą i widziałem w którym bajcie nastąpiła zwiecha.)

    Dodatkowo problem w tym że MM podpięty jest na stałe do atmegi, do tych samych nóżek podpięty też jest programator. Gdy programuję atmegę, to wydać wyraźnie, że wyświetlacz 7-seg mruga, tzn bity się zmieniają. W MM jest rejestr przsówny, po zakończonym programowaniu nie wiem ile już tam jest wpisanych bitów.
    Objawia się to tym że stan wyświetlaczy zamiast zmienić się po wysłaniu 5 bajtów (w dokumentacji tak podali) , zmienia się kilka bajtów szybciej. Wtedy pokazuje się coś przypadkowego.

    Nie wiem jak rozwiązać ten problem - nawet chwilowe odłączenie zasilania od MM nie pomaga. Nie pomaga też ( co mnie dziwi) odłączanie masy od MM na czas programowania - i tak widać jak minimalnie wyświetlacz 'świeci' ?::?:



    Czy ktoś byłby w stanie podpowiedzieć czy kod napisany na ATmegę jest ok? oraz jak rozwiązać problem z nieprawidłową transmisją danych? Czy jest możliwość aby z uC wymuszać reset sterownika?

    Docelowo układ ma sterować wyświetlaczem 4-cyfrowym w układzie częstościomierza/generatora (jeśli to się uda, to spróbuje podłączyc termometr - plany ambitne, z wykonaniem na razie problemy), a opisany wyżej układ na razie stosuję jako układ testowy.]Link[/url]
  • Pomocny post
    #2 6274711
    asembler
    Poziom 32  
    Mam podejrzenie ze uklad generuje wewnetrzny sygnal strob po 36 bitach odebranych a twoj program wysyla wielokrotnosc 8 bitow co powoduje przesuniecie o 4 bity prawdziwych danych. Prawdopodobnie musisz zrobic SPi programowo. To tak na szybko bo szybciej mi jest napsiac program niz analizowac cudzy
  • #3 6275013
    elvis921
    Poziom 11  
    dzięki za sugestię. Właśnie po napisaniu tego zapytania też pomyślałem że łatwiej powinno być sterować kosteczką przez programowe SPI - wtedy będę mógł wysyłać co chcę, ile chcę i jak chcę :)
    Jak wrócę z zajęć to coś napisze na szybko i sprawdzę czy to rozwiązało problem.
    pozdrawiam


    ps. ale czy z dokumentacji MM (strona 5 pod schematem) nie wynika właśnie że bitów ma być 40? :
    1 bit startu, potem 4*8+1 bitów danych , 6 zer na końcu ?? w sumie daje 40 bitów (5 bajtów).
REKLAMA