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

Atmega644 i bootloader MCS - Dzielę się wrażeniami i dopytuję. [BASCOM]

MES Mariusz 24 Maj 2015 16:18 4713 45
  • #1 14717355
    MES Mariusz
    Poziom 36  
    Witam.

    W Bascom AVR załadowałem przykładowy bootloader ( C:\Program Files (x86)\MCS Electronics\BASCOM-AVR\SAMPLES\BOOT\BootLoader.bas ) po ustawieniu mikrokontrolera ATmega644 i baudrate na 4800, skompilowałem i zaprogramowałem procesor.

    Dla pewności wklejam:

    Kod: text
    Zaloguj się, aby zobaczyć kod



    Następnie ustawiłem fusebity - taktowanie oscylator wewnętrzny 8MHz, dzielnik przez 8 wyłączony, JTAG wyłączony.

    Atmega644 i bootloader MCS - Dzielę się wrażeniami i dopytuję. [BASCOM]

    Od tego momentu, po zresetowaniu mikrokontrolera, dioda konwertera USB-UART sygnalizuje impulsy na linii TXD mikrokontrolera. Mikrokontroler cyklicznie wysyła dane.

    W monitorze portu szeregowego otwarłem więc port COM na którym obecny jest konwerter USB-UART (baudrate 4800). Nie udaje mi się jednak zaobserwować żadnej aktywności (mimo, że dioda pokazuje, że coś jednak jest wysyłane). Ani we wbudowanym monitorze Bascom, ani w zewnętrznym monitorze z pakietu arduino:

    Atmega644 i bootloader MCS - Dzielę się wrażeniami i dopytuję. [BASCOM]

    Atmega644 i bootloader MCS - Dzielę się wrażeniami i dopytuję. [BASCOM]

    Zaro zanotowanej aktywności.

    No nic, pobieram aplikację MCSbootloader, by sprawdzić, czy za jej pomocą uda mi się załadować po UART docelowy firmware.

    Ustawiam odpowiednie parametry i ładuję wsad.

    Atmega644 i bootloader MCS - Dzielę się wrażeniami i dopytuję. [BASCOM]

    Atmega644 i bootloader MCS - Dzielę się wrażeniami i dopytuję. [BASCOM]


    Po chwili:

    Atmega644 i bootloader MCS - Dzielę się wrażeniami i dopytuję. [BASCOM]

    Ok. Wszystko działa.

    Zastanawia mnie co jest słane przez procesor (załadowany czysty bootloader), i dlaczego nie widać tego w oknie terminala.
  • #2 14717502
    kamyczek
    Poziom 38  
    Zastanawiam się czy tak ciężko przeczytać listing bootloadera i wywnioskować co się dzieje . Może zanim zadasz banalne pytanie ,na które odpowiedź znajdziesz w listingu umieszczonym w poście pofatygujesz się i przeczytasz ze zrozumieniem kod . Zrozumiał bym że pytanie zadaje amator ale 24 poziom i takie pytanie to oznaka lenistwa . Mogę zrozumieć jeśli kod tego bootloadera był w asemblerze ale to jest bascom ...
  • Pomocny post
    #3 14717505
    Konto nie istnieje
    Konto nie istnieje  
  • #4 14717520
    kamyczek
    Poziom 38  
    Nic nie przestanie działać bo po wyjściu z bootloadera nastąpi skok do programu głównego w którym w sposób prawidłowy skonfiguruje się wszystkie potrzebne wyprowadzenia.
  • #5 14717524
    Konto nie istnieje
    Konto nie istnieje  
  • #6 14717622
    MES Mariusz
    Poziom 36  
    Nie ukrywam, że to moje pierwsze zetknięcie z bootloaderem dla AVR (nie stosowałem). Pewien sterownik działa w sieci RS485. Mogę się do niego zalogować, i wydawać polecenia tekstowe. Chciałbym by jednym z nich było "upgrade" po którym nastąpi wywołanie pętli, która skończy się tym, że watchdog zresetuje procesor. Po resecie włączy się bootloader, który wyśle coś w rodzaju "czekam na firmware". I jeśli w przeciągu 3 sekund wyślę przez terminal plik hex albo bin, rozpocznie się aktualizacja firmware. Będę próbował coś naskrobać na przykładzie bootloader.bas. Nie ukrywam, że wszelkie podpowiedzi będą dla mnie bardzo cenne.
  • #8 14717662
    Konto nie istnieje
    Konto nie istnieje  
  • #9 14717700
    dondu
    Moderator na urlopie...
    niveasoft napisał:
    Kompilator sam inicjalizuje domyślnie zmienne wartościami 0. Dopiero jak chcesz to nadajesz wartość. Z portami powinno być tak samo, ale nie zawsze. To są takie niuanse czasem.

    Jeszcze raz zapytam:

    dondu napisał:
    niveasoft napisał:
    Nigdy nie konfiguruję wejść bo są wejściami.

    Czy takie wejścia zostawiasz w stanie PORT i DDR w jakim są po resecie?
  • #10 14717723
    Konto nie istnieje
    Konto nie istnieje  
  • #11 14717834
    Jaca
    Poziom 31  
    MES Mariusz napisał:
    Nie ukrywam, że to moje pierwsze zetknięcie z bootloaderem dla AVR (nie stosowałem). Pewien sterownik działa w sieci RS485. Mogę się do niego zalogować, i wydawać polecenia tekstowe. Chciałbym by jednym z nich było "upgrade" po którym nastąpi wywołanie pętli, która skończy się tym, że watchdog zresetuje procesor. Po resecie włączy się bootloader, który wyśle coś w rodzaju "czekam na firmware". I jeśli w przeciągu 3 sekund wyślę przez terminal plik hex albo bin, rozpocznie się aktualizacja firmware. Będę próbował coś naskrobać na przykładzie bootloader.bas. Nie ukrywam, że wszelkie podpowiedzi będą dla mnie bardzo cenne.


    Po co takie kombinacje ? Po wykryciu odpowiedniej komendy ("upgrade"):
    1. Wyłącz WD (Stop Watchdog)
    2. Wyłącz przerwania (Disable Interrupts)
    3. Skocz do BootLoader'a (Goto &Hxxxx, gdzie xxxx to adres BL)
    4. Wgraj FW
    5. Restart z poziomu BL
  • #12 14717846
    kamyczek
    Poziom 38  
    Tak jest właśnie jak się używa nieznanych bibliotek w połączeniu z językiem wysokiego poziomu .. Bootloader to taki sam program jak każdy inny , tak samo kompilowany zapisany zazwyczaj w odrębnej sekcji pamięci i służący do aktualizacji sekcji aplikacji . jego działanie może być równie dobrze wywołane z poziomu aplikacji jak również przeniesienia sekcji przerwań do bloku bootloadera . Może to być sprawdzenie pinu przy resecie ale równie dobrze odebrany znak z uart , spi czy I2C slave . Tu dowolność jest ograniczona wielkością kodu wynikowego i inwencją programisty .
  • #13 14717848
    dondu
    Moderator na urlopie...
    niveasoft napisał:
    Nie ;) Na nieużywanych włączam pullup :P lub na używanych jeśli mi potrzebny.

    Dlatego jeśli piszesz że nie konfigurujesz wejść to dodaj proszę zawsze, że należy zadbać o pewien szczegół :)
    To bardzo istotne dla początkujących, którym podpowiedzi udzielasz.

    Co do bootloadera i stanu po nim, tym bardziej należy zadbać o prawidłowe konfigurowanie wszystkich pinów pod kątem PORT i DDR , by być pewnym, że bootloader (którego autorami nie jesteśmy) nie wykrzaczył nam naszego projektu w najmniej oczekiwanym momencie.

    Tę zasadę warto stosować zawsze by aplikacja była na 100% niezależna od nieprzewidzianych sytuacji.

    Piszę to nie pod kątem Ciebie, bo wiem że Ty sobie i tak poradzisz - piszę to pod kątem początkujących.

    niveasoft napisał:
    Więc pewnie w DDR mam zera..

    To jest dokładnie określone w dokumentacji w tabelkach opisujących rejestry PORT i DDR - każdy bit, ma zaznaczoną wartość po resecie.
  • #14 14717898
    tmf
    VIP Zasłużony dla elektroda
    Jaca napisał:
    MES Mariusz napisał:
    Nie ukrywam, że to moje pierwsze zetknięcie z bootloaderem dla AVR (nie stosowałem). Pewien sterownik działa w sieci RS485. Mogę się do niego zalogować, i wydawać polecenia tekstowe. Chciałbym by jednym z nich było "upgrade" po którym nastąpi wywołanie pętli, która skończy się tym, że watchdog zresetuje procesor. Po resecie włączy się bootloader, który wyśle coś w rodzaju "czekam na firmware". I jeśli w przeciągu 3 sekund wyślę przez terminal plik hex albo bin, rozpocznie się aktualizacja firmware. Będę próbował coś naskrobać na przykładzie bootloader.bas. Nie ukrywam, że wszelkie podpowiedzi będą dla mnie bardzo cenne.


    Po co takie kombinacje ? Po wykryciu odpowiedniej komendy ("upgrade"):
    1. Wyłącz WD (Stop Watchdog)


    To raczej nie jest możliwe. W sensownie wykorzystywanym WD jego zablokowanie programowe nie jest możliwe. Jaki ma sens wykorzystywać WD, jeśli jego działanie da się programowo (w tym przypadkową sekwencją) zablokować? W dodatku WD także w BL da się sensownie wykorzystać, np. do tego o czym pisze kol. Dondu, czyli reinicjalizacji MCU po wyjściu z kodu bootloadera.
  • #15 14718166
    Jaca
    Poziom 31  
    tmf napisał:
    To raczej nie jest możliwe. W sensownie wykorzystywanym WD jego zablokowanie programowe nie jest możliwe. Jaki ma sens wykorzystywać WD, jeśli jego działanie da się programowo (w tym przypadkową sekwencją) zablokować? W dodatku WD także w BL da się sensownie wykorzystać, np. do tego o czym pisze kol. Dondu, czyli reinicjalizacji MCU po wyjściu z kodu bootloadera.


    Rozwiązań tyle co programistów. ;-) Ja nie zostawiam BL pod władanie WD ponieważ BL to przeważnie krótki program i MUSI być "dopieszczony". Poza tym wolę mieć kontrolę nad BL w przypadku nieprzewidywalnych sytuacji w stylu uszkodzenie przewodów transmisyjnych lub dziwne poczynania użytkownika urządzenia w trakcie transmisji/programowania strony przez BL. W takich przypadkach nie pozwalam aby procesor opuścił BL i dokonał ponownego wgrania FV po uprzednim naprawieniu przyczyny zerwania połączenia. Jaki byłby efekt gdyby WD zrestartował procesor podczas wgrywania FW ?
  • #16 14718266
    Konto nie istnieje
    Konto nie istnieje  
  • #17 14718374
    tmf
    VIP Zasłużony dla elektroda
    Jaca napisał:
    tmf napisał:
    To raczej nie jest możliwe. W sensownie wykorzystywanym WD jego zablokowanie programowe nie jest możliwe. Jaki ma sens wykorzystywać WD, jeśli jego działanie da się programowo (w tym przypadkową sekwencją) zablokować? W dodatku WD także w BL da się sensownie wykorzystać, np. do tego o czym pisze kol. Dondu, czyli reinicjalizacji MCU po wyjściu z kodu bootloadera.


    Rozwiązań tyle co programistów. ;-) Ja nie zostawiam BL pod władanie WD ponieważ BL to przeważnie krótki program i MUSI być "dopieszczony". Poza tym wolę mieć kontrolę nad BL w przypadku nieprzewidywalnych sytuacji w stylu uszkodzenie przewodów transmisyjnych lub dziwne poczynania użytkownika urządzenia w trakcie transmisji/programowania strony przez BL. W takich przypadkach nie pozwalam aby procesor opuścił BL i dokonał ponownego wgrania FV po uprzednim naprawieniu przyczyny zerwania połączenia. Jaki byłby efekt gdyby WD zrestartował procesor podczas wgrywania FW ?


    Rozwiązań wiele, lecz dobre jest jedno :) Jeśli WD da się zablokować, to prawie tak jakby go nie było - dobrowolnie rezygnujesz z tego do czego WD został stworzony. Co się stanie jeśli WD zrestartuje MCU realizujący kod bootloadera? Przede wszystkim należałoby się zastanowić dlaczego go restartuje. Dwie główne przyczyny - zły kod bootloadera (czyli programista dał ciała), lub procek poszedł w maliny (i tu widać zaletę WD, bo go z tych tarapatów może wyciągnąć). A co się stanie jak go zresetujemy? Ano nic. W poprawnie napisanym kodzie procek po prostu ponownie rozpocznie upload FW. I tyle. Nie wiem dlaczego zakładasz, że jak procek wejdzie w BL to musi zakończyć poprawnie swoją działalność. A co jeśli użytkownik odłączy zasilanie, lub download FW zostanie przerwany? Urządzenie do serwisu? Nie prościej dobrze napisać BL?

    Dodano po 2 [minuty]:

    niveasoft napisał:
    ..a teraz zejdźmy na ziemię. Kolega Mariusz dopiero zaczyna znajomość z Bootloaderem. Tam w samplach do Bascom jest gotowy, działający, obsługujący eeprom i możliwy do uruchomienia bezpośrednio ze środowiska Bascom.
    ...
    W swoich wypowiedziach powinniśmy pomagać, a nie udowadniać kto ma rację :D


    Owszem, ale temat jest tak oklepany, że o czym tu dyskutować? Skoro w Bascomie jest gotowiec, Atmel też daje swój gotowiec w C (i kod BL na każdy MCU i soft na PC z nim współpracujący) to o czym dyskutować?:)
  • #18 14718569
    kamyczek
    Poziom 38  
    Mariusz ten bootloader czeka na znak z terminala , nie będzie też działał po rs485 jeśli nie zastosujesz 2 pętli jednej do nadawania i drugiej do odbierania informacji pojedyncza pętla rs485 działa jednokierunkowo nadawanie lub odbieranie brakuje wiec sterowania przepływem i identyfikacji urządzenia w pętli
  • #19 14718895
    MES Mariusz
    Poziom 36  
    Witam ponownie. Dziękuję za wszystkie wasze uwagi i podpowiedzi.

    kamyczek napisał:
    Mariusz ten bootloader czeka na znak z terminala , nie będzie też działał po rs485 jeśli nie zastosujesz 2 pętli jednej do nadawania i drugiej do odbierania informacji pojedyncza pętla rs485 działa jednokierunkowo nadawanie lub odbieranie brakuje wiec sterowania przepływem i identyfikacji urządzenia w pętli


    1. Kierunek transmisji. Owszem, są takie konwertery USB <-> RS485, które wyprowadzają piny sterowania kierunkiem transmisji. Większość jednak posiada wbudowany automat. Po zakończeniu nadawania przez komputer, konwerter przechodzi natychmiast w tryb odbioru. Taka właśnie transmisja dwukierunkowa half-dupleks obowiązuje w sterownikach o których piszę.

    2. Identyfikacja urządzenia w sieci RS485. Jak napisałem wcześniej, mam możliwość "zalogowania się" na konkretny sterownik. W uproszczeniu: muszę wykonać szereg instrukcji by wejść w konkretny sterownik, następnie komendy, które trafiają niby do wszystkich urządzeń obsługiwane / wykonywane są wyłącznie przez jedno urządzenie, do którego "wszedłem".

    3. Będąc "wewnątrz" konkretnego sterownika mógłbym wykonać na nim komendę "upgrade". Następnie skoczyć do obszaru bootloadera. Nie twierdzę, że do tego celu powinienem użyć aplikacji na PC od MCS. Wręcz przeciwnie. Chciałbym się uwolnić od jakiejkolwiek aplikacji i procedurę upgrade od początku do końca wykonać w terminalu. Najpierw (po zalogowaniu do wybranego sterownika) wykonać komendę "upgrade". Następnie bootloader wysłałby komunikat w rodzaju "czekam na firmware" i w tym momencie za pomocą okna terminala wysłałbym plik bin (hex?) - większość terminali posiada narzędzie "wyślij plik".

    Prosiłbym o komentarze / podpowiedzi właśnie w takich warunkach sprzętowo / programowych. Dzięki śliczne, bo każda wasza mądra uwaga pozwoli mi zaoszczędzić być może długie godziny tkwienia w nieuświadomionych błędach.

    Pozdrawiam serdecznie
    Mariusz
  • #20 14719020
    tmf
    VIP Zasłużony dla elektroda
    @MES Mariusz Owszem, większość terminali posiada opcję wysyłania plików, lecz czyni to bez jakiejkolwiek kontroli, musisz więc założyć, że slave będzie w stanie nadążyć z odbiorem informacji. Jest to naciągane założenie w przypadku wypalania firmware, bo programowanie strony FLASH trwa 2-4 ms. Chyba, że masz spory bufor w RAM. Oczywiście zawsze można wykorzystać jakiś tryb typu XMODEM, ZMODEM itd.
  • #21 14719136
    kamyczek
    Poziom 38  
    Do takich zastosowań powinieneś napisać własny bootloader ze sterowaniem przepływem po rs 485 i dodatkowym zwrotnym raportem po zaprogramowaniu każdego pakietu danych i dla kontroli poprawności programowany kontroler powinien zwrócić crc lub otrzymać je wraz z pakietem danych . To co teraz używasz to zabawka dla amatora a nie bootloader do aplikacji ...
  • #22 14719550
    MES Mariusz
    Poziom 36  
    tmf napisał:
    @MES Mariusz Oczywiście zawsze można wykorzystać jakiś tryb typu XMODEM, ZMODEM itd.

    Chętnie poczytam coś więcej w temacie XMODEM, ZMODEM w aspekcie bootloadera.


    kamyczek napisał:
    Do takich zastosowań powinieneś napisać własny bootloader ze sterowaniem przepływem po rs 485 i dodatkowym zwrotnym raportem po zaprogramowaniu każdego pakietu danych i dla kontroli poprawności programowany kontroler powinien zwrócić crc lub otrzymać je wraz z pakietem danych . To co teraz używasz to zabawka dla amatora a nie bootloader do aplikacji ...

    Warunki sprzętowe są takie, że sterownik już jest wyprodukowany (nie był przewidziany bootloader). Na zewnątrz wyprowadzone tylko sygnały A i B RS485. Należy więc przyjąć, że na sterowanie kierunkiem transmisji wpływu nie mamy, co jednak nie powinno być problemem, bo konwerter po wysłaniu danej w kierunku od PC do uC natychmiast przełącza się na odbiór. Rzeczywiście narzędzie "wyślij plik" terminala nie przewiduje kontroli wysyłanych danych. Co najwyżej po przesłaniu całego firmwareu do RAM mikrokontrolera ten mógłby nie wiem, może sprawdzić CRC dla całego kodu, i albo przeprowadzić upgrade, albo wysłać komunikat o błędnym firmware, i zrezygnować z upgrade-u. Ale nie wiem, czy takie coś jest w ogóle realne.

    Można ewentualnie spróbować tak napisać bootloader dla uC oraz jakąś aplikację do uploadu na PC (program konsolowy dla linuxa), że po odebraniu komendy upgrade mikrokontroler skoczy do bootloadera, który wyśle komunikat o gotowości, a aplikacja flashująca będzie wysyłała po jednym znaku i czekała na potwierdzenie od mikrokontrolera, czy znak doszedł. Jeśli doszedł nastąpi wysyłka kolejnego znaku i tak aż do końca. Proszę dajcie znać, czy to realne, bo nic innego do głowy mi w tej chwili nie przychodzi.
  • #23 14719707
    Konto nie istnieje
    Poziom 1  
  • #24 14719867
    MES Mariusz
    Poziom 36  
    MArSTER_1 napisał:
    W terminalach monitorując port COM nic nie zobaczysz, bo BootLoader bascomowy czeka na sygnał 123 z programu wysyłającego Firmware. Sam Boot Loader w żaden sposób nie zgłasza swojej gotowości.


    Też tak mi się zdawało (nie wnikając nawet w kod bootloadera) - można się tego domyślić obserwując konsolę aplikacji bootloader na PC od MCS. Przy uploadzie bin-a wartość "123" jest słana tak długo, aż bootloader odpowie i rozpocznie się upload. Stąd zdziwiła mnie migająca dioda na konwerterze USB <-> UART (linia TX mikrokontrolera, nawet gdy jest on odpięty od portu USB. Wygląda to tak, jakby uC coś nadawał. A tym czasem on nie ma nadawać, tylko oczekiwać na "123" (lub "124") z PC.

    Wracając natomiast do tego, co jest mi potrzebne i zastanych warunków sprzętowych.

    Sterowiniki (9 sztuk) pracują w moim domu, wszystkie są spięte w sieci RS485.
    Transmisja, jak wspomniałem half duplex.

    Komputer sterujący to Raspberry Pi. Posiadam publiczne IP, więc bez problemu mogę z zewnątrz połączyć się po ssh na Raspbery Pi, a będąc już w konsoli, uruchomić konsolowy monitor portu szeregowego (używam minicom). Tu już mogę swobodnie poruszać się po sterownikach i wykonywać na nich polecenia sterujące całą elektryką w budynku.

    Tego czego mi brakuje do szczęścia to możliwość zdalnego upgrade-u firmware (obecnie pozostaje mi wpinać się pod ISP i programować).

    Jeśli zostawię USBasp wpięty do któregoś sterownika i do maliny, to rzeczywiście mogę to zrobić "zdalny upgrade" firmware obsługując USBasp w konsoli maliny (tak czasem robię, jak rozwijam firmware sterownika).

    Ale szukam rozwiązania, które umożliwiłoby mi na zaprogramowanie dowolnego ze sterowników - po istniejącej już sieci RS485. Tylko obecne warunki sprzętowe są dosyć mocno ograniczone. RS485 - halfduplex (pojedyncza pętla A B).
  • #25 14719944
    Konto nie istnieje
    Poziom 1  
  • #26 14720548
    MES Mariusz
    Poziom 36  
    Świetne :-)

    Szkoda, że moja to sieć kablowa RS485 a nie WiFi, no ale trudno ;-)

    Dobra, teraz zajarzyłem też, że wcześniej pisaliście o sterowaniu kierunkiem transmisji od strony mikrokontrolera. Oczywiście, że mikrokontroler steruje kierunkiem transmisji (przełącza kostkę MAX485 w tryb nadawania lub odbioru), i rzeczywiście takie coś będzie musiał obsłużyć bootloader. Ja zafiksowałem się na sterowaniu kierunkiem transmisji od strony komputera (niektóre konwertery USB <-> RS485 mają złącze do sterowania kierunkiem wyprowadzone) - tutaj (w moim przypadku) rzeczywiście jest automat - PC przełącza się w tryb nasłuchu (a właściwie robi to za niego sam konwerter) natychmiast po wysłaniu danych. Sprawdza się to przy założeniu, że komputer (sterujący urządzeniami w sieci) jest masterem, a sterowniki są slavea-mi odpowiadającymi na zapytanie mastera - i tak właśnie wygląda to u mnie.

    Znalazłem też chyba coś czego szukałem (wsparcie dla RS485), oraz soft na różne platformy, to tego darmowe :-D.

    https://www.chip45.com/avr_bootloader_atmega_xmega_chip45boot2.php

    Widzę, że chip45boot2 wspiera sterownie kierunkiem transmisji przez bootloader. Muszę się wczytać / pokorespondować z supportem.
  • #27 14723826
    kamyczek
    Poziom 38  
    Darmowe do niekomercyjnego użycia . Nie rozumiem w czym masz problem żeby zrobić sobie własną przejściówkę z AVR ,który ma np. USB i uarta , np. M16U4 lub takiej która ma 2 uarty i z jednego zrobisz sobie komunikację ze sterowaniem przepływem do komputera na rs232 a na drugim porządnie komunikację po rs485 z wyborem prędkości buforowaniem i kontrolą kierunku transmisji . np. na M162 lub attiny1643 takim sposobem będziesz miał narzędzie ,które pozwoli wykorzystać każdy terminal nawet taki z dosa lub windowsa ...
  • #28 14727528
    MES Mariusz
    Poziom 36  
    Próbuję zrozumieć kod samplowy:

    Kod: text
    Zaloguj się, aby zobaczyć kod



    Mam problem z sekcją Do_spm

    Kod: text
    Zaloguj się, aby zobaczyć kod


    O ile wcześniejsza część kodu pozwala się zrozumieć, o tyle w tej sekcji zupełnie odpadam.

    Prośba o wytłumaczenie linia po linii co się tu dzieje / i generalnie co jest zadaniem sekcji.

    Generalnie widzę, że jest to sekcja odpowiedzialna za "zapis strony" / "załączenie strony", ale nie bardzo wiem / rozumiem, co się za tym kryje.

    Proszę o pomoc.
  • Pomocny post
    #29 14727561
    Konto nie istnieje
    Poziom 1  
  • #30 14727656
    MES Mariusz
    Poziom 36  
    Zależałoby mi na podpowiedzi:

    - czym jest / są: Spmcsr.0, Eecr.1.
    - czym są r0, r1, r30, r31
    - z czego wynika dzielenie firmware-u na kawałki akurat 128 bajtowe ?
    - wytłumaczenie może nie tyle instrukcji shift (bo to dostępne jest w helpie) ale generalnie co jest zadanem linii: Shift Z , Left , Maxwordshift
    - wytłumaczenie roli "pointera Z":
    lds r30,{Z}
    lds r31,{Z+1}


    Co prawda we fragmencie:

    Kod: text
    Zaloguj się, aby zobaczyć kod


    jest komentarz:

    Kod: text
    Zaloguj się, aby zobaczyć kod


    ale jakoś trudno mi go przełożyć na "życie".

    Dzięki piękne.
REKLAMA