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


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


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


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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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


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