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

[ATmega8] flash a wielkość pliku HEX

webmortiz 02 Lut 2009 16:02 3199 16
  • #1 6091994
    webmortiz
    Poziom 20  
    Wybaczcie banalne pytanie ale jak się ma wielkość pliku hex do ilości pamięci flash w ATmedze? Zawsze myślałem że rozchodzi się tu 1:1 ale zwątpiłem jak przeglądałem materiały dla usbasp. Autor zrobił to na ATmedze46 (4k flash) + Atmega8 (8k flash) a hex w materiałach ma ponad 10k. Więc jak to jest?
  • #2 6092069
    lamator
    Poziom 12  
    Jak sprawdzales wielkosc pliku HEX (Windows - rozmiar czy rozmiar na dysku) :P?
  • Pomocny post
    #3 6092087
    PiotrPitucha
    Poziom 34  
    Witam
    HEX nie jest czystym kodem binarnym, zawiera zdziebko więcej informacji i możesz sobie go podglądnąć edytorem tekstowym, jeśli chcesz wiedzieć ile naprawdę zajmuje to zrób z niego BIN :D
    Wiele programatorów (programów do nich) potrafi zapisac pliki jako BIN lub możesz to zrobić zewnętrznym programem np. HEX2BIN
    Piotr
  • Pomocny post
    #4 6092485
    Galareta
    Poziom 23  
    Niżej głupoty :P Lepiej w wiki sprawdzić :] nie 100% głupoty ale mija się z prawdą, (Link post niżej dał kolega)

    HEX jest zapisany jako liczba 16 w ASCII czyli 8 bitów zajmuje 16 + do tego adresy komórek początkowych co jakiś czas (bynajmniej tak mi się wydaje)
    :1000000012C02CC02BC02AC029C028C027C026C0BF

    Tak wygląda 1 linijka pliku HEX

    Adres:

    Koniec głupot

    pojedyncze 8b jest rozpisane jako np.

    czyli zajmuje 16b:]
  • #6 6095173
    webmortiz
    Poziom 20  
    Ok, dzięki za odpowiedź. Kamień spadł mi z serca jak się okazało że grubo więcej kodu mogę upchać do ATmegi ;) Temat można zamknąć.
  • #7 6095392
    PiotrPitucha
    Poziom 34  
    Witam
    Galareta, HEX zawiera zgodnie z tym co napisałem więcej informacji, po pierwsze ma adresy, wiersze zaczynają się dwukropkiem a kończą ... pewnym bajtem i pewnym drugim bajtem, czyli Twoje rozważania że 8b w BINie to 16b w HEXie są mocno nieprecyzyjne, dodatkowo cały HEX też się czymś kończy ale do tego by to zobaczyć trzeba oglądnąć HEXa edytorem tekstowym i porównać z BINem oglądniętym np. w edytorze Bascoma
  • #8 6100016
    webmortiz
    Poziom 20  
    Hmmm... Gdybym wcześniej zwrócił uwagę to zauważyłbym że WinAVR w Output wyświetla bajtowo i procentowo ilość zajętych zasobów procka. Tak jak napisałem, temat do zamknięcia
  • #9 6100018
    arturt134
    Poziom 27  
    No i oczywiście, BIN to zapis CAŁEJ pamięci, tylko w miejscach pustych ma 0xff. Inaczej nie dałoby się odzyskać informacji o adresie danych. Rozmiar pliku BIN jest zawsze taki jak rozmiar pamięci flash danego kontrolera.
  • #10 6100100
    webmortiz
    Poziom 20  
    Cytat:
    Rozmiar pliku BIN jest zawsze taki jak rozmiar pamięci flash danego kontrolera.


    Albo ja źle zrozumiałem albo Ty źle napisałeś. Jeżeli by tak było to np. dla ATmegi 8 bin zajmowałby 8kB, a tak naprawdę to chyba zajmuje tyle ile wynika z kompilacji danego softu który napisałeś.
  • #11 6100189
    arturt134
    Poziom 27  
    Dokładnie tak. BIN dla ATmega8 będzie miał 8kB.
    Jeżeli twój projekt po kompilacji zajmie 1kB, to tylko 1kB z tych 8 bedzie zawierał jakieś dane. Reszta to będzie 0xff. Plik BIN jest niczym innym jak obrazem pamięci.
  • #12 6100229
    K_o_n_r_a_d
    Poziom 23  
    arturt134 napisał:
    Rozmiar pliku BIN jest zawsze taki jak rozmiar pamięci flash danego kontrolera.
    arturt134 napisał:
    Dokładnie tak. BIN dla ATmega8 będzie miał 8kB.
    Jeżeli twój projekt po kompilacji zajmie 1kB, to tylko 1kB z tych 8 bedzie zawierał jakieś dane. Reszta to będzie 0xff. Plik BIN jest niczym innym jak obrazem pamięci.
    Nie zawsze. Zależy od kompilatora, np. Bascom nie wypełnia niewykorzystywanych bajtów pamięci programu wartością 0xff. Czyli w Bascomie plik BIN będzie rozmiarem równy wielkości programu skompilowanego wgrywanego do pamięci.

    Dodano po 2 [minuty]:

    BIN odczytany z pamięci uK będzie równy wielkością z rozmiarem pamięci uK.
  • #13 6100346
    webmortiz
    Poziom 20  
    Z K_o_n_r_a_d mogę się zgodzić. Hex który ostatnio wygenerowałem zajmował 7k z groszem po wrzuceniu na programik hex2bin bin zajmował 2k albo 3k z groszem, nie pamiętam już. A przy zrzucaniu z uC zapewne zrzucana jest cała pamięć.


    -- dopiska --

    żeby nie było pisząc wygenerowałem - w sensie skompilowałem projekt i kompilator mi go wygenerował ;)
  • #14 6100473
    arturt134
    Poziom 27  
    To spróbuj wygenerować hex-a, który będzie miał zapisany 1 bajt pod ostatnim adresem we flash.
  • #16 6100526
    arturt134
    Poziom 27  
    Po prostu chciałbym się upewnić, że moja teoria jest błędna.... Do tej pory uważałem, że taki plik jest obrazem pamięci i jako taki nie może mieć innego rozmiaru. No chyba, że ten co generował bin z hex-a zrobił to źle.

    A propos teorii o samochodach z 3 kołami... Myślę że mądrości na tym poziomie nie powinieneś ogłaszać na tym forum.
    Pozdrawiam.
  • #17 6100566
    Freddie Chopin
    Specjalista - Mikrokontrolery
    twoja teoria jest zla - bin bedzie zajmowal tyle ile bedzie mial potrzebe zajmowac. jesli dasz na koncu pamieci zmienna (a w zasadzie stala), to bedzie on obejmowal caly obszar pamieci flash. jesli nie, to po co ma zajmowac wiecej?

    wartosci 0xFF (zreszta niezawsze takie) w pamieci znajda sie same, dzieki operacji kasowania ukladu - nie ma potrzeby (a wrecz byloby to bezsensu) zapisywac ich ponownie.

    4\/3!!
REKLAMA