а есть какие контроллеры arduino совместимые которые могут в 5ггц

а есть какие контроллеры arduino совместимые которые могут в 5ггц

а есть какие контроллеры arduino совместимые которые могут в 5ггц

и это опять полноценный комп на линуксе

первая это pico

с такими ценами лучше на жопе сидеть

с такими ценами лучше на жопе сидеть

Насколько дешевле получится, если делать самому?

у меня на даче только 5ггц

Интересно, во всяких Arduino библиотеках - тоже нельзя RS485 на скоростях больше 230400 использовать??

У атмеги нет rs485, поэтому видимо это будет uart-485, а если речь про ардуино библиотеки то значит чтение через serial. И да реализация его там врятли такая быстрая, если даже обычный блинк упирается

Украли у мужика корову. Приходит он домой и говорит сыновьям: - У нас корову украл какой-то пидар. Старший брат: - Если пидар - значит маленький. Средний брат: - Если маленький - значит из Малиновки. Младший Брат: - Если из Малиновки - значит Васька Косой. Все выдвигаются в Малиновку и там прессуют Ваську Косого. Однако Васька корову не отдает. Его ведут к мировому судье. Мировой судья: - Ну... Логика мне ваша непонятна. Вот у меня коробка, что в ней лежит? Ср брат: - Коробка квадратная, значит внутри что-то круглое. Ст. брат: - Если круглое, то оранжевое. Мл. брат: - Если круглое и оранжевое, то апельсин. Судья открывает коробку, а там и правда апельсин. Судья - Ваське Косому: - Косой, отдай корову.

Какой вопрос, такой ответ

Крайне неприятные условия для драйвера. Так как входное напряжение (3.6В и меньше)может быть как больше, так и меньше напряжения на светодиоде(3.2....3.7В). А большинство драйверов так не умеет. Они или вверх или вниз напряжение преобразуют.

Что не так с вопросом?

Ну вы в курсе что у атмеги нет rs485? Значит это какой колхоз умноженный на библы ардуино

Неправда ваша. Полно устройств на atmega и на stm32, которые работают с RS485.

Крайне неприятные условия для драйвера. Так как входное напряжение (3.6В и меньше)может быть как больше, так и меньше напряжения на светодиоде(3.2....3.7В). А большинство драйверов так не умеет. Они или вверх или вниз напряжение преобразуют.

Драйверы светодиодов преобразуют "изменчивое" напряжение в "моногамный" ток.

Мозг сломал, пытаясь понять. Как правило драйверы либо повышают напряжение , либо понижают(на ходу переключаться с повышения на понижение и обратно не умеют), а обратную связь берут с падения напряжения на низкоомном резисторе(100...200мВ, в отличии от обычных стабилизаторов напряжения с 600...800мВ), который является датчиком тока ,протекающем через светодиод.

Я один ESP12 вижу? :-) Делал такое лет пять назад с ливоло

а какую цель преследовал при переводе?

Подскажите плиз. Стоит задача собирать время получения сигнала на пинах микроконтроллера (микроконтроллер будет подключен к станку), в виде дата+время:№ пина;…. И далее, раз в 5-10 секунд, отправлять накопленные данные по WIFI. Частота, с которой могут приходить сигналы - до 3000 раз/сек (в основном около 1500 раз/сек). Задействованных пинов будет до 10шт. Попробовал собирать данные через прерывания без получения реального времени на ESP32-WROOM: - прерывания регистрируют задачи через таймер - задачи сохраняют значения в глобальную строку-переменную (как бы кэш) - каждые 5 сек, срабатывает задача на отправку данных и очистка “кэша” В последнем пункте, попытался вывести в консоль, и получил ошибку - “паника ядра”. Подозреваю, что слишком долго передовались данные в консоль. Какой подход лучше использовать? Или на прерываниях будет норм?

Кому интересно, стоит на github выкладывать idf проект?

