Ты на даты смотреть научись: это за три последних года. MPLAB у меня всегда последний _рабочий_, обновляю регулярно (и откатываюсь взад регулярно тоже). Потому, что в ~половине~ версий то не отлаживает, то не программирует, то не симулирует (про http://www.microchip.com/forums/m755766-print.aspx
тестирование ПО в микрочипе не знают). И описанные проблемы легко увидеть и в последней текущей версии и MPLAB и C30/XC16... Почило в бозе? Где багфикс? (см. ссылку -- это очень ненормально, когда сходу не работает средних размеров проект из-за -Os для версии выложенной на сайте -- они вообще ничё не тестируют) Последняя версия компилятора не работает вообще (LOL!!! они об этом знают и поэтому собирают libc с -O1 судя по дизассемблеру). А C30 3.31 это как раз устаревший продукт самособранный из исходников ихнего gcc. И легко, кстати, почитать README от последующих версий XC16 и убедиться, что в 3.31 тоже глюкодром. И всем пофиг. Это вот так коммерческий софт делается. В мире opensource можно хотя бы написать bugtracker и рассылку и хоть добиться того, что разработчики прочитают, мол баг есть. А также можно ожидать нормальной методики разработки: есть разрабатываемая версия, со всеми багами, и есть стабильная. И коль исправили ошибки по пути от C30 3.31 до XC16 1.20, то можно эти же исправления было внести в "стабильный" C30 3.31.
[ZX]
тестирование ПО в микрочипе не знают). И описанные проблемы легко увидеть и в последней текущей версии и MPLAB и C30/XC16... Почило в бозе? Где багфикс? (см. ссылку -- это очень ненормально, когда сходу не работает средних размеров проект из-за -Os для версии выложенной на сайте -- они вообще ничё не тестируют) Последняя версия компилятора не работает вообще (LOL!!! они об этом знают и поэтому собирают libc с -O1 судя по дизассемблеру). А C30 3.31 это как раз устаревший продукт самособранный из исходников ихнего gcc. И легко, кстати, почитать README от последующих версий XC16 и убедиться, что в 3.31 тоже глюкодром. И всем пофиг. Это вот так коммерческий софт делается. В мире opensource можно хотя бы написать bugtracker и рассылку и хоть добиться того, что разработчики прочитают, мол баг есть. А также можно ожидать нормальной методики разработки: есть разрабатываемая версия, со всеми багами, и есть стабильная. И коль исправили ошибки по пути от C30 3.31 до XC16 1.20, то можно эти же исправления было внести в "стабильный" C30 3.31.
$ xc16-gcc -v -v -v Microchip Language Tool Shell Version v1_20 (Build date: Sep 30 2013). Copyright (c) 2012 Microchip Technology Inc. All rights reserved Executing: "/opt/microchip/xc16/v1.20/bin/bin/elf-gcc" "-v" "-v" "-v" Using built-in specs. COLLECT_GCC=/opt/microchip/xc16/v1.20/bin/bin/elf-gcc Target: pic30-elf Configured with: /Users/cawilkie/dev/builds/build_20130930_1/src/XC_GCC/gcc/configure --build=i386-darwin --host=i386-linux --target=pic30-elf --disable-lto --disable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --disable-hosted-libstdcxx --with-gnu-as --with-gnu-ld --enable-languages=c --disable-nls --disable-libgomp --without-headers --disable-libffi --disable-bootstrap --prefix=/Users/cawilkie/dev/builds/build_20130930_1/install/bin --libexecdir=/Users/cawilkie/dev/builds/build_20130930_1/install/bin --program-prefix=pic30- --with-libelf=/Users/cawilkie/dev/builds/build_20130930_1/bin/XC_GCC-elf-linux-xclm/host-libs/ --with-dwarf2 --with-gmp=/Users/cawilkie/dev/builds/build_20130930_1/bin/XC_GCC-elf-linux-xclm/host-libs --with-ppl=/Users/cawilkie/dev/builds/build_20130930_1/bin/XC_GCC-elf-linux-xclm/host-libs --with-cloog=/Users/cawilkie/dev/builds/build_20130930_1/bin/XC_GCC-elf-linux-xclm/host-libs --with-zlib=/Users/cawilkie/dev/builds/build_20130930_1/bin/XC_GCC-elf-linux-xclm/host-libs --with-bugurl=http://www.microchip.com/support --with-host-libstdcxx= Thread model: single gcc version 4.5.1 (XC16, Microchip v1_20) Build date: Sep 30 2013 (Microchip Technology) $ pic30-coff-gcc -v -v -v Using built-in specs. Target: pic30-coff Configured with: ../gcc-4.0.2/gcc-4.0.2/configure --prefix=/opt/c30 --target=pic30-coff --enable-languages=c Thread model: single gcc version 4.0.3 (dsPIC30, Microchip v3.31) Build date: Apr 17 2012Жирным выделено. Показательно, что авторы работают в cygwin. Исходники гвоздями прибиты к mingw. Исходники с gcc 4.5.1 вообще не сличаются т.к. дико перетасованы по каталогам. Не хватает 11000 глобальных переменных. Понятно почему они это не делают. В GCC 4.0.3 тоже полно проблем. Но легко было перейти на соседнюю 4.0.4, например. Но вместо этого схватили последнюю на тот момент версию GCC 4.5.1 по-определению-глючную. Но опять же это история 2010 года. Сегодня уже 2014 на носу. Исходники не проапдейтить до 4.5.4 хотя бы (там масса исправленных проблем) ? Потому, что вместо нормального написаня бэкенда для pic24 там сумасшедший патч всего gcc, что не позволяет даже апдейт gcc до следующей версии. Пусть vbulletin настраивать научаться. То, что на форуме microchip.com в принципе не работают переводы строк из линукса и это никого не волнует -- показательно (у всех остальных работает -- т.е. это их криворукий индус что-то испортил). Неужели такая большая фирма как microchip не может, если ихние сотрудники (которых там, похоже, вовсе 1 человек и уволься он всё встанет) не справляются, то просто заплатить денег авторам GCC чтоб сами сделали нормальную версию на pic24? Что они делают вместо этого? Их люди спрашивают. Вот у вас используется GCC и там есть лицензия. Дайте исходники. И что? Исходники, сюрприз, не собираются. Т.е. фирма микрочип берёт из опенсоурса, выпускает свой глючный продукт, который сама же не в состоянии довести до ума, и хакерскими методами зажимает исходники. Тьфу...