YuraFCZ

То, что определённые отличия между ST и GD есть и программа написанная под ST требует адаптации для работы в GD - это понятно и этот путь мы уже прошли. Прошивка протестирована на нескольких макетных платах. Вопрос же в том, не сталкивались ли при производстве с таким что отлаженная и проверенная прошивка на платах с новой партией контроллеров перестаёт программироваться или адекватно работать?

Добрый день. Можете поделиться опытом применения GD-шных контроллеров в серийном производстве? Помимо той ситуации, которую вы в этой теме описали, сталкивались ли ещё с какими то неожиданностями? Мы сейчас адаптировали один проект для STM32F427 под GD32F450, собираемся запускать в серию, в связи с этим интересно можно ли ожидать сюрпризов :)

По моему мнению, если приходится таким образом "отдавать всё" чтобы достичь нужной скорости исполнения программы, то это чревато неприятными последствиями. Обновился компилятор на более свежую версию, и уже результат для того же самого кода может получится другим. Кто нибудь применяет в своих серийных проектах оптимизацию по скорости именно из-за необходимости достичь некую требуемую скорость?

#define USBD_STATE_DEFAULT 1 - это исходное состояние USB-device, устанавливается при инициализации и остаётся таковым до подключения к хосту #define USBD_STATE_ADDRESSED 2 - промежуточное состояние при подключении, хост уже установил адрес, но ещё не передал конфигурацию #define USBD_STATE_SUSPENDED 4 - по названию понятно, что перевод в некое остановленное состояние, но не знаю в каких случаях хост выполняет перевод подключенного девайса в состояние suspend и выводит из этого состояния (resume), у меня при работе с CDC такое состояние не возникало

Прошу администраторов заменить мой кириллический ник "Юрий Санвальд" на SanvaldYV. Заранее спасибо.

У нас было так на плате с LPC2132, когда только начинали с ним работать. У LPC есть нога, нулевой уровень на которой в момент ресета запускает встроенный (заводской) загрузчик. У 2132 это была P0.14. У нас она использовалась еще для работы с внешним АЦП и при включении девайса иногда была ситуация что в момент запуска МК в момент поднятия ресета напряжение на этой ноге еще не установилось. Тоже долго не могли понять почему иногда некоторые платы не стартуют.

Как то странно Вы работаете с прерываниями от УАРТа... While-ы в функциях "putchar/getchar" потенциально могут привести к зависанию в прерывании - ведь Вы не смотрите, чем оно было вызвано. По идее, логика работы должна быть такая: 1. Попали в прерывание - читаем U0IIR. 2. В нем смотрим поле "Interrupt Identification" (IID), определяем причину прерывания. 3. Выполняем обработчик для того события, которое вызвало прерывание.

Автор топика написал, что требуется не только выдать на пин частоту порядка 10 МГц, но еще и мониторить состояние некоторых ног с входными частотами такого же порядка... Если работа с GPIO на таких частотах принципиально возможна (как уже написали выше авторитетные люди), то времени на какую либо обработку получаемых с входных ног данных по моему просто нет - что можно успеть за несколько единиц тактов? Сохранить состояние ноги где то в RAM, переключить какой нибудь выход?

А почему Вы думаете, что ошибка в обработчике прерывания? Оно у Вас вообще происходит, это прерывание? В обработчик программа попадает? Как это проверяли? Инициализация портов и таймера не приведена, так что трудно что то сказать...

Запущено серийное производство прибора в котором есть LPC2132. За 1.5 года выпущено пока около 500 штук. В статистике приборов, приходящих в ремонт, не помню ни одного случая когда неисправность была бы связана с ним. Тоже столкнулся с этим при оборудовании рабочего места на производстве, где должно было осуществляться программирование МК, насколько я помню проблема тогда решилась обновлением версии J-Flash с 3.40 до 4.0. Сейчас жалоб на проблемы с программированием по JTAG нет.

Ну а как Вы предлагаете выключить ХТ1? ХТ2 выключается через XT2OFF, но ХТ1 то чем выключить? При включенном и нормально работающем ХТ2 переключить на него MCLK не удастся, если отсутствует или не работает генератор на XT1. П.С. Понятно, конечно, что проблема надуманная. Во-первых, тактировать именно MCLK не от DCO, а от внешнего ВЧ-кварца вряд ли бывает необходимо. Во вторых, если уж вдруг приспичило так сделать, но при этом не нужен НЧ-кварц, то ВЧ можно повесить на XT1, а XT2 выключить.

То есть, получается вообще нельзя переключить MCLK ни на что кроме DCO, если установлен OFIFG. Если же хотите проверить включился ли у Вас уже собственно XT2, то и проверяйте непосредственно XT2OF, а не OFIFG.

При пустом цикле и включенной оптимизации компилятор вероятно выкинет и объявление переменной, и сам цикл, так что это скорее всего просто время на переключение пина, по которому вы замеряете время выполнения.

Доброго времени суток, уважаемые форумчане. При прошивке устройства на базе MSP430f2617 столкнулся с тем, что и IAR, и FET-Pro430 при подключении определяют его как MSP430f2618. :cranky: Сам процесс прошивки проходит нормально, проблем не возникает. Но из чистого интереса хочу поинтересоваться, может быть кто то знает - так и должно быть, или это ненормально?

ИМХО, хранить все накопленные данные в ОЗУ, пусть даже и энергонезависимого прибора - это не комильфо. Поставьте маленькую внешнюю FRAM-ку с SPI/I2C интерфейсом, и сохраняйте туда все. Ресурс FRAM сейчас таков, что при записи раз в минуту о нем можно даже не думать. При этом все Ваши накопленные значения всегда будут в целости и сохранности даже при смене батарейки, перезагрузке прибора и т.п.