razrab83

Спасибо!

Подскажите... российскую микроэвм, (типа MOXA UC-8400) на российской комплектухе... (байкал, эльбрус...) Нужны порты rs-485, eth, gpio. Желательно в коробке Linux ОС + тулчейн.

это иар из коробки в идэ выдал. с++ тоже дает ворнинг на такой код gcc молча съел. но gcc с ключом -Wwrite-strings выдал ps да, си, в отличии от с++, может пропустить "asdf" (но не const char *str = "asdf"). Лишний раз задаюсь риторическим вопросом - зачем нужен си? С++ более строг. Если даже не любишь(не знаешь) ооп, не нужны классы, шаблоны, stl и прочие плюшки... пиши код аля си стайл с любимым goto, но собирай его сипипишным компилятором.

в чем прав и какой код? void func1(char *p){} //со слов Arlleex "достаточно часто функции требуют указатель (обычный)" const char *str = "asd"; func(str); //тут error. со слов Arlleex " а мы туда передаем, например, строку." вот об это я и говорю.

такого не бывает, либо это говнокод. Например функции (пусть будет некое API, реализация скрыта в библиотеках) void func1(int *value); void func2(const int *value); если я вызову func2 и передам туда (обычный или конст) указатель, я буду 100% уверен в том, что мои данные не изменяться. Такой аргумент "const int *value" с языка с/с++ можно перевести на русский как "уважаемый программист, при использовании этого метода, будьте уверены, что ваши данные останутся неизменными". В func1 данные могут быть модифицированы. Если вы пишете свою функцию и в аргументах передаете указатель или ссылку, и этот метод не должен менять данные по * или &, то всегда ставьте const. Это убережет от ошибок реализации метода, а также будет в дальнейшем будет легче пользоваться методом. если строка константная, ворнинга не будет, компилятор даст ошибку и не соберёт код. если строка не конст, то ни каких ворнингов не будет.

не я автор кода. я бы всё в ++ увел. тут пуре си. на си сделано что-то типа ооп. и сделано все чуть менее чем полностью на глобальных переменных (раньше так писали, это было нормально). я бы сам так делать не стал. а по поводу вашего примера SetArg(&a, 12);.... так тут почти так и есть... ошибку дает компилятор, поэтому автор делает так SetArg((int *)&a, 12); Т.е. объявляет константную структуру, а потом где-то пытается её модифицировать. Компилятор ругается. В этом месте стоит явное приведение к типу без конст. Я уже принял меры и выправил этот код. Просто перед правкой решил убедиться, что мои опасения не напрасны. Всем спасибо.

вот это меня и смущает. этот код компилится и работает. и кочует из проекта в проект. на этом камне с этим компилятором всё нормально. а в другом окружении "выстрел в ногу". Или я загоняюсь и при любом раскладе все будет работать?

сорри.... опечатался const int a = 10; void f() { int *y; y = (int*)&a; *y = 12; .... }

const int a = 10; void f() { int *y; y = (int*)&a; y = 12; .... } встретил такой код. работает. Тут все в порядке?

