[Гость @Ark]

... вдруг, по команде извне, начинаем АЦПировать и накапливать 100 значений, вместо того, чтобы делать это постоянно и спокойно отдавать при необходимости готовый результат.

... Только этот "готовый результат", полученный "постоянным и спокойным АЦПированием" - ни кому не нужен, когда необходимо получить мгновенное значение с максимальной точностью и минимальной временной задержкой. Вообще, что я Вам доказываю - каждый выбирает технические решения так, как считает нужным. Вам не нравятся мои подходы, а мне - Ваши. На том и остановимся. В конечном итоге - меня лично интересует только мнение заказчика по этому поводу, и ни чье больше...

Удачи!

[aaarrr 69]

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

Да нет, скорее вряд ли кому нужно "мгновенное значение", полученное с "минимальной временной задержкой", обеспеченной средствами Модбаса (т.е. примерно никак не обеспеченной).

 

Удачи!

И Вам!

[rezident 0]

2 defunct, еще раз обращаю внимание, что я писал про общий случай, а не про тот, когда устройство только связью занимается. И не про канальный уровень, а про физический, когда обработка прерывания по времени должна занимать как можно меньше времени. Потому, что могут быть и другие прерывания тоже критичные ко времени. Ничего не имею против вашего мнения, но получается, что вы сами себе возражали, т.к. переиначили мое сообщение так, чтобы вам было удобно возражать :)

[Гость @Ark]

... скорее вряд ли кому нужно "мгновенное значение", полученное с "минимальной временной задержкой", обеспеченной средствами Модбаса (т.е. примерно никак не обеспеченной).

Вашими методами, конечно, может получится "никак не обеспеченной", а за других - не "расписывайтесь". ;)

[aaarrr 69]

Вашими методами, конечно, может получится "никак не обеспеченной", а за других - не "расписывайтесь". ;)

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

 

Гениально просто: слейв получил команду "считать что-то с АЦП", и не убеждаясь в достоверности оной (мы ведь спешим, пожар!), начинает накапливать мильен отсчетов. А потом - бац! - CRC не совпало. Что делать? Конечно, отработать аварийный выход (и так для любой команды чтения, ага).

 

Красиво?

[Гость @Ark]

Ну, хорошо, давайте продолжим...

А что будет с вашей "минимальной временной задержкой", случись, скажем, ошибка при передаче?

Ничего страшного -"выпадет" одно из значений. Ошибки при передаче случаются при любом протоколе. При необходимости, мастер заменит выпавшее значение его аппроксимацией.

Минимальным задержкам место внутри одного устройства, а не в распределенной системе, связанной протоколом сорокалетней давности.

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

Гениально просто: слейв получил команду "считать что-то с АЦП", и не убеждаясь в достоверности оной (мы ведь спешим, пожар!), начинает накапливать мильен отсчетов. А потом - бац! - CRC не совпало. Что делать? Конечно, отработать аварийный выход (и так для любой команды чтения, ага).

Красиво?

А что Вас смущает? Вполне нормальная стратегия : обнаружили ошибку - прекратили выполнение команды и перешли обработке ошибки. А если нет ошибки, то результат готов сразу по завершению обработки команды.

Например, процессор в Вашем компьютере поступает примерно так же - очень много чего считает, забегая вперед, а потом лишь выбирает нужный результат. Если бы этого не было, то, возможно, Винда на Вашем ПК ползала бы как черепаха...

[aaarrr 69]

Ничего страшного -"выпадет" одно из значений. Ошибки при передаче случаются при любом протоколе. При необходимости, мастер заменит выпавшее значение его аппроксимацией.

Выпадет просто, да? А таймаут ответа "сверхточную" времянку, конечно, не сместит.

 

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

Ну, мне вот всегда казалось, что решение применить модбас можно принять разве что при наличии административного давления, если клиент очень того хочет.

 

