Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
14 сентября

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

Микроконтроллеры

1140359 Топик полностью

Argon (24.10.2021 09:43, просмотров: 284) ответил SciFi на Зачем так сложно? Почему бы не обязать арбитра выдавать в линию сигналы точного времени не реже, чем NNN? Собственно, на этом всё.

т.е. разделение по времени - лишнее?

Ответить

- Лучше расскажите, что делаете. Слово "синхронизация" можно по-разному понимать. Все как партизаны, молчат как рыба об лёд... - SciFi(24.10.2021 09:44)
  - Грубо - есть 2 сервопривода, к-рые надо включать одновременно по команде с шины CAN. Т.е. есть платки-шагогенераторы с CAN интерфейсом. Там не настолько требуется полный реалтайм, как в ЧПУ оборудовании, тем не менее лаг в 0.5с будет фатален. Также при аварии одного из сервоприводов нужно максимально быстро тормознуть второй. Но это, вообще-то, не совсем про синхронизацию. - Argon(24.10.2021 10:08)
    - Если придет просто тупо две команды одна за другой, то быстрее чем задержка протокола сделать не получится. Если есть желание заморочиться и сначала синхронизировать часы протоколом синхронизации времени (а пускать точно в назначенное время) то это немного другое. - RxTx(25.10.2021 14:01)
      - "Другое" и имею ввиду, две команды одна за другой - слишком тупо. Можно ведь команду отправить двум абонентам одним сообщением. - Argon(25.10.2021 14:25)
        
        А ты это делаешь ради искусства :) или реально посчитал сколько задержка между двумя командами по CAN'у. Шина у тебя незанята или по ней mp3 кто-то играет? :) - RxTx(25.10.2021 14:48)
        
        Заболевание перфекционизмом привело к склонности к необоснованному усложнению. - Argon(25.10.2021 15:14)
        
        можно! но я бы так делать не стал... проще назначить свой id каждому узлу и не придется разгребать на программном уровне сообщения - Aleksey_75(25.10.2021 14:28)
        
        Тогда отдельными сообщениями, но с синхронизацией. А надеяться на минимальный лаг протокола как-то не хочется (хотя оно вроде и должно работать). - Argon(25.10.2021 14:31)
        
        есть "псевдо мастер" который шлет сихру по id 0x000, её принимают все узлы! Дальше самые "серьезные приводы" id 0x001.... все остальное 0x700.... (кстати это адреса авто диагностики) Aleksey_75(55 знак., 25.10.2021 14:35)
        
        А нельзя ли принимать сообщения по маске ID? Т.е. два девайса с разными ID, но совместимы по маске. И таки одним сообщением кидать команду. - Argon(25.10.2021 14:33)
        
        нет проблем, можно... но каждый узел в любом случае будет на уровне ПО разгребать "это мне или нет", 64 мкс сильно критично ? - Aleksey_75(25.10.2021 14:37)
        
        Я имел ввиду аппаратную селекцию по маске. Т.е. девайсу по идее не придется программно разгребать. Нет ли такой возможности в CAN? - Argon(25.10.2021 14:43)
        
        ну по маске влетит овер много id, так что в по придется в любом случае разгребать.. по номеру фильтра id можно автоматом вызывать колбек - Aleksey_75(25.10.2021 14:48)
        
        Наверное нет, но почему-то хотелось бы максимальной тишины на шине. - Argon(25.10.2021 14:40)
        
        дык в чем проблем ? я так понял вам в первую очередь интересна синхра, ну а команды они и есть команды "скока" будете двигать приводы так и будет занята шина... Aleksey_75(109 знак., 25.10.2021 14:46)
      - касаемо can 500К это будет 64 микросекунды, ни один привод такой таймаут даже не заметит.. главное правильно организовать распределение id каждому узлу - Aleksey_75(25.10.2021 14:13)
    - Или еще: есть 2 независимых электронагревателя, управляемых низкочастотным ШИМом. Текущая общая потребляемая мощность не должна превышать некоторую величину. Пока еще не придумал как их между собой увязать, но без синхронизации явно никак. - Argon(24.10.2021 10:11)