Конечно, вам слив засчитан, .... всё-таки трепло... вам что от меня нужно? вы мне что хотите доказать? The TCP specification does not include a keep-alive mechanism! Я с самого начала ровно сказал тоже самое - в TCP нет keep-alive. Или вы хотите доказать, что в TCP можно сделать keep-alive - так кто с этим спорит - делайте. это не конкретный совет. конкретный совет/ответ дал Сергей Борщ, gerber, mantech, Rst7. Вы не смогли указать, где в спецификации TCP есть keep-alive. То, что его можно дополнительно реализовать, я и без вас знаю. Если вы уже выучили, как и где определён этот самый uint_fast8_t? Последуйте своему же совету: Читать описание TCP, чтобы не пороть очередную чушь (С). если вам не получиться, это не значит, что ни кому не получиться. ещё раз, как я на com в рукопашную делал keep-alive.... прямо, спешал4ю, шагзашагом.... берём протокол... на вскидку... FD00042 Этот протокол не имеет средств определения разрыва соединения. пускаем этот протокол через COM, использую только TxD и RxD. То, что вам не получиться обнаружить разрыв, это уже все поняли. Я обнаруживаю разрыв следующим образом: Если нет активного обмена с устройством в течении времени t1, то читаю идентификатор устройства. Если устройство не ответило несколько раз подряд, то считаю что имеет место разрыв (или устройство вышло из строя) и помечаю "нет связи с устройством". Ровно об этом я и говорил, когда сказал Что я сказал про компорт не так? Не нравиться пример на протоколе FD00042 - замените FD00042 на Modbus-RTU. Если нет активного обмена с устройством в течении времени t1, то читаю_нужный_регистр/читаю_несуществующий_регистр/отправляю_устройству_команду_тест_связи/отправляю_устройству_не_поддерживаемую_команду (нужное подчеркнуть). Если устройство не ответило несколько раз подряд, то считаю что имеет место разрыв (или устройство вышло из строя) и помечаю "нет связи с устройством". Вы мне что пытаетесь доказать? Что я так не делал? Или что это сделать не возможно? Мне возможно. Вам видимо нет, так как плохому танцору вам мешают ... мешает протокол обмена, о чем вы сами и заявили мне, в отличии от вас, протокол обмена это сделать не помешал. PS: С вами говорить о чём-либо по TCP (да и не только) бесполезно. А вменяемые люди знают: 1) На соединении через COM-порт возможно программно организовать проверку соединения без привлечения каких-то дополнительных инструментов типа сигналов CTS/RTS 2) ух ты!!! TCP с точки зрения пользователя сокета!!! Уже взгляд с точки зрения сокета?! С точки зрения пользователя сокета номера последовательностей недоступны. 3) Что за кадры вы придумали? Новые ваши "перлы", точно характеризующие ваш уровень "знаний" о TCP (С). Вы придумали в этой теме кадры, теперь кому-то доказываете что там нет кадров? ))) Я тут редко бываю.... с вам наверно в 3-ий раз вступаю в диалог, и в 3-ий раз вы за оппонентов что-то своё додумываете, и потом что-то им приписываете и потом всем начинаете что-то доказывать и спорить. Зачем? pps человек точно под алкоголем/веществам/COVID19 не вменяемый . Начинает мерещиться всякое.... Модераторы, дайте бан отправте на карантан на пару недель jcxz. Видно же, что человек не в себе. ppps Если вы уже выучили, где и как определён uint_fast8_t и как найти stdint.h, и есть время свободное, но вы не можете ни как осилить TCP, то пожалуйста, выучите хотябы это - The TCP specification does not include a keep-alive mechanism и постарайтесь понять смысл.

я писал выше в этой теме. если вы не видите (читаете не внимательно), не вижу смысла писать ещё раз... CRC - (она же контрольная сумма, или checksum, имелось это в виду), Чтоб вы тут не лопнули, пытаясь доказать, что CRC != checksum, ...... вместо "контрольная сумма" часто говорят crс, из-за краткости. Более того.... см ваш вики в анг, вот вам пруф на crc в tcp "сегмент TCP максимального размера имеет длину пакета больше, чем MTU. Это приводит к фрагментации и уменьшению скорости передачи полезных данных." пруф на вашу же вики. Ваши "перлы", точно характеризуют ваш уровень "знаний" о TCP. Вы бы хотя бы свою вики почитали. я говорю про TCP. В TCP нет keep-alive.... The TCP specification does not include a keep-alive mechanism!!! Прикладной программист, использующий TCP как транспорт как безошибочный COM-порт ( с чего и возник мой вопрос), берёт готовый стек (программный или аппаратный) и использует его. Стек, как правило имеет API на открытие сокета, закрытие, прослушку, отправку данных и чтение. Номера последовательностей, crc контрольную сумму и т.п. - это всё скрыто за API. И если в стеке TCP нет реализации keep-alive, то ..... Вот именно. Но TCP не заботится о keep-alive. (Если не согласен, читай The TCP specification does not include a keep-alive mechanism! и если со спецификацие не согласен - пиши авторам в адрес). В LwIP стек на себя взял заботу keep-alive. я же писал выше. Девайс-Хаб-(облако)-ПК. Вот ноут подключен к роутеру патчкордом, ваш девайсStm32 также подключен к этому же роутеру пачкордом. Везде "горят" линки. Ваш ноут установил соединение с девайсStm32 (локально, без выхода в инет). Выдерните пачкорд из девайсStm32 - на ПК в сетевухе будет гореть линк, и винда не обнаружит что кабель из девайсStm32 выдернули.

где там сказано о обнаружении разрыва соединения? см выше, я уже писал. я вас тоже. Я с вами согласен. Делает программист, пишуший TCP-стек. делающий программную или аппаратную реализацию ТСП стека. Но ТС вроде как всего лишь хочет пк подружить с стм32. Было предложено ТСП. Он не стек пишет, а приложение. я вам написал как это можно обнаружить. Если в стеке не реализован механизм keep-alives (а как мы видим из RFC он там не обязан быть реализован), то разрыв, во время простоя, возможно из аппликэйшин обнаружить, только посылая дополнительные пакеты. ну наконец-то от вас конкретика... можете ведь нормально общаться... что касается написанного..... если а вам скажу про ваш плохой аглицкий - примете за оскорбление? там написано следующее: Если keep-alives включён, (не, не включён... включён не в смысле turn on, а в смысле реализован.... перефразируй в данном контексте) Если keep-alives реализован, то приложение должно иметь возможность включать и выключать такие пакеты (пакеты keep-alives) для КАЖДОГО ТСП соединения. The TCP specification does not include a keep-alive mechanism!!! О чем я сразу сказал, с чем вы не согласны и меня пытаетесь переубедить. Давайте остановимся на этом. Если есть желание поспорить - поспорьте со спецификацией. не являюсь носителем английского и прошу за неточность перевода... вот нашел перевод на великом и могучем.... "If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection" - "При включении keep-alive приложениям должна обеспечиваться возможность запрета таких пакетов для отдельных соединений TCP" пруф

