Форум РадиоКот

Если б открыли RM на Ваш МК - даже без знания инглиш, видно, что ноги связаны с регистрами CCRx.

del

удалил - сообщение было не во всем корректно.
но вызывать передачу строки в обработчике прерывания ни есть гуд.

так там и должна быть "1", исходно CNT < CCR =ARR/10. чего не так?

"110: PWM mode 1 (режим 1 ШИМ) - при счете вверх канал 1 активен (OC1REF=1), пока TIMx_CNT < TIMx_CCR1, иначе не активен (OC1REF=0). "

при включении TIM2->CCER |= TIM_CCER_CC2E;
состояние OCxREF отображается на ногу.

Пробовали делать снимки направляя лампу на об'ект с'емки, а не в камеру?

если интересует тон - зачем АЦП ?

а если посмотреть, действительно EOSEQ пропадает ?

ADC_array[128]=0;

ADC1->ISR |=ADC_ISR_EOC | ADC_ISR_EOSEQ;
for (int i; i<128; i++){

while ((ADC1->ISR & ADC_ISR_EOC) == 0) {}
ADC1->ISR |=ADC_ISR_EOC;

if (ADC1->ISR & ADC_ISR_EOSEQ) {
ADC1->ISR |= ADC_ISR_EOSEQ;
ADC_array = 1;}
else {ADC_array ...

выстраивайте ожидание:
1 снимаем флаг EOSEQ, если был
2 ждем когда EOSEQ=1 - текущая очередь заканчивается,
3 снимаем флаги EOSEQ, EOC ,
4 ждем EOC первого из новой очереди
...

да и очередь лучше как-то так задавать (не через |=)
ADC1->CHSELR = ADC_CHSELR_CHSEL2 | ADC_CHSELR_CHSEL5;

будем полагать, что не знаем какой канал сейчас оцифровывается, поэтому считав DR проверяем EOSEQ - если 1 то это последний в очереди. и я полагаю, что в последующем это все таки массив (с чередованием каналов) - иначе зачем массив, это просто две переменные.

у него на библиотеке - а это и"жирней" на 10-20% и медленнее.
да и ожидания BUSY после загрузки DR.
т.е. сделать пошустрей цели не стояло похоже

полагаю "вас" во множественном числе
я не спец, да и в рабочее время доступа к компам и интернету не имею - совсем в другой области работаю

а RM на свой МК открывали?
в видео режимах импульсы синхр. нужны чтоб раскладывать приходящую инфу по строкам и по кадрам, в режиме jpeg этой раскладки нет, но нужен спад по VSYNC для начала захвата "кадра", если dma не успеет выбрать буфер, захват прекратится до следующего VSYNC.
это из RM, как оно ...

если я правильно понял исп. DCMI для этого дела:
синхронизация аппаратная,
нужен режим JPEG,
сигн.DCMI_HSYNC - в неактивный уровень (или разрешение данных),
сигн.DCMI_VSYNC - для запуска захвата, если DMA не успеет забрать данные, эту линию придется передернуть, или можно их объединить ...

непонятно было, когда Вы вопрос задали не приводя контекст, вот и ответ был - не надо читать - не читайте.
а код привели, стало понятно - вывод байта обрамляется сиг.DC, а как узнать когда можно уже дергать DC? -вот и ждут RXNE, а уже чтобы сбросить флаг - читают DR, можно в никуда.
когда не надо ...

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

остается научить DCMI правильно работать.
жесть, кто придумал так порты конфигурить ...
заблудился, что Вы подаете на PA3?
на HSYNC и VSYNC должен быть неактивный уровень, 0 или 1 зависит от VSPOL и HSPOL в DCMI_CR

[uquote="Sergi",url="/forum/viewtopic.php?p=4457173#p4457173"]В F0 можно проверять флаг BUSY. Означает что передача не окончена. Ждать пока BSY=0 и потом можно дергать DC.[/uquote]
...Ждать когда BSY=0...

на быстром коде может потребоваться небольшая задержка после записи в DR до проверки BSY, он ...

в пакетах, где частая смена линии DC (инит дисплея), ожидание завершения передачи байта, перед сменой сост. линии DC - неизбежность.
в пакетах, где DC менять не надо - в рукопашную не передают , используют DMA.

у Вас на картинке есть параметр tpd (задержка от соответствующего фронта на установку данных на шине - только после нее данные достоверны) по тексту у Вас о нем ни слова.
т.е. Вам надо не только удвоение частоты (захват чаще), но и фазовый сдвиг на этот самый tpd (для захвата).
или аппаратно ...

zenon ,
1- SPI у F1 и F0 разный, в первом нет FIF0 очереди, источники для подглядывания надо выбирать соответствующие;
2- флаги TXE, RXNE можно сказать здесь относятся к очереди, а не процессу передачи - что приводит к тому, что Вы шурудите линеей DC прям во время передачи уходящего байта.
в ...

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

поясните, плиз, зачем такая конструкция
*(uint8_t *)&
или это, когда data нельзя сделать uint8_t ?