но это совершенно пофиг

__T_NC_COMM_SETUP это же тип? Или это все таки переменная?

тип описывающий структуру

ок а как берется значения по указателю из типа структуры? И потом побитовое и с значением?

Я просто вижу если упростить typedef struct { } struct_t; int variable = 0; *(struct_t*) & variable = 1;

пойми сам принцип - дальше оптимизируй до посинения

вот да. Я не понимаю как вы из типа - берете значение по указателю.

*(__T_NC_COMM_SETUP*) вот сюда.

У вас может структура не через тайпдеф определена и это так работает? (я всю жизнь через тайпдефы делаю и никогда не интересовался как иначе).

то там же написано

Через тайпдеф. Мне такое компилятор зарубит. Т.к. __T_NC_COMM_SETUP это тип, а не экземпляр типа.

с какого перепугу?

это условность - ниначто не влияющая

Причем тут андерскоры и имя вообще =).

я не пойму в чем сложность?

Если я не не знаю чего-то невообразимо важного в С. То, если абстрагировать от частного случая, там написано: *(int*) & somevariable_1 = somevariable_2;

Я помощь зала запрашиваю, у меня стойкое ощущение, что я чего-то в лоб не вижу.

*(__T_NC_COMM_SETUP*)&RS_485_OUT_Buf[RS_485_OUT_Len] = NC_COMM_SETUP; // разжовываю &RS_485_OUT_Buf[RS_485_OUT_Len] - разадресация переменной, в часности буфера с указанным индексом *(__T_NC_COMM_SETUP*) - присвоение типа тому что разедресовали - типу структуры = NC_COMM_SETUP; - и ложим туда данные которые в NC_COMM_SETUP

т.е. в буфер положили данные структуры

Да я тупой =) Я смотрю и вижу побитовое И =)

да Си он такой

Не я обычно просто все в 5 строк делаю чем одну.

Не вижу смысла жать. Потом с чтением проблемы.

вообщем это можно и по одному байту переложить - но если компилятор умеет - то нафига мучаться

при приеме после проверки црц обратное действие и у тебя данные из пакета уже в втруктуре

Код.

Но это вкусовщина.

Но это вкусовщина.

одно действие пишется в строку, накой его еще раскладывать по строкам

и так кода тысящи строк

и я никого не призываю писать как я, мне так удобно я так пишу

и я никого не призываю писать как я, мне так удобно я так пишу

Я потому и сказал что вкусовщина.

Это вроде стандартная фигня.

Во всяком случае много где видал.

S32 не видел, U8 точно видел =)

Можно ещё void переименовать в VD, например

та можно что угодно - лишь бы удобно было ну и не переборщить ))

Та куда уж )

Можно ещё void переименовать в VD, например

Скобки в OB\CB и получить местный филиал брейнфака.

ну то ты понял принцип работы - или будем обсуждать скобки ?

ну то ты понял принцип работы - или будем обсуждать скобки ?

Прием скините?

то я же в самом начале скинул

Нет, парс приема на полезную нагрузку.

да собственно if (flag_ZAPROS == 1) // Флаг устройство получило запрос { if ((DALLAS_CRC8(RS_485_IN_Buf, posIn_RS_485_IN_Buf))==0) // CRC { и тут уже смотрим код команды и куда переложить пакет

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

ну добавьте в начале заголовок если нужно, у меня первый байт - код команды, второй адрес RS-485

Не, я к тому, что NC_COMM_SETUP уже содержит полезную нагрузку.

т.е. в буфер ложим RS_485_OUT_Buf[0] = kod_READ_PARAM; RS_485_OUT_Buf[1] = ADDRESS; // а дальше нагрузку полезную

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

т.е. в буфер ложим RS_485_OUT_Buf[0] = kod_READ_PARAM; RS_485_OUT_Buf[1] = ADDRESS; // а дальше нагрузку полезную

А ну значит все в NC_COMM_SETUP. У вас получается фиксированной длинны? Ну у меня сорт того же был, только я побайтно копировал в буфер =) Затайпдефить структуру и в указатель кидать целиком прикольный метод. Надо больше чужих исходников читать =\

"У вас получается фиксированной длинны? " для этой команды - такая длина, для другой может быть другая

не имеет значения

есть флаг когда пакет принят - от него и пляшем

ну и понятно что другой МК должен знать этот пакет

да и в принципе не важно - может и не знать, например - обновление прошивки через RS-485

Да, не понять мне С-пути видимо. Вроде смотришь - простейше, безотказно, но блин вморожено в текущую задачу с головой. Меня слишком промыли повторным использованием =)

