Всем привет,

Есть задача - МК с TCP/IP и аппаратным модулем WiFi необходимо осуществлять запись данных (примерно 100 байт) раз в час в БД MSSQL или MYSQL.
Вопрос - Как реализовать sql клиент на МК?
Интересуют функции - создать таблицу, вставить данные, считать данные из таблицы, удалить данные, удалить таблицу.

Я пока решил задачу методом написания нативного приложения, как мне сказал разработчик базы в MS SQL по другому никак, хотя может слукавил.
Приложение конектится к устройству по TCP и к БД и транслирует "команды"(по сути вставляет присланные данные в таблицу) с девайса в БД.

по сути sql соманды это просто текстовые строчки в которых данные также могут быть в текстовом формате, строчки текста или числа 'text' 123 123.4 0x1AF тоесть задача по сути сводится к формированию и выводу строчек текста с динамически меняющимися частями, напр:
insert into t1 values (d13,d23,d33);
insert into t1 (c1,c3) values (d14,d34);
update t1 set c2='x22' where c1>'b';
update t1 set c1='xxx',c3=777;

клиент это вобщем штука которая позволяет авторизоваться на сервере и создать поток по которому будет идти подобный текст. по дефолту из консоли оно цепляет дескрипторы stdin/stdout к серверу и сам клиент выводит в stderr.

если по какойто причине не удается соорудить на mcu коннектит к базе напрямую (напр нет возможности сделать tls транспорт на mcu а база разрешает коннект только tls и невозможно управлять политиками доступа ,скажем сделать плэйнтекст трасэд без авторизации для ip контроллера, то можно сделать отдельный tcp сокет на любом компьютере в сети, который сможет приконнектится к базе клиентом и направит сокет в клиента напр на linux/bsd ss+mysql, или nc+psql, в любых сочетаниях конечно)). тогда задача обратно вернется к телнет протоколу через tcp.

если я правильно понял вопрос.

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

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

Подробнее>>

Если на МК возможно поднять SSL, задача элементарно выполняется, если нет - то никак. Без ssh или ssl только дурак оставить открытый наружу сокет!

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

>Без ssh или ssl только дурак оставить открытый наружу сокет!
извиняюсь какого ssl? не ssl v3 случаем ?))

зы речь врядли идет о связи mcu-mysql через интернет . а если даже и через интернет - нет никаких проблем транспортировать это соединение секюрно и терменировать за пределами mcu.

К чему такая категоричность? На серьёзных производствах работал с АСУ, в которых стояли десятки SQL-серверов, но их сеть не имела физического подключения к сетям вне завода. В таком случае необходимости в шифровании и нет.

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

Подкину вам интересную идею - сейчас популярны умные счётчики которые передают данные раз в час куда-то в интернет на свой сервер, а пользователь потом забирает эти данные через API либо другой интерфейс.
Недостаток 1. Получается помимо счётчика производитель навязывает пользователю свой сервер или облачный сервис.
Недостаток 2. Если пользователь хочет писать данные не куда-то в интернет а на другую платформу, то ему необходимо в довесок к счётчику приобрести "энергетический сервер" к которому будут подключаться несколько счётчиков, и тогда данные можно будет сбрасывать по sftp (ver 3) куда-то на свой сервер в виде csv файла. Стоимость такого сервера примерно как 10-15 счётчиков.

Идея такая - скрестить два устройства - умный счётчик и энергетический сервер, чтобы счётчик мог из коробки конектиться к стандартным сервисам (MS SQL, MYSQL, MS IoT, MQTT, SFTP-server и т.д.) и передавать свои данные без всяких скриптов, АСУТП, шлюзов на свой внутренний сервер.

боюсь на слабых контроллерах без ос нереально поддерживать современные шифрованные протоколы в актуальном виде. напр всего неск лет назад мир шифрованных соединений пришлось срочно какследует перетряхнуть см "sslv3 poodle vulnerability" ну и всякие вещщи попроще случаются 1-2 раза в год ... + скажем x509 даж пресеты сертификатов поддерживать ...

