CodeVision массив по конкретному адресу, Как расположить проинициализированный массив в памяти по нужному адрес Опции

[InvisibleFed]

Здравствуйте. Есть массив (табличный метод расчета кцк). Не могу в CodeVision разместить его по нужному адресу. Например:

Код

char array[5] = {0x12, 0x34, 0x45, 0x56, 0x67};

Хочу чтобы лежал он с адреса 0x100:

Код

char array[5] = {0x12, 0x34, 0x45, 0x56, 0x67} @0x100; // не помогает

Куда только эти @0x100 я не ставил. Хотя вот так пишут в хелпе:

Код

char a@0x100;

... и все пашет. А с инициализацией нивкакую...

[haker_fox]

Здравствуйте. Есть массив (табличный метод расчета кцк). Не могу в CodeVision разместить его по нужному адресу. Например:

Код

char array[5] = {0x12, 0x34, 0x45, 0x56, 0x67};

Хочу чтобы лежал он с адреса 0x100:

Код

char array[5] = {0x12, 0x34, 0x45, 0x56, 0x67} @0x100; // не помогает

Куда только эти @0x100 я не ставил. Хотя вот так пишут в хелпе:

Код

char a@0x100;

... и все пашет. А с инициализацией нивкакую...

А зачем его располагать по конкретному адресу?
Не проще ли просто инициализировать массив во флеш памяти и взять его адрес для работы с ним?
P.S.
А что такое кцк?

[InvisibleFed]

А зачем его располагать по конкретному адресу?
Не проще ли просто инициализировать массив во флеш памяти и взять его адрес для работы с ним?
P.S.
А что такое кцк?

1. КЦК - это я так обозвал CRC в переводе на наш (контрольный циклический код или КИК - контрольный избыточный код).
2. Если размещать во флеш - долго выдергивать байт из памяти (команда LPM выполняется аж 3 такта).
3. Если разместить массив данных длиной не более 256 по адресу с младшим байтом 0x00, то при обращении к этому массиву придется работать (при вычислении адреса) только с одним младшим байтом адреса.

Как Вы поняли из пунктов 2 и 3 - счет в моем случае идет на такты - нужно как можно быстрее.

[vet]

InvisibleFed,
предваряйте определение переменной директивой #asm(".org 0x100").
все последующие переменные разместятся выше.

UPD:
да, ничто не мешает объявить переменную без инициализации, т.е. char a[5]@0x100, а при старте программы скопировать в неё массив из flash.

[VDG]

Не могу в CodeVision разместить его по нужному адресу.

и не сможете. Компилятор этому не обучен.

предваряйте определение переменной директивой #asm(".org 0x100").
все последующие переменные разместятся выше.

Вот никогда не понимал зачем писать бред, даже не проверив. Это как в анекдоте про дохнущих кур и раввина - "...жаль что все сдохли, у меня ещё куча советов была".
и к чему приведет такое грубое вмешательство в дела компилятора? - крахом и более ничем. посмотрите карту памяти!

Сообщение отредактировал VDG - Jun 30 2008, 11:47

[sgs]

Здравствуйте. Есть массив (табличный метод расчета кцк). Не могу в CodeVision разместить его по нужному адресу. Например:

Код

char array[5] = {0x12, 0x34, 0x45, 0x56, 0x67};

Хочу чтобы лежал он с адреса 0x100:

Код

char array[5] = {0x12, 0x34, 0x45, 0x56, 0x67} @0x100; // не помогает

Куда только эти @0x100 я не ставил. Хотя вот так пишут в хелпе:

Код

char a@0x100;

... и все пашет. А с инициализацией нивкакую...

В CodeVision можно или разместить массив по заданному адресу: char arr[5] @0x0100 , но инициализировать его потом отдельной командой, или объявить инициализированный массив, но при этом нельзя указать расположение. Одновременно эти действия видимо невозможны.

[defunct]

Как Вы поняли из пунктов 2 и 3 - счет в моем случае идет на такты - нужно как можно быстрее.

пишите на asm.
Правда непонятно зачем уж такая погоня за тактами. Будет быстро и без фокусов с абсолютными адресами и пустой тратой RAM непонятно на что. Как по мне лучше эти 256 байт под стек отдать, эффективнее будет.

char a@0x100;
... и все пашет.

С другой стороны, если припекло, то что мешает заполнить массив в RAM значениями из флеш в начале программы? Только не факт, что компилятор умеет оптимизировать код так как вам нужно.

[fmdost]

Непонятно, зачем конкретный адрес? Что асм, что компиятор, всё-равно придётся брать по указателю. Или Вы пытаетесь спасти полпжение командой LDS ???

[defunct]

Что асм, что компиятор, всё-равно придётся брать по указателю.

3. Если разместить массив данных длиной не более 256 по адресу с младшим байтом 0x00, то при обращении к этому массиву придется работать (при вычислении адреса) только с одним младшим байтом адреса.

где-то в самом начале однократно инициализировать старшую часть указателя
ldi xh, 1

потом доступ к любому элементу двумя командами

mov xl, <индекс> / ldi xl, <индекс>, i.e. адрес элемента одной командой загрузить
ld RR, x

только вот догадается ли компилятор, что можно так делать?

[vet]

и к чему приведет такое грубое вмешательство в дела компилятора? - крахом и более ничем. посмотрите карту памяти!

