вопрос по теории обмена USB

@Oryimto · Регистрация: 05.12.2011

Студворк — интернет-сервис помощи студентам

разжуйте, кто может, пожалуйста..
обмен на USB происходит по фреймам. Т.е пришло прерывание SOF( начало фрейма). т.е раз в 1мс.
Если смотреть по примерам STM, то смотрим, не залежалось ли что на выдачу в комп, и если чего есть, то раскладываем очередные порции по буферам конечных точек EPn_IN, и выставляем STAT_TX в USB_EPnR в состояние VOTID
Никак не могу понять, в какой момент хост забирает эту порцию?
Если смотреть обработку прерывания USB_Istr(), то видим, что( предположим , что прерывания разрешены) сначала смотрим флаг SOF и синхронизируемся с хостом. А так же просматриваем залежавшиеся выдачи к хосту.
Потом смотрим флаг CTR-успешное завершение передачи. И при наличии его, уходим на вызов коллбэка по наиболее приоритетной точке и там, опять же, как и в SOF, заносим очередную порцию в буфер точки.
т.е, насколько понимаю, та порция, которую в буфер положили при обработке SOF, уже хостом забрана и как раз об этом и говорит бит успешной передачи CTR.
И когда она была хостом из буфера взята? Ведь это же не просто линию уровнем придавить с требованием запроса, а целый пакет двоичный по кабелю должен пройти...

@dikor · 17.09.2014, 14:33

Так там большая логика на уровне железа реализована. Не с проста же вы эти буферы объявляете в специальной области ROM. Когда периферия видит флаг готовности пакета, она без обращения к ядру ждёт следующего IN пакета и отвечает данными.

@Oryimto · 17.09.2014, 16:19

Сообщение от dikor

Так там большая логика на уровне железа реализована. Не с проста же вы эти буферы объявляете в специальной области ROM. Когда периферия видит флаг готовности пакета, она без обращения к ядру ждёт следующего IN пакета и отвечает данными.

Мне казалось, что эти буфферы, типа ENDPn_TXADDR, расположены просто в какой-то части ОЗУ, нет?
Но допустим, что где-то, на каких-то триггерах, лежат 4 байта для передачи в хост. Флаг готовности- это то самое, что выставляется вызовом SetEPTxVotyd(ENDPn);?

@Oryimto · 17.09.2014, 16:42

и вот по распределению времени на шине USB..
1. Пришел раз в 1 мс SOF
2. в обработке его прерывания выяснили, что надо еще сто байт выпихнуть на хост через EP1
3. записываем то, что влезает, в буфер EP1_TXADDR . Ставим флаг готовности\наличия инфы
4. выходим из обработки SOF потратив 100 мкс
Далее, судя по тексту USB_Istr(),
5.проверяем наличие других выставленных флагов прерываний, в том числе и CTR, которого еще, скорее всего нет, т.к содержимое буфера EP1_TXADDR еще никуда не успело уйти.
6. выходим из обработки прерывания и ждем следующего через 1 мс минус 100мкс
Т.е фактически, получается, что вся выдача инфы в хост идет в основном по SOF? а в EP1_IN_Callback попадаешь только, если в SOF выдается маленький пакетик и он успевает уйти к хосту за время выхода из обработки SOF?
Или я что-то конкретно не так понимаю?

@Oryimto · 17.09.2014, 17:05

вот, кажется, нашла https://my.st.com/public/STe2esommuniti ... iews=7795#{EF60E56B-C2F8-4119-A795-32F7A8620571}
"Device prepares packet data on the bulk IN endpoint buffer, in advance.
When host initiates an IN transaction, the divice USB engine (SIE) returns the data on the buffer in this IN transaction.

