Хм. Прикольно.

там еще по ссылкам прогуляйся.

Прикольно, да. Но это ж realtek… Это ещё те извращенцы… Я поэтому и говорю что нормальных открытых вещей я не видел. Либо рабочее, но огороженное по самое небалуйся, либо рабочее, но полу-открытое, плюс, там изврат на изврате.

Да, я некорректно по 915 написал.

433 и 868 открытые. 915 открыт, но в США

Да, почти так. Только я всегда предупреждаю заказчика что 433 только формально открыт. Зависеть будет от мощности, излучаемой в эфир и от близости к ненужным некоторым координатам на местности. Если автомобильные сигналюги не парят никого, кроме соседей по многоэтажкам (да и то, когда машины во дворе от скуки орать начинают), то в случае, если мощность поболе чем у брелка автосигнализации, можно заполучить неиллюзорных проблем. В Москве, например, вероятность таких проблем стремится вообще к 1.

А по поводу 915 Вы абсолютно правильно всё говорите. У меня за всё время только один заказчик пару раз хотел залезть в этот диапазон. Зачем-то. Этот диапазон менее выгоден чем 868 из-за «физики», её никуда не денешь.

Так что, 868 в России это наше всё.

Эмм... Скажем так...

Есть интуитивное ощущение что когда-нибудь откроют (или утекут) исходники всех этих модных IoT-радиоблобов и человечество обнаружит что все устройства доступны для взлома всеми желающими. А обновить прошивки уже не получится.

С одной стороны, да. Это правда. С другой, уже сейчас можно просто и без затей поставить рачком практически любую сеть IoT, банально выставив помеху (помехи) в данном диапазоне, в данной технологии (ну, чтобы помеха по тому же алгоритму делала бы хоп по частоте, например, в зависимости от времени, если это предусмотрено используемой технологией). Тогда вся сеть очень умных датчиков внезапно станет очень тупой. И на очень долго, пока источник помехи не будет найден и изолирован, а это уже пеленгация, триангуляция и вот это вот всё, т.е., это «анализ радиоокружения и радиообстановки».

Или как я внезапно понял на одном из проектов, что да, в сс1310 поддерживается AES. Но есть незадача – если показания датчиков не менялись в течении более-менее длительного времени и я их знаю, и я могу перехватить каким-то образом (весь вопрос в том, насколько хорошо вооружён злоумышленник) траффик, то получается что мне этот трафик даже ненужно дешифровать. Я могу и восстановить ключ (достаточно долго) и подменить сообщения, передаваемые в эфире. И, подчеркну ещё раз, это даже не BLE и не Wi-Fi, это отдельные радиопротоколы, которые разрабатываются под использование их с платы со своим проприетарным стеком типа EasyLink. Тогда в полный рост пришлось разбираться с изменением ключа, nonce, синхронизацией, восстановлением после ошибок, вот этим вот всем. А это дополнительная нагрузка на довольно простенькое устройство (cc1310, она с ноготь мизинца) и расход питания, как ни крутите. Ещё полным-полно трюков.

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

Будущее нас сильно «обрадует». =)))

Да ни кто и не собирается...

рынок-то отжимать.

Поэтому у этих плат и не получается отжать рынок у avr’ок. Т.к. там студия, где все сразу: документация, примеры, редактор кода, симулятор, отладчик и морда к программатору.

Как правило, о плюсах и минусах решений на ARM/AVR/MIPS/… все в курсе. Вон, выше уважаемый mv хорошо написал. Просто, когда «всё и в куче», это означает что Вы разбираетесь с проблемами именно этого решения. Например, на AVR, если уж о нём речь зашла. Если Вы готовите (умеете готовить) сами себе toolchain, среда Вам пофиг, т.к. это просто нашлёпка над toolchain, программатор или внутрисхемный эмулятор Вы можете себе сами «подстегнуть» для отладки/прошивки, то это означает что Вы знакомы со всем стеком разработки. И Вам что ARM, что Aarch64, что MIPS, что ещё что-либо, совершенно похрен. Надо под ARM, будет под ARM. Надо перейти на MIPS, ну то же в принципе понятно что делать. Вы будете знать где именно искать источник проблем, если всё пошло не так.