я читал это. во первых это рекомендация, а не требование (не спецификация ТСП).... Это рабочее предложение.... ну и во вторых даже в этом документе чёрным по белому

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

Где? Как обычно - пустослов. Дайте пруфлинк или копипаст. Понимаете в чем ваша проблема? Какая проблема в вашем общении?.... вы ни когда не можете дать конкретный ответ/совет. Даже в рамках последней дискусии - gerber, Сергей Борщ дали короткий ясный ответ/совет. Всё понятно. Что вы тут устроили? перефразирую, для тех, кто в танке - я внимательно посмотрел описание ТСР. Я не нашел там "встроенное" определение внезапного разрыва соединения. Скорее всего, перед тем, как вы дали совет "повнимательней прочитать описание ТСП", вы сами открыли и прочитали это описание, чтобы убедиться, что вы ни чего не путаете. Так вот, я прошу вас дать мне ссылку на это описание и на тот раздел, где говориться том, каким образом ТСП определит обрыв кабеля? Пруфлинк или трепло? Вы упорно не желаете дать конкретный ответ, только на подобие "Имеющий уши - да услышит, глаза - да увидит." Сплошной троллинг. номера последовательностей (входящий и исходящий). пфффф...... так этого НЕТ в ТСП ТСП сам ни чего отправлять и контролировать не будет. В ТСП есть crc, есть фрагментация, есть номера последовательностей и много чего. ТСП вам гарантирует доставку данных без ошибок, т.е. там уже встроено crc и не нужно дополительно его делать. Но ТСП вам не гарантирует автоматическое определение разрыва, ТСП сам не будет ни чего посылать и контролировать, ни какие кипэлайвы . Это нужно делать программисту, как вы пишете, дополнительно. Ровно как и в СОМ. вы как обычно, живете в фантазиях и каждую строчку, каждую фразу путаете. я вам не говорил, что в СОМ есть keep-alive , что СОМ может сам обнаружить обрыв. Я вам говорил, что keep-alive в СОМ я реализовывал врукопашную, т.е. программно, дополнительно - ровно как и вы предлагаете в ТСП keep-alive реализовать программно и дополнительно. UART Бывает плохому танцору тоже что-то мешает. Но это же не про вас? У меня был как и свой доморощенный протокол, так и стронние. На вскидку, Modbus-RTU, хотя там и есть тестовые команды, которые разрабы леняться реализовывать ( или мало место в мк), можно читать один и тот же регистр с таймаутом keep-alive_timeout и далее все как реализовано в.... в моей ссылке выше. Можно послать команду несуществующую, слэйв должен вернуть ответ с кодом ошибки.... в немодбасе - также, делай обмен периодический (что-нибудь читай короткое, без всяких спец пакетов). А теперь внимание откровение для Вас: В TCP сокете keep-alive (в тсп, в сом, в др....) делается именно для соединения, а не для протокола обмена и не зависит от протокола. Почувствуйте разницу! Одни это реализовали аском, вы предлагаете номерами, я делал пустым обменом.... не важно как это реализованно, но делается именно для соединения. Неожиданно, для вас это наверно, да? Вам неожиданно то, что вы мне что-то доказываете... что-то свое.. вы придумали, что я утверждаю кипэлайв для протокола. Но это не так, я этого вам не говорил. я почти на протяжении всех постов говорю "разрыв соединения". Перечитайте мои посты. Неожиданно, да? речь не о контроле линка, а определение выдергивание кабеля. подключитесь Девайс-Хаб-(облако)-ПК. Дерните пачкорд из ПК. Линк на вашем девайсе не пропадет.

