Chaosorg пишет: Не определился потому что много соблазнов и потому, что заинтересовался пониманием того, какая аппаратная поддержка нужна AVR, чтобы хватало даже его. И это больше будет соответствовать стилю работы с ПЛИС - разгружать проц специализированным железом, достигая недостижимых для софта скоростей.
Идею понял - вполне достойная и востребованная идея. Жаль, что цели у нас разные. Но наверное до какого-то уровня можно использовать общие вещи.
Конечно, я бы не отказался от какого-то более умного и быстрого устройства, которое умеет DMA передачу и всё работу по управлению пакетами берёт на себя, но если бы у Марсохода2 было бы чуть больше логических элементов...
Второй соблазн - чужие исходники. Раз стандарт USB не нами с Вами создан и есть исходники реализующие его софтом с какой-то минимальной аппаратной поддержкой, то зачем велосипедить в плохом смысле этого слова? Мне кажется, что USB даже по стилю индустриальный, а не академический. Ваш интерес мне, вроде как, понятен, но я не совсем понял как далеко Вы удалились от мира готового ПО, хотя Вам достаточно всего несколько команд добавить к какой-нить существующей системе для поддержки парадигмы обмена сообщениями.
От готового ПО я удалился на расстояние стадарта POSIX - всё что выше - пусть живёт, всё что ниже - переписать. Включая железо :)
Если серьёзно, то изначально и была идея добавить несколько инструкций к какой-нибудь существующей SoC. Чем глубже "рылся" в проектах процессоров на
opencores.org
, попутно изучая Verilog, тем меньше все эти проекты нравились. А потом показалось что можно сделать интереснее.
Это, опять же, если замахиваться на 32битный, но компактный проц. Вам же USB нужен не просто так - какие задачи будут потом? 16 бит хватит (это я с учетом предложенной Вами ссылки на 16битный, вроде как, проект)?
Вроде бы он 32-х битный, если не ошибаюсь. Хотя, автор проекта тоже может читать эту тему - может быть пояснит.
Мой процесссор в некотором роде тоже компактный:
Total logic elements 6,710 / 10,320 ( 65 % )
Total combinational functions 5,750 / 10,320 ( 56 % )
Dedicated logic registers 2,404 / 10,320 ( 23 % )
Total pins 45 / 95 ( 47 % )
Total virtual pins 0
Total memory bits 190,464 / 423,936 ( 45 % )
Embedded Multiplier 9-bit elements 0 / 46 ( 0 % )
Total PLLs 0 / 2 ( 0 % )
Но, к сожалению, для сколь-нибудь серьёзных применений он пока не готов. :(
Ну а проект USB трекера потому и работает, что он лишь слушает чужую, не им организованную физику процесса передачи данных. Он и не приемник и не передатчик. Поэтому и без отвечающих за физику элементов.
После Вашего ответа почитал подробнее про USB и полазил по схемам Марсоход2. Таки есть резисторы. Номиналы точно соответствуют спецификации. Просто они стоят не на плате расширения, а на самом Марсоходе2 четыре штуки - R73, R74 для одного порта и R77, R78 для второго. Смотрел по вот этой схеме -
marsohod.org/downloads/category/21?download=120
Таки у Марсохода2 всё в порядке на этом фронте.
Насколько я понял, чтобы определить максимальную скорость USB устройства, USB-хост каким-то образом детектирует "speed identification resistor", но у Марсохода2 нет такой схемы, чтобы определить наличие резистора. Но это не должно быть проблемой, поскольку любое устройство должно уметь работать на low speed, а там уже можно "напрямую спросить" устройство о поддерживаемых скоростях. Как-то так.
А вот дальше - засада. В проекте анализатора есть код приёмника и, судя по всему, он вполне рабочий - может принимать по байту. А вот кода передатчика нет. Вероятно, основательно переделав код приёмника , можно соорудить передатчик, который сможет передавть по одному байту (по аналогии с приёмником). NRZI-кодирование и bit stuffing не так уж и сложно реализовать. Однако, тут возникают сомнения, что можно программно
побайтно передавать USB пакеты - временные интервалы между байтами будут нарушены и синхронизация сорвётся - т.е. передаваемый USB пакет надо каким-то образом заранее формировать в памяти, а передавать его уже должен контроллер. И контрольные суммы надо бы считать аппаратно.
В общем, на мой взгляд, основная проблема заключается в реализации механизма взаимодействия процессора и USB-контроллера. Впоследствии все операции, типа согласования протокола и поддержки различных режимов работы, можно переложить на железо, но для начала вполне подошла бы возможность формирования пакета "извне", т.е с помощью процессора.
Часть сообщения скрыта для гостей. Пожалуйста, авторизуйтесь или зарегистрируйтесь, чтобы увидеть его.
