|
CodeVision массив по конкретному адресу, Как расположить проинициализированный массив в памяти по нужному адрес |
|
|
|
Jun 30 2008, 03:51
|
Местный
  
Группа: Свой
Сообщений: 401
Регистрация: 18-11-06
Из: Хабаровск
Пользователь №: 22 469

|
Здравствуйте. Есть массив (табличный метод расчета кцк). Не могу в CodeVision разместить его по нужному адресу. Например: Код char array[5] = {0x12, 0x34, 0x45, 0x56, 0x67}; Хочу чтобы лежал он с адреса 0x100: Код char array[5] = {0x12, 0x34, 0x45, 0x56, 0x67} @0x100; // не помогает Куда только эти @0x100 я не ставил. Хотя вот так пишут в хелпе: Код char a@0x100; ... и все пашет. А с инициализацией нивкакую...
|
|
|
|
3 страниц
1 2 3 >
|
 |
Ответов
(1 - 30)
|
Jun 30 2008, 04:54
|

Познающий...
     
Группа: Свой
Сообщений: 2 963
Регистрация: 1-09-05
Из: г. Иркутск
Пользователь №: 8 125

|
Цитата(InvisibleFed @ Jun 30 2008, 12:51)  Здравствуйте. Есть массив (табличный метод расчета кцк). Не могу в 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. А что такое кцк?
--------------------
Выбор.
|
|
|
|
|
Jun 30 2008, 06:31
|
Местный
  
Группа: Свой
Сообщений: 401
Регистрация: 18-11-06
Из: Хабаровск
Пользователь №: 22 469

|
Цитата(haker_fox @ Jun 30 2008, 15:54)  А зачем его располагать по конкретному адресу? Не проще ли просто инициализировать массив во флеш памяти и взять его адрес для работы с ним? P.S. А что такое кцк? 1. КЦК - это я так обозвал CRC в переводе на наш (контрольный циклический код или КИК - контрольный избыточный код). 2. Если размещать во флеш - долго выдергивать байт из памяти (команда LPM выполняется аж 3 такта). 3. Если разместить массив данных длиной не более 256 по адресу с младшим байтом 0x00, то при обращении к этому массиву придется работать (при вычислении адреса) только с одним младшим байтом адреса. Как Вы поняли из пунктов 2 и 3 - счет в моем случае идет на такты - нужно как можно быстрее.
|
|
|
|
|
Jun 30 2008, 11:43
|

Знающий
   
Группа: Участник
Сообщений: 845
Регистрация: 10-02-06
Пользователь №: 14 193

|
Цитата(InvisibleFed @ Jun 30 2008, 07:51)  Не могу в CodeVision разместить его по нужному адресу. и не сможете. Компилятор этому не обучен. Цитата(vet @ Jun 30 2008, 14:13)  предваряйте определение переменной директивой #asm(".org 0x100"). все последующие переменные разместятся выше. Вот никогда не понимал зачем писать бред, даже не проверив. Это как в анекдоте про дохнущих кур и раввина - "...жаль что все сдохли, у меня ещё куча советов была". и к чему приведет такое грубое вмешательство в дела компилятора? - крахом и более ничем. посмотрите карту памяти!
Сообщение отредактировал VDG - Jun 30 2008, 11:47
--------------------
|
|
|
|
|
Jun 30 2008, 16:32
|
Участник

Группа: Участник
Сообщений: 54
Регистрация: 25-01-06
Из: Самара
Пользователь №: 13 578

|
Цитата(InvisibleFed @ Jun 30 2008, 08:51)  Здравствуйте. Есть массив (табличный метод расчета кцк). Не могу в 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 , но инициализировать его потом отдельной командой, или объявить инициализированный массив, но при этом нельзя указать расположение. Одновременно эти действия видимо невозможны.
|
|
|
|
|
Jun 30 2008, 22:17
|

кекс
     
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326

|
Цитата(InvisibleFed @ Jun 30 2008, 09:31)  Как Вы поняли из пунктов 2 и 3 - счет в моем случае идет на такты - нужно как можно быстрее. пишите на asm. Правда непонятно зачем уж такая погоня за тактами. Будет быстро и без фокусов с абсолютными адресами и пустой тратой RAM непонятно на что. Как по мне лучше эти 256 байт под стек отдать, эффективнее будет. Цитата char a@0x100; ... и все пашет. С другой стороны, если припекло, то что мешает заполнить массив в RAM значениями из флеш в начале программы? Только не факт, что компилятор умеет оптимизировать код так как вам нужно.
|
|
|
|
|
Jun 30 2008, 23:45
|

