Dlaczego ciągle używamy plików hex?

Co najmniej dwa powody - prostota i chęć ukrycia informacji nt. programu w mcu.
Rozwój większego systemu bez elf się nie obejdzie, ale w pracy nad małym projektem typu PIC10Fxx albo ATtiny, hex wystarczy.

Mlody_Zdolny wrote:

Rozwój większego systemu bez elf się nie obejdzie, ale w pracy nad małym projektem typu PIC10Fxx albo ATtiny, hex wystarczy.

Może i wystarczy, ale skoto i tak musimy generować elf, w dodatku narzędzia potrafią z niego korzystać, to po co hex? Dla mnie jedyna zaleta to łatwość edycji i prostota struktury, któa ma znaczenie wyłącznie jeśli byśmy np. hexa przesyłali bezpośrednio do MCU, np. przez bootloader.

Pliki hex używane są np. do aktualizacji firmware. Udostępniając tylko plik hex twórca nie dzieli się informacjami na temat struktury projektu, użytymi bibliotekami itp.
Co prawda bardziej szanujący się twórcy dodatkowo szyfrują tego typu pliki, ale ogólnie chodzi o to, że udostępnianie informacji potrzebnych w procesie developmentu na zewnątrz to zła praktyka działająca na niekorzyść projektu.

tmf wrote:

i tak musimy generować elf

A co, przyjdzie ktoś z policji sprawdzać?
Cześć kompilatorów nie generuje go jeśli nie potrzebujemy, albo nie generuje wcale.
Ile programatorów obsługuje ELFy?
Zostaję przy BIN/HEX. Proste w podglądzie czy dalszej obróbce.

Równie dobrze można by zapytać czemu używamy plików .bin

Odkąd przesiadłem się na ESP32 używam ELF i oczywiście BIN. Jako parsery służą readelf oraz objdump.

Po co wybierać jak można mieć wszystko na raz. ELF jest generowany chyba zawsze i wystarczy jedno polecenie (avr-objcopy) żeby wyłuskać z niego HEX albo BIN. Dla programisty to bez znaczenia, ustawi sobie w projekcie i z automatu się one wygenerują. Użyje tego co jest mu wygodne. Dla użytkownika, który chciałby sobie wgrać firmware i posiadający mało zaawansowany programator to ELF może być kłopotliwy i niepotrzebnie zmuszać do instalacji toolchaina.

Zaletą HEX albo BIN jest łatwa późniejsza modyfikacja stałych (fonty, grafika, stablicowane wartości, etc.), oczywiście pod warunkiem że zna się ich adres w pamięci. Nie potrzebny jest dostęp do kodu i w prosty sposób proces można zautomatyzować a grzebanie w ELF nie jest już takie proste.

jvoytech wrote:

ELF jest generowany chyba zawsze i wystarczy jedno polecenie (avr-objcopy) żeby wyłuskać z niego HEX albo BIN.

Dokładnie. W drugą stronę to już nie zadziała

jvoytech wrote:

Zaletą HEX albo BIN jest łatwa późniejsza modyfikacja stałych (fonty, grafika, stablicowane wartości, etc.), oczywiście pod warunkiem że zna się ich adres w pamięci

I pod warunkiem poprawienia sumy kontrolnej.

Mlody_Zdolny wrote:

Udostępniając tylko plik hex twórca nie dzieli się informacjami na temat struktury projektu, użytymi bibliotekami itp.

To nie jest prawda. Z elf można usunąć te dodatkowe informacje np. programem strip, ma się pełną kontrolę nad tym co w pliku finalnie się znajdzie.

piotr_go wrote:

A co, przyjdzie ktoś z policji sprawdzać?

A tak ogólnie to o co ci chodzi? Może niedobór magnezu?

piotr_go wrote:

Cześć kompilatorów nie generuje go jeśli nie potrzebujemy, albo nie generuje wcale.
Ile programatorów obsługuje ELFy?

gcc generuje, a jest to jeden z popularniejszych kompilatorów na arm i avr. Pozostałe to raczej wśród hobbystów sprawy niszowe. Jeśli chodzi o programatory, to jakie dla avr i arm nie obsługują elfów?

jvoytech wrote:

Po co wybierać jak można mieć wszystko na raz. ELF jest generowany chyba zawsze i wystarczy jedno polecenie (avr-objcopy) żeby wyłuskać z niego HEX albo BIN. Dla programisty to bez znaczenia, ustawi sobie w projekcie i z automatu się one wygenerują. Użyje tego co jest mu wygodne. Dla użytkownika, który chciałby sobie wgrać firmware i posiadający mało zaawansowany programator to ELF może być kłopotliwy i niepotrzebnie zmuszać do instalacji toolchaina.

Pytanie po co wszystko na raz? Wystarczy to z czego się korzysta. Co do tych programatorów, to jakie konkretnie nie wspierają elfów? Bo się to ciągle przewija, a ja się jeszcze z takim nie zetknąłem (piszę o ARM i AVR).
Jak dla mnie główną zaletą elfów w stosunku do hex jest możliwość umieszczenia wszystkiego w jednym pliku. Mniejszy bałagan, a i przy okazji jakiś tam zysk wydajnościowy jest, bo można ominąć etap tworzenia hexów.

tmf wrote:

Z elf można usunąć te dodatkowe informacje np. programem strip, ma się pełną kontrolę nad tym co w pliku finalnie się znajdzie.

Można, tylko po co skoro można użyć hexa?
Analogiczna sytuacja jak z ipv4 i ipv6. Kto musi ten używa bardziej złożonych standardów, a kto nie musi wybiera rozwiązania prostsze.
W systemie, nad którym pracuje kilka zespołów, normalne jest, że do taska w jirze tester nie wrzuci hexa tylko elfa z dumpem, żeby programista mógł szybko ruszyć z tematem.

Mlody_Zdolny wrote:

Można, tylko po co skoro można użyć hexa?

Bo:
- elf i tak jest generowany,
- stripować elfa wystarczy jednorazowo jeśli publikujesz wynik pracy, a generować hexy musiałbyś przy każdej kompilacji.

tmf wrote:

jvoytech wrote:

Po co wybierać jak można mieć wszystko na raz. ELF jest generowany chyba zawsze i wystarczy jedno polecenie (avr-objcopy) żeby wyłuskać z niego HEX albo BIN. Dla programisty to bez znaczenia, ustawi sobie w projekcie i z automatu się one wygenerują. Użyje tego co jest mu wygodne. Dla użytkownika, który chciałby sobie wgrać firmware i posiadający mało zaawansowany programator to ELF może być kłopotliwy i niepotrzebnie zmuszać do instalacji toolchaina.

Pytanie po co wszystko na raz?

Tak bez powodu, przyda się. Jeżeli projekt publiczny to co przeszkadza wygenerować do katalogu ELF, HEX,BIN? Zainteresowany może wybrać ulubioną opcję a nas nic to nie kosztuje. Projekt prywatny to pełna zgoda i na ELFach można poprzestać.

tmf wrote:

Wystarczy to z czego się korzysta. Co do tych programatorów, to jakie konkretnie nie wspierają elfów? Bo się to ciągle przewija, a ja się jeszcze z takim nie zetknąłem (piszę o ARM i AVR).

Nie programatory tylko programy do obsługi tych programatorów. Na pewno jakieś własne rozwiązania mogą go nie obsługiwać bo potrzebny extra czas do jej implementacji. Kiedyś korzystałem z stm32flash i on ELF nie rozumie. Na AVR oczywiście korzystam z avrdude i karmie go ELFem.

tmf wrote:

Jak dla mnie główną zaletą elfów w stosunku do hex jest możliwość umieszczenia wszystkiego w jednym pliku. Mniejszy bałagan, a i przy okazji jakiś tam zysk wydajnościowy jest, bo można ominąć etap tworzenia hexów.

Z tym zyskiem to poleciałeś. Przecież to ma praktycznie zerowy koszt (no może parę milisekund). Ale kompaktowość i brak bałaganu jest faktycznie dużą zaletą.

HEX/BIN to prostota. Prosty skrypt może ogarnąć automatyzację podmiany stałych w pamięci FLASH, gdyby zaszła potrzeba modyfikacji firmware pod końcowe urządzenie. Z ELF też się da, ale to nie jest już takie proste.

tmf wrote:

