IoT разработка

Решил побаловаться разработкой IoT (и реализовать некоторые решения для своего дома), выбираю плату и немного запутался. Мне, как .NET разработчику, наверное лучше остановиться на netduino, т.к. на него ставится .NET micro и можно программировать сам контроллер на привычном для меня C#, что не позволит популярный Arduino (как я понял) и т.д. Как быть с датчиками, они же совместимы?

У кого есть опыт такой разработки?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Коли я жартував про Асемблер і веб не думав що є люди які таким займаються, навіть заради фану: habrahabr.ru/post/318916

Тю, тут на ДОУ пасётся наш украинский Televendor (ukr.nodes — привет!).
lurkmore.to/Жо-Па

Google надав можливість писати на Java для IoT:
android-developers.googleblog.com/...e-and-android-things.html

habrahabr.ru/post/318296

Не взлетит, как не взлетело android auto. Одно дело барыжить телефонами для домохозяек, совсем другое предоставлять платформу, где нужно писать драйвера и следить за всеми ньюансами работы системы.

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

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

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

Сейчас скатимся в холивар =) Я пас.

рекомендую прочитати:
catethysis.ru/arduino-vs-stm32
geektimes.ru/post/255760

тут я із вами погоджуюсь, але статті зовсім не про це.

Перефразовуючи статтю можна сказати так:можна зрозуміти людину яка вивчала електроніку та програмування в університеті, зробила багато зусиль щоб дізнатись як це все працює, піднятись до професійного рівня, а люди яки помигали світлодіодом (як правило поняття не мають як це все працює, не кажучи вже про основи електроніки) на Ардуіно починають вважати себе гуру і починають агітувати інших)

Отож. Склепать MVP по бырику, провести питч для инвестора, и го в гринбар пить смузи -вот это ниша для ардуины. Правда я больш наблюдаю другое: пропить бабло на смузи, потом нанять дядю/тетю для клепания MVP, попытатся прокинуть его бабло, показать инвестору кривой MVP, ну потом рассказать что инвестор уже не тот, и эт не Кремниевый Яр, а ардуино не торт.

я думаю «Ардуінщики» не можуть скласти серйозної конкуренції, навіть при всьому їхньому бажанні)

Ну как простое, матлаб он код генерит для ардуины, ну это так для общего развития, www.mathworks.com/...pport/arduino-matlab.html
Правда вот это заиграло по новому?

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

Ардуино (как и наверное Nucleo) конечно больше подходит для сборки проекта на коленке (хотя сам я предпочитаю самостоятельно развести и изготовить плату), плюс ко всему для программистов удобно, не нужно там заморачиваться сильно с регистрами и тд... С колокольни электронщиков это конечно же игрушка. Особенно доставляют проекты управления станком например, на базе Ардуино, шилда и беспаячной панели с кучей натыканной вермишели. PS: кстати видел коммерческие проекты, разработанные в mBed;

Он бы уж определился составят они ему конкуренцию или нет.
Когда-то давно попалась мне вакансия. Дописывать/улучшать софт для кофейного автомата. Кофейный автомат был сделан на Ардуинке. Причины выбора ардуинки были следующие: информации по ардуинкам много, ардуинщиков тоже много, стоят они дешевле.
Сплошная экономия ))). Так что, возможно, у чувака не зря пригорает. Что-то чуствует :-D

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

Там в основном автоматизируют квесты Ардуинами, так что не только вендинговые автоматы.

Кофейный автомат был сделан на Ардуинке.

На самой плате, или просто на AVR? Для кофейного автомата AVR вполне логичный выбор, более логичный чем ARM/STM32. Использовать Arduino для разработки/отладки тоже вполне логично.

Вообще чаще встречал в промышленных устройствах PIC или MCP430.

Если чесно то железа не видел. Хватило информации о том, что работать прийдется с Arduino environment (IDE, библиотеки и отэтовотвсе)

Нет конечно. Работа с этой херней меня никак бы не продвинула вперед в навыках. Нафейхоа мне такое надо?

Так бабоса ж меньше давали. Потому что ардуинка.

А не нравиться тебе такое, укро-индусы тебя порвут.
will see
IDE
 Да, как посмотрел в первый раз на енто чудо, то потом гдет часа 2 думал про «как можно сделать настолько прекрасное» при живом и доступном Эклипсе

Ну тут лучше прикрутить Ардуину к Atmel Studio и там уже работать.

Ну по мне так даж нотепад++ лучше чем родное ардуинопроизведение. А атмел студио это ж самолет.

Смотрю на этот тред вот так — o.O

Ну чтоб поиграться я вообще использовал FlowCode.

