Перейти к содержанию
    

Добавлю еще один недостаток: качество кода, примеров, знание принципов программирования, языка С отавляет, мягко говоря, желать...Понятия bit-field, enum NXP незнакомы, количество "magic number" зашкаливает... Простие меня электрики, но это ваш стиль. Другими словами, софтвер НЕПРОФЕССИОНАЛЕН!

Да, и вайла описания битое у NXP нет! У Atmel с этим серьезных проблем не обнаружил.

Ужос-то какой! Гадский NXP не написал хидеры в приятном Вам стиле.

Если микроконтроллер берется в разработку плотно и надолго (на несколько проектов/серию, не для "халтурки"), то хидеры вообще-то желательно написать полностью "под себя" самому. Внести свою систему обзывания регистров, битов в регистрах, размещения определений в секциях, учесть особенности компилятора(-ов). Попутно, создавая хидер, внимательно прочесть документацию (когда обзываешь биты - так или иначе читаешь за что они отвечают и как работают) и получить более-менее полное представление об аппаратуре. Для начала можно описывать не все блоки - а только нужные, и потом расширять хидер по мере освоения новых блоков. Угу, это сначала долго, требует кропотливого труда, но потом проблем сильно меньше обычно и при наличии в работе полудюжины архитектур мозгам потом сильно проще работать в едином, собственноручно созданном формате.

ИМХО, если компания/разработчик профессионалы (опытные, уже занимается софтом для контроллеров некоторое время), то обычно есть свои наработки в виде выбранной RTOS, стеков USB/TCP и прочего, и от контроллера требуется только соответствовать заявленным техническим характеристикам, и иметь более-менее удобоваримую документацию. На софтовый мусор, предлагаемый производителями, как правило можно не смотреть - это для хомячков, глючное, непортируемое, часто с лицензионными ограничениями.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Переход на ARM ядро у меня и было обусловлено, тем что в глаза бросился STM32. Низкая цена, доступность средств разработки. Изучение заняло неделю + неделя на портирование текущих проектов. Atmel нервно курит со своими подходами (Про NXP к сожалению не скажу). А удобство программирования на лицо. Взаимозаменяемость чипов+четкая логика в наборе интерфейсов и возможностей для каждой градации контроллеров.

Изменено пользователем Batman

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ужос-то какой! Гадский NXP не написал хидеры в приятном Вам стиле.

Если микроконтроллер берется в разработку плотно и надолго (на несколько проектов/серию, не для "халтурки"), то хидеры вообще-то желательно написать полностью "под себя" самому. Внести свою систему обзывания регистров, битов в регистрах, размещения определений в секциях, учесть особенности компилятора(-ов). Попутно, создавая хидер, внимательно прочесть документацию (когда обзываешь биты - так или иначе читаешь за что они отвечают и как работают) и получить более-менее полное представление об аппаратуре. Для начала можно описывать не все блоки - а только нужные, и потом расширять хидер по мере освоения новых блоков. Угу, это сначала долго, требует кропотливого труда, но потом проблем сильно меньше обычно и при наличии в работе полудюжины архитектур мозгам потом сильно проще работать в едином, собственноручно созданном формате.

ИМХО, если компания/разработчик профессионалы (опытные, уже занимается софтом для контроллеров некоторое время), то обычно есть свои наработки в виде выбранной RTOS, стеков USB/TCP и прочего, и от контроллера требуется только соответствовать заявленным техническим характеристикам, и иметь более-менее удобоваримую документацию. На софтовый мусор, предлагаемый производителями, как правило можно не смотреть - это для хомячков, глючное, непортируемое, часто с лицензионными ограничениями.

Желаю всяческих успехов в переписывании всех и вся! И не жалейте времени...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Желаю всяческих успехов в переписывании всех и вся! И не жалейте времени...

Жалеть время придется Вам, если будете использовать "професиональный софтвер" от производителя. Там очень часто встречаются ошибки, которые могут дорого обойтись.

 

PS: Работал (т.е. делал реальные проекты, а не игрался с отладками) с мк атмела, nxp и stm. Самые приятные ощущения от nxp.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если микроконтроллер берется в разработку плотно и надолго (на несколько проектов/серию, не для "халтурки"), то хидеры вообще-то желательно написать полностью "под себя" самому. Внести свою систему обзывания регистров, битов в регистрах, размещения определений в секциях, учесть особенности компилятора(-ов).

Не вижу смысла в переписывании заголовочных файлов. К примеру, в stm32f2xx.h все регистры и биты описаны, близко к техническому руководству, зачем же их "обзывать" иначе? Другое дело - дополнить чем-то... Лучше пройтись по этому заголовку, глядишь, на умное решение натолкнешься...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не вижу смысла в переписывании заголовочных файлов. К примеру, в stm32f2xx.h все регистры и биты описаны, близко к техническому руководству, зачем же их "обзывать" иначе? Другое дело - дополнить чем-то... Лучше пройтись по этому заголовку, глядишь, на умное решение натолкнешься...

ИМХО, готовые хидеры тоже как бы имеют право на жизнь. Тогда разработчик их принимает "как есть", не парится насчет их формата и не устраивает "хомячковых драм онлайн" типа "гадский разработчик не знает про битовые поля".