Я вот с какой точки зрения это всё рассматриваю.

Ответ сразу двоим уважаемым коллегам.

Не забудь упомянуть, что китайский сканер стоит сто евро, а родной все 400.

И

Любой J2534 сканает. У меня коётовские Mongoose VCI и Xhorse видятся.

Я только в начале пользовался «полноформатным сканнером», выделенным клубом, точнее, нашим клубным сервисом. Пока не понял что лучше бы мне спаять на базе ELM327 свой провод и распаять его на плату моего CarPC.

Так-то рекомендую мастридные в данном случае вещи типа The car hacker’s handbook (http://opengarages.org/handbook/) и более наглядный чисто для примера https://www.freecodecamp.org/news/hacking-cars-a-guide-tutorial-on-how-to-hack-a-car-5eafcfbbb7ec/

Bluetooth варианты, которые есть на рынке, мне не понравились, т.к. не дело в эфир нутро машины выставлять, пусть оно и довольно скромное по своему наполнению, чем у большинства современных машин. Спаял в общем, прокинул аккуратно кабель под торпедой, встал на разъём. А дальше пришлось немного пофаззить, т.к. было не совсем понятно что у меня за контроллер и как с ним общаться. В моём случае их два типа, там режим работы различается. Система запросов и откликов практически не различается.

И да, в моём случае «сканнер» это так… больно громкое название. Я оттуда запрашиваю весьма небольшое число данных, если честно. Чтоб соблазна не было нарукоблудить лишнего.

Так что, в моём случае это было цена микрухи, обвеса и примерно неделька неспешного фаззинга. А дальше уже какая-то добрая душа мануал подогнала, как раз на мою тачку и с кодами. Всё было проще. Просто проверял запрос-отклик-реакцию бортового контроллера.

Книгу рекомендую к прочтению, там всё очень хорошо расписано, чисто для вкуривания темы «с нуля», как это было в моём случае. Ну а конкретику под конкретную машину, это понятно что надо софт точить уже по месту. Хотя, через ELM там всё просто. По сути, ELM это ODB-II-RS232 интерфейс. Т.е., в ядре включаем поддержку FT232R и погнали запросы через UART кидать на контроллер/читать оттуда ответы. Так намного проще, чем через CAN-шину напрямую общаться с контроллером. Я этот вариант именно из-за простоты и выбрал. Открываем какой-то /dev/ttyUSB*, а дальше можно даже посредством AT-команд попробовать поработать. Ничего сложного.

Сложности будут – выставить нужный режим работы ELM, чтобы именно под эту версию ODB-II пошло (последние ELM позволяют сконфигурировать программно эту часть, раньше нужно было разные варианты иметь в виде «жгутов», насколько я знаю) и подобрать команды запросов, распарсить коды ответов (я не стал мудровать и заюзал regular expressions in glibc, благо и так гента на борту используется), интерпретировать их и закинуть в экранные формы, тот же аккумулятор нарисовать на экране и показать какое там напряжение, например. Собственно, чисто примера ради, если кому понадобится – https://codeseekah.com/2012/02/22/elm327-to-rs232-in-linux/

Ну вот, как-то вот так, в общем.

P.S. Вспомнил. Вдруг, кому интересно будет – http://freediag.sourceforge.net/ Тут реально рабочий линуксовый проект. Авось кому сгодится. Я сюда подглядывал когда свою версию писал.

Угу. Но только учитывая даже микропитон, она только разве что лампочками мигать и будет. Больше ресурсов не хватит, скорее всего, практически ни на что.

«Мигать лампочкой» - это условность. Можно собрать экран из лед лент и он может им управлять (да и более слабый контроллер с меньше памяти, но этот быстрее и лучше), однако в отсутствии вафли и блюпупа пользы мало - с трубки не порулишь изображениями.
Можно собрать автобармена, автоконтроль теплицы, Наливатор напитков на компанию и любое число рюмок 1-9 автоматический. Автокормушку, сворачиватель штор, открывалку окон. Роботов разных видов, часы-метеостанцию. Анализатор спектра, nfc-замок.
Это только из того, что сразу припомнил навскидку и что не сложно сваять в ардуино иде. Правда я прочёл уже, у малины своё будет предлагаться. Хотя уверен, ни что не мешает и в этом делать по привычке.

Главная проблема, что тут ни вафли ни блюпупа - ничего распространённого.

Какой у нее интерфейс между cpu и fpga с точки зрения системного программиста?

Pico

Boku no?

Получается, Pidora – это были ещё цветочки.

Уже появилась на taobao: https://world.taobao.com/item/636599392844.htm

Единственные два плюса Arduino...

это цена и простота. Цена – потому что не жаль спалить платку. Хотя, всё относительно, кому-то и $20 это безумные расходы. Простота – потому что программирование ардуинки это по сути то же, что в ARM/Aarch64/MIPS называется bare-metal. Хотя, тут «стандартная» либа весьма развита и позволяет без напряга сделать многое. Не спорю. Плюс, конечно же, IDE в помощь.

Но мне лично ARM (и прочие выше названные) позволяют работать как угодно. Я могу работать с ними как с bare metal системами, я могу поставить туда какую-нибудь ОС типа freertos или little kernel (да, ту самую, которую за пару лет написали пять или шесть немцев и на базе которой Google сейчас свою фуксию пилят) или openwrt или вообще накатить gentoo. Если нужно по условиям задачи и позволяют ресурсы вычислительной системы, которую я пилю. Но тогда уже либы я так же должен туда сам накатывать, собирая то, что мне конкретно нужно на данном решении. CAN, значит, CAN, сетевые какие-то вещи, значит, сетевые какие-то вещи. Ардуинка этого мне не особо позволяет. Не тот круг задач, как правило.

Как пример. По роду моей деятельности мне частенько приходится дизассемблировать и реверсить чужой код. И не всегда открытых решений (это-то зачем?). Чтобы просто навскидку глянуть что там происходит с сетевым протоколом, мне неплохо было бы использовать классическую MiTM-атаку. Т.е., ставлю, например, андроидную софтину в эмулятор ARM на десктопе, запускаю, подсовываю ей фейковый DNS, сдёргиваю SSL/TLS через sslsplit. Для этого есть своё «решение» под названием «сетевой вампир». Это платка Raspberry Pi2 (покупал её самой первой чисто теста ради и под это решение). На борту – gentoo, нужный софт типа sslsplit, dnsmasq и прочего, два адаптера usb-ethernet, через usermode-utilities и bridge-utils там собран бридж, который пропускает трафик, позволяет с него сдёргивать защиту, писать tcpdumpом .pcap и можно отправить через стандартный eth на хост с wireshark, чтобы удобно и ненапряжно распарсить. Боюсь, на ардуинке это было бы несколько сложнее сдалать.

«Малинка» как таковая это несколько более тяжёлый вес, чем ардуинка. Хотя, в генточке под ардуинку тоже toolchain собирать надо описанным выше способом (через crossdev). Но это не делает ардуинку дейстительно универсальным решением.

nfc-замок.

Можно. Вот тут какие-то… «умники» залудили замок на Android Things и Raspberry Pi3 (не знаю что они там курят, но вот – https://habr.com/ru/post/331888/) и вот тут через iPhone и облако на Pi Zero, там ещё и node.js используется (https://withintent.com/blog/how-to-implement-door-unlocking-system-with-raspberry-pi-iphone-and-service-in-cloud/). Видел даже где-то с распознавалкой лиц. Тоже на малинке зеро.

Вот человек сделал типа SIP-домофон. На третьей малинке (https://ab-log.ru/page.php?ID=212&cs=1). Видео, wifi, «переговорное устройство», NFC-ключи… Все дела, кроче.

Открытая схемота именно под замки тоже есть (https://easyeda.com/COshmyan/Raspberry-Pi-Zero-for-door-lock). А уж сверху навернуть – хоть nfc, хоть что угодно можно. Вот тут чёт учудили с Raspberri Pi 3/4, аж с мускулем, тачскрином, апачем и похапе на борту (https://zetsila.ru/%D1%83%D0%BC%D0%BD%D1%8B%D0%B9-%D0%B7%D0%B0%D0%BC%D0%BE%D0%BA-%D0%B4%D0%BE%D0%BC%D0%B0-%D0%BD%D0%B0-raspberry-pi/).

В общем, сделать не проблема, было бы желание. А по цене… По цене это всё не дорого. Правда, если честно, то глядя на некоторые проекты из того, что на малинках делается, мне просто страшно становится. Поверхность атаки такая, что просто ужас. Но это уже дело третье. =)

Делать открывалку-закрывалку для одного окна на малинке я бы не стал, а вот контроллер на все окна для частного дома, можно. Один на все.

Ну вот, как-то вот так…

Я только в начале пользовался «полноформатным сканнером», выделенным клубом, точнее, нашим клубным сервисом. Пока не понял что лучше бы мне спаять на базе ELM327 свой провод и распаять его на плату моего CarPC.

Полноформатный - это обычный «raw», просто трансивер с CAN-контроллером. Типа любой ардуиновский шилд на MCP2515. Или, если есть встроенный в чип CAN-контроллер, то трансивер, типа SN65HVD230. Далее на подходящей библиотеке строится свой код, который может программировать любой аспект передачи сообщений, а не только то, что ELM умеет.

Моя «приблуда» так и работает, прикидываясь официальным вольвовским сканером и, в принципе, дотягиваясь до всего, до чего может дотянуться официальный дилерский софт.

Если есть возможность выбрать микроконтроллер для carpc, то лучше тот, в котором CAN-контроллер уже встроен и висит в адресном пространстве проца, ибо через SPI с внешним контроллером медленновато может быть. 240 МГц ESP32 с двумя MCP2515 уже за старой вольвой уже не поспевает, например. А там всего 125 и 500 кбит/c шины. В то же время, 84 МГц Arduino Duo на ARM’е со встроенными контроллерами работает просто шикарно. 600 МГц Teensy 4.0, тоже на ARM’е, тоже отлично работает. И даже RPC-подобное общение, без фонового траффика, проходит быстрее процентов на 15, чем если использовать тот же Teensy, но MCP2515 через SPI.

Простота – потому что программирование ардуинки это по сути то же, что в ARM/Aarch64/MIPS называется bare-metal. Хотя, тут «стандартная» либа весьма развита и позволяет без напряга сделать многое. Не спорю. Плюс, конечно же, IDE в помощь.

Но мне лично ARM (и прочие выше названные) позволяют работать как угодно. Я могу работать с ними как с bare metal системами, я могу поставить туда какую-нибудь ОС типа freertos или little kernel

Ардуины на не самых мелких 8-битных AVR работают поверх имеющейся rtos. По-сути, только тулчейн, бутстрап и API, а операционные кишки - какие есть на данном подвиде. Вот эта совместимость API и цикла разработки - самое ценное.

Я не эксперт, но разве для переключения потоков нужна прямо ОС? Не хватит просто упрощенной стандартной библиотеки для голого металла? ОС обычно это же много всего, процессы, файловая система, драйверы. Это возможность работы множества программ их независимой загрузки и выгрузки

Да.

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

Для программиста ОС это прежде всего набор каких-то API по работе с разными подсистемами и управлением ресурсами вычислительной системы. В конечном счёте всё сводится именно к управлению ресурсами. Какие именно там сисколлы, как оно внутри реализовано, это уже как правило, дело третье. Тут… народ раздражается от идеи «цонпелять ведро», а уж как оно там унутре устроено, им это вообще лет 300 подряд ненужно даже и знать. А по временам даже вредно это знать. =)))

