jcxz

Если собираетесь писать/отлаживать новую прошивку, то проще будет подыскать какой-то современный МК, совместимый (хотя-бы частично) по ногам с вашим и впаять вместо. И со средствами отладки тогда проблем не будет и флешка внешняя не нужна и ресурсов намного больше. Зачем его туда переводить? Он же вроде как раньше и грузился с внешней флешки. Значит уже переведён. Не понимаю - как вы умудрились "не найти" там мануала на этот МК??? Заходим: https://www.infineon.com/cms/en/product/microcontroller/legacy-microcontroller/legacy-8-bit-16-bit-microcontroller/c166-family/c164ci-c164cl-c164si/ качаем самый главный документ - юзер-мануал и сразу в нём находим раздел про загрузку: "15 The Bootstrap Loader The built-in bootstrap loader of the C164 provides a mechanism to load the startup program, which is executed after reset, via the serial interface. In this case no external memory or an internal ROM/OTP/Flash is required for the initialization code starting at location 00’0000H. The bootstrap loader moves code/data into the internal RAM, but it is also possible to transfer data via the serial interface into an external RAM using a second level loader routine. ROM memory (internal or external) is not necessary. ..." Как подключить - всё описано, протокол - тоже описан. Находится в пару кликов. PS: Про отладчики в мануале тоже есть.

Наверно нужно объяснять - что такое "firmware lib" и где она находится? И какой TCP-стек используете? (или не используете никакой и работаете без TCP?) Чтобы народ понимал о чём речь. Телепатов на нашем форуме отродясь не водилось. Например в моём TCP-стеке никакой "функции loopback" нету ни на каком уровне. И не знаю - зачем она вообще нужна? ЗЫ: С МК GD не работал, по их периферии подсказать не могу. Но слышал, что вроде как GDxx по периферии очень похожи на соответствующие STM. Поэтому - раз описания нужных регистров нет в мануале GD32F107, то может стоит заглянуть в мануал STM32F107? Глянул мельком в мануал GD32F107 - вижу, что регистры для отладки там имеются (всякого рода регистры-счётчики). Каких регистров вам ещё не хватает?

Где "не сходятся"? В "DSView_v1.2.0_x64_setup.exe"? А инсталлятор-то тут причём??? Вроде из элементарной логики следует, что правка касается самой программы, а не её инсталлятора. Да и в моём сообщении чётко указан "DSView.exe".

Думаю - нужно автоматически удалять сообщения, состоящие из одной вставленной картинки. Без осмысленного текста. А также - сообщения, сгенерённые явно ботами. В сети полно ресурсов, где этим можно заниматься. Не нужно превращать наш форум в одну из таких помоек. Когда у вас засоряется толчок, вы же не идёте сюда, и не создаёте тему со скриншотом инструкции к вантузу? Наверняка вы идёте на форум сантехников. В самом запущенном случае.

Так ведь прыщавому Давиду не подадут здешние дядечки. Вот он и мимикрирует, ориентируясь на целевую аудиторию. И их уже прям табун этих Давидов сюда ломанулся в последние дни. К чему бы это? RTC у бота что-ль слетело?

Не могла бы. Т.к. это не поисковый бот, а копипастный. Функция поиска не реализована. Да и на кой искать, если всегда найдётся желающий найти за леру?

Т.е. - предлагаете вместо паразитной запитки ведомого микроскопическими токами через подтяжки, запитать его полноценным паразитным током с открытых нижних ключей SCL/SDA мастера (и других ведомых)? Т.е. - не только ведомого паразитно запитать, но ещё и завалить обмен с другими ведомыми? В случае редких транзакций. "Отличное" решение! Для корректного отключения ведомого в случае ТС, можно использовать: либо аналоговые коммутаторы; либо гальванические изоляторы (как уже предлагалось выше); либо даже есть спец.микросхемы для этого (не помню конкретных наименований). Ну или (эконом-вариант): Не выключать ведомого, а уводить его в сон. По команде мастера например. Если такое возможно по условиям всей системы. С предварительным отключением ведомым своих SCL/SDA и прочей ненужной требухи.

Так может у вас REC или TEC достигает 127 и временно входит в это самое "error passive state"? Если попробовать помониторить их в каком-то периодическом (таймерном) прерывании? и поискать максимальные значения?

