razrab83

stvp https://disk.yandex.ru/d/pwdYRHejJ0GPtA ps дожили, на яндекс диск можно попасть только через vpn.

у меня так C:\soft\ST\STM32CubeIDE_1.8.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.0.400.202209281104\tools\bin\ST-LINK_gdbserver.exe -p 61234 -l 1 -d -s -cp C:\soft\ST\STM32CubeIDE_1.8.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.500.202209151145\tools\bin -m 0 -k Я хотел её сразу показать... но раз в STM32CubeProgrammer тоже проблема, то проблема не в ИдеКуб. А у вас есть не кубовские продукты? например IAR или stvp ST Visual Programmer, или st-utility, или кеил? С ними есть проблема? Попробуйте кеил. там вроде до 2 кб кода он бесплатен. временно поставьте и попробуйте холовордом достучаться до процессора.

ну я бы не назвал её "безплатной". Её стоимость заложена в чипах st. Покупаешь процессор Stm - вот тебе от st среда разработки. Точно также, как MPLAB шла к pic, CCS к продуктам TI, AVR Studio к продуктам Atmel, Arduino Ide к платам arduino. А вот CooCox, да даже тот же Eclipse+plug - вот это действительно "безплатные".

у меня STM32CubeProgrammer API v2.5.0, а STM32CubeIDE Version: 1.11.2 Build: 14494_20230119_0724 (UTC) Программер то должен работать.

у меня при работе кубИде запускаются процессы arm-none-eabi-gdb.exe и ST-LINK_gdbserver.exe. Может помочь перезагрузка ПК (и перезагрузка st-link). STM32CubeProgrammer должен соединяться без всяких шаредов.

у меня в STM32CubeProgrammer без shared есть соединение. Эта галочка, это про... Enabled shared mode allowing connection of two or more instance of Stm32CubeProgremmer or other debugger to the same st-link probe. Вангую, что у вас в процессах запущен процесс какойнить Gdb/St. Этот процесс отвалился от IDE. Убейте его принудительно.

у меня так проверьте соединение в STM32CubeProgrammer (а также в st-utility, stvp, ...). Если и там нет соединения, то проблема аппаратная вашего таргета.

вот строки Как обозначить через регулярку что это одно и тоже. Наличие/отсутствие пробела перед и за симоволом "=", а также использование TAB или несколько пробелов - это всё одно и тоже. "123" или "0x7b" - это тоже одно и тоже. Т.е. не то, что 123 == 0x7b, а то, что цифра может быть в dec или в hex.

https://vseinstrumenti.ru/category/rele-kontrolya-napryazheniya-168798/

может вы не так поняли? я не спрашивал "где найти преобразователи PCI-485". Вы читайте всё моё сообщение, с цитатой. - почему так много оборудования с Модбас, но почему я не знаю о полноценной поддержки этого стандарта на ПК? - если честно, не встречал на ПК, тем более виндовомПК мастера модбас. Я говорю, что я не встречал чтобы кто-то напрямую затаскивал рс485 в ПК и гонял там модбас. Т.е. есть объект, допустим жилой дом. в нем 100 квартир. у каждой есть эл. счетчик с модбас. Я не всречал, чтобы кто-то ставил ПК для опроса всех этих счетчиков напрямую. Ставят в доме УСД и оно опрашивает эти счетчики. Отправляет через Eth/4g/Lora в офисный ПК, ну или на удаленный сервер, арендованный в Нидерландах. Но чтобы прямо ПК напрмую по рс485 гоняло модбас - не встречал. Или есть трансформаторная подстанция. Куча оборудования... на столько много, что одной шины не хватает на всех... делают 2 или 3 шины, т.к. есть ограничения не макс. число слейвов. Ставят контроллер-мастер, как шлюз, который делает рутину на рс-ах, а в мир смотрит чистым tcp. Ни каких ПК (тем более бытовых) на трансформаторных подстанциях не встречал. пусть будет Рита. Звучит приятнее ))