А что Вас смущает? Вполне нормальная стратегия : обнаружили ошибку - прекратили выполнение команды и перешли обработке ошибки. А если нет ошибки, то результат готов сразу по завершению обработки команды.

Меня лично смущает принесение здравого смысла в жертву за три копейки, только и всего.

 

Например, процессор в Вашем компьютере поступает примерно так же - очень много чего считает, забегая вперед, а потом лишь выбирает нужный результат. Если бы этого не было, то, возможно, Винда на Вашем ПК ползала бы как черепаха...

Не считает, а считывает, и не очень много.

[Гость @Ark]

Выпадет просто, да? А таймаут ответа "сверхточную" времянку, конечно, не сместит.

С чего вдруг? Точность обеспечиватется, заранее известной, точной задержкой от завершения измерений до начала передачи ответа.

Ну, мне вот всегда казалось, что решение применить модбас можно принять разве что при наличии административного давления, если клиент очень того хочет.

Бывает и так. Мне и самому MODBUS не нравится. Но если клиент настаивает - как ему отказать? К тому же MODBUS - промышленный стандарт, все-таки.

Меня лично смущает принесение здравого смысла в жертву за три копейки, только и всего.

Это нужно считать отдельно, в каждом конкретном случае. Иногда стоимость "здравого смысла" - отнюдь не три копейки.

Не считает, а считывает, и не очень много.

И считывает, и считает (вычисляет). А потом еще "довычисляет", если нужно. И все равно, в итоге, получается быстрее...

[defunct 0]

И не про канальный уровень, а про физический,

Выше Вы привели ссылку на модель OSI, вы ее читали?

 

Физический уровень

Самый нижний уровень модели предназначен непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель или в радиоэфир и, соответственно, их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов. Другими словами, осуществляет интерфейс между сетевым носителем и сетевым устройством.

 

Канальный уровень

Этот уровень предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля за ошибками, которые могут возникнуть. Полученные с физического уровня данные он упаковывает во фреймы, проверяет на целостность, если нужно исправляет ошибки (посылает повторный запрос поврежденного кадра) и отправляет на сетевой уровень.

 

Физический уровень это сугубо природа сигналов, трансивер и иже с ним сдвиговый регистр и схема битового кодированая (манчестер, инверсия и т.п.). А выделением из мусора битов входного потока осмысленных данных, проверкой ошибок, занимается уже канальный уровень, на ступеньку выше. Прерывание от UART "кадр принят" это не физ, а канальный уровень.

 

когда обработка прерывания по времени должна занимать как можно меньше времени. Потому, что могут быть и другие прерывания тоже критичные ко времени. Ничего не имею против вашего мнения, но получается, что вы сами себе возражали, т.к. переиначили мое сообщение так, чтобы вам было удобно возражать :)

просто показал что имеет смысл собирать пакеты побайтово прямо в прерывании, а не наваливать бездумно все байты в буфер перекладывая тем самым работу канального уровня на сетевой уровень. Для примера взял PPP который в отличие от Modbus является протоколом строго канального уровня.

[aaarrr 69]

С чего вдруг? Точность обеспечиватется, заранее известной, точной задержкой от завершения измерений до начала передачи ответа.

То есть процесс считывания АЦП в вашей системе выглядит так:

1. Мастер через строго определенные промежутки времени дает запрос на считывание АЦП

2. Слейв считывает/накапливает, возвращает отсчет мастеру

3. Если ответ не получен, мастер восстанавливает данные интерполяцией

Я правильно понял?

 

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

 

Это нужно считать отдельно, в каждом конкретном случае. Иногда стоимость "здравого смысла" - отнюдь не три копейки.

Стоимость потери здравого смысла здесь определяется двумя байтами CRC, время на получение которых вы так упорно хотите сэкономить, наворотив при этом кучу ненужного кода. По сравнению с тем оверхедом, который в принципе дает использование модбаса, это - ноль.

 

И считывает, и считает (вычисляет). А потом еще "довычисляет", если нужно. И все равно, в итоге, получается быстрее...

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