1. Что бы советовать подход, нужно как минимум а) ТЗ б) схему в) код 2. Прерывания не должны ничего запускать, только самые короткие операции. Типа поставить в очередь события изменения пина. 3. Паника ядра разная бывает

Спасибо за ответ. 1. Это пет-проект, поэтому четкого ТЗ нет. А так как подключение к планируется к разным станкам, то под каждый тип, планируется свой код, использующий одинаковый принцип (просто разное кол-во отслеживаемых пинов и прерываний) а) Микроконтроллер будет подключен к датчикам старого станка (станков будет много). С датчиков будут приходит сигналы, которые нужно временно сохранять и переодически, скопом, отправлять через WIFI Mesh сеть на комп/микрокомп, по IP. б) схемы нету :( в) код сборщика данных: https://gist.github.com/Ingco/d4833877df1d7de924671014cedd1181 Mesh сеть еще не пробовал/не закончил с ней. код эмулятора, с которым тестил: https://gist.github.com/Ingco/a5a3a7f0d87621471168fcd38c94d031 2. Прерывания так и использовал. Подскажите хотя бы - реально ли отправить по WIFI довольно длинную строку, когда постоянно срабатывают прерывания? Может можно перекинуть эту задачу, на второе ядро?

1 реально ли отправить по WIFI довольно длинную строку, когда постоянно срабатывают прерывания? Вроде как WiFi обслуживается немаскируемым прерыванием ( не помню где это указано, кажется в technical reference) Кроме того например в esp32-cam отправляется большие массивы данных без последствий. 2 Может можно перекинуть эту задачу, на второе ядро? - можно, именно на то которое не обслуживает Wifi Но вообще 3 КГц для это очень низкая частота, должно все работать.

Спасибо за ответ. 1. Это пет-проект, поэтому четкого ТЗ нет. А так как подключение к планируется к разным станкам, то под каждый тип, планируется свой код, использующий одинаковый принцип (просто разное кол-во отслеживаемых пинов и прерываний) а) Микроконтроллер будет подключен к датчикам старого станка (станков будет много). С датчиков будут приходит сигналы, которые нужно временно сохранять и переодически, скопом, отправлять через WIFI Mesh сеть на комп/микрокомп, по IP. б) схемы нету :( в) код сборщика данных: https://gist.github.com/Ingco/d4833877df1d7de924671014cedd1181 Mesh сеть еще не пробовал/не закончил с ней. код эмулятора, с которым тестил: https://gist.github.com/Ingco/a5a3a7f0d87621471168fcd38c94d031 2. Прерывания так и использовал. Подскажите хотя бы - реально ли отправить по WIFI довольно длинную строку, когда постоянно срабатывают прерывания? Может можно перекинуть эту задачу, на второе ядро?

глянул код 1 Не увидел где используется rtos? 2 Откажитесь от ардуино или чего у вас там, используйте FreeRTOS 3 Не надо в прерывании отладочные строки пихать

Подскажите плиз. Стоит задача собирать время получения сигнала на пинах микроконтроллера (микроконтроллер будет подключен к станку), в виде дата+время:№ пина;…. И далее, раз в 5-10 секунд, отправлять накопленные данные по WIFI. Частота, с которой могут приходить сигналы - до 3000 раз/сек (в основном около 1500 раз/сек). Задействованных пинов будет до 10шт. Попробовал собирать данные через прерывания без получения реального времени на ESP32-WROOM: - прерывания регистрируют задачи через таймер - задачи сохраняют значения в глобальную строку-переменную (как бы кэш) - каждые 5 сек, срабатывает задача на отправку данных и очистка “кэша” В последнем пункте, попытался вывести в консоль, и получил ошибку - “паника ядра”. Подозреваю, что слишком долго передовались данные в консоль. Какой подход лучше использовать? Или на прерываниях будет норм?

Разделите на 2 проца: один только подсчитывает импульсы, другой только wifi соединением занят. Иначе будут коллизии одного с другим. Результат не понравится.