Просмотр полной версии : Прошу совета
На Овеновское ВУ с. STM по модбас рту подаю команду. Мне не важно,когда прийдет ответ. Мне важно знать,ког
да байты ответа полностью заскочат в буфер STM. Так же могу контролировать каждый входящий байт.Мне
необходимо по приходу последнего байта вытянуть ответ из буфера, тем самым очистив его. С ответом по DCON
и ОВЕН. протоколам проблем нет, так как ответы заканчиваются маркером OD. Не зная последнего байта я в бу
Фере ловлю ответ сдвинутый как попало,т.е байты ответа правильные ,но начало строки ответа
может быть в середине строки и вообще где угодно.
А по таймауту длительностью в полтора байта при передаче ответа никак? И кстати, вы должны знать, сколько слов в ответе, начало ответа по перввым двум байтам элементарно определяется.
А по таймауту длительностью в полтора байта при передаче ответа никак? И кстати, вы должны знать, сколько слов в ответе, начало ответа по перввым двум байтам элементарно определяется.
Пробовал с временными фокусами. Все равно информация в строке сдвинута. Если предварительно посчитать количество
байтов ответа,могу поймать последний байт,но не могу же я для каждой команды это просчитывать.
Пробовал с временными фокусами. Все равно информация в строке сдвинута. Если предварительно посчитать количество
байтов ответа,могу поймать последний байт,но не могу же я для каждой команды это просчитывать.
По адресу устройства находите равный ему первый байт, по первому байту находите команду и длину посылки, по ней находите CRC, если CRC совпало - всё вычислено правильно, иначе ищете другой первый байт.
По адресу устройства находите равный ему первый байт, по первому байту находите команду и длину посылки, по ней находите CRC, если CRC совпало - всё вычислено правильно, иначе ищете другой первый байт.
Поясняю боллее конкретно. Выдаю команду 10 03 01 00 00 01 86 АС В ответ должен получить 10 03 02 80 00 25 0Е
Но получаю 80 00 25 0Е 10 03 02 или 03 02 80 00 25 0Е 10 и тд. Те. байты ответа приходят правильные , но начало
пакета может начинаться с любого байта .Если бы ответ приходил по декону или овну,проблем бы никаких не было,т.к
у них в конце пакета служебный символ 0D. Отслеживая входной поток по этому признаку конца я извлекаю данные из
буфера,этим самым очищаю его. С модбасом такой фокус не проходит. Ваши рекомендации справедливы в том случае,если бы адрес ,который Вы советуете отлавливать и от него плясать,стоял последним в сообщении,а не первым.
Если я последую Вашему совету и по приходу адреса,буду читать буфер, то кроме байта с этим адресом там ничего не
будет.
Решений типа обработать пришедшую строку,те ее упорядочить-не предлагать.Это я сам
знаю.
Поясняю боллее конкретно. Выдаю команду 10 03 01 00 00 01 86 АС В ответ должен получить 10 03 02 80 00 25 0Е
Но получаю 80 00 25 0Е 10 03 02 или 03 02 80 00 25 0Е 10 и тд. Те. байты ответа приходят правильные , но начало
пакета может начинаться с любого байта.
Разве такое возможно?
VaBo товарищ CRC считает в онлайн калькуляторе, ему впадлу написать 10 строк кода, чтобы она считалась сама по себе....
на счет смещения байт тоже какой-то бред, слейв устройство не начнет отвечать пока его не спросят. Судя по всему, что-то не так в датском королевстве программиста, который не дождавшись одного ответа опять посылает в сеть очередной запрос...
Поправка - не обработав один ответ посылает очередной запрос...
Выдаю команду 10 03 01 00 00 01 86 АС В ответ должен получить 10 03 02 80 00 25 0Е
Но получаю 80 00 25 0Е 10 03 02 или 03 02 80 00 25 0Е 10 и тд. Те. байты ответа приходят правильные , но начало
пакета может начинаться с любого байта .
Вам надо понять, где что в буфере? Начало пакета в этом примере 10 03 (или при ошибке 10 83) Непонятно, чем знание конца полезнее знания начала.
Разве такое возможно?
Байты с прибора Овен приходят в правильной последовательности. Но я сторонним прибором их отловить не могу,так не знаю от чего синхронизироваться.
Одесса синхронизироваться необходимо от окончания запроса. в RTU слейв устройство не отвечает когда попало, а только после определения, что запрос прислан именно ему и что CRC запроса соответствует пакету. иначе слейв просто промолчит.
Послали запрос - ждите ответа.
з.ы. мне что-то кажется, что вы в многопоточном режиме даже опрос прибора сделали в STM, а это неправильно.
VaBo товарищ CRC считает в онлайн калькуляторе, ему впадлу написать 10 строк кода, чтобы она считалась сама по себе....
на счет смещения байт тоже какой-то бред, слейв устройство не начнет отвечать пока его не спросят. Судя по всему, что-то не так в датском королевстве программиста, который не дождавшись одного ответа опять посылает в сеть очередной запрос...
Поправка - не обработав один ответ посылает очередной запрос...
Мелки Вам неоднократно делали замечания по поводу Вашей невнимательности. Если Вы и дальше будете делать выводы
космических масштабов не вникнув в суть вопроса это вызовет не только недоумение но даже смех. У меня есть предположение
что это даже не невнимательность,а элементарная лень прочитать до конца пост и вникнуть в суть проблемы. В этом ответе я легко
и аргументированно докажу правоту вышеизложенных слов . И в каждом другом посте сделаю то же самое.
1. Отвечаю на 1 абзц Вашего ответа. Товарищу не впадлу написать 10 строк кода по вычислению СRC. Товарищ написал этот совет
не программистам,а слесарям-киповцам,для которых слово CRC является матерным ругательством и которым я посоветовал использовать калькулятор для его вычисления.
2. По второму вопросу насчёт датского королевства. В каком конкретно предложении и какого поста вы видили ,чтобы я посылал
запрос к устройству не дождавшись ответа по первому запросу? Вы сами родили такое предположение. И в в своей нелепой
фантазии обвиняете меня.
Одесса тогда простой вопрос - почему у вас ответ начинается не с 1-ого байта а идет мешанина ?
Найдете ответ на этот вопрос - найдете и решение получать данные с 1-ого байта.
Еще раз говорю, любой прибор слейв в сети Modbus не будет ничего передавать, если не проверит что запрос предназначен ему и он не битый.
Никаких смещений в буфере ответа быть не должно в принципе.
Но получаю 80 00 25 0Е 10 03 02 или 03 02 80 00 25 0Е 10 и тд. Те. байты ответа приходят правильные , но начало
пакета может начинаться с любого байта
Это говорит о том, что прибор отвечал несколько раз (было несколько запросов) и вы ловите куски различных ответов в буфере... найдите причину почему
Одесса синхронизироваться необходимо от окончания запроса. в RTU слейв устройство не отвечает когда попало, а только после определения, что запрос прислан именно ему и что CRC запроса соответствует пакету. иначе слейв просто промолчит.
Послали запрос - ждите ответа.
з.ы. мне что-то кажется, что вы в многопоточном режиме даже опрос прибора сделали в STM, а это неправильно.
Отвечаю опять же аргумментированно.
1.Я не обращаюсь к кому попало с неправильной контрольной суммой команды. Если бы я. так сделал ,как Вы предполагаете,то
Ваши предположения верны. Но они не верны. Устройство отвечает. О чем написано в первых постах,которых Вы не читали. Если
бы читали, первого предложения в этом посте не было бы.
2. Комментировать то,что Вам кажется ни есть аргументом для специалиста. Ни в каком многопоточность режиме я не работаю,
это я для того ,чтоб Вам не казалось.
Одесса я и не говорил, что вы обращаетесь к кому попало, я только сказал, что вы обращаетесь явно более одного раза до окончания ответа и его обработки.
По этому у вас в буфере и идет скользящие ответы.
Повесьте на порт ПК с наблюдателем порта и сами посмотрите что у вас с запросами и что с ответами, ну и скрин программы сюда выложите, потому что интересно.
Ну и шаманов с бубнами тут нет, чтобы на словах понять, что вы там за код накодили...
Я вот на ПК принимаю с порта 100-150 байт и мне как-то в голову не приходит искать какой-то там байт, я просто беру весь полученный буфер за минусом CRC, считаю CRC и сверяю с CRC, присланным прибором - ВСЕ, что я делаю не так ?
Отсюда вопрос, почему у вас буфер не с 1-ого байта ответа а скользящий ?
Одесса тогда простой вопрос - почему у вас ответ начинается не с 1-ого байта а идет мешанина ?
Найдете ответ на этот вопрос - найдете и решение получать данные с 1-ого байта.
Еще раз говорю, любой прибор слейв в сети Modbus не будет ничего передавать, если не проверит что запрос предназначен ему и он не битый.
Никаких смещений в буфере ответа быть не должно в принципе.
Но получаю 80 00 25 0Е 10 03 02 или 03 02 80 00 25 0Е 10 и тд. Те. байты ответа приходят правильные , но начало
пакета может начинаться с любого байта
Это говорит о том, что прибор отвечал несколько раз (было несколько запросов) и вы ловите куски различных ответов в буфере... найдите причину почему
Мелки. Жаль что синусоида Вашего биологического жизненного ритма ,а именно интеллектуальная кривая находится сейчас
даже не на нулевом уровне ,а в глубоком минусе. Отвечаю почему. Вы мне советуете ответить на вопрос самому себе именно на
тот вопрос,который я задал на форуме. Вопрос к Вам - нафига мне задавать вопрос на форуме,если я по Вашему совету должен
отвечать на него сам.
На Ваши рассуждения о том,что никаких смещений в буфере не должно быть в принципе,я с Вами вполне согласен.
Но я не знаю где у содержимого буфера начало. И если я не зная этого вытаскиваю содержимое буфера с произвольного буферного
индекса ,принимая его за начало,то после этого все остальные байты буфера строятся за этим ,как бы началом. И за этого и получается ,что содержимое буфера ,вытянутое мной появляется в таком непристойном виде.
Чтоб Вам было более понято,пока Ваша синусоида не выйдет на нужный уровень, объясняю. Если по протоколу
DCON или Овен последним байтом в в ответе является байт OD, то у модбаса такой фишки нет. И с этими протоколами у меня нет
проблем. Отслеживая входные данные по этим протоколам,я ориентируюсь на этот байт,по приходу которого извлекаю содержимое буфера, тем самым его опорожняя. У модбаса такого конечного байта нет. Поэтому я и задал вопрос на форуме. На
мой вопрос Вы ответили,что я дятел,который CRC считает на калькуляторе и что я не дружу с датским королевством и что бы
Я сам отвечал на свой вопрос,заданный мной на форуме.
Спасибо вам за Ваш обстоятельный ответ.
Одесса поиском конечного байта в протоколе Овен или DCON в скользящем буфере вы сделали костыль, при помощи которого вы получаете ответы от приборов.
Найдите первопричину и у вас отпадет необходимость в костыле.
Я пока еще не изучал STM, мне еще это только предстоит, но ваша проблема именно в том, что вы изначально неправильно работаете с портом при опросе приборов.
Скрин с программы снифера будет ? без него все вами вышесказанное ни о чем...
Опять же, код программы опроса тоже не помешал бы, тут и Сишники наверняка бродят.
А вообще вам больше какой-то профильный форум по STM даст больше толку...
Одесса я и не говорил, что вы обращаетесь к кому попало, я только сказал, что вы обращаетесь явно более одного раза до окончания ответа и его обработки.
По этому у вас в буфере и идет скользящие ответы.
Повесьте на порт ПК с наблюдателем порта и сами посмотрите что у вас с запросами и что с ответами, ну и скрин программы сюда выложите, потому что интересно.
Ну и шаманов с бубнами тут нет, чтобы на словах понять, что вы там за код накодили...
Я вот на ПК принимаю с порта 100-150 байт и мне как-то в голову не приходит искать какой-то там байт, я просто беру весь полученный буфер за минусом CRC, считаю CRC и сверяю с CRC, присланным прибором - ВСЕ, что я делаю не так ?
Отсюда вопрос, почему у вас буфер не с 1-ого байта ответа а скользящий ?
Ничего Вы там не вытаскиваете. За Вас это делает СОМ Ская утилита,которая следит за входным буфером,а Ваше дело отследить в программе ,когда Вам эта утилита скажет,что данные в буфере готовы- мол забирайте товарищ. Поэтому Вам так и
легко отбросить CRC и всех деллов. И как эта утилита положила эти данные в буфер ,это проблемы утилиты. Я же эти данные вы
таскиваю сам,как ота утилита.
Одесса сами, сами, кто же спорит, только внимательнее прочтите - запрос, проверка запроса слейвом, что обратились именно к нему и именно правильно обратились и только тогда ответ. Слейвы тупые, они не передают данных когда их не просят и они не предают данные несколько раз если их спросили один раз.
ВДУМАЙТЕСЬ в эту последовательность.
У вас на STM есть возможность использовать дискретный вход ? сделайте подпрограмму запроса только по импульсу включения входа а не в цикле и посмотрите что у вас получится.
Одесса поиском конечного байта в протоколе Овен или DCON в скользящем буфере вы сделали костыль, при помощи которого вы получаете ответы от приборов.
Найдите первопричину и у вас отпадет необходимость в костыле.
Я пока еще не изучал STM, мне еще это только предстоит, но ваша проблема именно в том, что вы изначально неправильно работаете с портом при опросе приборов.
Скрин с программы снифера будет ? без него все вами вышесказанное ни о чем...
Опять же, код программы опроса тоже не помешал бы, тут и Сишники наверняка бродят.
А вообще вам больше какой-то профильный форум по STM даст больше толку...
Если бы я был грубым человеком,то ответил бы,что сам ты костыль,но так как я человек воспитанный,то так не отвечу-солдт
ребенка не обидит. Где ты там костыль увидил? Как мне по другому бескостыльному методу принять ответ по деконовскому
протоколу? Ответь пожалуйста. Буду безмерно благодарен. Спецов профильного форума сопряжение приборов Овен с STM мало
волнует. Насчёт кода программы. У STM стандартное решение UART приемника,как в любом процессоре.В программном плане
я должен указать размер буфера и все. По заполнению буфера возникает прерывание основной программы и я должен в подпрограмме прерывания вытянуть эти данные. Но я не знаю сколько байт мне должно прийти и поэтому размер буфера указываю приблизительно,что неправильно. Также прерывание можно сделать по любому байта. Пробовал и то и другое.
Задавая вопрос на форуме-готового решения не получил. На форуме по STM задавать не буду,там у меня самого спрашивают.
Поэтому тему закрываю. Возьму свою абракадабру с буфера, найду в нем адрес,поставлю его первым и к нему приклею все остальное. Вот это называется костыли,а не то о чем говорите Вы. Это называется ещё решил проблему через жопу. Иногда и такое
приходится делать .
Вопрос закрыт.
Одесса сами, сами, кто же спорит, только внимательнее прочтите - запрос, проверка запроса слейвом, что обратились именно к нему и именно правильно обратились и только тогда ответ. Слейвы тупые, они не передают данных когда их не просят и они не предают данные несколько раз если их спросили один раз.
ВДУМАЙТЕСЬ в эту последовательность.
У вас на STM есть возможность использовать дискретный вход ? сделайте подпрограмму запроса только по импульсу включения входа а не в цикле и посмотрите что у вас получится.
Если бы я делал запрос два раза, то в ответе получил бы повторяющиеся байты. А я получаю полноценный ответ ,со всеми байтами
и правильной контрольной суммой,но порядок последовательности байтов неправильный.
Одесса 1. размер буфера можно указывать больше, если неизвестно количество принимаемых байт
2. первый байт который посылает прибор в ответ должен лежать на первом месте, независимо от размера буфера
Где у вас 1-й байт ? почему не на месте ? сделали так именно вы и никто другой.
в стопятьсотый раз повторяю, вы не принимаете данные от прибора, который всегда посылает данные с некоторым промежутком времени (типа аля маяк, хочу мигаю, хочу не мигаю), вы принимаете данные ТОЛЬКО ПОСЛЕ выполнения запроса данных у прибора и никак иначе в данном случае.
у вас режим запрос - ответ. оставьте в программе один единственный запрос или увеличьте время между запросами до 5 минут и посмотрите снифером порта что происходит. и только потом начинайте думать что не так у вас в программе.
з.ы. спецам по STM должно быть фиолетово, что именно вы опрашиваете через порт если у вас проблема в программе.
Одесса, я выше написал, возможно у вас проблема с заполнением буфера, неправильная его организация и х.з. что еще.
Если бы ответ прибора был один и просто распихивался бы хаотично в буфер байтами это одно, но вот то, что у вас в буфер попадает точная последовательность, наводит на странные мысли.
Например если один ответ был бы обрезан, но никак не заполнен точными значениями обрезанной части.
Причем тип протокола тут абсолютно тоже не при чем.
Ревака Юрий
14.09.2018, 17:05
Очень похоже что буфер неправильно инициализируется, и пришедший байт ложится в середину.
Очень похоже что буфер неправильно инициализируется, и пришедший байт ложится в середину.
ну Вы то куда, он привел чисто гипотетический пример. Ему нужна просто реализация протокола modbudRTU, разобраться со всеми "паузами тишины" и всё
Ревака Юрий
14.09.2018, 17:58
он привел чисто гипотетический пример.
мне показалось что это живой пример:)
Очень похоже что буфер неправильно инициализируется, и пришедший байт ложится в середину.
Тут нечего смотреть
мне показалось что это живой пример:)
Это живой пример
Это живой пример
Наверное скаду ,что обещали пилите ? если она золотая ,то можно- осталось 1-2 недели ....
Наверное скаду ,что обещали пилите ? если она золотая ,то можно- осталось 1-2 недели ....
Да куда мне. А Вы наверное соскучились. Давно на Вашей ветке шороху не делал? Щас с Капзапом столкуюсь и прийдем Вашу
Каскаду причешем. А то у Вас там ,кроме вечерних телепередач для телепузиков ничего не наблюдается. Да и от телепузиков
вопросов не поступает. Тихо мирно сами с собой диалог ведёте.
Да куда мне. А Вы наверное соскучились. Давно на Вашей ветке шороху не делал? Щас с Капзапом столкуюсь и прийдем Вашу
Каскаду причешем. А то у Вас там ,кроме вечерних телепередач для телепузиков ничего не наблюдается. Да и от телепузиков
вопросов не поступает. Тихо мирно сами с собой диалог ведёте.
Вопросов мало потому что все интуитивно понятно , а остальные на почте ,ну не регистрироваться для этого на форуме же ....
И давно банов не получали ;), а тут в подвале тепло и мухи не кусают :p
Одесса покажите что фиксирует снифер порта.
Размер NewData где задается ? безразмерный ? как чтение происходит ?
И еще вопрос: почему вы байтовый буфер лепите в строковую переменную ? в ответе что, все байты соответствуют ASCII кодам что ли ?
Это же вам не Овен и не DCON чтобы работать со строками.
Мне просто интересно, как вы будете работать например со счетчиками электроэнергии, где все выглядит примерно так:
- Эй, счетчик 20, открой канал связи
- я 20-й, канал связи открыл, че хотел ?
- Держи пароль, хочу от тебя данные получить
- Пароль принял, спрашивай, о хозяин
- Зафиксируй для меня данные
- Зафиксировал, какие из них хочешь получить ?
- Дай мне, ну это, ты знаешь, что Вольтами зовутся
- Ну на, держи
- Ну хрен с тобой, закрывай канал связи
- Закрыл, мог бы и не просить, через время и так бы закрыл, если бы ниче больше не спрашивал...
Одесса покажите что фиксирует снифер порта.
Размер NewData где задается ? безразмерный ? как чтение происходит ?
И еще вопрос: почему вы байтовый буфер лепите в строковую переменную ? в ответе что, все байты соответствуют ASCII кодам что ли ?
Это же вам не Овен и не DCON чтобы работать со строками.
Мне просто интересно, как вы будете работать например со счетчиками электроэнергии, где все выглядит примерно так:
- Эй, счетчик 20, открой канал связи
- я 20-й, канал связи открыл, че хотел ?
- Держи пароль, хочу от тебя данные получить
- Пароль принял, спрашивай, о хозяин
- Зафиксируй для меня данные
- Зафиксировал, какие из них хочешь получить ?
- Дай мне, ну это, ты знаешь, что Вольтами зовутся
- Ну на, держи
- Ну хрен с тобой, закрывай канал связи
- Закрыл, мог бы и не просить, через время и так бы закрыл, если бы ниче больше не спрашивал...
Завтра все обясню подробно и зачем я байтовый массив в строковую переменную луплю и как сниффер снифируется и все
что Вас интересует. А сейчас пятница,вечер. Нужно 300гр накатить и на Ровкиной ветке пьяный дебош устроить. А то этот дед
сюда приполз и своей старческой рукой баном угрожает. Я при этом начинаю так волноваться,что забыл,что такое сниффер. Кстати
принесли на днях старого кота,на 2 дня,чтоб я просмотрел. Так я его Ровкой назвал. Отзывается на это имя гад.
Какой смешной ТС. Ему много раз ответили - продолжает бить себя ногой в грудь что весь в белом.
Никакие девайсы не посылают часть ответа. Только полностью.
Чото потерялось - ищи у косячного юзера/косячных либы/косячного железа со стороны мастера. Других вариантов нет.
По сути вопроса - ответ в п#2. Все другое - онанизм
С такими-то понтами и не можешь ? Тогда на форум филателистов.
Картинку с каким-то куском зачем-то пришпилил. К этому куску можно добавить такой же красивый кусок увешанный пояснениями но всё вместе станет полным говном. Тем более со строками, как правильно заметили. К чему была картинка то ?
Кто тебе Валенок сказал,что я получаю часть ответа? Я в 10 раз повторяю ,что ответ получаю полностью,а не половину. И ответ получаю у который,как бы разрезали на две части и части эти поменяли местами. Насчёт понтов- если бы они у меня были
Я бы тут вопросов не задавал. Это ты со своими понтами предлагаешь искать причины в железе. Насчёт ,что мне здесь ответили
100 раз. Чего тут мне тут понаотвечали? Если эти сто ответов включая твой под пресс положить то из под него не вытечет и грам
ма полезной для меня информации, потому,что в этих ответах было больше вопросов. А картинку нарисовал для таких ,как ты
которые только на пальцах понимают. Но тебе,как видно и такая распальцовка не поможет. Не можешь ответить на мой вопрос
так от твоих растопыренных пальцев моя проблема не решится.
А на самом деле картинку я нарисовал для Юрия, который предположил,что я неправильно
инициализировал буфер. И на картинке я ему четко показал как буфер инициализируется . Если б
ты прочитал кому адресуется картинка и что предполагает адресант, ты бы глупых вопросов не
задавал.
Вам надо понять, где что в буфере? Начало пакета в этом примере 10 03 (или при ошибке 10 83) Непонятно, чем знание конца полезнее знания начала.
Программными средствами я могу контролировать любой байт залетающий в буфер. Допустим могу отловить 1 адресный байт
и по этому событию могу прочитать буфер. Но толку от этого не будет,потому что буфер будет пуст,так туда ещё ничего не успело
залететь. Если бы этот адресный байт был последним,то я бы отловив этот байт ,и по этому событию прочитав буфер, увидил бы
Все данные,где последним был бы адресный байт.
Все проблему решил костылем. Обработал принятую строку следующим образом. Нашел в строке адресный байт и его индекс.
путем перебора. Не очень сложными программными манипуляциями вырезал адресный байт с байтами следующими за ним до
конца строки. И поставил этот байтовый блок в начало строки. Понимаю,что это не лучший метод решения,но лучшего не знаю.
Спасибо тему закрываю.
Программными средствами я могу контролировать любой байт залетающий в буфер. Допустим могу отловить 1 адресный байт
и по этому событию могу прочитать буфер. Но толку от этого не будет,потому что буфер будет пуст,так туда ещё ничего не успело
залететь. Если бы этот адресный байт был последним,то я бы отловив этот байт ,и по этому событию прочитав буфер, увидил бы
Все данные,где последним был бы адресный байт.
А что Вам мешает отловить сперва адресный байт, потом байт с командой, потом байты CRC, разобрать весь пакет на лету? Или проделать то же самое, набрав в буфер все принятые байты за время до следующего запроса?
А что Вам мешает отловить сперва адресный байт, потом байт с командой, потом байты CRC, разобрать весь пакет на лету? Или проделать то же самое, набрав в буфер все принятые байты за время до следующего запроса?
Я наверное Вас до конца не понял.Я програмно могу на лету поймать зараннее известный байт. Этим байтом является
из пакета только адресный, допустим я его отловил.По этому событию я могу сделать толко одно действие. это прочитать содержимое буфера на момент ,когда я этот байт поймал.Ну посмотрю я буфер и не увижу там ничего,потому,
что следующий байт еще не зашел. Я согласен с Вами,что рыть нужно в направлении указанном Вами,что и делаю в настоя
щий момент.
Я согласен с Вами,что рыть нужно в направлении указанном Вами,что и делаю в настоя
щий момент.
а там посмотреть как реализован протокол в modbus.lib и взять из него стоящие моменты, например очистка буфера...
ЗЫ jamod еще есть в сырцах
Спасибо.Сам не допер. Так и сделаю.
Это ты со своими понтами предлагаешь искать причины в железе.Да, да. Далее - определились. Дело не в бобине. С смысле не в железе..
....Все проблему решил костылем. . Инвалидный как далее оказалось код только костылями - это да.
О ее решении написал в посте 35...Да. Я ошибся. То что было с 3-ого по 34-й пост - не онанизм, а просто заблуждение. Онанизм начался с 35-ого поста.
.. Это решение у меня было до обращения к форуму
.. но началось до обращения к форуму 8( ??
А что Вам мешает отловить сперва адресный байт, потом байт с командой, потом байты CRC, разобрать весь пакет на лету? Или проделать то же самое, набрав в буфер все принятые байты за время до следующего запроса?
Автору темы ничего не мешает заниматся этим онанизмом. Он даже считает что у него что-то получается.
Но для RTU это в принципе бред. В момент перехода мастера к чтению ответа в приемном буфере пусто (или мусор от помех) т.к. слейв еще принимает запрос или отбивает тайм-маркер а не генерит чего-либо. И если первый же байт не нужный адрес, можно, нет, вру, не можно, а обязательно нужно весь последующий кусок до самого тайм-маркера отправлять в мусор.
Автору темы ничего не мешает заниматся этим онанизмом. Он даже считает что у него что-то получается.
Но для RTU это в принципе бред. В момент перехода мастера к чтению ответа в приемном буфере пусто (или мусор от помех) т.к. слейв еще принимает запрос или отбивает тайм-маркер а не генерит чего-либо. И если первый же байт не нужный адрес, можно, нет, вру, не можно, а обязательно нужно весь последующий кусок до самого тайм-маркера отправлять в мусор.
Для справки. Если программа написано правильно, в момент перехода мастера к чтению ответа в приемном буфере либо лежит ответ, либо сообщение об ошибке. Мастеру при этом даже не обязательно ждать таймаута конца передачи. В остальных случаях мастеру незачем переходить к чтению.
Для справки. Если программа написано правильно, в момент перехода мастера к чтению ответа в приемном буфере либо лежит ответ, либо сообщение об ошибке. Мастеру при этом даже не обязательно ждать таймаута конца передачи. В остальных случаях мастеру незачем переходить к чтению.
а где, кстати, обозначено что реализуют мастера?
а где, кстати, обозначено что реализуют мастера?
На Овеновское с. STM по модбас рту подаю команду. Мне не важно,когда прийдет ответ....
...............в первой посте
Для справки. Если программа написано правильно, в момент перехода мастера к чтению ответа в приемном буфере либо лежит ответ, либо сообщение об ошибке. Мастеру при этом даже не обязательно ждать таймаута конца передачи. В остальных случаях мастеру незачем переходить к чтению.
Справка от кого ?
Если слейв реализовал машину времени - да. Если не реализовал, то :
Мастер переходит в чтению после отправки последнего байта.
В этот момент в слейве в лучшем случае лежит всё кроме последнего байта. Именно байта. Потому что пока нет последнего бита - на слейве не сработало прерывание о готовности к передаче в систему цельного байта.
А еще ему (слейву) нужно отбить тайм-маркер потому что все что есть у слейва до окончания тайм-маркера - мусор, и только мусор (Если, конечно мы говорим об RTU а не о "как бы RTU").
И все это время все слейвы на линии(получил первый байт, ... последний байт, выдержал тайм-маркер) молчат. Тупо молчат. А мастер тем временем уже ждет ответ. И ждет (как минимум) время пути последнего бита последнего байта запроса + тайм-маркер (который выдерживает слейв).
И откудова у мастера возникнет ответ сразу после ухода запроса ? Звездные врата форева ?
И это все - если вы сами побайтно пихаете в порт, а не из ЯВУ делает аналог неблокируемого "syscomwrite". В противном случае мастеру нужно учесть :
1. блуждание данных в собственных системных недрах
2. время физического ухода данных в линию
3. ну и тайм-маркер слейва
Ну и раз пошла такая ... детализация
4. время разбора пакета слейвом
5. время формирования ответа слейвом
6. блуждание данных в собственных системных недрах слева
7. время в пути до мастера первого (старт) бита
8. время заскакивания в мастера всех остальных битов сетевого байта
9. время обслуживания системой прерывания по приходу первого байт на мастере
10. задержка обращения пользователя к чтению данных из системы чтоб увидеть хотя бы первый пришедший байт для рестарта отсчета таймаута и начале отсчета тайм-маркера (который, в свою очередь будет рестартовать после каждого чтения из системы при условии наличия там данных).
В зависимости от релиза некоторые пункты могут слится в экстазе. Но все всегда будут.
.....в момент перехода мастера к чтению ответа в приемном буфере либо лежит ответ, либо сообщение об ошибке....В остальных случаях мастеру незачем переходить к чтению.
Ну и как мастер вообще определит читать - пора ? Событие ? Так оно ж формируется из биб-ки/системы. Но при этом остается такой же программой.
И вот тут-то и переходим к ключевой фразе :
Если программа написано правильно.... .
+100500.
ТС'у это и предлагал выяснить. Он предложил какие-то цветные пятна несущие кокой-то (по его словам) тайный смысл (видимо в расширенном сознании) и стал измерять ширину распальцовки. Обычное дело.
...............в первой посте
ну и кто тут троль?
Упоминание слова мастер присутствует? Да есть описание работы ведущего и что.
Ситуация, когда в приемный буфер приходит последовательность запроса модбас но частично меняющая куски запроса (конец с началом), может существовать только когда этот буфер слейва и не корректная работа мастера, который не ждет ответов от слейвов, а каждый цикл шлет запросы
Автору темы ничего не мешает заниматся этим онанизмом. Он даже считает что у него что-то получается.
Но для RTU это в принципе бред. В момент перехода мастера к чтению ответа в приемном буфере пусто (или мусор от помех) т.к. слейв еще принимает запрос или отбивает тайм-маркер а не генерит чего-либо. И если первый же байт не нужный адрес, можно, нет, вру, не можно, а обязательно нужно весь последующий кусок до самого тайм-маркера отправлять в мусор.
УВ. Валенок. Заметьте,после замечания Ровки обращаюсь к Вам на Вы.Хочу успокоить всех форумчан и Вас в том числе.Решение
Найдено. К сожалению не на этом форуме. И Ваши рассуждения програмно-филоссовские с применением специфических терминов
типа онанизма на техническм форуме, не имели успеха. Так ,что относитесь к таким терминам с осторожностью. В решение этого
вопроса хочу поблагадарить сапзапа и rwq и Юрия,которые поняли суть проблемы. Остальные не поняв сути давали советы косми
веских масштабов ,не вникая в суть,в том числе и Вы. Теперь о том как эту проблему я решил по советам 3 людей которых я перечи
слил. Суть проблемы я узнал от Юрия. Направление решения я узнл от RWG. Путь поиска от сапзапа. Учитывая это я обратился на
американский форум ,благо с англицким дружу. И первый америкос для которого программирование есть хобби,а не специальность ответил мне четко на решение моей проблемы.Он в отличии от валенка понял суть проблемы. Зовут его RIs.
Он сказал мне,что я не вовремя читаю буфер. И почитав это я получаю только часть буфера,не дочитав его до конца. И этот конец
,который я недочитал приклеивается в начало. И посоветовал мне следуещее. Поймать мне первый байт (адресный,как советовал
rwq) и по нему запустить таймер на время соответствующее времени прохождения одного байта при указанной скорости) и при
Этом следить за состоянием этого таймера. Поскольку каждый новый байт поступающий в буфер перезапускает этот таймер,то
Таймер то он не сбросится до конца посылки полного пакета ответа от клиента модбаса.. Програмно отслеживая сброс таймера,
Я могу сделать вывод,что пакет ответа лежит в буфере. И только с этого момента я его могу читать .
Логику америкоса я проверил. И получил правильное расположение байтов ответа от слэйва. Всем спасибо. Особенно сапзапу,
Юрию и RGW.
Справка от кого ?
Если слейв реализовал машину времени - да. Если не реализовал, то :
Мастер переходит в чтению после отправки последнего байта.
Не обязательно. В моих программах Мастер отдаёт блок данных обработчику передачи по СОМ-порту, озадачивает обработчиков приёма по СОМ-порту и таймаутов и отключается. А в нужное время, получив сообщение от обработчика приёма или обработчика таймаута, возвращается к своей работе.
Хочу добавить ,что поиск сырцов,рекомендованных сапзапом не увенчался успехом.
На форуме ардуинщиков по проблеме модбаса нашел решение,но оно меня не устроило.
Нашел решение на Расбери,которое мне понравилось. Но до конкретного его анализа не дошел.
Так,как применил решение америкоса.
Заметьте,после замечания Ровки обращаюсь к Вам на Вы.
У меня рога от "ты" выросли ? Можете даже называть меня грязным подонком купить пару валенков и тыкать в них иголки ))
Он сказал мне,что я не вовремя читаю буфер. И почитав это я получаю только часть буфера,не дочитав его до конца
О-о-о. Прочитав некоторые Ваши посты в других темах даже предположить такой глупости от Вас не мог. А Ris без комплексов - предположил. Ему респект.
Хотя если б ранее сказали что навел на ответ именно rwg - возможно и дошло б. Потому что именно его (rwg) ход мыслей ясен после п#45. Вышел-зашел, а прошло мсек 10-30. Поэтому и ответик мог образоватся. А то что не дождавшись полного ответа генерите запрос .... многих повеселили думаю.
http://www.owen.ru/forum/showthread.php?t=29367
Про тоже практически и там п#2. ТС там не Вы, но Вы ж и там отметились.
Поймать ... первый бай ... по нему запустить таймер ....каждый новый байт поступающий в буфер перезапускает этот таймер,то ...Таймер то он не сбросится до конца посылки полного пакета ответа от клиента модбаса
На надцатом посту это стало откровением ? )))))
PS
))
А Ris не советовал помимо таймера еще и общую текущую длину данных в буфере на предмет превышения максимально возможного размера в RTU и самого буфера проверять ?
Если нет - то и он в глазах упадет.
Мастер отдаёт блок данных обработчику передачи по СОМ-порту, озадачивает обработчиков приёма по СОМ-порту и таймаутов и отключается....
Да все понятно )) Отдали всю работу нижнему уровню. При наличии потоков - это вполне норм.
Тут ТС рассмешил с тем, что получив что-то - сразу посчитал что это - всё.
"Чото потерялось - ищи у косячного юзера/косячных либы/косячного железа со стороны мастера. Других вариантов нет"
Вообщем вариант 1.
Да ни вопрос.
"Никакие девайсы не посылают часть ответа. Только полностью.
Ни один слейв не посылает ответ полностью но с переставленными кусками. Только в правильном порядке. ... ""
Тут всех посылаете читать что написано ? Так и я пошлю. Читайте внимательно. Второй раз. Было ведь уже. Но повторюсь:
"...Чото потерялось - ищи у косячного юзера/косячных либы/косячного железа со стороны мастера. Других вариантов нет"[/B]
Железо - последний вариант. А начинать надо с первого.
Так читайте внимательно. Второй раз - заметь :
По сути вопроса - ответ в п#2
Может что с Вашим прессом ? Всё бывает. А п#2 достаточно для ручной выжимки достаточной информации.
По чему не могу ? См. про суть - см. выше. Просто сначала подумал что Вы не заметили ответа. Так бывает у птиц каких-то. Пока токуют - можно хоть голыми руками брать.
А про ширину растопырок - разве я вышел на форум с проблемой и доказываю что косяк где угодно, только не у меня ?
Нет, уважаемый, для Юрия - в личку. На форуме - для всех.
Пиписькой у школы помашите и доказывайте после что это для жены, это личное ...
Про то что не можешь заранее определить размер ответа ?
Или про никчемную картинку ?
Наверно глупые. Каюсь
Но после поста #2 умные вопросы - только про детали и техническое исполнение. А все остальные и есть глупость. Но что-то исходят они как бы и не от меня.
Я с Вас хохочу и хохоту моему нет тормозов. Остановите пожалуйста меня ,Валенок,пожалуйста,а то я умру от Ваших аргументов,которые меня невыносимо щекочут. Особенно в неудержимое хохотание ввело меня Ваше последнее предложение
в посте. Вы хотя бы поняли чего Вы написали? Так ото проанализируйте свое последнее высказывание и присоединяйтесь ко мне
Похохочем вместе. Не, еслиб не прочитал не поверил бы ,что уважаемые программисты так чудят
УВ. Валенок можно ли Вас прилампичить к своим друзьям на этом форуме ? У меня тут только
один друг- Ровки. Записал его в друзья за бредовые инженерные решения(например соединение
гавна мамонта с синхрофазотроном). Так ,как я есть большой ценитель юмора то и Ваши смешные высказывания в виде обоснованных аргументов записываю в коллекцию " МЫСЛИ
ПЬЯННЫХ ПРОГРАММИСТОВ"
ну и кто тут троль?
Упоминание слова мастер присутствует? Да есть описание работы ведущего и что.
Ситуация, когда в приемный буфер приходит последовательность запроса модбас но частично меняющая куски запроса (конец с началом), может существовать только когда этот буфер слейва и не корректная работа мастера, который не ждет ответов от слейвов, а каждый цикл шлет запросы
Так ведуший это разве не мастер ,а ведомый не слейв в модбасе RTU?
Я с Вас хохочу и хохоту моему нет тормозов.
И я ж тоже про Вас
... и вы ловите куски различных ответов в буфере... найдите причину почему
Пресс не отжал ?
Очень похоже что буфер неправильно инициализируется, и пришедший байт ложится в середину.
И тут ?
Но я надеялся на подсказку боллее изящного решения
Изящным решением оказалось предположение американца - "а данные-то до конца ждешь то ?" ))
"Не, еслиб не прочитал не поверил бы" (С) Одесса
Особенно в неудержимое хохотание ввело меня Ваше последнее предложение в посте.
Ну да. Разве не может вызвать хохот предположение что Одесса'е нужно снизойти до :
"..после поста #2 ... только про детали и техническое исполнение"
т.е. детализации процесса определения окончания пакета.
Да все понятно )) Отдали всю работу нижнему уровню. При наличии потоков - это вполне норм.
Или потоков, или прерываний. Смотря для какого железа пишешь
И я ж тоже про Вас
Пресс не отжал ?
И тут ?
Изящным решением оказалось предположение американца - "а данные-то до конца ждешь то ?" ))
"Не, еслиб не прочитал не поверил бы" (С) Одесса
Ну да. Разве не может вызвать хохот предположение что Одесса'е нужно снизойти до :
"..после поста #2 ... только про детали и техническое исполнение"
т.е. детализации процесса определения окончания пакета.
А чем Вам не нравится решение америкоса?
Или потоков, или прерываний. Смотря для какого железа пишешь
Я видимо отстал - какая-то именно железка заточена на прерывание по RTU-таймингу ?
Слово "событие" - не произносить)))
А чем Вам не нравится решение америкоса?
О-о-о. Прочитав некоторые Ваши посты в других темах даже предположить такой глупости от Вас не мог. А Ris без комплексов - предположил. Ему респект.
Себя цитировать - дурной тон. Но так как указывать про что-то написанное выше это только Ваше неотъемлемое право - позволил себе это.
Я видимо отстал - какая-то именно железка заточена на прерывание по RTU-таймингу ?
Слово событие - не произносить)))
Так отож. Отстали и сильно. Поясняю почему. Только событие может вызвать прерывание. А Вы ,как сильно отставший этого
не понимаете. А слова событие и прерывание есть терминами ваимно связанными. А вы,не понимая этого советуете не употреблять слово событие.
Себя цитировать - дурной тон. Но так как указывать про что-то написанное выше это только Ваше неотъемлемое право - позволил себе это.
Конечно респект. Указал точный путь решения проблемы. Последовал его рекомендациям решил вопрос. Вы же залетев на ветку
пукнули помахав крыльями и улетели. И ваш пук я ни как не мог использовать для решения проблемы,поэтому Вам не респект.
Так отож. Отстали и сильно. Поясняю почему. Только событие может вызвать прерывание. А Вы ,как сильно отставший этого
не понимаете. А слова событие и прерывание есть терминами ваимно связанными. А вы,не понимая этого советуете не употреблять слово событие.
А я ж не к Вам обращался. А ну да, это только Вы имеете право адресовать свое "посекретувсемусвету".
Про слово "событие" конкретизирую (действительно есть неопределенность. Особенно для филителистов) - не физическое событие, а программный калбек называемый в некоторых ЯВУ термином "событие". Если для Вас это одно и тоже - вы не отстали. Нет канешно. Вы просто до этого не дошли.
А для rwg просил не употреблять это слова в контексте его ответа с терминами "прерывание/потоки" (развивать тему ?)
А так как вы судя по всему "неотстали", может посоветуете именно железку c прерыванием по RTU-таймингу.
И если Вас не затруднит (второй раз, заметьте спрашиваю), не могли бы все-таки уточнить у RIS'а он таки советует проверять только тайминга и всё ?
У меня рога от "ты" выросли ? Можете даже называть меня грязным подонком купить пару валенков и тыкать в них иголки ))
О-о-о. Прочитав некоторые Ваши посты в других темах даже предположить такой глупости от Вас не мог. А Ris без комплексов - предположил. Ему респект.
Хотя если б ранее сказали что навел на ответ именно rwg - возможно и дошло б. Потому что именно его (rwg) ход мыслей ясен после п#45. Вышел-зашел, а прошло мсек 10-30. Поэтому и ответик мог образоватся. А то что не дождавшись полного ответа генерите запрос .... многих повеселили думаю.
http://www.owen.ru/forum/showthread.php?t=29367
Про тоже практически и там п#2. ТС там не Вы, но Вы ж и там отметились.
На надцатом посту это стало откровением ? )))))
PS
))
А Ris не советовал помимо таймера еще и общую текущую длину данных в буфере на предмет превышения максимально возможного размера в RTU и самого буфера проверять ?
Если нет - то и он в глазах упадет.
На надцатом посту это не стало откровением. По тому как после надцотогго поста поста,после многочисленных дебатов,которые
вы ,с высоты своего полета приняли за онанизмом Рис предложил решение. И только после этого я его озвучил.И не мог его озву
чить раннее.
. Вы же залетев на ветку пукнули помахав крыльями и улетели. И ваш пук я ни как не мог использовать для решения проблемы.
Это - да. Когда при 5-летней племяше произнес слова "3 и 6 равно 2" она тоже сказала что я пукаю. Доставило. Я ей купил мороженое.
Вы ж
.....Элементарную (для программиста) задачу решить не можете.
поэтому Вам не респект
Йо. У меня день не задался.
..вы ,с высоты своего полета приняли за онанизмом.
Дык оно им и оказалось. Костыли те - помните ?
Рис предложил решение. Рис - умница. Начал с самого простого - "дело не в бобине". Он прав.
А я ж предположил - чел глупости не напишет, вона какую чоткую и однозначную картинку привел, это все железо виновато. Глупый я. Все проще. И побоялся пост#2 развить. Думал - обидится оппонент.
..И не мог его озвучить раннее.
Просто мучаюсь - а што так ?
может посоветуете именно железку c прерыванием по RTU-таймингу.
Не знаю, что вы называете RTU-тайминг но в качестве железки, на которой работает любой тайминг, мне хватает Atmel AVR
А я ж не к Вам обращался. А ну да, это только Вы имеете право адресовать свое "посекретувсемусвету".
Про слово "событие" конкретизирую (действительно есть неопределенность. Особенно для филителистов) - не физическое событие, а программный калбек называемый в некоторых ЯВУ термином "событие". Если для Вас это одно и тоже - вы не отстали. Нет канешно. Вы просто до этого не дошли.
А для rwg просил не употреблять это слова в контексте его ответа с терминами "прерывание/потоки" (развивать тему ?)
А так как вы судя по всему "неотстали", может посоветуете именно железку c прерыванием по RTU-таймингу.
И если Вас не затруднит (второй раз, заметьте спрашиваю), не могли бы все-таки уточнить у RIS'а он таки советует проверять только тайминга и всё ?
Вы чего,вообще ненормальный,объясняя мне ,что событие я толкую на физическом уровне? Объясняю Вам,что событие на
физическом уровне это есть понятие,что Вы обосрались на этой ветке. А программное событие (объясняю,как филитилист,три оши
бки в одном слове,правильно пишется филателист. Я украинец по русски пишу грамотнее Вас) это совсем другое. И прежде чем
называть меня филитилистом поймите ,что прерывание -это прерывание. А келбек к прерыванию никакого отношения не имеет,
так,как келбек это совсем другое. Келбек это есть вызов обратной функции. Ровки мне Вас рекомендовал,как программиста с боль
шой буквы. Но он в очередной раз ошибся. Ему простительно-он старый.Но если для Вас келбек -это прерывание, то я немедленно
прекращаю с Вами диалог,ввиду Вашей невежественность,как программиста. И пусть любой участник форума плюнет мне в рожу
если я не прав,в том что я программиста ,не понимающего разницы в прерывании и келбек обозвал ненормальным.
Не знаю, что вы называете RTU-тайминг но в качестве железки, на которой работает любой тайминг, мне хватает Atmel AVR
Мастер Ваш (именно Ваш, у Одессы даже спрашивать бесполезно) когда решает или кто его вызывает когда тайминг отбит и пора разбирать ?
Валенок. Позавчера был день программиста. Так я Вас с этим днём не поздравляю
Потому,что программиста ,который путает келбек с прерыванием таким словом
назвать нельзя.И пусть Ровки меня простит,по мнению ,которого это есть програм
мист с большой буквы,но по моему мнению Валенок,как программист вряд ли и ма
ленькой буквы заслуживает.
Рассмешила его реплика о " ЯВУ ТЕРМИНАХ". Точно преподаватель информатики
для 5 классов с незаконченным среднем образованием
Мастер Ваш (именно Ваш, у Одессы даже спрашивать бесполезно) когда решает или кто его вызывает когда тайминг отбит и пора разбирать ?
Пора разбирать или когда пауза в приёме затянулась, или когда СRC совпала, смотря по результатам приёма байтов. Решают обработчики прерываний.
поймите ,что прерывание -это прерывание..
"А я дерусь, ..... потому что дерусь"
..Ровки мне Вас рекомендовал...
От Ровки эта услуга - явно медвежья ))) Прям отпустило.
Я украинец по русски пишу грамотнее Вас..Вы даже не представляете - это как раз и вселяет надежды.
Но с чтением какие-то проблемы. Ваш мозг сам себе внушил что где-то я сказал
Но если для Вас келбек -это прерывание...
я немедленно
прекращаю с Вами диалог,ввиду Вашей невежественность..Хорошее решение. Поздно уже. Да и обосратся на уровне элементарного приема данных и после этого пальцевать поэтому поводу - удел великих. Куда нам-то
Пора разбирать или когда пауза в приёме затянулась, или когда СRC совпала, смотря по результатам приёма байтов. Решают обработчики прерываний.
Он не знает такого термина,как обработчик прерывания. Спорим ,что не знает? Руб за сто даю - не знает.
"А я дерусь, ..... потому что дерусь"
От Ровки эта услуга - явно медвежья ))) Прям отпустило.
Вы даже не представляете - это как раз и вселяет надежды.
Но с чтением какие-то проблемы. Ваш мозг сам себе внушил что где-то я сказал
Хорошее решение. Поздно уже. Да и обосратся на уровне элементарного приема данных и после этого пальцевать поэтому поводу - удел великих. Куда нам-то
А чего от Ровки медвежья услуга? Аж интересно
Александр_Гранд
16.09.2018, 00:11
А у Вас тут до сих пор в почёте повтирать в мозг оппонента, что он не на что не годен? Айда к нам! В секту доброжелателей )
Он не знает такого термина,как обработчик прерывания. Спорим ,что не знает? Руб за сто даю - не знает.
"Обработчик прерываний — специальная процедура, вызываемая по прерыванию для выполнения его обработки" - неправильно?
Валенок. Позавчера был день программиста. Так я Вас с этим днём не поздравляю
А я плакаю, но Вас поздравляю - у Вас впереди много непознаного
Потому,что программиста ,который путает келбек с прерыванием..
Сами себе внушили - сами с собой спорите. Любопытный Вы экзепляр для наблюдения.
И пусть Ровки меня простит..
Ровки !! Прости его !! Я - подонок и чмо ! Ровки ! Не дай бог .. Ровки !!
Расмешила реплика о "реплике о " ЯВУ ТЕРМИНАХ"". Типа не уборщик, а клининг-инженер - и это все радикально меняет.
..с незаконченным среднем образованием
Угадал же. Незаконченное среднее. Ушел в училище.
"Обработчик прерываний — специальная процедура, вызываемая по прерыванию для выполнения его обработки" - неправильно?
Очень даже правильно. А вот Ваш оппонент не знает этого. С келбеком путает. А келбек это вызов обратной функции,а это вообще
из другой оперы. Вот такой он программист с большой буквы,как сказал Ровки.
А чего от Ровки медвежья услуга? Аж интересно
Ну так я вляпался бы в общение с Вами...
Он не знает такого термина,как обработчик прерывания. Спорим ,что не знает? Руб за сто даю - не знает.
Конечно не знаю. За их отсутствием здесь.
С келбеком путает. А келбек это вызов обратной функции..
Какая бурная фантазия ))
Очень даже правильно. А вот Ваш оппонент не знает этого. С келбеком путает. А келбек это вызов обратной функции,а это вообще
из другой оперы. Вот такой он программист с большой буквы,как сказал Ровки.
В качестве обработчиков прерываний часто используется келбек, это как удобнее программисту. Даже в нашем случае Modbus с их помощью удобно переключаться с RTU на ASCII. Про 100 рублей не забывайте.
А у Вас тут до сих пор в почёте повтирать в мозг оппонента, что он не на что не годен? Айда к нам! В секту доброжелателей )
Тута в почете обкакаться на уровне арихметики, прийти к людям которым даже как-то неудобно даже предполагать такой обкак, просить помощи и качать права. После этого обратится к американам, которые начинают объяснения с курса подтирания и гордится что это сказали сами американы.
Пора разбирать или когда пауза в приёме затянулась, или когда СRC совпала, смотря по результатам приёма байтов. Решают обработчики прерываний.
Ну ж. В прерывании же не сидите пока не случится нужное физическое Событие (с большой буквы для филитилистов, для выделения отличия от калбека-события). И, надеюсь, когда случается нужное Событие, калбек-событие (для вызова мастера) происходит не из прерывания ?
Валенок давай дружить . Почитав твои опусы ты стал мне симпатичен. Ты так звездишь красиво, шо я аж радоваться за тебя
начинаю. В 63 посте говорил,что колбек и прерывание одно и тоже. Через 5 постов-говоришь ,что это я придумал. Когда ты ото
вчера сюда залетел, то я подумал шо гопник какой то. Та Ровки мене объяснил ,шо ты уважаемый программист. Мне после его
слов аж некрасиво стало. По манере твоего ухода от прямого прижатия ты красиво уходишь взад.Душой чувствую,шо ты наш
Одесский,тока в России где то хоронитшся. Видать нашкодничал где то и программистом Российским притворился. Так ото
сиди тихо в схроне и на форумах не привередничай,а то загребут. Тока одно не понятно Ровка с
тобой бандитствует или сам посебе. Судя по вчера он за тебя круто мазу держит. Я когда тебя
вчера на Вы не назвал ,то он такое устроил-ховайся.
63 посте говорил,что келбек и прерывание одно и тоже
Мою цитату - на базу.
Или у Вас принято теперь желаемое за действительное ?
ты стал мне симпатичен.
И если что - я гомофоб и ксенофоб.
Мою цитату - на базу.
Или у Вас принято теперь желаемое за действительное ?
И если что - я гомофоб и ксенофоб.
Щас стану на лыжи и цытату привезу. Сам ныряй в свой пост 63 и читай его вдумчиво.
А за ксенофоба и как там его ,второе ото модератору пожалуйста,шо ты на форуме матюкался
Щас стану на лыжи и цытату привезу. Сам ныряй в свой пост 63 и читай его вдумчиво.
А за ксенофоба и как там его ,второе ото модератору пожалуйста,шо ты на форуме матюкался
Все таки теперь у Вас принято выдавать желаемое за действительное.
+ "манере твоего ухода от прямого прижатия ты красиво уходишь взад". На лыжах
Какая бурная фантазия ))
Так это я нафантазировал? Ты чего? Точно бандит, притворившись программистом.
Ну ж. В прерывании же не сидите пока не случится нужное физическое Событие (с большой буквы для филитилистов, для выделения отличия от калбека-события). И, надеюсь, когда случается нужное Событие, калбек-событие (для вызова мастера) происходит не из прерывания ?
О каком колбек событии вы говорите. Есть событие, а есть коолбек. По отдельности они живут. И через чёрточку не пишутся.
Произошло событие. По этому событию произошло прерывание. В подпрограмме прерывания сидит колбек ,который вызывает
функцию из функции ( это называется вызов обратной функции,колбеком называется) Это я Вам ,как программиста с большой
буквы объясняю. Мало того я очень редко видит,чтобы в обработчике прерывания колбек сидел. Привожу пример конкретный.
К данному случаю . Приходят из вне входные данные. Вопрос-как их принять и обработать? Ответ - есть два варианта. 1. Сидеть
и ждать пока они пройдут,а программа основная пусть ждёт,пока я приму данные и обработаю. Но так никто не делает. Для этого
предусмотрен механизм прерывания. Основная программа крутится и делает свое дело. Наступает событие - пришел первый байт
в буфер. По этому событию основная программа приостанавливается-это называется прерыванием. Вступает в работу подпрограмм
а, которая принимает и обрабатывает входные данные. И приняв их передает управление основной программе. При чем здесь кол
Бек о котором говорит Валенок я не понимаю. Ну может этот коллбек сидеть в подпрограмме обработки прерывания,но это не обязательно.
Тута в почете обкакаться на уровне арихметики, прийти к людям которым даже как-то неудобно даже предполагать такой обкак, просить помощи и качать права. После этого обратится к американам, которые начинают объяснения с курса подтирания и гордится что это сказали сами американы.
Ну ты действительно Валенок. Если я обкакался на уровне арифметики-прдположим,что так. Почему же ты гордый и всезнающий
орел залетел на ветку и со своими заоблачными знаниями не помог желторотому птенцу решить простую арифметическую задачку
Ты просто сказал,что свойственно орлам высокого полета, что тут птицам такого масштаба как ты делать нечего. Занимайтесь
мол тут ананизмом и дальше,а я полетел на Эверест отдыхать от дел трудных. Но тут появились менее породистые птицы,и посоветовали мне хотя бы в какую сторону рыть. Когда желторотый птенец эту задачу решил гордого орла задело за живое.
Он начал нервно кусать себе крылья. Кусал кусал и докусался до такой степени,что стал недопонимать что такое колбек и что такое
прерывание. Завтра на ветку обязательно прилетят гуси ближнего полета и увидят по рассуждениям орла,что это и не орел,а так
воробей общипанный.
А решение америкоса было одно из 3х. 1 готовое решение было найдено у ардуинщиков
австрийского. 2.У россиянина. для Расбери,на питоне писанное. И 3 американское. Причем, первые два готовые исходники,то америкос мне на пальцах объяснил и его решение показалось
мне боллее изящное. Самое интересное то что этот америкос не является профессиональным
программистом,а работает простым клерком,а программирование хоби. И второе,что было удиви
тельно вник в проблему моментально. И тут же предложил решение. Как же мне им не восторгать
мы? А кем тогда Валенком,который всех участников обсуждения онанистами обозвал? Та не изве
ните. Пусть им Ровка восторгается и фамилию с большой буквы пишет.
Обяснял,обяснял этому тугодуму Валенку . Нифига не доходит. Упёрся рогом в дерево и все. Говорит,что,еслиб америкос ещё и
объяснил ,где конец у буфера,то ему б цены не было. Именно это он и объяснил. И предложил метод который я не встречал ни
в одной реализации. И этот оригинальный метод сработал. Последний раз повторяю,а ты можешь и дальше стоять с воткнутым
рогом. Конец буфера там,где программный таймер сбросился.
В качестве обработчиков прерываний часто используется келбек, это как удобнее программисту. Даже в нашем случае Modbus с их помощью удобно переключаться с RTU на ASCII. Про 100 рублей не забывайте.
Не используется колбек в качестве обработчика прерывания. Валенок Вам врет,не слушайте этого программиста-гопника. Обработчик прерывания по калбеку получает функцию ,которую ему передает калбек. При этом программа обработчика прерывания приостанавливаетя и ждёт пока эта функция выполнится. По выполнению этой функции управление возвращается
Обработчику. И только после завершения обработки управление передается основной программе. Это я Вам описал механизм
Колбека. И пусть Валенок называет это бурной моей фантазией, но это лишь подтверждает ,что он является программистом-гопником.
Пост 81 по поводу бурной фантазии.
А я ж не к Вам обращался. А ну да, это только Вы имеете право адресовать свое "посекретувсемусвету".
Про слово "событие" конкретизирую (действительно есть неопределенность. Особенно для филителистов) - не физическое событие, а программный калбек называемый в некоторых ЯВУ термином "событие". Если для Вас это одно и тоже - вы не отстали. Нет канешно. Вы просто до этого не дошли.
А для rwg просил не употреблять это слова в контексте его ответа с терминами "прерывание/потоки" (развивать тему ?)
А так как вы судя по всему "неотстали", может посоветуете именно железку c прерыванием по RTU-таймингу.
И если Вас не затруднит (второй раз, заметьте спрашиваю), не могли бы все-таки уточнить у RIS'а он таки советует проверять только тайминга и всё ?
Причем здесь тайминги проверять. Просто я сейчас образно опишу, вы ,как я понял только образами мыслите. Соберите Ваше
нездоровое соображение в кулак сосредоточтесь и послушайте, не отвлекаясь на включенный телевизор и шелест жены на кухне.
Представьте себе элементарный ждущий мультивибратор с перезапуском по каждому входному входному байту. Так отот мультивибратор не сбросится до тех пор,пока идёт поток этих байтов. И только он сбросится,то это и есть сигнал мне ,что пакет
закончился . И я по этому сигналу могу читать буфер. И я его читаю правильно,без всяких проблем и сдвигов. Это равносильно. То
му,что по декону символ конца OD. Ну ,что дошло до Вас? Если нет - то это клиника,а я не доктор.
Не используется колбек в качестве обработчика прерывания. Валенок Вам врет,не слушайте этого программиста-гопника. Обработчик прерывания по калбеку получает функцию ,которую ему передает калбек. При этом программа обработчика прерывания приостанавливаетя и ждёт пока эта функция выполнится. По выполнению этой функции управление возвращается
Обработчику. И только после завершения обработки управление передается основной программе. Это я Вам описал механизм
Колбека.
Вы не находите, что утверждения о том, что колбек не используется в качестве обработчика прерывания и о том, что колбек выполняется в процессе работы обработчика прерываний несколько противоречат друг другу? Интересно, что вы возразите на утверждение, что колбек может быть частью обработчика прерываний? С учётом того, что никто не утверждал, что обработчик прерываний состоит из одного колбека?
alexx751
16.09.2018, 18:18
есть куча профильных сайтов по STM32, тот же easyelectronics.ru. Там полно примеров по modbus. Конец пакета в подавляющем большинстве
случаев определяется по прерыванию от аппаратного таймера (TIMx), т.е. паузе между пакетами.
Просто зачем было это все устраивать здесь - непонятно.
Одесса, вам американец предложил ещё один костыль. Запарился уже повторять, ведомое устройство на любом протоколе - овен, dcon, modbus, mbus и так далее, все и не перечисляет, отвечает на один запрос ОДИН раз и с 1-ого байта.
Если у вас в буфере такое смещение значит вы ловите конец одного ответа с началом следующего так как в программе у вас запросы идут в цикле
Возьмите например модуль аналогового ввода, который передает float и получите фигню в crc вашего склеенного ответа.
Ну и на счёт строк повеселили ...
Как будете искать начало если началом будет последовательность 10 03 и внутри ответа тоже встретится 10 03 в данных ?
..Как будете искать начало если началом будет последовательность 10 03 и внутри ответа тоже встретится 10 03 в данных ?
Дык он же уверен что
...Я програмно могу на лету поймать зараннее известный байт. Этим байтом является из пакета только адресный
Великий программист.
Причем здесь тайминги проверять,,.
Токует токует, даже вопроса - не слышит. Два раза заданного. Ведь
...Конец буфера там,где программный таймер сбросился.
Ну да, ну да ))))
.. С учётом того, что никто не утверждал..
Выдавать желаемое за действительное - это такой у него диагноз
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot