Здравсвуйте,
Я Хочю Собрать full sped USB Sniffer на STM32f407
Кто Может мне помочь в этом деле????
Буду благодарен за любой помощь

А че не на плиске?

вообще с плис не знаком

Я немножко подумал над алгоритмом работы, думаю подавать сигнал на сдвиговый регистр(8 или 16 битный) а выходы подать на целый порт МК, при таком подходе получается что считать информацию нужно на более низкой скорости. Но вот тут для меня есть один не решенный , когда считывать порт? Задействовать таймер и считать до 8 или 16 клоков от 12мгц и считать? Успеет ли МК ? Не потеряется ли бит?

А зачем огород городить, если у МК и так есть сдвиговые регистры в виде модулей SPI?

Я новичок в этом деле...
Что Вы имеете ввиду?
Использовать приёмник буфера SPI как сдвиговый регистр?

У меня немножко со временем скудно...
Если есть кот реально может помочь , конечно же не за спасибо, пишите на мейл или в личку.

Вообще, это хороший повод ознакомиться и приобрести полезные навыки.


Это и есть сдвиговый регистр. Можете принимать поток данных с частотой 42МГц, и сразу складывать через DMA в память для последующего анализа. Для настольной конструкции можно и до 48МГц разогнать.


Если со временем скудно, то это совсем не та задача, за которую стоит браться. На МК подобный прибор можно делать только из любви к искусству в свободное время.

Делал такое на ПЛИС, Spartan-II. Плюс ПО, которое отображало информацию, полученную сниффером, на экране. Как такой сниффер сделать на МК - представляю с большим трудом ...

Высший пилотаж - это когда через 5-6 периодов 12 МГц (бит) после DataX пакета процессор успеет ответить ACK сверив CRC. Но это чуть больше чем сниффер. Это софтовый USB.

Спасибо за ответы.
В данном случаи у меня под рукой просто есть такой МК, вот и решил что на нём получится.... Главная задача это просто сделать такой прибор , хоть на ПЛИС хоть на МК.
Если есть люди которые возьмутся за софт , то буду рад, повторюсь-на за спасибо.
Пишите на мейл, договоримся.

Перехват и отображение одиночных пакетов думаю возможно так сделать.
Но человек, который сможет это сделать, не станет спрашивать как это сделать, или как использовать SPI.

ЗЫ: Начинать надо с моргания светодиодами, имхо.

Я семплировал шину с частотой 96 МГц и отсчеты записывал в BlockRAM в режиме "магнитофона". А уже потом эту запись выводил в ПК и там отображал. Т.е., сам сниффер ничего о пакетах не знал, а просто брал отсчеты с шины.
Задача эта гораздо лучше решается именно на ПЛИС, ИМХО. Но начинать, как вы правильно сказали, надо не с нее, а с мигания светодиодом ...

Светодиодами моргал, давно....
Я не знаком с этой темой(USB sniffer),только начал изучать, не работал вообще по этой области, нужно многое изучить, выходит что и с ПЛИС-ами нужно знакомится, а это займёт мнооооого времени, вот и решил обратится к более опытным людям за помощью.

Господа, наверное я не правильно сформулировал вопрос.
Кто возьмётся за софт USB full speed сниффера? На чём угодно, не имеет значения
О подробностей договоримся по мейлу.

Тут рядом есть раздел с предложениями работы, попробуйте поместить свой вопрос там.
И еще, я так и не понял, вы именно на МК хотите делать сниффер ? Если бы вам нужен был пример сниффера, я бы порылся в своих исходниках и вам бы его прислал, но для ПЛИС ...

kovigor , можно связаться с вами по мейлу?

Пожалуйста,
kovigor@yahoo.com

А EOP как ловить?

Взять второй SPI.

Отъест слишком много ресурсов ЯДРА.
Можно предложить на SPI подать D+, а EOP ловить логикой вроде 2ИЛИ с небольшим(и) RC-фильтром, поданным на вход INT процессора. EOP будет виден как строб шириной пару бит в конце пакета (сплошные еденицы). А прерывание обратит на это место внимание ядра. Хотя между Out токеном и DataX пакетом бывает всего пару бит состояния Idle. Тут разобраться будет сложнее.

