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

AVR/bootloader - Includowanie bibliotek w sekcji bootloadera

pawelvod 04 Lut 2013 20:09 1719 19
  • #1 11888548
    pawelvod
    Poziom 18  
    Jak includować biblioteki np:
    #include <avr/delay.h>

    do sekcj bootladera?
  • #2 11888572
    mickpr
    Poziom 39  
    Bootloader to taka sama "aplikacja", jak zwykły "program" dla AVR. Różni się jedynie lokalizacją w pamięci Flash.

    Biblioteki inkluduje się tak samo.
  • #3 11888636
    tmf
    VIP Zasłużony dla elektroda
    pawelvod napisał:
    Jak includować biblioteki np:
    #include <avr/delay.h>

    do sekcj bootladera?


    Pamiętaj, aby nie mieszać kodu bootloadera i aplikacji. Bootloader to oddzielna aplikacja, a więc przy includowaniu bibliotek nawet zawierających kod nic nie musisz robić - bootloader wymaga przesunięcia sekcji .text, a więc także kodu, który znajdzie się w nagłówku.
  • #4 11888805
    pawelvod
    Poziom 18  
    Ok tylko mam tak zdefiniowaną sekcję:
    #define BootSection __attribute__ ((section(".bootloader")))
    #include	"rfm22/rfm22.h"
    BootSection int main(void)
    {
    	while(1);
    }
    

    mam bibliotekę obsługującą RM22 przy pomocy którego chcę wgrywać program.
    Kiedy podglądam plik hex widzę że cała biblioteka rfm jest "na początku" pamięci. Jedynie funkcja main jest pod adresem 0x001C00
  • #5 11888865
    mickpr
    Poziom 39  
    Musisz podać linkerowi (np. w Makefile) od jakiego adresu ma umieszczać kod.
    Kod: Bash
    Zaloguj się, aby zobaczyć kod

    W jakim środowisku piszesz?
  • #6 11888900
    pawelvod
    Poziom 18  
    Eclipse i AvrCgg.
    Podaję
    --section-start=.BootSection=0x001C00 

    i wszytkie funkcie opatrzone BootSection są tam gdzie trzeba, ale biblioteki własne i systemowe (jak math) wędrują do pamięci na początku.
  • #7 11888922
    mickpr
    Poziom 39  
    pawelvod napisał:
    ale biblioteki własne i systemowe (jak math) wędrują do pamięci na początku.
    Z ciekawości, po co ci w bootloaderze biblioteka math?
  • #8 11888939
    pawelvod
    Poziom 18  
    Tak na próbę bo nie są inline jak _delay_ms które czasem są dobrze, a czasem źle wlinkowane (w zależności od widzimisie kompilatora) więc nie mogę sprawdzać na nich czy problem rozwiązałem.
  • #9 11888959
    mickpr
    Poziom 39  
    A skierowałeś też sam kod (.text) ?
    Kod: Bash
    Zaloguj się, aby zobaczyć kod


    p.s. Nigdy nie pisałem bootloadera pod AVR (jedynie PIC18F i ARM11).
  • #10 11889065
    pawelvod
    Poziom 18  
    Ok. po dodaniu -Ttext=0x001C00 właściwie wywaliłem z linkera .bootloader i przy wejściu funkcją main() wszystko wydaje się chodzić tak jak oczekuję... Cały program jest od adresu 0x1c00 i wszystko ci #includuje też tam jest. W hex edytorze widzę nawet że wektory przerwań są na początku (to akurat zabiera pamięć bo nie korzystam). Wygląda na to że chodzi jak potrzeba wszystko. Chyba że się mylę...?
  • #11 11889073
    mickpr
    Poziom 39  
    Pamiętaj o fusebitach, sprawdź wektory przerwań....
  • #12 11889136
    tmf
    VIP Zasłużony dla elektroda
    Na początku ci pisałem, że masz przesunąć właśnie sekcję text. Sekcja .bootloader służy zupełnie czemuś innemu, bynajmniej nie pisaniu bootloadera :)
    Na wektory musisz uważać, szczególnie na wektor reset - poza tym, że powinien wskazywać na bootloader, to bootloader musi uruchamiać kod aplikacji np. po sprawdzeniu jej integralności. IVT możesz sobie przesuwać jak chcesz, ale zapewne chciałbyś ją mieć od adresu 0x0000, bo inaczej będzie problem z ISR w aplikacji głównej - trzeba będzie linker poinformować, że IVT leży w obszarze bootloadera.
  • #13 11889318
    pawelvod
    Poziom 18  
    No jeśli chcę używać przerwań to z dokumentacji wynika że powinienem na początku kodu botladera umiećcić:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    natomiast na końcu analogicznie:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    i wszystko powinno byc ok...?
  • #14 11889380
    tmf
    VIP Zasłużony dla elektroda
    Niekoniecznie. Musisz pamiętać o wektorze RESET, aby go przenieść w obszar bootloadera (niektóre AVRy mają nawet dedykowany pin IO, którego stan zmienia wektor Reset. Dwa, to inicjalizacja aplikacji. Jeśli skoczysz pod adres 0, to pamiętaj, że nie nastąpi reset procesora, a w szczególności jego układów peryferyjnych. Zostaną one w takim stanie w jakim skonfigurował je bootloader. W zależności od sposobu pisania aplikacji może to rodzić probley lub nie. Stąd też często aplikację inicjalizuje się przy pomocy WDR - wtedy dostaje ona procka w takim stanie jak po prawdziwym resecie.
  • #15 11889531
    pawelvod
    Poziom 18  
    Hm... reset hardwarowy ustawia fusebit bootrst...? Nie bardzo rozumiem co mam przenosić? Następna dziwna sprawa. Tak na próbę wgrałem sobie w obszar bootloadera obsługę graficznego wyświetlacza. Wszytko dzieje się na atmega16a który ma 2kB botloadera niby. Tylko że obsługa wyświetlacza zajmuje prawie 4 i wszystko hula. Jak podejrzałem w hex to całość kończy się w okolicach 0x2AFE... Wszystko natomiast chodzi. Dziwne. Czy Atmel dorzuca jakieś gratisy do pamięci??
    Jeszcze pytanie. Piszesz że rjmp 0 wywoła reset procesora. Czy chodzi o skok do komórki 0 w której jest instrukcja skoku pod adres main() wgranego programu? Czy dzieje się tam coś jeszcze? Jeśli to tylko skok to oczywiście zdaje sobie sprawę że używane w botlaoaderze ustawienia PIN, DDR czy zainicjowane urządzenia będą dalej w stanie jakim je bootloader zostawił.
  • #16 11889805
    mirekk36
    Poziom 42  
    jeśli chodzi o fusebity i inne rzeczy to popatrz sobie może tutaj - masz też kody źródłowe BLS'a

    https://www.elektroda.pl/rtvforum/topic1343484.html

    Atmel nie dorzuca żadnej dodatkowej pamięci za free ;) po prostu robisz coś totalnie źle - tak bym na to spojrzał ... A w tym temacie i kodach będziesz mógł sobie podpatrzeć co i jak

    przy okazji zastanów się dobrze czy jest sens do bootloadera wrzucać COKOLWIEK poza tym co on ma zrobić czyli załadować wsad i już ;) po co jakiś LCD ? ... no chyba że tak do testów potrzebujesz bo na razie nie wiesz co i jak to rozumiem

    a z bootloadera spokojnie możesz wychodzić za pomocą "jmp 0" i tak ładowana aplikacja musi zadbać o ustawienie tego z czego korzysta po swojemu, więc nie masz co się obawiać o pozostawienie peryferiów dotykanych w bootloaderze ;)
  • #17 11890069
    pawelvod
    Poziom 18  
    Ok. Znalazłem błąd. Nota katalogowa podaje początek adresu w słowach nie w bajtach więc nie 0x1c00 tylko 0x3800. Wrzuciłem 2 rodzaje migania diodą w adresy 0x00 i 0x3800 i w zależności od BOOTRST dioda teraz mruga na dwa różne sposoby więc początek jest;) Reszta jutro. Jako że odezwał się mirek to pytanie do niego;) Jak myślisz uda się upchnąć w atmega128 programowanie bootlaoderem poprzez HTTP? Używam kodu emc28j60 z twojej książki i ciekaw jestem czy da się go na tyle odchudzić żeby samego klienta http zmieścić w sekcji bootloadera. Na razie robię programowanie poprzez RM22 i to się zmieści bez problemu.
  • #18 11890717
    mirekk36
    Poziom 42  
    hmm ciekawy pomysł, nie próbowałem tego ale myślę że gra warta świeczki i popróbowania. Tylko czy nie lepiej byłoby to zrobić przez UDP i jakąś aplikację na PC, która będzie słać dane właśnie przez UDP. Tzn ja właśnie mam gdzieś w planach na kiedyś zrobienie czegoś takiego właśnie na UDP ;) .... ale jeśli ci się uda przez HTTP to też fajnie, daj znać w razie czego. Czy się zmieści? ciężko tak powiedzieć - trzeba właśnie popróbować ale ATmega128 ma jednak sporo miejsca na BLS.
  • #19 11892211
    pawelvod
    Poziom 18  
    Generalnie możliwość programowania urządzenia poprzez internet jest super opcją. Klient odpytuje o aktualną wersję softwaru i w przypadku updata sam zaczyna się programować. Poza tym HTTP daje jakąś tam większą odporność na niedotarte pakiety itd. Na komputerze na którym programuje i tak ma APACHE więc po odczekaniu czasu sprawdzania nowej wersji softwaru bądź resecie procesora zaprogramuje on sie sam o ile jest nowy .hex w katalogu projektu.
  • #20 11892804
    McMonster
    Poziom 32  
    Nie HTTP, tylko TCP, jeśli już. Przy czym można w tym celu spokojnie zastosować UDP i na przykład TFTP, tak to jest rozwiązane np. w urządzeniach Cisco, które same potrafią za pomocą TFTP ładować konfigurację i obrazy. IP i domyślną ścieżkę wsadu zapisujemy sobie gdzieś w dogodnym miejscu i możemy wykorzystać gotowy serwer. Wadą jest tu brak autoryzacji, ale to można obejść tworząc własny protokół, wzorujący się na TFTP.
REKLAMA