Trinamic делает так: ставит на мотор с энкодером контроллер с мощным процессором (они их заклеивают, а частично какой-то эпоксидкой езе заливают, но где-то я читал, что не слабже STM32), который следит за командами по RS-485 (например). Исполняет их и взаимодействует с энкодером. Т.е. PC может дать команду - повернуть на 32 градуса и сам контроллер этим займется. При движении, в обратную сторону по 485-му летят данные - скорость и позиция энкодера. Во всяком случае их софтина рисует разгонную кривую и тормозной путь. Не скажу, что рисует в рилтайме, отставание какое-то есть. Для серьезных применений у них имеется TMCL. Пишешь на нем программу, заливаешь на контроллер и он сам сутками хоть кривые выписывает, хоть резьбу с переменным шагом нарезает.
А тринамик-то в двигателях понимает.
Спасибо! Мы в свое время приобрели шаговик компании Сервотехника. Это очень сложное устройство с мощным процессором и многими потоками выполнения с разными приоритетами. Мне про это сами разработчики рассказывали. Так вот, с компом двигатель общается и по usb в тестовом режиме. А при работе в боевом режиме рекомендуют использовать CAN протокол причем мы приобретали адаптер usb-can и реальная программа работала именно через can протокол.
Причем, я смотрю сейчас документацию на двигатель, с которым дело имел, он на 9600 вообще болтает. Никаких мегабодов там нет. Но он и не сильно быстрый, конечно.
Ну допустим, захотелось культурному и грамотному челу узнать что в плане скорости может ftgi и ch340. Какого для этого срач на форуме городить и кривые опыты ставить. Открой бля доки!
Все видно? Чё там еще в твоем никчемном канале обмена? Атмега - те сказали, максимум CLK/8. Толко надо правильные мозги иметь чтоб столько получить. USB - так если ты такой продвинутый по работе с ним должен знать о его режимах и ограничении скорости в CDC. А винда ниграме не реалтайм, она не обязана сообщать точное время прихода каждого байта, буферирует как считает нужным. Но над фактом того что в этот же разем USB вставленая флешка работает побыстрей чем цифры выше, можна и задуматся чтоб решить надо ли винду тестить.
Отсюда вывод: у ТС будет тормозня в атмеге т.к. хрен напишеш код, приближающийся к её максимуму. На этом и остановимся, поскольку для способных выжать те самые CLK/8 это все не интересно, а ТС не актуально.
Ну вот и ты туда же. ) Никто не говорит что надо получать теоретический максимум) Насчёт ассемблера, применим без проблем. Оптимизация процесс поэтапный ) Теперь по поводу usb. Да в нем как известно для разного типа информации разный приоритет и разное время доставки. Вот это и побудило провести эксперимент. Флешка ясно почему работает быстрее. Ее поток данных имеет высокий приоритет плюс пакеты ее между контрольными точками доставляются максимально полными. А я как раз имею коротенькие сообщения. Но протокол rs-232 ни разу не пакетный. То есть это уже особенности реализации виртуального com порта.
//Никто не говорит что надо получать теоретический максимум
Если его, т.е. 2МВ, не получить, то не выйдет загрузить ftgi и ch340 на их пределы, 3 и 2МВ соответственно, а очевидно что до них они справятся, согласно спекам. Значить узреть разницу между ними ну никак не получится, твои 0,5МВ все элементы канала пропустят с запасом. А сокращение CDC интереса я так понимаю вобще не вызвало. Ну и ладно ;)
//Никто не говорит что надо получать теоретический максимум
Если его, т.е. 2МВ, не получить, то не выйдет загрузить ftgi и ch340 на их пределы, 3 и 2МВ соответственно, а очевидно что до них они справятся, согласно спекам. Значить узреть разницу между ними ну никак не получится, твои 0,5МВ все элементы канала пропустят с запасом. А сокращение CDC интереса я так понимаю вобще не вызвало. Ну и ладно ;)
Вызвало ) То есть ты уверен что драйвер для режима CDC что для ch340 что для ftdi работает одинаково ??? Если ты это точно знаешь, спасибо за информацию.
Просто в качестве комментария: на алиэкспрессах встречаются разные там RS232 TTL уровня. Я как-то покопал в ту область и обнаружил, что это относится только к микрухам от FT с номером модели 232. Совпадение ли такой номер или он несет тайный смысл - я не знаю. По даташиту в эту МС входит USB, выходит UART. Ну и наоборот.
Просто в качестве комментария: на алиэкспрессах встречаются разные там RS232 TTL уровня. Я как-то покопал в ту область и обнаружил, что это относится только к микрухам от FT с номером модели 232. Совпадение ли такой номер или он несет тайный смысл - я не знаю. По даташиту в эту МС входит USB, выходит UART. Ну и наоборот.
Спасибо! Я вроде бы читал что стандарт rs-232 состоит из нескольких частей и электрическая лишь одна из.
Задача в том чтобы управлять с Ардуино двумя двигателями шаговыми и обратно получать уведомления на комп в какой позиции двигатель сейчас находится. Уведомления поступают только при вращении и через каждые 11 позиций. То есть где то через градус. Плюс ещё уведомления об успешном исполнении команды которую послали двигателям и уведомление об окончании движения. Двигатель имеет 4096 позиций с учётом редуктора. Так что при скорости даже в 70 градусов в секунду время между двумя шагами составляет около 1,2 миллисекунды. То есть в реальной задаче большого траффика не предвидится. Единственно с разницей в два два шага могут прийти уведомления об успешности команды и о достижении очередной позиции кратной 11 шагам.
sadman41 пишет:
Trinamic делает так: ставит на мотор с энкодером контроллер с мощным процессором (они их заклеивают, а частично какой-то эпоксидкой еще заливают, но где-то я читал, что не слабже STM32), который следит за командами по RS-485 (например). Исполняет их и взаимодействует с энкодером. Т.е. PC может дать команду - повернуть на 32 градуса и сам контроллер этим займется. При движении, в обратную сторону по 485-му летят данные - скорость и позиция энкодера. Во всяком случае их софтина рисует разгонную кривую и тормозной путь. Не скажу, что рисует в рилтайме, отставание какое-то есть. Для серьезных применений у них имеется TMCL. Пишешь на нем программу, заливаешь на контроллер и он сам сутками хоть кривые выписывает, хоть резьбу с переменным шагом нарезает.
sadman41 пишет:
... Причем, я смотрю сейчас документацию на двигатель, с которым дело имел, он на 9600 вообще болтает. Никаких мегабодов там нет. Но он и не сильно быстрый, конечно.
wdrakula пишет:
Разумно ставить задачу так, чтобы Винда давала МК задание в виде: ... Ну что-то в этом роде. А МК отчитывался бы о текущем статусе, ошибке, если есть и т.п. То есть не управлять движением в РТ.
Собственно все три поста, КМК и есть подсказки к решению: переформулировать задачу так, чтобы Ардуино решала все что нужно в РТ, а с компом только связывалась для получения команд и обратной отчетности .. возможно и вовсе "постфактум" отправляла данные о разгоне, торможении и т.д., накапливая внутри себя чего надо. Не нужно с компа указывать дуньке КАК ей и что делать.
SergeiSX, а тогда какой тайный смысл в поиске предельной скорости UART дуньки?
Тут даже не надо ничего экспериментировать: 2мегабода по даташиту. 10 бит на байт = 200кб/сек. или около 5 микросекунд на программную подготовку байта при побайтной пересылке. Буферизация облегчит задачу, но не сильно, ибо буфер тоже надо готовить.
на 16Мгц, 5мксек это .. около 80 тактов, а учитывая что доля команд с памятью высока (буфер), то немногим более 40 команд камня. Это практически "ниочем". То есть, орать в провод с такой скоростью оно может, но только теоретически. А Вам же хочется чтобы дунька ещё что-то и делала, так ведь!
Отсюда, сразу можно понять что "предельная скорость" FTDI или CH340 .. роялей не играет никакой. А важно, реконфигурировать задачу так, чтобы скорость UART-USB была не самым критичным параметром.
А лучше ваще никаким. 9600 - вполне должно стать достаточно.
SergeiSX, а тогда какой тайный смысл в поиске предельной скорости UART дуньки?
Тут даже не надо ничего экспериментировать: 2мегабода по даташиту. 10 бит на байт = 200кб/сек. или около 5 микросекунд на программную подготовку байта при побайтной пересылке. Буферизация облегчит задачу, но не сильно, ибо буфер тоже надо готовить.
на 16Мгц, 5мксек это .. около 80 тактов, а учитывая что доля команд с памятью высока (буфер), то немногим более 40 команд камня. Это практически "ниочем". То есть, орать в провод с такой скоростью оно может, но только теоретически. А Вам же хочется чтобы дунька ещё что-то и делала, так ведь!
Отсюда, сразу можно понять что "предельная скорость" FTDI или CH340 .. роялей не играет никакой. А важно, реконфигурировать задачу так, чтобы скорость UART-USB была не самым критичным параметром.
А лучше ваще никаким. 9600 - вполне должно стать достаточно.
Со скоростью конечно. Но судя по всему драйвер винды может быть разным для CH340 и FTDI. Я хочу померять в программе на Винде весь цикл обмена.
Со скоростью конечно. Но судя по всему драйвер винды может быть разным для CH340 и FTDI. Я хочу померять в программе на Винде весь цикл обмена.
Возможно. В разных сортах гумна (винде) - не разбираюсь, так шта .. что там с драйверами - пофиг. Скорее всего надо менять не только весь цикл обмена но и уровень делегирования микроконтроллеру. Вы бы огласили весь список, озвучили всю задачу ..
Со скоростью конечно. Но судя по всему драйвер винды может быть разным для CH340 и FTDI. Я хочу померять в программе на Винде весь цикл обмена.
Возможно. В разных сортах гумна (винде) - не разбираюсь, так шта .. что там с драйверами - пофиг. Скорее всего надо менять не только весь цикл обмена но и уровень делегирования микроконтроллеру. Вы бы огласили весь список, озвучили всю задачу ..
Да собственно я выше описывал про два двигателя. Это и вся задача. Можно здесь делать ссылки на посты выше???
Да собственно я выше описывал про два двигателя. Это и вся задача. Можно здесь делать ссылки на посты выше???
Фиг его знает .. надеюсь потрут завтра. С дураками, всё одно иначе - нельзя.
Там озвучено, что Вы хотите крутить два шаговика с хорошей точностью и свистеть в уарт на комп о текущем состоянии. Но .. это не совсем есть "задача". Оно же не просто так надо .. или это тупо "стенд" какой-то?
Если "стенд" (студентам показать как оно вертится), то понятно. Но и тут, микроконтроллер может получать "крупную" команду типа "встать через 30 градусов", и по мере управления движками (тогда нафиг их два?) собирать диагностику (движение, разгон, торможение, ошибки) и пачками свистеть в комп "по завершению команды" .. или по мере её исполнения.
Но .. у Вас 2 двигла, а стало быть это управление в двух координатах .. столик? А если это некая шелезяка, то нафиг свистеть на комп в режиме практически онлайн? "Я поехал сюда".. компу не все равно "как" он поехал, если микроконтроллер самостоятельно может обнаружить ошибку и её исправить?
Я - про эту часть "задачи".. переформулировать похоже надо с самого верху.
Да собственно я выше описывал про два двигателя. Это и вся задача. Можно здесь делать ссылки на посты выше???
Фиг его знает .. надеюсь потрут завтра. С дураками, всё одно иначе - нельзя.
Там озвучено, что Вы хотите крутить два шаговика с хорошей точностью и свистеть в уарт на комп о текущем состоянии. Но .. это не совсем есть "задача". Оно же не просто так надо .. или это тупо "стенд" какой-то?
Если "стенд" (студентам показать как оно вертится), то понятно. Но и тут, микроконтроллер может получать "крупную" команду типа "встать через 30 градусов", и по мере управления движками (тогда нафиг их два?) собирать диагностику (движение, разгон, торможение, ошибки) и пачками свистеть в комп "по завершению команды" .. или по мере её исполнения.
Но .. у Вас 2 двигла, а стало быть это управление в двух координатах .. столик? А если это некая шелезяка, то нафиг свистеть на комп в режиме практически онлайн? "Я поехал сюда".. компу не все равно "как" он поехал, если микроконтроллер самостоятельно может обнаружить ошибку и её исправить?
Я - про эту часть "задачи".. переформулировать похоже надо с самого верху.
Ну вот добрался до компа с интернетом)))) Задача состоит в том чтобы мерять с разных направлений в пространстве мощность звука. Для этого делается небольшое ОПУ с маленькими шаговиками. Далее планируется задать набор азимутов и углов места дабы померять в этих точках мощность звука. Крутить с огромной скоростью не нужно. Но понятно что если положений будет много то при сильно малой скорости перемещения из точки в точку мерять придется довольно долго. Поэтому и встал вопрос какие вообще максимальные скорости по вращению можно будет задавать. Ну и отсюда следствие, с какой скоростью надо уметь обрабатывать уведомления от шаговиков. Концепция в которой контроллер обслуживает перемещения по командам от компа и потом лишь сообщает об окончании перемещения я считаю что правильная. Так собственно сейчас и работает первый тестовый макет. Еще принимаю уведомления "ОК" или "ОF" что означает команда успешна или неуспешна сразу после посылки самой команды и установки задания на вращение. То есть вполне себе рабочая задача. Я попытался отключив предварительно двигатели от платы Ардуино задать нереальную скорость вращения (300 градусов в секунду, двигатели так не смогут эти вращаться) и протестировать программные комплекс в стрессовом режиме. И вот тут то и столкнулся что программа на компе запаздывает с приемом уведомлений. Редко но это случается в одном цикле съема по всем точкам. И я тогда решил проверить а какова максимальная производительность виртуального COM порта в связке с Windows. Еще узнал что для микросхем семейсва FTDI драйвер в Windows ставится автоматически а для CH340 его нужно специально ставить. Стало быть драйверы разные. В общем думаю правильно протестировать одну транзакцию со стороны компьютера (то есть передача данных и прием данных ) с помощью таймера высокого разрешения.
function TSerialSimple.Get(p: PByte; Cnt: Integer): Boolean;
var
nCnt: Cardinal;
begin
Result := False;
if h <> INVALID_HANDLE_VALUE then
begin
if ReadFile(h, p^, Cnt, nCnt, nil) then
begin
if Cnt = nCnt then
begin
Result := True;
end
else
begin
nCnt := 0;
end;
end;
end;
end;
function TSerialSimple.Put(p: PByte; Cnt: Integer): Boolean;
var
nCnt: Cardinal;
begin
Result := False;
if h <> INVALID_HANDLE_VALUE then
begin
if WriteFile(h, p^, Cnt, nCnt, nil) then
begin
if nCnt = Cnt then
begin
Result := True;
end;
end;
end;
end;
И код в основной программе
str := ''#$a;
sw := TStopwatch.Create;
sw.Start;
m_SerialS.Put(PByte(PAnsiChar(str)), 1);
m_SerialS.Get(PByte(PAnsiChar(sAll)), 1);
sw.Stop;
Я потестировал программу на Ардуино приема и передачи одного символа обратно. Работает отлично! И времена близки к теоретическому. А вот тест кода доступа к COM порту через Windows API разочаровывает. Надеюсь на то что делаю что - то неправильно. Упростил функцию приема до предела. В принципе так же делается в putty. И тут же получаю 1 миллисекунду даже при приеме одного символа. Если убрать Get получается порядка 40 микросекунд что вполне приемлемо. То есть прием символа длится очень долго даже если плата Ардуино посылает его быстро. Лишь бы это не были задержки в самих функциях Windows API при доступе к порту. Последняя надежда что сам что - то не настраиваю правильно.
И вот тут то и столкнулся что программа на компе запаздывает с приемом уведомлений. Редко но это случается в одном цикле съема по всем точкам. И я тогда решил проверить а какова максимальная производительность виртуального COM порта в связке с Windows.
Вам же Логик уже писал, что винда не реал таймовая система. В свое время, когда строили свою сеть с гарантированным временем отклика, пришлось написать свой драйвер под винду, а в дальнейшем со стороны компа поставить отдельный контроллер, который держит сетку устройств в реал тайме и имеет приличный буфер, а с компом общается прямо по усби.
И вот тут то и столкнулся что программа на компе запаздывает с приемом уведомлений. Редко но это случается в одном цикле съема по всем точкам. И я тогда решил проверить а какова максимальная производительность виртуального COM порта в связке с Windows.
Вам же Логик уже писал, что винда не реал таймовая система. В свое время, когда строили свою сеть с гарантированным временем отклика, пришлось написать свой драйвер под винду, а в дальнейшем со стороны компа поставить отдельный контроллер, который держит сетку устройств в реал тайме и имеет приличный буфер, а с компом общается прямо по усби.
Ну чтобы настолько не реал тайм... При виртуальном ком порту по usb... Драйвер то можно написать... Но настолько большая задержка при приеме...
Но судя по всему драйвер винды может быть разным для CH340 и FTDI. Я хочу померять в программе на Винде весь цикл обмена.
"Программа на Винде" IMHO должна не сама по себе обмерять передачу по COM-порту, а лишь принимать данные с логичекого анализатора и аккуратно рисовать их на экране. А сам "обмер" должен делать именно логический анализатор. Сразу будут видны и скорость передачи, и структура посылки, и интервал между посылками...
PS. В целом согласен с коллегами, что при правильно спроектированном обмере между Arduino и ПК скорости 9600 должно быть за глаза.
Но судя по всему драйвер винды может быть разным для CH340 и FTDI. Я хочу померять в программе на Винде весь цикл обмена.
"Программа на Винде" IMHO должна не сама по себе обмерять передачу по COM-порту, а лишь принимать данные с логичекого анализатора и аккуратно рисовать их на экране. А сам "обмер" должен делать именно логический анализатор. Сразу будут видны и скорость передачи, и структура посылки, и интервал между посылками...
PS. В целом согласен с коллегами, что при правильно спроектированном обмере между Arduino и ПК скорости 9600 должно быть за глаза.
Но ведь уведомления от контроллера надо принимать? Надо... И если время приема не может быть быстрее 1 миллисекунды то и скорость вращения должна быть ограничена. В принципе этого то хватит но не совсем понятно что так тормозит прием сообщения, сами функции WinAPI или драйвер.
если время приема не может быть быстрее 1 миллисекунды то и скорость вращения должна быть ограничена.
Откуда это следует?
Следует что? Что время приема в программе на компьютере не менее 1 миллисекунды даже одного символа? Это следует из измерений с помощью функций высокого разрешения. А то что скорость ограничена это следует из того что на морде лица пользовательского интерфейса программы надо обновлять индикаторы положения двигателей хотя бы раз в градус иначе будут рывки а это раздражает пользователя. И это не реальное время это разумная задержка реакции.
А то что скорость ограничена это следует из того что на морде лица пользовательского интерфейса программы надо обновлять индикаторы положения двигателей хотя бы раз в градус иначе будут рывки а это раздражает пользователя. И это не реальное время это разумная задержка реакции.
Из чего следует неизбежность возникновения рывков в зависимости от скорости индикации "хотя бы раз в градус"?
Вы всерьез считаете, что если при скорости вращения 10000 об/мин показания на индикаторе не будут обновляться с частотой 60000 FPS, рывки неизбежны?
А то что скорость ограничена это следует из того что на морде лица пользовательского интерфейса программы надо обновлять индикаторы положения двигателей хотя бы раз в градус иначе будут рывки а это раздражает пользователя. И это не реальное время это разумная задержка реакции.
Из чего следует неизбежность возникновения рывков в зависимости от скорости индикации "хотя бы раз в градус"?
Вы всерьез считаете, что если при скорости вращения 10000 об/мин показания на индикаторе не будут обновляться с частотой 60000 FPS, рывки неизбежны?
Я понимаю Ваш вопрос. Я объясню. У меня скорость измеряется в градусах в секунду. И более 70 градусов в секунду данные шаговики в принципе отрабатывают неважно. Так что скорость вращения как в РЛС мне не грозит. Кстати я описывал условия задачи выше. Поэтому при такой скорости вращения отображать текущее положение двигателей вполне реально. Опорно-поворотное устройство быстрее и нет смысла вращать. Экспериментально убедились что отображать положение ротора чаще чем раз в градус нецелесообразно а реже видны скачки индикатора.
Я понимаю Ваш вопрос. Я объясню. У меня скорость измеряется в градусах в секунду. И более 70 градусов в секунду данные шаговики в принципе отрабатывают неважно. Так что скорость вращения как в РЛС мне не грозит.
Сначала Вы жалуетесь на то, что есть какие-то проблемы при высоких скоростях вращения.
Я Вам привожу пример, что при скорости 10000 проблем быть не должно.
И возражений от Вас по этому поводу я не наблюдаю.
Цитата:
Экспериментально убедились что отображать положение ротора чаще чем раз в градус нецелесообразно а реже видны скачки индикатора.
Вы просто эксперименты до конца не довели. Если бы продвинулись чуть дальше, то обнаружили бы, что обновлять показания индикатора чаще N раз в секунду нецелесообразно вне зависимости от скорости вращения. На практике N обычно выбирают в пределах от 2 до 10. Даже в кино N=24.
Другими словами, шаг приращения показаний индикатора должен зависеть от скорости вращения, постоянным ему быть совершенно ни к чему. А вот постоянный интервал обновления - идея вполне здравая. Например, можно отсылать положение вала 5 раз в секунду, притом даже в том случае, если вал стоит на месте.
Я понимаю Ваш вопрос. Я объясню. У меня скорость измеряется в градусах в секунду. И более 70 градусов в секунду данные шаговики в принципе отрабатывают неважно. Так что скорость вращения как в РЛС мне не грозит.
Сначала Вы жалуетесь на то, что есть какие-то проблемы при высоких скоростях вращения.
Я Вам привожу пример, что при скорости 10000 проблем быть не должно.
И возражений от Вас по этому поводу я не наблюдаю.
Цитата:
Экспериментально убедились что отображать положение ротора чаще чем раз в градус нецелесообразно а реже видны скачки индикатора.
Вы просто эксперименты до конца не довели. Если бы продвинулись чуть дальше, то обнаружили бы, что обновлять показания индикатора чаще N раз в секунду нецелесообразно вне зависимости от скорости вращения. На практике N обычно выбирают в пределах от 2 до 10. Даже в кино N=24.
Другими словами, шаг приращения показаний индикатора должен зависеть от скорости вращения, постоянным ему быть совершенно ни к чему. А вот постоянный интервал обновления - идея вполне здравая. Например, можно отсылать положение вала 5 раз в секунду, притом даже в том случае, если вал стоит на месте.
Спасибо Большое! Идея очень хорошая! Думаю так и сделать.
Задача состоит в том чтобы мерять с разных направлений в пространстве мощность звука. Для этого делается небольшое ОПУ с маленькими шаговиками. Далее планируется задать набор азимутов и углов места дабы померять в этих точках мощность звука. Крутить с огромной скоростью не нужно. Но понятно что если положений будет много то при сильно малой скорости перемещения из точки в точку мерять придется довольно долго. Поэтому и встал вопрос какие вообще максимальные скорости по вращению можно будет задавать. Ну и отсюда следствие, с какой скоростью надо уметь обрабатывать уведомления от шаговиков. Концепция в которой контроллер обслуживает перемещения по командам от компа и потом лишь сообщает об окончании перемещения я считаю что правильная. Так собственно сейчас и работает первый тестовый макет. Еще принимаю уведомления "ОК" или "ОF" что означает команда успешна или неуспешна сразу после посылки самой команды и установки задания на вращение. То есть вполне себе рабочая задача. Я попытался отключив предварительно двигатели от платы Ардуино задать нереальную скорость вращения (300 градусов в секунду, двигатели так не смогут эти вращаться) и протестировать программные комплекс в стрессовом режиме. И вот тут то и столкнулся что программа на компе запаздывает с приемом уведомлений. Редко но это случается в одном цикле съема по всем точкам. И я тогда решил проверить а какова максимальная производительность виртуального COM порта в связке с Windows. Еще узнал что для микросхем семейсва FTDI драйвер в Windows ставится автоматически а для CH340 его нужно специально ставить. Стало быть драйверы разные. В общем думаю правильно протестировать одну транзакцию со стороны компьютера (то есть передача данных и прием данных ) с помощью таймера высокого разрешения.
Во-от. Оказывается что стоит совсем иная задача, а свист в комп данными с движка в общем-то и не требуется вовсе.. :)
попытаюсь переформулировать вашу задачу, может так будет проще:
С компа задается набор азимутов и мест, с направлений и в которых прибор должен измерить мощность звука и отправить результат на комп взад.
Так - совсем нет никакой "скоростной" передачи обратно на комп, и с него на прибор. Свистнули заданной программой измерений, прибор отработал и отствистелся компу сколько намерял. Объем пересылок - ровно сложность программы (количество направлений и узлов) и количество проведенных замеров: по кол-ву направлений и "микрофонов".
Суммарное время пересылки "туда и обратно" - не более времени очередной партии замеров по программе, которое определяется скоростью проведения одного замера и их количеством и .. достаточно велико.
То есть, приняли программу, пошли замерять и накапливать массив отклика. В это же время спокойно можем принимать следующую программу. Завершили первую - начали свистеть обратно данными, одновременно можем принимать очередную порцию программы. Требуется по 2 буфера на размер программы и результатов. Первый - исполняемая программа замеров, второй - принимаемая следующая программа. И по результатам: один буфер высвистываем, второй заполняем.
Верно?
P.S. Чем-то напоминает нашу установку "уши робота", когда планировали слушать противника на трассе и определять его местоположение, дабы избежать столкновений.. Уши - два микрофона с раструбами для лучшей локализации звука на серводвигателе SG-90. :)
Но, мы тогда пошли чуть иначе: сразу заводили сигнал от обоих микрофонов на дифференциальный вход Меги и по разностному уровню крутили серву на макс. сигнал. Получалось не шустро, но практически "беззатратно". :)
Кстати, нифига себе вы все поднимаетесь! Я в полдесятого встал, и то только потому, что сволочи электрики меняют провода по всему частному сектору на СИП. И под радостный писк УПС я иду заводить генератор... мля! 10л каждый день! И это называется "бесплатная замена".
-------------------------------------
Так. посоветовавшись со спецами по Винде (я сам очень давно на ...никсах, сперва на Фри, теперь на Линухе), я получил внятный ответ, и даже некий "пруф" на дискуссию в РСДН.
Так вот: Отклик от Винды, аккуратнее 1 мс, получить невозможно вообще.
Таким образом ставится точка в исследованиях. Если интересно построить честные тесты, то стенд я заготовил, в виде W8.1-32 на виртуалке, запихнул туда драйвера плат, среду, последний Питон. Материнский комп 4 ядра, 8Гиг, виртуализация Vbox, аппаратная. То есть на все хватит. Плат с FTDI у меня, конечно, нет. Но, поверь опыту, драйвера почти одинаковые.FTDI больше плюшек поддерживает, поэтому возможностей настройки больше, но в работе - никакой разницы быть не может. Поиграй с приоритетом и квантами, как на виндовых форумах пишут. Но правильное решение мы уже предложили - обновление интерфейса 15-20 раз в сек, на основании имеющихся и (возможно) прогнозных данных, получаемых от контроллера ассинхронно, с разумной скоростью передачи.
Мне - не очень уже интересно... Как у доктора Хауса - диагноз поставлен, остальное - муть. Но если что-то не получится с тестами - пиши.
----------------------
Решил добавить про твои тесты:
Ты измеряешь разовые события, это неправильно. Потому, что система работает ассинхронно. Могут быть прерывания от чего-то, да хоть от сети.
Нужно делать серию однотипных действий - например погонять случайные числа с компа на контроллер и обратно, и измерять среднее время. Серия из пар передач туда-обратно, серия из 10 последовательный передач, среднее, среднее на одну передачу. Посмотреть вариабельность. Нагрузить комп закачкой тррента и компиляцией какого-нить монстра, повторить тесты на нагруженном компе, нагрузитиь закачкой с USB драйва и повторить.
Задача состоит в том чтобы мерять с разных направлений в пространстве мощность звука. Для этого делается небольшое ОПУ с маленькими шаговиками. Далее планируется задать набор азимутов и углов места дабы померять в этих точках мощность звука. Крутить с огромной скоростью не нужно. Но понятно что если положений будет много то при сильно малой скорости перемещения из точки в точку мерять придется довольно долго. Поэтому и встал вопрос какие вообще максимальные скорости по вращению можно будет задавать. Ну и отсюда следствие, с какой скоростью надо уметь обрабатывать уведомления от шаговиков. Концепция в которой контроллер обслуживает перемещения по командам от компа и потом лишь сообщает об окончании перемещения я считаю что правильная. Так собственно сейчас и работает первый тестовый макет. Еще принимаю уведомления "ОК" или "ОF" что означает команда успешна или неуспешна сразу после посылки самой команды и установки задания на вращение. То есть вполне себе рабочая задача. Я попытался отключив предварительно двигатели от платы Ардуино задать нереальную скорость вращения (300 градусов в секунду, двигатели так не смогут эти вращаться) и протестировать программные комплекс в стрессовом режиме. И вот тут то и столкнулся что программа на компе запаздывает с приемом уведомлений. Редко но это случается в одном цикле съема по всем точкам. И я тогда решил проверить а какова максимальная производительность виртуального COM порта в связке с Windows. Еще узнал что для микросхем семейсва FTDI драйвер в Windows ставится автоматически а для CH340 его нужно специально ставить. Стало быть драйверы разные. В общем думаю правильно протестировать одну транзакцию со стороны компьютера (то есть передача данных и прием данных ) с помощью таймера высокого разрешения.
Во-от. Оказывается что стоит совсем иная задача, а свист в комп данными с движка в общем-то и не требуется вовсе.. :)
попытаюсь переформулировать вашу задачу, может так будет проще:
С компа задается набор азимутов и мест, с направлений и в которых прибор должен измерить мощность звука и отправить результат на комп взад.
Так - совсем нет никакой "скоростной" передачи обратно на комп, и с него на прибор. Свистнули заданной программой измерений, прибор отработал и отствистелся компу сколько намерял. Объем пересылок - ровно сложность программы (количество направлений и узлов) и количество проведенных замеров: по кол-ву направлений и "микрофонов".
Суммарное время пересылки "туда и обратно" - не более времени очередной партии замеров по программе, которое определяется скоростью проведения одного замера и их количеством и .. достаточно велико.
То есть, приняли программу, пошли замерять и накапливать массив отклика. В это же время спокойно можем принимать следующую программу. Завершили первую - начали свистеть обратно данными, одновременно можем принимать очередную порцию программы. Требуется по 2 буфера на размер программы и результатов. Первый - исполняемая программа замеров, второй - принимаемая следующая программа. И по результатам: один буфер высвистываем, второй заполняем.
Верно?
P.S. Чем-то напоминает нашу установку "уши робота", когда планировали слушать противника на трассе и определять его местоположение, дабы избежать столкновений.. Уши - два микрофона с раструбами для лучшей локализации звука на серводвигателе SG-90. :)
Но, мы тогда пошли чуть иначе: сразу заводили сигнал от обоих микрофонов на дифференциальный вход Меги и по разностному уровню крутили серву на макс. сигнал. Получалось не шустро, но практически "беззатратно". :)
С точки зрения вращения все верно, а вот съем будет вестись отдельной платой АЦП прямо на компе. То есть координировать увы должна программа на компе. Я поэтому и настаиваю на уведомлениях. Просто АЦП уже есть и менять стратегию начальство не позволит. Хотя Ваша идея прилично бы разгрузилась комп и позволила бы уйти от завязок на скорость реакции.
Trinamic делает так: ставит на мотор с энкодером контроллер с мощным процессором (они их заклеивают, а частично какой-то эпоксидкой езе заливают, но где-то я читал, что не слабже STM32), который следит за командами по RS-485 (например). Исполняет их и взаимодействует с энкодером. Т.е. PC может дать команду - повернуть на 32 градуса и сам контроллер этим займется. При движении, в обратную сторону по 485-му летят данные - скорость и позиция энкодера. Во всяком случае их софтина рисует разгонную кривую и тормозной путь. Не скажу, что рисует в рилтайме, отставание какое-то есть. Для серьезных применений у них имеется TMCL. Пишешь на нем программу, заливаешь на контроллер и он сам сутками хоть кривые выписывает, хоть резьбу с переменным шагом нарезает.
А тринамик-то в двигателях понимает.
Спасибо! Мы в свое время приобрели шаговик компании Сервотехника. Это очень сложное устройство с мощным процессором и многими потоками выполнения с разными приоритетами. Мне про это сами разработчики рассказывали. Так вот, с компом двигатель общается и по usb в тестовом режиме. А при работе в боевом режиме рекомендуют использовать CAN протокол причем мы приобретали адаптер usb-can и реальная программа работала именно через can протокол.
Ну, CAN тоже неплохо. Как-никак промышленный стандарт. Тринамик тоже умеет с ним работать: https://www.trinamic.com/products/drives/
Причем, я смотрю сейчас документацию на двигатель, с которым дело имел, он на 9600 вообще болтает. Никаких мегабодов там нет. Но он и не сильно быстрый, конечно.
Бля, ну и охота ж людям херней страдать?!
Ну допустим, захотелось культурному и грамотному челу узнать что в плане скорости может ftgi и ch340. Какого для этого срач на форуме городить и кривые опыты ставить. Открой бля доки!
Все видно? Чё там еще в твоем никчемном канале обмена? Атмега - те сказали, максимум CLK/8. Толко надо правильные мозги иметь чтоб столько получить. USB - так если ты такой продвинутый по работе с ним должен знать о его режимах и ограничении скорости в CDC. А винда ниграме не реалтайм, она не обязана сообщать точное время прихода каждого байта, буферирует как считает нужным. Но над фактом того что в этот же разем USB вставленая флешка работает побыстрей чем цифры выше, можна и задуматся чтоб решить надо ли винду тестить.
Отсюда вывод: у ТС будет тормозня в атмеге т.к. хрен напишеш код, приближающийся к её максимуму. На этом и остановимся, поскольку для способных выжать те самые CLK/8 это все не интересно, а ТС не актуально.
Ну вот и ты туда же. ) Никто не говорит что надо получать теоретический максимум) Насчёт ассемблера, применим без проблем. Оптимизация процесс поэтапный ) Теперь по поводу usb. Да в нем как известно для разного типа информации разный приоритет и разное время доставки. Вот это и побудило провести эксперимент. Флешка ясно почему работает быстрее. Ее поток данных имеет высокий приоритет плюс пакеты ее между контрольными точками доставляются максимально полными. А я как раз имею коротенькие сообщения. Но протокол rs-232 ни разу не пакетный. То есть это уже особенности реализации виртуального com порта.
А где там вобще RS232?
А где там вобще RS232?
А по какому протоколу работает виртуальный com ??
//Никто не говорит что надо получать теоретический максимум
Если его, т.е. 2МВ, не получить, то не выйдет загрузить ftgi и ch340 на их пределы, 3 и 2МВ соответственно, а очевидно что до них они справятся, согласно спекам. Значить узреть разницу между ними ну никак не получится, твои 0,5МВ все элементы канала пропустят с запасом. А сокращение CDC интереса я так понимаю вобще не вызвало. Ну и ладно ;)
А где там вобще RS232?
А ты не знаеш какие у тя протоколы используются?
//Никто не говорит что надо получать теоретический максимум
Если его, т.е. 2МВ, не получить, то не выйдет загрузить ftgi и ch340 на их пределы, 3 и 2МВ соответственно, а очевидно что до них они справятся, согласно спекам. Значить узреть разницу между ними ну никак не получится, твои 0,5МВ все элементы канала пропустят с запасом. А сокращение CDC интереса я так понимаю вобще не вызвало. Ну и ладно ;)
Вызвало ) То есть ты уверен что драйвер для режима CDC что для ch340 что для ftdi работает одинаково ??? Если ты это точно знаешь, спасибо за информацию.
А где там вобще RS232?
А по какому протоколу работает виртуальный com ??
UART это не протокол ) rs-232 протокол )
Почитал, подумал... ;)
Разумно ставить задачу так, чтобы Винда давала МК задание в виде:
1. Разгон с Т1 на шаг, до Т2 на шаг за х1 шагов;
2. N шагов;
3. Торможение с Т2 до Т0 на шаг за х2 шагов;
4. останов.
Ну что-то в этом роде. А МК отчитывался бы о текущем статусе, ошибке, если есть и т.п. То есть не управлять движением в РТ.
----------------
И да, на 1Мбоде ошибки приема будут одна на одной. Я так понимаю, что расстояния будут больше 1 м? Пусть лучше скорость будет меньше? ;) ;) ;)
------------
Ладно. Я посочиняю тесты разные... вроде поставил W8 32 бита на вирт. Теперь уже завтра. Дела домашние:
Самогон сам себя не выпьет и сериалы сами себя не посмотрят... ;)
Почитал, подумал... ;)
Разумно ставить задачу так, чтобы Винда давала МК задание в виде:
1. Разгон с Т1 на шаг, до Т2 на шаг за х1 шагов;
2. N шагов;
3. Торможение с Т2 до Т0 на шаг за х2 шагов;
4. останов.
Ну что-то в этом роде. А МК отчитывался бы о текущем статусе, ошибке, если есть и т.п. То есть не управлять движением в РТ.
----------------
И да, на 1Мбоде ошибки приема будут одна на одной. Я так понимаю, что расстояния будут больше 1 м? Пусть лучше скорость будет меньше? ;) ;) ;)
------------
Ладно. Я посочиняю тесты разные... вроде поставил W8 32 бита на вирт. Теперь уже завтра. Дела домашние:
Самогон сам себя не выпьет и сериалы сами себя не посмотрят... ;)
Благодарю!!!
UART это не протокол ) rs-232 протокол )
Который не имеет НИКАКОГО отношения к обсуждаемому вопросу. Совсем. Даже наш конвертор это USB-UART ;).
Ладно... сегодня уже знатно развлеклись метанием фекалий... хватит, ИМХО.
Читать совсем слабо! Даже первую строку крупными? Юморист. У 232 уровни сигнало спалят все выше перечисленое.
UART это не протокол ) rs-232 протокол )
Который не имеет НИКАКОГО отношения к обсуждаемому вопросу. Совсем. Даже наш конвертор это USB-UART ;).
Ладно... сегодня уже знатно развлеклись метанием фекалий... хватит, ИМХО.
Uart семейство протоколов. И в документации, которую представил Logik очень хорошо видно rs-232. Но вот насколько это принципиально вопрос.
... хватит, ИМХО.
тоже завязываю на пока.
Читать совсем слабо! Даже первую строку крупными? Юморист. У 232 уровни сигнало спалят все выше перечисленое.
А можно ссылочку на протокол uart ???)
Читать совсем слабо! Даже первую строку крупными? Юморист. У 232 уровни сигнало спалят все выше перечисленое.
А можно ссылочку на протокол uart ???)
Хочется понять какие вещи в нем оговариваются а какие нет
Приятно пообщались ) Всем спасибо)
Просто в качестве комментария: на алиэкспрессах встречаются разные там RS232 TTL уровня. Я как-то покопал в ту область и обнаружил, что это относится только к микрухам от FT с номером модели 232. Совпадение ли такой номер или он несет тайный смысл - я не знаю. По даташиту в эту МС входит USB, выходит UART. Ну и наоборот.
Просто в качестве комментария: на алиэкспрессах встречаются разные там RS232 TTL уровня.
Это как зеленая линия красного цвета. В стандарте RS232 четко определены уровни. Они не TTL. Если с TTL то уже не соответствует RS232. Тут либо-либо.
Пожалуста http://ww1.microchip.com/downloads/en/devicedoc/atmel-42735-8-bit-avr-microcontroller-atmega328-328p_datasheet.pdf , глава 24 и далее по ссылкам.
Просто в качестве комментария: на алиэкспрессах встречаются разные там RS232 TTL уровня. Я как-то покопал в ту область и обнаружил, что это относится только к микрухам от FT с номером модели 232. Совпадение ли такой номер или он несет тайный смысл - я не знаю. По даташиту в эту МС входит USB, выходит UART. Ну и наоборот.
Спасибо! Я вроде бы читал что стандарт rs-232 состоит из нескольких частей и электрическая лишь одна из.
Пожалуста http://ww1.microchip.com/downloads/en/devicedoc/atmel-42735-8-bit-avr-microcontroller-atmega328-328p_datasheet.pdf , глава 24 и далее по ссылкам.
Благодарю!
Просто в качестве комментария: на алиэкспрессах встречаются разные там RS232 TTL уровня.
Это как зеленая линия красного цвета. В стандарте RS232 четко определены уровни. Они не TTL. Если с TTL то уже не соответствует RS232. Тут либо-либо.
Это к продавцам уже обратите свой гнев.
Я просто написал, с какой путаницей в цифрах 232 сталкивался.
Trinamic делает так: ставит на мотор с энкодером контроллер с мощным процессором (они их заклеивают, а частично какой-то эпоксидкой еще заливают, но где-то я читал, что не слабже STM32), который следит за командами по RS-485 (например). Исполняет их и взаимодействует с энкодером. Т.е. PC может дать команду - повернуть на 32 градуса и сам контроллер этим займется. При движении, в обратную сторону по 485-му летят данные - скорость и позиция энкодера. Во всяком случае их софтина рисует разгонную кривую и тормозной путь. Не скажу, что рисует в рилтайме, отставание какое-то есть. Для серьезных применений у них имеется TMCL. Пишешь на нем программу, заливаешь на контроллер и он сам сутками хоть кривые выписывает, хоть резьбу с переменным шагом нарезает.
Собственно все три поста, КМК и есть подсказки к решению: переформулировать задачу так, чтобы Ардуино решала все что нужно в РТ, а с компом только связывалась для получения команд и обратной отчетности .. возможно и вовсе "постфактум" отправляла данные о разгоне, торможении и т.д., накапливая внутри себя чего надо. Не нужно с компа указывать дуньке КАК ей и что делать.
Вполне логично. Архитектура именно такой и будет.
SergeiSX, а тогда какой тайный смысл в поиске предельной скорости UART дуньки?
Тут даже не надо ничего экспериментировать: 2мегабода по даташиту. 10 бит на байт = 200кб/сек. или около 5 микросекунд на программную подготовку байта при побайтной пересылке. Буферизация облегчит задачу, но не сильно, ибо буфер тоже надо готовить.
на 16Мгц, 5мксек это .. около 80 тактов, а учитывая что доля команд с памятью высока (буфер), то немногим более 40 команд камня. Это практически "ниочем". То есть, орать в провод с такой скоростью оно может, но только теоретически. А Вам же хочется чтобы дунька ещё что-то и делала, так ведь!
Отсюда, сразу можно понять что "предельная скорость" FTDI или CH340 .. роялей не играет никакой. А важно, реконфигурировать задачу так, чтобы скорость UART-USB была не самым критичным параметром.
А лучше ваще никаким. 9600 - вполне должно стать достаточно.
SergeiSX, а тогда какой тайный смысл в поиске предельной скорости UART дуньки?
Тут даже не надо ничего экспериментировать: 2мегабода по даташиту. 10 бит на байт = 200кб/сек. или около 5 микросекунд на программную подготовку байта при побайтной пересылке. Буферизация облегчит задачу, но не сильно, ибо буфер тоже надо готовить.
на 16Мгц, 5мксек это .. около 80 тактов, а учитывая что доля команд с памятью высока (буфер), то немногим более 40 команд камня. Это практически "ниочем". То есть, орать в провод с такой скоростью оно может, но только теоретически. А Вам же хочется чтобы дунька ещё что-то и делала, так ведь!
Отсюда, сразу можно понять что "предельная скорость" FTDI или CH340 .. роялей не играет никакой. А важно, реконфигурировать задачу так, чтобы скорость UART-USB была не самым критичным параметром.
А лучше ваще никаким. 9600 - вполне должно стать достаточно.
Со скоростью конечно. Но судя по всему драйвер винды может быть разным для CH340 и FTDI. Я хочу померять в программе на Винде весь цикл обмена.
Возможно. В разных сортах гумна (винде) - не разбираюсь, так шта .. что там с драйверами - пофиг. Скорее всего надо менять не только весь цикл обмена но и уровень делегирования микроконтроллеру. Вы бы огласили весь список, озвучили всю задачу ..
Возможно. В разных сортах гумна (винде) - не разбираюсь, так шта .. что там с драйверами - пофиг. Скорее всего надо менять не только весь цикл обмена но и уровень делегирования микроконтроллеру. Вы бы огласили весь список, озвучили всю задачу ..
Да собственно я выше описывал про два двигателя. Это и вся задача. Можно здесь делать ссылки на посты выше???
Фиг его знает .. надеюсь потрут завтра. С дураками, всё одно иначе - нельзя.
Там озвучено, что Вы хотите крутить два шаговика с хорошей точностью и свистеть в уарт на комп о текущем состоянии. Но .. это не совсем есть "задача". Оно же не просто так надо .. или это тупо "стенд" какой-то?
Если "стенд" (студентам показать как оно вертится), то понятно. Но и тут, микроконтроллер может получать "крупную" команду типа "встать через 30 градусов", и по мере управления движками (тогда нафиг их два?) собирать диагностику (движение, разгон, торможение, ошибки) и пачками свистеть в комп "по завершению команды" .. или по мере её исполнения.
Но .. у Вас 2 двигла, а стало быть это управление в двух координатах .. столик? А если это некая шелезяка, то нафиг свистеть на комп в режиме практически онлайн? "Я поехал сюда".. компу не все равно "как" он поехал, если микроконтроллер самостоятельно может обнаружить ошибку и её исправить?
Я - про эту часть "задачи".. переформулировать похоже надо с самого верху.
Фиг его знает .. надеюсь потрут завтра. С дураками, всё одно иначе - нельзя.
Там озвучено, что Вы хотите крутить два шаговика с хорошей точностью и свистеть в уарт на комп о текущем состоянии. Но .. это не совсем есть "задача". Оно же не просто так надо .. или это тупо "стенд" какой-то?
Если "стенд" (студентам показать как оно вертится), то понятно. Но и тут, микроконтроллер может получать "крупную" команду типа "встать через 30 градусов", и по мере управления движками (тогда нафиг их два?) собирать диагностику (движение, разгон, торможение, ошибки) и пачками свистеть в комп "по завершению команды" .. или по мере её исполнения.
Но .. у Вас 2 двигла, а стало быть это управление в двух координатах .. столик? А если это некая шелезяка, то нафиг свистеть на комп в режиме практически онлайн? "Я поехал сюда".. компу не все равно "как" он поехал, если микроконтроллер самостоятельно может обнаружить ошибку и её исправить?
Я - про эту часть "задачи".. переформулировать похоже надо с самого верху.
Ну вот добрался до компа с интернетом)))) Задача состоит в том чтобы мерять с разных направлений в пространстве мощность звука. Для этого делается небольшое ОПУ с маленькими шаговиками. Далее планируется задать набор азимутов и углов места дабы померять в этих точках мощность звука. Крутить с огромной скоростью не нужно. Но понятно что если положений будет много то при сильно малой скорости перемещения из точки в точку мерять придется довольно долго. Поэтому и встал вопрос какие вообще максимальные скорости по вращению можно будет задавать. Ну и отсюда следствие, с какой скоростью надо уметь обрабатывать уведомления от шаговиков. Концепция в которой контроллер обслуживает перемещения по командам от компа и потом лишь сообщает об окончании перемещения я считаю что правильная. Так собственно сейчас и работает первый тестовый макет. Еще принимаю уведомления "ОК" или "ОF" что означает команда успешна или неуспешна сразу после посылки самой команды и установки задания на вращение. То есть вполне себе рабочая задача. Я попытался отключив предварительно двигатели от платы Ардуино задать нереальную скорость вращения (300 градусов в секунду, двигатели так не смогут эти вращаться) и протестировать программные комплекс в стрессовом режиме. И вот тут то и столкнулся что программа на компе запаздывает с приемом уведомлений. Редко но это случается в одном цикле съема по всем точкам. И я тогда решил проверить а какова максимальная производительность виртуального COM порта в связке с Windows. Еще узнал что для микросхем семейсва FTDI драйвер в Windows ставится автоматически а для CH340 его нужно специально ставить. Стало быть драйверы разные. В общем думаю правильно протестировать одну транзакцию со стороны компьютера (то есть передача данных и прием данных ) с помощью таймера высокого разрешения.
И по поводу уведомлений - они разумеется идут на комп не через каждый шаг а шагов через 11 то есть раз в один градус и то только при движении ротора.
Я потестировал программу на Ардуино приема и передачи одного символа обратно. Работает отлично! И времена близки к теоретическому. А вот тест кода доступа к COM порту через Windows API разочаровывает. Надеюсь на то что делаю что - то неправильно. Упростил функцию приема до предела. В принципе так же делается в putty. И тут же получаю 1 миллисекунду даже при приеме одного символа. Если убрать Get получается порядка 40 микросекунд что вполне приемлемо. То есть прием символа длится очень долго даже если плата Ардуино посылает его быстро. Лишь бы это не были задержки в самих функциях Windows API при доступе к порту. Последняя надежда что сам что - то не настраиваю правильно.
Да, забыл сказать - TStopwatch обертка для функций измерения времени высокого разрешения.
Вам же Логик уже писал, что винда не реал таймовая система. В свое время, когда строили свою сеть с гарантированным временем отклика, пришлось написать свой драйвер под винду, а в дальнейшем со стороны компа поставить отдельный контроллер, который держит сетку устройств в реал тайме и имеет приличный буфер, а с компом общается прямо по усби.
Вам же Логик уже писал, что винда не реал таймовая система. В свое время, когда строили свою сеть с гарантированным временем отклика, пришлось написать свой драйвер под винду, а в дальнейшем со стороны компа поставить отдельный контроллер, который держит сетку устройств в реал тайме и имеет приличный буфер, а с компом общается прямо по усби.
Ну чтобы настолько не реал тайм... При виртуальном ком порту по usb... Драйвер то можно написать... Но настолько большая задержка при приеме...
Но судя по всему драйвер винды может быть разным для CH340 и FTDI. Я хочу померять в программе на Винде весь цикл обмена.
"Программа на Винде" IMHO должна не сама по себе обмерять передачу по COM-порту, а лишь принимать данные с логичекого анализатора и аккуратно рисовать их на экране. А сам "обмер" должен делать именно логический анализатор. Сразу будут видны и скорость передачи, и структура посылки, и интервал между посылками...
PS. В целом согласен с коллегами, что при правильно спроектированном обмере между Arduino и ПК скорости 9600 должно быть за глаза.
Но судя по всему драйвер винды может быть разным для CH340 и FTDI. Я хочу померять в программе на Винде весь цикл обмена.
"Программа на Винде" IMHO должна не сама по себе обмерять передачу по COM-порту, а лишь принимать данные с логичекого анализатора и аккуратно рисовать их на экране. А сам "обмер" должен делать именно логический анализатор. Сразу будут видны и скорость передачи, и структура посылки, и интервал между посылками...
PS. В целом согласен с коллегами, что при правильно спроектированном обмере между Arduino и ПК скорости 9600 должно быть за глаза.
Но ведь уведомления от контроллера надо принимать? Надо... И если время приема не может быть быстрее 1 миллисекунды то и скорость вращения должна быть ограничена. В принципе этого то хватит но не совсем понятно что так тормозит прием сообщения, сами функции WinAPI или драйвер.
Как показал тест со стороны Ардуино сам обмен идёт на отличной скорости. Вопрос в обработке со стороны Windows.
если время приема не может быть быстрее 1 миллисекунды то и скорость вращения должна быть ограничена.
если время приема не может быть быстрее 1 миллисекунды то и скорость вращения должна быть ограничена.
Следует что? Что время приема в программе на компьютере не менее 1 миллисекунды даже одного символа? Это следует из измерений с помощью функций высокого разрешения. А то что скорость ограничена это следует из того что на морде лица пользовательского интерфейса программы надо обновлять индикаторы положения двигателей хотя бы раз в градус иначе будут рывки а это раздражает пользователя. И это не реальное время это разумная задержка реакции.
Вы всерьез считаете, что если при скорости вращения 10000 об/мин показания на индикаторе не будут обновляться с частотой 60000 FPS, рывки неизбежны?
Вы всерьез считаете, что если при скорости вращения 10000 об/мин показания на индикаторе не будут обновляться с частотой 60000 FPS, рывки неизбежны?
Я понимаю Ваш вопрос. Я объясню. У меня скорость измеряется в градусах в секунду. И более 70 градусов в секунду данные шаговики в принципе отрабатывают неважно. Так что скорость вращения как в РЛС мне не грозит. Кстати я описывал условия задачи выше. Поэтому при такой скорости вращения отображать текущее положение двигателей вполне реально. Опорно-поворотное устройство быстрее и нет смысла вращать. Экспериментально убедились что отображать положение ротора чаще чем раз в градус нецелесообразно а реже видны скачки индикатора.
Я понимаю Ваш вопрос. Я объясню. У меня скорость измеряется в градусах в секунду. И более 70 градусов в секунду данные шаговики в принципе отрабатывают неважно. Так что скорость вращения как в РЛС мне не грозит.
Сначала Вы жалуетесь на то, что есть какие-то проблемы при высоких скоростях вращения.
Я Вам привожу пример, что при скорости 10000 проблем быть не должно.
И возражений от Вас по этому поводу я не наблюдаю.
Экспериментально убедились что отображать положение ротора чаще чем раз в градус нецелесообразно а реже видны скачки индикатора.
Вы просто эксперименты до конца не довели. Если бы продвинулись чуть дальше, то обнаружили бы, что обновлять показания индикатора чаще N раз в секунду нецелесообразно вне зависимости от скорости вращения. На практике N обычно выбирают в пределах от 2 до 10. Даже в кино N=24.
Другими словами, шаг приращения показаний индикатора должен зависеть от скорости вращения, постоянным ему быть совершенно ни к чему. А вот постоянный интервал обновления - идея вполне здравая. Например, можно отсылать положение вала 5 раз в секунду, притом даже в том случае, если вал стоит на месте.
Я понимаю Ваш вопрос. Я объясню. У меня скорость измеряется в градусах в секунду. И более 70 градусов в секунду данные шаговики в принципе отрабатывают неважно. Так что скорость вращения как в РЛС мне не грозит.
Сначала Вы жалуетесь на то, что есть какие-то проблемы при высоких скоростях вращения.
Я Вам привожу пример, что при скорости 10000 проблем быть не должно.
И возражений от Вас по этому поводу я не наблюдаю.
Экспериментально убедились что отображать положение ротора чаще чем раз в градус нецелесообразно а реже видны скачки индикатора.
Вы просто эксперименты до конца не довели. Если бы продвинулись чуть дальше, то обнаружили бы, что обновлять показания индикатора чаще N раз в секунду нецелесообразно вне зависимости от скорости вращения. На практике N обычно выбирают в пределах от 2 до 10. Даже в кино N=24.
Другими словами, шаг приращения показаний индикатора должен зависеть от скорости вращения, постоянным ему быть совершенно ни к чему. А вот постоянный интервал обновления - идея вполне здравая. Например, можно отсылать положение вала 5 раз в секунду, притом даже в том случае, если вал стоит на месте.
Спасибо Большое! Идея очень хорошая! Думаю так и сделать.
Во-от. Оказывается что стоит совсем иная задача, а свист в комп данными с движка в общем-то и не требуется вовсе.. :)
попытаюсь переформулировать вашу задачу, может так будет проще:
С компа задается набор азимутов и мест, с направлений и в которых прибор должен измерить мощность звука и отправить результат на комп взад.
Так - совсем нет никакой "скоростной" передачи обратно на комп, и с него на прибор. Свистнули заданной программой измерений, прибор отработал и отствистелся компу сколько намерял. Объем пересылок - ровно сложность программы (количество направлений и узлов) и количество проведенных замеров: по кол-ву направлений и "микрофонов".
Суммарное время пересылки "туда и обратно" - не более времени очередной партии замеров по программе, которое определяется скоростью проведения одного замера и их количеством и .. достаточно велико.
То есть, приняли программу, пошли замерять и накапливать массив отклика. В это же время спокойно можем принимать следующую программу. Завершили первую - начали свистеть обратно данными, одновременно можем принимать очередную порцию программы. Требуется по 2 буфера на размер программы и результатов. Первый - исполняемая программа замеров, второй - принимаемая следующая программа. И по результатам: один буфер высвистываем, второй заполняем.
Верно?
P.S. Чем-то напоминает нашу установку "уши робота", когда планировали слушать противника на трассе и определять его местоположение, дабы избежать столкновений.. Уши - два микрофона с раструбами для лучшей локализации звука на серводвигателе SG-90. :)
Но, мы тогда пошли чуть иначе: сразу заводили сигнал от обоих микрофонов на дифференциальный вход Меги и по разностному уровню крутили серву на макс. сигнал. Получалось не шустро, но практически "беззатратно". :)
Ну вот и я проснулся!
OFFTOP:
Кстати, нифига себе вы все поднимаетесь! Я в полдесятого встал, и то только потому, что сволочи электрики меняют провода по всему частному сектору на СИП. И под радостный писк УПС я иду заводить генератор... мля! 10л каждый день! И это называется "бесплатная замена".
-------------------------------------
Так. посоветовавшись со спецами по Винде (я сам очень давно на ...никсах, сперва на Фри, теперь на Линухе), я получил внятный ответ, и даже некий "пруф" на дискуссию в РСДН.
Так вот: Отклик от Винды, аккуратнее 1 мс, получить невозможно вообще.
Таким образом ставится точка в исследованиях. Если интересно построить честные тесты, то стенд я заготовил, в виде W8.1-32 на виртуалке, запихнул туда драйвера плат, среду, последний Питон. Материнский комп 4 ядра, 8Гиг, виртуализация Vbox, аппаратная. То есть на все хватит. Плат с FTDI у меня, конечно, нет. Но, поверь опыту, драйвера почти одинаковые.FTDI больше плюшек поддерживает, поэтому возможностей настройки больше, но в работе - никакой разницы быть не может. Поиграй с приоритетом и квантами, как на виндовых форумах пишут. Но правильное решение мы уже предложили - обновление интерфейса 15-20 раз в сек, на основании имеющихся и (возможно) прогнозных данных, получаемых от контроллера ассинхронно, с разумной скоростью передачи.
Мне - не очень уже интересно... Как у доктора Хауса - диагноз поставлен, остальное - муть. Но если что-то не получится с тестами - пиши.
----------------------
Решил добавить про твои тесты:
Ты измеряешь разовые события, это неправильно. Потому, что система работает ассинхронно. Могут быть прерывания от чего-то, да хоть от сети.
Нужно делать серию однотипных действий - например погонять случайные числа с компа на контроллер и обратно, и измерять среднее время. Серия из пар передач туда-обратно, серия из 10 последовательный передач, среднее, среднее на одну передачу. Посмотреть вариабельность. Нагрузить комп закачкой тррента и компиляцией какого-нить монстра, повторить тесты на нагруженном компе, нагрузитиь закачкой с USB драйва и повторить.
Как-то так.
Во-от. Оказывается что стоит совсем иная задача, а свист в комп данными с движка в общем-то и не требуется вовсе.. :)
попытаюсь переформулировать вашу задачу, может так будет проще:
С компа задается набор азимутов и мест, с направлений и в которых прибор должен измерить мощность звука и отправить результат на комп взад.
Так - совсем нет никакой "скоростной" передачи обратно на комп, и с него на прибор. Свистнули заданной программой измерений, прибор отработал и отствистелся компу сколько намерял. Объем пересылок - ровно сложность программы (количество направлений и узлов) и количество проведенных замеров: по кол-ву направлений и "микрофонов".
Суммарное время пересылки "туда и обратно" - не более времени очередной партии замеров по программе, которое определяется скоростью проведения одного замера и их количеством и .. достаточно велико.
То есть, приняли программу, пошли замерять и накапливать массив отклика. В это же время спокойно можем принимать следующую программу. Завершили первую - начали свистеть обратно данными, одновременно можем принимать очередную порцию программы. Требуется по 2 буфера на размер программы и результатов. Первый - исполняемая программа замеров, второй - принимаемая следующая программа. И по результатам: один буфер высвистываем, второй заполняем.
Верно?
P.S. Чем-то напоминает нашу установку "уши робота", когда планировали слушать противника на трассе и определять его местоположение, дабы избежать столкновений.. Уши - два микрофона с раструбами для лучшей локализации звука на серводвигателе SG-90. :)
Но, мы тогда пошли чуть иначе: сразу заводили сигнал от обоих микрофонов на дифференциальный вход Меги и по разностному уровню крутили серву на макс. сигнал. Получалось не шустро, но практически "беззатратно". :)
С точки зрения вращения все верно, а вот съем будет вестись отдельной платой АЦП прямо на компе. То есть координировать увы должна программа на компе. Я поэтому и настаиваю на уведомлениях. Просто АЦП уже есть и менять стратегию начальство не позволит. Хотя Ваша идея прилично бы разгрузилась комп и позволила бы уйти от завязок на скорость реакции.
Интересная установка у Вас получилась. Концепция главное хорошая !
А зачем сьем вести "АЦП на компе"?!? Он что сделает это лучше дуньки? Сильно сумневаюсь, особенно в свете не РТ..
Как раз сьем нужно доверить МК, а вот обработку снятого, вполне можно на комп. Отправить "raw" на комп - об этом и писал как раз.