Да, вы правы, для переменных в ОЗУ так лучше не делать - карта памяти становится недостоверной, что не добавляет ясности в проект. Насчет краха не соглашусь - код будет работать, но лишние заботы со слежением за порядком размещения переменных не нужны, разумнее сразу применить второй мой вариант.
Сам применяю такой трюк для размещения кода и данных по нужным адресам памяти программ, если такая необходимость возникает. По-другому средствами CV этого не сделать.

[InvisibleFed]

Здравствуйте. Всем спасибо за ответы. Отвечу и внесу некоторые комментарии.
1. Код подсчета CRC действительно пишу на асме, используя вставки. Весь остальной проект (4000 строк примерно) - на С. При реализации пользуюсь статьей своего хорошего товарища (Сравнительные характеристики алгоритмов расчёта CRC16 последовательным и табличным способом на примере микроконтроллера AVR). У него на шаг цикла (один байт исходных данных) уходило 18 тактов (на асме, с выровненными массивами таблиц). Столько и хочу получить.
2. Директива .ORG, будучи перед объявлением массива в виде все той же вставки на асме не меняет map-файл. Т. е., если посмотреть листинг (lst, asm), то массив действительно распологается по адресу, указанному в .ORG, но вот сборка проги все равно будет производится на основании данных из map-файла.
3. Некоторые противоречат сами себе - говорят об лишних затратах на память и тут же предлагают дублировать значения из флэш с последующим переписыванием в RAM при старте программы. Это коряво!

Я кажется уже смирился с тем, что в CV действительно невозможно то о чем я говорю. Странный он вообще-то какой-то. Например, я всегда думал, что при сборке программы, он вначале, в одной единой области памяти распологает все объявленные, но неинициализированные переменные, а потом в другой области (следующей) - объявленные и инициализированные (глобальные, естественно). И вот уже наблюдаю совсем иное...

[Александр Куличо...]

3. Некоторые противоречат сами себе - говорят об лишних затратах на память и тут же предлагают дублировать значения из флэш с последующим переписыванием в RAM при старте программы. Это коряво!

Повнимательней посты читать надо. Вам предложили 2 варианта решения проблемы, которые отличаются тем, что в 1м варианте Вы выигрываете 256 байт ОЗУ + универсальность() кода. Во втором - выигрыш в 1 такт (применив ldd вместо lpm) ценой повышенного расхода памяти.
И прежде чем обвинять в корявости, подумайте, каким образом попадают данные в инициализированные переменные в RAM. Просто Вам предлагают сделать некоторые действия вместо компилятора, раз он такому не обучен.

При реализации пользуюсь статьей своего хорошего товарища (Сравнительные характеристики алгоритмов расчёта CRC16 последовательным и табличным способом на примере микроконтроллера AVR). У него на шаг цикла (один байт исходных данных) уходило 18 тактов (на асме, с выровненными массивами таблиц). Столько и хочу получить.

У Вашего друга - CRC16. У Вас, судя по размеру массива - CRC8. Так что 18 тактов можно получить, не экономомя на LPM'е

[InvisibleFed]

Повнимательней посты читать надо. Вам предложили 2 варианта решения проблемы, которые отличаются тем, что в 1м варианте Вы выигрываете 256 байт ОЗУ + универсальность() кода. Во втором - выигрыш в 1 такт (применив ldd вместо lpm) ценой повышенного расхода памяти.
И прежде чем обвинять в корявости, подумайте, каким образом попадают данные в инициализированные переменные в RAM. Просто Вам предлагают сделать некоторые действия вместо компилятора, раз он такому не обучен.

Не надо считать себя много умнее других. Во-первых, про тормознутость lpm писал я сам - потому и просил помочь с размещением массива не в памяти программ, а в памяти данных. Во-вторых, и тут я действительно не просвещен, Вы утверждаете, что размещение инициализированногог массива во flash в коде программы с последующим его переписыванием в RAM - есть одно и то же, что просто размещение инициализированного массива (в коде) в памяти данных (т. е. без ключевого слова flash)?
В-третьих, CRC16 от CRC8 я могу отличить - у меня CRC16 (таблиц две по 256 байт - для младшего и старшего байта)!

[Сергей Борщ]

Вы утверждаете, что размещение инициализированногог массива во flash в коде программы с последующим его переписыванием в RAM - есть одно и то же, что просто размещение инициализированного массива (в коде) в памяти данных (т. е. без ключевого слова flash)?

А вы думаете, что данные появляются в RAM каким-то иным (магическим) способом? Кстати о CV: версии 1.хх не поддерживали раздельную компиляцию (прочитав инструкцию к 2.хх не понял, изменилось ли что-то в этом плане), поэтому понятие линковки в нем отсутствует. Подумайте, как бы вы решили вашу задачу на голом асме и дальше исходите из того, что CV генерит из ваших исходников один большой асм-файл который и подсовывает ассемблеру.

[Александр Куличо...]

Во-первых, про тормознутость lpm писал я сам

Я умнее себя не считаю а, просто обратил внимание форумчан, на чем вы делаете выигрыш в 1 такт.
А по поводу инициализации данных в ОЗУ - так компилятор при старте контроллера как раз все инициализируемые данные переписывает из флеш-памяти (где они хранятся при отключенном питании) в ОЗУ. Так что данные все равно дублируются.

у меня CRC16

У меня код для CRC16 занимает 16/17 тактов на 1 байт при размещении таблицы во флеш. Правда, на асме. Если интересно, могу выложить.