Я не эксперт, но разве для переключения потоков нужна прямо ОС?

Программирование для bare metal отличается тем, что круг решаемых задач сравнительно узок. По сути если, программирование bare metal это программирование конечных автоматов. Т.е., есть состояния типа «включить светодиод»/«выключить светодиод», «открыть шторы/закрыть шторы» и есть таблица переходов между этими состояниями. Чем сложнее комплекс, тем больше состояний и тем шире таблица, тем выше вычислительные расходы на каждую операцию, дороже процессор и прочий обвес. Тут лишние сложности не нужны. Они, как правило, резко снижают надёжность системы, т.к. всегда есть шанс на то, что что-то пойдёт не так и надо будет как-то отрабатывать возникшее состояние ошибки. Некоторые люди даже не научились проверять возвращаемые функцией значения и им понадобился ещё и механизм exceptions, ага. =)

Переключение потоков привнесёт (ну, по крайней мере может привнести) ряд усложнений. Т.е., состояние регистров как минимум надо сохранить для одного процесса, передать управление второму процессу, сохранить состояние регистров для него, вернуть управление первому, и так для всех процессов, которые могут быть в данный момент в системе, а их может быть более чем два. Ещё бы не забыть о возможно нужных механизмах синхронизации… Короче, это довольно дорогая по накладным расходам операция, которая привносит дополнительные сложности. Для bare metal это плохо, т.к. приходится решать нерелевантные основной задаче дополнительные задачи.

