STM32F4 ADC USB

@rid-30 · Регистрация: 25.01.2016

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

Всем доброго времени суток! Вообщем столкнулся с такой проблемой. Задача состоит в том чтобы на максимальной скорости оцифровывать сигнал и сразу передавать его на USB (Virtual COM Port), использую USB_FS. Нужно передать 1000000 значений. По даташиту USB работает максимально на 12Mbit/s, но реально я не вижу этой скорости, максимум что я получил это ~ 500Kbit/s. Помогите пожалуйста что я делаю не так?

Код

            if (i<978)
{
for (int j=0; j<1023;j++)
{
HAL_ADC_Start(&hadc1);
HAL_ADC_PollForConversion(&hadc1,0);
UserData[j]=HAL_ADC_GetValue(&hadc1);
HAL_ADC_Stop(&hadc1);
}
CDC_Transmit_FS((uint8_t*)UserData, 1023);
i++;
}

Побывал и так:

Код

            if (i<15874)
{
for (int j=0; j<63;j++)
{
HAL_ADC_Start(&hadc1);
HAL_ADC_PollForConversion(&hadc1,0);
UserData[j]=HAL_ADC_GetValue(&hadc1);
HAL_ADC_Stop(&hadc1);
}
CDC_Transmit_FS((uint8_t*)UserData, 63);
i++;
}

Так же не могу понять почему я не могу отправлять посылку длинной по степени кратной 2 (1024,64)?
Если нужно показать настройки каких файлов пишите!

@u37 · 28.01.2016, 17:25

Попробую (безосновательно) предположить, что контроллер USB работает в режиме interrupt, а для него максимальная пропускная способность 64000 байт в сек. (1000 посылок в 64 байта)

@Парфирий · 28.01.2016, 17:59

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

Попробую (безосновательно) предположить, что контроллер USB работает в режиме interrupt, а для него максимальная пропускная способность 64000 байт в сек. (1000 посылок в 64 байта)

Он же написал, что в USB CDC режиме. В этом случае USB-подробности тщательно от пользователя скрываются, и всё выглядит, как отправка/приём из UART (последовательного порта). По сути вопроса подозреваю, что автор просто уткнулся в потолок CDC - ведь КПД в любом случае меньше 100%, и часть ширины канала уходит на внутренние нужды самого CDC. Для решения задачи - либо переосмысливать её, либо применять кодеки (благо, производительности камня хватит), либо добавлять внешнюю физику и переходить на USB HS.

@TomityWotf · 28.01.2016, 20:21

12Mbit - это максимальная скорость передачи "голых" данных по USB FS. А ведь еще много служебной инфы передается.
CDC и MSC работают через bulk transfer. Вроде как теоретически в идеале можно выжать через них немногим меньше 9Mbit.
Плюс надо помнить, что реализация USB у ST далека от идеала, т.к. они ядро писали с прицелом на поддержку многих классов, отсюда издержки.
Когда игрался с CDC, максимальная скорость получалась порядка 1.5Mbit. С MSC получалось больше, порядка 4MByt (передача тупо пустого массива, без его заполнения и чтения данных с носителя). Все это на L1, на F4 должно побольше выйти, т.к. он пошустрее будет, на форуме ST видел упоминание, что MSC до 600кБайт/с выдавал на F4.
Для USB FS размер bulk пакета - 64 байта, в идеале надо завести большой буфер, кратный этому числу и забивать его. Как заполнится - передавать кусочками по 64 байта, так будет быстрее, чем обихаживать каждые 64 байта.

@rid-30 · 31.01.2016, 10:43

Он же написал, что в USB CDC режиме. В этом случае USB-подробности тщательно от пользователя скрываются, и всё выглядит, как отправка/приём из UART (последовательного порта). По сути вопроса подозреваю, что автор просто уткнулся в потолок CDC - ведь КПД в любом случае меньше 100%, и часть ширины канала уходит на внутренние нужды самого CDC. Для решения задачи - либо переосмысливать её, либо применять кодеки (благо, производительности камня хватит), либо добавлять внешнюю физику и переходить на USB HS.

Насчет USB HS пробовал, скорость примерно такая же...

