Comments 14
Интересное решение. Я видел нечто похожее в китайской светодиодной ленте. Касательно количества портов АЦП: почему бы не применить вместо нескольких плат с контроллерами один контроллер и несколько аналоговых мультиплексоров (возможно, с повторителями для защиты аналоговых портов от перенапряжения при неправильном подключении, а так же для лучшего согласования сопротивления измеряемого источника и модуля АЦП).
Например, так:
Например, так:
схема
Я старался использовать те компоненты, которые уже у меня были, к тому же максимально упростить схему, хотя ваше решение может тоже пригодится. Спасибо за предложение.
Мультиплексоры хорошо, но один МК имеет ограниченное быстродействие АЦП которое делится на все каналы. 6 каналов еще можно сканировать со скоростью 1К выборок/сек а вот уже 40 каналов не потянет. в 10 раз медленнее разве что и уже с явным сдвигом по времени.
Да, защита и нормализация перед АЦП — и получаем велосипед в виде промышленных модулей сбора данных, и не факт что получится дешевле чем купить готовое.
Да, защита и нормализация перед АЦП — и получаем велосипед в виде промышленных модулей сбора данных, и не факт что получится дешевле чем купить готовое.
Интересное решение. Не в плане конкретной реализации АЦП, а в плане логики расширения. К примеру, если нужно сделать платформу с переменным количеством модулей и вешать модули, допустим, на общую шину, то потребуется: отличать модули друг от друга, дать им какие-то имена, MAC, для этого они все должны быть уникальными, определять их порядок. А тут можно закодировать так, чтобы данные с датчиков приходили по порядку их следования и точно соответствовать порядку следования, например, резисторов-крутилок на передней панели устройства.
Собственно, ради этого всё и затевалось. Сколько бы модулей не было нам нужно, будут использоваться однотипные платы с идентичными прошивками. Нужно просто подключить к их входам источники сигнала в том порядке, в котором их ожидает софт на компьютере. Единственный минус — если заглючит один из модулей, то данные перестанут поступать со всех. С другой стороны поскольку прошивка очень простая, то вряд ли в ней есть баги, а от аппаратных проблем есть watchdog (мой софт на компьютере корректно обрабатывает кратковременную потерю связи). Мне вот только интересно, можно ли избавится от ошибок передачи (те самые 0.17% потерь данных) улучшив качество линии USART (например, взяв провод покороче) или же это модулю USART атмеги становится не хорошо от непрерывного потока данных и случается рассинхронизация. В принципе в ответственном применении можно просто перейти на синхронный USART и потери должны исчезнуть.
А как на счет SPI в виде кольцевой структуры? Подозреваю, что жесткий общий SCLK снизит вероятность ошибки.
Да, это хорошая идея, однако переходник USB-SPI труднее найти. Некоторые USB-USART-переходники (например, FT232) поддерживают bitbang, но хватит ли скорости… (насколько я понял по другим статьям, в режиме bitbang FTDI работает медленно, а нам потребуется в 2 раза большая частота, чтобы программно делать SCLK для эмуляции SPI). Вообще есть большой шанс, что уже есть готовые микросхемы АЦП, работающие по SPI в таком режиме и мне ничего выдумывать не придётся :-)
Суть проекта в том, что там как раз обычный USART, на который есть куча переходников всех цветов и размеров, либо вообще разъём на материнке.
Суть проекта в том, что там как раз обычный USART, на который есть куча переходников всех цветов и размеров, либо вообще разъём на материнке.
SPI плох тем что на большой скорости сильно ограничивается расстояние устойчивой связи и повышаются требования по входной емкости модулей.
работа на скорости 115200 на расстоянии более метра уже считается ненадёжной.
работа на скорости 115200 на расстоянии более метра уже считается ненадёжной.
потери возникают из-за большой скорости. в переходнике стоит кварц не с кратной частотой, боюсь из-за этого её приходится домножать на дробный коэффициент — в результате появляется джиттер и снижается устойчивость цифровой части к помехам. было бы неплохо записать RAW код с постоянными значениями аналоговых напряжений на входе(прописать константы в прошивке) и посмотреть какого рода происходят проблемы, так же надо анализировать ошибки самого порта — framing error тоже надо перехватывать и фиксировать. Если возникает такая ошибка, имеет смысл увеличить количество стоп-битов на передающей стороне, хотя это на 10% снизит максимальную скорость передачи но тогда поврежден будет только один байт а не нарушена синхронизация при несовпадении скоростей приема/передачи.
А как подсчитать процент потерь данных?
У меня, в своё время, вот такая штука получилась:
Классное решение! Только протокол из однобайтового сделать бы более изощренным, введя команду сброса cur_out_adc. Хотя тут скорость передачи пострадает =( Зато можно будет защититься от случайного вылета управляющего ПО без перезагрузки всех составляющих цепи )
Решение классное, меня самого от таких вещей «вставляет». Но все-таки, почему не modbus на 485?
Sign up to leave a comment.
Делаем модульный многоканальный АЦП