Jak dla mnie główną zaletą elfów w stosunku do hex jest możliwość umieszczenia wszystkiego w jednym pliku.

Ale zaleta, o której tu mówisz, dotyczy akurat specyfiki konstrukcji AVRów, gdzie faktycznie jedyną możliwością by to był jeden plik, to format elf. Z powodów znanych.
W przypadku różnych innych uC (np. ARM, PIC24), gdzie wszystkie rzeczy do zaprogramowania (FLASH, EEPROM, bajty konfiguracyjne itd.) znajdują się w jednej przestrzeni adresowej, tego problemu nie ma i pojedynczy plik hex jest w stanie przechować pełną informację potrzebną programatorowi.

jvoytech wrote:

Tak bez powodu, przyda się. Jeżeli projekt publiczny to co przeszkadza wygenerować do katalogu ELF, HEX,BIN? Zainteresowany może wybrać ulubioną opcję a nas nic to nie kosztuje.

Nie twierdzę, że przeszkadza. Bardziej mnie zastanawia po co? Mając elf, użytkownik sobie wygeneruje pozostałe pliki o ile potrzebuje, a zwykle potrzebować nie będzie.

jvoytech wrote:

Z tym zyskiem to poleciałeś. Przecież to ma praktycznie zerowy koszt (no może parę milisekund). Ale kompaktowość i brak bałaganu jest faktycznie dużą zaletą.

Też tak myślałem, zdziwiłem się kiedy wyłączyłem generowanie tych dodatkowych plików. I nie że mam jakiś stary komp - raczej na dzień dzisiejszy dosyć topowy. Jednak przetrawienie sporego elfa najwyraźniej nie jest aż tak krótkie. Oczywiście nie piszę o jakichś kolosalnych oszczędnościach, ani nawet sensownych. Ale da się je odczuć.

jvoytech wrote:

HEX/BIN to prostota. Prosty skrypt może ogarnąć automatyzację podmiany stałych w pamięci FLASH, gdyby zaszła potrzeba modyfikacji firmware pod końcowe urządzenie. Z ELF też się da, ale to nie jest już takie proste.

To prawda, jeśli musisz manipulować plikiem to hex jest prostszy. Jest to też związane z istnieniem np. SRecord do manipulacji, niestety chyba nie obsługuje on elfów. Można to samo osiągnąć przy pomocy innych programów, ale faktem jest, że nie są one w toolchainie. Z drugiej strony to też zależy co chcemy zmieniać - jeśli tylko np. dodać CRC to faktycznie hex z powodów jak wyżej jest lepszy, jeśli np. komuś przyjdzie do głowy usunięcie lub relokacja segmentów to już tylko elf.

rb401 wrote:

Ale zaleta, o której tu mówisz, dotyczy akurat specyfiki konstrukcji AVRów, gdzie faktycznie jedyną możliwością by to był jeden plik, to format elf. Z powodów znanych.

Raczej sposobu działania programów kontrolujących programatory. Nic nie stoi na przeszkodzie, aby nawet dla AVR wszystko było w jednym hex - w końcu te odrębne elementy zajmują oddzielne wirtualne adresy. Jednak twórcy narzędzi zdecydowali inaczej.

rb401 wrote:

W przypadku różnych innych uC (np. ARM, PIC24), gdzie wszystkie rzeczy do zaprogramowania (FLASH, EEPROM, bajty konfiguracyjne itd.) znajdują się w jednej przestrzeni adresowej, tego problemu nie ma i pojedynczy plik hex jest w stanie przechować pełną informację potrzebną programatorowi.

Raczej konfig fuse/lock bitów dla ARMów (przynajmniej niektórych) też musisz mieć osobno, nie ma go w hexie.

tmf wrote:

Nic nie stoi na przeszkodzie, aby nawet dla AVR wszystko było w jednym hex - w końcu te odrębne elementy zajmują oddzielne wirtualne adresy.

Bzdura. Do lock/fuse/itp są zupełnie inne komendy. Programowanie tego wygląda kompletnie inaczej niż flasha. Nie jest to żaden "oddzielny adres".

Jeśli chodzi o ARMy (np STM32) to ELFem lockbitów się nie ustawi.
Wymagany jest wielokrotny zapis czy delaye. Czasem odczyt.

