c🦊
spi и i2c однонаправленные
У тебя eventы летят что ли?
Size: a a a
2020 February 20
VS
@stolen У меня клиент, щас прверю
ML
У тебя eventы летят что ли?
думаю, захочу
ML
У тебя eventы летят что ли?
Нажатие кнопки питания, перегрев, отказ вентилятора
c🦊
думаю, захочу
На самом деле я тебя понимаю. Я тоже без острейшей необходимости использовать SPI или I²C использую UART
c🦊
Нажатие кнопки питания, перегрев, отказ вентилятора
Тогда. Да. UART наше все
В
Коллеги, а кто-нибудь организовывал общение софтины на эрланге по uart с микроконтроллером?
Надо что-то знать типа тротлинга отправки данных, чтобы уарт не переполнялся?
Надо что-то знать типа тротлинга отправки данных, чтобы уарт не переполнялся?
https://github.com/vicbaz/erlang_ale
Трудится на производстве несколько лет.
Использует https://sigrok.org/wiki/Libserialport
Трудится на производстве несколько лет.
Использует https://sigrok.org/wiki/Libserialport
ML
https://github.com/vicbaz/erlang_ale
Трудится на производстве несколько лет.
Использует https://sigrok.org/wiki/Libserialport
Трудится на производстве несколько лет.
Использует https://sigrok.org/wiki/Libserialport
Ага, оно часто всплывает. Мне все таки непонятно, зачем отдельные процессы
RP
В
Ага, оно часто всплывает. Мне все таки непонятно, зачем отдельные процессы
На каждый UART свой процесс. Все под супервизором. В духе Erlang. Не понял, в чем сомнения.
MK
Коллеги, а кто-нибудь организовывал общение софтины на эрланге по uart с микроконтроллером?
Надо что-то знать типа тротлинга отправки данных, чтобы уарт не переполнялся?
Надо что-то знать типа тротлинга отправки данных, чтобы уарт не переполнялся?
https://github.com/tonyg/erlang-serial
я пользуюсь вот этим. мне хватает. по поводу тротлинга, не очень понял в чем проблема. в большинстве микроконтроллеров обмен выпонляется по принципу "запрос-ответ", микроконтроллер тупой - параллельно несколько запросов ему сложно обрабатывать. поэтому он сам себя затротлит раньше, чем проблема где-то с буферами в ОС начнется.
я пользуюсь вот этим. мне хватает. по поводу тротлинга, не очень понял в чем проблема. в большинстве микроконтроллеров обмен выпонляется по принципу "запрос-ответ", микроконтроллер тупой - параллельно несколько запросов ему сложно обрабатывать. поэтому он сам себя затротлит раньше, чем проблема где-то с буферами в ОС начнется.
MK
MK
Одно расстройство с вами...
ML
На каждый UART свой процесс. Все под супервизором. В духе Erlang. Не понял, в чем сомнения.
Непонятно зачем отдельные юниксовые процессы
ML
Оу, питон стайл? Прекрасно!
RP
Ну скорее эликсир стайл
RP
Собственно сам EEP был Валимом инициирован
MK
Непонятно зачем отдельные юниксовые процессы
А ты уверен, что в этом проблема есть? Ну сколько ты UART-ов сможешь реально к одному компу подключить? Два десятка - верхняя граница.
MK
У тебя потоков CPU и то больше
ML
А ты уверен, что в этом проблема есть? Ну сколько ты UART-ов сможешь реально к одному компу подключить? Два десятка - верхняя граница.
я вижу в этом источник будущей проблемы.
Мы огребаем много проблем из-за того, что то epmd глюкнет, то ещё какая-нибудь нода не сдохнет, хотя вот совсем точно должна была.
Системд не интегрирован с эрланговскими супервизорами и поэтому прибить ветку процессов с юниксовым процессом бывает ненадежно
Мы огребаем много проблем из-за того, что то epmd глюкнет, то ещё какая-нибудь нода не сдохнет, хотя вот совсем точно должна была.
Системд не интегрирован с эрланговскими супервизорами и поэтому прибить ветку процессов с юниксовым процессом бывает ненадежно