USB, Bootloader AVR -pytań kilka

[Wojtek]

Potrzebuje zrobić urządzenie które będzie posiadało możliwość aktualizacji (podmienienia) softu - nie potrzebuje żadnej innej komunikacji. Najpierw poradzono mi abym użył FT232 i bootloadera pod UART. Tak też zrobiłem. Ale teraz zdałem sobie sprawę że da się jeszcze prościej.

Istnieje bootloader symulujący USBasp: http://www.obdev.at/products/vusb/usbasploader.html

Od strony sprzętowej przy tym bootloaderze wystarcza sama wtyczka USB.

I teraz kilka pytań (bo ja się za bardzo nie orientuje w temacie bootloaderów):

1) Bootloader w systemie przedstawia się jako "USBasp"- czy w prosty sposób udało by się podmienić nazwę na inną (nazwe mojego urządzenia)?

2) Aby uruchomić bootloader należy zewrzeć jedną ze zworek - dla mnie nie jest to ani wygodne ani nawet możliwe (bo wszystkie piny AVR są wykorzystane) - czy dało by się zrobić to tak aby bootloader uruchamiał się np. przy wyborze jakiejś opcji z menu?

3) Na schemacie (artykuł w którym znalazłem ten bootloader jest na forbocie)

piny USB są podłączone do nóżek PD2, PD4 - oczywistym jest że trzeba to zmienić bo ja te nóżki mam zajęte. Będzie to proste? Co więcej na wyżej pokazanym schemacie AVR jest zasilany z USB a ja bym chciał aby podczas aktualizacji softu AVR cały czas był zasilany z baterii w urządzeniu. Wystarczy więc po prostu zawiesić w powietrzu pin 1 gniazda USB?

Analizuje kod bootloadera: znalazłem taką definicje preprocesora w pliku nagłówkowym która jest chyba kluczowa dla wprowadzenia uruchamiania bootloadera z MENU (domyślnie jest ze zworki D7 (JUMPER_BIT = 7)):

#define bootLoaderCondition() ((PIND & (1 << JUMPER_BIT)) == 0)

Z tego co rozumiem bootloader sparawdza warunek( domyślnie jest to stan zworki) zaraz po włączeniu układu. Jeśli zworka jest zwarta uruchamia się całe wnętrze bootloadera , po wgraniu softa AVR musi zostać zresetowany. W przeciwnym razie (zworak otwarta) wykonuje się mój program.

Ja jednak potrzebuje zrobić tak aby użykownik wybierał sobie z MENU opcje ,że chce zaktualizować soft. W związku z tym wymyśliłem, że bootloader będzie sprawdzał (zamiast stanu zworki) zawartość pewnej komórki w EEPROM. Jeśli będzie domyślna(1) bootloader się nie uruchomi, jeśli (0) uruchomi się.

W związku z tym wymyśliłem że po wybraniu opcji w MENU zostanie zmieniona wartość tej komórki w EEPROM a następnie AVR zostanie programowo zresetowany (np przez watchdog). Na LCD zostanie ekran że "proszę wgrać softa". W tym czasie bootloader będzie aktywny. Ostatnią operacją którą bootloader wykona po wgraniu softa będzie ustawienbie na nowo 1 w EEPROM i programowy reset(lub nie bo chyab bootloader jak wykona swoje to się wyłączy i AVR przejdzie do programu głównego?). dobrze to wymyśliłem?

Oczywiście może dojść do pomyłek polegających np. na wgraniu wadliwie działającego softa(uniemożliwiającego zmianę stanu komórki w EEPROM i tym samym dostęp do bootloadera) dlatego można wprowadzić alternatywny sposób uruchamiania bootloadera właśnie ze zworką czy coś w tym stylu która była by wewnątrz obudowy np. koło baterii <-- oczywiście ten sposób byłby niewygodny i mniej efektowny (LCD by nic nie wyświetlał itp) ale to rozwiązanie "serwisowe", awaryjne.Wszystkie te moje pomysły zakładają że bootloader może tylko włączyć się na początku, więc zasadnicze pytanie czy istnieje możliwość wywołania bootloadera np w środku programu?

[OldSkull]

Z racji iż zrobiłem urządzenie z bootloaderem na ATmedze8 i działa doskonale może się wypowiem.

Masz kilka opcji:

- bootloader czeka po resecie przez określony czas (np. 5s) i potem uruchamia program. W takim wypadku możesz całość obsłużyć ręcznie nawet poprzez załączanie zasilania

- program zapisuje do EEPROM pod jakimś adresem flagę, następnie resetuje procesor. Bootloader sprawdza tą flagę, jeśli jest ustawiona programuje, a program potem na starcie też ją sprawdza i w razie czego czyści

