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 байт при размещении таблицы во флеш. Правда, на асме. Если интересно, могу выложить.

[InvisibleFed]

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

Буду признателен. На 1/2 такта у Вас быстрее моей реализации получается.

[defunct]

Табличный способ расчета CRC внезависимости от размещения таблиц и способа доступа даст огромный выигрыш и так, по сравнению с классическим битовым расчетом.

i.e. если при размещении в RAM на расчет одного байта уходит 18 тактов, то при размещении во флеш будет 19. (замедление (1/18*100%) - на несчастных 5%). Зато сколько полезной и быстрой RAM теряется на это. Стоит ли 5% таких жертв? К тому же этот 1 такт из 19-ти можно легко скомпенсировать подняв частоту МК на 1Mhz, и не надо будет морочить голову с кривыми решениями при той же производительности.

Плюс если выкинуть из головы идею расчета CRC непосредственно в обработчике прерывания, то не понадобится экономить такты.

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

Перед вызовом Y <= указатель на данные
XL (или XH:XL) <= кол-во байт (но не менее одного)

Код

lblCRC16_Table:
// размещаем на границе 256 байт
.ORG ((lblCRC16_Table>>2)+1)<<2
CRC16_Table: // array[0..255] OF WORD =
.dw $0000,$C0C1,$C181,$0140,$C301,$03C0,$0280,$C241,$C601,$06C0
.dw $0780,$C741,$0500,$C5C1,$C481,$0440,$CC01,$0CC0,$0D80,$CD41
.dw $0F00,$CFC1,$CE81,$0E40,$0A00,$CAC1,$CB81,$0B40,$C901,$09C0
.dw $0880,$C841,$D801,$18C0,$1980,$D941,$1B00,$DBC1,$DA81,$1A40
.dw $1E00,$DEC1,$DF81,$1F40,$DD01,$1DC0,$1C80,$DC41,$1400,$D4C1
.dw $D581,$1540,$D701,$17C0,$1680,$D641,$D201,$12C0,$1380,$D341
.dw $1100,$D1C1,$D081,$1040,$F001,$30C0,$3180,$F141,$3300,$F3C1
.dw $F281,$3240,$3600,$F6C1,$F781,$3740,$F501,$35C0,$3480,$F441
.dw $3C00,$FCC1,$FD81,$3D40,$FF01,$3FC0,$3E80,$FE41,$FA01,$3AC0
.dw $3B80,$FB41,$3900,$F9C1,$F881,$3840,$2800,$E8C1,$E981,$2940
.dw $EB01,$2BC0,$2A80,$EA41,$EE01,$2EC0,$2F80,$EF41,$2D00,$EDC1
.dw $EC81,$2C40,$E401,$24C0,$2580,$E541,$2700,$E7C1,$E681,$2640
.dw $2200,$E2C1,$E381,$2340,$E101,$21C0,$2080,$E041,$A001,$60C0
.dw $6180,$A141,$6300,$A3C1,$A281,$6240,$6600,$A6C1,$A781,$6740
.dw $A501,$65C0,$6480,$A441,$6C00,$ACC1,$AD81,$6D40,$AF01,$6FC0
.dw $6E80,$AE41,$AA01,$6AC0,$6B80,$AB41,$6900,$A9C1,$A881,$6840
.dw $7800,$B8C1,$B981,$7940,$BB01,$7BC0,$7A80,$BA41,$BE01,$7EC0
.dw $7F80,$BF41,$7D00,$BDC1,$BC81,$7C40,$B401,$74C0,$7580,$B541
.dw $7700,$B7C1,$B681,$7640,$7200,$B2C1,$B381,$7340,$B101,$71C0
.dw $7080,$B041,$5000,$90C1,$9181,$5140,$9301,$53C0,$5280,$9241
.dw $9601,$56C0,$5780,$9741,$5500,$95C1,$9481,$5440,$9C01,$5CC0
.dw $5D80,$9D41,$5F00,$9FC1,$9E81,$5E40,$5A00,$9AC1,$9B81,$5B40
.dw $9901,$59C0,$5880,$9841,$8801,$48C0,$4980,$8941,$4B00,$8BC1
.dw $8A81,$4A40,$4E00,$8EC1,$8F81,$4F40,$8D01,$4DC0,$4C80,$8C41
.dw $4400,$84C1,$8581,$4540,$8701,$47C0,$4680,$8641,$8201,$42C0
.dw $4380,$8341,$4100,$81C1,$8081,$4040