+ ардуіно є те що там вже готовий бутлодер, і не потрібно програматора.
цю властивість я використовував щоб працювати з Atmel Studio.
Atmel Studio + Arduino = чистий С код, в зручному середовищі (обходжусь без їхніх бібліотек). Заливка hex в Ардуіно через XLoader:

embedded.co.ua/...rduino-plus-atmel-studio

Смотря какой автомат. Если офисный настольный, то вполне ОК. Если массового c тач-скрином и телеметрией, то ARM/Linux гораздо сподручнее.

Не в целях рекламы, лучше взять к примеру PinBoard и колбасить там на C в чудесной Atmel Studio, а с шилдом STM32 например в KEIL (там удачный отладчик). Без отладчика в электронике очень тяджко...

Мені більше подобалась AVR Studio 4.16 — зручний дебаг, все «літає»,

Atmel Studio,
 — стала монстром, набагато повільнішим, який «їсть» багато пам’яті (як дискової так і оперативки).

Ну мне после VS, естественно AS стала казаться классной IDE, но тормозит, Вы правы. В AVR Studio особо не работал, работал в CVAVR (поучился там, плюс мастер настроек нравится) но дебаггер там хорош!

Кстати с RPI баловался, прикручивал к нему промышленный частотный преобразователь www.youtube.com/watch?v=5uCV_gNWw2Q .

Попробуйте STM32 Nucleo, это подобие Ардуино, только с 32 разрядным микроконтроллером и совместимость шилдов. Ну и Raspberry Pi конечно, я на этой штуке дома автоматизировал отопление и собрал прототип контроллера системы полива деревьев с которого собирали статистику в облако.

Я роблю так: Кінцеві контроллери Arduino nano + Ethernet шилд (не заради реклами aliexpress.com/...ino-Nano/32664329422.html )
Головний «мозок» — одноплатний Cubietruck з Armbian-ом на борту. Все заведено в тупий свіч.
Переваги бачу для себе наступні: живлення до кінцевого контролера (датчиків, реле... ) можна подати по тому ж ethernet кабелю, що і дані, для обміну данними використовую звичайні і зрозумілі http запити з json (можна додати шифрування або елементарні ключі або навіть ssl для маньяків).
Логіку і інтерфейс можна писати на чому зручно. У мене цілком нормально працює демон на звичному мені PHP + MySql хоча проситься Node.js
Інтерфейс web з усіма зручностями :)
ESP8266 звісно цікаво, але якось стрьомно як на мене.

tl;dr comments
imho:
esp8266 (espduino) + rpi 2 (+wi-fi) / rpi 3, что бы немного разгрузить rpi можно использовать отдельный роутер, к которому будет это все счастье коннектиться
c++ — для arduino
python / bash / c++ — на выбор для rpi,
на крайний случай nodejs, можно и java, если хочется извращений и религия позволяет :)
.net совершенно не для этих задач

.net совершенно не для этих задач

но Майкрософт его туда портирует же почему-то, значит планирует подружить :)

да они во многие места лезут :)
можно посмотреть еще в сторону intel edison + arduino — «не работал, но осуждаю» ©
по отзывам друзей — убогая вещь, множество проблем было с передачей данных (года 2 назад, возможно уже и поправили что-то)

для ардуины куча библиотек уже написано на c++ и аналогично для rpi на питоне и на ноде