Nie jestem pewien czy można wykonać z programu skok do kodu bootloadera - ani tym bardziej jak się zachowa procesor i czy powrót będzie możliwy (moim zdaniem nie, bo kod bootloadera będzie przy inicjowaniu automatycznie czyścił wszystko i ustawiał pod siebie. Dlatego też polecam drugą opcję z podanych.

[Wojtek]

Problem rozwiązałem za pomocą assemblerowskiej wstawki skoku wektora do początku sekcji bootloadera we FLASH'u więc ten temat mam już dokładnie prześwietlony. Powrót z bootloadera nie jest potrzebny. W każdym razie w swoim poście nie napisałeś nic nowego więc może znasz odpowiedzi na kilka innych spraw.

Pozostało mi tylko kilka banalnych pytań:

1) W makefile bootloadera są jakieś odniesienia do AVRDUDE - czy to znaczy że ten makefile sam wywołuje AVRDUDE ? Jak to rozumieć? Jak wygląda takie wywołanie? Tzn od razu po kompliacji mi się sam włącza AVRDUDE i wgrywa?

2) Chce zasilać układ z baterii czyli po prostu pozostawić pin vcc gniazda w powietrzu bez żadnych dodatkowych modyfikacji?

To jest schemat:

https://www.forbot.pl/forum/upload_img/obrazki/IMG_4c7d66b7accc47332.png

[kling]

Zapisywanie i odczyt flagi w EEPROM'ie nie wydaje się byc najszczęśliwszym pomysłem. Wymaga to wykorzystania bibliotek do obsługi EEPROM'u, co zwłaszcza w bootloaderze zajmuje cenne miejsce.

Moim zdaniem lepiej stworzyć małą sekcję gdzieś w RAM'ie pod konkretnym adresem z flagą NOCLEAR. Wtedy obszar ten nie będzie zerowany pomiędzy resetami proca.

Wtedy po podaniu zasilania, bootlader sprawdza czy aplikacja jest na miejscu, jeżeli tak to ją wywołuje.

Jeżeli rozkaz flashowania przyjdzie w momencie działania aplikacji to ustawia ona tą flagę w RAM'ie i resetuje proca. Następnie bootloader sprawdza tę flagę i mimo obecności aplikacji rozpoczyna flashowanie.

Co do drugiegp pytania - tak.

Wywołując make z komendą flash najpierw program zostanie skompilowany a następnie wgrany do procesora.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Wojtek]

Co do wywoływania bootloadera to już skończmy temat bo tak jak napisałem są normalne sposoby czyli po prostu skok do odpowiedniego miejsca w pamięci FLASH.

1) W tym makefile są odwołania do AVRDUDE i jeszcze jakieś nazwy programatora "STK500" ja będę korzystał z innego programatora do wgrywania bootloadera. Coś trzeba zrobić żeby ten makefile sam nie próbował się wgrać do uC. Ja chce poprostu otrzymać hexa i tyle.

2) Jak z tym zasilaniem z USB? Wystarczy ten jeden pin gniazda zostawić w powietrzu?

[kling]

ASH.

1) W tym makefile są odwołania do AVRDUDE i jeszcze jakieś nazwy programatora "STK500" ja będę korzystał z innego programatora do wgrywania bootloadera. Coś trzeba zrobić żeby ten makefile sam nie próbował się wgrać do uC. Ja chce poprostu otrzymać hexa i tyle.

?

Wystarczy wywołać:

make all

[Wojtek]

czyli sam się nie wywoła - bo właśnie mi chodzi o to żeby mi się nic nie wywoływało.

A tak nawiasem to "make all" to gdzie się wpisuje?

I wciąż nie wiem co z tym USB? Może to tak oczywiste że nikt nie chce na to odpowiedzieć ale wole się upewnić zanim coś popsuje.

[OldSkull]

Moim zdaniem lepiej stworzyć małą sekcję gdzieś w RAM'ie pod konkretnym adresem z flagą NOCLEAR. Wtedy obszar ten nie będzie zerowany pomiędzy resetami proca.

O, ciekawe. Nie wiedziałem o tej metodzie. Możesz to neico przybliżyć?

edit:

O ile nie używasz zasilania z USB to Vusb możesz zostawić nieużywane.

[kling]

czyli sam się nie wywoła - bo właśnie mi chodzi o to żeby mi się nic nie wywoływało.

A tak nawiasem to "make all" to gdzie się wpisuje?

Jak to ma się 'nic' nie wywoływać? A kompilacja?

