Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

ATmega - Kopiowanie ATmegi przez .hex

mac310 07 Sty 2016 23:02 1044 6
  • #1 07 Sty 2016 23:02
    mac310
    Poziom 11  

    Próbowałem coś znaleźć na ten temat i trochę udało mi się poczytać, a nawet poeksperymentować jednak nie jestem pewny czy jest tak jak myślę więc proszę o weryfikację.
    Sytuacja jest taka, że mam program napisany i wgrany na ATmega88PA poprzez Arduino IDE. Czyli układ działa na uC ale z bootloaderem i programem w środowisku Arduino. Chciałbym teraz zapisać taki gotowy wsad w postaci skompilowanej gotowej do wgrania na inną kostkę (tzn. taką samą ATmegę88PA ale nową sztukę) gdzieś w innym miejscu. Nie zawsze chciałbym przekazywać otwarty plik .ino do wgrania poprzez Arduino IDE i wolałbym wysłać komuś np. plik .hex do wgrania np. eXtreme Burner'em.
    Zrobiłem zatem tak, że zaprogramowany jak wyżej uC zaczytałem w eXtreme Burnerze i zapisałem to do pliku .hex
    Następnie takowy plik zapisałem na nowym uC i wygląda na to, że chyba zadziałało bo nie dostałem żadnych błędów.
    Pytanie zatem czy da się tak przenieść całą zawartość uC? Co z bootloaderem i fusami w takim przypadku? Czy .hex zawiera cały komplet danych taki, że po wgraniu na świeży uC staje się on dokładną kopią pierwowzoru programowanego z Arduino IDE?

  • #2 07 Sty 2016 23:05
    excray
    Poziom 38  

    Nie. Plik zawiera tylko zawartość Flash. Zawartość pamięci eeprom oraz fusebity musisz przekazać oddzielnie.

  • #3 07 Sty 2016 23:14
    mac310
    Poziom 11  

    OK zatem wysyłam .hex i zakładając, że w eepromie niczego nie zapisuję to tylko fusebity do wpisania ręcznie w eXtreme Burnerze.
    Czy te fusebity mogę gdzieś znaleźć, żeby je poprawnie wpisać poza Arduino IDE? Czy to są te 0x?? z pliku boards.txt:

    Kod: txt
    Zaloguj się, aby zobaczyć kod

    No i czy bootloader jest zawarty razem z programem w pliku .hex?
    Czy dobrze myślę, że najpierw trzeba wysłąć te fusebity do uC, a następnie wsad z .hex?

  • #4 08 Sty 2016 06:16
    emarcus
    Poziom 34  

    mac310 napisał:

    Pytanie zatem czy da się tak przenieść całą zawartość uC? Co z bootloaderem i fusami w takim przypadku? Czy .hex zawiera cały komplet danych taki, że po wgraniu na świeży uC staje się on dokładną kopią pierwowzoru programowanego z Arduino IDE?

    Nie używam eXtreme Burner, więc tu moja opinia może byc nie dokładna.(!)
    Wydaje mi się jednak że jest to bardzo okrężna droga.
    Pierwsze pytanie, które nasuwa się na myśl to:
    -czy ten drugi urzytkownik programu potrzebuje miec wgrany bootloader na nowy mega88?; czy go będzie wykorzystywał tak jak w Arduino?
    Podejrzewam że eXtreme Burner (podobnie jak inne programy), stworzył ci kopię całej zawartości mem. flash (włącznie z bootloaderem). Mając taką kopię, otwórz ja w Notepad i prześledź jego zawartośc. Jeżeli masz ewidentne dwie grupy wpisanej Data przedzielone dłuższym obszarem FF FF FF FF .... itd, to ta druga częśc (pod koniec flash jest bootloader). Najczęściej dla 'wolnostojącego' processora bootloder nie jest potrzebny, a zatem i zmieniony dla niego fusebit (vector addressu startu) nie jest też potrzebny co w sumie lekko wydłuża czas startu programu a bootloader zajmuje tylko miejsce w pamięci.\

    Naturalnie fusebity ustawiające częstotliwośc pracy processora winny byc ustawione zgodnie z board dla której jest/była przeprowadzona kompilacja (zwykle 16 MHz, lecz tu może byc inaczej).

    Jest jeszcze inna, prostsza metoda: (dotyczy o.s. Windows)
    Podczas kompilacji Arduino tworzy na twoim komputerze własny folder;patrz pod:

    C:\Users\Twojeimie\AppData\Local\Temp
    Nowy folder będzie zaczynał się od 'build' dalej będzie z 18-20 numerów i miał rozszerzenie .tmp
    W tym folderze Arduino utworzy około 60 plików, z których kilka będzie nosiło nazwę kompilowanego projektu na przykład:
    ..................
    Example_4__Blink1_with_millis.cpp.eep
    Example_4__Blink1_with_millis.cpp.elf
    Example_4__Blink1_with_millis.cpp.hex
    ......................
    Popatrz na rozszerzenia tych plików;
    - pierwszy z tej listy (*.eep)zawiera zawartośc eeprom (w formacie hex) - jeżeli program nie wykorzystuje eeprom-to plik jest 'pusty'.
    - trzeci (*.hex) - to zasadniczy plik hex samego programu. - mozesz go wpisac do nowego processora czymkolwiek np. AvrDude, AVRStudio, programator Mirka K, nawet Bascom - wskazując miejsce pliku na dysku.

    - i drugi (*.elf) -masz w nim w zasadzie wszystko (flash, fuses, lockbits,eeprom) - możesz go wykorzystac do programowania produkcyjnego na przykład w AVR studio. W twoim przypadku nie bardzo przydatny(?)

    Pliki te zarówno jak i cały folder są dostępne tylko po zakończonej kompilacji i do czasu zamknięcia Arduino IDE. Możesz je przeglądac, kopiowac w inne miejsce etc. Po zamknięciu Arduino IDE cały ten folder jest wykasowany i już go nie znajdziesz.

    e marcus

  • #5 08 Sty 2016 09:01
    mac310
    Poziom 11  

    Dzięki za wyjaśnienia. Postaram się prześledzić Twoje rady.
    Co do wczytywania zawartości już zaprogramowanego uC, żeby skopiować go na kolejny układ to był pomysł na wypadek braku źródeł .ino. Wtedy mógłbym np. zrobić kopię działającego już procesora.

    Z prześledzenia zawartości pliku .hex jakoś nie widzę w nim opisanych grup oddzielonych FF, jednocześnie mam wrażenie, że jak wziąłem czystą megę i wrzuciłęm na nią ten .hex oraz ustawiłem FuseBity tak jak znalazłem w boards.txt to układ zaczął działać jak zaprogramowany poprzez Arduino IDE. To mały test ale może jednak to działa bo nie wiem jak jeszcze można przetestować taką procedurę?
    No i jeszcze jedna wątpliwość. Czy można tym samym plikiem .hex zaprogramować podobny, choć nieidentyczny układ np. zamiast 88PA użyłbym 328, 328P lub 168P itp? One są chyba zgodne i różnią się tylko wielkością pamięci...

  • #6 08 Sty 2016 10:54
    piotrva
    Moderator Mikrokontrolery

    W odczytanym pliku hex będziesz miał bootloader, ale musisz pamiętać, że jeśli procesor jest zablokowany przed odczytem to pomimo, że da się go zaprogramować bootloaderem to nie odczytasz jego zawartości (plik hex będzie miał same FF lub kolejne liczby lub inne śmieci.

  • #7 08 Sty 2016 11:08
    mac310
    Poziom 11  

    No rozumiem. Jeśli zablokowany to się nie da odczytać. Nie chodzi mi o hakowanie obcych procesorów. Miałem na myśli np. swój procesor, który chciałbym skopiować na odległość albo nie mam do niego z jakichś powodów źródeł.
    Dzięki za wyjaśnienia.

 
Black Friday do -15%
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
Ferguson