С другой стороны, если есть уже куча своего софта, уже отлаженного и вылизанного, портируемого на разные чипы, и все уже разложено по полочкам - то почему бы новый контроллер не встроить в эту систему полочек.

Это как штаны - можно открыть шкаф и бросить комом, а можно аккуратно сложить и положить на полку (или даже повесить на вешалку). Результат то один - штаны в шкафу, вот только слегка по-разному они там лежат.

Собственно писать свои хидеры недолго, у меня основное время тратится на чтение документации и вникание в нее. Новополученная информация закрепляется еще и в письменном виде - такая вот особенность со студенческих лет у меня - при подготовке к экзаменам исписывал еще бумаги в 2-3 раза больше чем объем конспекта. Поэтому лично для меня переписывание хидеров достаточно полезно - дальше работать с контроллером мне проще. Ну и удовольствие от того, что "мои штаны аккуратно висят на вешалке". (Не, в реальном шкафу джинсы таки часто комом :biggrin:)

И еще момент. Софт-то усложняется и усложняется. Сотни тысяч сишных строк. И если постоянно "пихать штаны комом" то в шкафу появляется неряшливая куча, которую может оказаться достаточно тяжело разгребать.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Собственно писать свои хидеры недолго, у меня основное время тратится на чтение документации и вникание в нее.

+1. Сам так же делаю. Время написания своих хедеров пренебрежимо мало по сравнению с остальными этапами разработки. Кстати, устраняется зависимость от компилятора (keil/iar/...). Ну и эстетический эффект немаловажен: иногда чужие хедеры вызывают омерзение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати, устраняется зависимость от компилятора (keil/iar/...).

Это у кого хидеры такие классные, что от компилятора зависят?

PS переписывание хидеров считаю делом неблагодарным, в отличие от библиотек, кои часто оставляют желать лучшего.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Предлагаю вернуться к теме, а не обсуждать привычки написания хидеров и использования готовых библиотек.

Модератор.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Работал (т.е. делал реальные проекты, а не игрался с отладками) с мк атмела, nxp и stm. Самые приятные ощущения от nxp.

 

+1 в пользу NXP - LPC17 - основной процессор для серийных проектов

+1 в пользу KINETIS - хороший набор периферии при малопотребляющем ядре M0, много режимов сна с огромными возможностями по выхода.

 

-1 против STM32 - кто пользуется CMSIS начнут защищать что это упрощает/ускоряет разработку - IMHO забивает голову, раздувает код, снижает производительность - один раз попробовал - впечатления ужасные.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

-1 против STM32 - кто пользуется CMSIS начнут защищать что это упрощает/ускоряет разработку - IMHO забивает голову, раздувает код, снижает производительность

А вы, случаем, CMSIS с SPL не перепутали??? ))))

один раз попробовал - впечатления ужасные.

Дык... "один раз" - ещё не... эксперт по STM32...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

-1 против STM32 - кто пользуется CMSIS начнут защищать что это упрощает/ускоряет разработку - IMHO забивает голову, раздувает код, снижает производительность - один раз попробовал - впечатления ужасные.

Я сейчас смирился с хедерами. Там того HALа с гулькин нос... Ну в 500 строчек попаду, ну в 1000 - максимум. Хотя, желание потихоньку рихтовать хедеры осталось.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тем более, что по рукам за это никто и не бьёт... а в случае с STM32F0XX... там явно придётся ручёнки шаловливые приложить...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

-1 против STM32 - кто пользуется CMSIS начнут защищать что это упрощает/ускоряет разработку - IMHO забивает голову, раздувает код, снижает производительность - один раз попробовал - впечатления ужасные.

1. CMSIS есть и для LPC.

2. Никто не заставляет пользоваться CMSIS применительно к STM32. Я, например, не пользуюсь и более чем доволен (имеется в виду STM32).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

CMSIS есть и для LPC.

Никто не заставляет пользоваться CMSIS ......

 

Тут следует, наверное, уточнить, что CMSIS определяет поддержку ядра, и определяет поддержку периферии.

Те макросы и функции что относятся к ядру наверное использовать следует, так как они распространяются на ВСЕ Cortex-M3 а также скорее всего пригодны и для M4 и для M0.

 

А вот поддержка перифирии, да она у NXP не идеальна, код местами написан кривовато, тем не менее всё тщательно задоксигенено и примеры и библиотека.

 

Еще пару слов об NXP ибо в рабочей обстановке имел дело только с ними. В своё время выбор был сделан в пользу LPC2478 ибо такой комбайн из периферии был только у голландцев.

Периферия у них неплохая UART сделан аля '550, SPI имеет поддержку DMA, I2C ясное дело сделано лучше всех так как это детище Philips-а(как и компакт диски :biggrin: ).

 

Разработчики стараются соблюсти наследсвенность, совместимость софта. Начиная с LPC2101...03 заканчивая LPC23xx 24xx.

При переходе на Cortex-M3 -- были сохранены многие модули почти неизменёнными или доработанными чуть-чуть. Поэтому LPC23xx--LPC176x,175x а LPC24xx -- LPC177x. Другое дело что не во всех случаях эта совместимость приятна и радует. Благодоря этой совместимости мне удалось примеры (UART, USB HOST) для LPC176x запустить на LPC2468, чему и посвящен мой проект

USB device правда пока у меня не запустился. (

Изменено пользователем SyncLair

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...