Про принцип работы и подключение читать тут: 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)

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

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

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

В каждом проекте приходит время писать Code of Conduct

Мы себе взяли за основу RIOT'овский, но немного подправили в паре мест: https://github.com/unwireddevices/RIOT/blob/loralan-public-2018.07/CODE_OF_CONDUCT.md

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

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

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

То есть, никто не предпримет, простите за выражение, decisive actions. Не выдаст пиздюлей.

Потому что некому. Нет такого человека.

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

Но, кстати, я слабо верю, что они этот драйвер вообще исправят.

Разве что пару самых грубых ошибок.

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

https://github.com/RIOT-OS/RIOT/issues/10090

Я им тут, кстати, понасабмитил за отпуск.

Вот с интересом следим за развитием событий — ткнул людей носом в то, что АЦП на STM32 в их реализации по сути бесполезен, так как выдаёт на выходе попугаи.

Мой прогноз: развития событий не будет, всем похрену.

Подумаешь, кому нахрен АЦП на STM32 вообще нужен-то.

Потому что открываем баг-трекер и берём там что-нибудь постарее, ну например, https://github.com/RIOT-OS/RIOT/issues/495

2014:
— Тут баг.

2016:
— Надо бы пофиксить.

2017:
— Может напишем, что не фиксится?
— Не, нехорошо как-то, лучше пофиксить.

Причём заранее понятно, что в выбранной модели разработки (читай: построения комьюнити) проблема с АЦП является нерешаемой

Потому что любое решение требует:
а) изменения API (но тут можно исхитриться и через макрос с VA_ARGS сделать аналог плюсового adc_sample(int adc_line, bool convert_to_mv = false), это через жопу и MISRA C вряд ли одобрит, но можно)

б) дописывания того самого преобразования в милливольты хотя бы в десяток-полтора самых популярных микроконтроллеров из поддерживаемых ОС

В рамках централизованной (формально или неформально) разработки обе проблемы решаются штатными методами: «мы посовещались и я решил, об исполнении доложить к понедельнику».

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

А вообще это уже не про IoT, но вы понимаете же, что для инвестора нет слов страшнее, чем «у нас в стартапе три основателя и полная демократия»?