piotr_go wrote:

Bzdura. Do lock/fuse/itp są zupełnie inne komendy. Programowanie tego wygląda kompletnie inaczej niż flasha. Nie jest to żaden "oddzielny adres".

Jak pisałem, zażyj sobie magnezu, napij się czegoś mocniejszego lub użyj innej metody, która cie uspokaja zanim coś napiszesz. Bo niestety bzdury sam opowiadasz i wykazujesz się nieznajomością toolchaina dla AVR.
W toolchainie z microchipa przyjęto, że dla rozróżnienia różnych typów pamięci nadano im pewne offsety, tak jest dla FLASH, EEPROM, sygnatur użytkownika, programu, fuse- i lockbitów. Dzięki temu technicznie można wszystko wrzucić w jeden HEX. Jest tylko kwestia jego interpretacji, czego np. AVRDude, czyli powszechnie stosowany program do obsługi niefirmowych programatorów nie robi. To jak fizycznie programuje się poszczególne elementy jest bez znaczenia dla samej struktury pliku hex. Dla przykładu narzędzia z microchipa i Microchip Studio używają plików elf i w ogóle ignorują hexy, i jeśli elf zawiera sekcje odpowiadające fuse- i lock-bitom, lub inne sekcje pamięci, to mogą one być automatycznie programowane.

piotr_go wrote:

Jeśli chodzi o ARMy (np STM32) to ELFem lockbitów się nie ustawi.
Wymagany jest wielokrotny zapis czy delaye. Czasem odczyt.

Sugerujesz, że istnieje powiązanie pomiędzy strukturą pliku elf, a sposobem programowania poszczególnych typów pamięci/elementów MCU? Jedno z drugim nie ma nic wspólnego. Rolą programu sterującego programatorem jest rozpoznanie z czym ma do czynienia i jak to zaprogramować, a elf ma tylko dostarczyć dane do programowania. Równie dobrze mógłbyś napisać, że w ELF nie można umieścić danych do EEPROM i FLASH, bo procedura programowania tych dwóch pamięci jest różna. Niektóre narzędzia mają ograniczenia, ale nie wynikają one ze struktury elf/hex, czy odmienności sposobu programowania różnych elementów MCU.

Tu zresztą dowód, że jest tak jak piszę - fragment wygenerowanego pliku map po kompilacji:


Jak widać sekcje odpowiadające poszczególnym typom pamięci mają odpowiednie offsety, technicznie można je więc przenieść do jednego hexa, tylko program sterujący programatorem musiałby to umieć poprawnie zinterpretować.

tmf wrote:

text 0x00000000 0x00000800 xr
data 0x00803f80 0x00000080 rw !x
eeprom 0x00810000 0x00000040 rw !x
fuse 0x00820000 0x0000000a rw !x
lock 0x00830000 0x00000400 rw !x
signature 0x00840000 0x00000400 rw !x
user_signatures 0x00850000 0x00000400 rw !x
*default* 0x00000000 0xffffffff

Podaj przykład innego producenta który takie cuda wyczynia. Dziś adresy są takie, za kilka updatów mogą być inne
Nie ma to nic wspólnego z AVRami. To tylko wymysł tego kto napisał skrypt linkera. Równie dobrze mogę sobie tak poprzydzielać fałszywe adresy dla dowolnego innego układu.
Porównaj programowanie pamięci AVRa z np. STM8 albo PIC. Tam są adresy przydzielone konfiguracji czy eepromowi.

AVR:

STM8:

piotr_go wrote:

Bzdura. Do lock/fuse/itp są zupełnie inne komendy. Programowanie tego wygląda kompletnie inaczej niż flasha. Nie jest to żaden "oddzielny adres".

Chyba nie do końca masz rację.
Zrobiłem taki eksperyment. Wziąłem STM32L152RE (bo ma EEPROM) i spreparowałem jeden plik hex z trzema obszarami. Flash (od 0x08000000, blink jakiś), EEPROM (od 0x08080000, tekst próbny) i Option Bytes bank 0 (od 0x1FF80000, zgrany z kostki z przestawionym względem fabrycznego BOR level). Następnie wróciłem do fabrycznego BOR level i skasowałem FLASH i EEPROM.
Wczytałem tego hexa do STM32CubeProgrammer. Ładnie rozpoznał segmenty:


