IC-PROG и EEPROM DATA

May 17, 2004 3 Replies

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



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

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

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

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

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

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required