используй хоть миллион раз - работает и работает

не бывает ничего универсального - все равно надо допиливать под задачу

Ну я развожу жаваскрипт на С =) С ООП, конфигурацией во время инициализации, что бы вообще к железу не было привязано. Сейчас вот посмотрел на ваши 20 строк и на свои 400. Думаю - может я все таки че-то упускаю =)

метод конечно для видео - обмена не катит, но для обмена данными по юарт/rs-485 - очень даже неплох

Ну я развожу жаваскрипт на С =) С ООП, конфигурацией во время инициализации, что бы вообще к железу не было привязано. Сейчас вот посмотрел на ваши 20 строк и на свои 400. Думаю - может я все таки че-то упускаю =)

ну как бы тут не сильно оно и привязо к железу это было на АВР, мигрировало на STM32 и NPX и там тоже работает

а на ESP32 не мигрировало ))))))))) уже пол года лежит - времени нет )) но куда он денется ))

У меня вчера - пожелание было, что бы на входе\выходе был поток байт.

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

добавляем очередь - и вуаля - "тепленькая пошла" - поток

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

нафига козе - баян?

задача связи двух МК(и даже более) - решается

Ну вот не подумал, что любой размер можно попросту выше уровнем собирать =)

угу

вот из старых проэктов на авр прием данных по юарт __interrupt void RX_char(void) { U8 c = UDR0; if (posIn_RS_485_IN_Buf<Size_RS_485_IN_Buf) RS_485_IN_Buf[posIn_RS_485_IN_Buf++] = c; timer_RX_485 = 2; // 3.5 символа тишины }

👍 вот это самое верное решение. Протокол RTU , пакеты разделены фиксированной паузой.

По началу. (Маркер начала) - (длинна) - (нагрузка) - (црц) Если приходит новый маркер - текущая сборка перезапускается. Вопрос кстати к чему? У меня ничего рабочего не получилось. Просто обточил что было до более универсального варианта.

Это нехорошее решение. Это режим ASC.

По началу. (Маркер начала) - (длинна) - (нагрузка) - (црц) Если приходит новый маркер - текущая сборка перезапускается. Вопрос кстати к чему? У меня ничего рабочего не получилось. Просто обточил что было до более универсального варианта.

Зачем с нуля писать. Возьмите "хорошую/рабочую" библиотеку Modbus RTU, под вашу среду. И допишите её под свои нужды.

https://summit.iridi.com/

Запись первого дня 19 октября https://youtu.be/vpS-czfa4nQ?list=PLfS9mpIz-NfYfXI0G4Jwx2y9eC425Sy0p

Оформляйте в моноспейс, читать удобней будет *(__T_NC_COMM_SETUP*)&RS_485_OUT_Buf[RS_485_OUT_Len] = NC_COMM_SETUP; // перекидываем данные RS_485_OUT_Len = RS_485_OUT_Len + sizeof(__T_NC_COMM_SETUP); // RS_485_OUT_Buf[RS_485_OUT_Len] = DALLAS_CRC8(RS_485_OUT_Buf, RS_485_OUT_Len); // CRC RS_485_OUT_Len++; // +1 байт CRC RS_485_TX_len(RS_485_OUT_Buf, RS_485_OUT_Len); //

Очень долгое видео, но интересно посмотреть куда идет направление. а толкают его на безпроводные технологии.

.........какое то перемешивание воды....... - у меня 6 МК связаны по RS-485 - работает все по принципу "код команды+тело команды+crc" пакеты организованы - структурами тайм ауты на ожидание ответа 100ms

Тут есть подводный камень: * Собрали пакет с crc, * Отправили * Приемник принял, проверил crc, все годно, подготовил ответ с crc, отправил ответ. (Начал обработку принятого пакета) * ответ пришёл с ошибкой, его выбрасываем? * Ждём таймаут 100мс. * Ответа нет. Повторно высылаем пакет. * Приемник получает дубль пакета. Два одинаковых пакета подряд вместо одного.

Для исходных файлов C++ IntelliSenseMode был изменен с "clang-x64" на "gcc-x64" на основе аргументов компилятора и compilerPath при каждом запуске VSCode откуда это вообще прилетело ? )

Для исходных файлов C++ IntelliSenseMode был изменен с "clang-x64" на "gcc-x64" на основе аргументов компилятора и compilerPath при каждом запуске VSCode откуда это вообще прилетело ? )

settings.json

ну как знаешь я предлагаю простой и надежный способ - который проверен в сотнях устройств

С мультимастером?

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