Я одним письмом сразу обоим - "чтобы два раза не вставать". Тем более, что это с моей точки зрения один ответ.
OR>>> Более того.. Мне даже тяжело понять -- чем может быть хорош отдельный OR>>> GUI программатора (отдельный от среды разработки).
VB>> Hу, оболочка с hex/ascii редактором может быть полезна на предмет VB>> поковыряться с содержимым EEPROM (в том числе и "набортным" EEPROM VB>> микроконтроллера, либо с секциями данных прошивки). Hо и только, IMHO. Ну и пусть этот редактор будет в том софте, с которым человек _работает_. avreal по смыслу не предназначен для _регулярной_ ручной работы, он предназначен для встраивания в кому-какой-удобнее процесс автоматизации. Если мне надо будет поковыряться в EEPRОМ, я открою HEX-файл в MED-е. Собственно, мне за всё время это надо было только один единственный раз, в результате чего avreal научился игнорировать пробелы в HEX-файлах, комментарии в них же и (только по запросу) контрольные суммы.
Дальше пошли спекуляции, так как всё, что начинается с "если бы" -- это уже "не совсем то". Если бы мне это надо было очень часто, каждый день и по многу... Ну не знаю. Скорее всего надо было бы думать о программе в духе когда-то бегавшей (если я правильно помню имя) stl -- могла показывать бинарную информацию в нужном виде (фактически, в виде структур/записей), чтобы не ковыряться в "сырых" байтах вручную.
IMHO функцию редактирования EEPROM должна выполнять IDE программиста, аналогично тому, как можно в симуляторе посмотреть память не только в бинарном виде, но и в виде значений находящихся там переменных. Информацию о размерах (и типах, если ассемблер позволяет) неплохо бы выдёргивать из
.section .eeprom bbb: .byte 0 fff: .single 3.1415926
Итого, на мой взгляд, помещение двоичного редактора в программатор - это костыли, призванные как-то спасти ситуацию с IDE, не поддерживающими то, что надо. Хотя для этого и GUI как таковой не обязателен, текстового режима достаточно :-), визуальные редакторы появились достаточно давно... Причём это навешивание на программатор чужой ему функции редактора, при том, что в IDE уже есть редактор, в симуляторе есть двоичный редактор.
Лучше пусть IDE хорошо выполняет свои функции, а программатор не берёт на себя функции IDE. Начнётся с редактирования прошивок в программаторе, а закончится необходимостью поддерживать coff/ubrof/avrobj и симулировать кристалл :-)
VV> Есть еще одно преимущество: намного приятнее выбирать соответствующие VV> галочки в GUI, чем читать мануал Хех, а почему же тогда даже я (ни разу не запускавший пони-прог) знаю, что у него "галочка стоит -- это 0, а не то, что вы подумали" :-) Тут вот по соседству у одного проблемы с "нечтением по SPI" у 89s8252, а другой ему что он на эти грабли (???) на 90s8515 наткнулся и выяснил (!!!), что для этого надо писать в регситр SPI что-нибудь. Это я к тому, что не читать мануал вообще всё равно не выйдет.
VV> и вписывать в батник десяток фьюзов и прочих опций.
Аналогично. Я нажимаю Ctrl-F9 не в avreal-е, а в MED-е. Как я уже говорил на телесистемах: пользоваться _двумя_ GUI-программами -- редактором исходных текстов с вызовом компиляции, отслеживанием сообщений об ошибках, ... т.е. какой-никакой IDE И программатором -- мне лично неудобно.
А фьюзы я выставляю один раз на проект, когда его завожу. В MED-е в makefile пишу FUSES=-fтра-ля-ля и всё. CPU=atmega8 всё равно там указано для компилятора. Имена выходных файлов тоже в makefile присутствуют в неявном виде, иначе бы make не знал, что ему делать. Всё. Мне это *гораздо* удобнее, чем лазить каждый раз по меню отдельной программы для выбора файла и т.п. Если работать не через makefile, а через оболочку тира того же AVRstudio, то всё аналогично. Там всё равно выбирается тип кристалла, имя проекта, оболочка это всё уже знает. Вот пусть там и fuses устанавливаются, и содержимое EEPROM редактируется. Пусть, раз она INTEGRATED, занимается интерфейсом с программистом. И передаёт что надо программатору. А программатор пусть делает свою работу. Тут, правда, возникает вопрос как передать сами fuse (с процессором проще, это одно имя и его можно подставить через %CPU% или где как в командную строку tools подставляются параметры проекта). Ну так это дело в любом случае поправимое. Стал же avreal (кажется, по просьбе Алексея Бойко) поддерживать имена не только в виде 90s8515, но и at90s8515, чтобы проще было в makefile для gcc вставлять вызов.
VV> Кстати, предложение к AVREALу: фьюзы и локбиты хорошо бы показывать VV> после, а не до программирования. Хорошо.
VB>> Однако если VB>> программатор "заточен" именно под микроконтроллеры - отсутствие GUI не VB>> напрягает совершенно. Скорее даже радует :)
VV> Это просто ты - человек старой закалки :) VV> Среди новых инженеров бытует мнение, что софт без GUI бесмысленнен VV> и бесполезен. В чем-то они правы. Если имеется ввиду то, с чем человек непосредственно работает, то да, хороший UI нужен. Но avreal писался в соответствии с моими привычками в качестве тулзы нижнего уровня, не зависящей от того, что я сейчас выбрал в качестве UI. И успел пожить и под QEdit в dos-окне OS/2, сейчас живёт под MED, на работе на соседнем столе -- под AVRstudio. Было бы это возможно, если бы у него был свой собственный UI?
Wbr,