кекс
     
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326

|
Цитата(Т.Достоевский @ Jul 1 2008, 02:35)  Что асм, что компиятор, всё-равно придётся брать по указателю. Цитата 3. Если разместить массив данных длиной не более 256 по адресу с младшим байтом 0x00, то при обращении к этому массиву придется работать (при вычислении адреса) только с одним младшим байтом адреса. где-то в самом начале однократно инициализировать старшую часть указателя ldi xh, 1 потом доступ к любому элементу двумя командами mov xl, <индекс> / ldi xl, <индекс>, i.e. адрес элемента одной командой загрузить ld RR, x только вот догадается ли компилятор, что можно так делать?
|
|
|
|
|
Jul 1 2008, 06:02
|
Знающий
   
Группа: Свой
Сообщений: 550
Регистрация: 16-06-04
Из: Казань
Пользователь №: 32

|
Цитата(VDG @ Jun 30 2008, 15:43)  и к чему приведет такое грубое вмешательство в дела компилятора? - крахом и более ничем. посмотрите карту памяти! Да, вы правы, для переменных в ОЗУ так лучше не делать - карта памяти становится недостоверной, что не добавляет ясности в проект. Насчет краха не соглашусь - код будет работать, но лишние заботы со слежением за порядком размещения переменных не нужны, разумнее сразу применить второй мой вариант. Сам применяю такой трюк для размещения кода и данных по нужным адресам памяти программ, если такая необходимость возникает. По-другому средствами CV этого не сделать.
--------------------
Главная линия этого опуса ясна мне насквозь!
|
|
|
|
|
Jul 1 2008, 06:57
|
Местный
  
Группа: Свой
Сообщений: 401
Регистрация: 18-11-06
Из: Хабаровск
Пользователь №: 22 469

|
Здравствуйте. Всем спасибо за ответы. Отвечу и внесу некоторые комментарии. 1. Код подсчета CRC действительно пишу на асме, используя вставки. Весь остальной проект (4000 строк примерно) - на С. При реализации пользуюсь статьей своего хорошего товарища ( Сравнительные характеристики алгоритмов расчёта CRC16 последовательным и табличным способом на примере микроконтроллера AVR). У него на шаг цикла (один байт исходных данных) уходило 18 тактов (на асме, с выровненными массивами таблиц). Столько и хочу получить. 2. Директива .ORG, будучи перед объявлением массива в виде все той же вставки на асме не меняет map-файл. Т. е., если посмотреть листинг (lst, asm), то массив действительно распологается по адресу, указанному в .ORG, но вот сборка проги все равно будет производится на основании данных из map-файла. 3. Некоторые противоречат сами себе - говорят об лишних затратах на память и тут же предлагают дублировать значения из флэш с последующим переписыванием в RAM при старте программы. Это коряво! Я кажется уже смирился с тем, что в CV действительно невозможно то о чем я говорю. Странный он вообще-то какой-то. Например, я всегда думал, что при сборке программы, он вначале, в одной единой области памяти распологает все объявленные, но неинициализированные переменные, а потом в другой области (следующей) - объявленные и инициализированные (глобальные, естественно). И вот уже наблюдаю совсем иное...
|
|
|
|
|
Jul 1 2008, 08:24
|
Местный
  
Группа: Свой
Сообщений: 256
Регистрация: 6-03-06
Из: Украина, г. Винница
Пользователь №: 15 017

|
Цитата 3. Некоторые противоречат сами себе - говорят об лишних затратах на память и тут же предлагают дублировать значения из флэш с последующим переписыванием в RAM при старте программы. Это коряво! Повнимательней посты читать надо. Вам предложили 2 варианта решения проблемы, которые отличаются тем, что в 1м варианте Вы выигрываете 256 байт ОЗУ + универсальность() кода. Во втором - выигрыш в 1 такт (применив ldd вместо lpm) ценой повышенного расхода памяти. И прежде чем обвинять в корявости, подумайте, каким образом попадают данные в инициализированные переменные в RAM. Просто Вам предлагают сделать некоторые действия вместо компилятора, раз он такому не обучен. Цитата При реализации пользуюсь статьей своего хорошего товарища (Сравнительные характеристики алгоритмов расчёта CRC16 последовательным и табличным способом на примере микроконтроллера AVR). У него на шаг цикла (один байт исходных данных) уходило 18 тактов (на асме, с выровненными массивами таблиц). Столько и хочу получить. У Вашего друга - CRC16. У Вас, судя по размеру массива - CRC8. Так что 18 тактов можно получить, не экономомя на LPM'е
|
|
|
|
|
Jul 1 2008, 08:53
|
Местный
  
