Перейти к содержанию
Поиск
    

razrab83

Участник
 Профиль  Обзор контента

  • Постов

    383

  • Зарегистрирован

  • Посещение

  • Победитель дней

    3

 Тип контента 

Сообщения, опубликованные razrab83

  1. Опубликовано · Пожаловаться

     

    2 минуты назад, Arlleex сказал:
    14 минут назад, quark сказал:

    У вас при приеме в ПК все паузы потеряются. Хуже того - могут появиться лишние. Там не годится этот метод.

    Так ведь и речь о том, что на ПК сделать честный RTU нельзя.

    ну наконец то... всё! Расходимся ;)

  2. Опубликовано · Пожаловаться

    2 минуты назад, tonyk_av сказал:

    Ничего подобного.

    Есть работающая сеть Модбас. Решил заказчик поставить мастера в своём дата-центре, а на объекте контроллер с радиомодемом. Как, с какими задержками проходит сигнал- ему было пофиг, а то что фрейм мог быть разбит на несколько частей, приходящими с интервалами в 15-20 минут, так то мелочи. Трафик стоит дорого, частота опроса низкая, поэтому терять фреймы нельзя. И таких объектов у него сотни, а нужно всё подключить к удалённому мониторингу. Вот и приходится драйверу собирать фрейм из кусочков, прежде чем послать в сеть или отдать мастеру в обработку.

    ну вы и описываете что-то доморощенное. 

     

    Это холивар двух подходов к модбас. Очень часто новички не анализируют паузы. кадру выделяют на "лету", т.е. сначало что-то там анализируют, потом сверяют CRC. Встречал даже так... Принял первый байт - это адрес. Адрес не мой - значит это не мне. Далее делает разбор пакета и даже не считает CRC. Зачем его считать, если пакет не мне? А то, что в адресе может быть ошибка и адрес нельзя анализировать до приема всего пакета и проверки CRC - об это не думают. 

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

    • Upvote 2

  3. Опубликовано · Пожаловаться

    1 час назад, tonyk_av сказал:

    Вот поэтому устройства со стандартными протоколами не требуют его описания. Достаточно в характеристиках указать поддерживаемый протокол(ы). И всё.

    вы не сможете указать в хар-ках девайса: поддерживается протокол Modbus. 

    Вы должны будете описать физику шины (RS232/485/ttl3.3), битрейт, старт/стоп. описать как менять битрейт, если есть ограничение на 19200 - то и их указать... а теперь самое вкусное))) - вы должны описать все регистры и поддерживаемые функции из протокола, а также если есть пользовательские функции (а модбас это допускает) - будьте любезны и их. 

     

    например у девайса состояние системы из 50 параметров. я в своем самописном протоколе опишу структуру и пакет с фиксированым заголовком в 3 байта и далее структура. 

    вы в готовом модбасе укажите, что использовать модбас, а потом всё состояние из 50 параметров раскидаете на регистры. надо передать флоат в 4-х байтах, у вас это будет два регистра, мл часть флоата в регистре 0х1000, старшая в 0х1001. и так про каждый параметр. 

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

     

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

  4. Опубликовано · Пожаловаться

    5 минут назад, quark сказал:

    Хорошо, уточню. Длина становится известна после приема первых байт пакета.

    ну анализировать первый попавшийся байт - это тоже не торт. приняли вы первый байт - тут должен быть адрес. Если пакет без ошибки - то это адрес. Приняли второй. Если пакет без ошибки - то это функция... но вот только есть там ошибка или нет, вы поймете только после расчета CRC (не берём во внимание паузы в 1.5). Как так? вы уже анализируете пакет не проверив его целостность. Вам отправили 200 байт одним пакетом. вы приняли второй байт с ошибкой и ошибочно определили длину пакета допустим в 7 байт. у вас crc не совпало. игнорим. приняли 8-ой и 9-ый байт - для вас это новый адрес и функция. Но это ещё первый пакет. вы запускате новый вычисление нового пакета - упс, там тоже crc не совпал. В счетчике пакетов девайс отметит "Получил 10 пакетов, из них 10 с ошибкой". А на самом деле был один пакет и он с ошибкой. как можно анализировать пакет, если ты не знаешь про его целостность?

    8 минут назад, jcxz сказал:

    Ошибаетесь.

    нет, не ошибаюсь. в даyном случае в тендере на оборудование не было ни каких требований к стандарту протокола. Да и этого протокола как такого не было... он родился спонтанно... просто решили сделать межплатный обмен на Modbus. Было требование, допустим, измерять влажность и включать насос. Было бы это один МК или Два... шкаф или ящик... внутри CAN или RS485. сколько плат и как они сопрягаются - вообще таких требований не стояло. Делай хоть на ПЛИС, хоть на МК, хоть на MOXA, хоть на паровом двигателе... Главное чтобы обеспечить внешние измерения, внешние воздействие и индикацию. А как ты там обеспечил межплатный обмен - это ни кого не интересует. 

    • Upvote 1

  5. Опубликовано · Пожаловаться

    5 минут назад, jcxz сказал:

    Дружелюбные соседи, "пошедшие друг другу навстречу", оказываются без зарплаты.

    .... делали систему... одной комнадой... сосед по парте пошел на встречу... т.е. внутри команды договорились убрать 1.5. Вышли на рынок с этим устройством. В мануале "Провод А подключить в проводу В" внутри шкафа. Ни каких modbus, ни каких rs485, ни каких сторонних девайсов и боже упаси ни каких ОРС в помине нет (даже на горизонте). Юзеру не нужно и он не должен знать, какой внутри протокол. Конкурент пусть хоть затестирует наш протокол. Замкнутрая система - работает, заявленые требования выполняет. А что там в кишках - ни кого не волнует. Но вот если внутри системы воткнуть санкционку устройство, которое разработала не наша кантора, и даже не в рф, а в германии/сша... и там честный модбас... и его воткнуть внутри в наш шкаф (на этапе разработки системы) - то работать система не будет. Наша система продавалась на рынке как единое целое. не допускает подклчения внешних девайсов. Естественно, если выпускать систему с расчетом расширения внешними чужими девайсами, то о ни каких договорах с колегой речи быть не может, должен быть честный модбас.

  6. Опубликовано · Пожаловаться

    26 минут назад, tonyk_av сказал:

    Никогда не понимал, зачем повторять то, что уже сделано? Тратить на это время? Мне своей жизни на такую фигню жалко.

    ни когда не понимал, зачем писать MS Word, когда есть OpenOffice? Зачем писать дельта-дизайн, когда есть альтиум и eagle? Зачем писать ВК, когда есть фэйсбук? Зачем писать воцап, когда есть вайбер? На такую фигню жизни жалко. ))

    Делали своё железо, по него делали свою скаду, со своим блекджетом и девушками. Продовалось и железо и скада. Что в этом плохово?

  7. Опубликовано · Изменено пользователем razrab83 · Пожаловаться

    12 минут назад, tonyk_av сказал:

    А при том, что раз делается устройство используемое в какой-то системе управления и/или мониторинга, то вопрос интеграции этого девайса с другими стоит не на последнем месте.

    оно не то что стоит на последнем месте, оно не стоит не на каком месте, от слова совсем. Сколько за карьеру было сделано мной систем... в скольких учавствовал... и скаду свою писали, и кучу АСКУЭ всяких делали... свои эл.счетчики, водосчетчики... И Modbus был, и МЭК-104, и куча Проприетарных протоколов. И даже был сторонний датчик ветра, на который не было описание протокола - сами его реинженерили. Сколько автоматики для себя наделал.... ОРС даже на горизонте не было. 

    12 минут назад, tonyk_av сказал:

    документации внятной нет

    на мои протоколы документация более внятная, чем на Modbus. Протокол пишется с описания. Через 1-2 мес я уже сам его забуду. Даже так - вышел из офиса и забыл свой же протокол. Зачем помнить константы. Единственное что помню - описание лежит там и называется так. После хорошего описания и сам ошибок не наделаешь и тот, кто будет сопрягаться мне ни одного вопроса не задаст, не будет отвлекать. 

     

    ps был случай.... купили датчик ветра. по RS232 его можно читать. Описания протокола нет. Звоним на завод изготовитель:

    -А можно описание протокола?

    -А его нет.

    -А как ваша программа на ПК с ним работает?

    -А её написал один инженер и уволился. исходников нет. описания протокола нет.

  8. Опубликовано · Пожаловаться

    5 минут назад, quark сказал:

    Реал-тайм бывает разный. Задайте требование "не более 10 сек", тогда и винду можно рассматривать как реал-тайм систему. )))

    не бывает разного реалтайма. 3.5 и 1.5 символов определены в стандарте. их надо выдержать. чтоб их выдеражать, нужно точно знать сколько времени у вас буде реакция на воздействие. мк может обеспечить точное поведение, т.к. обеспечить реалтайм. МК может обеспечить 3,5 и 1,5. ОС, допустим винда не может. 

     

    что касается ожидание ответа, то модбас его не рагламентирует. При создании системы пишутся требования: "битрейт 115200, старт, 8бит, ДВА стопа. адреса то такие. Ожидание ответа не более 1000 мс.". Винда должна обеспечить выдачу пакета без пауз, а ожидать ответ будет 1 сек. ожидать она 1 сек сможет, а выдать команды без пауз не всегда.

     

    Опять же.... я же писал....

    30 минут назад, razrab83 сказал:

    "ПК+железо" есть не раелтайм

    т.е. пусть это будет поливалка теплицы. Винда отпрашивает датчик влажности грунта. Винда сама опрашивает по модбас через usb/rs485. Отправила запрос... ушел запрос с дыркой в 4 байта. Датчик грунта не ответил. Система нереалтаймовая не работает. а теперь, в этой нереалтаймовой системе выносим преобразование usb в rs-485 во внешний преобразователь на контроллере stm32. 

    Нереалтаймовая Винда по usb отправила булк, МК принял. Мк формирует запрос датчику. Нереалтаймовая винда ждет ответа. Мк выдает через DMA в rs запрос. байты идут строго друг за другом. без пауз. Датчик грунта принял пакет и запустил измерение. Там сложный датчик, состоящий из кучи устройств и медленный.... в течении 800 мс делается изсерение и отправляется ответ. Ответ без пауз. Преобразователь на МК получает ответ, при этом контролируя 1.5 и 3.5. Получив пересылает его по USB в ПК. Через 805 мс после запроса ПК получил ответ. В зависимости от состояния грунта измерение проводиться от 500 до 900 мс. Поэтому требование в 1000 мс - обоснованное. 

    Далее... надо включить полив.... всё тоже самое... нереалтаймовый ПК передает в преобразователь команду на включение поливалки. и преобразователь в модбус команду на насос - пошел полив. 

    Допустим, нереалтаймовый ПК дал команду в USB на полив, и ушел на свопинг.... или на индексацию FS. Команда застряла на 1-2 с недрах ОС и в конце концов попала в преобразователь. И что? Вся система рухнет? Помидоры завянут? Нет! Преобразователь с задержкой в 1-2 сек получит команду на полив, выдаст "правильно" эту команду в модбас и насос начнет полив. 

    Но если в вашей нереалтаймовой системе преобразователь модбас не реалтайм, и ваш usb свисток не сможет обеспечить выдачу непрерывно без пауз пакета, то насос получит команду с паузой и не выполнит её. Помидоры завянут. 

     

  9. Опубликовано · Пожаловаться

    2 минуты назад, quark сказал:

    Одного честного реал-тайм контроллера недостаточно. Нужна еще честная реал-тайм операционная система на ПК.

    не нужна. если у вас вся система "ПК+железо" есть не раелтайм, но есть модбас - то ОС с реалтаймом не нужен. 

     

    Допустим вы сделаете свой преобразователь rs485/usb. или rs485/tcp на stm32f107. с одной стороны 485/modbus. мк обеспечивает 3.5 и 1.5 паузы. получил 20 байт - пауза в 3.5 - отправил по тср в ПК пакет добавив 6 байт заголовка. хоть на ОРС отправляй. Нужно ПК дать запрос - отправил по ТСП/USB в преобразователь запрос, МК сам его выдаст в rs485 со всеми тайменгами. Задаем требование системы "Ответ от слейва не более 1 сек". На любом битрейте ваш преобразователь будет работать, вне зависимости от ОС и реалтайма на ОС.

  10. Опубликовано · Пожаловаться

    21 минуту назад, quark сказал:

    известна заранее

    "известна заранее" != "есть длинна пакета". Вопрос не в том, как определить длинну пакета, вопрос в том, что в модбас нет длинны пакета. Длинну пакета конечно же определить можно. Она в каждом пакете своя и нужно уже на уровне парсинга данных вычислять данных. С длинной гораздо проще парсить. Длинна пакета известна до парсингаданных.  получил пакет взял первые 3 байта из потока/массива - сразу понятна длинна пакета. ещё не заглядывая в данные - уже понимаешь сколько байт данных. из этих заголовок + данные можно сразу сделать класс/структуру и засунуть его в очередь, БД, мессадж, контейнр. Не разбирая и не сами данные уже можно разбить входной поток/массив на поток пакетов аля std::list<MyPack> list; А потом перебирай этот лист и обрабатывай каждый пакет. 

     

    ps посмотрите Modbus TCP - обязательный заголовок 6 байт в котором есть длинна пакета. Длинна каждого пакета, в том числе которые фиксированные и не меняются.  

     

    43 минуты назад, tonyk_av сказал:

    Модбас- это стандарт, хорошо документированный и поддержанный, нравится он кому-то или не нравится. "Железку" с ним несложно включить в любую систему мониторинга и управления без дополнительных затрат. Вот для вашего расчудесного протокола за подобные деньги можно будет купить ОРС-сервер, чтобы включить "железку" с этим протоколом в работающую систему?

    при чем здесь OPC? А ваш распрекрасный стандарт можно будет подключить к танку Армата? Можно будет купить готовый боинг, чтобы включить "железку" с этим протоколом с Modbus в работающую систему самолёт? Понимаете - нет задачи включиться в ОРС. Нет задачи, стыковаться с др системами, о чем ТС говорил. 

     

     

  11. Опубликовано · Изменено пользователем razrab83 · Пожаловаться

    20 минут назад, tonyk_av сказал:

    Куда оно делось?

     

    где оно в запросе? где оно в пакетах с кодом ошибок? то, что там длинна какая-то в частных пакетах внутри данных - это не длинна пакета. Эта ваша длинна - это данные. У вас когда уарт примет 100 пакетов. Потом парсер начнет распарсивать - парсер должен должен прежде всего выделить целый пакет абстрагируясь от данных, потом, в зависимости от функции передать данные в парсер конкретного пакета.

    Если я в свой протокол добавлю длину пакета (или пусть длину данных)  -  модбаса не получиться.

     

    запос: 

    04 - адреc МК (получателя)

    01 - адрес отправителя (ПК)

    03 - функция, чтение смещения

    0 - длина данных

    12 34 - CRC

     

    ответ

    01 - адрес ПК

    04 - адрес отправителя

    03 - функция, чтение смещения

    4 - длинна поля данных

    0x12345678 - тут в float смещение инструмента в метрах

    12 34 - crc

     

    если можно ещё и адрес отправителя, это если много девайсов, но и без него не хуже. Зелёным - обязательный заголовок пакета. из 3-х(4-х) байт. Далее... поле данных - не регистры, а данные. Нужно смещение - получи смещение. Надо температуру - получи температуру. Надо в одном пакете 50 данных в разных форматах (float/int/float/MyStruct) - упакуй и передай. Вплоть до того что можно запросить у слейва текст. в пакете вернёт массив char. Если есть потребность в пакетах больших 256 байт, поле длинны данных 2 байта - передавай одним пакетом до 65 кб.  

  14. Опубликовано · Изменено пользователем razrab83 · Пожаловаться

    19 часов назад, mantech сказал:

    Вот приведите пожалуйста пример - я сделал переходник усб-485, подключил к нему промышленное RTU устройство и оно, блин не работает!!!

    есть шкаф, в котором с десяток устройств объедены шиной RS-485. Для обмена используется протокол Modbus. Девайсы Промышленные девайсы в шкафу с "честным"  Modbus. Контролируется 3.5 и 1.5. Все девайсы - это слейвы. Подрубили промышленную ЭВМ к этой шине как мастера. битрейт 921600. по этой шине идет непрерывный контроль со стороны мастера. Пакеты не очень длинные, но и не короткие. Обмен непрерывный.

    Периодически  рвется связь. мастер теряет ответы от слейва и принимает решение, что слейв рипнулся и делает соответствующие действия. Если снизить битрейт до 9600 - то обмен стабильный, но время опроса всей системы сильно увеличивалось и не удовлетворяло требованиям. 

    Стали разбираться..... мастер при запросе, в пакете часто делал дырки более 1.5 символов. А иногда и более 3.5 символов. Прогеров мастера носом ткнули в осциллограммы шины  485. Прогеры стали кумекать.... на эвм был linux. они что то там намудрили... что-то в область realtime... стало лучше... дырок в 3.5 нет, а вот в 2 символа появлялись. редко, но появлялись. Долго они с этим боролись - и сдались. Нешмагла я, нешмагла. В итоге разрабов слейвов заставили убрать контроль 1.5. Перешли на нечестный Modbus.

     

    Далее.... пожелали написать анализатор/снифер. Подрубился ноутом через usb-rs485 к шине - и в окошках весь обмен... кто, кому, когда, какие данные шлёт и по возможности визуализировать данные. Т.е. ПК выступал как слейв, который просто подслушивает. Так вот ПК не смог разделить пакеты. Делалось это через VCP. На ПК прога спрашивает "есть в порту непрочитанные данные?", далее "прочитать все данные". Вычитывает много байт... допустим 1500. Что это? где там пакеты? как их поделить? В массиве байт искались пакеты программно. В лог падали пакеты... несколько штук подряд у которых время приема было одинакового, т.е. время вызова функции read();

    ps переходник usb-rs485 использовался MOXA, о котором недавно тут упоминали. 

    Я это всё к тому, что тащить Modbus в ПК - это геморрой. Если Modbus тащится для того, чтобы "быть как все", т.е. что-бы в будущем было сопряжение с другими, то нужно его делать честным. Если он не честный, то могут быть проблемы с сопряжение др. устройств. Если др. устройства разрабатывает сосед по офису, то он может "вам пойти на встречу". А если это какая нить санкционочка - то .....

    Modbus хорош для обмена между МК, но тащить его в ПК, даже в промышленный - это геммор. Даже на апаратном rs485 - это тоже гемор. 

    В 22.05.2023 в 15:30, tonyk_av сказал:

    Для наладки использовал MOXA-1150. На объектах платы от Advantech с аппаратным UART. Проблем с Модбас ни там, ни там не было.

    Вполне вероятно. С большей вероятностью для наладки все будет работать. с маленьким битрейтом ваш ПК отправит запрос - минуту 10 мс будет ждать ответ, а не дождется то повторит запрос. Даже если в запросе/ответе были дырки и слейв не ответил. Ваш пк раз 50 повторит запрос, пользователь даже не заметит, что там что-то пошло не так. Прочитать и записать несколько регистров - почему бы нет. 

     

    Я бы объединил две платы через UART. И объединил бы у uarta Rxd и TxD и соеденил бы одной линией (аля 1-Wire). Пк через USB. программный проброс команд с USB в 1-Wire. Протокол и на usb и на 1-Wire свой. 

    Даже если подключаться к ПК через uart, то тоже все 3 девайса соединить одной 1-Wire. Какие проблемы? Ни каких колец не нужно

    Если всё же RS, то ни как не 422, а 485. Чем плох 485? 

    Протокол - свой. Даже если за основу Modbus, то нечестный. Да и зачем вам модбас? Зачем вам какой-то готовый freeПротокол? Свой протокол пишется быстрее, чем я этот пост. 

    0-ой байт - адрес, 1-ый байт команда, 3....n байт данные, CRC, ВСЁ!!! Ну можно докинуть ещё один байт длинны. И чтоб было совсем приятно парсить массив с 10-ю пакетами, добавьте в начало пакета 2 байта синхрослова.  

  15. Опубликовано · Изменено пользователем razrab83 · Пожаловаться

    1 час назад, jcxz сказал:

    Но если у вас в каждом устройстве есть USB, то можно сделать на USB (без UART-ов): Мастер - USB-host, ведомые - USB-slave.

    ТС же пишет, что в eps32 нет usb, а есть USB Serial. Т.е. это урезанный usb, до usb-device cdc. ни каких хостов там нет. и писать там usb стек не придется. 

    Цитата

    USB Serial это устройство с фиксированной функцией, реализованной полностью аппаратно. Это значит, что USB Serial нельзя переконфигурировать на использование других функций, кроме как каналов обмена последовательными сообщениями (USB CDC) и отладки JTAG.

    да даже если взять стм32ф103 CPU - на котором есть "полноценный" usb. Как этим одним усб подключиться одновременно к пк и к другому cpu?

  16. Опубликовано · Пожаловаться

    10 минут назад, Cirnas сказал:

    Микроконтроллер = ESP32-C3FN4 или STM32F103C8T6 - оба умеют USB

    зрачком чиркнул даташит - Full-speed USB Serial/JTAG controller. везде USB/JTAG. Я правильно понимаю, что усб используется в eps как встроенный отладчик и ему не требуется внешних st-link/j-link/прочий-link отладчиков? Как он поддерживается в IAR-e? 

  17. Опубликовано · Пожаловаться

    3 минуты назад, Arlleex сказал:

    На честном RTU с 3.5-символьными интервалами это г*вно не работает

    На честном RTU с 3.5-символьными интервалами это г*вно любой USB/UART не работает, даже запаянный на плате. 

    37 минут назад, razrab83 сказал:

    Не понимаю, как это работает?  

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

  19. Опубликовано · Изменено пользователем razrab83 · Пожаловаться

    4 часа назад, jcxz сказал:

    Вот и большинство, лепящее modbus на USB-UART, также не включают голову. Ведь вроде как работает, но иногда почему-то глючит.

    более того.... большинство, лепящие modbus в ПК на COM (без усб) или /dev/tty - так же не включают голову. 1,5 и 3,5 символа между байтами не анализируют.

     

    вопрос филоссофический..... допустим cpu шлет в пк через усб свисток USB FS. скорость в modbus 9600. всего 5 байт. 

    байт-пауза в 0,5 байт - байт - пауза в 0,5 байт - байт - пауза в 0,5 байт - байт - пауза в 0,5 байт - байт - пауза в 3,5

    как UART/USB выдаст в ПК эти байты? Будет пять булков отправлено в ПК и приложение получит через VCP пять байт с паузой между ними 0,5±t? Или преобразователь эти байты оформит в один булк? 

    А если в modbus будет два пакета по 5 байт с паузой между ними в 4 символа. То в пк отправятся 10 булков по 1 байту? или UART/USB соберёт эти два пакета отправит один булк в 10 байт? Как ваше приложение на ПК в одном булке разделит на пакеты эти 10 байт? 

    В 20.05.2023 в 09:26, Cirnas сказал:

    Изначально я закладывал другой конфиг:

    ПК <-> USB/UART <-> CPU + CPU <-> UART/422 <-> 422/UART <-> CPU

    Таким образом один модуль должен был получать команды от ПК по USB и пересылать их по витой паре с 422 другому модулю.

    Меня стали убеждать что этот вариант плохой

    Это хороший вариант, лучше чем у вас на первой картинке. Если не 422, то тогда так 

    ПК <-> USB/UART <-> CPU1 + CPU1 <-> UART/485 <-> 485/UART <-> CPU2

    А вообще... вы пишете, что вам нужно ТРИ устройство посадить на шину? Зачем? Соедините два устройства любой самой дешевой/доступной шиной: CAN/UART/485/422/1-Wire/I2C/Ethernet.... и сделайте порт USB для подключения к ПК. Зачем ПК лезьть в шину между CPU? CPU может ретранслировать команды от пк другому CPU. 

     

    Ну хорошо.... ну всё таки вам нужен modbus (т.к. это стандарт, сторонние устройства, сторонние программы, бла бла бла.... ) выкиньте с платы всю ветку usb-uart-485, оставьте на плате только 485 и втыкайтесь в эту шину компьютером напрямую через всё тот же злощасный usb/uart, ой, т.е. через usb/rs485. Например через такой. Возможно они дороговаты... но алиэкспресс ещё не забанили. Там эти переходники 72р (по мойму на сегодня  меньше $1). 

     

     

  20. Опубликовано · Пожаловаться

    В 16.05.2023 в 22:37, Cirnas сказал:

    Микроконтроллер: ESP32
    Коммуникации: Подключение к шине RS422/485 с Modbus через USB и/или по витой паре

     

    В 17.05.2023 в 15:33, destroit сказал:

    Проц выбран правильный... и да, почему 485/422 ? ... езернет-то, где ?

    выбор 485 в отрыве от всего - наверно оправдан....   выбор ESP32.... наверно тоже оправдан.... но... если глянуть на всю систему... см 1-ую картинку

    USB <-> usb/uart <-> uart/485 <-> 485/uart <-> cpu ..... ??? можно ещё 10 штук 485/uart добавить ))... почему нельзя USB<->cpu ?

    аааа.... ну да, в eps нет usb. Но лучше может тогда USB <-> usb/uart <-> cpu и объединить внутри cpu два "485"?  Или может лучше взять stm32 с usb на борту? А ещё лучше в топку 485 и оставить esp, но соединить всё на ethernet? в esp eth на борту... более того у esp на борту wifi.  

  22. Опубликовано · Пожаловаться

    3 минуты назад, jcxz сказал:

    Во-вторых этот регистр не имеет никакого отношения к запросам прерываний. Он замораживает тактирование самого соответствующего периферийного блока на время останова CPU.

    и? это имеет прямое отношение к запросом на прерывания: стоит вачдог - нет запросов на прерывание. У ТС может именно по WD идет прерывание. 

    • Like 1

  23. Опубликовано · Пожаловаться

    6 минут назад, RusikOk сказал:

    в IAR такого точно нет

    в иаре точно такое есть. если в паузе сработает таймер или вачдог, то при шаге - велкомТуОбработчик. НО, если у вас STM32, то посмотрите регистр DBG. В нем можно отключить прерывания в "паузе". Например если выставить флаг DBG_WWDG_STOP, то Window Watchdog Stopped when Core is halted

    • Like 1

  24. Опубликовано · Пожаловаться

    я такого поведения не наблюдал.

     

    ps из сказанного вами я понимаю так:

    1) запускаем программу в отладке

    2) останавливаемся где-то в коде на брейке (программа находиться в паузе)

    3) смотрим код, пъем кофе, ни чего не нажимаем, программа продолжает пребывать в паузе....

    4)пока пили кофе, и вдруг налетел ветер  вас перекинуло в прерывание, т.е. IDE открыла файл с обработчиком прерывания и подсветило первую строку. файл, на котором был брейк и на котором стояли стал неактивным (или перекрылся обработчиком). вы ни чего не нажимали, ни чего не выполняли, находились в паузе - и вас перекинуло!?

    Вот именно такого поведения, о котором вы говорите,  я ни когда не наблюдал. 

     

    если же вас, находясь в паузе, ни куда не перекидывает, потом вы делаете шаг - и перекидывает в обработчик - так это не "перебрасывает в паузе", а "перебрасывает при пошаговой отладке". Это не пауза, а выполнение. Вы шагнули через функцию printf() без захода - там коду 100500 строк асма, конечно там может все что угодно случиться. Если в паузе у вас встал флаг прерывания, то после того, как допьете кофе и сделаете шаг (даже если шаг по asm("nop");) - вас перебросит. По мойму это нормальное поведение любой иде (в том числе и IAR). Чтоб этого не было, в паузе запретите прерывания (можно прямо в IDE руками нужный флаг снять, можно в коде до брейка запретить прерывания, после разрешить).

     

  25. Опубликовано · Пожаловаться

    В 02.12.2022 в 19:43, *SERG сказал:

    мьютексы, очереди и пр. объяснены на примере многоквартирного дома, закрытой двери, закрытой двери с замком

    да почти в любом описании основ ОС/РТОС где идет объяснение мьютексов - приводится аналогия с домом/закрытой дверью/ключами....

×
×
  • Создать...