[rezident 0]

Выше Вы привели ссылку на модель OSI, вы ее читали?

Вот потому, что я ее читал (и неоднократно) и не называю его канальным. Т.к. часть характеристики

Полученные с физического уровня данные он упаковывает во фреймы, проверяет на целостность, если нужно исправляет ошибки (посылает повторный запрос поврежденного кадра) и отправляет на сетевой уровень.

в моем описании отсутствует. Вообще сетевая модель OSI это лишь идеал. В реальности крайне мало (стеков) протоколов которые бы полностью укладывались в эту модель. Возможно я вообще зря ее упомянул. :cranky:

[Гость @Ark]

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

То есть, как я понял, Вы настойчиво предлагаете передавать все данные мастеру, отказавшись от их обработки в устройстве? Сделать канал побыстрее, увеличить траффик, нагрузить мастера дополнительными задачами... Я это уже комментировал, повторятся не буду.

Стоимость потери здравого смысла здесь определяется двумя байтами CRC, время на получение которых вы так упорно хотите сэкономить, наворотив при этом кучу ненужного кода. По сравнению с тем оверхедом, который в принципе дает использование модбаса, это - ноль.

Это всего лишь Ваше мнение, основанное видимо, на Вашем личном опыте программирования А когда оно еще и не привязано к условиям конкретной задачи - его ценность, увы, нулевая.

Ну, расскажите мне про современные процессоры...

http://ru.wikipedia.org/wiki/%D0%9F%D1%80%...%BE%D1%80%D1%8B

[aaarrr 69]

То есть, как я понял, Вы настойчиво предлагаете передавать все данные мастеру, отказавшись от их обработки в устройстве? Сделать канал побыстрее, увеличить траффик, нагрузить мастера дополнительными задачами... Я это уже комментировал, повторятся не буду.

Да нет же, все с точностью до наоборот. Это вы пытаетесь нагрузить шину "реалтаймовыми" и предельно неэффективными передачами по одному семплу. Я предлагаю снабдить слейв минимальным интеллектом, и работать блоками данных (накопленных, нормализованных и т.д. и т.п.), но не в реальном времени.

 

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

[defunct 0]

Вот потому, что я ее читал (и неоднократно) и не называю его канальным. Т.к. часть характеристики

в моем описании отсутствует.

Не совсем, у Вас в описании просматривается часть характеристки канального уровня - проверка правильности принятых данных (по крайней мере четность).

 

Вообще сетевая модель OSI это лишь идеал. В реальности крайне мало (стеков) протоколов которые бы полностью укладывались в эту модель. Возможно я вообще зря ее упомянул. :cranky:

Согласен, однако если грань между верхними тремя уровнями (session/presentation/app) настолько мала что ее часто трудно найти особенно в embedded сфере, то границы между нижними уровнями физ, канал, транспорт - просматриваются довольно четко. И хотя бы на этих трех уровнях можно пытаться стремиться к идеалу:

 

<физ уровень> --> сводится к драйверу железа или эмулятору железа (программый UART/ программный SPI)

<канальный уровень> ---> разбиение пакетов на голые байты и передача их драйверу железа, прием голых данных от железа и укладка в пакеты

<сеть> --> маршрутизация (проверка сетевого адреса).

<транспорт> --> укладка и выделение пользовательских данных в/из пакетов.

 

сетевой уровень (который лежит между транспортом и каналом) можно взависимости от конкретного протокола, объединять или с транспортным или с канальным уровнем. В случае одноранговой сети Modbus его выгоднее объединить с канальным уровнем, в случае многоранговой IP сети - с транспортным.

[Гость @Ark]

Я предлагаю снабдить слейв минимальным интеллектом, и работать блоками данных (накопленных, нормализованных и т.д. и т.п.), но не в реальном времени.

Ну, а как быть с реальным временем?

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

Да, действительно. О том, что команды из конвейеров могут выполняться не по порядку - ничего не сказано.