Группа: Свой
Сообщений: 401
Регистрация: 18-11-06
Из: Хабаровск
Пользователь №: 22 469

|
Цитата Повнимательней посты читать надо. Вам предложили 2 варианта решения проблемы, которые отличаются тем, что в 1м варианте Вы выигрываете 256 байт ОЗУ + универсальность() кода. Во втором - выигрыш в 1 такт (применив ldd вместо lpm) ценой повышенного расхода памяти. И прежде чем обвинять в корявости, подумайте, каким образом попадают данные в инициализированные переменные в RAM. Просто Вам предлагают сделать некоторые действия вместо компилятора, раз он такому не обучен. Не надо считать себя много умнее других. Во-первых, про тормознутость lpm писал я сам - потому и просил помочь с размещением массива не в памяти программ, а в памяти данных. Во-вторых, и тут я действительно не просвещен, Вы утверждаете, что размещение инициализированногог массива во flash в коде программы с последующим его переписыванием в RAM - есть одно и то же, что просто размещение инициализированного массива (в коде) в памяти данных (т. е. без ключевого слова flash)? В-третьих, CRC16 от CRC8 я могу отличить - у меня CRC16 (таблиц две по 256 байт - для младшего и старшего байта)!
|
|
|
|
|
Jul 1 2008, 09:14
|

Гуру
     
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095

|
Цитата(InvisibleFed @ Jul 1 2008, 11:53)  Вы утверждаете, что размещение инициализированногог массива во flash в коде программы с последующим его переписыванием в RAM - есть одно и то же, что просто размещение инициализированного массива (в коде) в памяти данных (т. е. без ключевого слова flash)? А вы думаете, что данные появляются в RAM каким-то иным (магическим) способом? Кстати о CV: версии 1.хх не поддерживали раздельную компиляцию (прочитав инструкцию к 2.хх не понял, изменилось ли что-то в этом плане), поэтому понятие линковки в нем отсутствует. Подумайте, как бы вы решили вашу задачу на голом асме и дальше исходите из того, что CV генерит из ваших исходников один большой асм-файл который и подсовывает ассемблеру.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
Jul 1 2008, 09:34
|
Местный
  
Группа: Свой
Сообщений: 256
Регистрация: 6-03-06
Из: Украина, г. Винница
Пользователь №: 15 017

|
Цитата Во-первых, про тормознутость lpm писал я сам Я умнее себя не считаю а, просто обратил внимание форумчан, на чем вы делаете выигрыш в 1 такт. А по поводу инициализации данных в ОЗУ - так компилятор при старте контроллера как раз все инициализируемые данные переписывает из флеш-памяти (где они хранятся при отключенном питании) в ОЗУ. Так что данные все равно дублируются. Цитата у меня CRC16 У меня код для CRC16 занимает 16/17 тактов на 1 байт при размещении таблицы во флеш. Правда, на асме. Если интересно, могу выложить.
|
|
|
|
|
Jul 1 2008, 10:24
|
Местный
  
Группа: Свой
Сообщений: 401
Регистрация: 18-11-06
Из: Хабаровск
Пользователь №: 22 469

|
Цитата У меня код для CRC16 занимает 16/17 тактов на 1 байт при размещении таблицы во флеш. Правда, на асме. Если интересно, могу выложить. Буду признателен. На 1/2 такта у Вас быстрее моей реализации получается.
|
|
|
|
|
Jul 1 2008, 12:03
|
Местный
  
Группа: Свой
Сообщений: 256
Регистрация: 6-03-06
Из: Украина, г. Винница
Пользователь №: 15 017

|
Перед вызовом 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
|
|
|
|
|
Jul 1 2008, 21:54
|
Местный
  
Группа: Свой
Сообщений: 256
Регистрация: 6-03-06
Из: Украина, г. Винница
Пользователь №: 15 017

