Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Потенциальный баг при работе с PWMLER?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
GetSmart
(название темы на жаргоне лотереи 1010 белайна smile.gif)

По логике работы (аппаратной) он чем-то похож на xxIR регистры таймера и PWM-а. То есть сам сбрасывает биты. Но...

Кто как работает с этим регистром в многоканальном ШИМе?

PS. после стольких смсок от 1010 с утверждением что я потенциальный победитель приза в 30 лимонов я просто обязан назвать сей косяк (вопрос только чей) - багом biggrin.gif

PPS. забыл указать что проц LPC2132, но думаю PWM и у других камней LPC аналогичный.
abcdefg
Всё как-то туманно. В чем баг то?

Цитата(GetSmart @ Jun 9 2010, 02:24) *
(название темы на жаргоне лотереи 1010 белайна smile.gif)

PS. после стольких смсок от 1010 с утверждением что я потенциальный победитель приза в 30 лимонов я просто обязан назвать сей косяк (вопрос только чей) - багом biggrin.gif

PPS. забыл указать что проц LPC2132, но думаю PWM и у других камней LPC аналогичный.
GetSmart
Я пока ещё сам не до конца прощупал баг. Но склоняюсь к тому, что с регистром PWMLER при независимой установке (изменении) MACH каналов нужно работать в битовом режиме, а не как с ххIR регистрами, в которые достаточно просто записывать не читая. Баг например заключается в том, что если установить в PWMLER бит, а потом его сбросить, то соответствующий канал установится не в то значение, которое нах-ся в PWMMRx.

Где-то в описании на PWMLER нашёл, что биты в нём сбрасываются автоматически по смене текущего периода ШИМа. Но опять же работая с этим регистром в битовом режиме может возникнуть любимый баг NXPшников в аппаратном несбрасывании бита к которому в данный момент есть программный доступ. Вообще, если бы разработчики периферии делали всё по-умному, то они бы не стали так делать, а сделали бы этот регистр по аналогии с IOSET, то есть с возможностью только установки стробов (и автоматическим аппаратным сбросом).
KRS
Кстати, хороший вопрос!
Если PWMы не зависимы (например разные яркости) и значения меняются независимо друг от друга.
Как правильно писать PWMLER?
Код
  PWMMRx = val;
  PWMLER = (1<<x);

или

Код
  PWMMRx = val;
  PWMLER |= (1<<x);


По хорошему у этого регистра должно быть - запись 0 без эффекта!
Потому что |= не атомарная операция. И возможно второй раз бит установится. Хотя в большинстве случаев это не критично.

Надо будет завтра проверить.
GetSmart
Цитата(KRS @ Jun 10 2010, 01:21) *
Надо будет завтра проверить.

Если в процессе работы программы будут исполняться такие куски кода
Код
  PWMMRx = val;
  PWMLER = (1<<x);

то в случайном порядке некоторые каналы не будут прописываться.
Далее. Если есть допустим такая инициализация
Код
  PWMTCR = 0x02;
  PWMPR  = 0;
  PWMMR0 = PCLK / 1000;
  PWMMCR = 0x03;
  PWMPCR = 0x2400;
  PWMTCR = 0x09;

  PWMMR2 = 0;
  PWMMR5 = 0;
  PWMLER = 0xff;
  PWMIR = 0xff;
  PINSEL0_bit.P0_7 = 2;
  PINSEL1_bit.P0_21 = 1;

а потом ещё до окончания первого периода PWM будет исполнено
Код
  PWMMRx = val;
  PWMLER = (1<<x);

то начальная инициализация PWMMR2 и PWMMR5 рискует не состояться.

И наконец реальный баг (?). Если выполнить данную инициализацию, а потом (через любое время) два раза подряд
Код
  PWMMRx = val;
  PWMLER = (1<<x);

с небольшим промежутком между ними (внутри периода ШИМа) то исполнявшийся первым канал всё таки обновится, но не реальным значением из PWMMRx, а возможно значением из теневого регистра и у меня почему-то это значение равно какому-то максимуму, то есть на выходе пина PWMx устанавливается значение 3.3V (Vcc). А уже второй или третий такой "глюк" выводит на пин PWMx значение, похожее на записанное в PWMMRx.

Из всего этого следует что наименьшим злом будет использование
Код
  PWMLER |= (1<<x);

Ещё как вариант можно в PWMLER всегда записывать маску всех каналов, которые меняются в процессе работы проги.

Но может быть возможны ситуации, в которых это будет вызывать глюки.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.