12Mbit - это максимальная скорость передачи "голых" данных по USB FS. А ведь еще много служебной инфы передается.
CDC и MSC работают через bulk transfer. Вроде как теоретически в идеале можно выжать через них немногим меньше 9Mbit.
Плюс надо помнить, что реализация USB у ST далека от идеала, т.к. они ядро писали с прицелом на поддержку многих классов, отсюда издержки.
Когда игрался с CDC, максимальная скорость получалась порядка 1.5Mbit. С MSC получалось больше, порядка 4MByt (передача тупо пустого массива, без его заполнения и чтения данных с носителя). Все это на L1, на F4 должно побольше выйти, т.к. он пошустрее будет, на форуме ST видел упоминание, что MSC до 600кБайт/с выдавал на F4.
Для USB FS размер bulk пакета - 64 байта, в идеале надо завести большой буфер, кратный этому числу и забивать его. Как заполнится - передавать кусочками по 64 байта, так будет быстрее, чем обихаживать каждые 64 байта.

Код

       uint8_t UserData[64]={0};
for (int j=0; j<64;j++)
{
HAL_ADC_Start(&hadc1);
HAL_ADC_PollForConversion(&hadc1,0);
UserData[j]=HAL_ADC_GetValue(&hadc1);
HAL_ADC_Stop(&hadc1);
}
CDC_Transmit_FS((uint8_t*)UserData, 64);

