Сначала возникла задача сделать GPS-трекер с биометрической авторизацией владельца — ну, чтобы было понятно, что этот трекер сейчас носит конкретный человек, а не какой-нибудь другой человек или его вообще не бросили валяться. По отпечатку пальца, понятно, до скана радужки глаза, как в кино, мы нескоро ещё дойдём.
Взяли китайский модуль с датчиком отпечатков R300 — это платка с собственно сенсором FPC1020AM на гибком шлейфе и процессором. Сенсор тупой, он просто отдаёт картинку, вся логика обработки живёт в процессоре. Процессор китайский, прошивок нет, общение командами по UART.
На основную плату поставили STM32L1 + SX1276, ну и в общем прототип получился быстро и страшно, толстый и с отваливающейся китайской платой
Изучение рынка показало, что есть несколько контор, которые продают алгоритмы распознавания пальчиков, которые можно было бы положить в свой процессор, прицепив к нему сенсор, тот же FPC1020. Одна проблема — конторы эти хотят примерно от 50 тысяч евро за лицензию на библиотеку, и работу её при этом гарантируют только на STM32F4, который слишком много жрёт, чтобы использовать его основным процессором.
Начали думать, что делать. Мы нашли, купили и выдрали прошивку из китайского модуля на GD32F105 — с мыслью, что уж лучше его в пару к STM32L1, чем дорогущий F4 и лицензию за 50К, заказчик стал писать свой алгоритм распознавания пальчиков.
Когда последнее у заказчика начало получаться, он прикинул системные требования — и мы, пошукав по рынку, начали делать прототип на ATSAMD51, который, с одной стороны, более-менее экономичный, с другой, до 120 МГц, с третьей, $4,50, а не как новые STM32L4+. Одновременно заказчик захотел маленький OLED-экран и NFC.
Это, соответственно, была вторая версия. Взлеть ей было не суждено — когда заказчик алгоритм дописал, он оказался настолько хорошим, что влезал в обычный STM32L451CCU6, который и стоит недорого, и ОСРВ наша его поддерживает более-менее, и в целом работать с ним проще, чем с атмелом, хотя бы в силу большей распространённости.
Вот на фоточке — версия на STM32L4, т.е. уже третья.
И всё, казалось бы, шло хорошо, но тут-то стали подтягиваться другие заказчики, которые немедленно возжелали иметь на карточке ещё и BLE — чтобы в помещениях делать зональную навигацию (сотрудник проходит мимо BLE-считывателя — мы знаем, в каком он помещении). И возжелали они это слишком массово, чтобы игнорировать.
BLE у нас имеется в nRF52832, вместо с 64 КБ ОЗУ — из которых минимум 40 КБ надо отдать алгоритму обработки пальчиков, а остального впритык хватает на остальное. Ну ок, за денёк набросали карточку на nRF52832.
И тут один заказчик сказал — а чой-та у вас там 3-осевой акселерометр? А можно 6-осевой гиро? А вам зачем? А у нас алгоритм хитрый. А алгоритм сколько ОЗУ хочет? Сколько?! Да вы там...
Так родилась пятая версия, на nRF52840. 256 КБ ОЗУ, мег флэша, 64 МГц, всё это за $3,90, что в общем вполне нормально. Тем более, остальная часть карточки удешевилась на полдоллара за счёт выкидывания отдельного контроллера NFC — у nRF52840 он встроенный, а на место этого контроллера встал контроллер беспроводной зарядки Wireless Qi. Одновременно антенну LoRa пришлось заменить на керамическую, потому что PCB уже не влезала, а делать многодиапазонную антенну LoRa + BLE и развязывать её между двумя разными чипами как-то очень не хотелось.
Ах да, будет ещё шестая версия. На NB-IoT вместо LoRa. Мы уже даже нашли модуль, который без вазелина влезает на существующую плату. А потом, видимо, и DecaWave подоспеет, для сверхточного позиционирования в помещениях — уже несколько запросов есть.
Так и живём.
Взяли китайский модуль с датчиком отпечатков R300 — это платка с собственно сенсором FPC1020AM на гибком шлейфе и процессором. Сенсор тупой, он просто отдаёт картинку, вся логика обработки живёт в процессоре. Процессор китайский, прошивок нет, общение командами по UART.
На основную плату поставили STM32L1 + SX1276, ну и в общем прототип получился быстро и страшно, толстый и с отваливающейся китайской платой
Изучение рынка показало, что есть несколько контор, которые продают алгоритмы распознавания пальчиков, которые можно было бы положить в свой процессор, прицепив к нему сенсор, тот же FPC1020. Одна проблема — конторы эти хотят примерно от 50 тысяч евро за лицензию на библиотеку, и работу её при этом гарантируют только на STM32F4, который слишком много жрёт, чтобы использовать его основным процессором.
Начали думать, что делать. Мы нашли, купили и выдрали прошивку из китайского модуля на GD32F105 — с мыслью, что уж лучше его в пару к STM32L1, чем дорогущий F4 и лицензию за 50К, заказчик стал писать свой алгоритм распознавания пальчиков.
Когда последнее у заказчика начало получаться, он прикинул системные требования — и мы, пошукав по рынку, начали делать прототип на ATSAMD51, который, с одной стороны, более-менее экономичный, с другой, до 120 МГц, с третьей, $4,50, а не как новые STM32L4+. Одновременно заказчик захотел маленький OLED-экран и NFC.
Это, соответственно, была вторая версия. Взлеть ей было не суждено — когда заказчик алгоритм дописал, он оказался настолько хорошим, что влезал в обычный STM32L451CCU6, который и стоит недорого, и ОСРВ наша его поддерживает более-менее, и в целом работать с ним проще, чем с атмелом, хотя бы в силу большей распространённости.
Вот на фоточке — версия на STM32L4, т.е. уже третья.
И всё, казалось бы, шло хорошо, но тут-то стали подтягиваться другие заказчики, которые немедленно возжелали иметь на карточке ещё и BLE — чтобы в помещениях делать зональную навигацию (сотрудник проходит мимо BLE-считывателя — мы знаем, в каком он помещении). И возжелали они это слишком массово, чтобы игнорировать.
BLE у нас имеется в nRF52832, вместо с 64 КБ ОЗУ — из которых минимум 40 КБ надо отдать алгоритму обработки пальчиков, а остального впритык хватает на остальное. Ну ок, за денёк набросали карточку на nRF52832.
И тут один заказчик сказал — а чой-та у вас там 3-осевой акселерометр? А можно 6-осевой гиро? А вам зачем? А у нас алгоритм хитрый. А алгоритм сколько ОЗУ хочет? Сколько?! Да вы там...
Так родилась пятая версия, на nRF52840. 256 КБ ОЗУ, мег флэша, 64 МГц, всё это за $3,90, что в общем вполне нормально. Тем более, остальная часть карточки удешевилась на полдоллара за счёт выкидывания отдельного контроллера NFC — у nRF52840 он встроенный, а на место этого контроллера встал контроллер беспроводной зарядки Wireless Qi. Одновременно антенну LoRa пришлось заменить на керамическую, потому что PCB уже не влезала, а делать многодиапазонную антенну LoRa + BLE и развязывать её между двумя разными чипами как-то очень не хотелось.
Ах да, будет ещё шестая версия. На NB-IoT вместо LoRa. Мы уже даже нашли модуль, который без вазелина влезает на существующую плату. А потом, видимо, и DecaWave подоспеет, для сверхточного позиционирования в помещениях — уже несколько запросов есть.
Так и живём.
Ох, а как мы отладку с этим D51 покупали...
Полтора месяца и подписание бумажек, о том, что мы обязуемся в оружии массового поражения её не применять.
Полтора месяца и подписание бумажек, о том, что мы обязуемся в оружии массового поражения её не применять.
Чтобы враг не догадался, российский диапазон LoRaWAN официально называется RU864-870 (см. LoRaWAN Regional Parameters 1.0.3a и выше), сокращённо — RU864. По факту занимает он оба безлицензионных российских диапазона — 864,0-865,0 МГц и 868,7-869,2 МГц.
В народе безлицензионный ISM-диапазон при этом известен как 868 МГц, хотя вот именно 868 МГц в России в него-то и не входит.
Разумеется, каждый второй заказчик смотрит на строчку «LoRaWAN 1.0.2, RU864, ADR, OTAA» в спецификации и, переминаясь с ноги на ногу, спрашивает «а можно нам 868 МГц сделать, а не 864?»
В народе безлицензионный ISM-диапазон при этом известен как 868 МГц, хотя вот именно 868 МГц в России в него-то и не входит.
Разумеется, каждый второй заказчик смотрит на строчку «LoRaWAN 1.0.2, RU864, ADR, OTAA» в спецификации и, переминаясь с ноги на ногу, спрашивает «а можно нам 868 МГц сделать, а не 864?»
https://habr.com/company/uline/blog/423825/
Интересно, это творчество маркетингового отдела — или они искренне с ума сошли?
Интересно, это творчество маркетингового отдела — или они искренне с ума сошли?
Habr
Все устройства в одном приложении | Мир IoT c Uline
Как и зачем мы планируем объединить все устройства IoT на одной платформе и управлять ими через одно приложение. Проблемы в IoT сегодня Cегодня реальное...
https://habr.com/company/sap/blog/325122/
Вот, кстати, пример искреннего схождения с ума (и да, там на фото наши модули видно). Целый SAP пытался продавать проект, нарисованный на бумаге людьми, вообще в принципе даже примерно не представляющими, как это всё должно работать хотя бы на самом базовом уровне.
Разбирать «почему это не будет работать никогда» там можно буквально на каждом абзаце.
Говорят, они его даже на конференциях показывали.
И вот одна из больших проблем IoT — в том, что у «мировых лидеров индустрии» проекты такие через один.
Вот, кстати, пример искреннего схождения с ума (и да, там на фото наши модули видно). Целый SAP пытался продавать проект, нарисованный на бумаге людьми, вообще в принципе даже примерно не представляющими, как это всё должно работать хотя бы на самом базовом уровне.
Разбирать «почему это не будет работать никогда» там можно буквально на каждом абзаце.
Говорят, они его даже на конференциях показывали.
И вот одна из больших проблем IoT — в том, что у «мировых лидеров индустрии» проекты такие через один.
Хабр
Умная ферма с дронами-ковбоями с помощью SAP Cloud Platform
SAP часто воспринимают как только разработчика ERP-систем для управления корпорациями и промышленными предприятиями. Между тем, компания довольно давно вышла за...
Такая штука меряет двигательную активность и температуру уха. Если корова заболевает, у неё уши становятся холодными, причём сильно так холодными, так что высокая точность градусника не нужна.
(На фото датчик CowManager, канал связи — Bluetooth. Ухо любезно предоставлено компанией Гейзер-Телеком. Ни одна корова при съёмках не пострадала)
Многие, кстати, удивляются, что у коров есть период охоты. Ну, мол, жвачное же травоядное, на кого она охотится-то?
Это на самом деле период половой охоты.
Определяется по акселерометру, корова начинает сильно активнее двигаться.
Это на самом деле период половой охоты.
Определяется по акселерометру, корова начинает сильно активнее двигаться.
Ещё интересная тема — определение энергетического баланса тушки, т.е. сколько она сожрала vs сколько она двигалась.
Но тут всё немножко сложно, т.к. для определения двигательной активности именно туши акселерометр желательно крепить на холке, но там его в реальных условиях, не лабораторных, крепить нечем. На шее и на ушах же много мелких паразитных движений, которые надо отфильтровывать, а это жрёт батарейку.
Как вариант — измерение пульса, очень хороший показатель физической активности, но тоже непонятно, как.
Но тут всё немножко сложно, т.к. для определения двигательной активности именно туши акселерометр желательно крепить на холке, но там его в реальных условиях, не лабораторных, крепить нечем. На шее и на ушах же много мелких паразитных движений, которые надо отфильтровывать, а это жрёт батарейку.
Как вариант — измерение пульса, очень хороший показатель физической активности, но тоже непонятно, как.
Жрачку можно определять на ухе, акселерометром по наклону головы и движениям ушей, но вообще считается, что точнее — ларингофоном (sic!) на шее. Когда она жуёт, у неё там внутри шумит. А датчик вешается на шейный ремень с грузиком внизу, чтобы сам датчик к шее сбоку прижимался.
О вреде преждевременного составления ТЗ.
Однажды к нам пришёл заказчик, который спрашивал, есть ли у нас датчик освещённости, который отличал бы безлунную ночь от полной темноты.
После лёгкого удивления с нашей стороны и расспросов заказчик сознался, что ему нужен датчик вскрытия люков, работающий с учётом, что крышку с люка могут спиздить и ночью.
Поставить туда полудолларовый акселерометр, который бы шевеление крышки фиксировал, ему просто как-то в голову не пришло.
Однажды к нам пришёл заказчик, который спрашивал, есть ли у нас датчик освещённости, который отличал бы безлунную ночь от полной темноты.
После лёгкого удивления с нашей стороны и расспросов заказчик сознался, что ему нужен датчик вскрытия люков, работающий с учётом, что крышку с люка могут спиздить и ночью.
Поставить туда полудолларовый акселерометр, который бы шевеление крышки фиксировал, ему просто как-то в голову не пришло.
Если вам надо измерять разные газы, а китайские MQxxx, показывающие погоду на Марсе, немного надоели, то посмотрите на SpecSensors.
Электрохимические датчики, 20 баксов штука (в наших палестинах в розницу 40), калиброванные (sic!), с хорошим даташитом.
Электрохимические датчики, 20 баксов штука (в наших палестинах в розницу 40), калиброванные (sic!), с хорошим даташитом.
Про принцип работы и подключение читать тут: https://www.spec-sensors.com/wp-content/uploads/2016/05/SPEC-Sensor-Operation-Overview.pdf
Ну и вообще, если вы мало знакомы с темой газовых датчиков, стоит потыкать на сайте в разные pdf разных продуктов (там что-то выложено только для девкитов, например), они короткие и простыми, но в то же время мудрыми словами.
Отдельный бонус - электрохимические, в отличие от каталитических MQ, мало жрут и могут работать от батарейки.
Шёл мимо драйвера EEPROM в RIOT, зацепился за торчащее, достал бензопилу и подровнял.
Итого: 8-кратный прирост производительности, 4-кратное уменьшение износа флэша.
Все мы со школьной скамьи знаем, что EEPROM отличается от флэша тем, что его можно читать и писать побайтово и предварительно не стирая.
ТАК ВОТ, ЭТО НЕ ТАК.
Во-первых, в том же STM32, как ни странно, родная шина данных EEPROM имеет ширину 32 бита - то есть пишется и читается он 4-байтными словами. Во-вторых, писать, не стирая, в него можно только единицы, а вот чтобы на место единицы записать ноль - таки надо стереть. Ну да, не страниц или сектор, а всего лишь слово.
Всё остальное за нас делает контроллер: например, если мы упорствуем на побайтовой записи, то он читает из EEPROM слово, меняет в нём нужный байт, стирает это слово в EEPROM и записывает его обратно.
Итого, на такую побайтовую запись одного слова уйдут 12 обращений к EEPROM, из которых четыре - это совсем не безвредные стирания.
Ну, собственно, в RIOT и была побайтовая запись сделана.
Переделал. Теперь при вызове eeprom_write() и eeprom_read() стирание и запись только и строго целыми словами, при невыравненных адресах и/или записи не целыми словами - все операции read-modify-write теперь в явном виде в памяти, и запись всегда только одна.
Итог см. выше. Ну, ладно, в реальной ситуации, когда запись идёт поверх грязной области и требует стирания, прирост производительности всего четыре раза.
https://github.com/RIOT-OS/RIOT/pull/10026
Итого: 8-кратный прирост производительности, 4-кратное уменьшение износа флэша.
Все мы со школьной скамьи знаем, что EEPROM отличается от флэша тем, что его можно читать и писать побайтово и предварительно не стирая.
ТАК ВОТ, ЭТО НЕ ТАК.
Во-первых, в том же STM32, как ни странно, родная шина данных EEPROM имеет ширину 32 бита - то есть пишется и читается он 4-байтными словами. Во-вторых, писать, не стирая, в него можно только единицы, а вот чтобы на место единицы записать ноль - таки надо стереть. Ну да, не страниц или сектор, а всего лишь слово.
Всё остальное за нас делает контроллер: например, если мы упорствуем на побайтовой записи, то он читает из EEPROM слово, меняет в нём нужный байт, стирает это слово в EEPROM и записывает его обратно.
Итого, на такую побайтовую запись одного слова уйдут 12 обращений к EEPROM, из которых четыре - это совсем не безвредные стирания.
Ну, собственно, в RIOT и была побайтовая запись сделана.
Переделал. Теперь при вызове eeprom_write() и eeprom_read() стирание и запись только и строго целыми словами, при невыравненных адресах и/или записи не целыми словами - все операции read-modify-write теперь в явном виде в памяти, и запись всегда только одна.
Итог см. выше. Ну, ладно, в реальной ситуации, когда запись идёт поверх грязной области и требует стирания, прирост производительности всего четыре раза.
https://github.com/RIOT-OS/RIOT/pull/10026
GitHub
cpu/stm32_common: EEPROM speedup by olegart · Pull Request #10026 · RIOT-OS/RIOT
Contribution denoscription
Changing EEPROM access from byte to 32-bit word improves access speed by up to 8 times. Unaligned and less than 4 bytes access still possible using same functions.
P.S. _wa...
Changing EEPROM access from byte to 32-bit word improves access speed by up to 8 times. Unaligned and less than 4 bytes access still possible using same functions.
P.S. _wa...