USB slave
Многие компьютеры умеют загружаться с USB. Если бы можно было не записывать загрузочный образ на flash-диск, а передавать его прямо с одного компьютера на другой, это позволило бы ускорить процедуру инсталляции операционной системы на компьютер, особенно для тех систем, которые не поддерживают инсталляцию по PXE. LiveCD тоже можно было бы загружать без записи на диск.
Теоретически, это можно было бы сделать, если соединить два компьютера при помощи host-to-host-кабеля USB, такого как тот, что используется при поднятии сети usbnet.
Похоже, что сейчас нет софта, который позволяет это сделать, но (опять же, теоретически), его можно было бы смастерить на основе кода usbnet и прочего кода usb-gadget.
Пример использования g_file_storage из usb-gadget:
Можно указать ещё опцию removable=y, тогда файл backing_file можно менять через sysfs-интерфейс.
Если есть поддержка USB-slave, то всё работает. Но в том-то всё и дело, что в обычных компьютерах её нет!
Например, для телефона Nokia N900, такое организовать очень просто.
Ниже описывается пример использования, в котором мы создаём загрузочный файл, который телефон отдаёт как загрузочное устроство. Понятно, что в данном случае быстрее было бы использовать обычную флэшку, но здесь важно то, что загрузка выполняется с файла, который лежит на устройстве. И на его месте могло быть всё, что угодно (образ диска с другого компьютера, iSCSI-устройство, образ виртуального диска машины или что-нибудь ещё).
[править] Пример подготовки загрузочного файла для эскпорта по USB
Ключевая часть. Отдаём файл как блочное устройство для компьютера [1] :
После выполнения последней команды на компьютере, к которому подключён телефон, увидится новое блочное устройство (usb-storage). Допустим, /dev/sdb .
Проинциализируем на нём таблицу разделов, отформатируем и проинсталлируем загрузчик:
Устанавливаем загрузчик grub4dos, который умеет выполнять загрузку с ISO-образов:
Что такое usb slave
Поддержка eCos USB slave позволяет разработчикам производить периферийные устройства USB. Он состоит из нескольких различных пакетов eCos:
Драйверы устройств для конкретных реализаций ведомого USB-оборудования, например, встроенного контроллера USB-устройств, предоставляемого процессором Intel SA1110. Типичное периферийное USB-устройство предоставляет только один подчиненный USB-порт, поэтому потребуется только один такой пакет драйверов устройств. Обычно пакет драйвера устройства загружается автоматически при создании конфигурации eCos для целевого оборудования, имеющего ведомое устройство USB. Если вы выберете цель, которая имеет ведомое USB-устройство, но драйвер USB-устройства не загружен, это означает, что такой драйвер устройства в настоящее время недоступен.
Общий пакет подчиненного устройства USB. Это служит двум целям. Он определяет API, который должны реализовать определенные драйверы устройств. Он также предоставляет различные утилиты, которые потребуются большинству драйверов и приложений USB-устройств, например, обработчики стандартных управляющих сообщений. Обычно этот пакет загружается автоматически одновременно с драйвером USB-устройства.
Общий пакет USB. Это просто предоставляет некоторую информацию, общую как для хоста, так и для подчиненной стороны USB, например, детали протокола управления. Он также используется для надлежащего размещения других пакетов, связанных с USB, в общей иерархии конфигурации. Обычно этот пакет загружается одновременно с драйвером USB-устройства.
Пакеты поддержки USB для конкретных классов. Это упрощает разработку определенных классов периферийных устройств USB, таких как устройства USB-Ethernet. Если для данного класса периферийных устройств нет подходящего пакета, вместо этого можно получить доступ к драйверу USB-устройства непосредственно из кода приложения. Такие пакеты никогда не будут загружаться автоматически, поскольку система конфигурации не имеет возможности узнать, какой класс периферийных устройств USB разрабатывается. Вместо этого разработчики должны явно добавить соответствующий пакет или пакеты.
Эти пакеты поддерживают только разработку периферийных устройств USB, но не хостов USB.
Концепции USB
Информацию о USB можно получить из ряда источников, включая веб-сайт Форума разработчиков USB. Здесь представлено только краткое описание.
Сеть USB асимметрична: она состоит из одного хоста, одного или нескольких подчиненных устройств и, возможно, некоторого количества промежуточных концентраторов. Сторона хоста значительно сложнее, чем сторона ведомого. По сути, все операции инициируются хостом. Например, если хосту необходимо получить некоторые данные от определенного периферийного устройства USB, он отправит токен IN этому периферийному устройству; последний должен ответить либо NAK, либо соответствующими данными. Точно так же, когда хост хочет передать данные на периферийное устройство, он отправляет токен OUT, за которым следуют данные; периферийное устройство вернет NAK, если оно в настоящее время не может получить больше данных или если произошло повреждение, в противном случае оно вернет ACK. Все передачи проходят контрольную сумму, и существует четко определенный процесс устранения ошибок. Периферийные устройства USB могут взаимодействовать только с хостом, но не друг с другом.
USB поддерживает четыре различных типа обмена данными: управляющие сообщения, прерывающие передачи, изохронные передачи и массовые передачи. Управляющие сообщения далее подразделяются на четыре категории: стандартные, классовые, поставщика и зарезервированная категория. Все периферийные устройства USB должны отвечать на определенные стандартные управляющие сообщения, и обычно это будет обрабатываться общим пакетом подчиненных устройств USB (для сложных периферийных устройств потребуется поддержка приложений). Управляющие сообщения класса и поставщика могут обрабатываться пакетом поддержки USB для конкретного класса, например, пакет USB-ethernet будет обрабатывать управляющие сообщения, такие как получение MAC-адреса или включение/отключение неразборчивого режима. Кроме того, некоторые или все эти сообщения должны обрабатываться кодом приложения.
Прерывание передачи используется для устройств, которые необходимо регулярно опрашивать. Например, USB-клавиатура может опрашиваться каждую миллисекунду. Хост не будет опрашивать устройство чаще, поэтому прерывание передачи лучше всего подходит для периферийных устройств, которые используют относительно небольшой объем данных. Изохронные передачи предназначены для периферийных устройств, связанных с мультимедиа, где обычно требуется непрерывный обмен большим объемом видео- или аудиоданных. При соответствующей поддержке хоста периферийное устройство USB может зарезервировать часть доступной полосы пропускания. Изохронные передачи ненадежны; если конкретный пакет поврежден, он будет просто отброшен, и ожидается, что программное обеспечение восстановится после этого. Массовые передачи используются для всего остального: после обработки любых ожидающих управления, изохронных и прерывающих передач хост будет использовать оставшуюся полосу пропускания для массовых передач. Массовые переводы надежны.
Передача данных с хоста на периферийное устройство адресована не только этому периферийному устройству, но и конкретной конечной точке внутри этого периферийного устройства. Точно так же хост запрашивает входящие данные от конкретной конечной точки, а не от периферийного устройства в целом. Например, комбинированное устройство клавиатуры/тачпада может обеспечить события клавиатуры на конечной точке 1 и события мыши на конечной точке 2. Каждое периферийное устройство USB может иметь до 16 конечных точек для входящих данных и еще 16 для исходящих данных. Однако, учитывая сравнительно высокую скорость ввода-вывода USB, эта адресация конечных точек обычно реализуется аппаратно, а не программно, и аппаратно реализуется лишь небольшое количество конечных точек. Конечная точка 0 обычно используется только для управляющих сообщений.
На практике многие из этих деталей не имеют отношения к коду приложения или пакетам классов. Вместо этого такой высокоуровневый код обычно просто выполняет блокировку чтения и записи или неблокирующие специфичные для USB вызовы для передачи данных между хостом и целью через определенную конечную точку. Управляющие сообщения более сложны, но обычно обрабатываются существующим кодом.
Когда периферийное USB-устройство подключается к хосту, выполняется начальный процесс перечисления и настройки. Периферийное устройство предоставляет такую информацию, как класс устройства (аудио, видео и т. д.), идентификатор поставщика, какие конечные точки следует использовать для передачи данных и т. д. Хост-ОС использует эту информацию для определения подходящего драйвера хост-устройства. Это может быть универсальный драйвер для класса периферийных устройств или драйвер, специфичный для производителя. Предполагая, что подходящий драйвер установлен, хост затем активирует периферийное устройство USB и выполняет дополнительную инициализацию для конкретного приложения. Например, для USB-устройства Ethernet это потребует получения MAC-адреса Ethernet. Большинство периферийных устройств USB будут довольно простыми, но можно создавать многофункциональные периферийные устройства с различными конфигурациями, интерфейсами и альтернативными настройками интерфейса.
Ни один из пакетов eCos не может автоматически генерировать все данные перечисления. Некоторая необходимая информация, такая как идентификатор поставщика, не может быть предоставлена универсальными пакетами; только разработчиком приложения. Код поддержки класса, такой как пакет USB-ethernet, теоретически может предоставлять часть информации автоматически, но существуют также аппаратные зависимости, например, какие конечные точки используются для входящих и исходящих кадров Ethernet. Вместо этого разработчик приложения должен предоставить все данные перечисления и выполнить некоторую дополнительную инициализацию. Кроме того, стандартный подчиненный пакет USB может обрабатывать все стандартные управляющие сообщения для простого периферийного устройства USB, но для чего-то вроде многофункционального периферийного устройства требуется поддержка дополнительных приложений.
Примечание. Первоначальная реализация пакетов ведомых USB-устройств eCos включала аппаратное обеспечение, которое поддерживало только управление и массовые передачи, а не изохронные или прерывающие передачи. В будущем могут быть внесены изменения в код USB и API, чтобы обеспечить изохронную передачу и передачу с прерыванием, особенно первую. Другие изменения могут потребоваться для поддержки различных USB-устройств. В настоящее время удаленное пробуждение через USB не поддерживается, так как оно опять же не поддерживается аппаратным обеспечением.
Устройства ввода/вывода eCos USB
Включение USB-кода
Если целевое оборудование содержит ведомое USB-устройство, соответствующий драйвер USB-устройства и общие пакеты обычно автоматически загружаются в конфигурацию при выборе этого целевого устройства (при условии, что подходящий драйвер устройства существует). Однако драйвер не обязательно будет активен. Например, процессор может иметь встроенное USB-устройство, но не все приложения, использующие этот процессор, захотят использовать функции USB. Следовательно, по умолчанию USB-устройство отключено, что гарантирует, что приложения не будут страдать от памяти или других штрафов за функциональность, которая не требуется.
Если разработчик приложения явно добавляет пакет поддержки класса, такой как пакет USB-ethernet, это означает, что USB-устройство действительно необходимо, и устройство будет включено автоматически. Однако, если подходящего пакета класса нет, а доступ к USB-устройству будет осуществляться с помощью кода приложения, необходимо включить USB-устройство вручную. Обычно самый простой способ сделать это — включить параметр конфигурации CYGGLO_IO_USB_SLAVE_APPLICATION, и драйвер USB-устройства и связанные с ним пакеты будут настроены соответствующим образом. Кроме того, драйвер устройства может предоставлять некоторые параметры конфигурации для обеспечения более точного управления.
У устройства есть поддержка USB OTG. Ниже приведены сценарии:
Когда устройство подключено к ПК, оно действует как ведомое. (Как устройство узнает, что оно должно действовать как ведомое?)
Когда устройство подключено к принтеру, оно выступает в качестве главного. (Как устройство узнает, что оно должно действовать как главное?)
Какие шаги выполняются, когда устройство подключено к OTG?Как реализовать этот механизм (вкратце)?
2 ответа 2
Протокол согласования хоста в разделе 6 описывает, как два устройства OTG решают, какое из них получает встроенный хост. В основном это архивируется путем включения подтягивающих и понижающих резисторов на линии D+.
Примечание. Когда речь идет о USB, термины ведущий/ведомый не используются. Ведущее устройство называется host и питает шину, тогда как подчиненное устройство называется device. В случае OTG (как правило, исключения см. в спецификации) обе части могут быть хостом или устройством. Когда хост был определен протоколом согласования хоста, эта часть становится так называемым встроенным хостом.
В двух упомянутых вами сценариях USB-устройство может узнать, является ли оно хостом или устройством по кабелю. USB-кабели (не типа C) несимметричны. Одна сторона — хост, а другая — устройство. На разъеме есть контакт, называемый идентификационным контактом, который плавает на стороне устройства и заземлен на стороне хоста. Это позволяет USB-контроллеру на каждой стороне знать, к какой стороне кабеля он подключен и, следовательно, какую роль (хост или устройство) он должен выполнять при подключении. Устройства такого типа называются устройствами двойного назначения.
Если у вас есть такое устройство, вы можете подключить его к обычному хосту (например, к ноутбуку), и оно будет действовать как устройство. И вы можете подключить его к обычному устройству (например, к принтеру), и он будет выступать в роли хоста. Все это основано на кабеле.
Если вы подключите два устройства OTG двойного назначения друг к другу. Их первоначальные роли определяются кабелем таким же образом.
После того, как первоначальные роли определены, они могут поменяться ролями со своих первоначальных ролей, определенных кабелем, с помощью протокола согласования хоста (HNP).
Что касается реализации этого. Нет краткого способа объяснить это. Каждый контроллер уникален, и вам придется прочитать книгу данных контроллера и модель программирования, чтобы реализовать все эти процедуры. А также хорошее понимание самих спецификаций USB и OTG.
Физическая сеть USB представляет собой многоуровневую звездообразную сеть с одним хостом (ведущим) и несколькими устройствами (подчиненными).
Хост USB предоставляет один порт для подключения. Если требуется больше периферийных устройств, подключите концентратор к корневому порту, чтобы обеспечить дополнительные порты подключения. Сеть USB может поддерживать до 127 внешних узлов. Из-за временных ограничений для распространения сигнала максимально допустимое количество уровней равно семи:
- Один уровень для хоста (хозяина шины).
- Шесть уровней концентраторов и устройств.
USB-устройства делятся на классы устройств:
- Концентраторы предоставляют дополнительные точки подключения и упрощают подключение USB с точки зрения пользователя. Каждый концентратор преобразует одну точку подключения в несколько точек подключения, называемых портами.
- Функции предоставляют системе возможности для передачи или получения данных и управляющей информации. Каждая функция содержит информацию о конфигурации, описывающую возможности устройства и требования к ресурсам.
- Составные устройства — это физические пакеты, реализующие несколько функций и включающие встроенный концентратор. Составное устройство отображается для хоста как концентратор с одним или несколькими несъемными USB-устройствами.
- Композитные устройства поддерживают более одного класса и, таким образом, предоставляют хосту более одной функции.
- Устройство с интерфейсом пользователя, например мышь, клавиатура, планшет или игровой контроллер.
- Устройство обработки изображений, например сканер, принтер или камера.
- Запоминающее устройство, такое как дисковод для компакт-дисков, дисковод для гибких дисков или DVD-диск.
Логическая сеть USB представляется разработчику звездообразной сетью с хостом в центре. Концентраторы не усложняют программирование и прозрачны для программиста. USB-устройство будет работать одинаково независимо от того, подключено ли оно напрямую к корневому концентратору или подключено через промежуточные концентраторы. Все USB-устройства доступны как адресуемые узлы в этой сети master/slave. Только хост может инициировать передачу данных в сети.
Высокоскоростной одноканальный последовательный порт USB 2.0 FTDI Type-C, один порт подачи питания
Высокоскоростной одноканальный последовательный порт USB 2.0 FTDI Type-C, два порта подачи питания
Высокоскоростной двухканальный последовательный порт USB 2.0 FTDI Type-C, один порт питания
Высокоскоростной двухканальный последовательный порт USB 2.0 FTDI Type-C, два порта подачи питания
Высокоскоростной четырехканальный последовательный порт USB 2.0 FTDI Type-C, один порт питания
Высокоскоростной четырехканальный последовательный порт USB 2.0 FTDI Type-C, два порта подачи питания
Высокоскоростной одноканальный FTDI USB 2.0 для UART/FIFO IC
Высокоскоростной двойной USB 2.0 FTDI для UART/FIFO IC
ИС контроллера устройств FTDI USB 2.0 to Quad I2C/SPI
Обратитесь к нашим специалистам по продажам и техническим специалистам по телефону +44 1256 851770 (с понедельника по пятницу с 9:00 до 17:30)
Отправьте нам сообщение через нашу контактную страницу или нажмите ниже для живого чата
nedoPC.org
Решил поделиться своими наработками, актуальность которых утрачена минимум как лет на 10-15, но вдруг кому пригодится.
Привожу схему реализации ведомого USB интерфейса для любой системы на базе z80. Что это даёт:
возможность разработки и отладки bios без перепрошивки ППЗУ и использования эмуляторов. Прямой доступ к памяти на лету. Возможность вывода данных в терминал
PC из программного кода z80.
В схеме есть несколько некрасивых решений, обусловленных экономией на корпусах в моём проекте. Так что за ряд монтажных ИЛИ на диодах и пару емкостей прошу ногами не пинать — знаю )
Программная часть со стороны PC или Mac максимально проста: Используется стандартный VCP-драйвер виртуального порта. (из под linux будет /dev/ttyUSBn), который предварительно необходимо проинициализировать с параметрами 8N1, аппаратное управление потоком.
Далее, перед началом операций чтения или записи данных в память системы на z80, посылаем в данный порт четыре байта 0xFE для синхронизации (либо необходимо подать !RESET).
Затем следует 5-ти байтовый цикл чтения или записи данных в произвольную область памяти:
1-ый байт 0xFF — начало потока данных (разрешает последующий приём)
2-ой байт lADDR — младший байт адреса памяти
3-ий байт hADDR — старший байт адреса памяти
4-ий байт 0xFF/0x0F — разрешение / запрет записи в память
5-ый байт 0xNN — данные для записи (если bit7 предыдущего байта = 0, то данный байт игнорируется и производится только чтение содержимого из указанного адреса)
В ответ на каждый посланный байт данных в консоль будет приходить содержимое данного адреса RAM до его записи.
Разумеется в адресном пространстве ППЗУ в этом случае должна быть подключена SRAM
Usb slave что это
Разъемы USB следуют за отношениями ведущего и подчиненного. Это означает, что одно устройство, обычно персональный компьютер, выполняет роль главного, управляя информацией, поступающей в порт USB и из него. Периферийное устройство USB, например небольшая флешка, действует как подчиненное устройство. Им может управлять только мастер или он не будет работать. В этом отношении некоторые USB-слэйвы бесполезны, если они не подключены к главному устройству.
USB-ведомые могут содержать только данные и не работать как анонимные блоки.
Универсальная последовательная шина — это метод передачи данных и порты, используемые для подключения определенных устройств к компьютеру. Иногда термин «USB» также используется для соединительного кабеля или даже самого периферийного устройства. Современные компьютеры обычно имеют несколько портов USB. Во многих случаях для использования периферийного устройства с USB-портом необходимо просто подключить его. Затем ваш компьютер будет искать драйвер на устройстве или использовать существующие драйверы для загрузки файлов. Эти периферийные устройства называются USB-рабами.
USB Рабы
Термин «ведомые устройства USB» охватывает весь спектр периферийных устройств. Одной из наиболее распространенных форм USB-слэйва является флэш-накопитель или флэш-накопитель. Эти небольшие устройства подключаются к USB-концентраторам на компьютерах, предлагая куски внешнего хранилища размером от 256 МБ до 16 ГБ и более. Тем не менее, USB-устройства также включают такие устройства, как веб-камеры, принтеры или сканеры. В каждом случае устройству требуется главный компьютер для полной функциональности, хотя некоторые USB-устройства, такие как камеры, будут работать независимо. Некоторые периферийные устройства, такие как смартфоны, не являются строго подчиненными устройствами, хотя они действуют как таковые при подключении к компьютеру.
взаимодействие
Истинные USB-ведомые не могут взаимодействовать друг с другом, только с главным устройством. Таким образом, веб-камера USB не будет подключаться к игровому контроллеру USB. Большинство устройств, выпущенных после 2000 года, используют для связи USB 2.0, что является более быстрой спецификацией, чем у оригинальных USB-устройств с большей пропускной способностью. Некоторые USB-порты после 2010 года теперь используют USB 3.0, хотя по состоянию на июль 2011 года это относится только к высококлассному оборудованию. USB 3.0 обеспечивает скорость передачи 5 гигабит в секунду, что значительно выше, чем скорость USB 2.0 480 мегабит в секунду.
соединение
Многие USB-устройства подключаются к главному компьютеру с помощью соединительного кабеля. Большинство USB-кабелей имеют стандартный разъем на одном конце, предназначенный для подключения к классическому USB-порту на персональных компьютерах и аналогичных устройствах. Однако разъем на другом конце может отличаться в зависимости от типа USB-устройства. Например, на другом конце он может иметь микро-разъем для подключения к мобильному телефону или меньшему устройству.
Простые вопросы: что такое шрифт и что такое семейство шрифтов?
Что такое шрифт? Что такое семейство шрифтов? Когда были впервые изобретены шрифты? Каковы характеристики шрифта? Как хранятся шрифты в Windows?
Что такое 802.11ax, 802.11ad, 802.11ac и 802.11n? что такое Wi-Fi 6, Wi-Fi 5 и так далее?
Что такое Wi-Fi 6, Wi-Fi 5 или Wi-Fi 4? Что такое 802.11ax, 802.11ac или 802.11n? Что означают эти аббревиатуры? Что такое 802.11ad?
Что такое стекло гориллы? что такое 2.5d стекло? как они сравниваются?
Что такое Gorilla Glass? Что это значит? Что такое 2.5D стекло? Есть ли разница? Какое стекло лучше или долговечнее?
USB slave
Многие компьютеры умеют загружаться с USB. Если бы можно было не записывать загрузочный образ на flash-диск, а передавать его прямо с одного компьютера на другой, это позволило бы ускорить процедуру инсталляции операционной системы на компьютер, особенно для тех систем, которые не поддерживают инсталляцию по PXE. LiveCD тоже можно было бы загружать без записи на диск.
Теоретически, это можно было бы сделать, если соединить два компьютера при помощи host-to-host-кабеля USB, такого как тот, что используется при поднятии сети usbnet.
Похоже, что сейчас нет софта, который позволяет это сделать, но (опять же, теоретически), его можно было бы смастерить на основе кода usbnet и прочего кода usb-gadget.
Пример использования g_file_storage из usb-gadget:
Можно указать ещё опцию removable=y, тогда файл backing_file можно менять через sysfs-интерфейс.
Если есть поддержка USB-slave, то всё работает. Но в том-то всё и дело, что в обычных компьютерах её нет!
Например, для телефона Nokia N900, такое организовать очень просто.
Ниже описывается пример использования, в котором мы создаём загрузочный файл, который телефон отдаёт как загрузочное устроство. Понятно, что в данном случае быстрее было бы использовать обычную флэшку, но здесь важно то, что загрузка выполняется с файла, который лежит на устройстве. И на его месте могло быть всё, что угодно (образ диска с другого компьютера, iSCSI-устройство, образ виртуального диска машины или что-нибудь ещё).
[править] Пример подготовки загрузочного файла для эскпорта по USB
Ключевая часть. Отдаём файл как блочное устройство для компьютера [1] :
После выполнения последней команды на компьютере, к которому подключён телефон, увидится новое блочное устройство (usb-storage). Допустим, /dev/sdb .
Проинциализируем на нём таблицу разделов, отформатируем и проинсталлируем загрузчик:
Устанавливаем загрузчик grub4dos, который умеет выполнять загрузку с ISO-образов:
USB Host контроллер VinculumII. Запись на Flash.
Связь по USB происходит по принципу Главный-Подчинённый. В качестве подчиненных (USB Slave) обычно выступают периферийные устройства такие ка флешки, принтеры, клавиатуры, разрабатываемые электронщиками устройства и прочее. В качестве Главного (USB Host) обычно выступают компьютеры.
Если нам нужно передать информацию от нашего устройства на компьютер, то для реализации USB протокола подойдут как внешние микросхемы преобразователей, так и собственные средства самого контроллера. Но вот если данные нужно передать на флешку, то тут уже необходимо воспользоваться USB-Host контроллером. Можно воспользоваться контроллерами с внутренним USB-Host (например PIC24), ну или воспользоваться специальной микросхемой. Одну такую микросхему и рассмотрим — FTDI VinculumII.
- 16-разрядное процессорное ядро, выполненное по Гарвардской архитектуре;
- два блока USB, которые могут выполнять функции периферийного устройства или хост-контроллера;
- 256 кбайт флэш-памяти размером (128к х 16бит);
- 16 кбайт ОЗУ (4к х 32бита);
- набор интерфейсных модулей (UART, 2 SPI slave, SPI master, параллельный 8? разрядный FIFO, ШИМ, отладочный интерфейс);
- внешний кварц на 12МГц (частота ядра 12, 24, 48 МГц);
- мультиплексор, предназначенный для коммутации внутренних блоков контроллера и внешних выводов;
- микросхемы доступны в корпусах LQFP и QFN с количеством выводов для каждого типа 32, 48 и 64.
Здесь хотелось бы поподробнее остановиться на мультиплексоре выводов микросхемы. Он позволяет подключать интерфейсные линии от различных протоколов к различным ногам контроллера (например одну и туже линию можно подключить с разных сторон контроллера). Это очень упрощает разводку платы. Да и к тому же если каждую интерфейсную линию выводить на отдельную ногу, то понадобилось бы слишком много ног, учитывая обилие интерфейсов в данном контроллере. Второй особенностью мультиплексора является работа с портами ввода-вывода, которые можно настроить не только как вход/выход, но и установить рабочий ток вывода, Pull-up или Pull-down, и даже Триггер Шмидта.
Что же имеем в сухом остатке. Отличная микросхема имеющая большОе количество различных интерфейсов, позволяющая построить различные комбинации преобразователей (мостов) интерфейсов. Главная особенность микросхемы наличие USB-Host, позволяющей работать с флешками.
И вот теперь, когда мы такие радостные, думаем сколько удивительных девайсов можно на ней сделать, пора вкусить правду-матку.
Первый сюрприз который нас ожидает — микросхема поставляется БЕЗ ПРОШИВКИ (NOTE: VNC2 devices are supplied unprogrammed). Для того что прошить микросхему необходим специальный VNC2 Debug Module. Здесь есть выбор либо купить фирменный (около 1100 руб), или же изготовить самостоятельно, ибо схема есть в даташите. Я решил взять готовый модуль (хорошо что деньги не мои ;)))
Выглядит вот так.
Тут нужно упомянуть еще один момент — модуль имеет выходной разъем PBS-2.0, а на своей плате я использовал более родной PLS-2.54. Поэтому пришлось изготовить небольшой переходник.
Изолентой заклеен один маленький, но ОЧЕНЬ мерзкий светодиодик.
Сюрприз номер два — микруха работает на собственной операционной системе реального времени (RTOS VOS), соответственно и все прошивки для нее необходимо писать с использованием этой RTOS.
Сюрпризик номер три — напрямую работать с ресурсам и контроллера не возможно. Чтобы обратиться к чему либо необходимо использовать API-функции и драйверы, поставляемые производителем в закрытом виде. Все что нам доступно — это файлы инклудов, в которых можно посмотреть какие есть функции и как к ним обратиться.
Ну и самый большой сюрприз (и самый большой минус) это среда разработки (IDE). Более убогой, тупой, и неудобной среды я не видел уже давно. Если бы компания FTDI располагалась в России, то «программистами» там бы работали внучатые племянники главного бухгалтера и начальника отдела кадров, этакие «супер-пупер-школоло-программеры». Это отличный пример того как хорошую аппаратную часть наглухо губит программное обеспечение. Сам от себя не ожидал сколько новых матерных оборотов могу я придумать пока не увидел ЭТО IDE.
- полностью неудобный вкладочный интерфейс. Имея такое небольшое количество функций можно было их расположить на одной панели, чтобы не приходилось бегать по вкладкам;
- минимальное количество настроек самой программы, и отсутствие необходимых настроек (например постоянный запрос на пере-сохранение файлов);
- на редкость тормознутый интерфейс, например вызов меню по правой кнопки мыши (для COPY/PASTE) занимает от 1 до 2 секунд;
- постоянные и многочисленные запросы на сохранение файлов и прочее. Причем не все из них срабатывают по кнопке Enter, хотя кнопка и подсвечена все равно придется клацать по ней мышкой;
- при отладке не отображается место выполнения программы. Даже если поставить на паузу выскочит дизасемблинг программы, а не место останова программы в си-листинге;
- просмотр значений переменных возможно только в месте ее обработки, что становится проблематичным, так как нет отображения места выполнения программы. Для того чтобы поймать переменную нужно постоянно нажимать Старт-Пауза и надеяться на то что переменная отобразится, а учитывая общую тормознулось интерфейса этот процесс мягко говоря ……………………….
- просмотр переменных возможен только в HEX и DEC виде. Просмотр переменной в двоичном виде ОЧЕНЬ БЫ НЕ ПОМЕШАЛ.
- вероятность того что сработает установленный Breakpoint крайне мала. Например, в программе которая просто мигает светодиодом я наставил 3 бряка и так и не дождался их отработки хотя светодиодик исправно себе моргал. Опять же данная фишка сводит на нет все попытки посмотреть значение переменных. Единственную закономерность для срабатывания бряков которую удалось уловить — так это расстановка бряков с последующей компиляцией проекта (даже если ничего не менялось, а просто добавился новый бряк). Бряки поставленные во время отладки не срабатывают, да и просто иногда не ставятся и не отключаются;
- ввиду всего вышесказанного невозможно определить состояние переменных во время зависания прошивки или при выполнении «вечного цикла» в конце программы;
- ну и самое интересное — настройка вывод производится через wizard (IOMUX). Результат настройки записывается в специальный файл. Так вот если закрыть программу, запустить, снова зайти в wizard, то настраивать все выводы придется по новой. Поэтому либо настраивать все ноги изначально правильно и больше туда не лезть, либо при попытке, например, изменить направление одного пина, придется все настройки производить по новой.
- имеющиеся примеры прошивок мало применимы в реальной жизни, так как неполноценны и однобоки. Но с этим еще можно мириться ведь это примеры. Но вот с тем, что примеры содержат ошибки мириться нельзя.
Плюсуем сюда еще кучу мелких и тупых недочетов на которые уже тупо забиваеш со временем.
Вот такая вот «среда разработки».
Просто эксперимент.
Перед началом хотелось рассказать еще об одной забавной фиче. Не буду рассказывать как я дошел до проведения данного опыта, но я решил проверить реальную частоту работы ядра микросхемы.
Для примера возьмём контроллер PIC16F876A, с внешним кварцем на 16 МГц. Как известно PIC16 делит внешнюю частоту на 4. Получаем частоту работы ядра — 4 МГц.
Закинем в контроллер программу-мигалку:
Подключив осциллограф к RB2 получим вот такую картинку.
Частота переключений светика — 666653 Гц. Получается что на переключение требуется 6 тактов, Ну или 24 относительно кварца на 16 МГц.
Тот же самый опыт проведем с VinculumII.
Внешний кварц 12 МГц. Внутренняя частота 48 МГц.
Программка-мигалка:
Получаем частоту переключений светика — 126142 Гц. Уж не знаю делит ли VinculumII частоту или нет, но получается что относительно внутренней частоты в 48 МГц на мигалку требуется 380 тактов О_о. Даже если рассчитывать относительно внешнего кварца в 12 МГц то потребуется 95 тактов. Это просто «ППЦ» какой-то.
После данного опыта отпал вопрос «Почему на такой большой скорости работы минимальная функция временной задержки 1 мС?».
Так что не только «средство разработки» тормозное, но и сам контроллер, по крайней мере в вопросе выполнения программы. Возможно аппаратные средства интерфейсов не такие тормознутые.
Пишем Firmware.
Первоначально я бы посоветовал пройти на сайт http://www.ftdichip.com/ и накачать оттуда даташитов, апнотов, примеров и прочего. Оттуда же тянем Vinculum II Toolchain 2.0 (SP1).
- Vinculum II — новый хост-контроллер USB от FTDI.
- Vinculum II — с чего начать.
- Vinculum II — с чего начать 2.
Для первоначального вкатывания в тему разберем процесс создания нового проекта и опробуем процесс записи на флешку на примере HelloWorld.
Для начала рассмотрим процесс создания нового проекта.
Запускаем Vinculum II IDE. Делаем New -> App Wizard Project.
Во вкладке New Project указываем Название проекта, Папку для сохранения, И название прибора (допустим).
На вкладке Target Module можно выбрать одну из отладочных плат, ну или как в нашем отдельную микросхему Discrete -> 32 Pin.
На вкладке Driver подключаем необходимые драйвера — USBHost2, GPIO Port A, FAT File System, BOMS (USBHost 2), stdio, string.
А вот и самая интересная вкладка IOMUX — управление мультиплексором портов. Выводы USB портов и питания помечены серым и не могут быть изменены. А вот линии портов или же каких-нибудь интерфейсов могут быть распределены по соответствующим ногам микросхемы.
Для примера закинем PORT_A.0 на 23 ногу, а PORT_A.2 на 31. Обе ноги настроим на выход (к ним подключены светодиоды) и подключим Pull-Up. Кроме направления здесь также можно задать его рабочий ток, скорость переключения, триггер Шмидта, подтяжки к питанию.
ВАЖНО. Лучше всего сразу все настроить правильно и не открывать больше данного Wizard’а. Так как если переоткрыть программу и зайти сюда опять, то все настройки портов сбрасываются и придется все настраивать заново. ХОТЯ ВСЕ ЭТИ НАСТРОЙКИ СОХРАНЯЮТСЯ В ОТДЕЛЬНЫЙ ФАЙЛ.
На вкладке Kernel ничего не трогаем. Объяснение здешних параметров есть в указанных ранее русскоязычных статьях.
Один момент — параметр CPU Speed устанавливает внутреннюю частоту микрухи. Основное назначение снижения внутренней частоты — это снижение тока потребления.
На вкладке Threads опять же ничего не трогаем.
Так как внутренняя RTOS многозадачная, то тут можно создать потоки и настроить из приоритет.
На вкладке Summary отображается результат всех наших действий.
Нажимаем кнопку Finish.
Если по какой то причине вы решите все же еще раз попасть в Wizard, то это можно сделать нажав кнопку Modify на панели File.
После того как отработает Wizard в окне Project Manager (слева) отобразиться куча файлов драйверов, автоматически подключенных к проекту. Здесь нас интересуют 3 последних файла.
В файле Project_2_iomux.c хранятся настройки портов.
В файлах Project_2.h и Project_2.c и будет содержаться наша программа.
Открыв файл Project_2.c мы увидим ОЧЕНЬ много автоматически сгенерированного кода, созданного на основе настроек Wizard’a. Если вкратце то автоматом создаются функции настройки RTOS, создания потоков, настройка периферии, работы с драйверами. Некоторое объяснение можно найти в упомянутых статьях.
ВАЖНО: Important: Sections between markers «FTDI:S*» and «FTDI:E*» will be overwritten by the Application Wizard.
Это означает, что нельзя ничего писать между тегами «/* FTDI:S* */» и «/* FTDI:E* */» ибо все что находится между ними может в любой момент переписано Wizard’ом. По личному опыту скажу что не только им — я так однажды большого куска кода недосчитался, хотя wizard я не запускал и код был расположен за пределами данных тегов.
Сейчас нас интересует место в конце файла.
Именно в этой функции будет располагаться наш код. Название функции firmware() может быть и другим, оно указывается в wizard’е на вкладке Threads в столбце function.
Для начала переопределим переменную tx_buf, заменив на:
Ну вот потому что надо мне записывать по 65 байт )))). Вы можете это и не делать.
На основе примера HelloWorld запишем следующее содержание функции. От оригинала она будет отличаться только работой со светодиодами и дополнительными комментариями.
Ах да! Тут нас ожидает первый прикол – хотя мы и настроили направление выводов без команды:
они останутся работать на вход. И ДА это не опечатка 0-вход, 1-выход.
- пока флешка не подключена, мигает светодиод на ноге PORT_A.2 (красный), с частотой 2 Гц;
- когда подключается флешка происходит монтирование устройства, подключение раздела FAT, подключение библиотеки stdio, создание/открытие файла TEST.TXT (с установкой курсора в конец файла), производится запись тестовой строки в файл (для определения времени записи мигает белый светодиод на PORT_A.0), далее закрывается файл, размонтируется FAT и BOMS. В конце этого цикла белый светодиод зажигается на 100 мС. Потом следует пауза в три секунды и все повторяется по новой.
- если флешку отключить, то опять включается мигалка красным светодиодом.
Компилируем, запускаем, проверяем, радуемся процессу, проверяем более углубленно, недоумеваем, тупим, разбираемся.
А разбираться приходится вот в чем — если подключить флешку и дождаться прохождения 1 цикла записи, и сразу отключить, то выясняется что файл создался только вот записей в нем нет. После десяти таких проверок файл был по-прежнему пуст.
Пробуем держать флешку дольше, процесс контролируем по светику или по осциллографу.
Как видно из рисунка — после компиляции (первый широкий импульс), было проделано ПЯТЬ записей в файл. НО открыв файл в нем обнаружилось только ЧЕТЫРЕ записи.
Можно конечно долго рассказывать как именно я извращался над программой, но не буду. Важно то, что удалось выяснить. А именно то не записывается именно первая строчка, а точнее она записывается только при следующем проходе цикла (это удалось выяснить только запись номера строки в файл). Опять же путем долгих и неистовых пыток программно-аппаратных средство получилось что хоть как то гарантировать только путем ПОВТОРНОГО ПЕРЕМОНТИРОВАНИЯ BOMS. Однако хоть это и редкостная тупость, но пришлось добавить в код вот такие вот две строки:
Ок! С тупостью разобрались, переходим к маразму.
Для записи информации в файл существует несколько функций. Одна из них — fwrite() — была рассмотрена в примере. Но дабы познать все прелести форматированного вывода строк в библиотеке имеется такая замечательная функция как fprintf(), кстати именно с ее помощью удалось вывести нумерованные строки и определить «тупость». Эта функция так же была подвержена «тупости», но сейчас не об этом.
Индикация процесса записи была сделана тоже не просто так! Чисто эксперимента ради, было записано время записи функцией fwrite() и fprintf(), дабы определить самую быструю (потому что так надо)))).
Первый график показывает процесс записи с помощью функции fwrite().
Как видно все пики одинаковые и длительность записи (65 байт) составляет 4-6 мС. Для сравнения широкий импульс слева это тот самый импульс в 100 мС в конце цикла.
Вторая группа графиков показывает процесс записи с помощью функции fprintf() (те же 65 байт).
Вот тут то маразм крепчает. Из графиков видно, что импульсы записи не равномерны, каждый пятый импульс в 8.5 раз шире других. А именно обычный процесс записи длится 300 мС. А каждый пятый цикл записи длится
2.5 СЕКУНДЫ. Повторюсь за один цикл записывается строка длинной 65 байт. Для сравнения импульс слева это тот самый импульс в 100 мС в конце цикла.
Что это за маразм такой и как он лечится я так и не понял, скажу только то что эти опыты повторялись неоднократно и с различным временем подключения флешки. Результаты были идентичные.
Вот так вот весело и неоднозначно происходит запись информации на флешку с помощью микросхемы VinculumII.
Еще небольшая ложка дегтя в бочку дегтя!
Для этой микросхемы на сайте производителя имеет большое количество примеров. Вот только вряд ли они пригодятся кому-то в первозданном виде, так что придется все равно лезть в потроха этого «кода». Качество этих примеров тоже не на высоте, например в одном из примеров не производилась проверка длинны входного массива данных, и послав на 1 байт больше удалось наглухо повесить микросхему до ребута.
В другом примере обработка подключения флешки производилась только в начале программы и больше туда не возвращалась — в итоге повторно вставив флешку ничего не происходило. Чтобы добиться от этого примера хоть какой то внятной работы пришлось в конец программы добавить варварский сброс программы при извлечении флешки (vos_reset_vnc2();).
Так же чего мне никак до сих пор не удалось добиться — так это передачи от SPI_Slave, хотя прием вроде работает. Опять же в примерах SPI_Slave описан только для приема, а для передачи по SPI есть пример только для SPI_Master. От Slave не удалось добиться хоть какого нибудь дерганья ножками. Пока буду обходиться без него, ибо задачи позволяют.
Так что приводимые производителем примеры можно рассматривать ТОЛЬКО КАК ОЗНАКОМИТЕЛЬНЫЕ.
Вот такой вот обзор!
Казалось по описанию — мощная микросхема с кучей всяких крутых фишек, а на деле оказывается не все так просто.