; CRCH:CRCL:=CRCH(8bit) xor CRC16_Table[Data xor CRCL](16bit)
; или
; CRCL:=CRCH(old) xor LOW( CRC16_Table[Data xor CRCL] )
; CRCH:=             HIGH( Table[Data xor CRCL] )


CalcCRC16:
   crc16_loop:
    ld    ZL,Y+
    eor    ZL,CRCL
    ldi    ZH,high(CRC16_Table)
    lsl    ZL
    rol    ZH
    lpm    CRCL,Z+        // LOW( Table[Data xor CRCL] )
    eor    CRCL,CRCH        // = new CRCL
    lpm    CRCH,Z        // = new CRCH = HIGH( Table[Data xor CRCL] )

    dec    XL  (или sbiw XH:XL,1)
    brne    crc16_loop

[defunct]

XL (или XH:XL) <= кол-во байт (но не менее одного)

Вы шутите наверное?!
X использовать под счетчик байт?

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

Вы шутите наверное?!
X использовать под счетчик байт?

Не вижу ничего в этом плохого. IMHO, все зависит от стиля написания программ. Я, например, в своих ассемблерных программах указатель X практически не использую (все держу его "про запас" ). Да и при подсчете CRC в _моей_ программе он также не используется, так как вычислние контрольной суммы у меня осуществляется по мере приема данных.
А данный пример был адаптирован для InvisibleFed.

Да и ничто не мешает заменить
sbiw XH:XL,1
на
sbiw R25:R24,1
или на
subi R[16-25],1
sbci R[0-R25],zero
По тактам выходит то же.

[defunct]

Не вижу ничего в этом плохого.

Плохое - терять ценный указатель (или добавлять снаружи его сохранение).
что пагубно повлияет на скорость.

sbiw R25:R24,1

другое дело.

[VDG]

Сам применяю такой трюк

Вот я проверил на 1.24.8d. Фокус не вышел. У меня CV не смотрит (и не должен) что ему пихают в ассеблерных вставках, тем более вне функций.
====

А не проще было автору в бут область запихнуть все проверки CRC апликейшена (основного кода)?

Сообщение отредактировал VDG - Jul 2 2008, 21:08

[vet]

Вот я проверил на 1.24.8d. Фокус не вышел. У меня CV не смотрит (и не должен) что ему пихают в ассеблерных вставках, тем более вне функций.

почему не смотрит, все вставки аккуратно переносит в *.asm.

Код

;CodeVisionAVR C Compiler V1.24.8d Professional
...
    .CSEG
;      18 #asm(".org 0x1000")
    .org 0x1000
