STM32 новичку в ARM что к чему

[Eddy_Em]

[uquote="tonyk",url="/forum/viewtopic.php?p=4237422#p4237422"]использовать уже имеющийся во всех STM32 IDLE или, что лучше, RTO. [/uquote]
А кто сказал, что байты должны идти "ноздря в ноздрю"? Может, между ними по 2-4 свободных фрейма? И окончанием передачи считать, скажем, паузу дольше 100мс после последнего байта…
Я таймауты вообще на терминале тестировал, у меня был выставлен таймаут в 3 секунды (уж за три-то секунды я успею следующий символ набрать =D)

Что до переполнения буфера: а как он переполнится, когда прием идет посредством DMA? По заполнению буфера идет прерывание, и коль не было '\n' в процессе, считаем строку бажной и сбрасываем нафиг с выставлением флага ошибки (т.е. следующий пакет тоже нужно будет выбросить).

[Viktorkin]

[uquote="НовыйДень",url="/forum/viewtopic.php?p=4237131#p4237131"]

Спойлер

Код: Выделить всё

oid USART2_IRQHandler(void)
{
	/* Линия свободна (idle frame) */
	if((USART2->ISR & USART_ISR_IDLE)&&(USART2->CR1 & USART_CR1_IDLEIE))
	{
		Start_RTOTimer();
		USART2->ICR = USART_ICR_IDLECF;
	}

	/* Предыдущий принятый символ не был прочитан */
	if(USART2->ISR & USART_ISR_ORE)
	{
		ToRXBuff(USART2->RDR);
		USART2->ICR = USART_ICR_ORECF;
	}

	/* Символ был принят */
	if((USART2->ISR & USART_ISR_RXNE)&&(USART2->CR1 & USART_CR1_RXNEIE))
	{
		Stop_RTOTimer();
		ToRXBuff(USART2->RDR);
	}

	/* Готов к передаче символа */
	if((USART2->ISR & USART_ISR_TXE)&&(USART2->CR1 & USART_CR1_TXEIE))
	{
		uint8_t ch;
		if(FromTXBuff(&ch))
			USART2->TDR = ch;
		else
			USART2->CR1 &= ~USART_CR1_TXEIE;
	}

	/* Передача символа была завершена и передающий буфер пуст */
	if((USART2->ISR & USART_ISR_TC)&&(USART2->CR1 & USART_CR1_TCIE))
	{

	}

	/* Ошибка кадра в приемнике */
	if(USART2->ISR & USART_ISR_FE)
	{
		USART2->ICR = USART_ICR_FECF;
	}
}

[/uquote]
ухты как классно сделано! взял себе

[tonyk]

А кто сказал, что байты должны идти "ноздря в ноздрю"? Может, между ними по 2-4 свободных фрейма?

А ты поставь в настройках терминала, чтоб он отправлял сразу всю строку по нажатию "Enter", вот твои байты и пойдут ноздря-в-ноздрю.

[НовыйДень]

Одного универсального способа нет, всегда пишется под конкретную задачу. Где-то пакеты все одинаковой длины, где-то разной длины, но начинаются/заканчиваются определенными символами, где-то инфа в нетекстовом виде и нет определенного завершающего символа, где-то разрозненные символы с произвольными промежутками, где-то минимальные промежутки между пакетами регламентированы, а где-то есть контроль четности. Где-то очень высокая скорость порта и нужен DMA на прием/отправку, а где-то скорость низкая по отношению к частоте МК, да еще и занят нужный канал DMA.
Вобщем, ты владеешь несколькими методами работы и выбираешь в конкретном случае наиболее подходящий. Так и везде, в принципе то. Поэтому спорить, что дескать только DMA форева или стопудово только прерывания - не имеет смысла.

[Serj_K]

Уважаемые знатоки, подскажите в решении проблемы. Использовал STM32F051 совместно с отладчиком BlackMagik. Сначала всё работало как часы, прошивало, отлаживало. Но в один момент чип перестал видиться отладчиком. Достал ST-Link. С ним теперь возможна только запись прошивки из-под ресета через родную прогу, без отладки. Пин BOOT0 сидит на земле, то есть используется запуск из прошивки флеш, пины SWD в проекте вообще не заняты и нигде не переназначаются. Куда копать для восстановления нормальной работы SWD?

[Viktorkin]

наверно отключили swd в настройках cubeide

[Serj_K]

Не, кубами и халами не пользуюсь принципиально, только низкоуровневыми либами.

[Eddy_Em]

Одна из SWD'шных ног сожжена статикой? Можно проверить и поногодрыжить…

[Up2805]

Если бы SWD-шные ноги были бы сожжены, то МК не прошивался бы даже.

