Здравствуйте!
Подскажите, пожалуйста, каким образом реализовать контроль потока для CDC-устройства?
Необходимо, чтобы процессор приостановил передачу данных с хоста на время обработки данных, а потом возобновил.
Т. е., нужен аналог сигнала "CTS".
Правильно ли я понимаю, что нужно использовать нотификацию "SERIAL_STATE"?
Полная версия этой страницы: Контроль потока при обмене по USB для LPC1768
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > RS232/LPT/USB/PCMCIA/FireWire
С CDC все проще: достаточно не забирать данные, пока процессор занят. Хост будет получать NAK'и, и, соответственно ждать.
Цитата(aaarrr @ Mar 17 2013, 20:50) 
С CDC все проще: достаточно не забирать данные, пока процессор занят. Хост будет получать NAK'и, и, соответственно ждать.
В принципе, это первое, что пришло мне в голову.
Но смутило то, что подобные действия как-то косвенно управляют потоком, а не напрямую, скажем, установкой/сбросом CTS.
Ну а как об этом узнает программа пользователя, передающая данные в виртуальный порт?
Неужели драйвер в этом случае сам съэмулирует CTS, чтобы программа пользователя им пользовалась?
Цитата(koluna @ Mar 17 2013, 22:53)
Ну а как об этом узнает программа пользователя, передающая данные в виртуальный порт?
Увы (или к счастью, не знаю) - никак. Для нее просто затянется операция записи в порт.
Цитата(koluna @ Mar 17 2013, 22:53)
Неужели драйвер в этом случае сам съэмулирует CTS, чтобы программа пользователя им пользовалась?
Нет.
А как с программным управлением потоком?
Вот по теме:
http://www.keil.com/forum/18435/
http://tech.groups.yahoo.com/group/lpc2000/message/37858
В общем, программный контроль потока не поддерживается драйвером, реализовал на уровне приложения для хоста, вручную.
http://www.keil.com/forum/18435/
http://tech.groups.yahoo.com/group/lpc2000/message/37858
В общем, программный контроль потока не поддерживается драйвером, реализовал на уровне приложения для хоста, вручную.
Цитата(aaarrr @ Mar 17 2013, 20:50)
С CDC все проще: достаточно не забирать данные, пока процессор занят. Хост будет получать NAK'и, и, соответственно ждать.
Пытаюсь сделать как-то так...
Согласно разделу "11.14.2 Data transfer for OUT endpoints" даташита, дело не в заборе данных.
Правильно ли я понимаю, что если хотим, чтобы девайс слал хосту NAK, то нужно просто не очищать буфер (команда Clear Buffer)?
Цитата(koluna @ May 20 2013, 18:47)
Правильно ли я понимаю, что если хотим, чтобы девайс слал хосту NAK, то нужно просто не очищать буфер (команда Clear Buffer)?
Можно не очищать буфер, можно не читать и не очищать - смотря что удобнее в конкретном случае.
Цитата(aaarrr @ May 20 2013, 21:19)
Можно не очищать буфер, можно не читать и не очищать - смотря что удобнее в конкретном случае.
Цитата
11.14.2 Data transfer for OUT endpoints
...
Software can now start reading the data from the USBRxData register (Table 215). When
the end of packet is reached, the RD_EN bit is cleared, and the RxENDPKT bit is set in
the USBDevSt register. Software now issues a Clear Buffer (refer to Table 250) command.
The endpoint is now ready to accept the next packet.
...
...
Software can now start reading the data from the USBRxData register (Table 215). When
the end of packet is reached, the RD_EN bit is cleared, and the RxENDPKT bit is set in
the USBDevSt register. Software now issues a Clear Buffer (refer to Table 250) command.
The endpoint is now ready to accept the next packet.
...
Исходя из этого не ясно, что можно не читать... может, где-то еще написано?
Попробуем.
Пока не получилось. Где-то баг сидит
Кстати, а какой объем буфера у стандартного драйвера виндового (на передачу который)? Он не переполнится?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.