ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
22 декабря
1032882 Топик полностью
fk0легенда (01.09.2020 23:09, просмотров: 728) ответил Cкpипaч на Выбор кристала. Спрошу и я. Сейчас используем atmega8.
Никто не назвал PIC24. Плохой компилятор у микрочипа и отвратная IDE, но с этим можно смириться (отлаживать в старом мплабе, писать код в виме -- как-то так). 12-бит АЦП есть, внутрисхемная отладка есть, нужно покупать только шайбу (pickit дешевле), оперативки маловато и больше не будет (32кБайт -- максимум). ИДЕ покупать не надо, внутренняя структура простая и надёжная (читается общий PDF и специфичное для перифирии приложение), никаких кубов и т.п. нет. Что с отдельной 

EEPROM не помню, но страницы памяти допрограммируются мелкими блоками (можно сделать эмуляцию) -- так даже надёжней (поверх EEPROM тоже какой-то слой нужен, ибо запись может оборваться на любом байтике). Питание конечно же не 5в, но есть по крайней мере 5v tolerant выводы. Способность сохранять ОЗУ при работе от батарейки (в отличии от армов)


PIC18 -- садомазо, оправдано там где очень массовая продукция, из-за цены. К тому же лимит flash в 128кБайт. Всё 32-битное -- сложней в программировании периферии (и проще в программировании вообще), более нежное (у тех же пиков относительно мощные выводы которые ещё и параллелить можно), хуже перифирия часто.


Ещё альтернатива -- бывшие атмел, сейчас microchip армы. Там тоже относительно просто и без куба, можно обходиться чтением даташита. Они в некоторых аспектах очень интересные (на фоне STM, NXP или TI).


Плотность кода тоже фактор: обычно упираются в объём Flash, затем следует дорогой чип который портит бюджет проекта.


PIC24 и RL78 имеют сравнимую плотность кода и одинаково плохой компилятор: RL78 на 7% компактней для кода и, внимание, в 1.5 раза компактней для константных данных (у PIC24 очень специфическое представление констант в 24-битной программной памяти -- один байт из трёх не используется, можно записать 100% эффективно, но такие данные читать нужно будет вручную спец. командами).


У PIC24 и PIC18 как ни странно, плотность кода примерно сопоставимая: у PIC24 плохая оптимизация и слишком широкие 24-битные инструкции, у PIC18 на каждый чих нужно несколько инструкций. Может быть в XC16 плотность кода лучше, чем в C30, я давно не в теме. Но в самом XC16 есть специфические проблемы (из-за индусского видения C-компилятора), вполне возможно, что C30 безальтернативен.


MSP430 при лучшем компиляторе сходит с дистанции из-за генетических проблем с более чем 16-битным адресным пространством (когда я смотрел 7 лет назад в gcc что-то было не доделано, по-моему воз и ныне там).


ARM в thumb может где-то на 40% выигрывать у PIC24 и плотность кода у него выше чем у AVR или PIC18. Но есть и обратная сторона -- 32-битность может раздуть код (указатели в 2 раза больше, кода пишется больше и т.п.) И для ARM очень качественные компиляторы (gcc, clang). Для 16-битников реально сильно хуже. Это касается и C-библиотеки, и возможности использования многозадачной ОС (для PIC24 это без своей реализации libc кажется трудностью).


У ARM выше программная надёжность: большое адресное пространство (в 16-битном куда не ткни -- валидный адрес), наличие исключений вырабатываемых CPU в случае ошибок. У PIC24 вообще смешно: по адресу 0 располагаются регистры процессора (что такое NULL и характерные ошибки -- все же знают?) С другой стороны у него стек растёт вверх, что уменьшает число фатальных сбоев (адрес возврата не затирается).


PIC18, x51 -- принципиальные проблемы с рекурсивными функциями (из-за "компилированного стека"), плохо подходят для нормального программирования вообще...


Для ARM не нужны специфические IDE (если есть поддержка со стороны OpenOCD, что я бы крайне рекомендовал), можно брать обычный эклипс или работать из консоли. Для прочих -- выбора нет, что дали.


MIPS -- из контроллеров только Microchip, со страшной errata и как оно там мало вообще кто знает. В принципе MIPS как архитектура CPU разделяет многие свойства ARMа, но мало пользователей -- много несглаженных острых углов.


Исполнение кода из ОЗУ -- тоже особый момент, PIC18, PIC24 -- не умеют. Нужно иметь ввиду. Если вдруг захочется сделать загружаемые (по сети, с флешки...) программы.


Вдогонку: тактовый генератор, для микропотребления может оказаться важным, насколько он гибко настраивается. Бывает нужна высокая частота для периферии, бывает только для ядра, бывает нужно уметь останавливать ядро. Можно ли отключать выборочно периферию (для снижения потребления). У больших ARM'ов часто достаточно гибко, у PIC18 практически никак, у PIC24 однобоко: ядро всегда быстрей периферии (хотя его можно усыплять). Я бы обратил внимание, возможна ли работа от внутреннего генератора (с умножением до нужных мегагерьц) с синхронизацией от часового кварца. У PIC24 смешно в даташите, мол регистр подстройки не гарантирует монотонное изменение частоты (как тогда подстраивать вообще???)


Ещё вдогонку: C++. Тут пролетала ссылка на C++ компилятор для PIC24 (http://caxapa.ru/981010), но в целом как я понимаю C++ это удел RL78, ARM и MIPS. 8-битники в пролёте, PIC24 под вопросом. На мой взгляд наличие C++ компилятора -- это очень серьёзный фактор. C++ позволяет, при аккуратном подходе, очень значительное количество ошибок перетянуть из run time в compile time и таким образом повысить надёжность ПО и сократить время на постоянные багфиксы (которое доминирует над прочими затратами на разработку часто).


Опять вдогонку: RL78 в общем медленный. Если вдруг не только задачи логического управления, но посчитать что-то быстро нужно (dsp, криптография) -- скорей ARM или dsPIC.


По цене RL78 может оказаться в лидерах, особенно по отношению к объёму flash и наличию чипов с небольшим числом выводов в легко паяемых корпусах (что тоже негативно влияет на стоимость -- у ARM когда большой flash сразу 200 ног или BGA).

[ZX]