No to Start... .

Z flash i eeprom poszło bez problemu. Ale już z Option Bytes zgłosił błąd:


No dobra. Nie da się.
Przyglądam się kostce i widzę że flash i eeprom ok, program działa.
Ale jak wszedłem do Option Bytes z poziomu opcji STM32CubeProgrammer, to widzę że są zmiany, tyle że jakieś porąbane to wyszło. BOD level zmienił się na inny poziom. Ale nie ten który był w kostce przed programowaniem, ani ten który był w hexie. Oraz pojawiło mi się sporo blokad zapisu do segmentów. Na szczęście nie włączyło mi się chip protection, to wysprzątałem ten bałagan ręcznie.

Czyli eksperyment pokazał że z poziomu programowania obszarów pamięci, daje się zmieniać fusy w STM32, tylko co do przygotowania zawartości w pliku hex to nie jest tak prosto jak mi się wydawało. I pewnie trzeba by co nieco doczytać w dokumentacji by robić to w sposób kontrolowany.

Jeszcze w ramach ciekawostki, to kiedyś pisywałem softy na dsPIC30 i tam ewidentnie fusy (zestaw podobny jak w Atmelach, czyli opcje sprzętowe generatora taktującego, opcje blokady odczytu itp. ) były umieszczone w przestrzeni adresowej pamięci. I ustawienia tych fusów wychodziły z IDE w jednym pliku hex wraz z zawartością flash i eeprom.
Tak że jeden plik hex załatwiał kompletne programowanie kostki.

rb401 wrote:

Chyba nie do końca masz rację.

Pisałem o AVR:


STM32 coś tam się inaczej robiło przy option bytes.

Ja raczej z BIN korzystam, mniej roboty jak chcę do bootloadera zaszyfrować.
Lockbity załatwiam oddzielnie skryptem na sam koniec, jak już wszystko śmiga.

piotr_go wrote:

Podaj przykład innego producenta który takie cuda wyczynia. Dziś adresy są takie, za kilka updatów mogą być inne
Nie ma to nic wspólnego z AVRami. To tylko wymysł tego kto napisał skrypt linkera. Równie dobrze mogę sobie tak poprzydzielać fałszywe adresy dla dowolnego innego układu.

Ma o tyle wspólnego, że to oficjalne informacje publikowane na stronie microchipa i zaszyte w toolchainie microchipa - piszę o tym komercyjnym. Oczywiście jest to kwestia umowna i kiedyś tak to wymyśliły osoby portujące gcc na platformę AVR. Z tej konwencji korzystają też narzędzia. Oczywiście, może ktoś to kiedyś zmienić, ale tak można zmienić wszystko, w tym poważniejsze rzeczy, np. ABI kompilatora.
Natomiast istotą jest to, że dzięki tej konwencji można bez problemu stworzyć hex, któy zawiera informacje o różnych elementach MCU, czy takie informacje poprawnie zinterpretuje software napisany przez niezależne osoby to zupełnie inna historia.
Ale ot właśnie też argument za używaniem ELF - mamy jeden plik, który wspiera takie rzeczy natywnie, jest to też wspierane przez soft producenta, dzięki temu użytkownik nie musi w ogóle wiedzieć o takich niuansach o których piszemy.

tmf wrote:

dla rozróżnienia różnych typów pamięci nadano im pewne offsety, tak jest dla FLASH, EEPROM, sygnatur użytkownika, programu, fuse- i lockbitów. Dzięki temu technicznie można wszystko wrzucić w jeden HEX

Mam dwa pytania odnoście głównego tematu. Pierwsza sprawa, programując procesor prosto z MS7 wszystko mi jedno co sobie program obsługujący zasysa, mam zdefiniowane fusy i lock bity więc jest wygodnie i szybko. Wciskam F5 i mam za jednym razem gotowe urządzenie do testów (wgrany flash/ eeprom, ustawione fuse i lock bity). Jeśli się nie mylę to dzieję się tak właśnie dzięki plikom elf. No ale stworzyłem sobie bootloader i chcę go łączyć razem z domyślna wersją firmware więc po prostu łącze ręcznie oba pliki hex (app.hex + boot.hex) i teraz ładuję do procesora ale fuse i lock oraz eeprom robię już ręcznie. Jak to wrzucić z powrotem do pliku elf?

