jcxz

Например - для того, чтобы отдать DMA-канал другой периферии. Не знаю как с этим обстоит дело в STM dimka76, но ведь во многих STM32 запросы периферии прибиты гвоздями к DMA-каналам. И нельзя перебросить запрос от конкретной периферии на произвольный DMA-канал. В моём 3D-принтере (на STM32F103) глупый китайский разработчик схемы посадил две быстрых периферии (UART и SPI) на такие номера, которые используют один и тот же DMA-канал. Поэтому никак не возможно пользоваться DMA одновременно. Также ещё бывает нужно положить МК в сон например. Выключив работу UART. Вы не поняли смысла той фразы. Та фраза требует, чтобы до запуска нового трансфера, статусные флаги от предыдущего трансфера были бы очищены. Потому как сами они не очищаются при останове и переразрешении DMA-канала. Иначе сами подумайте: как тогда работать с многоблочными трансферами? Как чистить флаги в них? Те же - TCIF и HTIF. И зачем тогда они нужны (TCIF и HTIF), если их нельзя очистить в процессе трансфера? Нормально флаги чистятся и при работающем трансфере. И устанавливаются потом при следующем событии. По флагам TCIF/HTIF мои драйвера определяют - какой именно буфер нужно обрабатывать в многоблочных трансферах на STM32. Стараюсь нигде (по возможности конечно) не выключать работающий DMA принудительно. Имхо - это плохое решение. Как-то я много накувыркался с одним проектом, где предыдущий разработчик делал такое принудительное выключение: И данные в FIFO DMA там застревали (и этого никак не видно и никак их не сбросить) и необслуженные DMA-запросы повисали и не сбрасывались, и потом приводили к сбою в следующем трансфере. Чтобы это всё корректно очистить, пришлось сделать множество дополнительных телодвижений в коде. Гораздо лучше (в случае многоблочного трансфера на link-list-передаче) делать останов трансфера выставлением стоп-условия в следующем блоке регистров управления, который лежит ещё в ОЗУ (или в неактивном (теневом) наборе регистров). Так останов трансфера выглядит для DMA-контроллера как штатный останов. И ничего нигде не залипает. Если конечно такое возможно в данном МК.

Вполне возможно. Осталось лишь найти этот самый код для 0x08000000 и записать туда. Бут или что там должно быть.

Я имел в виду ваш STLink, про который вы писали. Раз уж вы умеете им подключиться к устройству и залить прошивку, то дальше осталось сделать всего один простой шаг: Пошагать отладчиком по коду, начиная с самого начала программы и посмотреть - по каким адресам идёт шагание? Валидный ли там лежит код? (а не мусор) Те ли это адреса, что вы ожидаете? Также - адреса расположения кода можно легко увидеть, открыв .hex-файл любым текстовым редактором и прочитав глазами.

Надо залить, а потом наконец - начать использовать ваш STLink по прямому назначению - как отладчик.

Точно. Мне они не нужны. Я сам умею программировать.

Уже в 90-хх нормально синтезировали из текста. См. "Фонемафон". Вполне слушабельно получалось. И никакой особой "вычислительной базы для этого не требовалось. Насколько помню - на тогдашних i386 "Фонемафон" нормально работал. А на моём тогдашнем i486DX4-100MHz даже параллельный озвучке поиск слов по большому словарю успевал нормально работать. PS: Правда тогда программисты умели код писать гораздо оптимальнее нынешних кодеров. Может поэтому.....

