Подскажите пожалуйста такую штуку. Мне нужно разместить 600 шт констант в памяти программ (t2313). В дальнейшем по необходимости редактировать непосредственно сам скомпилированный hex меняя значения констант, но без перекомпиляции. Редактировать и прошивать будет специальная программа. Собственно вопрос как адресно разместить константы в памяти программ чтобы точно знать какой байт в каком случае менять? Спасибо.

Для этого есть несколько вариантов.
1. Вы вообще не размещаете данный массив. При компиляции генерируете линкером файл map и в нём находите куда линкер его разместил. Соответственно в программе - редакторе задаёте адрес массива. Я бы пошёл этим путём.
2. Вы объявляете свою секцию в линкере, а в программе размещаете массив в данной секции. Адрес секции прописываете за пределами секции программ с какого-то кратного адреса. Этот адрес и используете для доступа.

Файл map идея хорошая. Только чтобы не получилось, что надо отыскивать все 600. А так чтобы конкретно указать, что константа konst1 дложна лежать по адресу 0x0100 к примеру?

Есть специальные правила оформления Hex-файла (т.е. формат файла), где ,например, в конце каждой строки записывается контрольная сумма этой строки. Кто ее будет пересчитывать? Вручную? или писать спец прогу для этого? Хотя у Вас будет своя прога для изменения и прошивки, но Вы тогда должны знать полный формат Hex-файла, чтобы определить позицию для изменения

Лучше всего менять не в Hex-файле, а в сконвертированном из него bin-файле (реализаций hex2bin.exe куча).
bin-файл - это линейный образ проги в памяти МК. Поэтому (чисто мое мнение), лучше создать свою секцию по определенному адресу и зная этот адрес можно изменить любую константу.
Пример, базовый адрес BASE=0x400, относительный адрес konst1 = 0x100, следовательно, абсолютный адрес konst1= BASE + 0x100 = 0x500 !!!!

Вопрос. Памяти 2К, а констант 600 байт. Следовательно, на прогу выходит 1448 байт. Хватит? или прога тупо пересылает эти константы в какое-либо устройство?

в скудном хэлпе на азм вы найдёте магическую дерективу

.org

применима к любому сегменту программы: коду, данным, статике...

удачи вам
(круглый)




если не боитесь доп. гимора с парсером хекс файла (собственно там ничего особенного нет - пару десяток строчек на сях), то отыскать нужное место можно по
а) конкретному смещению. (как уже было сказано выше - инструкция .org вам в помощь)
б) по определённой метке. (тут просто перед константой помещаете свою фамилию в текстовом виде. в последствии её и ищите в хексе)


удачи вам
(круглый)

Для ответа на этот вопрос надо знать какой у Вас компилятор. Как правило в препроцессоре есть директивы по размещению констант по определенному адресу. Но вот не помешает ли это линкеру размещать остальные переменные и саму программу?

Где можно почитать про эти bin? Как их лить в контроллер и чем бы скомпилировать? Памяти хватит. Также рассматривается вариант Т861, на всякий пожарный. Компилятор WinAVR-2010.

Вот нашел в avr_libc. Это оно? Кто-то пользовал?

Здеся!!!
Бинарный файл в общем случае - это последовательность произвольных (а не только текстовых) символов.
В нашем случае - это образ (дамп) flash-памяти МК, который содержит исполняемый код (машинные инструкции) и данные
Конвертируется из hex-файла специальными утилитами. одну я уже упоминал - hex2bin.exe. В инете их можно найти кучу. Я в Дельфях сделал свою примерно за полтора часа.
Любой программатор программирует МК БИНАРНЫМИ данными, а не в HEX'овом виде, перевод осуществляется перед прошивкой.
Проще говоря HEX-формат - это текстовая запись любых бинарных данных в текстовом виде

