Для шины UART скорость должна быть известна и для слейва и мастера, т.к. нету сигнала тактирования. Однако, есть аппаратно-софтверные решения определения скорости тактирования. Смысл в том, чтобы за несколько фреймов определить период 1 бита. Есть и метод по проще - перебор настроек приемопередатчика. Каждый фрейм принимается с определенной скоростью тактирования UART слейва и проверяется кол-во принятых бит, ошибки, старт и стоп биты. Если на текущих настройках байт принят без ошибки, то эту скорость и устанавливает слейв. Siemens в своих решениях использует метод посложнее, реализованный аппаратно. И на шине не могут быть устройства с разной скоростью...
Проблемы с полевой шиной, по-моему опыту, в основном связаны с именно с полевой шиной) За 2 года я заменил около 3х десятков приемопередатчиков RS485 в различных девайсах. И понял, что к выбору микросхемы тоже нужно подойти с "подветренной". Могу посоветовать ADM485 исключительно от Analog Devices (частенько встречаю их в девайсах B&R), а также SN75ALS176x. Я бы не грешил на какие-то недочеты парней из Lenze, по крайней о софтверной стороне...
Есть такое. Но, такие проблемы сегодня неизбежны. Поэтому в обиходе и появилось такое понятие как контроллер интерфейса. Даже специфичные архитектуры разрабатывают для этих целей, либо реализовывают на FPGA. А по поводу стмки, по сути, любой контроллер возьми - такие же проблемы будут. Очень быстрый период запроса посылки, процессору просто некогда делать что-то другое. Либо делать это по частям/аппаратно/дополнительное ядро для программного когда, а аппаратные возможности у конкретного контроллера неплохие. Конечно, я бы добавил всяких интересных фич, но для этого лучше взять FPGA... Как и говорилось, для реализации входа/выхода этого достаточно. Вообще, в планах портануть на f103c8, но это когда будет скучно)
Можно согласиться с тем, что статья была написана не совсем корректно - мой первый опыт. Но тема здесь специфичная, ищущая человека, который достаточно скиловый в теме микроэлектроники. Это не для "подпивасного" скрола... Зачем? Когда мне поставили этот вопрос, я был бы рад найти какую-то интересную информацию, тем более пример кода. Может кому-то это поможет...
Соглашусь с сегодняшней нуждой в рилтайме и смертью профибаса, а особенно с замороченным программированием драйверов от Lenze) Но сегодня еще остается туча технологических линий, особенно в СНГ, которые собирали на трехсотке... А про зависание вообще впервые слышу. На производстве около сотни приводов, проблем таких ни разу не было...
Для шины UART скорость должна быть известна и для слейва и мастера, т.к. нету сигнала тактирования. Однако, есть аппаратно-софтверные решения определения скорости тактирования. Смысл в том, чтобы за несколько фреймов определить период 1 бита. Есть и метод по проще - перебор настроек приемопередатчика. Каждый фрейм принимается с определенной скоростью тактирования UART слейва и проверяется кол-во принятых бит, ошибки, старт и стоп биты. Если на текущих настройках байт принят без ошибки, то эту скорость и устанавливает слейв. Siemens в своих решениях использует метод посложнее, реализованный аппаратно. И на шине не могут быть устройства с разной скоростью...
В моей голове это не выглядело как сравнение физ. уровня с целым стеком. Возможно, претензия вполне себе...
Не переживайте, знаком...
Проблемы с полевой шиной, по-моему опыту, в основном связаны с именно с полевой шиной) За 2 года я заменил около 3х десятков приемопередатчиков RS485 в различных девайсах. И понял, что к выбору микросхемы тоже нужно подойти с "подветренной". Могу посоветовать ADM485 исключительно от Analog Devices (частенько встречаю их в девайсах B&R), а также SN75ALS176x. Я бы не грешил на какие-то недочеты парней из Lenze, по крайней о софтверной стороне...
Есть такое. Но, такие проблемы сегодня неизбежны. Поэтому в обиходе и появилось такое понятие как контроллер интерфейса. Даже специфичные архитектуры разрабатывают для этих целей, либо реализовывают на FPGA. А по поводу стмки, по сути, любой контроллер возьми - такие же проблемы будут. Очень быстрый период запроса посылки, процессору просто некогда делать что-то другое. Либо делать это по частям/аппаратно/дополнительное ядро для программного когда, а аппаратные возможности у конкретного контроллера неплохие. Конечно, я бы добавил всяких интересных фич, но для этого лучше взять FPGA... Как и говорилось, для реализации входа/выхода этого достаточно. Вообще, в планах портануть на f103c8, но это когда будет скучно)
Можно согласиться с тем, что статья была написана не совсем корректно - мой первый опыт. Но тема здесь специфичная, ищущая человека, который достаточно скиловый в теме микроэлектроники. Это не для "подпивасного" скрола... Зачем? Когда мне поставили этот вопрос, я был бы рад найти какую-то интересную информацию, тем более пример кода. Может кому-то это поможет...
Соглашусь с сегодняшней нуждой в рилтайме и смертью профибаса, а особенно с замороченным программированием драйверов от Lenze) Но сегодня еще остается туча технологических линий, особенно в СНГ, которые собирали на трехсотке... А про зависание вообще впервые слышу. На производстве около сотни приводов, проблем таких ни разу не было...