Не знаю - поможет или нет, но ещё в дремучем 1999г. я писал читалку русского текста (голосом). Использовал для этого "СИНТЕЗАТОР РУССКОЙ РЕЧИ "ФОНЕМАФОН"" (который от "БелСИнт"). Который раздобыл где-то в виде COM-файла, со встроенным этим драйвером. Вырезал его оттуда, нашёл точки входа в функции и вклеил его в свою программу. (авторские права не нарушил, так как использовал только для личного пользования, никому не распространяя, и только для ознакомительных целей ) Он и в виде драйвера (включаемого в своё приложение) существовал (можно было не резать COM). Но добыть его самую свежую версию мне удалось только в виде COM-файла. Правда он на вход принимал не дифоны, а просто русский текст. Но смутно помню, что вроде в описании его говорилось, что внутри он текст преобразует в дифоны и затем озвучивает. "Фонемафон" озвучивал примерно с таким же качеством. Даже пожалуй лучше. Без таких артефактов на границах фраз. Полный вес его (насколько помню) - чуть менее 64КБ (как раз занимал почти полный сегмент x86 16-bit real mode). И качество можно было сильно улучшить, расставив в тексте ударения в словах. Даже скажу больше: бОльшая часть сложности моей читалки как раз заключалась во включённом в неё словаре слов и процедуре быстрого поиска по словарю (для расстановки ударений). Результирующий звук получался уже вполне приемлемым: Потом я не одну книгу прослушал этой своей читалкой. При точной расстановке ударений, результат получался почти такой же, как у современных озвучивателей русского текста. Без ударений текст звучал не очень - просто монотонный поток звуков. Может быть сейчас уже возможно найти исходники этого "Фонемафона" (или его наследников). И скомпилить их на ARM. А может даже запустить код x86 в режиме эмуляции на современном мощном ARM-е будет достаточно. Ведь тот старый, выполнялся даже на слабеньких компах 90-хх годов. PS: Вот нашёл в сети инфу по "Фонемафону": https://tiflohelp.ru/category/synthesizers Как раз пишут, что дизассемблировали Фонемафон. Тоже хакали Правда - какой-то 4-й. У меня вроде ещё без номера был.

А если хоть немного подумать?? Вроде как очевидно всё. Сделайте кольцевой буфер из фоток. Шириной = ширина экранного окна + ширина максимальной фотки. И двигайте попиксельно. Добавляя новую фотку справа, когда старая полностью вошла в экран.

Всё то же самое, только экранную плоскость шириной = сумме картинок. И копировать оттуда в экранный контекст окно размером в экран, постепенно его сдвигая.

Очевидно: Создать в памяти DC. Совместимый с экранным форматом и таким же размером, как экранное окно. Загрузить изображение в него один раз. А потом уже из него копировать в экранное ОЗУ, сдвигая на пиксель, сколько нужно раз.

Не выйдет "по ретурну". Деление на 0 как правило на большинстве систем вызывает исключение "деление на 0". На ARM - это соответствующий fault. Если не отключен конечно преднамеренно системным программистом. А если к тому же не сделана дифференциация по fault-ам, то будет эскалация до HF. Со всеми вытекающими. До "после ретурна" дело вообще не дойдёт.

Он вас не убеждал, что и вам JTAG не нужен? Потому как он то без него обходится. А меня - упорно убеждал в этом. "Выкидывай свой STM32. Бери ESP32! И фиг с ним, что там и JTAG-а нет нормального и периферии нужной и доступа к ней через регистры (если используется некая готовая закрытая "либа" для WiFi), да и даже - просто банально ног на все функции не хватает. Всё равно - бери ESP32 и кувыркайся как хошь."

Зачем вы подключили у себя TX если ничего не шлёте??? Вы это кого спрашиваете? Откуда-ж кто здесь это может знать - зачем вы это сделали? Тем - более - на неизвестном никому кроме вас датчике. PS: Вы - не шлёте, другие - шлют. Вдруг - завтра вы тоже захотите? Или насяльника прикажет слать?

А в этом фрагменте: int n_biases_hid; if(sscanf(pt, "%d", &n_biases_hid) != 1) { return false; } ... *pNOut = n_biases_out; *pNHid = n_biases_hid; *pNInp = n_inp_hid / n_biases_hid; Будет fault, если sscanf() введёт 0. Ведь никакой проверки на этот случай нет. Типичный говнокод.

Не "отфильтровать", а "разобрать все". Выбрав потом из результата нужную инфу.