[Eddy_Em]

Значит, остается лишь грепать по всем исходникам флаги отключения SWD/JTAG: вполне возможно, что с копипастой из старого кода, оно где-то пролезло.

[VladislavS]

[uquote="Serj_K",url="/forum/viewtopic.php?p=4245449#p4245449"]только низкоуровневыми либами.[/uquote]Искать где "низкоуровневая либа" с GPIOA->MODER нарукоблудила.

[Serj_K]

Вывел на экранчик железки, которую делаю, состояния некоторых регистров.
1) GPIOA->MODER для SWD в состоянии альтернативной функции как по умолчанию для порта А.
2) RCC->APB2RSTR->DBGMCURST = 0
3) RCC->APB2ENR->DBGMCUEN = 1 - включал вручную, так как по умолчанию был выключен
4) DBGMCU->CR = 6, изменение значения на работу не влияло

Вроде бы с SWD больше ничего не связано. Программирование остаётся всё равно только под ресетом.

[Eddy_Em]

А как насчет альтернативной функции? Что в GPIOA->AFR[1]? GPIOA->PUPDR? Посмотри в мануале табличку 25 в разделе 9.4.12 (GPIO register map and reset values).
И нет ли защиты?

[tonyk]

Программирование остаётся всё равно только под ресетом

Такое бывает, когда в коде меняется функция пина. Возможно, ты не всё нашёл.

[Up2805]

Serj_K, если вы прошиваете через ST-Link Utility, тогда в его настройках (Settings) переключите режим соединения на Hot Plug и режим сброса выберите Software System Reset (не обязательно). Потому что если назначение пинов PA13, PA14 не менялось, то подключение по SWD "на ходу" без сброса производится отправкой особой комбинации сигналов. Для этого программатор-отладчик должен быть переключен в соответствующий режим. IDE обычно самостоятельно это делает. Либо, если через IDE прошиваете, то в ее настройках проверьте подобный режим

[Serj_K]

Up2805, спасибо, с Software System Reset даже в нормальном режиме коннектится нормально. Теперь хоть прошивать можно без аппаратной кнопки сброса. Жаль, что BlackMagik пока не заработал. Если не заработает, придётся перенастраивать отладку под ST-Link, а он мне меньше нравится, так как не хавает китайские псевдо-стмки.
Вообще ситуация странная. Порт А был изначально настроен и отладка работала, а потом без перенастройки порта отладка отвалилась. Попробую разобраться в процессе работы.

[do-vitas]

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

тут еще кокой то прикол кайл мой почему-то не запускает прерывания таймера на котором энкодер, я че тока не делал и HAL и LL и CMSIS. Потом этот же проект компилирую под CUBIDE и там все заработало сразу не пойму раньше такого не было, я его недавно скачал с оф. сайта через vpn, может кто сталкивался?

[do-vitas]

Всем добра строи все свой бп на мк набросал уже почти программу осталось только настройка. Скажу несколько слов в защиту не любителей халакуба, пытался запустить обычный ацп на мк f373с применением библиотеки LL, на регулярном канале все быстро заработало а вот на ижекционном(прошу извинить за мой французский) ничего так и не заработало переписал инициализацию вручную и все очень быстро заработало. Так что самый большой плюс куба скорость в данном случае как то сильно пострадали, вот и выходит что лучше бы вручную все прописывал меньше времени ушло бы... Ну да бог с ним двигаемся дальше Спрошу тут, т.к. не знаю как разбить вопрос и отправить его часть в "питание". У меня будет вполне себе обычная схема БП коих на просторах интерната много т.к. 2 операционника управляют одним или более транзисторами, один отвечает за ток другой за напряжение. Вот только опорное напряжение будет формировать МК от поворота энкодера, это я уже все запрограммировал и сам себя МК меряет нормально, т.е. АЦП меряет выход ЦАП. Теперь вопрос стоит об измерение на выходе, думки у меня такие как обычно операционник и МК ну тоесть вариант 2, но тут мучают всякие нехорошие мысли у сигма-дельта АЦП можно вывести оба вывода в наружу и + и - а еще и можно включить усиление в 32 раза вот и думаю о варианте 1, но тут возникнет другая проблема как защитить выводы МК хватит ли этого коэф.... Что скажут знатоки?

[GARMIN]

Калибруй смещение при пуске, и всё будет ОК.

[jcxz]

[uquote="Serj_K",url="/forum/viewtopic.php?p=4245261#p4245261"]Пин BOOT0 сидит на земле, то есть используется запуск из прошивки флеш[/uquote]При отладке под эмулятором, лучше делать как раз наоборот. Чтобы предыдущее содержимое флеши никак не влияло на старт новой отладочной сессии.