имхо из более менее реального нешифрованного, без кулибин-колхоза и сильного запаха плесени это:
1. http get
2. snmp
3. webdav (over http)
4. upnp

ну или просто udp слать с данными в очевидном текстовом формате без извратов а на компе слушать чемто вроде nc/ss и парсить python/perl .

Третий еще unstable. Там запросто могут быть дыры. У меня последняя версия — 1.1.1l (но уже неделю не проверял обновления). UPD: почитал про баг sslv3, понял, какого черта оно hardmasked. Однако, как бы то ни было, вы не организуете секьюрный сокет (или вебсокет) без SSL.

Это пока какой-нибудь рукожоп (или вредитель) не влезет, куда не нужно! Потому единственная что по-настоящему защищенная сеть без шифрования — это компьютер без сетевой карты.

P.S. А что по поводу вопроса ТС, то простейшим способом было бы организовать выделенный канал связи МК с компьютером (USB, CAN, RS232 и т.п.), по нему считывать данные с МК и писать в БД. Так по крайней мере никто БД не порушит шаловливыми ручками.

P.P.S. И вообще, я категорически против беспроводной связи микроконтроллеров с чем бы то ни было (потому что вообще голой жопой в эфир торчат), а также — использования общих сетей ethernet для связи с МК. Если уж так надо — присобачьте к МК "малинку" или же возьмите МК пожирней, который сможет то же самое делать без ОС.

А кто является сервером?
Серв рядом или хостинг?
Если рядом то можно на МК скинуть ETHERNET + HTTP.
А на серв перекинуть PHP+SQL и TCP пакета хватит что бы запросы кидать.

Вопрос безопасности закрыть отдельным проводным каналом связи.

Eddy_Em, ssl v3 -это последняя версия этого протокола, она считалась стабильной продуктовой ... до 2014 , а после все его версии был признаны уязвимыми по дизайну и рекомендованы к замене на tls. современные протоколы и криптоалгоритмы и вообще настоящая несмишная компьютерная безопасность это довольно обширная область, обсуждать ее даж на продвинутом бытовом уровне нет смысла , это все равно что врачу терапефту рассказывать про проблемы апч у приемников с двойным преобразованием частоты. имхо.

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

а на бытовом уровне, ну напр: собери физический эзернет отдельный, в который можно попасть из интернета только через единственный интерфейс основного хоста с собранными данными и тогда надежность такого решения никак не зависит от надежности протоколов обмена в этом отдельном сегменте. но вообще при грамотной организации такой колхоз ненужен, есть netfilter,conntrack,rp_filter,ebtables,...

И в чём проблема? Что мешает его (TLS) использовать на МК?

А какие интеллектуальные счётчики э/э вы знаете? И почему думаете, что таких уже не существует?

Добавлено after 3 minutes 20 seconds:
Почему?
ТСу нужно всего "100 байт в час". С таким траффиком (шифрованным) имхо - даже самый слабый МК справится. А для счётчиков э/э редко когда нужно больше (если передавать только текущие показания).
Да даже если бы и больше траффик - основная загрузка в TLS - при открытии соединения (асимметричное шифрование). Когда "рукопожатие" завершено, используется уже только симметричное. Для передачи тела данных. А оно менее требовательно к вычислительным ресурсам. Видел реализации AES256 оптимизированные под 8-битные МК.

Добавлено after 3 minutes 56 seconds:
Вы в каком году живёте?
SSLv3 - давно уже анахронизм. По-крайней мере в нашем мире. Давно уже везде TLSv1.2 (достаточно открыть WireShark и подключиться к любому HTTPS, чтобы увидеть), а в перспективе - TLSv1.3.

Как хорошо что вас никто не спрашивает. А то так бы и жили до сих пор без мобильных телефонов!

jcxz, перечитай !)), я говорил не про производительность mcu а про организацию сопровождения продукта. если просто сделать и забыть то перестать работать может уже после первого апдэйта софта на другой стороне.

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

