Jump to content

    

YuraFCZ

Свой
  • Content Count

    123
  • Joined

  • Last visited

Community Reputation

0 Обычный

About YuraFCZ

  • Rank
    Частый гость
  • Birthday 10/05/1983

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

1402 profile views
  1. #define USBD_STATE_DEFAULT 1 - это исходное состояние USB-device, устанавливается при инициализации и остаётся таковым до подключения к хосту #define USBD_STATE_ADDRESSED 2 - промежуточное состояние при подключении, хост уже установил адрес, но ещё не передал конфигурацию #define USBD_STATE_SUSPENDED 4 - по названию понятно, что перевод в некое остановленное состояние, но не знаю в каких случаях хост выполняет перевод подключенного девайса в состояние suspend и выводит из этого состояния (resume), у меня при работе с CDC такое состояние не возникало
  2. Прошу администраторов заменить мой кириллический ник "Юрий Санвальд" на SanvaldYV. Заранее спасибо.
  3. У нас было так на плате с LPC2132, когда только начинали с ним работать. У LPC есть нога, нулевой уровень на которой в момент ресета запускает встроенный (заводской) загрузчик. У 2132 это была P0.14. У нас она использовалась еще для работы с внешним АЦП и при включении девайса иногда была ситуация что в момент запуска МК в момент поднятия ресета напряжение на этой ноге еще не установилось. Тоже долго не могли понять почему иногда некоторые платы не стартуют.
  4. Как то странно Вы работаете с прерываниями от УАРТа... While-ы в функциях "putchar/getchar" потенциально могут привести к зависанию в прерывании - ведь Вы не смотрите, чем оно было вызвано. По идее, логика работы должна быть такая: 1. Попали в прерывание - читаем U0IIR. 2. В нем смотрим поле "Interrupt Identification" (IID), определяем причину прерывания. 3. Выполняем обработчик для того события, которое вызвало прерывание.
  5. Автор топика написал, что требуется не только выдать на пин частоту порядка 10 МГц, но еще и мониторить состояние некоторых ног с входными частотами такого же порядка... Если работа с GPIO на таких частотах принципиально возможна (как уже написали выше авторитетные люди), то времени на какую либо обработку получаемых с входных ног данных по моему просто нет - что можно успеть за несколько единиц тактов? Сохранить состояние ноги где то в RAM, переключить какой нибудь выход?
  6. А почему Вы думаете, что ошибка в обработчике прерывания? Оно у Вас вообще происходит, это прерывание? В обработчик программа попадает? Как это проверяли? Инициализация портов и таймера не приведена, так что трудно что то сказать...
  7. Запущено серийное производство прибора в котором есть LPC2132. За 1.5 года выпущено пока около 500 штук. В статистике приборов, приходящих в ремонт, не помню ни одного случая когда неисправность была бы связана с ним. Тоже столкнулся с этим при оборудовании рабочего места на производстве, где должно было осуществляться программирование МК, насколько я помню проблема тогда решилась обновлением версии J-Flash с 3.40 до 4.0. Сейчас жалоб на проблемы с программированием по JTAG нет.
  8. Ну а как Вы предлагаете выключить ХТ1? ХТ2 выключается через XT2OFF, но ХТ1 то чем выключить? При включенном и нормально работающем ХТ2 переключить на него MCLK не удастся, если отсутствует или не работает генератор на XT1. П.С. Понятно, конечно, что проблема надуманная. Во-первых, тактировать именно MCLK не от DCO, а от внешнего ВЧ-кварца вряд ли бывает необходимо. Во вторых, если уж вдруг приспичило так сделать, но при этом не нужен НЧ-кварц, то ВЧ можно повесить на XT1, а XT2 выключить.
  9. То есть, получается вообще нельзя переключить MCLK ни на что кроме DCO, если установлен OFIFG. Если же хотите проверить включился ли у Вас уже собственно XT2, то и проверяйте непосредственно XT2OF, а не OFIFG.
  10. При пустом цикле и включенной оптимизации компилятор вероятно выкинет и объявление переменной, и сам цикл, так что это скорее всего просто время на переключение пина, по которому вы замеряете время выполнения.
  11. Доброго времени суток, уважаемые форумчане. При прошивке устройства на базе MSP430f2617 столкнулся с тем, что и IAR, и FET-Pro430 при подключении определяют его как MSP430f2618. :cranky: Сам процесс прошивки проходит нормально, проблем не возникает. Но из чистого интереса хочу поинтересоваться, может быть кто то знает - так и должно быть, или это ненормально?
  12. ИМХО, хранить все накопленные данные в ОЗУ, пусть даже и энергонезависимого прибора - это не комильфо. Поставьте маленькую внешнюю FRAM-ку с SPI/I2C интерфейсом, и сохраняйте туда все. Ресурс FRAM сейчас таков, что при записи раз в минуту о нем можно даже не думать. При этом все Ваши накопленные значения всегда будут в целости и сохранности даже при смене батарейки, перезагрузке прибора и т.п.
  13. while(FCTL3 & BUSY) {}; FCTL3 = FWKEY; FCTL1 = FWKEY + ERASE; __data20_write_char(g, 0x0F); У меня в функции стирания сектора, написанной для 5418, было еще одно while ( FCTL3 & BUSY ); между FCTL3 = FWKEY; и FCTL1 = FWKEY + ERASE; Уже не помню, из каких соображений это было сделано. Но можете попробовать проверить у себя.
  14. rezident, да вы правы конечно, но все таки "выбить" пин осциллом на стареньких атмеловских мегах и тексасовских МК было гораздо труднее, чем на новых MSP-ках или LPC-ках. :crying: Я встречался на 247-м и 5418-м, несколько раз приходилось перепаивать МК после интенсивного тыкания осциллом. А на 169-м, например, ни разу ни один пин не умирал от осциллотыкания у меня
  15. А если не секрет, с чем именно возникли сложности? Я тоже с 5418 работал, использовал только таймера, АЦП (без ДМА), УАРТ и еще во флэш писал (как в инфо-мемори так и в другие сектора), все работало в адекватно и в соответствии с мануалом. А у Вас с какой периферией трудности?