Как создать подключаемый файл из блока данных?

[Drex]

Я имел в виду, что эти 300 строк кода должен выполнить микроконтроллер. А если уже готовый дамп памяти вставить, этой "пустой" работы можно не делать.

Микроконтроллер выполнит эти 300 строк в любом случае, хоть ты в исходник вставишь 300 строк, хоть в hex файл - результат 100% одинаковый. В памяти программ хранятся только команды процессора, а не дампы строк. Просто есть такие команды, которые можно использовать как раз в этих целях.
Ну вот ты сам себе пустую работу и придумал, так как я предложил нужно всего лишь скомпилить, загрузить hex в программатор и прошить. А так как ты хочешь, нужно после компиляции еще и линковать и прочие заморочки - зачем оно надо, никак не пойму?

[zelanez]

Drex, эти 300 строк кода в МК делают только одно дело - создают в памяти программ блок данных. Поскольку память программ МК FLASH, то эти данные там хранятся независимо от наличия питания. Основная программа пользуется отдельными кусочками из этого блока. А вот упомянутые 300 строк больше не нужны. Совсем. Вообще. Никогда. Отсюда и возник вопрос по сабжу. Не зашивать эти 300 строк, а сразу зашить данные в программную память и всё. Чистая экономия 300(!) 14-битных слов в памяти программ.

2 deCoder, когда я начинал эту тему, написанный тобой макет действий у меня был в голове. Но сколько вопросов возникает - как это сделать в MPLAB, как сделать файл из куска прграммной памяти, как залинковать так, чтобы данные из этого файла прописались в программную память по нужному адресу?

Ведь могло оказаться так, что в этой конфе попадется человек, всё это уже проделавший и имеющий желание поделиться своим опытом....
Пока что разбираюсь с форматом НЕХ-файла, чтобы корректно вписать в него свои коды. Навскидку ничего сложного нет, разобраться можно. Осталось один вопрос решить - а нет ли специального байта для обозначения данных? Для кодов - 00h... Начну с метода тыка...

[zelanez]

Так.... То ли тема сложная, то ли не интересная...
Насчёт последнего - точно интересная. Тогда продолжим. Хочтся решить с общей помощью эту проблему красиво, чтоб и другие люди любовались и пользовались...
Короче, сделал я НЕХ файл, как посоветовал deCoder, набив пустых строк NOP для достижения адреса 1000h. Удобно оказалось - контрольные сумы легко считать.
Потом вставил не весь блок, а пару стрингов, для теста. Теперь появилась проблема - MPLAB не работает с НЕХ - файлом, а поэтому проверить тест в нём нельзя. Тогда я в Poteus. Сделал всё, как полагается - загнал асм-файл, сделал Build All, в полученный НЕХ загнал нужный дамп. Запускаю проект - а Протеус глючит - не читает дамп, хотя в программной памяти данные присутствуют, гляньте на картинку...
В программной памяти начиная с адреса 1000h пошли данные. Сначала пробелы (20Н), а потом буквы. На скрине EEADRH+EEADR = 1006h. На индикаторе черные прямоугольники - потому что считываются байты FF вместо данных (EEDATA=FF). На скринах Watch-окна видно, что адрес проходит верно, а чтения нет...
Как можно проверить, не зашивая всё это в МК? Подайте идею...

-- Прилагается рисунок: --

[deCoder]

я так понял ты сам не знаешь чего хочешь ) Вернее не понимаешь. Выигрыша никакого ведь нет.
А кодеры перешедшие из пионеров в комсомол обычно поступают так:

организовывается массив.
string_array:
;0
db 0,1,2,ffh ;0 строка
;1
db 55, 'my2string',ffh; 1 строка
;2
....

каждая строка заканчивается спецсимволом (например FF)
string_array - это ведь не только метка но и адрес в памяти.
Далее если тебе нужно считать например 40 строку то загружаешь адрес данного массива string_array,
в функции чтения строки находишь 39 символов FF и далее считываешь 40 ую строку до символа FF.
Подумай на досуге нахрена тебе абсолютные адреса строк.

[zelanez]

Я только октябрёнок, но со временем собираюсь вступить в партию (кодеров)
Понял твоё предложение - не нужно создавать дамп данных в памяти программ. Нужно сразу обращаться к той строке матрицы кодов, где находятся нужный стринг. Понятно, попробую.
Но экономия в варианте с дампом памяти всё же есть, поскольку компилятор из предложенной тобой строки с директивой db ‹string›, создает соответствующее количество строк retlw ‹знак›, т.е обратно получаем в зашитой в МК программе 300 строк...Хотя они уже будут работать постоянно.
У меня программа насыщена текстовыми сообщениями, выводимыми на двухстрочный LCD. Из 1000 строк кода около 70 % стринги. И ещё столько же добавится.
Потому и напрягает...
А ещё одно соображение - способ с директивами db, dw - слишком прямолинеен. Свеженького хочется...

Кстати, в дополнение к предыдущему сообщению, представляю скрин, как Proteus работает с дампом данных в программной памяти и читает из него стринги.
Хотя в окне программной памяти в области адресов чтения ничего нет....А вот в MPLAB тот же код создает видимый в таком же окне блок данных.

-- Прилагается рисунок: --

[zelanez]

deCoder, проверил твоё предложение.Оказалось, что оно не совсем верное. Директива db - путь в один конец, не возвращает байт, а просто записывает его в программную память. А как взять его оттуда - проблема кодера. Т.е. опять нужно привязываться к абсолютным адресам программной памяти для чтения байта. С чего начали, к тому и пришли.
Попутно выяснилось, что многие ассемблерные директивы могут писать в память, а читать из неё ни одна не может. Кроме одной, dt - которая возможно возвращает байт в аккумуляторе.
Но польза в твоём предложении есть - количество строк кода для ввода стрингов сократилось с 300 до 15.
Proteus не видит данные в программной памяти, как и раньше, но читает их и выводит на LCD. И ещё, для вывода на LCD нужно читать стринг побайтно, поэтому запись и чтение целого стринга не подходит.
Короче, пока запись сделал директивой dw по адресу 1000Н. И тут ещё один момент - при каждом включении будет происходить перезапись данных в программной памяти. Хватит ли её ресурса на весь срок эксплуатации?

-- Прилагается рисунок: --

[deCoder]

чевой то я совсем запутался. Я думал что нужно хранить статичные строки... хотя без разницы. Если для авр:
mov Z, 0x1000
lpm
(загружаем в r0 значение из памяти с адресом 0x1000) То должно работать и

mov Z, string_array
lpm
Или че то типо того. абсолютные адреса не нужны.

[zelanez]

И меня, тоже хочешь запутать?
В твоём примере
"...mov Z, string_array..."
да,тоже сработает, если заранее определить, что
string_array EQU 0х1000

[deCoder]

а зачем че то заранее определять? И без этого должно работать.

[Drex]

zelanez

Слушай, че-то я не пойму. В даташите на пик ясно сказано, что пользовательская программа не имеет доступа к памяти программ. Как же ты в программе создаешь блок данных в ней? Или ты всетаки имеешь в виду EEPROM область ?