;      19
;      20 void main() {
_main:

Насчет флэшевых переменных это я да, подзабыл матчасть - давно не работал с CV. Имелись в виду данные во встроенной EEPROM:

Код

#asm(".eseg")
#asm(".org 0x01")
eeprom SETTINGS eep={0};

Код

;    1281 #asm(".eseg")
    .eseg
;    1282 #asm(".org 0x01")
    .org 0x01
;    1283 eeprom SETTINGS eep={0};

    .ESEG
_eep:
    .DB  0x0
...

[VDG]

почему не смотрит, все вставки аккуратно переносит в *.asm.

не надо смотреть в сгенерированный ассм. это тоже самое что править его потом вручную.

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

а с байтовыми (или словами) переменными ещё хлеще. компилятор положил их в регистры, и соответственно вставка повлияла на сдвиг последующих объявленных переменных в SRAM. т.е. то самое перекрытие.

Сообщение отредактировал VDG - Jul 3 2008, 09:49

[vet]

не надо смотреть в сгенерированный ассм. это тоже самое что править его потом вручную.

Вовсе нет - ручные изменения *.asm после перекомпиляции придется вносить заново, так что это в целом бессмысленная затея. Исходник же, будучи единожды оптимизирован с учетом получаемого асма, в дальнейшем своих свойств не потеряет. В сущности, контроль генерируемого асма - это вопрос получения оптимального кода, лично я этой процедурой не пренебрегаю никогда.

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

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

а с байтовыми (или словами) переменными ещё хлеще. компилятор положил их в регистры, и соответственно вставка повлияла на сдвиг последующих объявленных переменных в SRAM. т.е. то самое перекрытие.

Не уловил мысль. Как .org после .cseg/.eseg повлияет на размещение переменных в ОЗУ?

Кстати, по поводу регистровых переменных - лично я предпочитаю размещать их исключительно вручную, в виде register int a@xx; регистры - это слишком ценный ресурс, чтобы оставлять их заполнение на усмотрение компилятора.

[VDG]

Не уловил мысль.

Если будет время закину скриншот.

[sgs]

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

Код

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

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

Код

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

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

Код

char a@0x100;

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

Оказывается, CV 2.0.4 (а может быть, и другие версии) умеет делать так:

eeprom char TEST[]={"0123456789"}; // создаем и инициализируем блок
....
eeprom char TEST[] @0x70; // объявляем линкеру, куда поместить блок

или:

eeprom char TEST[11] @0x70; // принципиален размер блока!
...
eeprom char TEST[11]={"0123456789"}; // инициалзация может быть позже

И все прекрасно инициализируется и размещается по адресу EEPROM...

[SasaVitebsk]

А если перейти на IAR (или GCC), то решается две задачи.
1) Можно легко выполнить любую вашу задачу (или просто разместить массив по конкретному адресу, либо сделать асмовую вставку в виде п/п что позволит сразу вызывать п/п из С)
2) Получите выигрыш в производительности самого кода, что,возможно, позволит вам отказаться от такой погони за производительностью.

И ещё. Практически сейчас все приходят к тому, что нет смысла вылизывать прогу. Необходимо выбирать кристалл с запасом производительности минимум 30%. Причина проста - стоимость кристаллов мизерна. Разница в цене между низкопроизводительным и более скоростным - ничтожна. Время потраченное на ухищрения и вылизывание будет стоить значительно дороже.

[InvisibleFed]

SasaVitebsk, спасибо, полностью согласен. Но так уж получилось, что не мне было выбирать средства. Всем спасибо за помощь - копирую в озу при старте. Попутно вырос связанный вопрос, хоть и чуток не в тему. Известно, что в функцию параметры можно передавать не одним способом: через стэк, через регистры. Допустим, есть функция полностью написанная на асме. Как мне передать в нее, зкажем значение переменной var1?. Т. е. как должен выглядить код-вставка на асме под CodeVision C, чтобы значение (или адрес) конкретной переменной записывались в стэк или регистр? Вся особенность в том, что сам компилятор передает параметры тоже черз регистры (косвенно) или через стэк, и о переменной var1, если она не во flash (ну или как минимум просто глобальная, видимо) ничего не знает (а работает напрямую с адресами). Возможно ли такое вообще. А то столкнулся тут. Написал кусок функции на асме, перед этим посмотрел, что в каких регистрах компилятор разместил, ну и работал с ними. Потом коду немного дописал, а он уже перераспределил операторы по другим регистрам. Не хочу каждый раз переписывать... =) Или я чего-то не понимаю/не знаю?

[Qwertty]

Но так уж получилось, что не мне было выбирать средства.

Неужели у Вас CV честно купленный?

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

Возможно что и изменилось, но CV 1.2.xx передавал параметры всегда через стек. В хелпе это описано.

Написал кусок функции на асме, перед этим посмотрел, что в каких регистрах компилятор разместил, ну и работал с ними. Потом коду немного дописал, а он уже перераспределил операторы по другим регистрам. Не хочу каждый раз переписывать... =) Или я чего-то не понимаю/не знаю?

ИМХО только на GCC можно красиво работать в такой ситуации. Инлайн ассемблер там самый разумный , и можно не задумываться о том, где на самом деле находится переменная.

[sgs]

Известно, что в функцию параметры можно передавать не одним способом: через стэк, через регистры. Допустим, есть функция полностью написанная на асме. Как мне передать в нее, зкажем значение переменной var1?

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