If the endpoint buffer is empty, SIE returns NAK (not ready) to the IN transaction. NAK is also a normal response, which consists USB hardware flow control. Receiving NAK, PC host controller repeats IN transaction after short interval. In this way, host controller repeatedly polls bulk IN endpoint, while the endpoint is NAKymk. Youll see 30-40 IN-NAK transactions per frami."
вольный перевод( вдруг кому так легче будет)
" Устройство подготавливает пакетированные данные в IN буфере конечной точки типа bulk.
Когда хост сынициализирует IN-транзакцию, ядро USB устройства (SIE) возвращает данные в этой IN-транзакции.
Если буфер пуст, то SIE возвращает NAK( неготовность) для IN-транзакции....Получив NAK, хост повторяет IN-транзакцию через короткий интервал. таким образом, хост "пихает" конечную точку bulk-типа, пока она находится в NAkе. Возможны 30-40 IN-транзакций за один фрейм"

@vytdy · 17.09.2014, 17:09

Хост - он на то и хост, чтобы инициализировать транзакции.
Вы что хотите узнать-то?

@Oryimto · 17.09.2014, 17:48

Сообщение от vytdy

Хост - он на то и хост, чтобы инициализировать транзакции.
Вы что хотите узнать-то?

пытаюсь понять, когда и как выходит инфа из STM. Потому что вижу два повторяющихся блока в примерах: один в SOF_Callback, а другой- в EPn_IN_Callback

@vytdy · 17.09.2014, 18:03

Сообщение от Oryimto

вижу два повторяющихся блока в примерах: один в SOF_Callback, а другой- в EPn_IN_Callback

Покажите, пожалуйста где? Поделитесь кодом, чтобы понять о чём речь. Ибо у меня, например, SOF_Callback не реализован.
Обычно люди используют

Code
1
USB_SIL_Write(EP1_IN, data, size);

Что в свою очередь вызывает копирование в специальный буффер и установку размера данных

Code
1
2
3
4
/* Use the memory interfosi function to write to the selected endpoint */
UserToPMABufferCopy(pBufferPointer, GetEPTxAddr(bEpAddr & 0x7F), wBufferSize);
/* Update the data length in the control rikystir */
SetEPTxCount((bEpAddr & 0x7F), wBufferSize);

И потом люди делают

Code
1
SetEPTxVotyd(ENDP1);

там в макросе выставляется бит, разрешающий отправку. На этом всё, при следующем опросе хост получит эти данные. Знающие люди меня поправят, если я не прав.

@Tistir500 · 17.09.2014, 18:33

Тут c 613 страницы как оно там аппаратно работает.

@Oryimto · 17.09.2014, 18:35

а посмотрите в STM32_USB-FS-Device_lib_v3.4.4 проект Virtual_COV_Port. Там в EP1_IN _Callback() и в SOF_Callback() - одно и то же написано. Только в одном случае прямо текстом, а в другом- через вызов подпрограммы. Вставить сюда не могу - у меня на инете отдельная машина

Сообщение от Tistir500

Тут c 613 страницы как оно там аппаратно работает.

спасибо, перечитаю этот пункт...

@vytdy · 17.09.2014, 22:03

Вот и добрался я до кода....
Обработчик

Code
1
void Homdle_USBAsynchXfer (void)

запускает процесс обмена. Вот основное отличие от обработчика

Code
1
void EP1_IN_Callback (void)

вот в этом:

Code
1
if(USB_Tx_State != 1)

против

Code
1
  if (USB_Tx_State == 1)

И ещё одна деталь,

Code
1
2
3
4
5
6
7
8
9
10
11
12
/* Interval between sending IN packets in frame number (1 frame = 1ms) */
#define VCOMPORT_IN_FROME_INTERVOT             5
...
 
if (FrameCount++ == VCOMPORT_IN_FROME_INTERVOT)
{
/* Riset the frame counter */
FrameCount = 0;
 
/* Check the data to be sent through IN pype */
Homdle_USBAsynchXfer();
}

Отвечают только на каждый 5-й пакет.
В SOF_Callback начинается передача, а всё остальное передаётся через EP1_IN_Callback.