Например -
:103510009AE010929E0A019690939B0A80939A0AD1
: - обязательный признак
10 - длина данных =16 (в 16-тиричном виде)
3510 - смещение
00 - команда что строка с данными(еще есть 01,02,03,04)
9AE010929E0A019690939B0A80939A0A - 16 байт полезной нагрузки
D1 - контрольная сумма

Насчет привязки объекта в WinAVR

// привязка секции (имени) к определенному адресу
// выполняется в Настройках Проекта => Custom Options => Linker Options

-Wl,--section-start=.TableCoef=0x0800
// адрес в БАйтах


// привязка объекта к фиксированной по адресу секции (имени)

ubyte tcoef2[2] __attribute__((section(".TableCoef"))) =
{
// #include "coef2.h"
};

// взятие адреса
register ubyte *address ;// asm("r14");
address = (ubyte*)tcoef2;
bplis = pgm_read_byte( address++);

// содержание coef2.h :

0x05,0x09,0xEB,0xA5,0xDD,0xCA // comment
,0x05,0x08,0x22,0xE2,0x2A,0xAB
,0x09,0x00,0x08,0x00,0x80,0x00, 0x81,0x08,0x88,0x00

У меня использовался массив, но можно сделать и набор любых объектов

Все программы уже написаны до нас: http://smarttechnosoft.com/ihex/

У Вас есть лишние 20 бакинских?? Тогда лучше высылайте их мне!!!

Во-первых можно заставить купить вашего работодателя, пусть не жмотится.
Во-вторых, 30 строк можно редактировать бесплатно, мне этого хватает, я редактирую данные в EEPROM.
В-третьих, если не хватает, то можно уменьшить число строк, увеличив длину каждой строки, а на длину там ограничения нет (кажется).

Я объявил в WinAVR массив и посмотрел как расположились мои данные. Тот факт, что они идут друг за другом несколько развязывает руки. Тепрь моя задача написать программу для редактирования этого hex-а. Собственно вопрос как правильно (алгоритм) разобрать этот файл.
Предположим я прочитал в массив файл (длянна известна и постоянна). В каком месте мне искать мои данные и куда писать подсчитанную контрольную сумму? Если я открою hex notepad-ом, то то что видится так и есть? Скрытого ничего нет? Для примера привожу сам hex и редактор (спасибо кому-то из форумчан). Мои данные лежат от адреса 0x000027 до 0x000044 включительно. Спасибо.

Нахрена покупать, если мне работы на полтора часа, да и заодно Delphi/Pascal вспомню



С EEPROM согласен, но Flash-память немного больше. Например рядовая программа занимает ~1200 строк в выходном hex-файле



Длина ограничена форматом HEX-файла - для длины строки дается две позиции - это 255 значений!!!

2 skyled
Повторяю ХЕКС-файл - это простой текстовый файл, написаный по определенным правилам(см пост №9)

Привожу алгоритм работы программы (не пользователя!!)

Первый вариант:
1. Открываешь hex-файл
2. Преобразоваваешь его в бинарный вид
3. редактируешь необходимую информацию
4. при необходимости - конвертируешь обратно в хекс
5. сохраняешь результаты

Второй вариант
1. Открываешь hex-файл
2. вычисляешь местоположение необходимых данных - оно не совсем линейное
3. изменяешь данные и коректно их записываешь
4. ЗАНОВО вычисляешь и записываешь контрольную сумму
5. сохраняешь результаты

Я работал почти по первому варианту.
Конвертирование в бин ставил в конце работы компилятора в настройках среды
Мне известные программаторы принимали в качестве загрузочного файлы и ХЕКС и БИН

Предположим я преобразую hex в бинарный вид. Как мне там найти те байты, где мой массив лежит? Преобразование часом не заключается в том, чтобы выкинуть из hex лишнее?

Здесь речь идет не о всей программе, а о 600 байтах. В отдельном HEX-файле! Кто мешает зашивать отдельно программу и отдельно этот массив?

Да, это я забыл. Но 600 байт все равно можно поместить.

