Ну, не совсем количество ножек
Но на 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 и наличия периферии в прошивках, поддерживающих несколько чипов
Но на 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 и наличия периферии в прошивках, поддерживающих несколько чипов
GitHub
RIOT/cpu/cortexm_common/cortexm_init.c at loralan-public · unwireddevices/RIOT
RIOT - The friendly OS for IoT. Contribute to unwireddevices/RIOT development by creating an account on GitHub.
Добавил в мейнлайн RIOT поддержку RU864 для LoRaWAN, наример
https://github.com/RIOT-OS/RIOT/commit/4ca6cd70cb4744d709dde7952d2f5a35d28801fe
https://github.com/RIOT-OS/RIOT/commit/4ca6cd70cb4744d709dde7952d2f5a35d28801fe
GitHub
Merge pull request #10049 from unwireddevices/riot-semtech-lorawan-ru864 · RIOT-OS/RIOT@4ca6cd7
pkg/semtech-loramac: RU864 band added
Вспомнил в ночи немного ассемблера, написал функцию проверки адресов на валидность для Cortex-M0 - у которого нет BusFault, а любая ошибка сразу валит проц в HardFault.
https://github.com/RIOT-OS/RIOT/pull/10051/commits/982d6664f17d572cee1b72832104f1320ea97d7e
https://github.com/RIOT-OS/RIOT/pull/10051/commits/982d6664f17d572cee1b72832104f1320ea97d7e
GitHub
cpu/cortexm_common: add function to check address for validity by olegart · Pull Request #10051 · RIOT-OS/RIOT
Contribution denoscription
Adds extremely useful function to check memory addresses for validity on Cortex-M3/M4/M7 MCUs.
Can be used to determine memory sizes, peripherals availability, etc. in runt...
Adds extremely useful function to check memory addresses for validity on Cortex-M3/M4/M7 MCUs.
Can be used to determine memory sizes, peripherals availability, etc. in runt...
https://github.com/RIOT-OS/RIOT/pull/10088
Вот примерно так выглядит опенсорс: чуваки запушили в ОС драйвер акселерометра с детскими ошибками, который, очевидно, тупо не работает. Драйвер раздувает код на лишний килобайт бессмысленным использованием float'а, а его автор перехерачил в него куски даташита, даже не пытаясь вдумываться, зачем они нужны - и не может этого объяснить и сейчас. Никто никогда этот драйвер не проверял хотя бы на уровне "выдаёт ли акселерометр 1g, просто лёжа на столе". За полтора года никто не исправил в драйвере ни единой значимой ошибки.
Зато драйвер моментально попал в релиз ОС.
И при этом главное - чтобы все с уважением друг к другу относились.
Хотя вообще-то главным должно быть немедленно охуеть и пойти ревьюить остальные коммиты того же автора, нет ли там такого же говна внутри.
Вот примерно так выглядит опенсорс: чуваки запушили в ОС драйвер акселерометра с детскими ошибками, который, очевидно, тупо не работает. Драйвер раздувает код на лишний килобайт бессмысленным использованием float'а, а его автор перехерачил в него куски даташита, даже не пытаясь вдумываться, зачем они нужны - и не может этого объяснить и сейчас. Никто никогда этот драйвер не проверял хотя бы на уровне "выдаёт ли акселерометр 1g, просто лёжа на столе". За полтора года никто не исправил в драйвере ни единой значимой ошибки.
Зато драйвер моментально попал в релиз ОС.
И при этом главное - чтобы все с уважением друг к другу относились.
Хотя вообще-то главным должно быть немедленно охуеть и пойти ревьюить остальные коммиты того же автора, нет ли там такого же говна внутри.
GitHub
drivers/adxl345: fix ADXL345 driver by olegart · Pull Request #10088 · RIOT-OS/RIOT
Contribution denoscription
Fixes the broken ADXL345 driver.
Scale factor can be 4, not 3.9. 3.9 came from "typical scale factor is 3.9" from datasheets' Table 1, but accel...
Fixes the broken ADXL345 driver.
Scale factor can be 4, not 3.9. 3.9 came from "typical scale factor is 3.9" from datasheets' Table 1, but accel...
Media is too big
VIEW IN TELEGRAM
Расстановщик компонентов LitePlacer у нас в офисе (http://www.liteplacer.com)
Проект, офигенный в том, что самодельные расстановщики схожего уровня себе делали многие самоделкины, но до готового к продаже набора довели единицы.
И когда оно приезжает - понимаешь, почему: это несколько немаленьких коробок, до отказа заполненных тщательно отсортированными и подписанными пакетиками. То есть вот прямо под отвёрточную сборку, там самостоятельно, кажется, только провода купить и нарезать надо. И всё это нормального и вполне фабричного вида, никакого напилинга по фанере. Делает чувак из Финляндии в одно лицо.
Ну а в остальном - да, штука со скоростью ручного монтажа, только не требующая для работы ручного монтажника.
И когда оно приезжает - понимаешь, почему: это несколько немаленьких коробок, до отказа заполненных тщательно отсортированными и подписанными пакетиками. То есть вот прямо под отвёрточную сборку, там самостоятельно, кажется, только провода купить и нарезать надо. И всё это нормального и вполне фабричного вида, никакого напилинга по фанере. Делает чувак из Финляндии в одно лицо.
Ну а в остальном - да, штука со скоростью ручного монтажа, только не требующая для работы ручного монтажника.
В каждом проекте приходит время писать Code of Conduct
Мы себе взяли за основу RIOT'овский, но немного подправили в паре мест: https://github.com/unwireddevices/RIOT/blob/loralan-public-2018.07/CODE_OF_CONDUCT.md
Мы себе взяли за основу RIOT'овский, но немного подправили в паре мест: https://github.com/unwireddevices/RIOT/blob/loralan-public-2018.07/CODE_OF_CONDUCT.md
GitHub
RIOT/CODE_OF_CONDUCT.md at loralan-public-2018.07 · unwireddevices/RIOT
RIOT - The friendly OS for IoT. Contribute to unwireddevices/RIOT development by creating an account on GitHub.
На примере RIOT мы наблюдаем яркий пример проекта без лидера — или, скорее, с некоей неформальной группой недолидеров, которые не хотят брать на себя обязанности лидера.
Вот та ситуация с угрёбищным, сломанным, плохо написанным, никем не тестировавшимся драйвером акселерометра — она же вообще на самом деле только отчасти про акселерометр.
Глобально она про то, что есть два чувака — один написал говнокод, а другой поставил его в релиз ОС — которым никто ничего не сделает, чтобы помешать им писать и релизить такой же говнокод в дальнейшем, равно как никто и не пойдёт проверять их предыдущие коммиты и аппрувалы, нет ли там такого же говнокода.
То есть, никто не предпримет, простите за выражение, decisive actions. Не выдаст пиздюлей.
Потому что некому. Нет такого человека.
То есть, вся текущая буча не имеет никакого практического смысла, потому что максимально возможный эффект от неё — исправление одного конкретного драйвера, который мы у себя и так давно уже исправили.
Вот та ситуация с угрёбищным, сломанным, плохо написанным, никем не тестировавшимся драйвером акселерометра — она же вообще на самом деле только отчасти про акселерометр.
Глобально она про то, что есть два чувака — один написал говнокод, а другой поставил его в релиз ОС — которым никто ничего не сделает, чтобы помешать им писать и релизить такой же говнокод в дальнейшем, равно как никто и не пойдёт проверять их предыдущие коммиты и аппрувалы, нет ли там такого же говнокода.
То есть, никто не предпримет, простите за выражение, decisive actions. Не выдаст пиздюлей.
Потому что некому. Нет такого человека.
То есть, вся текущая буча не имеет никакого практического смысла, потому что максимально возможный эффект от неё — исправление одного конкретного драйвера, который мы у себя и так давно уже исправили.
Но, кстати, я слабо верю, что они этот драйвер вообще исправят.
Разве что пару самых грубых ошибок.
Всё остальное уйдёт в песок в очередном обсуждении, в котором первые три дня автор драйвера будет упираться, а потом всем просто станет лень писать, ведь нельзя же просто так взять и решить, надо сначала к консенсусу придти.
Разве что пару самых грубых ошибок.
Всё остальное уйдёт в песок в очередном обсуждении, в котором первые три дня автор драйвера будет упираться, а потом всем просто станет лень писать, ведь нельзя же просто так взять и решить, надо сначала к консенсусу придти.
https://github.com/RIOT-OS/RIOT/issues/10090
Я им тут, кстати, понасабмитил за отпуск.
Вот с интересом следим за развитием событий — ткнул людей носом в то, что АЦП на STM32 в их реализации по сути бесполезен, так как выдаёт на выходе попугаи.
Мой прогноз: развития событий не будет, всем похрену.
Подумаешь, кому нахрен АЦП на STM32 вообще нужен-то.
Я им тут, кстати, понасабмитил за отпуск.
Вот с интересом следим за развитием событий — ткнул людей носом в то, что АЦП на STM32 в их реализации по сути бесполезен, так как выдаёт на выходе попугаи.
Мой прогноз: развития событий не будет, всем похрену.
Подумаешь, кому нахрен АЦП на STM32 вообще нужен-то.
GitHub
ADC data on STM32 are useless #10090
I'm not sure if it's bug or a feature, but... ADC scale on STM32 is related to VDDA voltage, which usually means VDD voltage, which often means not-so-stable battery voltage VDD can be calculated and ADC values properly scaled by reading...
Потому что открываем баг-трекер и берём там что-нибудь постарее, ну например, https://github.com/RIOT-OS/RIOT/issues/495
2014:
— Тут баг.
2016:
— Надо бы пофиксить.
2017:
— Может напишем, что не фиксится?
— Не, нехорошо как-то, лучше пофиксить.
2014:
— Тут баг.
2016:
— Надо бы пофиксить.
2017:
— Может напишем, что не фиксится?
— Не, нехорошо как-то, лучше пофиксить.
GitHub
native not float safe #495
When the FPU is used when an asynchronous context switch occurs, something goes wrong. Something (as far as quick testing could reveal): either the stack gets corrupted or a floating point exception occurs. Test case: test_irq with a flo...
Причём заранее понятно, что в выбранной модели разработки (читай: построения комьюнити) проблема с АЦП является нерешаемой
Потому что любое решение требует:
а) изменения API (но тут можно исхитриться и через макрос с VA_ARGS сделать аналог плюсового adc_sample(int adc_line, bool convert_to_mv = false), это через жопу и MISRA C вряд ли одобрит, но можно)
б) дописывания того самого преобразования в милливольты хотя бы в десяток-полтора самых популярных микроконтроллеров из поддерживаемых ОС
В рамках централизованной (формально или неформально) разработки обе проблемы решаются штатными методами: «мы посовещались и я решил, об исполнении доложить к понедельнику».
В рамках комьюнити, в котором нет что-либо решающего лидера, уже первый пункт приведёт к вялой, ничем не кончающейся дискуссии, а второй нереализуем вообще, ибо требует мобилизации полудесятка разработчиков, а это невозможно, если только они сами как-нибудь так не согласятся вдруг (особенно с учётом, что поддержка части процессоров брошена на полпути, и дописывать туда что-то серьёзнее нового инклюда или дефайна тупо некому).
Потому что любое решение требует:
а) изменения API (но тут можно исхитриться и через макрос с VA_ARGS сделать аналог плюсового adc_sample(int adc_line, bool convert_to_mv = false), это через жопу и MISRA C вряд ли одобрит, но можно)
б) дописывания того самого преобразования в милливольты хотя бы в десяток-полтора самых популярных микроконтроллеров из поддерживаемых ОС
В рамках централизованной (формально или неформально) разработки обе проблемы решаются штатными методами: «мы посовещались и я решил, об исполнении доложить к понедельнику».
В рамках комьюнити, в котором нет что-либо решающего лидера, уже первый пункт приведёт к вялой, ничем не кончающейся дискуссии, а второй нереализуем вообще, ибо требует мобилизации полудесятка разработчиков, а это невозможно, если только они сами как-нибудь так не согласятся вдруг (особенно с учётом, что поддержка части процессоров брошена на полпути, и дописывать туда что-то серьёзнее нового инклюда или дефайна тупо некому).
А вообще это уже не про IoT, но вы понимаете же, что для инвестора нет слов страшнее, чем «у нас в стартапе три основателя и полная демократия»?
https://www.computer.org/web/education/code-of-ethics
Реальный Code of Conduct реальных проектов, а не плюшевые посмешища про то, что «мы здесь все друг другу друзья, давайте за руки возьмёмся».
Реальный Code of Conduct реальных проектов, а не плюшевые посмешища про то, что «мы здесь все друг другу друзья, давайте за руки возьмёмся».
IEEE Computer Society
Code of Ethics
IEEE Computer Society and ACM have established a joint task force on software engineering ethics. Read through the best practices.
https://devanlai.github.io/projects/dap42/
DAP42 — это такой набортный мини-программатор с поддержкой SWD и проброса UART на базе STM32F042F6P6.
Позволяет на 20-ногом процессоре стоимостью доллар-полтора сделать интерфейс для отладочной платы. Без всех возможностей ST-Link, DAPLink или Black Magic, но вполне достаточный.
DAP42 — это такой набортный мини-программатор с поддержкой SWD и проброса UART на базе STM32F042F6P6.
Позволяет на 20-ногом процессоре стоимостью доллар-полтора сделать интерфейс для отладочной платы. Без всех возможностей ST-Link, DAPLink или Black Magic, но вполне достаточный.
devanlai.github.io
dap42
An open-source CMSIS-DAP debug probe
https://github.com/SushiBits/DAP42-Firmware
А это его чуть более свежая версия, причёсанная другими людьми.
А это его чуть более свежая версия, причёсанная другими людьми.
GitHub
SushiBits/DAP42-Firmware
CMSIS-DAP debug probe based on STM32F042. Contribute to SushiBits/DAP42-Firmware development by creating an account on GitHub.
Впрочем, с причёсыванием я поторопился — что-то там огрызки и ошмётки какие-то.
https://github.com/RIOT-OS/RIOT/pull/10037
Чувак отказался ревьюить валидный и, более того, полезный код, потому что моё поведение ему не нравится. К коду претензий нет.
Кстати, а никому не приходила в голову идея весёлого троллинга проектов борцов за справедливость:
а) регулярно сабмитить хороший и полезный код
б) вести себя при этом достаточно неприятно по отношению ко всяким идиотам, чтобы мейнтейнеры твои реквесты целенаправленно игнорировали
в) при попытке мейнтейнеров засабмитить тот же код (он же хороший и полезный) от своего лица бить по мордасам за GPL violation, если твой копирайт из кода убрали
Чувак отказался ревьюить валидный и, более того, полезный код, потому что моё поведение ему не нравится. К коду претензий нет.
Кстати, а никому не приходила в голову идея весёлого троллинга проектов борцов за справедливость:
а) регулярно сабмитить хороший и полезный код
б) вести себя при этом достаточно неприятно по отношению ко всяким идиотам, чтобы мейнтейнеры твои реквесты целенаправленно игнорировали
в) при попытке мейнтейнеров засабмитить тот же код (он же хороший и полезный) от своего лица бить по мордасам за GPL violation, если твой копирайт из кода убрали
GitHub
sys/crypto: optimize AES footprint by olegart · Pull Request #10037 · RIOT-OS/RIOT
Contribution denoscription
AES tables on-the-fly calculation instead of using precalculated tables - roughly the same performance while saving ~8 KB code size.
Testing procedure
Passes unittests/test...
AES tables on-the-fly calculation instead of using precalculated tables - roughly the same performance while saving ~8 KB code size.
Testing procedure
Passes unittests/test...
Неплохая идея, высказанная в фейсбуке: сводить перечень изменений, которые мы сделали в RIOT, в отдельный файл
https://github.com/unwireddevices/RIOT/blob/loralan-public-2018.07/UNWDS.md
https://github.com/unwireddevices/RIOT/blob/loralan-public-2018.07/UNWDS.md
GitHub
RIOT/UNWDS.md at loralan-public-2018.07 · unwireddevices/RIOT
RIOT - The friendly OS for IoT. Contribute to unwireddevices/RIOT development by creating an account on GitHub.
https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
S for Security
Китайцы якобы имплантировали в заказные железки контроллеры с бэкдором, подключённые к внутренней шине контроллера самой железки.
А на иллюстрация Блумберга при этом — безобидный согласующий балун, у которого всех внутренностей-то штук пять пассивных компонентов, зато очень характерный внешний вид, так что любителям сенсаций будет несложно найти его в тысячах IoT-устройств.
S for Security
Китайцы якобы имплантировали в заказные железки контроллеры с бэкдором, подключённые к внутренней шине контроллера самой железки.
А на иллюстрация Блумберга при этом — безобидный согласующий балун, у которого всех внутренностей-то штук пять пассивных компонентов, зато очень характерный внешний вид, так что любителям сенсаций будет несложно найти его в тысячах IoT-устройств.
Bloomberg.com
China Used a Tiny Chip in a Hack That Infiltrated U.S. Companies
The attack by Chinese spies reached almost 30 U.S. companies by compromising America's technology supply chain.