Не хватит просто упрощенной стандартной библиотеки для голого металла?

Считайте, получив такую библиотеку, Вы уже получили часть операционной системы. У Вас в таком случае уже появляется API для работы с процессами и потоками. Единственный вопрос только остаётся – что у Вас там за ОС получается. Есть в ней real time, т.е., есть фиксированные временные промежутки, в течении которых либо произойдёт переключение потока/процесса, либо таковых промежутков нет.

Кстати! Например, в Linux таких временных промежутков нет, поэтому на Linux real time в полной мере недостижим (патчи на ядро относятся только к механизмам приоретизации процессов, а в нормальных RTOS даже файловая система имеет такие временные промежутки, про потоки и не говорим, и так понятно что всё есть). Те же QNX/VxWorks и прочие узко специализированные решения таковые промежутки имеют. Поэтому они и RTOS и стоят как крыло от самолёта. Недавно смотрел вебинар, где чуваки из мира авионики рассказывали про свои проблемы – там даже многопроцессорные системы они путём не могут осилить повсеместно и за дёшево, т.к. возникают вопросы типа когерентности кешей и всё становится грустно и печально. Не всегда такой подход, связанный с реализацией такого рода библиотеки сработает «в лоб». Но если сработает, то озолотитесь. Я серьёзно. =)