"make all" wpisujesz w konsoli, bedąc w katalogu z plikiem Makefile. Pamietaj, zeby w zmiennej środowiskowej $PATH dodać Make'a.

Swoją drogą, jak do tej pory Ty to kompilowałeś?😉

@OldSkull

Opiszę pomysł dzisiaj wieczorem;)

[Wojtek]

Ja używam AVR studio. Zawsze do tej pory zaznaczalem jedna opcję żeby makefile mi się automatycznie generowal.Wiem że moge dac zewnętrznego makefilea i tak zamierzam zrobić w tym przypadku. Włączane kompilacje i otrzymuje hexa który pojawia się w katalogu. Jego następnie (także w avr studio) wgrywam do procka. Avrdude nie chcę używac i dlatego pytam co zrobić z tymi zapisami w makefilu?

[kling]

.Wiem że moge dac zewnętrznego makefilea i tak zamierzam zrobić w tym przypadku.

Wydaje mi się, że Makefile musiałby być napisany zgodnie z regułami AVR Studio. Przynajmniej eclipse nie łyka różnych makefilów.

[Wojtek]

Czyli rozumiem że powinienem się posłużyć AVRdude? Tylko przecież avrdude chyba nie posiada opcji kompilowania tylko wgrywania?

Dobra.Jestem otwarty na wszelkie propozycje. Mam do dyspozycji AS, Avrdude,plik main bootloadera, plik nagłówkowy bootloadera, makefile --Jak to skompilować i wgrać; krok po kroku?

[kling]

Nie wiem czy AVR Studio ma możliwość download'u wcześniej skompilowanego programu. Jeżeli tak, to wystarczy podać mu ścieżkę do pliku *.hex utworzonego po wywołaniu Make'a.

Jeżeli nie, to musisz użyć avrdude - w necie jest wiele step by step jak z niego korzystać😉

Jeżeli chodzi o bootloader i RAM to widzę to tak:

Zarówno w bootloaderze jaki i w aplikacji definiujemy sekcję w RAM'ie pod konkretny adresem, z flagą NOCLEAR. Spowoduje to, że w momencie resetu i wykonywania się startup'u proca sekcja ta nie będzie zerowana. Następnie tworzymy zmienna (flagę) właśnie w tej sekcji w bootloaderze jaki i w aplikacji. Będzie to współdzielony obszar przez oba programy, za pomocą którego będą mogły się komunikować między sobą.

Teraz uruchamiając bootloader sprawdzamy najpierw czy w pamięci flash jest aplikacja (sposób dowolny, ja wykorzystuje magic numbery 😋). Jeżeli nie ma aplikacji, czekamy w bootloaderze aż ktoś ją nam wyśle;)

Jeżeli jest aplikacja to sprawdzamy flagę we wspólnym obszarze RAM'u. Jeżeli jest ustawiona to czekamy na nową aplikację od operatora, jeżeli nie skaczemy do aplikacji.

W aplikacji dostając rozkaz flash'owania ustawiamy flagę i wykonujemy software reset (np watchdog'iem). Po resecie uruchomi się bootloader i sprawdzi naszą flagę, która nie będzie wyzerowana w czasie resetu.

Takie podejście oszczędza miejsce we flashu', które musiały by wykorzystać biblioteki do obsługi/emulacji eepromu.

Mam nadzieję, że w miarę jasno opisałem koncepcję😉

[Wojtek]

Napisałeś dokładnie to co napisałem w pierwszym poście.(no może poza tym NOCLEAR - bo tego n ie widziałem) ...ale chociaż dzięki za starania. Ja nie będe robił żadnej flagi tylko wywoływał bootloader skokiem do odp. sekcji w pamięci FLASH (przy 2kb bootloaderu i 32kb FLASH, adres to chyba jest coś koło 0x7800 zresztą w daasheet'cie napisane było, ale teraz nie chce mi się szukać). I wtedy nie trzeba będzie robić żadnego resetu itp.

W C wpisujemy:

asm volatile ("jmp 0x7800");

i tyle, jesteśmy w bootloaderze.

Dobrze, na razie tyle.

[OldSkull]

W C też można zrobić skok. Np. tak:

static void (*StartApp)(void) = 0x00;

i wywołanie skoku:

StartApp();

Analogicznie można zrobic dla Bootloadera - aczkolwiek ja robiłem raczej reset urządzenia, bo nie wiem co się dzieje z danymi i stanem układu jeśli się wywołuje skok do bootloadera zamiast resetu i potem skok do programu - i tak kilka razy. Czy efekt jest taki sam jakby układ był zresetowany.

Pytanie też czy można zamiast resetu wywoływać skok do adresu początku aplikacji.