Druga sprawa, polecicie jakieś wygodne narzędzie/ program GUI do obsługi ATMEL-ICE? Wbudowane w MS7 jest fajne ale żeby je użyć muszę odpalić całe środowisko, które nie jest małe...
AVRDUDE + avrdude-GUI z nieznanych jak dotąd mi powodów nie działa:



Widziałem, że powstała nakładka na atprogram: https://github.com/RuggedScience/atprogram-gui ale nie ma tam exe do pobrania (a kod wygląda jakby powstał w QT, którego nie posiadam)
_________
edit: no a jednak jest exe: https://github.com/RuggedScience/atprogram-gui/releases

Kolejna opcja to AN2466: Using Atmel-ICE for AVR® Programming In Mass Production

I tu też albo nie potrafię znaleźć albo temat umarł bo brak pliku do pobrania na stronie Microchip.

Podpowie ktoś/ coś?

Karol966 wrote:

No ale stworzyłem sobie bootloader i chcę go łączyć razem z domyślna wersją firmware więc po prostu łącze ręcznie oba pliki hex (app.hex + boot.hex) i teraz ładuję do procesora ale fuse i lock oraz eeprom robię już ręcznie. Jak to wrzucić z powrotem do pliku elf?

Zastosować program objcopy - potrafi robić konwersje w obie strony.

Karol966 wrote:

Druga sprawa, polecicie jakieś wygodne narzędzie/ program GUI do obsługi ATMEL-ICE? Wbudowane w MS7 jest fajne ale żeby je użyć muszę odpalić całe środowisko, które nie jest małe...

Osobiście nie znam, bo nie używam, wydaje mi się, że jeśli potrzebujesz programować poza GUI to większy sens ma wywołanie narzędzi z linii poleceń. Po co ci w takiej sytuacji GUI?

tmf wrote:

Po co ci w takiej sytuacji GUI?

Choćby dlatego, że wychowałem się już po czasach DOS'a i wiersza poleceń nie zdążyłem polubić dlatego wszelkie nakładki są dla mnie dużo wygodniejsze.

PS. Co ciekawe zbudowałem sobie program, który szyfruje pliki bin przed wrzuceniem na serwer właśnie z obsługą z poziomu wiersza poleceń ale to tylko dla tego że w VS Code jeszcze nie nauczyłem się robić form'sów

Karol966 wrote:

Programming In Mass Production

- wydaje mi się, że jak sama nazwa wskazuje, narzędzie to powstało właśnie w takim celu jak mnie interesuje, no ale nie zdobyłem go. Nakładka na atprogram nie działa u mnie.

Karol966 wrote:

PS. Co ciekawe zbudowałem sobie program, który szyfruje pliki bin przed wrzuceniem na serwer właśnie z obsługą z poziomu wiersza poleceń ale to tylko dla tego że w VS Code jeszcze nie nauczyłem się robić form'sów

I właśnie dlatego narzędzia z linii poleceń są wygodniejsze - wywołanie szyfrowania, przygotowania pliku, czy uploadu na serwer/programowania urządzenia możesz zintegrować np. z makefiile, w efekcie albo kliknięcie w IDE, ale proste wywołanie załatwia wszystko. Z GUI moim zdaniem na dłuższą metę jest to niewygodne i nie da się zautomatyzować. Ale oczywiście co kto lubi, nie ma jednej drogi

Zapomniałem o plikach bat. Również z nich korzystałem przy szyfrowaniu atmelowskim AES (jeśli dobrze pamiętam to było avr231). Taki plik bat miałem utworzony do szyfrowania i osobny do programowania. To już było dużo wygodniejsze.

PS. Ja cały czas mówię o powtarzalnych czynnościach, nie o pojedynczej akcji stąd taki plik bat jest na prawdę pomocny. Klikam 2 razy lpm i gotowe, nic nie trzeba wpisywać w wierszu poleceń (ew konsola pyta o nazwę/wersję pliku). Takie rozwiązanie faktycznie można polecać.