А про счётчики, работающие в сетях LoRaWAN не слыхал? Ты сейчас просто описал их работу и работу сети таких датчиков. Это давно уже есть и работает со всеми твоими хотелками. Так что изучай матчасть, тут ты сильно отстал.

Не надо набрасывать известную субстанцию на вентилятор. Ты не понял суть вопроса - задача не собрать сеть из умных счётчиков, это всё давно есть - задача собрать на МК счётчик который без дополнительных шлюзов, адаптеров, энергетических серверов скриптов на сервере и танцев с бубном и сам сможет писать данные в БД с применением шифрования.

Добавлено after 4 minutes 4 seconds:


Сервер рядом. В идеале должна быть железка с вебмордой в которой киповец вбивает данные, а айтишник предоставляет логин/пароль на своём сервере.
Никаких АСУТП, скриптов и т.д. то есть должно быть законченное решение.

Добавлено after 23 minutes 59 seconds:
А какие интеллектуальные счётчики э/э вы знаете? И почему думаете, что таких уже не существует?

У вас немного идеальные представления о производителях умных счётчиков. Посмотрите линейку от Шнайдера, на наших отечественных производителей максимум что они могут - это передавать данные к СЕБЕ в облако либо по модбас скидывать данные на шлюз или энергетический сервер. Писать сразу в БД или скидывать файл по SFTP куда-то на сервер никто из известных счётчиков прямо из коробки не умеет.
К тому же на большинстве предприятий полтора киповца половина асутпшника (если он вообще есть) и куча айтишников.
На айтишников и рассчитан данный девайс.

>>>задача собрать на МК счётчик который без дополнительных шлюзов, адаптеров, энергетических серверов скриптов на сервере и танцев с бубном и сам сможет писать данные в БД с применением шифрования.


имхо это просто перетаскивание функций из области где их удобно осуществлять туда где неудобно, я выше 2 раза обьяснил почему))
всякие скрипты с бубнами и настройка nginx+caldaw или snmpd или ldna это элементарная фигня по сравнению с тем что прийдется напр апдэйтить кучу самопальных контроллеров когда они перестанут работать c mariadb11 а она будет единственным способом держать сервер данных в приличном виде. все разговоры про то что "вот мы сейчас сделаем и больше никогда не будем трогать" очень быстро натыкаются на вал неудобств которые прогресс готовит для таких концепций. я не про то что это хорошо, это данность. как погода.

Готовое решение - raspberry pi. Есть и web server, SQL клиенты, LAN, цифровой ввод, вывод на плате и порты для подключения к кому либо ещё

А у вас, судя по этой фразе, вообще нет этих представлений.
Если что - я много лет проработал в разработке этих самых интеллектуальных счётчиков. Имею представление, что там есть и чего нет. А вот вы - не имеете.
Модбас вообще ни разу не применяется для приборов учёта э/э. Курите DLMS/COSEM.

Если в счётчиках чего-то нет, то это не потому, что их разработчики чего-то не умеют, а потому что нет заказчика хотящего данный функционал. Серьёзного заказчика, подтверждающего свои желания соответствующими деньгами. Когда такой заказчик появляется, я вас уверяю - конторы разрабатывающие эти счётчики идут ему навстречу. Уж каких только странных хотелок не приходилось реализовывать в этих самых счётчиках. Но кто платит - тот и заказывает бал.
Т.е. - раз какого-то функционала нет, то он и не нужен.

И многие конторы, выпускающие счётчики, продают их вместе со своим ПО в составе системы АСКУЭ. И уж в базы данных эти системы умеют писать. Кроме всего прочего.

Добавлено after 5 minutes 2 seconds:
Счётчик электроэнергии - это в первую очередь СИ (средство измерения). Прошедшее сертификацию по многим параметрам. А не показометр с лампочками, не пойми что показывающий, показания которого никто не будет воспринимать всерьёз.
И шифрование в нём - далеко не самое сложное. Очень далеко....
А ТС - дилетант, не шарящий в вопросе.

Добавлено after 14 minutes 54 seconds:


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