IC-PROG и EEPROM DATA

Do you have a question? Post it now! No Registration Necessary

Threaded View
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



IC-PROG и EEPROM 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


IC-PROG и EEPROM DATA
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



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

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

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

--
Rifkat < Team /Grave\ >
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Site Timeline