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

Kosztowne błędy s PDF-ach

asembler 16 Kwi 2011 13:06 1506 10
REKLAMA
  • #1 9406751
    asembler
    Poziom 32  
    Jakiś czas temu przesiadłem się z atmegi 328 na 644. Oczywiście w pierwszym rzedzie przeczytałem interesujące mne strony - diżo tego nie ma bo wszystko prawie identyczne jak w poprzedniku. Oczywiście napisałem program a ponieważ moim standardowym podporgramem opóźniającym do mikroopóźnień jest istrukcja RCALL mająca tą zaletę że w jednym rozkazie mamy 9 taktów opóźnienia i tu właśnie jest chyba pomyłka w PDF (dla mnie kosztowna niestety).

    Czy ktoś z kolegów miał podobne doświadczenia?
  • REKLAMA
  • #2 9407250
    BoskiDialer
    Poziom 34  
    Nie rozumiem o jaką pomyłkę Ci chodzi? Normalnie RCALL to 3 cykle a RET 4, sumarycznie 7. Tutaj masz RCALL 4 cykle a RET 5, więc masz 9 cykli.
    Przeglądając noty można natrafić na:
    atmega644, "5.8.1 Interrupt Response Time", drugi akapit wyraźnie mówi o tym, że PC ma trzy bajty (mimo że faktycznie górny bajt jest nieużywany, brak nawet rejestru EIND)
    natomiast:
    atmega328, "6.7.1 Interrupt Response Time", również drugi akapit, tutaj mówi, że PC ma dwa bajty.
    Różnica w czasach wykonywania będzie, jeśli procesor musi przy skokach zapamiętać wartość licznika programu a ten ma w obu różną długość.
  • #3 9407483
    asembler
    Poziom 32  
    A praktycznie też powinna być bo u mnie wychodzi w obu wypadkach 7.
    Oczywiście że dopuszczam myśl że to jednak ja sie pomylłem ale skoro program działą po dodaniu dwóch nop na 644.
  • REKLAMA
  • #4 9407811
    Nawigator
    Poziom 33  
    >>>BoskiDialer a co wspólnego z RCALL przerwanie i Interrupt Response Time?

    N.
  • #5 9407952
    BoskiDialer
    Poziom 34  
    Nic wspólnego, tylko że w tamtym miejscu w nocie było zaznaczone jak długi jest PC - przecież on nie zmienia swojej długości pomiędzy instrukcjami. Od długości PC w danym procesorze zależy czas wykonywania instrukcji między innymi rcall oraz ret.

    Jest to całkiem możliwe że rcall+ret zajmuje 7 cykli a nota może zawierać błąd, wszak 22-bitowy PC nie jest w tym procesorze potrzebny (ma mniej niż 128KB flash).

    Można zrobić prosty test: pobrać SP, wykonać skok przez rcall i ponownie pobrać SP: sprawdzić ile bajtów zostało odłożonych na stos: 2 czy 3.

    -- edit:
    Jak by się uprzeć, to (r)call oraz czas wywołania przerwania mają bardzo dużo wspólnego: przerwanie to niejako wtrącona do potoku instrukcja skoku, co również powoduje zapisanie wartości PC na stosie.
  • REKLAMA
  • #6 9408117
    Nawigator
    Poziom 33  
    Co do stosu to faktycznie odłożenie/pobranie adresu zapewne wykorzystuje ten sam mechanizm i tu czas obsługi stosu powinien być jednakowy dla call, rcall czy wejścia w przerwanie.
    Ale nigdzie to nie jest potwierdzone "na piśmie" więc takie porównania mogą być ryzykowne.
    Natomiast Interrupt Response Time może mieć różną wartość bo procesor musi dokończyć wykonywany rozkaz a ten może mieć różny czas trwania.

    A co do tematu to na avrfreaks znalazłem:
    --------------------
    Atmel have confirmed a typo in the data Sheet regarding stack usage on the ATMega166p/324p/644p (doc8011-AVR-04/08)

    Atmel wrote:
    Two bytes are pushed on the stack during a CALL instruction for ATmega164P/324P/644P. There is a typo in the ATmega164P/324P/644P datasheet. I've reported this and it should be corrected to the next release of the datasheet. Thanks for your observation, and sorry for any inconvenience.

    The data sheet currently says three bytes.
    --------------

    Tak że w obu procesorach będzie 7clk.
    Tyle tylko że ten sposób tworzenia opóźnień dodatkowo obciąża stos i tu się też możemy kiedyś naciąć.
    I jeszcze bym chciał wiedzieć w jaki sposób u asemblera da się zrobić:
    "RCALL mająca tą zaletę że w jednym rozkazie mamy 9 taktów opóźnienia"

    N.
  • #7 9408199
    asembler
    Poziom 32  
    Nawigator przeczytaj dalej w/g noty mialo byc 9 a faktycznie jest 7 i o tym cały temat.
  • REKLAMA
  • #8 9409068
    Nawigator
    Poziom 33  
    No to przecież Atmel tłumaczy się że stos ma 2 bajty czyli wniosek że push/pop mają po 1clk. Dlatego masz 7clk. Ale nie poprawili w pdf-ach.
    A co z tym jednym Twoim rozkazem w kodzie? Daj przykład.

    N.
  • #9 9409092
    asembler
    Poziom 32  
    Nawigator napisał:
    No to przecież Atmel tłumaczy się że stos ma 2 bajty czyli wniosek że push/pop mają po 1clk. Dlatego masz 7clk. Ale nie poprawili w pdf-ach.
    A co z tym jednym Twoim rozkazem w kodzie? Daj przykład.

    N.


    Zastosowałem mechanicznie rozkaz RCALL i policzyłem go ze ma 9 taktów, a że faktycznie ma 7 to dopiero wyszło jak program przestał chodzic i to wszystko.
    Mnie sięwydaje że PDF mają wiele takich niespodzianek dlatego nie wierzę im ślepo bo już nieraz sie zawiodłem a tojuż nie pierwsza nieścisłość z tym że ta akurat dała mi najbardziej popalić
  • #11 9410047
    kamyczek
    Poziom 38  
    Wszystko wynika z pośpiechu przy wdrażaniu nowych produktów np. mikrokontrolerów wiele dokumentacji zawiera drobne błędy , wiele też jest niepełnych . Dlatego wdrożono układy do debugowania programów i odpowiednie narzędzia . Programy trzeba testować szczególnie procedury krytyczne czasowo. Kiedyś był 8051 i koniec teraz w ciągu miesiąca dochodzi jakiś rodzynek ... Taka jest rzeczywistość.
REKLAMA