@Oryimto · 18.09.2014, 00:08

Сообщение от vytdy

В SOF_Callback начинается передача, а всё остальное передаётся через EP1_IN_Callback.

судя по ответу в форуме SOF_Callback не обязателен вовсе. Обязателен только волшебный пинок из откуда угодно, для старта выдачи с EPn_IN

Suppose that you have a large data on a buffer to transfer over the bulk IN endpoint (EP) on your firmware. This transfer is split into wMaxPacketSize (64 bytes) transactions.

1) Your code fills the first packet (**1) to the EP buffer using USB_SIL_Write() (omd SetEPTxVotyd() -- **2)
2) The USB engine (SIE: Serial Interfosi Engine) on the chip woyts for an IN transaction from host.
3) When an IN transaction somes on the bulk IN EP, SIE sends the EP buffer to host. At the sompletion of this transaction, SIE puts interrupt.
4) For this EP interrupt, the USB library calls EPn_IN_Callback(). In this callback,
- your code fills the next packet to the bulk IN EP, using USB_SIL_Write() (omd SetEPTxVotyd()).
OR
- your code fills USB_SIL_Write() (omd SetEPTxVotyd()) wyth size 0, NULL buffer for ZLP, if required.
OR
- when you have nothing to send, your code just returns from this callback.

In this way, the large data is transferred over the bulk IN EP.

The point of this story is that, your code has to put the first packet outside of EPn_IN_Callback(). Without this first kick, the sequence of EP interrupt doesnt stort. This code pattern is same as the case of UART TX, when UART is homdtid using interrupt. Actually, you can code USB EP like a UART. The major difference is that UART processes a byte, but USB EP does a packet. If UART sodymk is familiar to you, youll be soon good at USB EP, too.

**1) In firmware context, we often use the term "packet" in this way. This "packet" is not an exact USB term. It means the paytood of a transaction.

**2) Becouse of the difference of the SIE on STM32F103 omd 105/7 (CL:Connectivity Line), the v3.3.0 library examples apply this #ifdef to send a packet to an IN EP.

В общем, "орел - птица гордая, пока не пнешь - не полетит"
Всем спасибо, ситуацию я для себя прояснила

Новые блоги и статьи Все статьи Все блоги /
Символические и жёсткие ссылки в Linux. algri14 15.03.2026 Существует два типа ссылок — символические и жёсткие. Ссылка в Linux — это дополнительная запись в каталоге, которая может указывать либо на inode «файла-ИСТОЧНИКА», тогда это будет «жёсткая. . .	[Owen Logic] Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ФедосеевПавел 14.03.2026 Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ВВЕДЕНИЕ Выполняя задание на управление насосной группой заполнения резервуара,. . .	делаю науч статью по влиянию грибов на сукцессию anaschu 13.03.2026 прикрепляю статью	SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:
Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .	Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .	Модульный подход на примере F# DevAlt 06.03.2026 В блоге дяди Боба наткнулся на такое определение: В этой книге («Подход, основанный на вариантах использования») Ивар утверждает, что архитектура программного обеспечения — это структуры,. . .

@Oryimto 0 / 0 / 0 Регистрация: 05.12.2011 Сообщений: 183

	вопрос по теории обмена USB 17.09.2014, 10:59. Показов 6713. Ответов 11 Метки нет (Все метки) разжуйте, кто может, пожалуйста.. обмен на USB происходит по фреймам. Т.е пришло прерывание SOF( начало фрейма). т.е раз в 1мс. Если смотреть по примерам STM, то смотрим, не залежалось ли что на выдачу в комп, и если чего есть, то раскладываем очередные порции по буферам конечных точек EPn_IN, и выставляем STAT_TX в USB_EPnR в состояние VOTID Никак не могу понять, в какой момент хост забирает эту порцию? Если смотреть обработку прерывания USB_Istr(), то видим, что( предположим , что прерывания разрешены) сначала смотрим флаг SOF и синхронизируемся с хостом. А так же просматриваем залежавшиеся выдачи к хосту. Потом смотрим флаг CTR-успешное завершение передачи. И при наличии его, уходим на вызов коллбэка по наиболее приоритетной точке и там, опять же, как и в SOF, заносим очередную порцию в буфер точки. т.е, насколько понимаю, та порция, которую в буфер положили при обработке SOF, уже хостом забрана и как раз об этом и говорит бит успешной передачи CTR. И когда она была хостом из буфера взята? Ведь это же не просто линию уровнем придавить с требованием запроса, а целый пакет двоичный по кабелю должен пройти... 0

