0
У Вас же символ повляется в заголовке — прототип вектора. Может для понятности вынести прагмы туда?
Хотя я бы лично воспользовался __attribute__ ((weak, alias («foo»))); Насколько я помню разработчики GCC рекомендуют не пользоваться прагмами. Да и смотреться будет органично, ведь для всего остального у Вас используются аттрибуты, а не прагмы.
Но дело вкуса наверное, не больше :)
  • avatar
  • becopt
  • 12 ноября 2014, 13:04
0
И читается хорошо.

А почему #pragma weak? Атрибута weak нет?
  • avatar
  • becopt
  • 12 ноября 2014, 10:33
0
А мне нравится идея. Только вот лично мне при чтении такого кода было бы понять архитектуру тяжелее, чем простые коллбеки.
Действительно, пишите на плюсах, если ничто не ограничивает.

Естественно, говоря о Си, мы не можем говорить об объектах
Почему?

Ну и попридираюсь.
// Private Functions
void SystemTimerTick (void)
static?

inline void LedOn(void);
...
inline void __attribute__((always_inline)) LedOn(void)

Лучше static inline и без прототипа.
  • avatar
  • becopt
  • 21 октября 2014, 09:44
0
Для XC32 начиная с v1.32 поменялся менеджер лицензий и теперь старый кряк не работает.
  • avatar
  • becopt
  • 08 сентября 2014, 11:23
0
инструкция
  • avatar
  • becopt
  • 03 сентября 2014, 10:31
0
Я пользуюсь отладкой в proteus для простеньких задач, но не уверен, что он подойдет для решения вопросов, связанных с tcp/ip, файловыми системами и крупными жки.
Несмотря на то, что рабочая машина у меня достаточно мощная я ощущаю, как MPLAB-X её притормаживает. И это при довольно частой принудительной очистке мусора. Для сравнения — подключил xc32 в QtCreator — несравнимо легче и удобнее вести разработку, однако для прошивки и отладки пользоваться пока что не выходит, отлаживаться лишь терминалом не так удобно :(
  • avatar
  • becopt
  • 02 сентября 2014, 17:44
0
Процитирую с форума dangerousPrototypes
Microchip is a very good partner. When you work with them at high scale (100K or more chips per year), they provide instant support, lead time is most of the time <6months. Compared to, for example, NXP or ST, for such quantities, lead time is more than 1 year, and the bed thing, is that most of these vendors (including NXP) obsolete the chip without any warning.
Так что любимых не выбирают.
  • avatar
  • becopt
  • 02 сентября 2014, 17:41
0
Оптимизатор действительно нужен, т.к. к размеру и быстродействию кода задаются конкретные требования. А одна операция — 4 байта, ну или 2, если mips16. Есть некоторые критические участки кода, которые необходимо размещать в boot-секторе памяти контроллера, а он очень мал.
  • avatar
  • becopt
  • 02 сентября 2014, 17:38
0
У меня жрёт ~500 метров оперативки. Парсер иногда прилично подтупливает. Очень огорчает отсутствие плагинов как-то для проверки стиля кода и прочего. Я-то в целом привык, но пользуюсь лишь из-за отладки, которая не самая быстрая, но думается, что это в первую очередь из-за железа — дурацкого ICSP, который обрезок JTAG'a.
  • avatar
  • becopt
  • 02 сентября 2014, 13:56
0
MPLAB-X ужасно тяжелая и тормознутая вещь. Arriba — не знаю. Eclipse сам по себе куда более гибкий за счёт множества плагинов, в то время как хоть MPLAB-X и сделан на основе NetBeans, то плагины этого самого NetBeans он не поддерживает.
Основная хотелка — прикрутить к QtCreator эту аррибу, чтобы программировать-отлаживать, летать во сне.
  • avatar
  • becopt
  • 02 сентября 2014, 13:44
0
При создании проекта в окошке выбора дебаггера есть, только красный. У меня его нет, драйвера на него нет, так что правду не скажу. В целом оно один в один меню и возможности MPLAB-X, только в окошках эклипса.
  • avatar
  • becopt
  • 02 сентября 2014, 13:22
0
Под восьмибитники был микрочиповский и альтернатива — hi-tech, который микрочиповцы, судя по данным на форумах, в итоге выкупили и на его основе заделали XC8.
  • avatar
  • becopt
  • 02 сентября 2014, 11:51
0
Касаемо 32-х, то порт на MIPS давно сделали сами MIPS'овцы. Выглядит это всё-таки как развод на деньги, особенно сравнивая с ARM'ами, где gcc бесплатный, но не лучший компилер (лучшие платные и стоят своих денег).
  • avatar
  • becopt
  • 02 сентября 2014, 11:27
0
Наверное я просто не готов нажимать магическую кнопку, а потом удивляться в стиле «Что это? Я же такого не писал / писал совсем не так...» :)
Вероятно нажать кнопку и проще, но исправляя ошибки точно учишься быстрее. В своё время работая на Java меня очень впечатлил checkstyle.
  • avatar
  • becopt
  • 01 июля 2014, 16:42
0
Про режимы — таблица 6.3 в DS61112E-page 6-21.
Имхо, лучше всего распечатать схему тактирования на Рисунке 6-1 в DS61112E-page 6-2, непосредственно поверх неё ручкой просчитать как хочется тактировать и выставить соответственно значения регистров.
  • avatar
  • becopt
  • 26 мая 2014, 17:25
0
А есть возможность сравнить с code::blocks? Я к нему достаточно сильно привык, однако creator все очень нахваливают.
  • avatar
  • becopt
  • 06 мая 2014, 09:36
0
Я так понимаю, что _t зарезервированы толлко для POSIX-совместимых систем.
Вполне вероятно Вы правы и стоит использовать некий свой префикс/постфикс для создания персонального пространства имён и избегания коллизий.
  • avatar
  • becopt
  • 30 апреля 2014, 10:13
0
А где в исходной статье отрицается итеративный подход? Или где его отрицаю я? :) Там вся мысль гораздо проще: подумай, прежде чем делать.
  • avatar
  • becopt
  • 29 апреля 2014, 17:12
0
Подозреваю, что он говорит об этом :)
  • avatar
  • becopt
  • 29 апреля 2014, 17:05
0
Я лично, категорически не согласен с Вами за одним случаем: когда проект является радиолюбительской поделкой или несет в себе минимальный функционал.
В остальных случаях грамотный руководитель прорисовывает программу (алгоритм, конечный автомат, UML'ки), разделяет разработку по модулям и реализует связку Логика+HAL+драйвер. И требует прогонки по Unit Test'ам каждого модуля.
Я успел поработать и там, где реализован описанный выше подход, и где каждый разработчик кодит во что горазд. Как итог — во втором случае процесс разработки растягивается, поддержка кода и передача его усложняется очень сильно, переносимость практически отсутствует.
Хотя, как правило, (к сожалению) всем этим сильно пренебрегают «для ускорения разработки». Что выливается в большие костыли и потерю времени. Но людей не переубедишь.
  • avatar
  • becopt
  • 29 апреля 2014, 16:21