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

(На фото датчик CowManager, канал связи — Bluetooth. Ухо любезно предоставлено компанией Гейзер-Телеком. Ни одна корова при съёмках не пострадала)

Многие, кстати, удивляются, что у коров есть период охоты. Ну, мол, жвачное же травоядное, на кого она охотится-то?

Это на самом деле период половой охоты.

Определяется по акселерометру, корова начинает сильно активнее двигаться.

Ещё интересная тема — определение энергетического баланса тушки, т.е. сколько она сожрала vs сколько она двигалась.

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

Как вариант — измерение пульса, очень хороший показатель физической активности, но тоже непонятно, как.

Жрачку можно определять на ухе, акселерометром по наклону головы и движениям ушей, но вообще считается, что точнее — ларингофоном (sic!) на шее. Когда она жуёт, у неё там внутри шумит. А датчик вешается на шейный ремень с грузиком внизу, чтобы сам датчик к шее сбоку прижимался.

Но на шее бессмысленно измерять температуру.

О вреде преждевременного составления ТЗ.

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

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

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

Если вам надо измерять разные газы, а китайские MQxxx, показывающие погоду на Марсе, немного надоели, то посмотрите на SpecSensors.

Электрохимические датчики, 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

Не только лишь все это знают, но самая частая проблема с энергосбережением на STM32L1 - это его ножки.

В силу раздававшихся в головах у инженеров ST Microelectronics голосов они все по умолчанию сконфигурированы как цифровые входы. Цифровой вход, будучи подвешенным в воздухе, принимает на себя Радио Маяк и чёрт знает что ещё, то есть в общем случайный шум. На входе же у цифрового входа - триггер Шмитта, который от этого шума случайно переключается туда-сюда, при этом потребляя.

То есть, можно взять L1, увести его в STOP прямо-таки по всем правилам - и он всё равно будет жрать несколько десятков микроампер.

Поэтому первое, что надо сделать - это все ножки перевести в состояние аналоговых входов.

Впрочем, и тут инженеры без шутки не смогли - просто пройтись по всем регистрам подряд и сказать port->MODER = 0xffffffff нельзя, потому что в какой-то момент регистры кончатся, а начнётся Hard Fault.

А в какой - зависит от *корпуса* микроконтроллера. Ну то есть если вот у нас тут условный QFN48, и у него GPIOG нет, то стучаться в GPIOG нельзя, а если такой же в принципе проц, но в LQFP100 - то можно.

Остаётся одно из трёх - либо собирать прошивку под конкретный *корпус* микроконтроллера, либо определять в рантайме, сколько у его корпуса ножек.

К счастью, программно посчитать количество ножек процессора не просто, а очень просто!

Ну, не совсем количество ножек

Но на Cortex-M3 можно определить попадание в несуществующий адрес, запретив обработчик Bus Fault, ткнувшись в этот адрес, а потом посмотрев, не взвёлся ли SCB_CFSR_BFARVALID

Короче, вот: https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/cortexm_common/cortexm_init.c#L72

То есть при старте на STM32L1 проходимся по всем портам от GPIOA до GPIOG, но перед записью туда 0xFFFFFFFF проверяем, существует ли такой порт

Не благодарите

P.S. На более поздних чипах того же ST (L0 и далее везде) ножки по умолчанию уже в AIN, этот танец не нужен. Тем более, в Cortex-M0 нет BusFault, и метод определения валидности адреса изъёбистее на два порядка.

P.P.S. Тот же метод очень удобно использовать для определения объёмов ОЗУ/флэша/EEPROM и наличия периферии в прошивках, поддерживающих несколько чипов

Добавил в мейнлайн RIOT поддержку RU864 для LoRaWAN, наример

https://github.com/RIOT-OS/RIOT/commit/4ca6cd70cb4744d709dde7952d2f5a35d28801fe

Вспомнил в ночи немного ассемблера, написал функцию проверки адресов на валидность для Cortex-M0 - у которого нет BusFault, а любая ошибка сразу валит проц в HardFault.

https://github.com/RIOT-OS/RIOT/pull/10051/commits/982d6664f17d572cee1b72832104f1320ea97d7e

http://olegart.ru/wordpress/2018/09/30/5050/

Не благодарите.

https://github.com/RIOT-OS/RIOT/pull/10088

Вот примерно так выглядит опенсорс: чуваки запушили в ОС драйвер акселерометра с детскими ошибками, который, очевидно, тупо не работает. Драйвер раздувает код на лишний килобайт бессмысленным использованием float'а, а его автор перехерачил в него куски даташита, даже не пытаясь вдумываться, зачем они нужны - и не может этого объяснить и сейчас. Никто никогда этот драйвер не проверял хотя бы на уровне "выдаёт ли акселерометр 1g, просто лёжа на столе". За полтора года никто не исправил в драйвере ни единой значимой ошибки.

Зато драйвер моментально попал в релиз ОС.

И при этом главное - чтобы все с уважением друг к другу относились.

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

Расстановщик компонентов LitePlacer у нас в офисе (http://www.liteplacer.com)