|
Цитата Вы шутите наверное?! X использовать под счетчик байт? Не вижу ничего в этом плохого. IMHO, все зависит от стиля написания программ. Я, например, в своих ассемблерных программах указатель X практически не использую (все держу его "про запас"  ). Да и при подсчете CRC в _моей_ программе он также не используется, так как вычислние контрольной суммы у меня осуществляется по мере приема данных. А данный пример был адаптирован для InvisibleFed. Да и ничто не мешает заменить sbiw XH:XL,1 на sbiw R25:R24,1 или на subi R[16-25],1 sbci R[0-R25],zero По тактам выходит то же.
|
|
|
|
|
Jul 2 2008, 15:51
|

кекс
     
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326

|
Цитата(Александр Куличок @ Jul 2 2008, 00:54)  Не вижу ничего в этом плохого. Плохое - терять ценный указатель (или добавлять снаружи его сохранение). что пагубно повлияет на скорость. Цитата sbiw R25:R24,1 другое дело.
|
|
|
|
|
Jul 2 2008, 21:05
|

Знающий
   
Группа: Участник
Сообщений: 845
Регистрация: 10-02-06
Пользователь №: 14 193

|
Цитата(vet @ Jul 1 2008, 10:02)  Сам применяю такой трюк Вот я проверил на 1.24.8d. Фокус не вышел. У меня CV не смотрит (и не должен) что ему пихают в ассеблерных вставках, тем более вне функций. ==== А не проще было автору в бут область запихнуть все проверки CRC апликейшена (основного кода)?
Сообщение отредактировал VDG - Jul 2 2008, 21:08
|
|
|
|
|
Jul 3 2008, 05:43
|
Знающий
   
Группа: Свой
Сообщений: 550
Регистрация: 16-06-04
Из: Казань
Пользователь №: 32

|
Цитата(VDG @ Jul 3 2008, 01:05)  Вот я проверил на 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 ...
--------------------
Главная линия этого опуса ясна мне насквозь!
|
|
|
|
|
Jul 3 2008, 09:48
|

Знающий
   
Группа: Участник
Сообщений: 845
Регистрация: 10-02-06
Пользователь №: 14 193

|
Цитата(vet @ Jul 3 2008, 09:43)  почему не смотрит, все вставки аккуратно переносит в *.asm. не надо смотреть в сгенерированный ассм. это тоже самое что править его потом вручную. да, переносит вставку в код, не спорю. но откройте список переменных в treeview - компилятор ничего не знает об этой вставке. т.е. можно так хакнуть, но на свой страх и риск, потому что рано или поздно будет перекрытие. а с байтовыми (или словами) переменными ещё хлеще. компилятор положил их в регистры, и соответственно вставка повлияла на сдвиг последующих объявленных переменных в SRAM. т.е. то самое перекрытие.
Сообщение отредактировал VDG - Jul 3 2008, 09:49
--------------------
|
|
|
|
|
Jul 3 2008, 12:23
|
Знающий
   
Группа: Свой
Сообщений: 550
Регистрация: 16-06-04
Из: Казань
Пользователь №: 32

|
Цитата(VDG @ Jul 3 2008, 13:48)  не надо смотреть в сгенерированный ассм. это тоже самое что править его потом вручную. Вовсе нет - ручные изменения *.asm после перекомпиляции придется вносить заново, так что это в целом бессмысленная затея. Исходник же, будучи единожды оптимизирован с учетом получаемого асма, в дальнейшем своих свойств не потеряет. В сущности, контроль генерируемого асма - это вопрос получения оптимального кода, лично я этой процедурой не пренебрегаю никогда. Цитата(VDG @ Jul 3 2008, 13:48)  да, переносит вставку в код, не спорю. но откройте список переменных в treeview - компилятор ничего не знает об этой вставке. т.е. можно так хакнуть, но на свой страх и риск, потому что рано или поздно будет перекрытие. Это вопрос правильного применения техники. Если мне нужен код по определенному адресу флэша или данные по определенному адресу еепром - об отсутствии перекрытия я позабочусь сам. Цитата(VDG @ Jul 3 2008, 13:48)  а с байтовыми (или словами) переменными ещё хлеще. компилятор положил их в регистры, и соответственно вставка повлияла на сдвиг последующих объявленных переменных в SRAM. т.е. то самое перекрытие. Не уловил мысль. Как .org после .cseg/.eseg повлияет на размещение переменных в ОЗУ? Кстати, по поводу регистровых переменных - лично я предпочитаю размещать их исключительно вручную, в виде register int a@xx; регистры - это слишком ценный ресурс, чтобы оставлять их заполнение на усмотрение компилятора.
--------------------
Главная линия этого опуса ясна мне насквозь!
|
|
|
|
|
Jul 18 2008, 08:33
|
Участник