Про что я и говорил: Мы ведь исходников ТС не видели. И не знаем - как он там описал этот самый uint8_t. uint8_t - это не встроенный тип си. А значит может быть описан как угодно. Например у DSP семейства C55xx (TI) нет команд байтового обращения к памяти. Минимум = 16 бит. Да и вся память там - не пространство байт, а пространство 16-битных слов. Значит - как бы вы не описывали там этот самый uint8_t, он будет работать или посредством 16-битных обращений к памяти; или посредством операций чтения-модификации-записи. И то и другое может вызывать проблемы в определённых случаях. А искать надо в описании системы команд. Также можно обратить внимание на размер char в вашем компиляторе. Скорее всего его размер будет равен минимально-возможной ширине доступа к памяти.

А у DSP сколько бит? (минимальная разрядность обращения к памяти) Не "9-битные байты", а минимальная разрядность обращения к памяти.

Вообще-то при таких вопросах следует указывать - о каком CPU идёт речь? В обязательном порядке. Меняет это то, что во многих DSP не существует нативного байтового типа. И если у вас такой DSP, то непонятно - как именно реализован ваш uint8_t? В зависимости от его реализации, на таких DSP операция "& 0xFF" может быть необходима. При кривой реализации uint8_t.

Нету. "& 0xFF" не нужно. И скорее всего - ваш компилятор и так его выкидывает. Если не совсем уж глупый. Советую хоть иногда заглядывать в листинг. PS: У вас же не DSP наверняка.

Счётчики ошибок могут быть в МК. Локальные. Я не знаю CAN в STM32 (и тем паче - в китайцах), но в XMC4xxx в позапрошлом проекте у меня была похожая проблема: Из-за некорректной схемы подключения CAN-драйвера (чип) к МК (не было подтяжки цепей управления вроде), в моменты вкл. и выкл.питания устройства, этот драйвер впадал в ступор фиксировал на своих выходах доминантное состояние на ~0.6 сек. И на всех остальных участниках шины из-за этого в этот момент быстро инкрементировались счётчики ошибок. А реакция на достижение локальным счётчиком ошибок в МК некоего предела, может быть - не обязательно выставление на шину состояния ошибки. Состояние ошибки может быть выставлено локально, внутри данного конкретного МК. И он отключится от транзакций по шине. При этом - у других участников шины, счётчики ошибок могут и не достичь максимума, и они продолжат работу. И снаружи это будет выглядеть как: "все девайсы работают, а один почему-то не видит обмена по шине и сам туда ничего не выдаёт". А если ещё у вас в устройствах реализован периодический сброс этих счётчиков, то поведение разных девайсов может быть вообще очень сложным и труднопрогнозируемым. Не понял - причём тут errata? PS: да, кстати - отваливаться по накопленным ошибкам может не только ваш девайс, но и тот USB-CAN-свисток, которым мониторите обмен. (если вы конечно через USB-CAN мониторите).

Может в процессе вкл.питания какая-то из сторон отправляет сбойные CAN-кадры? Счётчик ошибок CAN достигает максимума и на одном из участников CAN шина переходит в состояние bus-off. Которое позже где-то сбрасывается. Это как версия. Вобщем - я бы проверил состояние счётчиков ошибок во время этих самых "первых 16 пакетов".

Вот интересно: Почему китайские авторы (и авторки), которые тут что-то продают, чаще всего берут никами русские имена? Не первый раз уже замечаю... Почему не что-то китайское? PS: Просто интересно. Ничего не имею против....

У вас некорректно построен весь алгоритм работы по UART. Вы смешали все уровни протокола обмена - от самого нижнего до самого верха. Корректно построенная архитектура работы с UART должна отделять уровень потока байт по UART (на ввод и на вывод) от протокольной обработки этого потока байт. Вот об этом (имхо) как раз и говорил Arlleex, советуя непрерывный режим работы DMA с UART. При непрерывном потоке (организуемом linked-list режимом DMA или режимом простой двойной буферизации DMA), входящий поток байт пишется в буферы памяти непрерывно. И уже затем - для очередной порции принятых в эти буферы байт данных, вызывается протокольный обработчик. Или он вызывается в случае паузы в потоке + наличия любого кол-ва необработанных байт в буфере DMA. Такая архитектура позволит использовать один и тот же драйвер нижнего уровня (UART-DMA) для любого протокола обмена, не переписывая его из проекта в проект. Переписывается только драйвер протокольной обработки. А нижний уровень - неизменен. Да и в пределах одного проекта можно организовать работы по одному каналу связи (UART) по разным протоколам обмена. Также - будет легко переносить проект на другой МК. С сильно отличающейся периферией. Просто надо будет переписать драйвер нижнего уровня. Не меняя процедуры протокольной обработки. А когда все уровни протокола перемешаны, будут большие сложности.

Например - для того, чтобы отдать 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-й. У меня вроде ещё без номера был.

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

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