Комментарии 14
Интересное решение. Я видел нечто похожее в китайской светодиодной ленте. Касательно количества портов АЦП: почему бы не применить вместо нескольких плат с контроллерами один контроллер и несколько аналоговых мультиплексоров (возможно, с повторителями для защиты аналоговых портов от перенапряжения при неправильном подключении, а так же для лучшего согласования сопротивления измеряемого источника и модуля АЦП).
Например, так:
Например, так:
схема![](https://habrastorage.org/files/454/e10/9b1/454e109b1076493ba2c369f07a9af32a.PNG)
+4
Я старался использовать те компоненты, которые уже у меня были, к тому же максимально упростить схему, хотя ваше решение может тоже пригодится. Спасибо за предложение.
+1
Мультиплексоры хорошо, но один МК имеет ограниченное быстродействие АЦП которое делится на все каналы. 6 каналов еще можно сканировать со скоростью 1К выборок/сек а вот уже 40 каналов не потянет. в 10 раз медленнее разве что и уже с явным сдвигом по времени.
Да, защита и нормализация перед АЦП — и получаем велосипед в виде промышленных модулей сбора данных, и не факт что получится дешевле чем купить готовое.
Да, защита и нормализация перед АЦП — и получаем велосипед в виде промышленных модулей сбора данных, и не факт что получится дешевле чем купить готовое.
0
Интересное решение. Не в плане конкретной реализации АЦП, а в плане логики расширения. К примеру, если нужно сделать платформу с переменным количеством модулей и вешать модули, допустим, на общую шину, то потребуется: отличать модули друг от друга, дать им какие-то имена, MAC, для этого они все должны быть уникальными, определять их порядок. А тут можно закодировать так, чтобы данные с датчиков приходили по порядку их следования и точно соответствовать порядку следования, например, резисторов-крутилок на передней панели устройства.
0
Собственно, ради этого всё и затевалось. Сколько бы модулей не было нам нужно, будут использоваться однотипные платы с идентичными прошивками. Нужно просто подключить к их входам источники сигнала в том порядке, в котором их ожидает софт на компьютере. Единственный минус — если заглючит один из модулей, то данные перестанут поступать со всех. С другой стороны поскольку прошивка очень простая, то вряд ли в ней есть баги, а от аппаратных проблем есть watchdog (мой софт на компьютере корректно обрабатывает кратковременную потерю связи). Мне вот только интересно, можно ли избавится от ошибок передачи (те самые 0.17% потерь данных) улучшив качество линии USART (например, взяв провод покороче) или же это модулю USART атмеги становится не хорошо от непрерывного потока данных и случается рассинхронизация. В принципе в ответственном применении можно просто перейти на синхронный USART и потери должны исчезнуть.
0
А как на счет SPI в виде кольцевой структуры? Подозреваю, что жесткий общий SCLK снизит вероятность ошибки.
0
Да, это хорошая идея, однако переходник USB-SPI труднее найти. Некоторые USB-USART-переходники (например, FT232) поддерживают bitbang, но хватит ли скорости… (насколько я понял по другим статьям, в режиме bitbang FTDI работает медленно, а нам потребуется в 2 раза большая частота, чтобы программно делать SCLK для эмуляции SPI). Вообще есть большой шанс, что уже есть готовые микросхемы АЦП, работающие по SPI в таком режиме и мне ничего выдумывать не придётся :-)
Суть проекта в том, что там как раз обычный USART, на который есть куча переходников всех цветов и размеров, либо вообще разъём на материнке.
Суть проекта в том, что там как раз обычный USART, на который есть куча переходников всех цветов и размеров, либо вообще разъём на материнке.
0
SPI плох тем что на большой скорости сильно ограничивается расстояние устойчивой связи и повышаются требования по входной емкости модулей.
работа на скорости 115200 на расстоянии более метра уже считается ненадёжной.
работа на скорости 115200 на расстоянии более метра уже считается ненадёжной.
0
потери возникают из-за большой скорости. в переходнике стоит кварц не с кратной частотой, боюсь из-за этого её приходится домножать на дробный коэффициент — в результате появляется джиттер и снижается устойчивость цифровой части к помехам. было бы неплохо записать RAW код с постоянными значениями аналоговых напряжений на входе(прописать константы в прошивке) и посмотреть какого рода происходят проблемы, так же надо анализировать ошибки самого порта — framing error тоже надо перехватывать и фиксировать. Если возникает такая ошибка, имеет смысл увеличить количество стоп-битов на передающей стороне, хотя это на 10% снизит максимальную скорость передачи но тогда поврежден будет только один байт а не нарушена синхронизация при несовпадении скоростей приема/передачи.
0
А как подсчитать процент потерь данных?
0
+5
Классное решение! Только протокол из однобайтового сделать бы более изощренным, введя команду сброса cur_out_adc. Хотя тут скорость передачи пострадает =( Зато можно будет защититься от случайного вылета управляющего ПО без перезагрузки всех составляющих цепи )
0
Решение классное, меня самого от таких вещей «вставляет». Но все-таки, почему не modbus на 485?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем модульный многоканальный АЦП