да они во многие места лезут :)
і після цього продукт стає набагато гіршим (: Skype яскравий приклад...

у МС действительно какие-то траблы с пользовательским софтом. А их видение удоства вообще такое чувство, что проектировалось инопланетянами (один mp3 плеер zune чего стоил, чтобы залить музыку — надо было через чудо-софт синхронизировать). А вот в серверных платформах и средствах разработки им, по-моему, нет равных

А вот в серверных платформах и средствах разработки им, по-моему, нет равных
Лолшто?

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

Да куда уж там ее разгружать, там ресурсов достаточно. Главное — это питание! Необходим достаточно мощный источник питания на 5 Вольт, особенно если если будет Wi-Fi Dongle (для RPi B+, II) и/или дисплей.

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

Можете подивитись в сторону stm32. Бавився з stm32f3 . На це все сімейство можна запустити .Net micro

После чуть более глубокого знакомства с предметом я так понял, что есть, грубо говоря, 3 пути:
1. Ардуино с си-подобным языком
2. Нетдуино с .NET Micro
3. Raspberry PI и что-то подобное с урезанной версией Windows 10

Теперь пытаюсь понять преимущества и недостатки по каждому из пунктов
Как я понял, с ардуино и нетдуино совместимые между собой и дешёвые датчики/борды, для распберри вся периферия другая. Но Распберри это по сути уже готовый мини-компьютер, способный работать автономно с сетью и т.д., т.е. я могу на .NET написать прикладное приложение, которое там будет само заниматься анализом/заливкой в облако и прочим...

датчики, що для ардуїно, що для распбері ті самі. У вас там і там є GPIO, датчикам всерівно куди посилати\приймати сигнал. Тут більше залежить від вашої задачі

можна зробити наступним чином
STM32, PSoC , Arduino для роботи з різними сенсорами, далі ці дані передаємо на Raspberry Pi (вибираємо зручний інтерфейс — UART, I2C, SPI), на Raspberry Pi — з`єднуємо з інтернетом, і при бажанні використовуєте Windows 10 IoT з C# . Таке рішення якщо датчиків багато, якщо ні достатньо тільки Raspberry Pi

А навіщо тоді Ардуіно потрібно? Щоб більше геморрою було? ;)
Розумію те, що ще не розумію задач, які виконує кожен з модулів.

стоїть распбері як сервер. має вихід в інет. А в кінці іншої кімнати ардуїно з датчиком. ардуїнка знімає дані з датчика і посилає їх по WiFi чи блютус на распбері(можна і іншим способом). Просто підключити датчики, напряму до распбері можна. Але якщо відстань велика — гєморно

як я розумію, я роблю вузел з ардуіно, на цей ардуіно чіпляю декілька датчичів і wi-fi модуль і програмую його таким чином, щоб він відправлял дані на распберрі, а на распберрі вже повноцінна прикладна програма, яка завантажує ці дані на облако?

повністю так.
Ще є цікавий комплект NodeMCU. в нього wifi і достатньо потужності щоб вебсервер підняти чи передавати дані в хмару. і ціна копійчана

Wi-fi модуль краще підключити до распбері, там із ним легше буде працювати. А арудіно до расбері через

UART, I2C, SPI
або BLE , Bluetooth.

якщо Аrduino + WiFi то вже краще esp8266 — вона підлючиться до вашого wi-fi роутера і через нього в інтернет на потрібну адресу надсилатиме дані., тоді Распберрі не потрібне.

Ардуіно
 — потрібно якщо багато датчиків. Із датчиками набагато простіше працювати на мікроконтроллері. але знову ж таки, все залежить які у вас датчики і скільки їх є. на Raspberry Pi простіше писати прикладні програми.

по идее, можно вообще стационарный комп вместо Raspberry Pi использовать в таком случае?

У вашому випадку так, залишилось тільки подружити стаціонарний комп’ютер із датчиками, а для цього без мікроконтроллерної плати не обійтись. Потірбно буде STM32, Arduino, або щось подібне.

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

тоді без проблем можете замінити распберрі на звичайний комп.

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

А если датчик понавороченнее будет?

Вообще я, как дотнетчик, привык к тому, что за простой семантикой языка ещё кроется фреймфорк, с его особенностями. Потому как тот же C# простой как двери, но за ним стоит фреймворк и понимание его работы как раз и важно, иначе и обезьяна может на дотнете формочки клепать. Так и с любым *дуиновским языком — я уже подсознательно предполагаю, что понимание простого кода ещё не значит понимание вообще :)

простота Arduino дозволяє працювати із ним всім, включаючи гуманітаріїв. Щоб запустити на ньому щось вам не обов"язково влізати в тонкощі роботи з переферією, писати і читати в регістри.

може глянути в сторону PSoC — тут більшість всього конфігурується в GUI, далі генеруються API функції які вже використовуєте. Також не потрібно заглиблюватись в тонкощі заліза.

www.cypress.com/...rm-cortex-m0-based-psoc-4
embedded.co.ua/psoc-kurs-vstup

А если датчик понавороченнее будет?
в PSoC та Arduino дуже розвинуті спільноти, де можна знайти відповіді на біьшість запитань.

Озвучьте что в итоге получить хотите. Тогда будет проще платформу подобрать.

Хочу 2 вещи:

1. Хочу натыкать кучу датчиков, анализировать информацию, пришедшую от этих датчиков и на основе этой информации (за какой-то период) выполнять какие-то действия (включать какие-то девайсы или уведомлять по почте, не столь важно). В идеале, чтобы эта система была автономна, в крайнем случае — часть задач выполняет домашний комп.

2. Хочу собрать девайс, который собирает информацию с 2-х датчиков и заливает их в облако, а также может вытягивать данные из облака (собранные ранее) и выводить их на устройство вывода.

найпростіше використати якийсь Single Board Computer (BeagleBone Black ,Raspberry Pi, Onion 2,...)

також можете ознайомитись із Blynk:
www.blynk.cc
play.google.com/...details?id=cc.blynk&hl=uk

1. Возьми какой-нибудь роутер пожирнее и прошей его OpenWRT.
Получишь нормально корпусированый сингл-боард с предустановленным Линуксом.
2. Коннектишь к нему вайфайные датчики.
3. Пишешь нужную тебе бизнес-логику.
4. Профит.

Почему я так цепляюсь за .NET — я просто .NET разработчик и мне он интересен. При желании я напедалю код хоть на С, хоть на питоне, но мне это не доставит удовольствия. Т.к. эта другая технология. Поэтому не хочу ни линукс, ни возиться с какими-то языками, характерными только для этого девайса.
Твой совет возможно очень даже хорош, но только мне он не подходит :)

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

Ничего, что .NET немножко не для этих задач?

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

тоді

Raspberry pi 3 + windows 10 IoT
найкраще що вам підійде.

«А где потерял?».
«В парке».
«А зачем здесь ищешь?».
"А здесь светлее ".©
Впрочем возможно такой подход практически продемонстрирует техническое убожество Майкрософта.

да это ж анегдот ))) чувак выучил немного сишарпа и думает что на нем можна программировать все что он захочет ))))

да-да, выучил синтаксис и считаю себя гуру

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

По-хорошему, там вообще нужно писать на ассемблере, но пишут на Си. Потому что его достаточно, пусть и страдает эффективность кода. Точно также и с .НЕТ, пусть он громоздкий и ненужный для таких примитивных задач, но для меня это:
1. попытка увидеть его потенциал (возможность, пусть и неэффективно, работать в таких ограниченных условиях)
2. посмотреть на .НЕТ в минимизированной версии. Его «настоящее» ядро, т.е. только то, что ’must have’
3. для меня это инфраструктура, возможно даже какие-то расшаренные наработки с проектами, не касающиеся IoT

А что мне даст то, что я заюзаю линукс? Или ты думаешь, я не знаком с линуксом? Я Х лет назад побаловался этим линуксом, изучил его в какой-то степени и остыл к нему. Мне он неинтересен. Точно также с Си-подобными языками, специфичными для какой-то *дуино платформы. Я буду тратить на это время и меня не будет покидать ощущение, что я занимаюсь неинтересной мне хернёй и трачу своё бесценное время. Т.к. я не хочу дальнейшую жизнь связывать с линуксом/питоном и т.д., понимаешь?

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

Я не буду спорить про популярность винды/линукса, просто моя ниша — это .НЕТ и пока что я её менять не собираюсь. Я прекрасно понимаю, почему .НЕТ в IoT лишний (ещё бы, целый фреймворк), я не стремлюсь в ИоТ покорять высоты, я просто хочу... Да я выше уже написал, чего я хочу :)

По-хорошему, там вообще нужно писать на ассемблере, но пишут на Си.
це не правда, де треба написати на асемблері пишуь на асемблері, це як правило асемблерні вставки в С код. Під Cortex M уже ніхто не пише на чистому асемблері. Самі виробники чіпів дають С — ні бібліотеки.

“C was originally developed by Dennis Ritchie between 1969 and 1973 at Bell Labs,[5] and used to re-implement the Unix operating system.”
en.wikipedia.org/.../C_(programming_language

По-хорошему, там вообще нужно писать на ассемблере, но пишут на Си. Потому что его достаточно, пусть и страдает эффективность кода.

Это вы очень большую глупость написали.

Почему? Неужели пересичный Сишный компилятор лучше скомпилит, чем ручками написать на ассемблере?

Да. Они сейчас умные.Только компилятор времени потратит на все это гораздо меньше чем пересичный разработчик. Ну и для понимания в целом. Представте что вы писали на asm для Cortex M0/M1. И вдруг понадобилось сменить чип на Cortex-M3/M4. Предпосылки могут быть разные. Например нужно добавить новый функционал (например криптографию. А у M3/M4 есть аппаратный криптомодуль) Или чип старшего семейства стоит дешевле чем младшего (и такое бывает).
А теперь посмотрите вот на эту картинку.
www.lpcware.com/...s/1100969_Cortex-Inst.jpg
И что вы со своим оптимальным asm кодом делать будете?

Ну, я никогда особо не интересовался компиляторами и почему-то был уверен, что «аккуратнее», чем человек, ассемблерный код никто не напишет. Вижу, что ошибался

таке ще було можливим на 8-х мікронтроллерах, зараз час 32-них (Cortex M, A, R), для них це вже не актуально

не повірите, але так

Почему, поверю
Тогда ассемблер вообще ушёл со сцены, т.к. всегда можно налабать на Си?

думаю ассемблер не піде ніколи, дуже корисно знати асемблер для при відлагодженні програм.

також в С-й код роблять асемблерні вставки, в критичних місцях програми. Більшість операційних систем реального часу (RTOS) використовують такі вставки в апатно-залежних місцях, наприклад, в перериванні таймера відбувається переключення контексту потоку на асемблері. Тобто С код викликає асемблерний,

SysTick_Handler ; 1) Saves R0-R3,R12,LR,PC,PSR
CPSID I ; 2) Prevent interrupt during switch
;YOU IMPLEMENT THIS (same as Lab 2)
PUSH {R4-R11} ; 3) Save remaining regs r4-11
LDR R0, =RunPt ; 4) R0=pointer to RunPt, old thread
LDR R1, [R0] ; R1 = RunPt
STR SP, [R1] ; 5) Save SP into TCB
PUSH {R0,LR}
BL Scheduler
POP {R0,LR}
LDR R1, [R0] ; 6) R1 = RunPt, new thread
LDR SP, [R1] ; 7) new thread SP; SP = RunPt->sp;
POP {R4-R11} ; 8) restore regs r4-11
CPSIE I ; 9) tasks run with interrupts enabled
BX LR ; 10) restore R0-R3,R12,LR,PC,PSR

а асемблерний (BL Scheduler) С-ну функцію

void Scheduler(void)
{
// every time slice
// ROUND ROBIN, skip blocked and sleeping threads
RunPt = RunPt -> next;
while((RunPt -> sleep)||(RunPt -> blocked))
{
RunPt = RunPt -> next;
}
}

Если сишный компилятор генерит код не хуже рукописного ассемблера, то зачем тогда ассемблерные вставки?

це робиться для того що С -код одинаковий на всіх платформах (у випадку RTOS) — аплікаційний рівень, а асемблерний унікальний для кожного мікроконтроллера. Компілятор генерує нормальний код для складних речей (матиматичні функції, різні розрахунки)
асемблерні вставки це всього кілька рядків коду, де людина зробить краще за компілятор.

Тобто в межах цілого проекту краще писати на С, а дуже специфічні речі (їх не дуже багато) на асемблері для найращої оптимізації роботи. таке робиться не часто.

А компилятор, скомпилированный ошибочным компилятором?

Просто для справочки, мануал по архитектуре Intel Haswell имеет 4600 страниц жёсткого чтива, ты уверен, что сможешь разложиться команды так, чтобы они эффективно выполнялись без простоя? Думаю, что это уже нереально сделать в голове за разумное время. А компилятору вполне по зубам.

В данном случае вопрос не в том, сможет ли человек/группа людей в принципе, а в том, генерит ли компилятор лучше код, чем способен создать человек

В этой задаче, если человек ее грамотно поставит, компьютер посчитает быстрее, чем человек.

вот это я имел ввиду, когда сказал, что оптимальнее всего писать на ассемблере (я уже понял, что си-компиляторы вполне могут создать лучше), парируя «нафиг тебе .НЕТ, пиши на Си»

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

При такой целевой функции человек окажется эффективнее компилятора.

т.е. всё-таки си-шный компилятор не создаст идеальный код? Я просто не знаю особенности создания компиляторов, могу только предположить, что есть математическое обоснование для этого (или нет).
Вот это я и имел ввиду, когда меня тыкнули в .НЕТ, мол пиши на Си, что в идеале нужно писать на ассемблере :)

Вот это я и имел ввиду, когда меня тыкнули в .НЕТ, мол пиши на Си, что в идеале нужно писать на ассемблере :)

С розроблявся низькорівневим щоб працювати із залізом напряму, він призначений для цього, а .Net ні. Тому ваше порівняння не зовсім коректрне.

Ваше твердження схоже " в ідеалі треба писати сайти на чистому HTML"....

Я это всё прекрасно понимаю :)
Зато будет ощущение, что занимаюсь своей технологией, а не трачу впустую время на изучение нового, с чем не собираюсь связывать свою деятельность в дальнейшем

Зато будет ощущение, что занимаюсь своей технологией
, це тільки ілюзія... Але це ваше право.

із власного досвіду, мені треба було зробити програму для Android для роботи з Bluetooth. Оскільки це був разовий проект, і знаючи Python вирішив написати таку програму на ньому. Для цьогго вибрав Kivy, кілька днів мучився із ним, нічого хочошого не вийшло, то одне не працювало, то інше.

Вирішив все зробити на Java, якої в загалі не знаю, знайшов приклади роботи, вдалося зробити мою програму.

А міг і далі мучитись з Python, а не використвовувати Java — "

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

Ну, человек четко описал что он хочет «натянуть сову на глобус». И, опять же, четко обозначил что понимает последствия данного решения. Но все равно будет писать на .NET. Смысл его дальше переубеждать?

В любом случае, мне интересно читать про глубину этих самых последствий. Может, если уж совсем ж*па, то и передумаю :)

Будь який досвід — це досвід! :) Успіхів Вам!

На тему C та Assemblera: habrahabr.ru/post/317078

Чудесный алгоритм сортировки, который виснет на отсортированных данных.

Тут есть ньюанс: в таких проектах 80-90% работы — собрать внятное железо и добиться чтобы оно работало 24/7 (надежность будет главной проблемой если не делать плату под сенсоры). Поэтому начинать надо с железа, потом смотреть что с ним хорошо работает, и где-то в конце уже подстраивать PC стек под то, что получилось. В данном случае знание .NET — незначительная деталь, это как выбирать ноут под запасной аккумулятор, который случайно завалялся дома

Поэтому начинать надо с железа, потом смотреть что с ним хорошо работает,

А что, Распберри плохое железо?
Я никогда с подобными вещами не сталкивался, для меня сейчас всё железо «одинаковое» по надёжности

Распберри сама по себе — не супер (много тратит, сильно греется, легко убивается статикой) — но для начала сойдет. Настоящая проблема в другом: чтобы подключить к ней, допустим, 5 датчиков, нужно протянуть 20 проводов. Если каждый провод будет макетным со штекером — то система будет работать только на столе и когда рядом никто не ходит. Придется паять на макетке для пайки. Если провода нужно будет протянуть больше чем на пару метров, а для высокоскоростного интерфейса — десятка сантиметров, то начнутся проблемы с сигналом, надо будет ставить буферы, а это тут уже надо делать свою плату. Если датчик требует много тока (как большинство датчиков газа например) — то нужно сделать отдельную схему питания, распберри не вытянет.

Потом, когда захочется работать с сервами, придет понимание что если система не может выдать импульс управляемой длиной от 1000 до 2000 микросекунд с точностью не хуже чем ±10 микросекунд — то нафиг не нужна такая система. На этом отваливается и Распберри (там очень скудные возможности), и, подозреваю, .NET.

что значит пару метров? Я хочу раскидать датчики по всему своему подвирью :)

Тогда без радиосвязи никак. Могу порекомендовать связку ардуино + nrf24L01 на каждую ноду, стоит до $5, программируется легко и приятно. На открытой местности говорят можно до 100 метров связи получить, проверял — работает через три бетонные стенки. Главный плюс — не нужно тянуть провода. Единственная проблема — надо освоить ардуино по готовым примерам (есть библиотечка специально для нрф24, и примеры которые делают более-менее то что надо).

Від себе добавлю, працював колись із радіомодулями Synapse, вони дуже прості в програмуванні — використовується Python. Якщо цікаво можете більше дізнатись тут:
embedded.co.ua/...diomoduli-synapse-theory
embedded.co.ua/...moduli-synapse-prakty-ka
єдиний мінус, як на мене трохи завищена ціна.

також можете ознайомитись із Zigbee, але це скадніше за Synapse

Сорян, я чуть-чуть знаю о чем говорю. Во-первых $5 это включая ардуинку. Сам по себе модуль стоит доллар с копейками. И он у меня давал стабильный 1 мбит в радиусе 30 метров (_без_ повторов пакетов и даже без CRC) при том, что находился в 10см от земли на роботе с большими искрящими движками, и в 10см от другого радиомодуля, который каждые 7 миллисекунд отправлял запрос на ToF одному из 6ти маяков вокруг.

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

Парни из Nordic Semiconductors действительно умеют делать хорошие радиочипы. Если купить их оригинал, а не китайскую подделку — то будет работать как по даташиту. Другой вопрос что по этому запросу можно найти модуль с большой каплей смолы на месте чипа — вот те да, работать ниоч будут.

z-wave не дошли руки попробовать — я проверял модули в порядке улучшения соотношения цена/характеристики ))

С дефолтными настройками там стоит меньше скорость, повтор пакетов если не подтверждено получение, и включен CRC — это все приводит к тому что практический битрейт падает до десятков кбит, но сильно растет надежность. Через стенки он именно в таком режиме работал, на 1мбите без повторов и контроля отвалился бы раньше

Вобщем под инструмент выбираем задачу.
Тогда можно скреативить так:
1 В качестве гейта в интернет можно использовать Распберри. Mono на нем работает, поэтому свои приложения сможете писать на .Net
2 На этом же распберри подымаем Wi-Fi точку доступа (если необходимо)
3 В качестве контроллеров для сбора данных с датчиков используете Netduino либо что-то подобное + Wi-Fi шилд (да, ESP8266 обойдется дешевле, но ANSI С не подходит по условиям задачи)
4 Контроллеры гонят данные по Wi-Fi либо на домашний роутер либо сразу на распберри (если поднята точка доступа).

P.S: Получился отличный пример как НЕ надо проектировать системы сбора данных ))

P.S: Получился отличный пример как НЕ надо проектировать системы сбора данных ))

почему, что тут не так в проектировании кроме чрезмерного уклона на .НЕТ?

Недостатки:
1 .Net вносит сильный оверхэд. Невозможно спрогнозировать насколько стабильно будет работать система.
2 Wi-Fi (частота 2,4ГГц + мощность. Если контроллеры будут с батарейным питанием, то Wi-Fi будет порядочно жрать батарейку)
3 Топология «звезда». Чту будем делать если мощности Wi-Fi недостаточно? Например зимой работает, весной и летом — нет. Поскольку на деревьях появились листья, которые начали поглощать радиосигнал (не забываем про 2,4 ГГц). Опять же что будем делать если надо добавить пару сенсоров.

Как бы я делал для себя.
1 Взял какой-то мелкий low-power микроконтроллер и воткнул бы туда 6LoWPAN стек и субгигагерцовый радиомодуль. Если хочется писать красиво и с операционкой, взял бы вот эту www.contiki-os.org
2 Благодаря 6LoWPAN получил бы mesh топологию (а не звезду) и с маштабируемостью системы и мощностями сигналов вопросов бы не было.
3 Граничный маршрутизатор воткнул бы в домашнюю сеть и через него пробросил бы данные куда нужно.

Ну так обычно никто не заморачивается ))

2 Wi-Fi (частота 2,4ГГц + мощность. Если контроллеры будут с батарейным питанием, то Wi-Fi будет порядочно жрать батарейку)
3 Топология «звезда». Чту будем делать если мощности Wi-Fi недостаточно? Например зимой работает, весной и летом — нет. Поскольку на деревьях появились листья, которые начали поглощать радиосигнал (не забываем про 2,4 ГГц). Опять же что будем делать если надо добавить пару сенсоров.

как-будто вариант без .НЕТ эту проблему решит :)

А что за железяки?
6LowPAN — это стек. en.wikipedia.org/wiki/6LoWPAN

Если говорить о железячках (и о нежелании делать/паять свои платы), то собрал бы что-то типа такого (страница 10) www.st.com/...lations/en.DM00255309.pdf

Если с платами заморачиваться охота, то можно сделать радиошилд (например на СС1120) и шилд с сенсорами для тех-же ultra-low-power nucleo www.st.com/...criteria=productId=LN1847

Ну или целиком контроллер скреативить.

вот это ответ настоящего виндовс сеньйора — ну хочу ни линукс ни возится с другими языками

якщо С# то Raspberry pi 3 + windows 10 конект до інтернету через Wi-Fi або Ethernet
developer.microsoft.com/...us/windows/iot/getstarted
blogs.windows.com/...pi-3/#LTADYH7O5qXpMxvm.97

ось ще один варіант (замовив собі такий):
www.kickstarter.com/...th-wi-fi-powered-by-linux — але тут С/С++

C# для Netduino, Arduino і подібного це те саме що писати під веб на С, можна, але не треба.

маєте досвід в комерційних проектах для

Raspberry pi 3 + windows 10
?

ні

если реально что-то хочется сделать — то выбирать плату нужно по другим критериям и сразу смириться C. ну максимум, можно задуматься о Питоне ибо он с С хорошо дружит

Если АRM, то еще Go неплохо заиграет.

Ай-Ай, ну зачем так пукать людям в лицо? Вы б еще про rust/D вспомнили.....

Вероятно можно, не уверен в наличии кросс-компиляторов.

А как же ESP8266 ? тут тебе и контроллер, и вайфай модуль, и 160 МГц тактовая частота, даже ртос есть. Но тут опять же Си, но в извращенном его понимании — работать по калбэкам.
Ну или NodeMCU и подобные решения на тойже ESP8266

Заодно хотілося б щоб ще порадили платформи на яких можна створювати робочі рішення, а не тільки прототипи як наприклад Arduino.

Можливо в когось є практичний досвід з STM32?

Да, отличное семейство, библиотеки HAL позволяют писать код под разные их чипы с минимальными изменениями. У нас редкий проект без них обходится.
Но чтобы прямо платформа для рабочих решений — не знаю такой. Всегда делаем плату под конкретную задачу, так меньше по размеру, экономнее по питанию, и надежнее выходит

Працював з STM32, пізніше з Tiva C (TM4C123G ) від Texas Instruments. Бібліотеки для роботи з переферієї сподобались більше в Tiva C, як на мене набагато логічніші та простіші ніж в STM32.

приклад, мигання ледом:
Tiva C:

int main(void)
{
ROM_SysCtlClockSet(SYSCTL_SYSDIV_4|SYSCTL_USE_PLL
|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);

//enable clock for PORTF
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);

//initialization pins as output
ROM_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, LED_RED_PIN);

while(1)
{
GPIOPinWrite(GPIO_PORTF_BASE, LED_RED_PIN, LED_RED_ON);
SysCtlDelay(3000000);

GPIOPinWrite(GPIO_PORTF_BASE, LED_RED_PIN, LED_RED_OFF);
SysCtlDelay(1500000);
}
}

STM32:

int main(void)
{
GPIO_InitTypeDef GPIO_LED;

//enable clock for PORTD
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);

GPIO_LED.GPIO_Pin = LED4 | LED5;
GPIO_LED.GPIO_Mode = GPIO_Mode_OUT;
GPIO_LED.GPIO_OType = GPIO_OType_PP;
GPIO_LED.GPIO_Speed = GPIO_Speed_100MHz;
GPIO_LED.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(LED_PORT, &GPIO_LED);

while(1)
{
GPIO_ResetBits(LED_PORT, LED5);
Delay(1000);

GPIO_SetBits(LED_PORT, LED5);
Delay(1000);
}
}

Одно и то же. Не вижу никакой разницы. В первом случае все доп. настройки скрыты в функции ROM_GPIOPinTypeGPIOOutput — а значит либо доп. возможностей просто нет, либо для их настройки есть еще куча функций. Во втором случае все доп. настройки задаются в явном виде.
Еще вы не использовали HAL и stm32Cube — сейчас весь код настройки периферии в стм32 генерируется автоматически.

використвовува перші версії

stm32Cube
не сподобалось, може зараз все на багато краще, з STM32 працював десь 1.5 роки тому...

В Tiva C є цікаве рішення, функції прошиті в память, тобто можна задати при завантаженні в мікроконтроллер всі функції викликаються з EEPROM і не використовують флеш:
we.easyelectronics.ru/...d-funkcii-v-tivaware.html
embedded.co.ua/...nchpad-zagal-ny-j-oglyad

Все, что дальше прототипа требует хороших знаний правильной разводки печатной платы и навыков пайки. Потому как таже STM32 довольна «хрупкая» вещь при монтаже. Или брать готовые борды от ST.

Можете спробувати рішення від Cypress, ще простіше і зручніше за ардуіно, але набагато гнучкіше і потужніше: dou.ua/forums/topic/17973

спочатку на кітах (не важливо, Arduino, STM32,....) збирається прототип (за умови що проект не дуже складний).

якщо все працює, відбувається розробка плати, таких плат робиться всього кілька штрук — це перші прототипи. На них відбувається налагодження. Всі нюанси баги враховуються, баги випраяють тестують, після цього йде розробка наступної версії прототипу. Таких ітерацій буває кілька, з особистого досвіду( в цій компанії так відбуваються процеси www.pdt.com ) , найбільше це було 4, після цього пристрій йде в серійне виробництво.

Под ардуино я часто видел node.js, так как удобная событийная модель. Но никто не мешает использовать нормальный embedded C. Учтите, что ардуина это часто только прототип и не стоит привязываться к специфичным вещам ардуины. Если нужна переносимость, то советую писать на сях и не насиловать платформу с .NET mircro/Java/Node.js/Python.

колупаться в сях не очень горю желанием (особенно если будет что-то более сложное, чем светодиодный индикатор), хочу именно на .NET micro

Скажу честно, что я только читал про .NET Micro и не пробовал его, но у меня есть большой опыт разработки устройств на STM8/32 (и вообще электроники и отладочных плат), и я знаю/пишу на .NET где то на уровне между джуном и мидлом. И мой опыт говорит мне следующее: если будет что то более сложное — НУЖНО будет делать это на Си :-)
Микрофреймворк несколько тормознутый для работы с выводами общего назначения (GPIO) и т.п. Включить двигатель, моргнуть светодиодом, отправить данные по WiFi пожалуйста, но если на контроллере крутится много быстрых задач, думаю тут будет затык. Кроме того, плата для .Net Micro требует кажется около 350кБ Flash памяти, чтобы развернуть там .NET. Для сравнения, наиболее полпулярные ардуинки (а в реальности AVR ATMEL микроконтроллеры) имеют 8-32кБ. Платы получаются дорогие, много потребляющие (если интересует автономность изделия), и в общем навороченные. Это как из пушки по воробьям стрелять

Подписаться на комментарии