Зачем искать?
Изначально в исходнике разместите его по фиксированному адресу.

Ну вот в качестве примера я приводил свой файлик. Если там нужное число находится по адресу 0х000027 и я его вижу редактором, то где оно будет после конвертации в bin?

По какому адресу было по томуже и останется!
Чем .bin смотрите?

есть прекрасная тулза уже в составе WinAVR - srec_cat называется.
Она прекрасно всё во всё конвертит и т.д.
Вот её ман: http://pwet.fr/man/linux/commandes/srec_cat

bin в принципе есть чем посмотреть, UniProg-ом, например. Т.е. как я Вас понял, если в редакторе hex нужный байт был под номером 0х000027 (т.е. 39 по счету если в десятичной) таким он и будет по счету в bin, если я побайтно прочитаю этот bin в массив? Т.е. Если 0х000027==0хCC, то бит №39 (my_mass[0x27] тоже будет 0xCC?

Да.
Только в Вашем файле prg_con.hex по адресу 0027H находится байт 0x00, а байт 0хСС по адресу 0026H.

А Вы случаем не забыли что AVR к флэшу пословно адресуется?

Насчет Hex-редактора. Если Вы открыли хекс-файл в хекс-редакторе, то он отобразит его бинарное представление в удобоворимом для человека и к тому же линейном формате. То есть на каком месте байт поменяли, на таком он и будет поменян.
Раньше я писал о размещении массива во Flash - там необходимо задавать БАЙТОВУЮ адресацию. И редактор отображает побайтно (по умолчанию). Так что если в WinAVR задано

, то и в редакторе начало массива будет равно 0x800.

Но я понял, что изменения в бинарнике будет делать отдельная прога, а не человек! Или это не так?


Мешает обычно опыт. Если у человека опыта не хватит, то он может сначала зашить прогу, а потом таким же образом зашить массив, что перетрет прогу. Правильнее надо будет в программаторе открыть прогу, а потом по определенному адресу подгрузить массив, а уже потом шить. Все зависит от человека и его понимания поставленной задачи!!



Да!!! Я и не знал!! Спасибо за подсказку! Надо будет посмотреть
Посмотрел. Тулза прикольная, но для начинающего слишком сложная. Вы бы привели законченный пример для конвертации.


не ругайте пианиста - он играет как может!!!

Как массив ее перетрет, если он по другому адресу?

Именно так. На уровне пользователя будет удобный (а главное понятный) ему интерфейс. Пользователь выставляет что ему нужно и говорит "прошить железяку". Железяка шьется программатором из-под avrdude. Программа просто запкскает avrdude вегда неизменной командной строкой. Программатор шьет контроллер и все работает. Ограничения на установки накладываются на этапе изменения установок пользователем так чтобы всегда знвчения были валидными. Ну вот такая вот задумка...

А Вы попробуйте в любом программаторе сначала сделать Open_File/Load_File для одного файла, а потом Open_File/Load_File для другого м посмотрите результаты. Для второго файла обычно используется что-то типа Open_File_At//Load_File_At, где указывается адрес смещения

Не знаю как насчет любого, но в AVRStudio есть флажок Erase device before flash programming. Если его снять, то можно шить отдельные части флэш.

А Вы пытались без стирания перешить флеш и все работало?? Насколько я помню если в памяти было что-то и оно перешивается без стирания, то в результате будет что-то похожее на логическую сумму того что было и нового содержимого.
Ваше утверждение будет работать тогда, когда в ячейках памяти были 0xFF. А если там УЖЕ была какая-то информация, то результат будет не тот что надо, иначе бы операция стирания не требовалась.
Во-вторых, я не помню чтобы AVRStudio за раз прошивал сразу два файла.

Что мешает сперва стереть всё, а потом зашить прогу и массив без промежуточного стирания?

Ну дак так ибудет. Прога с массивом в ее составе льется как один файл при программировании.