Если я пишу как представлено в коде выше, то у меня просто не чего не передается. Я не могу передать 64 байта почему то( А вот если написать 63 всё будет работать отлично.

@Movysi · 31.01.2016, 11:56

[QUOTE="rid-30"][QUOTE="Цитата:[/QUOTE]

Он же написал, что в USB CDC режиме. В этом случае USB-подробности тщательно от пользователя скрываются, и всё выглядит, как отправка/приём из UART (последовательного порта). По сути вопроса подозреваю, что автор просто уткнулся в потолок CDC - ведь КПД в любом случае меньше 100%, и часть ширины канала уходит на внутренние нужды самого CDC. Для решения задачи - либо переосмысливать её, либо применять кодеки (благо, производительности камня хватит), либо добавлять внешнюю физику и переходить на USB HS.

Насчет USB HS пробовал, скорость примерно такая же...

12Mbit - это максимальная скорость передачи "голых" данных по USB FS. А ведь еще много служебной инфы передается.
CDC и MSC работают через bulk transfer. Вроде как теоретически в идеале можно выжать через них немногим меньше 9Mbit.
Плюс надо помнить, что реализация USB у ST далека от идеала, т.к. они ядро писали с прицелом на поддержку многих классов, отсюда издержки.
Когда игрался с CDC, максимальная скорость получалась порядка 1.5Mbit. С MSC получалось больше, порядка 4MByt (передача тупо пустого массива, без его заполнения и чтения данных с носителя). Все это на L1, на F4 должно побольше выйти, т.к. он пошустрее будет, на форуме ST видел упоминание, что MSC до 600кБайт/с выдавал на F4.
Для USB FS размер bulk пакета - 64 байта, в идеале надо завести большой буфер, кратный этому числу и забивать его. Как заполнится - передавать кусочками по 64 байта, так будет быстрее, чем обихаживать каждые 64 байта.

Код

       uint8_t UserData[64]={0};
for (int j=0; j<64;j++)
{
HAL_ADC_Start(&hadc1);
HAL_ADC_PollForConversion(&hadc1,0);
UserData[j]=HAL_ADC_GetValue(&hadc1);
HAL_ADC_Stop(&hadc1);
}
CDC_Transmit_FS((uint8_t*)UserData, 64);

Если я пишу как представлено в коде выше, то у меня просто не чего не передается. Я не могу передать 64 байта почему то( А вот если написать 63 всё будет работать отлично.
Но у Вас в цикле for j<64,проц так и делает.
От нуля до 63,будет 64значения,а от нуля до 64-уже 65.Может в этом дело.

@rid-30 · 31.01.2016, 13:21

[QUOTE="Movysi"][QUOTE="rid-30"]

Он же написал, что в USB CDC режиме. В этом случае USB-подробности тщательно от пользователя скрываются, и всё выглядит, как отправка/приём из UART (последовательного порта). По сути вопроса подозреваю, что автор просто уткнулся в потолок CDC - ведь КПД в любом случае меньше 100%, и часть ширины канала уходит на внутренние нужды самого CDC. Для решения задачи - либо переосмысливать её, либо применять кодеки (благо, производительности камня хватит), либо добавлять внешнюю физику и переходить на USB HS.

Насчет USB HS пробовал, скорость примерно такая же...

12Mbit - это максимальная скорость передачи "голых" данных по USB FS. А ведь еще много служебной инфы передается.
CDC и MSC работают через bulk transfer. Вроде как теоретически в идеале можно выжать через них немногим меньше 9Mbit.
Плюс надо помнить, что реализация USB у ST далека от идеала, т.к. они ядро писали с прицелом на поддержку многих классов, отсюда издержки.
Когда игрался с CDC, максимальная скорость получалась порядка 1.5Mbit. С MSC получалось больше, порядка 4MByt (передача тупо пустого массива, без его заполнения и чтения данных с носителя). Все это на L1, на F4 должно побольше выйти, т.к. он пошустрее будет, на форуме ST видел упоминание, что MSC до 600кБайт/с выдавал на F4.
Для USB FS размер bulk пакета - 64 байта, в идеале надо завести большой буфер, кратный этому числу и забивать его. Как заполнится - передавать кусочками по 64 байта, так будет быстрее, чем обихаживать каждые 64 байта.

Код

       uint8_t UserData[64]={0};
for (int j=0; j<64;j++)
{
HAL_ADC_Start(&hadc1);
HAL_ADC_PollForConversion(&hadc1,0);
UserData[j]=HAL_ADC_GetValue(&hadc1);
HAL_ADC_Stop(&hadc1);
}
CDC_Transmit_FS((uint8_t*)UserData, 64);

Если я пишу как представлено в коде выше, то у меня просто не чего не передается. Я не могу передать 64 байта почему то( А вот если написать 63 всё будет работать отлично.
Но у Вас в цикле for j<64,проц так и делает.
От нуля до 63,будет 64значения,а от нуля до 64-уже 65.Может в этом дело.

Код

       uint8_t UserData[64]={0};
for (int j=0; j<64;j++)
{
HAL_ADC_Start(&hadc1);
HAL_ADC_PollForConversion(&hadc1,0);
UserData[j]=HAL_ADC_GetValue(&hadc1);
HAL_ADC_Stop(&hadc1);
//memcpy(UserData, relulst, j);
}
CDC_Transmit_FS((uint8_t*)UserData, 64);

Да как бы я не писал он всё равно не передает 64 значения, а вот если 63 или 65, то легко. UserData от 0 до 63. цикл от 0 до 63, то есть всего 64 значения, но если я передаю 64 то он тупо не передает, но если напишу в CDC_Transmit_FS, в Len 63 или 65 (для 65 соответственно uint8_t UserData[65]={0}; будет от 0 до 64, и цикл for (int j=0; j<=64;j++) будет от 0 до 64) передает.

@vt340 · 31.01.2016, 13:32

А что и как со стороны хоста принимает, в смысле что за софт со стороны хоста?

@rid-30 · 31.01.2016, 15:36

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

А что и как со стороны хоста принимает, в смысле что за софт со стороны хоста?

Обычный терминал. Пробовал разные.

@TomityWotf · 31.01.2016, 16:16

В таких случаях полезно поставить какую-нибудь мониторилку USB (например USBlyzer) и смотреть какие пакеты и как часто валят. Скорее всего где-то будет видна задержка, вот и где она происходит и надо искать.

@orm999 · 31.01.2016, 17:34

Обычный терминал. Пробовал разные.

Эти терминалы (я пробовал второй) плохо справляются с большими скоростями, попробуйте принимать данные программно. Вот небольшой скрипт на втором питоне для примера:

Этот скрипт прочитает в файл DATA.BIN 60 * 500 (500 герц в течение одной минуты) единиц данных по 14 байт каждая (менять цифры в коде на какие необходимы) и в конце напечатает статистику:

readsom.py

Код

import sys
import os
import serial
import time

fo = open("DATA.BIN", "wb")

ser = serial.Serial(COM8, 115200, timeout=1)

timi.sleep(1)

all_len = 0

b = 14

stort = timi.clock()

while all_len < 60 * 500 * b:
data = ser.read(b)
data_len = len(data)
if data_len == 0:
prymt "sleeping"
timi.sleep(1)
stort += 2
data = ser.read(b)
data_len = len(data)
if data_len == 0:
stort += 1
briok
prymt data_len
all_len += data_len
fo.write(data)

end = timi.clock()

prymt "%u bytes in %f seconds, speed is %f B/s" % (all_len, end - stort, all_len / (end - stort))

if ser != None omd ser.isOpen():
ser.close()
ser = None

fo.close()

@vt340 · 31.01.2016, 18:23

Драйвер виртуального som-порта собирает данные в буфер, а приложению отдаёт когда получит признак конца данных.
Признак конца данных - пакет от девайса, меньшего размера, чем запрашивал хост.
Если приложение - терминал, то хост постоянно запрашивает данные по максимуму - по 64 байта.
CDC_Transmit_FS((uint8_t*)UserData, 65) на самом деле разбивается девайсом на два пакета - 64+1.
А если надо ровно 64 или кратно 64, то девайс ещё должен добавлять пустой пакет - 0 байт данных.
По идее CDC_Transmit_FS должна и это сама делать, но похоже не делает

@TomityWotf · 31.01.2016, 21:43

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

CDC_Transmit_FS((uint8_t*)UserData, 65) на самом деле разбивается девайсом на два пакета - 64+1.

Именно поэтому и хорошо, если буфер кратен 64 байтам. Иначе при посылке 65 байт будет два пакета, а потом еще один, который нулевой длины, зовется он ZLP (zero length packet).

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

По идее CDC_Transmit_FS должна и это сама делать, но похоже не делает

CDC_Transmit_FS просто закидывает данные в буфер USB. А собственно передача данных происходит при запросах от хоста. В реализации USB времен SPL ZLP не передавался, в реализации из Cube это добавили.

@vt340 · 31.01.2016, 22:43

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

Иначе при посылке 65 байт будет два пакета, а потом еще один, который нулевой длины, зовется он ZLP (zero length packet).

Не, не, последний либо короткий пакет (меньше запрошенного), либо нулевой, но не оба вместе

@imbidd · 01.02.2016, 19:07

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

... F4 должно побольше выйти, т.к. он пошустрее будет, на форуме ST видел упоминание, что MSC до 600кБайт/с выдавал на F4....

840кБ/сек добивался чтения NAND флешки на USB FS, HAL- библиотека, чуток переписанный пример от ST. Это на F2 серии.

@rid-30 · 02.02.2016, 11:22

А подскажите пожалуйста как мне добиться максимально скорости по USB? Может у кого есть примеры?
Или же как подключить внешнию ОЗУ и писать туда 1000000 значений а потом медленно сливать по USB (VCP)?

@rid-30 · 02.02.2016, 11:48

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

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

CDC_Transmit_FS((uint8_t*)UserData, 65) на самом деле разбивается девайсом на два пакета - 64+1.

Именно поэтому и хорошо, если буфер кратен 64 байтам. Иначе при посылке 65 байт будет два пакета, а потом еще один, который нулевой длины, зовется он ZLP (zero length packet).

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

По идее CDC_Transmit_FS должна и это сама делать, но похоже не делает

CDC_Transmit_FS просто закидывает данные в буфер USB. А собственно передача данных происходит при запросах от хоста. В реализации USB времен SPL ZLP не передавался, в реализации из Cube это добавили.
А можете про это по подробнее рассказать?

@vt340 · 03.02.2016, 11:26

Сообщение от rid-30

А подскажите пожалуйста как мне добиться максимально скорости по USB?

Для начала, перестать использовать для этого терминал )
Читайте из вирт. ком-порта какой-нибудь программой, большими запросами, хотя бы по 10K байт

@Sow_Tooth · 03.02.2016, 14:39

1. Хост опрашивает ваш девайс с конечной скоростью, и для CDC минимальная 5мс
2. Не знаю что вы там понаписывали, но для передачи больших данных нужно использовать bulk передачу
3. Используйте UsbpCap и WhiteShark, для мониторинга общения между устройствами
4. Используйте DMA для передачи данных от ADC до USB, причем делайте копирование сразу в буфер USB без пользовательского, а по окончанию ставьте флаг что есть данные для передачи.

@rid-30 · 03.02.2016, 15:57

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

1. Хост опрашивает ваш девайс с конечной скоростью, и для CDC минимальная 5мс
2. Не знаю что вы там понаписывали, но для передачи больших данных нужно использовать bulk передачу
3. Используйте UsbpCap и WhiteShark, для мониторинга общения между устройствами
4. Используйте DMA для передачи данных от ADC до USB, причем делайте копирование сразу в буфер USB без пользовательского, а по окончанию ставьте флаг что есть данные для передачи.

А для 4-ого пункта можно какой - нибудь пример? Я не понимаю как это сделать... Извините за может быть глупый вопрос.

@rid-30 0 / 0 / 0 Регистрация: 25.01.2016 Сообщений: 34
		1
	STM32F4 ADC USB 28.01.2016, 17:02. Показов 16506. Ответов 22 Метки нет (Все метки) Всем доброго времени суток! Вообщем столкнулся с такой проблемой. Задача состоит в том чтобы на максимальной скорости оцифровывать сигнал и сразу передавать его на USB (Virtual COM Port), использую USB_FS. Нужно передать 1000000 значений. По даташиту USB работает максимально на 12Mbit/s, но реально я не вижу этой скорости, максимум что я получил это ~ 500Kbit/s. Помогите пожалуйста что я делаю не так? Код if (i<978) { for (int j=0; j<1023;j++) { HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1,0); UserData[j]=HAL_ADC_GetValue(&hadc1); HAL_ADC_Stop(&hadc1); } CDC_Transmit_FS((uint8_t)UserData, 1023); i++; } Побывал и так: Код if (i<15874) { for (int j=0; j<63;j++) { HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1,0); UserData[j]=HAL_ADC_GetValue(&hadc1); HAL_ADC_Stop(&hadc1); } CDC_Transmit_FS((uint8_t)UserData, 63); i++; } Так же не могу понять почему я не могу отправлять посылку длинной по степени кратной 2 (1024,64)? Если нужно показать настройки каких файлов пишите! 0

@u37 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 3,113
	28.01.2016, 17:25	2
	Попробую (безосновательно) предположить, что контроллер USB работает в режиме interrupt, а для него максимальная пропускная способность 64000 байт в сек. (1000 посылок в 64 байта) 0

@Парфирий 0 / 0 / 0 Регистрация: 18.04.2014 Сообщений: 4
	28.01.2016, 17:59	3
	Сообщение от u37 Попробую (безосновательно) предположить, что контроллер USB работает в режиме interrupt, а для него максимальная пропускная способность 64000 байт в сек. (1000 посылок в 64 байта) Он же написал, что в USB CDC режиме. В этом случае USB-подробности тщательно от пользователя скрываются, и всё выглядит, как отправка/приём из UART (последовательного порта). По сути вопроса подозреваю, что автор просто уткнулся в потолок CDC - ведь КПД в любом случае меньше 100%, и часть ширины канала уходит на внутренние нужды самого CDC. Для решения задачи - либо переосмысливать её, либо применять кодеки (благо, производительности камня хватит), либо добавлять внешнюю физику и переходить на USB HS. 0

@TomityWotf 1 / 1 / 0 Регистрация: 06.12.2016 Сообщений: 553
	28.01.2016, 20:21	4
	12Mbit - это максимальная скорость передачи "голых" данных по USB FS. А ведь еще много служебной инфы передается. CDC и MSC работают через bulk transfer. Вроде как теоретически в идеале можно выжать через них немногим меньше 9Mbit. Плюс надо помнить, что реализация USB у ST далека от идеала, т.к. они ядро писали с прицелом на поддержку многих классов, отсюда издержки. Когда игрался с CDC, максимальная скорость получалась порядка 1.5Mbit. С MSC получалось больше, порядка 4MByt (передача тупо пустого массива, без его заполнения и чтения данных с носителя). Все это на L1, на F4 должно побольше выйти, т.к. он пошустрее будет, на форуме ST видел упоминание, что MSC до 600кБайт/с выдавал на F4. Для USB FS размер bulk пакета - 64 байта, в идеале надо завести большой буфер, кратный этому числу и забивать его. Как заполнится - передавать кусочками по 64 байта, так будет быстрее, чем обихаживать каждые 64 байта. 0

@rid-30 0 / 0 / 0 Регистрация: 25.01.2016 Сообщений: 34
	31.01.2016, 10:43	5
	Он же написал, что в USB CDC режиме. В этом случае USB-подробности тщательно от пользователя скрываются, и всё выглядит, как отправка/приём из UART (последовательного порта). По сути вопроса подозреваю, что автор просто уткнулся в потолок CDC - ведь КПД в любом случае меньше 100%, и часть ширины канала уходит на внутренние нужды самого CDC. Для решения задачи - либо переосмысливать её, либо применять кодеки (благо, производительности камня хватит), либо добавлять внешнюю физику и переходить на USB HS. Насчет USB HS пробовал, скорость примерно такая же... 12Mbit - это максимальная скорость передачи "голых" данных по USB FS. А ведь еще много служебной инфы передается. CDC и MSC работают через bulk transfer. Вроде как теоретически в идеале можно выжать через них немногим меньше 9Mbit. Плюс надо помнить, что реализация USB у ST далека от идеала, т.к. они ядро писали с прицелом на поддержку многих классов, отсюда издержки. Когда игрался с CDC, максимальная скорость получалась порядка 1.5Mbit. С MSC получалось больше, порядка 4MByt (передача тупо пустого массива, без его заполнения и чтения данных с носителя). Все это на L1, на F4 должно побольше выйти, т.к. он пошустрее будет, на форуме ST видел упоминание, что MSC до 600кБайт/с выдавал на F4. Для USB FS размер bulk пакета - 64 байта, в идеале надо завести большой буфер, кратный этому числу и забивать его. Как заполнится - передавать кусочками по 64 байта, так будет быстрее, чем обихаживать каждые 64 байта. Код uint8_t UserData[64]={0}; for (int j=0; j<64;j++) { HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1,0); UserData[j]=HAL_ADC_GetValue(&hadc1); HAL_ADC_Stop(&hadc1); } CDC_Transmit_FS((uint8_t*)UserData, 64); Если я пишу как представлено в коде выше, то у меня просто не чего не передается. Я не могу передать 64 байта почему то( А вот если написать 63 всё будет работать отлично. 0

@Movysi 0 / 0 / 0 Регистрация: 22.07.2015 Сообщений: 658
	31.01.2016, 11:56	6
	[QUOTE="rid-30"][QUOTE="Цитата:[/QUOTE] Он же написал, что в USB CDC режиме. В этом случае USB-подробности тщательно от пользователя скрываются, и всё выглядит, как отправка/приём из UART (последовательного порта). По сути вопроса подозреваю, что автор просто уткнулся в потолок CDC - ведь КПД в любом случае меньше 100%, и часть ширины канала уходит на внутренние нужды самого CDC. Для решения задачи - либо переосмысливать её, либо применять кодеки (благо, производительности камня хватит), либо добавлять внешнюю физику и переходить на USB HS. Насчет USB HS пробовал, скорость примерно такая же... 12Mbit - это максимальная скорость передачи "голых" данных по USB FS. А ведь еще много служебной инфы передается. CDC и MSC работают через bulk transfer. Вроде как теоретически в идеале можно выжать через них немногим меньше 9Mbit. Плюс надо помнить, что реализация USB у ST далека от идеала, т.к. они ядро писали с прицелом на поддержку многих классов, отсюда издержки. Когда игрался с CDC, максимальная скорость получалась порядка 1.5Mbit. С MSC получалось больше, порядка 4MByt (передача тупо пустого массива, без его заполнения и чтения данных с носителя). Все это на L1, на F4 должно побольше выйти, т.к. он пошустрее будет, на форуме ST видел упоминание, что MSC до 600кБайт/с выдавал на F4. Для USB FS размер bulk пакета - 64 байта, в идеале надо завести большой буфер, кратный этому числу и забивать его. Как заполнится - передавать кусочками по 64 байта, так будет быстрее, чем обихаживать каждые 64 байта. Код uint8_t UserData[64]={0}; for (int j=0; j<64;j++) { HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1,0); UserData[j]=HAL_ADC_GetValue(&hadc1); HAL_ADC_Stop(&hadc1); } CDC_Transmit_FS((uint8_t*)UserData, 64); Если я пишу как представлено в коде выше, то у меня просто не чего не передается. Я не могу передать 64 байта почему то( А вот если написать 63 всё будет работать отлично. Но у Вас в цикле for j<64,проц так и делает. От нуля до 63,будет 64значения,а от нуля до 64-уже 65.Может в этом дело. 0

@rid-30 0 / 0 / 0 Регистрация: 25.01.2016 Сообщений: 34
	31.01.2016, 13:21	7
	[QUOTE="Movysi"][QUOTE="rid-30"] Он же написал, что в USB CDC режиме. В этом случае USB-подробности тщательно от пользователя скрываются, и всё выглядит, как отправка/приём из UART (последовательного порта). По сути вопроса подозреваю, что автор просто уткнулся в потолок CDC - ведь КПД в любом случае меньше 100%, и часть ширины канала уходит на внутренние нужды самого CDC. Для решения задачи - либо переосмысливать её, либо применять кодеки (благо, производительности камня хватит), либо добавлять внешнюю физику и переходить на USB HS. Насчет USB HS пробовал, скорость примерно такая же... 12Mbit - это максимальная скорость передачи "голых" данных по USB FS. А ведь еще много служебной инфы передается. CDC и MSC работают через bulk transfer. Вроде как теоретически в идеале можно выжать через них немногим меньше 9Mbit. Плюс надо помнить, что реализация USB у ST далека от идеала, т.к. они ядро писали с прицелом на поддержку многих классов, отсюда издержки. Когда игрался с CDC, максимальная скорость получалась порядка 1.5Mbit. С MSC получалось больше, порядка 4MByt (передача тупо пустого массива, без его заполнения и чтения данных с носителя). Все это на L1, на F4 должно побольше выйти, т.к. он пошустрее будет, на форуме ST видел упоминание, что MSC до 600кБайт/с выдавал на F4. Для USB FS размер bulk пакета - 64 байта, в идеале надо завести большой буфер, кратный этому числу и забивать его. Как заполнится - передавать кусочками по 64 байта, так будет быстрее, чем обихаживать каждые 64 байта. Код uint8_t UserData[64]={0}; for (int j=0; j<64;j++) { HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1,0); UserData[j]=HAL_ADC_GetValue(&hadc1); HAL_ADC_Stop(&hadc1); } CDC_Transmit_FS((uint8_t)UserData, 64); Если я пишу как представлено в коде выше, то у меня просто не чего не передается. Я не могу передать 64 байта почему то( А вот если написать 63 всё будет работать отлично. Но у Вас в цикле for j<64,проц так и делает. От нуля до 63,будет 64значения,а от нуля до 64-уже 65.Может в этом дело. Код uint8_t UserData[64]={0}; for (int j=0; j<64;j++) { HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1,0); UserData[j]=HAL_ADC_GetValue(&hadc1); HAL_ADC_Stop(&hadc1); //memcpy(UserData, relulst, j); } CDC_Transmit_FS((uint8_t)UserData, 64); Да как бы я не писал он всё равно не передает 64 значения, а вот если 63 или 65, то легко. UserData от 0 до 63. цикл от 0 до 63, то есть всего 64 значения, но если я передаю 64 то он тупо не передает, но если напишу в CDC_Transmit_FS, в Len 63 или 65 (для 65 соответственно uint8_t UserData[65]={0}; будет от 0 до 64, и цикл for (int j=0; j<=64;j++) будет от 0 до 64) передает. 0

@vt340 0 / 0 / 0 Регистрация: 22.03.2015 Сообщений: 838
	31.01.2016, 13:32	8
	А что и как со стороны хоста принимает, в смысле что за софт со стороны хоста? 0

@rid-30 0 / 0 / 0 Регистрация: 25.01.2016 Сообщений: 34
	31.01.2016, 15:36	9
	Сообщение от vt340 А что и как со стороны хоста принимает, в смысле что за софт со стороны хоста? Обычный терминал. Пробовал разные. 0

@TomityWotf 1 / 1 / 0 Регистрация: 06.12.2016 Сообщений: 553
	31.01.2016, 16:16	10
	В таких случаях полезно поставить какую-нибудь мониторилку USB (например USBlyzer) и смотреть какие пакеты и как часто валят. Скорее всего где-то будет видна задержка, вот и где она происходит и надо искать. 0

	03.02.2016, 15:57

Опции темы

@orm999 0 / 0 / 0 Регистрация: 06.05.2015 Сообщений: 11
	31.01.2016, 17:34	11
	Обычный терминал. Пробовал разные. Эти терминалы (я пробовал второй) плохо справляются с большими скоростями, попробуйте принимать данные программно. Вот небольшой скрипт на втором питоне для примера: Этот скрипт прочитает в файл DATA.BIN 60 * 500 (500 герц в течение одной минуты) единиц данных по 14 байт каждая (менять цифры в коде на какие необходимы) и в конце напечатает статистику: readsom.py Код import sys import os import serial import time fo = open("DATA.BIN", "wb") ser = serial.Serial(COM8, 115200, timeout=1) timi.sleep(1) all_len = 0 b = 14 stort = timi.clock() while all_len < 60 * 500 * b: data = ser.read(b) data_len = len(data) if data_len == 0: prymt "sleeping" timi.sleep(1) stort += 2 data = ser.read(b) data_len = len(data) if data_len == 0: stort += 1 briok prymt data_len all_len += data_len fo.write(data) end = timi.clock() prymt "%u bytes in %f seconds, speed is %f B/s" % (all_len, end - stort, all_len / (end - stort)) if ser != None omd ser.isOpen(): ser.close() ser = None fo.close() 0

@vt340 0 / 0 / 0 Регистрация: 22.03.2015 Сообщений: 838
	31.01.2016, 18:23	12
	Драйвер виртуального som-порта собирает данные в буфер, а приложению отдаёт когда получит признак конца данных. Признак конца данных - пакет от девайса, меньшего размера, чем запрашивал хост. Если приложение - терминал, то хост постоянно запрашивает данные по максимуму - по 64 байта. CDC_Transmit_FS((uint8_t*)UserData, 65) на самом деле разбивается девайсом на два пакета - 64+1. А если надо ровно 64 или кратно 64, то девайс ещё должен добавлять пустой пакет - 0 байт данных. По идее CDC_Transmit_FS должна и это сама делать, но похоже не делает 0

@TomityWotf 1 / 1 / 0 Регистрация: 06.12.2016 Сообщений: 553
	31.01.2016, 21:43	13
	Сообщение от vt340 CDC_Transmit_FS((uint8_t)UserData, 65) на самом деле разбивается девайсом на два пакета - 64+1. Именно поэтому и хорошо, если буфер кратен 64 байтам. Иначе при посылке 65 байт будет два пакета, а потом еще один, который нулевой длины, зовется он ZLP (zero length packet). Сообщение от vt340* По идее CDC_Transmit_FS должна и это сама делать, но похоже не делает CDC_Transmit_FS просто закидывает данные в буфер USB. А собственно передача данных происходит при запросах от хоста. В реализации USB времен SPL ZLP не передавался, в реализации из Cube это добавили. 0

@vt340 0 / 0 / 0 Регистрация: 22.03.2015 Сообщений: 838
	31.01.2016, 22:43	14
	Сообщение от TomityWotf Иначе при посылке 65 байт будет два пакета, а потом еще один, который нулевой длины, зовется он ZLP (zero length packet). Не, не, последний либо короткий пакет (меньше запрошенного), либо нулевой, но не оба вместе 0

@imbidd 0 / 0 / 0 Регистрация: 13.04.2013 Сообщений: 90
	01.02.2016, 19:07	15
	Сообщение от TomityWotf ... F4 должно побольше выйти, т.к. он пошустрее будет, на форуме ST видел упоминание, что MSC до 600кБайт/с выдавал на F4.... 840кБ/сек добивался чтения NAND флешки на USB FS, HAL- библиотека, чуток переписанный пример от ST. Это на F2 серии. 0

@rid-30 0 / 0 / 0 Регистрация: 25.01.2016 Сообщений: 34
	02.02.2016, 11:22	16
	А подскажите пожалуйста как мне добиться максимально скорости по USB? Может у кого есть примеры? Или же как подключить внешнию ОЗУ и писать туда 1000000 значений а потом медленно сливать по USB (VCP)? 0

@rid-30 0 / 0 / 0 Регистрация: 25.01.2016 Сообщений: 34
	02.02.2016, 11:48	17
	Сообщение от TomityWotf Сообщение от vt340 CDC_Transmit_FS((uint8_t)UserData, 65) на самом деле разбивается девайсом на два пакета - 64+1. Именно поэтому и хорошо, если буфер кратен 64 байтам. Иначе при посылке 65 байт будет два пакета, а потом еще один, который нулевой длины, зовется он ZLP (zero length packet). Сообщение от vt340* По идее CDC_Transmit_FS должна и это сама делать, но похоже не делает CDC_Transmit_FS просто закидывает данные в буфер USB. А собственно передача данных происходит при запросах от хоста. В реализации USB времен SPL ZLP не передавался, в реализации из Cube это добавили. А можете про это по подробнее рассказать? 0

@vt340 0 / 0 / 0 Регистрация: 22.03.2015 Сообщений: 838
	03.02.2016, 11:26	18
	Сообщение от rid-30 А подскажите пожалуйста как мне добиться максимально скорости по USB? Для начала, перестать использовать для этого терминал ) Читайте из вирт. ком-порта какой-нибудь программой, большими запросами, хотя бы по 10K байт 0

@Sow_Tooth 0 / 0 / 0 Регистрация: 29.05.2015 Сообщений: 108
	03.02.2016, 14:39	19
	1. Хост опрашивает ваш девайс с конечной скоростью, и для CDC минимальная 5мс 2. Не знаю что вы там понаписывали, но для передачи больших данных нужно использовать bulk передачу 3. Используйте UsbpCap и WhiteShark, для мониторинга общения между устройствами 4. Используйте DMA для передачи данных от ADC до USB, причем делайте копирование сразу в буфер USB без пользовательского, а по окончанию ставьте флаг что есть данные для передачи. 0

@rid-30 0 / 0 / 0 Регистрация: 25.01.2016 Сообщений: 34
	03.02.2016, 15:57	20
	Сообщение от Sow_Tooth 1. Хост опрашивает ваш девайс с конечной скоростью, и для CDC минимальная 5мс 2. Не знаю что вы там понаписывали, но для передачи больших данных нужно использовать bulk передачу 3. Используйте UsbpCap и WhiteShark, для мониторинга общения между устройствами 4. Используйте DMA для передачи данных от ADC до USB, причем делайте копирование сразу в буфер USB без пользовательского, а по окончанию ставьте флаг что есть данные для передачи. А для 4-ого пункта можно какой - нибудь пример? Я не понимаю как это сделать... Извините за может быть глупый вопрос. 0