если честно, не встречал на ПК, тем более виндовомПК мастера модбас. Очень много оборудования с модбас... все они подключаются как каким-то модемам, УСД, АСКУЭ, ПЛК и т.п. Но чтобы напрямую рс485 где-то затащили в пк... наверно есть такое. Затаскивали напрямую в пк модбас для конфигурирования/настройки, но не для "жизненой" системы.... ps Но периодически в голове витает мысль сделать свой не USB/RS485, а USB/Modbus. Чтоб с одной стороны usb со своими буклами со своим драйвером/протоколом, с другой полноценный модбас. Чтоб и мастер и слейв - не вопрос! Но я уже отошел от этой автоматики.... возможно когданить вернусь - сделаю. На алишке по 51 рублю продавать буду ))) Возможно уже такие есть.

да, если ответ был с паузой в 3 символа меж байтами? Модбас строго регламентирует, что если межбайтовый интервал >1.5, то это NOK. Эти ваши PCIe через API Win32 как сообщат на прикладной уровень, что пакет принят с пометкой NOK?

а если ответ был с дыркой?

так о чем спор? я так и сказал, ещё 100500 страниц назад - реализовать "честный" модбус на ПК - это гемморой. Хорошо... вот плата PCI-1602B-CE, $143. Два rs-485. Что будет в винде? Будет vcp-COM23. Как на апликэйшен уровне вы всё это реализуете? Через API Win32? Или через Qt? Вы по приему 1го байта испустите сигнал и перехватите слотом. В слоте запустите QTimer для отслеживании 1,5 символа? Так вы это себе представляете? Или же допустим, раз написано производителе "Для сетей Modbus" (это же не маркетинг, продавцы все честные для маркетинга никада ни напишут лошь). Т.е. производитель на этой плате в Зилинкс-е реализовал все эти 3,5 и 1,5. Прекрасно. Как это работает в винде? Вы подрубили на PCI-E плату. установили дрова. Заходите в "Диспетчер устройств" и в разделе COM порты нет ни каких дополнительных компортов. Зато появилось устройство ADVANTECH/Modbus0 и ADVANTECH/Modbus1. Вы в этой вашей О! Писи! OPC выбираете подключение через ADVANTECH/Modbus0. Т.е. программа, на Qt, создает ioDevice = QIODevice(QT::TYPE::PCI_E_MODBUS, "ADVANTECH/Modbus0"); И дальше всё согластно протоколу... программа шлет пакет в ioDevice.... ioDevice->send(adr, buffer, size); Ваша плата получает пакет и в плате плиска начинает выдавать целостный пакет, обрамляя его паузами. Если так - то да, всё будет работать. только какое-то API для винды нужно чтобы из прикладного уровня слать и получать пакеты. Какая-то сишная библа должна прилагаться. А если в винде появиться обычный COM порт... то это то, о чем я говорил - можно, но гемморойно.

Т.е. делаешь свой преобразователь из tcp/485. ставишь на него реалтайм МК. Получаешь от ПК по tcp допустим tcp-модбас, или мэк, или http и транслируешь в RS реалтаймовым МК модбас со всеми паузами. получаешь ответ в соответствии с протоколом, ретранслируешь его в ПК по tcp. Да, конечно, всё будет работать. Разработать свой модбас-преобразователь. Кто за это спорит. Все предложения были касательно - взять бытовой ПК с виндой + усбсвисток с алишки и всё сделать в соответствии со стандартом. Вот сомниния во втором варианте. спецы по кишкам USB, подскажите вот за что.... вот ПК... у него в процессоре встроенный USB. этот USB на материнской плате подключен к микросхеме-хабмост. одна дырка - usb device, 3 дырки - usb-host. два хоста от этого моста уходят на внутреннюю перефирию на материнке. один сомтрит разъемом наружу. к этому разъему подключили раширитель usb до 7 портов. и в этот расширитель ткнули принтер/ethernet/wifi/ ну и usb/rs485. Вот при такой герлянде usb/rs485 гарантировано выдаст 100-200 байт неразрывно?

а что ваша плата сделает? ну во первых - речь всё таки о бытовом ПК (да и ктому же с вашего ходу... "Товар не доступен к продаже"). во втоврых ПК+PCI-1602+Win - что получиться? Modbus строго по спецификации? выделение пакета по паузам с контролем 1.5? Что-то я очень сомневаюсь, что на винде на уровне апликэшэн это получиться. А если делать модбас раком-боком с костылями, методами "ну вроде подключил и работает" с оговорками - конечно получиться.

