IC-PROG и EEPROM DATA

Hi All !

Вот столкнулся с неудобством: при компиляции программы, содержащей данные для области EEPROM DATA (процессоры типа PIC18, компилятор picc18), из файла некорректно загружается в программатор содержимое этой области: грузится каждый второй байт, то есть по адресам 0,1,2,3 получаем то, что в файле было по адресам 0,2,4,6. Приходится загружать сначала сам файл в hex-виде (при этом область EEPROM DATA грузится некорректно), после чего подгружать отдельно эту область из этого же исходного файла, но имеющего вид бинарного (*.bin) командой "Open Data File".

Из бинарного файла корректно грузится область EEPROM, но зато некорректно грузится кодовая область.

Это кто-то смог побороть? Чтобы из одного файла PIC18x корректно грузились оба сегмента?

WBRgrds Ruslan

Reply to
Ruslan Mohniuc
Loading thread data ...

Hello Ruslan!

17 May 04 10:29, you wrote to All:

RM> Вот столкнулся с неудобством: при компиляции программы, содержащей RM> данные для области EEPROM DATA (процессоры типа PIC18, компилятор RM> picc18), из файла некорректно загружается в программатор содержимое RM> этой области: грузится каждый второй байт, то есть по адресам 0,1,2,3 RM> получаем то, что в файле было по адресам 0,2,4,6. Приходится загружать

DB 1 DB 2 DB 3 DB 4 заменить на DB 1,2,3,4

Ассемблер дополняет память нулем до четного адреса по окончании каждого DB. Отсюда и проблемы.

Anatoly

Reply to
Anatoly Mashanov

Hi Anatoly !

Совсем недавно 17 May 04 20:15, Anatoly Mashanov писал к Ruslan Mohniuc:

RM>> Вот столкнулся с неудобством: при компиляции программы, RM>> содержащей данные для области EEPROM DATA (процессоры типа PIC18, RM>> компилятор picc18), из файла некорректно загружается в RM>> программатор содержимое этой области: грузится каждый второй RM>> байт, то есть по адресам 0,1,2,3 получаем то, что в файле было по RM>> адресам 0,2,4,6. Приходится загружать

AM> DB 1 AM> DB 2 AM> DB 3 AM> DB 4 AM> заменить на DB 1,2,3,4

AM> Ассемблер дополняет память нулем до четного адреса по окончании AM> каждого DB. Отсюда и проблемы.

Я пользуюсь компилятором picc18 от hi-tech. Он сам делает именно так, как ты сказал:

=== Cut === 5007 psect eeprom_data 5008 0000 00 00 00 00 01 00 db 0,0,0,0,1,0,0,0 ;# + 00 00 5009 0008 60 00 00 00 02 01 db 96,0,0,0,2,1,0,0 ;# + 00 00 5010 0010 40 08 45 20 20 20 db 64,8,69,32,32,32,32,32 ;# + 20 20 === Cut ===

Вроде бы никакого выравнивания кода не происходит. У меня нет претензий к компилятору. Hасколько я понял, это касается загрузки сегментов в программатор IC-PROG, причем при использовании процессоров семейства PIC16 такой проблемы не наблюдалось.

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

PS. А вот не далее, как вчера впервые нарвался на то, что Ц++Билдер по умолчанию производит выравнивание не только в коде, но и в данных, в результате по полям структур, вложенных в объединение, получается разброд и шатание. Маньяки оптимизации, блин. Спасибо, что фича выключаемая.

WBRgrds Ruslan

Reply to
Ruslan Mohniuc

RM> У меня нет претензий к компилятору. Hасколько я понял, это касается загрузки RM> сегментов в программатор IC-PROG, причем при использовании процессоров RM> семейства PIC16 такой проблемы не наблюдалось.

Именно так. Я столкнулся с этим при работе с 18F8720. Писал на асме. Кроме того, объем EEPROM для этого проца в IC PROG неверно отражается - он показывает первые 256 слов из 1024 байт!

Попробовал писаль об этом разработчику софта - понял, что мы говорим на разных языках - мне заявили, что с пиками не общаются :-)

Reply to
Rifkat Abdulin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.