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

linuxbergi

Участник
  • Постов

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

  • Посещение

Репутация

0 Обычный

Старые поля

  • Vkontakte
    Array

Контакты

  • Сайт
    Array
  • ICQ
    Array

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

476 просмотров профиля
  • pokk

  1. За информацию и отклики благодарен всем, рискну выложить схему реализации, может кто-нибудь ещё подкинет идей. В цикле мониторятся флаги событий. GLOBAL_SM - мониторит RESET, SUSPEND и пр. Группа TRN_SM собирает из отдельных транзакций запросы управления, мониторит флаги транзакций передач управления. После транзакции setup, выполняется парсинг пакета конфигурации (выделено голубым), остальные секции не реагируют, состояние автомата фиксируется в глобальных переменных. По транзакции IN выполняется соответственная секция кода, состояние фиксируется в гл. переменных. Транзакция setup общая для всех передач управления, а дальнейшая реализация зависит от парсинга конфигурационного пакета из этой самой транзакции setup. В секции setup устанавливается указатель на функцию реализующую конкретный запрос и далее эта функция вызывается каждый раз при выполнении последующих транзакций пока запрос не закончится выполняться. Думаю схема ясна. Обработчик транзакций передачи данных прост, по сравнению с управляющими, поэтому пока не рассматривается
  2. В своё время интересовался USB , даже опубликовал результат своих изысканий https://yadi.sk/i/kQfoeUJ8iicDi Чем плохи доки по стандартам? Они объективно очень громоздки в силу их специфики, там предусматриваются все варианты событий, какие только возможны. Например если смотреть стандарт по HID, то умопомрачительно, а кто знает, что такое custom hid (наиболее используемый на практике), тот рассмеётся. На практике можно многое отбросить, скостить углы. Основу моего проекта составляют идеи предоставленные здесь: http://mcu.goodboard.ru/viewtopic.php?id=40 Может модератор не удалит сей ценный материал?
  3. И ещё вопрос для специалистов. Могут ли быть вложенными управляющие передачи? Например, началась передача setup и не завершая её хост начинает новую? Из разных источников разные ответы, по-моему полная ерунда. То что хост может внезапно закончить начатаю передачу, это знаю. А вот вложенные передачи? Тогда нужно складывать контекст. Да и какой максимальный уровень вложенности? В "USB complete" написано что вроде как могут быть вложенные.
  4. Премного благодарен! Многая лета. В книге 'Making Embedded systems' описывается шаблон программирования МК под названием 'драйвер', ну это так. Залез в USB-FS-Device_Lib_V4 и ужаснулся, мрачное нагромождение файлов и не понятно по какому принципу. Меня интересовало как можно подойти к проблеме. Общая схема, два конечных автомата, один автомат отвечает за переходы между состояниями USB устройства, а второй за сборку управляющих запросов из отдельных транзакций. После сборки сообщения , передаётся первому автомату и служит событием, которое может изменить его состояние. Когда смоделировать поведение устройства оказывается затруднительным одним автоматом, то оказывается просто смоделировать несколькими конечными автоматами, взаимодействующими друг с другом передачей сообщений. Но при ближайшем рассмотрении выяснилось, что обработку управляющих запросов от хоста невозможно представить одним конечным автоматом. Схема сложней. После выполнения транзакции SETUP нужно раскодировать конфигурационный пакет. По результатам расшифровки выбирается один из некоторого множества конечных автоматов, отражающий запрос. Ниже граф переходов для запроса GET_DESCRIPTOR c несколькими стадиями данных. Транзакции выполняются аппаратурой автоматически, по результатам выполнения выставляют флаги. Хост инициирует тр. setup, из сост. I переходит в S, готовит буфер USB для следующей транзакции от хоста и т.д.
  5. Работаю над собственным драйвером для USB в STM32 , что-то мало материала. 99 % как скомпилировать готовый пример. Кто занимался аналогичной задачей? В принципе значительная часть уже сделана.
  6. Сменить контроллер - это всё равно, что изучить новый язык, читал в одной книге. Даже если неплохо знаешь два, то переключаться между темами затратно, производительность падает. Вообще в такие долгоживущие системы, нужно закладывать стандарты, известные протоколы, а не хорошо документированный код и не оригинальные находки. И нужно смотреть по уровням. Уровень транспортных пакетов, уровень прикладных сообщений. В самом подходе к реализации чувствуется непрофессионализм. Задача раскладывается на 2 уровня, уровень системы и уровень блоков. Один специалист работает на уровне системы и формирует задания для специалистов блоков. Задача специалистам блоков должна ставиться так, что бы они могли выполнять работу не вникая в особенности реализации всей системы. Конечно управляющее ядро должно разрабатываться специалистом, знающим задачи системы целиком. Первое, нужно позаботиться о создании стендовых заглушек, подключая к которым можно было бы в живую отлаживать блоки, независимо и параллельно. Да и разаработчику управляющей программы нужен имитатор объекта управления. Хотя всё зависит от сложности объекта управления. Физик должен сформулировать задачу в технических терминах не затрагивая вопросов реализации.
  7. Бросается в глаза необоснованная неоднородность системы. Шина I2C не совсем подходит, ограничена пропускная способность, да и помехозащищённость не очень, в лабораторных условиях нужна промышленная сеть, может CAN. Остановиться на каком-нибудь современном контроллере, сделать типовую плату(или лучше купить), наваять типовую библиотеку для коммуникаций. Ну и внешние схемы для съёма сигналов с датчиков. Такую как представлена, затратно реализовывать, отлаживать и развивать.
  8. Вы адаптировали SimpliciTi для Cortex-M3? То же думал попробовать. Но если строго, то SimpliciTi разрешают использовать бесплатно только для TI МК.
  9. А как тогда измерять амплитуду синуса?
  10. А фильтр восстановления? Если частота меняется, то и полоса пропускания фильтра должна меняться?
  11. Что-то я не понял. Зачем SRAM? Пиши в свободную флэш из программы, там имеется контроллер внутренней флэш, у него регисты флаги, записывай читай.
  12. Timer в STM32 может одновременно генерировать сигнал и измерять частоту. Один канал настраиваете на генерирование, а на другой канал поступают импульсы для измерения пропущенные через RC цепочку. Импульсы пропускаете через RC цепочку, через триггер Шмидта и измеряете длительность импульса. Вообще вариантов может быть много.
×
×
  • Создать...