вы как всегда путаете мягкое с тёплым. по порядку.... в ТСР контроля (внезапного) разрыва соединения нет. Это его (этого протокола) недостаток. Этот недостаток компенсируется надстройкой (в ОС, в реализации стека, в программе). Можно самому по таймеру слать контрольный пакет и получать ответ. если тишина - коллбакДисконнект(); (может кто-другой предложит др алгоритм.... в студию). дальше можно не читать. Ни кто не говорит, что это невозможно СДЕЛАТЬ. В рамках протокола ТСР ни каких keep-alive нет. Для "автоматического" определения выдергивания кабеля (я не имею в виду link, т.к. кабель можно дернуть в др сегменте сети и link останется) нужно (правильно вы говорите) СДЕЛАТЬ. Сергей Борщ говорит, что в lwip это сделано. Далее... чтобы вы понимали что такое "автоматическое определение выдернутого кабеля", о коем идет речь, посмотрите USB. должно быть стыдно за этот ps. см как сделали keep-alive в ТСП, например тут. Кто вам мешает по COM посылать АСК контрольные пакеты и если не было ответа, то принимать решение, что соединение разорвано? ps а как можно реализовать keep-alive обнаружение выдернутого кабеля по номерам пакетов ТСП? Не поделитесь секретом? (чтоб вы опять пустых реплик, типа "читай гугл да вразуми" не писали... вот вам ситуация... установили соединение между 2-мя устройствами по тсп. обменялись данными.... и..... пока нет необходимости в обмене... минуту нет обмена... две минуты... 100 минут... 10 дней..... 3 года нет обмена - можно уже считать что кабель выдернули? Как это покажет нумерация пакетов ТСП?)

"Ты суслика видишь? а он там есть" (С). пруфлинк или ....? сами себе противоречите. Вы уже определитесь - он keepalive там в ТСР ЕСТЬ? Или его нужно организовать?

Я другим стеком пользовался, там не было. Про lwip буду иметь в виду, спс. там нет keepalive. Я другим стеком пользовался, там не было. Про lwip буду иметь в виду, спс. Хотя... минуточку.... а Вы им пользовались? Реализация keepalive зависит от стека. в ТСР нет пакетов keepalive. Если прибор с ТСР(lwip) подключить к устройству, в котором нет lwip, и в котором нет надстройки keepalive? Или в котором keepalive реализован по другому.... ?

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

В TCP есть keep-alive? я делал рукопашный keep-alive для TCP. По сути этот тот же рукопашный keep-alive как и для ком-порта (т.е. смена COM на TCP тут преимуществ не даст). Возможно keep-alive уже реализован в каком нибудь стеке, типа LWIP. Кто в курсе?

Считайте, что это такой безошибочный COM-порт БЕЗ определением выдергивания кабеля.

Коллеги, кто разобрася с корректировкой частоты в Sx1276, sx1272? Не получается скорректировать частоту. В даташите треборание на кварц ±30ppm, но в реали с таким кварцем без корректировки lora не работает. Что сделал: Собрал модуль, частота резонатора 32МГц. Задал частоту приёма/передачи 868 МГц. Смотрю анализатором - передача ровно на частоте 868 МГц. Пакеты ходят без ошибок. Ставлю менее точный кварц. запускаю передачу - анализатор показывает 868,050 МГц. Хорошо.... в регистры частоты записываю меньшую частоту, в результате передача становиться ровно на 868МГц, но данные все с ошибкой. понятно что кодировка (битрэйт) съехал. Из даташита у меня уход несущей на 50 кГц, т.е. 57 ppm. 0.95*57 = 54. Записываю 54 в регистр PpmCorrection - не помогает. Заношу минус 54, не помогает. Сделал отправку раз в сек, при каждом пакете значение регистра PpmCorrection инкриминирую на 1 - нет ни одного пакета без ошибки. PpmCorrection крутил долго, несколько раз от 0 до 255 прошел - ни одно принятого пакета без ошибки. Причем, когда меняю регистр PpmCorrection, то частота передачи стоит на месте, т.е. PpmCorrection корректирует ppm кварца, от которого работает несущая, но несущая от PpmCorrection не меняется. В связи с этим вопросы: 1) какой правильный алгоритм корректировки частоты? 2)на что и как влияет PpmCorrection?

Зачем? "Да что ты, чёрт побери, такое несёшь?" (С) Для тех кто не дружит со здравым смыслом вообще не нужно заходить на форумы и давать советы.

"Да что ты, чёрт побери, такое несёшь?" (С) раз "Программирование под Андроид", год назад просили... где нужный раздел? два для тех кто с аглицким не дружит, чтоб не опозориться, хотя бы читаем тут

смотрите..... пример на вскидку.... в самом начале - создание JOB. Всё мышкой. ПКМ по проекту и понеслась выбор всех пунктов мышкой. Вы серъёзно!? Вы по пунктам меню лазаете клавиатурой? Быстрыми клавишами!? А как роялем на клавиатуре добавить JOB в проект? Нажать последовательно (не одновременно) Alt - F - N - u. Неужели кто-то так делает? Неужели вы помните все эти IDDQD как без мышки сгенерировать выходные герберы? Зачем это помнить? Всегда считал и считаю, что эти Move (M) (не горячие клавиши, а "быстрые" клавиши, доступ до пунктов меню, ведь об этом идет речь, логика рухнула на "Перемещение - М") нужны только тогда, когда сломалась мышка и при этом клавиши курсора на клавиатуре не работают/отсутствуют.