Конечно, первая мысль была - сделать 10 повторов - отказ будет не раз в неделю, а раз в год. Но это тоже недопустимо. И их нельзя было больше трех. нужно было много девайсов опросить и много у них параметров вычитать. Почему 921600? (даже пришлось менять драйвер rs485, потому как не каждая микросхема может такой битрейт). Потому что нужно было быстро реагировать на изменение системы. когда опрос идет без сбоя, то запрос-ответ идет без задержек... около 4 символов между запросом и ответом. когда кто-то не ответил, мастер ждет ответ какое-то время, потом повтор... я не помню какой максимальное время давалось на ответ, но если кто-то затыкался, опрос всех увеличивался. это критично. Нельзя было увеличивать кол-во повторов.

кто так решил? В реальности, у нас, было так, что 100 пакетов идет не за сутки, а за несколько секунд 100 мс. Т.е. вероятность 1/100 - это 10 разрывов в секунду. что там с вашей минус 12 степенью?... Так вот в реалии, сначала потерю связи убрали повторами. Стали случаться выходы из строя, переход на резервный комплект по причине "устройство перестало отвечать". Пришлось убрать контроль 1.5 у слейвов, стало работать безотказно. Но это что касательно нашей разработки и реального случая из жизни. Конечно... если ТС сделает обмен раз в 1 сек на 9600 и не будет на мастере-ПК контролировать тайминги - да всё будет прекрасно работать. Кто спорит. Но о чем тут спор: вопрос - какой протокол? Ответ предложение - modbus. Кто-то на ПК с модбасом хаплул горя. Посторался на ПК сделать его как требует стандарт и замучался. Теперь делиться своим опытом. Но кто-то топит за модбас, он ему нравиться. Довод в пользу модбас - это стандарт, это ОРС, это можно расширять систему, это можно подключать сторонних слейвов. Так вот если расширяться чужаками, надо делать честный модбас, а это геморой. А если не расширяться чужаками - то и довод этот в топку... ps ах да.... совсем забыл... ещё случай из жизни... реальная разработка была... есть система: мастер - несколько слейвов. сделали 115200, старт, 8 бит, без чет, стоп. Модбас. свой мастер, часть слейвов свои, часть чужие. Решили расширить систему. купили "чужака" слейва. У него был модбас. легко интегрируется в нашу систему. достаем из коробки и .... у него только 9600 и 19200. да ещё и с четностью. Будет у вас 3-5 устройств с разными параметрами RS.... Будете мастера перенастраивать? или делать несколько шин 485? Так что довод "в будущем легко расширить" тоже в топку. модбас - со своими регистрами. да, на мелких МК удобно. всё таки некий стандарт. для разработчиков слейвов - модбас в первую очередь. со своим доморощенным говнопротоколом на рынок не выйдешь. Но если делаешь свою систему - н@х нужен этот ваш модбас. Сделал структуру struct State; заполнил поля, обрамил заголовком и CRC - выдал в IODevice. Получатель принял - проверил CRC (а если это USB/Eth, то и crc не нужен), инициализировал структуру - хочешь приведением типа, хочешь union-ом, хочешь с помощью memcpy - ВСЁ!!! Весь парсинг одной строчкой. И ты сразу получаешь всё состояние всего слейва одним пакетом. хоть 10 байт, хоть 100, хоть 500.

И? -6 степень..... что там выходит.... раз в год? или раз в 10 лет? у вас раз в 10 лет выйдет из под контроля ядерный реактор остановиться полив теплицы. что хорошего? И ещё, раз в 10 лет - это не значит что после ввода в эксплуатацию через 10 лет, это значит на интервале 10 лет случиться 1 раз. И этот раз может наступить на следующий день после ввода в эксплуатацию.

нет, не чувствую. я спросил "то какова вероятность что потеряем 3 пакета ПОДРЯД из 300?" Посчитали? Запомнили. Та вот "3 пакета подряд" это и есть "3 пакета друг за другом". "вероятность 3-х пакетов др. за др" не будет совершенно другой вероятностью, будет такая же, как "вероятность 3 пакета подряд", в силу того что наречие "подряд" и "др. за др." это одно и тоже.

МК это делает аппартно.