Соглашусь.

Ардуины на не самых мелких 8-битных AVR работают поверх имеющейся rtos. По-сути, только тулчейн, бутстрап и API, а операционные кишки - какие есть на данном подвиде. Вот эта совместимость API и цикла разработки - самое ценное.

Для «мира ардуино» да, всё верно. Но у меня проблема в том, что создаваемые иной раз устройства это сразу и по дефолту не ардуино. Девайс делается под соответствующие business requirements, как правило берётся максимально похожая «открытая» плата т.е. плата с открытой схемотой, правится, добавляя нужное и убирая ненужное, переразводится, делаются герберы, отдаётся вся эта беда технологу на производство (а вот это крайне дорого, т.к. не упоротые в хлам технологи это на вес золота, реально), на производстве «вылизывается» технологом, уходит на «выпечку», дальше, а чаще всего параллельно с разработкой и производством железки (считаем что опытный экземпляр у нас уже есть), пишется dts на плату, обеспечивается boot, если требуется, то и secure boot, потом уже натягивается какая-то ОС… Уффф… писать устал. =) Но примерно так и есть.

И мне тут уже существующая ОС, пусть даже и RTOS может оказаться не помощью, а помехой. Если, конечно, это не специализированное, кастомное решение типа тех же сс1310/1350/1352, про которые я тут уже помянул. Там RTOS как раз очень в тему. Иначе можно просто задолбаться.

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

