Кстати, нифига себе вы все поднимаетесь! Я в полдесятого встал, и то только потому, что сволочи электрики меняют провода по всему частному сектору на СИП. И под радостный писк УПС я иду заводить генератор... мля! 10л каждый день! И это называется "бесплатная замена".
-------------------------------------
Так. посоветовавшись со спецами по Винде (я сам очень давно на ...никсах, сперва на Фри, теперь на Линухе), я получил внятный ответ, и даже некий "пруф" на дискуссию в РСДН.
Так вот: Отклик от Винды, аккуратнее 1 мс, получить невозможно вообще.
Таким образом ставится точка в исследованиях. Если интересно построить честные тесты, то стенд я заготовил, в виде W8.1-32 на виртуалке, запихнул туда драйвера плат, среду, последний Питон. Материнский комп 4 ядра, 8Гиг, виртуализация Vbox, аппаратная. То есть на все хватит. Плат с FTDI у меня, конечно, нет. Но, поверь опыту, драйвера почти одинаковые.FTDI больше плюшек поддерживает, поэтому возможностей настройки больше, но в работе - никакой разницы быть не может. Поиграй с приоритетом и квантами, как на виндовых форумах пишут. Но правильное решение мы уже предложили - обновление интерфейса 15-20 раз в сек, на основании имеющихся и (возможно) прогнозных данных, получаемых от контроллера ассинхронно, с разумной скоростью передачи.
Мне - не очень уже интересно... Как у доктора Хауса - диагноз поставлен, остальное - муть. Но если что-то не получится с тестами - пиши.
----------------------
Решил добавить про твои тесты:
Ты измеряешь разовые события, это неправильно. Потому, что система работает ассинхронно. Могут быть прерывания от чего-то, да хоть от сети.
Нужно делать серию однотипных действий - например погонять случайные числа с компа на контроллер и обратно, и измерять среднее время. Серия из пар передач туда-обратно, серия из 10 последовательный передач, среднее, среднее на одну передачу. Посмотреть вариабельность. Нагрузить комп закачкой тррента и компиляцией какого-нить монстра, повторить тесты на нагруженном компе, нагрузитиь закачкой с USB драйва и повторить.
Как-то так.
Сердечно Благодарю! В принципе я делал тесты и однотипных событий и с нагрузкой. Это вчера уже решил сделать замер разовых событий. Все к одному и свелось, прием данных быстрее миллисекунды никак не получился. Как говорится все предельно ясно. Ну можно конечно свой драйвер написать ведь can адаптер как то работает пошустрее через usb а это тоже последовательный протокол. Но я так думаю что и такая скорость вполне устроит для моей задачи. Ещё раз Огромное Спасибо!
А зачем сьем вести "АЦП на компе"?!? Он что сделает это лучше дуньки?
А что, Дунька в принципе способна цифровать звук?
(Хотя, в принципе, с Вашим убеждением, что 256 кб - это море места для хранения сэмплов профессионального качества, - да, 4 кГц/8 бит с Дуньки снять можно)
А кто говорил о высококачественном звуке? У ТС-а задача измерять МОЩНОСТЬ звука, а не его "качество". Ну или пусть поправит. а цифровать звук - она вполне способна. Пиковая скорость АЦП 78ksps даже по даташиту. Не идеальные 128кГц, но выше типовых 44кГц. - заведомо.
(хотя с вашим непониманием о чем была речь тогда и как оно не соотносится с сейчас и уже неоднократно..)
Господа, АЦП нужен 32 разряда и он такой и есть. То есть тут комп со специальной платой.
Зачем 32 разряда? Какие требования к оцифровке? (и снова: огласите весь список, пжалста)
P.S. Ну и опять жеж. Кто-то или что-то мешает завести измеренный результат в дуньку для накопления, а уже потом отправлять в комп с расфасовкой по направлениям "итого"?
P.P.S. сдается мне, что Вы пытаетесь скрестить ежа с ужом: попользовать имеющуюся готовую плату в направлении, не предназначенном для такого, только потому что "она уже есть"... и именно отсюда и растут ноги управления шаговиками с компа или скоростной отправки данных с них. Если ответ "да", то без меня плиз.. :) (*тут хватает любителей-скрещивателей*)
Господа, АЦП нужен 32 разряда и он такой и есть. То есть тут комп со специальной платой.
Зачем 32 разряда? Какие требования к оцифровке? (и снова: огласите весь список, пжалста)
А вот здесь ситуация дурацкая. Такой АЦП уже записан в ТЗ. И ТЗ составляли без нас. Наверху. И грозили каким то мега датчиком с большим динамическим диапазоном. Самого датчика я пока в глаза не видел)
Вот и выплыла лажевость. Замеры АЦП никак не привязаны к инфе о положении. Потому и требуется быстро получать положение чтоб соответствовало замеру. Сушите весла, сэр! Замеры с АЦП тоже не приходят мгновенно. Задержки в обоих случаях будут и будут малопрогнозируемыми и зависить от загрузки ПК. Ибо - нех! )))
Вы там часом не звуки выстрелов засекаете? Хотя какая разница, с такими разрабами жизни снайпера нихрена не угрожает )))
Господа, АЦП нужен 32 разряда и он такой и есть. То есть тут комп со специальной платой.
Зачем 32 разряда? Какие требования к оцифровке? (и снова: огласите весь список, пжалста)
P.S. Ну и опять жеж. Кто-то или что-то мешает завести измеренный результат в дуньку для накопления, а уже потом отправлять в комп с расфасовкой по направлениям "итого"?
P.P.S. сдается мне, что Вы пытаетесь скрестить ежа с ужом: попользовать имеющуюся готовую плату в направлении, не предназначенном для такого, только потому что "она уже есть"... и именно отсюда и растут ноги управления шаговиками с компа или скоростной отправки данных с них. Если ответ "да", то без меня плиз.. :) (*тут хватает любителей-скрещивателей*)
Рад бы был на Ардуино все сделать но никак не получится...
Господа, АЦП нужен 32 разряда и он такой и есть. То есть тут комп со специальной платой.
Зачем 32 разряда? Какие требования к оцифровке? (и снова: огласите весь список, пжалста)
А вот здесь ситуация дурацкая. Такой АЦП уже записан в ТЗ. И ТЗ составляли без нас. Наверху. И грозили каким то мега датчиком с большим динамическим диапазоном. Самого датчика я пока в глаза не видел)
ТЗ как правило "само по себе" а грамотное решение отдельно. что там предлагал Вам подсунуть заказчик, в общем-то меня мало интересовало. Спрашивал о требованиях к оцифровке звука: диапазон уровней - какой звук, в каком диапазоне; скорость оцифровки - предельная частота звучания (может речь про ультразвук?!?), и т.д. То есть исходные требования - мощность какого звука оцифровываем и с какой точностью по уровную и времени (мгновенную насколько?) ..
а то может имеющихся 8-10 бит и скорости в 78ksps "за глаза".. и даже 8/16 датчиков навешать можно..
а че тут удивлятся, при таком уровне компетентности.
Ну Вы можете сколько угодно рассуждать о моем уровне компетентности. Это ради Бога. А задачу просто не поняли которую я описал. Уровень звука надо замерять не налёту а алгоритм предельно простой. Привели двигатель в нужное положение получили уведомление об окончании вращения и померяли. И все же ещё раз спасибо Вам за ссылку на документ по процессору atmel прочитал я про uart. Более или менее хорошо там все описано.
Господа, АЦП нужен 32 разряда и он такой и есть. То есть тут комп со специальной платой.
Зачем 32 разряда? Какие требования к оцифровке? (и снова: огласите весь список, пжалста)
А вот здесь ситуация дурацкая. Такой АЦП уже записан в ТЗ. И ТЗ составляли без нас. Наверху. И грозили каким то мега датчиком с большим динамическим диапазоном. Самого датчика я пока в глаза не видел)
ТЗ как правило "само по себе" а грамотное решение отдельно. что там предлагал Вам подсунуть заказчик, в общем-то меня мало интересовало. Спрашивал о требованиях к оцифровке звука: диапазон уровней - какой звук, в каком диапазоне; скорость оцифровки - предельная частота звучания (может речь про ультразвук?!?), и т.д. То есть исходные требования - мощность какого звука оцифровываем и с какой точностью по уровную и времени (мгновенную насколько?) ..
а то может имеющихся 8-10 бит и скорости в 78ksps "за глаза".. и даже 8/16 датчиков навешать можно..
Если бы я заранее все это знал... Но я же говорю ситуация дурацкая. Не говорят многое. Только динамическим диапазоном стращают более 110 дБ.
Господа, Спасибо Всем за советы, критику и полемику. Очень много ценных вещей почерпнул. Вне зависимости от мнения обо мне всем премного благодарен! Далее думаю поборюсь сам. Частные задачи я понял как решать. Если будут вопросы обязательно спрошу.
Я бы очень ну удивился, попав в свое время в вашу ситуацию .. впрочем .. удалил, а то тут опять срач начнется.
Спасибо Вам ! Хорошая на самом деле идея сделать все критичное ко времени на контроллере. Может как нибудь удастся продавить. Но не сейчас. Ещё раз, Спасибо!
Так вот: Отклик от Винды, аккуратнее 1 мс, получить невозможно вообще.
Да, речь идет именно о пределе возможностей.
В стандартном режиме Винда квантует все с периодом примерно 15-16 мс. В крайнем случае этот "квант" можно уменьшить до 1 мс, но не далее.
Ну вот и я проснулся!
OFFTOP:
Кстати, нифига себе вы все поднимаетесь! Я в полдесятого встал, и то только потому, что сволочи электрики меняют провода по всему частному сектору на СИП. И под радостный писк УПС я иду заводить генератор... мля! 10л каждый день! И это называется "бесплатная замена".
-------------------------------------
Так. посоветовавшись со спецами по Винде (я сам очень давно на ...никсах, сперва на Фри, теперь на Линухе), я получил внятный ответ, и даже некий "пруф" на дискуссию в РСДН.
Так вот: Отклик от Винды, аккуратнее 1 мс, получить невозможно вообще.
Таким образом ставится точка в исследованиях. Если интересно построить честные тесты, то стенд я заготовил, в виде W8.1-32 на виртуалке, запихнул туда драйвера плат, среду, последний Питон. Материнский комп 4 ядра, 8Гиг, виртуализация Vbox, аппаратная. То есть на все хватит. Плат с FTDI у меня, конечно, нет. Но, поверь опыту, драйвера почти одинаковые.FTDI больше плюшек поддерживает, поэтому возможностей настройки больше, но в работе - никакой разницы быть не может. Поиграй с приоритетом и квантами, как на виндовых форумах пишут. Но правильное решение мы уже предложили - обновление интерфейса 15-20 раз в сек, на основании имеющихся и (возможно) прогнозных данных, получаемых от контроллера ассинхронно, с разумной скоростью передачи.
Мне - не очень уже интересно... Как у доктора Хауса - диагноз поставлен, остальное - муть. Но если что-то не получится с тестами - пиши.
----------------------
Решил добавить про твои тесты:
Ты измеряешь разовые события, это неправильно. Потому, что система работает ассинхронно. Могут быть прерывания от чего-то, да хоть от сети.
Нужно делать серию однотипных действий - например погонять случайные числа с компа на контроллер и обратно, и измерять среднее время. Серия из пар передач туда-обратно, серия из 10 последовательный передач, среднее, среднее на одну передачу. Посмотреть вариабельность. Нагрузить комп закачкой тррента и компиляцией какого-нить монстра, повторить тесты на нагруженном компе, нагрузитиь закачкой с USB драйва и повторить.
Как-то так.
Сердечно Благодарю! В принципе я делал тесты и однотипных событий и с нагрузкой. Это вчера уже решил сделать замер разовых событий. Все к одному и свелось, прием данных быстрее миллисекунды никак не получился. Как говорится все предельно ясно. Ну можно конечно свой драйвер написать ведь can адаптер как то работает пошустрее через usb а это тоже последовательный протокол. Но я так думаю что и такая скорость вполне устроит для моей задачи. Ещё раз Огромное Спасибо!
А зачем сьем вести "АЦП на компе"?!? Он что сделает это лучше дуньки?
А что, Дунька в принципе способна цифровать звук?
(Хотя, в принципе, с Вашим убеждением, что 256 кб - это море места для хранения сэмплов профессионального качества, - да, 4 кГц/8 бит с Дуньки снять можно)
Господа, АЦП нужен 32 разряда и он такой и есть. То есть тут комп со специальной платой.
А кто говорил о высококачественном звуке? У ТС-а задача измерять МОЩНОСТЬ звука, а не его "качество". Ну или пусть поправит. а цифровать звук - она вполне способна. Пиковая скорость АЦП 78ksps даже по даташиту. Не идеальные 128кГц, но выше типовых 44кГц. - заведомо.
(хотя с вашим непониманием о чем была речь тогда и как оно не соотносится с сейчас и уже неоднократно..)
P.S. Ну и опять жеж. Кто-то или что-то мешает завести измеренный результат в дуньку для накопления, а уже потом отправлять в комп с расфасовкой по направлениям "итого"?
P.P.S. сдается мне, что Вы пытаетесь скрестить ежа с ужом: попользовать имеющуюся готовую плату в направлении, не предназначенном для такого, только потому что "она уже есть"... и именно отсюда и растут ноги управления шаговиками с компа или скоростной отправки данных с них. Если ответ "да", то без меня плиз.. :) (*тут хватает любителей-скрещивателей*)
А вот здесь ситуация дурацкая. Такой АЦП уже записан в ТЗ. И ТЗ составляли без нас. Наверху. И грозили каким то мега датчиком с большим динамическим диапазоном. Самого датчика я пока в глаза не видел)
Вот и выплыла лажевость. Замеры АЦП никак не привязаны к инфе о положении. Потому и требуется быстро получать положение чтоб соответствовало замеру. Сушите весла, сэр! Замеры с АЦП тоже не приходят мгновенно. Задержки в обоих случаях будут и будут малопрогнозируемыми и зависить от загрузки ПК. Ибо - нех! )))
Вы там часом не звуки выстрелов засекаете? Хотя какая разница, с такими разрабами жизни снайпера нихрена не угрожает )))
P.S. Ну и опять жеж. Кто-то или что-то мешает завести измеренный результат в дуньку для накопления, а уже потом отправлять в комп с расфасовкой по направлениям "итого"?
P.P.S. сдается мне, что Вы пытаетесь скрестить ежа с ужом: попользовать имеющуюся готовую плату в направлении, не предназначенном для такого, только потому что "она уже есть"... и именно отсюда и растут ноги управления шаговиками с компа или скоростной отправки данных с них. Если ответ "да", то без меня плиз.. :) (*тут хватает любителей-скрещивателей*)
Рад бы был на Ардуино все сделать но никак не получится...
ТЗ как правило "само по себе" а грамотное решение отдельно. что там предлагал Вам подсунуть заказчик, в общем-то меня мало интересовало. Спрашивал о требованиях к оцифровке звука: диапазон уровней - какой звук, в каком диапазоне; скорость оцифровки - предельная частота звучания (может речь про ультразвук?!?), и т.д. То есть исходные требования - мощность какого звука оцифровываем и с какой точностью по уровную и времени (мгновенную насколько?) ..
а то может имеющихся 8-10 бит и скорости в 78ksps "за глаза".. и даже 8/16 датчиков навешать можно..
Вы там часом не звуки выстрелов засекаете? Хотя какая разница, с такими разрабами жизни снайпера нихрена не угрожает )))
Такая тема мелькала тут пару лет назад .. що, до сих пор снова?!? ;)
а че тут удивлятся, при таком уровне компетентности.
а че тут удивлятся, при таком уровне компетентности.
Ну Вы можете сколько угодно рассуждать о моем уровне компетентности. Это ради Бога. А задачу просто не поняли которую я описал. Уровень звука надо замерять не налёту а алгоритм предельно простой. Привели двигатель в нужное положение получили уведомление об окончании вращения и померяли. И все же ещё раз спасибо Вам за ссылку на документ по процессору atmel прочитал я про uart. Более или менее хорошо там все описано.
ТЗ как правило "само по себе" а грамотное решение отдельно. что там предлагал Вам подсунуть заказчик, в общем-то меня мало интересовало. Спрашивал о требованиях к оцифровке звука: диапазон уровней - какой звук, в каком диапазоне; скорость оцифровки - предельная частота звучания (может речь про ультразвук?!?), и т.д. То есть исходные требования - мощность какого звука оцифровываем и с какой точностью по уровную и времени (мгновенную насколько?) ..
а то может имеющихся 8-10 бит и скорости в 78ksps "за глаза".. и даже 8/16 датчиков навешать можно..
Если бы я заранее все это знал... Но я же говорю ситуация дурацкая. Не говорят многое. Только динамическим диапазоном стращают более 110 дБ.
И АЦП в компе это данность.
Господа, Спасибо Всем за советы, критику и полемику. Очень много ценных вещей почерпнул. Вне зависимости от мнения обо мне всем премного благодарен! Далее думаю поборюсь сам. Частные задачи я понял как решать. Если будут вопросы обязательно спрошу.
Я бы очень ну удивился, попав в свое время в вашу ситуацию .. впрочем .. удалил, а то тут опять срач начнется.
Я бы очень ну удивился, попав в свое время в вашу ситуацию .. впрочем .. удалил, а то тут опять срач начнется.
Спасибо Вам ! Хорошая на самом деле идея сделать все критичное ко времени на контроллере. Может как нибудь удастся продавить. Но не сейчас. Ещё раз, Спасибо!