3 раза делался повтор. если 3 раза не ответил - переключались на резерв... ещё 3 раза - останавливали всю систему. На самом деле на длинных пакетах такое наблюдалось. сначало, когда увидели это на столе - сделали повторы. действительно - вдруг помеха (хотя линия короткая была, всё экранировано, даже в грозу помехе не откуда взяться). Но подстраховались повторами. Уже в работе, так бывало, что и 3 раза нет ответа. Мастер linux не гарантировал неразрывной передачи. это было редко, но было. и было от этого "не прияно". А теперь с ваших слов... 1 пакет из 100 теряем. Хорошо. кто силён в теории вероятности? если теряем 1 пакет из 100, то какова вероятность что потеряем 3 пакета подряд из 300? ps Когда строили АЭС в Чернобыле, то считалось что вероятность аварии очень мала. Авария на АЭС может произойти раз в 1 млн лет. Ученные не ошибались. Первый миллион прошел. pps причем граница между первым млн и вторым проходит где-то между 1986 и 2011 годами. фукусима - это уже из 2-го млн.

вот куча противоречий..... 1. вот у вас ПК есть мастер. Состряпали ПО на ПК.... винда... воткнули usb-485 свисток.... подождали минутку - увидели сообщение "Xi Me Chao готово к использованию как COM23". Что там про настройку буфера ввода/вывода? 2. "ограничением максимальной длины запроса в управляющей программе ведущего" - ухты!!! это как? пакет не более 10 байт? а это разве не Modbus с "оговоркой"? вы подключили стороннее устройство, а ему нужно 120 регистров обновить. вы их будете делить на пакеты по 10 байт и писать по 2-3 регистра? а это разве не Modbus с "оговоркой"? 3. "Гарантия в 100% не нужна." - не, ну если 100% гарантия не нужна, то расходимся. ну если вы хотите записать настроченный коэффициент слейву, при вводе системы в эксплуатацию - то конечно, мастер не получит ответа - повторит. в конце концов электрик жамкнет ещё раз кнопку "Отправить"... и ещё и ещё... в 5-го нажатия запишится. Но если вы ПК делает мастером в работающей системе - то тут слейв не ответил, мастер принял решение что слейт умер и вывел его из опроса.

modbus rtu отличный протокол. мне нравится. выделение пакетов по паузам на МК - как 2 пальца об асфальт. Но тут спор не за modbus rtu в контроллере, а modbus rtu в ПК. выделение пакетов на ПК по паузам - пока ни кто не смог. Даже quark , топит за модбас, и не замечает как Федьку по матери величает периодически сам себе противоречит. то он пишет Работает точно по стандарту без всяких оговорок. С любыми стандартными устройствами. то он пишет оговорки, типа то он пишет "Работает точно по стандарту" (т.е. по стандарту, значит выделение пакета по паузе), то он пишет "У вас при приеме в ПК все паузы потеряются." ни кто его не хоронит. Действительно, на МК его реализовать не сложно. Для очень мелких МК он самое то. эти всякие ваши стеки LwIP и т.п. просто не зайдут в 8 кб флеша (а то и меньше). очень часто используем modbus rtu. заходим на объект, там куча автоматики (всякие счетчики, регуляторы, реле, датчики....), почти у всех есть modbus rtu. ставим свой контроллер. по modbus rtu всех опрашиваем и контролируем работу объекта. диспетчеру/оператору по радиоканалу/tcp скидываем информацию о состоянии всего объекта. Но в радиоканале/tcp протокол уже другой. уже нет такого интенсивного обмена. Да даже если надо напрямую в этот ваш ОРС (госсспади, прости меня за это слово) прокинуть инфу... т.е. дать удаленному ПК ПРЯМОЙ доступ к конечному датчику и почитать регистры датчика - прокинем через tcp modbus. Но ни как не rtu. modbus rtu - это удел низкоуровневой автоматики, МК. Пихать его в ПК - это геморрой. Конечно, мы также приезжаем на объект, напрямую тычемся ноутом через китайский эфтидиайный usb-свисток в шину и прямо через modbus rtu что-то там налаживаем. Прочитать/записать регистр... или на столе, до монтажа, сконфигурировать электросчетчик, да ещё и штатной виндовой утилитой - почему бы нет. 9600 (или 115200) по дефорлту, черепаший темп... всё записалось. Но делать мастером ПК в работающей системе... modbus rtu не для этого предназначен.

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