Перейти к содержанию
    

jcxz

Свой
  • Постов

    13 724
  • Зарегистрирован

  • Посещение

  • Победитель дней

    38

jcxz стал победителем дня 23 августа

jcxz имел наиболее популярный контент!

Репутация

235 Очень хороший

4 Подписчика

Информация о jcxz

  • Звание
    Гуру
    Гуру
  • День рождения 01.12.1974

Контакты

  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

29 239 просмотров профиля
  1. WCH CH32F203 CAN

    Так может у вас REC или TEC достигает 127 и временно входит в это самое "error passive state"? Если попробовать помониторить их в каком-то периодическом (таймерном) прерывании? и поискать максимальные значения?
  2. Про что я и говорил: Мы ведь исходников ТС не видели. И не знаем - как он там описал этот самый uint8_t. uint8_t - это не встроенный тип си. А значит может быть описан как угодно. Например у DSP семейства C55xx (TI) нет команд байтового обращения к памяти. Минимум = 16 бит. Да и вся память там - не пространство байт, а пространство 16-битных слов. Значит - как бы вы не описывали там этот самый uint8_t, он будет работать или посредством 16-битных обращений к памяти; или посредством операций чтения-модификации-записи. И то и другое может вызывать проблемы в определённых случаях. А искать надо в описании системы команд. Также можно обратить внимание на размер char в вашем компиляторе. Скорее всего его размер будет равен минимально-возможной ширине доступа к памяти.
  3. А у DSP сколько бит? (минимальная разрядность обращения к памяти) Не "9-битные байты", а минимальная разрядность обращения к памяти.
  4. Вообще-то при таких вопросах следует указывать - о каком CPU идёт речь? В обязательном порядке. Меняет это то, что во многих DSP не существует нативного байтового типа. И если у вас такой DSP, то непонятно - как именно реализован ваш uint8_t? В зависимости от его реализации, на таких DSP операция "& 0xFF" может быть необходима. При кривой реализации uint8_t.
  5. Нету. "& 0xFF" не нужно. И скорее всего - ваш компилятор и так его выкидывает. Если не совсем уж глупый. Советую хоть иногда заглядывать в листинг. PS: У вас же не DSP наверняка.
  6. WCH CH32F203 CAN

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

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

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

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

    Например - для того, чтобы отдать 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-контроллера как штатный останов. И ничего нигде не залипает. Если конечно такое возможно в данном МК.
  11. Вполне возможно. Осталось лишь найти этот самый код для 0x08000000 и записать туда. Бут или что там должно быть.
  12. Я имел в виду ваш STLink, про который вы писали. Раз уж вы умеете им подключиться к устройству и залить прошивку, то дальше осталось сделать всего один простой шаг: Пошагать отладчиком по коду, начиная с самого начала программы и посмотреть - по каким адресам идёт шагание? Валидный ли там лежит код? (а не мусор) Те ли это адреса, что вы ожидаете? Также - адреса расположения кода можно легко увидеть, открыв .hex-файл любым текстовым редактором и прочитав глазами.
  13. Надо залить, а потом наконец - начать использовать ваш STLink по прямому назначению - как отладчик.
  14. Уже в 90-хх нормально синтезировали из текста. См. "Фонемафон". Вполне слушабельно получалось. И никакой особой "вычислительной базы для этого не требовалось. Насколько помню - на тогдашних i386 "Фонемафон" нормально работал. А на моём тогдашнем i486DX4-100MHz даже параллельный озвучке поиск слов по большому словарю успевал нормально работать. PS: Правда тогда программисты умели код писать гораздо оптимальнее нынешних кодеров. Может поэтому.....
×
×
  • Создать...