Я не совсем понимаю, зачем все это, если гораздо проще использовать ПЛИС ?

Спортивный интерес программистов.

Да и ТС предложил пофантазировать на нестандартную тему.

На обработке? Не отъест: всего-то сложить по OR два числа и проверить, все ли единицы.


Во-первых, это подразумевает разбор на лету; во-вторых, "это место" получится слишком уж неопределенным из-за латентности прерывания. Тогда уж таймером захватывать.

Кто обещал?


На arm.com все расписано. Недавно обсуждалось.

Реклама разработчиков. Но в STM могут быть любые неожиданности. Сам проверял с обработчиком во внутренней RAM и джиттера не наблюдал. С точностью до такта.

На 168 МГц два бита EOP выльются в 28 тактов свободы. Джиттер готовности SPI будет сравнимый (на 42 МГц), если SPI байтовый. Так что не надо сгущать краски. OR двух байт тоже быстро, согласен. Если не будет проблем с вычитыванием двух SPI.

-----
По недоразумению мой предыдущий пост удалили. Восстанавливаю.

Какую латентность? На заявленном процессоре и на остальных Кортексах обещали нулевой джиттер. Но читая мануалы NXP почти нигде не указано сколько задержка в тактах.

Только не байт, а слова - у нас же 32 битный процессор, зачем по мелочам размениваться? А считывать будет DMA.


Тем не менее, время входа зависит от прерываемого кода. Даже когда все выполняется из RAM. И ST/NXP тут ни при чем, ядро так себя ведет.

Не очень понял из той ветки: что нужно сделать чтобы это увидеть? Какой код?

ЗЫ
Проверял не с одним обработчиком в раме, а и основной программой тоже, вместе с таблицей векторов.


У NXP SPI/SSP максимум 16 бит. Если у STM 32, то круто.

Прибавляется такт при прерывании bit-band операций и инструкций с невыровненным доступом.


Я данные предлагал сложить в RAM при помощи DMA. Далее уже оперировать 32 битными словами.

А на CM0 джиттера нет?

Всё перечисленное легко избегаемо даже в Си-коде. И пугать тактом задержки на фоне EOP равного 28 тактам это как минимум странно.

Еще джиттер создают late arrival и pop pre-emption, если прерывание не одно.


Только в особом режиме:



Странно, по-моему, пытаться разбирать поток на лету. Реальные задержки будут далеко не в один такт.

Прерывание должно было "метку поставить", например, по текущему адресу из DMA, что там (+-байт) находится EOP. Шириной, грубо, тоже в байт. При этом не используя второй SPI. Ничего странного в этом нет.

На лету делают разбор даже на AVR. Пример тому V-USB. Умножив ресурсоёмкость на 8 (FS/LS) получим сравнимую тактовую в 160 МГц.

В качестве продолжения фантазий, могу предложить вариант без ПЛИС, но с реализацией, подобной описанной kovigor - простой рекордер с внешним парсером:
Частотой 96МГц тактируем два сдвиговых регистра на которые поступают сигналы D+/D-. Через N тактов содержимое регистров считывает CY7C68013A и накопив пакет шлёт его в хост.
На CY7C68013A построено много многоканальных логических анализаторов. Здесь примерно то же самое, но с предварительным десериализатором.

Кстати - а почему 96МГц? Может меньше?

Думаю, и 48 было бы достаточно ...

Думаю - топикстартеру использовать CY7C68013A гораздо проще чем осваивать ПЛИС. Всё практически сведётся к написанию ПО под винду.
ПЛИС имеет смысл использовать только если на ней-же делать какую-то обработку.

Зависит от каких микробов хочется там увидеть. Может и гигагерца не хватить. Особенно если кошки там нет

Если и искать микробов, то в акцентах. USB с ...им акцентом. В смысле, что скрытую информацию можно передавать 1000 и 1 способом.

FUI, недавно saleae выкатили новый софт, парсит usb LS и FS. Софт работает с китайским железом за 5-10$