Группа: Участник
Сообщений: 54
Регистрация: 25-01-06
Из: Самара
Пользователь №: 13 578

|
Цитата(InvisibleFed @ Jun 30 2008, 08:51)  Здравствуйте. Есть массив (табличный метод расчета кцк). Не могу в 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...
|
|
|
|
|
Jul 22 2008, 06:34
|
Местный
  
Группа: Свой
Сообщений: 401
Регистрация: 18-11-06
Из: Хабаровск
Пользователь №: 22 469

|
SasaVitebsk, спасибо, полностью согласен. Но так уж получилось, что не мне было выбирать средства. Всем спасибо за помощь - копирую в озу при старте. Попутно вырос связанный вопрос, хоть и чуток не в тему. Известно, что в функцию параметры можно передавать не одним способом: через стэк, через регистры. Допустим, есть функция полностью написанная на асме. Как мне передать в нее, зкажем значение переменной var1?. Т. е. как должен выглядить код-вставка на асме под CodeVision C, чтобы значение (или адрес) конкретной переменной записывались в стэк или регистр? Вся особенность в том, что сам компилятор передает параметры тоже черз регистры (косвенно) или через стэк, и о переменной var1, если она не во flash (ну или как минимум просто глобальная, видимо) ничего не знает (а работает напрямую с адресами). Возможно ли такое вообще. А то столкнулся тут. Написал кусок функции на асме, перед этим посмотрел, что в каких регистрах компилятор разместил, ну и работал с ними. Потом коду немного дописал, а он уже перераспределил операторы по другим регистрам. Не хочу каждый раз переписывать... =) Или я чего-то не понимаю/не знаю?
|
|
|
|
|
Jul 22 2008, 07:00
|
Местный
  
Группа: Свой
Сообщений: 408
Регистрация: 21-10-06
Из: Санкт-Петербург
Пользователь №: 21 527

|
Цитата(InvisibleFed @ Jul 22 2008, 10:34)  Но так уж получилось, что не мне было выбирать средства. Неужели у Вас CV честно купленный? Цитата(InvisibleFed @ Jul 22 2008, 10:34)  Вся особенность в том, что сам компилятор передает параметры тоже черз регистры (косвенно) или через стэк, и о переменной var1, если она не во flash (ну или как минимум просто глобальная, видимо) ничего не знает (а работает напрямую с адресами). Возможно что и изменилось, но CV 1.2.xx передавал параметры всегда через стек. В хелпе это описано. Цитата(InvisibleFed @ Jul 22 2008, 10:34)  Написал кусок функции на асме, перед этим посмотрел, что в каких регистрах компилятор разместил, ну и работал с ними. Потом коду немного дописал, а он уже перераспределил операторы по другим регистрам. Не хочу каждый раз переписывать... =) Или я чего-то не понимаю/не знаю? ИМХО только на GCC можно красиво работать в такой ситуации. Инлайн ассемблер там самый разумный  , и можно не задумываться о том, где на самом деле находится переменная.
|
|
|
|
|
Jul 22 2008, 10:30
|
Участник

Группа: Участник
Сообщений: 54
Регистрация: 25-01-06
Из: Самара
Пользователь №: 13 578

|
Цитата(InvisibleFed @ Jul 22 2008, 11:34)  Известно, что в функцию параметры можно передавать не одним способом: через стэк, через регистры. Допустим, есть функция полностью написанная на асме. Как мне передать в нее, зкажем значение переменной var1? В HELP'е CV очень четко прописаны входы-выходы ассемблерной функции. В процедуру параметры передаются через стек, внутри процедуры используется любые из разрешенных регистров (предварительно, конечно, сохраненных в стеке), в конце процедуры проводится восстановление регистров, коррекция стека (удаление входных переменных) и возвращение выходных данных через регистры (в соответствии с типом и размером данных). Другого механизма в CV пока не наблюдалось...
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|