Да, это я уже понял. =)

Моя «приблуда» так и работает, прикидываясь официальным вольвовским сканером и, в принципе, дотягиваясь до всего, до чего может дотянуться официальный дилерский софт.

Поэтому сразу и заценил, сказав что крутая разработка. И не отказываюсь от своей оценки ни в какой мере. =) Я пошёл по более простому пути. Не люблю я усложнений типа «программирования CAN-шины», т.к. имею некоторое представление об этом процессе. Мне «всё» ненужно, мне нужно сравнительно немного, поэтому я и зарядился сразу на ELM.

Полноформатный - это обычный «raw», просто трансивер с CAN-контроллером. Типа любой ардуиновский шилд на MCP2515. Или, если есть встроенный в чип CAN-контроллер, то трансивер, типа SN65HVD230. Далее на подходящей библиотеке строится свой код, который может программировать любой аспект передачи сообщений, а не только то, что ELM умеет.

Для меня «полноформатным», который я использовал на первом этапе, был сканнер от клубных ремонтников. Я просто посмотрел что он вообще может, т.к. у меня есть доступ в клубную ремзону и меня оттуда не выгоняют (обычно – пригнал своё корыто, передал в ремонт и иди погуляй где-нибудь). =) Поэтому просто смотрел что сканнер вообще делает, что показывает. Прикидывал перспективы, т.к. программирование CAN для меня это не то чтобы тёмный лес, но довольно сложно. Там состояния надо отлавливать очень чётко, ЕМНИП. А я на старте не особо хотел морочиться, это уже потом, аппетит пришёл во время еды, что называется. =)

Если есть возможность выбрать микроконтроллер для carpc, то лучше тот, в котором CAN-контроллер уже встроен и висит в адресном пространстве проца, ибо через SPI с внешним контроллером медленновато может быть. 240 МГц ESP32 с двумя MCP2515 уже за старой вольвой уже не поспевает, например. А там всего 125 и 500 кбит/c шины. В то же время, 84 МГц Arduino Duo на ARM’е со встроенными контроллерами работает просто шикарно. 600 МГц Teensy 4.0, тоже на ARM’е, тоже отлично работает. И даже RPC-подобное общение, без фонового траффика, проходит быстрее процентов на 15, чем если использовать тот же Teensy, но MCP2515 через SPI.

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

ТС, унчё исчо нашлось...

Некая малазийская контрока под назанием Cytron забабахала плату для разработки/отладки на Pico Pi https://www.tomshardware.com/news/cytron-raspberry-pi-pico под названием Maker Pi Pico.

Т.е., вставляем платку Pico Pi в некую плату, где разведено всё, что есть на Pico Pi и даже есть micro-SD, разрабатываем, программируем, получаем готовое и в принципе тиражируемое решение. Цена, как говорят, в районе $5-10 за платку.

Рендер решения – https://cdn.mos.cms.futurecdn.net/RUtQLB2UfGAsNm62TaAGe3-970-80.png

Реальная цена zero £4.50, о каких $50 речь? https://shop.pimoroni.com/products/raspberry-pi-zero

We don’t offer shipping to Kazakhstan

Не работает твоя ссылка.