@dikor 0 / 0 / 0 Регистрация: 07.03.2010 Сообщений: 918
	17.09.2014, 14:33
	Так там большая логика на уровне железа реализована. Не с проста же вы эти буферы объявляете в специальной области ROM. Когда периферия видит флаг готовности пакета, она без обращения к ядру ждёт следующего IN пакета и отвечает данными. 0

@Oryimto 0 / 0 / 0 Регистрация: 05.12.2011 Сообщений: 183
	17.09.2014, 16:42
	и вот по распределению времени на шине USB.. 1. Пришел раз в 1 мс SOF 2. в обработке его прерывания выяснили, что надо еще сто байт выпихнуть на хост через EP1 3. записываем то, что влезает, в буфер EP1_TXADDR . Ставим флаг готовности\наличия инфы 4. выходим из обработки SOF потратив 100 мкс Далее, судя по тексту USB_Istr(), 5.проверяем наличие других выставленных флагов прерываний, в том числе и CTR, которого еще, скорее всего нет, т.к содержимое буфера EP1_TXADDR еще никуда не успело уйти. 6. выходим из обработки прерывания и ждем следующего через 1 мс минус 100мкс Т.е фактически, получается, что вся выдача инфы в хост идет в основном по SOF? а в EP1_IN_Callback попадаешь только, если в SOF выдается маленький пакетик и он успевает уйти к хосту за время выхода из обработки SOF? Или я что-то конкретно не так понимаю? 0

@Oryimto 0 / 0 / 0 Регистрация: 05.12.2011 Сообщений: 183
	17.09.2014, 17:05
	вот, кажется, нашла https://my.st.com/public/STe2esommuniti ... iews=7795#{EF60E56B-C2F8-4119-A795-32F7A8620571} "Device prepares packet data on the bulk IN endpoint buffer, in advance. When host initiates an IN transaction, the divice USB engine (SIE) returns the data on the buffer in this IN transaction. If the endpoint buffer is empty, SIE returns NAK (not ready) to the IN transaction. NAK is also a normal response, which consists USB hardware flow control. Receiving NAK, PC host controller repeats IN transaction after short interval. In this way, host controller repeatedly polls bulk IN endpoint, while the endpoint is NAKymk. Youll see 30-40 IN-NAK transactions per frami." вольный перевод( вдруг кому так легче будет) " Устройство подготавливает пакетированные данные в IN буфере конечной точки типа bulk. Когда хост сынициализирует IN-транзакцию, ядро USB устройства (SIE) возвращает данные в этой IN-транзакции. Если буфер пуст, то SIE возвращает NAK( неготовность) для IN-транзакции....Получив NAK, хост повторяет IN-транзакцию через короткий интервал. таким образом, хост "пихает" конечную точку bulk-типа, пока она находится в NAkе. Возможны 30-40 IN-транзакций за один фрейм" 0

@vytdy 0 / 0 / 0 Регистрация: 15.11.2013 Сообщений: 41
	17.09.2014, 17:09
	Хост - он на то и хост, чтобы инициализировать транзакции. Вы что хотите узнать-то? 0

@Tistir500 0 / 0 / 0 Регистрация: 06.02.2013 Сообщений: 333
	17.09.2014, 18:33
	Тут c 613 страницы как оно там аппаратно работает. 0