AVReAl update — 1.28r8

avreal v1.28r8 (Sat 2011-08-13) has been released.

  • Raw binary file support is added.
    Binary files are denoted by :bin: prefix in file name.
  • -r switch behavior is changed.
    -r+ forces writing full memory content into output file (“old” behavior of -r).
    When -r is used, rows which contain only FF bytes in data field will not be written into :ihex: output file. FF-only tail will not be written into :bin: file.

15 Responses to “AVReAl update — 1.28r8”

  1. Viktor says:

    Ще виникло питання – як стерти EEPROM при програмуванні в 128-й атмезі. Окремий запуск програми з встановленням -feesv=0 результату не дає:

    avreal32.exe  +mega128 -p1 -aa -o1.8432MHZ -e -w -fBODLEVEL=0,BODEN=0,SUT=0,CKSEL=E,OCDEN=1,JTAGEN=1,CKOPT=1,EESAVE=0,BOOTSZ=0,BOOTRST=1,M103C=0,WDTON=1
    • ReAl says:

      -feesv=0 — це зовсім інше. Це фьюз заборони стирати EEPROM при стиранні мікросхеми по -e
      При записаному eesv по команді стирання кристалу внутрішній автомат зітре лише флеш.
      Щоб по -e стиралася пам’ять EEPROM, треба записати -feesv=1. При наступних запусках avreal -e стиратиметься і EEPROM.

  2. smartly says:

    Хе. Ще б додати підтримку формату elf.

    • ReAl says:

      І ти туди ж 🙂
      Та я давно розумію, що підтримка elf «дуже бажана». З тих пір, як додали стандартизований спосіб записати в нього fuses.
      Будемо вважати, що перший крок зроблено.

      • smartly says:

        Ну, там запропонували викликати враппер який викликає objcopy, а потім avreal. Ця ідея і так у повітрі. В принципі під юніксом зазвичай можна покладатися і на наявність objcopy, і на наявність libbfd.

        А можна лінку на стандартний спосіб тримання фузів у ELF ?

        • ReAl says:

          В першому повідомленні там шукають програматор з підтримкою ELF.

          Стандартний спосіб — розміщення певної проініціалізованої структури у зарані визначеній секції .fuse
          Користуватсия через включення avr/fuse.h
          BootLockBits живуть в одному байті з LockBits і тому потрапляють в іншу секцію, .lock. І живуть в avr/lock.h

          В лінкерних скриптах секції прибито на фіксовані адреси.
          Тому можна було б викидати їх у hex-файл без зміни адреси, як то робиться для секції .eeprom, і брати програматором з тих верхніх адрес.

  3. Viktor says:

    Не можу прошити бінарнік, строка – avreal32.exe +mega128 -p1 -aa -o3.686MHZ -e -w -c :bin:load.bin, результат(скорочено) – …Device erased Device connected, mega128|mega128A detected Fuses .. Programming CODE memory ….. done(!)(295ms) Total time 0,75s Reset pin released Adapter disabled… Як видно з виведеного результату роботи програми запис даних відбувається, але чомусь тільки невеликої частини.

    • ReAl says:

      Дивно. А якщо прочитати тепер у вихідний :bin:-файл?

      Я вдома на mega168 перевіряв, зараз спробую на mega128, але там принципової різниці немає, бо зміни у програмі були лише в частині завантаження файлу з диска. Далі процедури запису отримують дані не знаючи, звідки вони.

      • Viktor says:

        Пробував заливати туж прошивку в hex – все в нормі.

        • ReAl says:

          Щойно оце повернувся з наради і спробував зашити великий (більше 100К) файл в mega128. У мене був hex-файл з випадковими даними, згенерований srecord-ом. Я трохи повирізав, щоб були дірки і обрізав хвіст, щоб перевіряти -r/-r+.

          Тим же srec-cat-ом перегнав в bin, записав bin, верифікацію зробив з hex — співпало.
          Прочитав окремо в bin в інший файли, він побайтно співпав з початковим.

          «Тю, зараза». Вишліть мені на пошту bin та hex файли, я спробую їх позаливати.

        • Viktor says:

          Конвертую цією програмкою http://www.blog-cub.pp.ua/программа-конвертация-hex-в-bin, може то справа в ній(хоча Uniprog шиє нормально). Спробую ще залити неконвертовані нею bin-файли, але то вже десь аж після завтра.

        • ReAl says:

          А все ж таки вишліть мені прошивки — обидві, і hex, і ту конвертовану. На ту адресу, яку avreal виводить на екран.
          Наче й не повинно від самих даних нічого залежати, але…
          Цікаво ж і розібратися.

        • Viktor says:

          Фальшива тривога, проблема виявилася не в програмі, а в операційній системі. Для зручності заливки програм я створив ВАТ файл, який б шукав файл з певним розширенням в певній папці, копіював його в іншу папку, перейменовував і прошивав. Ось частина:

          if exist …\need_to_load\*.hex (copy …\need_to_load\*.hex …\load\load.hex
          …\AVReal\avreal32.exe +mega128 -p1 -aa -o3.686MHZ -e -w -c …\load\load.hex)
          if exist …\need_to_load\*.bin (copy …\need_to_load\*.bin …\load\load.bin
          …\AVReal\avreal32.exe +mega128 -p1 -aa -o3.686MHZ -e -w -c :bin:…\load\load.bin)

          …-повний шлях до файлу.
          Так от, для правильного копіювання необхідно було задати папаметр /B. Без нього система копіювала бінарнік – тільки 127 байт, а в hex додавала в кінець файлу один лишній симлол(байт)(на роботу програми не впливало).

          if exist …\need_to_load\*.hex(bin) (copy …\need_to_load\*.hex(bin) /B …\load\load.hex(bin) /B
          …\AVReal\avreal32.exe +mega128 -p1 -aa -o3.686MHZ -e -w -c (:bin:)…\load\load.hex(bin))

          P.S. Без 100 грам не розберешся…

          • ReAl says:

            Символ Control-Z в багатьох системах здавна означав кінець текстового файлу.
            В текстовому режимі копіювання COPY його додає в кінці, якщо його не було, та копіює по нього, якщо він є, все далі ігнорує.

            Ну і добре, що все знайшлося.

Leave a Reply to ReAl

[flagcounter image]