udineze

если с нуля делать то да, но у меня сейчас в прототипе есть программа, которая настраивает датчик, считывает данные, заполняет кольцевой буфер и пуляет в USB. то есть на уровне датчика почти все готово, только вместо USB сделать UART. На базовом МК при норм скорости можно прицепить все датчики к одному UART или есть STM32 с 5-ю UART - по 2 датчика на шину.

не надо ничего исследовать. я прошу оценить варианты с точки зрения их реализации. вы писали, что вариант с отдельным МК на каждом датчике сложнее, чем одновременная эмуляция восьми I2C. Можете поподробнее объяснить почему? я, честно говоря, с трудом представляю себе эмуляцию восьми I2C

что вы все привязались к этим помехам, просто подскажите плюсы и минусы обоих вариантов, возможные "подводные камни", которые могут появиться

коагулятора нет. более опытные коллеги сказали, что "рядом с ним все глючит и USB бывает отваливается". дальше мнения разделились. с одной стороны, программно реализовать 8 I2C и своевременно перезапускать зависшие датчики кажется сложновато. с другой стороны, ставить контроллер на каждый датчик может быть избыточно

коагулятора у меня нет, пробовали бить магнитным стимулятором, добились стабильного зависания I2C. хочу спросить еще, а UART при помехах тоже будет намертво зависать, как I2C ?

типа того. помех от него хватило чтобы завалить USB на опытном образце с одним датчиком (а I2C тем более). вот я и спрашиваю, что лучше программно эмулировать I2C и бороться с зависаниями на шине или поставить дополнительный контроллер и пулять данные по UART

потому что датчики будут находится в рабочей зоне коагулятора, а устройство в 2-х метрах

датчики будут располагаться рядом с работающим электрокоагулятором. USB в таких условиях стабильно вылетает. коагулятора у меня нет и проверить уровень помех я не могу, знаю только что они будут и вероятно большие. 2-хметровый провод от датчика должен быть максимально гибким, поэтому экрана наверно не будет

нельзя. чтение данных на частоте 400 кГц занимает 0,3 мс. для определения ошибок считываем данные 3 раза т.е. 0,9 мс. период обновления данных 1, 25 мс.

довольно громоздко будет что вы имеете ввиду? I2C не будет работать на полной скорости (400 kHz) при 2-х метровом проводе?

датчик должен быть как можно меньше и легче. приведите пожалуйста пример копеечного проца и драйвера RS-485

помехи вызваны работой электрокоагулятора рядом с датчиками т.е да, в процессе передачи по I2C. с USB потом разберемся скорости I2C не хватит, на 400 кГц считывание данных занимает 0,3 мс. период выдачи данных 1,25 мс (800 Гц), а надо одни и теже данные 3 раза считать т.е. 0,9 мс звездой 8 датчиков, каждый на 2-х метровом проводе

Здравствуйте! Столкнулся с такой проблемой: нужно подключить 8 датчиков ММА8451Q к одному USB. При этом на датчики воздействуют различные помехи и нужно их минимизировать и при возникновении выявлять. Датчики соединяются с USB MK по интерфейсу I2C. Чтение данных происходит с частотой 800 Гц. Предполагается выявлять ошибки в данных путем чтения с частотой в три раза чаще. То есть микросхема выдает данные с частотой 800 Гц, а мы читаем с частотой 2400 Гц - три значения сравниваем между собой, если есть 2 одинаковых, считаем их верными. Есть два варианта реализации: 1) Необходимо 8 I2C, значит придется их эмулировать программно. 2) Прямо на датчик приделать МК с I2C, а на USB MK слать данные по UART Вопрос, какой вариант лучше с точки зрения помехозащищенности? Длина кабеля от датчика до USB MK 2 метра.

Здравствуйте! У меня какая то проблема со знаком ускорения в датчике LIS3LV02. Она состоит в том, что при угле между осью Z и ускорением свободного падения (g) 90 и более градусов датчик выдает нереальные значения (больше 1g). сам разобрался, знак никак не надо трогать в проге верхнего уровня

я смотрел для Vs =+- 15 вольт и перевел Quiescent Current , как "ток покоя", а Iq=25 мкА - на первой странице написано для Vs =+/- 15 вольт значит будет +-45 мкА