Jump to content

    

Алексей ВМ

Участник
  • Content Count

    119
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Алексей ВМ

  • Rank
    Частый гость

Recent Profile Visitors

2149 profile views
  1. TCIF сбрасываю. Если не сбрасывать, будет заходить в обработчик снова и снова по первой записи. Другие флаги не выставляются, то есть ошибок записи тоже нет.
  2. Вообще один раз, больше не возникает, запись в регистры ARR и RCR (через DMAR) перед этим прерыванием производится правильно. СС1 шлепают нормально, данные выводятся, UIF выставляется, но записи в регистры ARR и RCR не производится, прерывания от выполнения этой записи не возникает.
  3. Реализовал выдачу данных по событию capture/compare event. Прерывание ТС записи DMA по update event возникает только один раз, прерывание ТС записи DMA по capture/compare event генерируются нормально. Регистры CCR1 = 0, ARR и RCR содержат правильные значения. Как я понимаю update event возникает только один раз. В чем может быть причина?
  4. Немного модифицированное предложение ув. SSerge Пины дергать не по update event, а по capture/compare event. Соответственно, update event возникает при окончании передачи всего пакета (68 импульсов), по нему производится DMA запись регистра ARR новым значение периода. Два обработчика прерываний - один старый для формирования буфера передачи, новый для изменения периода таймера.
  5. В проекте присутствует обработка довольно большого объема данных, прерывание с такой обработкой будет занимать довольно значительное время... Немного не ясно с RCR: Each time the REP_CNT related downcounter reaches zero, an update event is generated Это какой-то особый update event, или он заведен на TIM1_UP? Дальше по тексту упоминается repetition update event U_RC: As REP_CNT is reloaded with REP value only at the repetition update event U_RC, any write to the TIMx_RCR register is not taken in account until the next repetition update event. но кроме этого отрывка нигде не находится поиском.
  6. Если удастся менять период таймера аппаратно, то задержки до единиц мкс до входа в обработчик прерывания ни на что не влияют. За FPU благодарю, постараюсь избавиться от него.
  7. Уже работает. Но заказчик решил изменить возможности, отсюда все эти пляски с бубном...
  8. Частота 168 МГц . XMC4700 мы с Вами уже обсуждали в другой ветке. Если девайс будет развиваться, естественно, аппаратная часть будет изменена.
  9. Перерыв в несколько десятков или даже сотен мкс не критичен, главное, чтобы он был не чаще одного раза в неск сотен мс. Потери данных, я понимаю, не произойдет? Не вариант, заказчик за каждый цент удавится
  10. Точность +- 10 нс для наименьшего периода 50 нс, меньше не нужна. По сути, это параллельная шина с 10 сигналами, один из которых клок. ШИМ, к сожалению, здесь не прокатит... Платы уже вовсю клепают...
  11. По мелочи если только. Протокол в части добавления новых команд, но объем обмена данными небольшой. Основной функционал - выдача на пины сигналов. Есть ещё редкое- раз в неск секунд - чтение данных из SPI памяти и обработка этих данных, но логика обработки относительно простая.
  12. Есть ещё обмен по уарту, и больше никаких прерываний. По сути, да, STM большую часть времени используется как ПЛИС.
  13. Это DMA с двойным буфером. Грузи данные раз в несколько мкс и все.
  14. Нет, минимальный период таймера 50 нс, период клока на пине - 100 нс - это 10 МГц. STM32F4 вполне справляется. Затык с переинициализацией таймера на ходу.