хорошо бы еще разводку ПП посмотреть — залепить каждый корпус по питанию парой конденсаторов (керамика + тантал) конечно можно, но это лишние элементы, а внятная разводка земель и питания ничего не стоит :)
И к слову, брать «медленные» ИС только потому, что быстрые звенят по питанию, когда драйвят мощную нагрузку — это не очень честное решение. Лучше ограничить скорость роста тока, включив в цепь питания светодиодов (надеюсь, индикаторы применены с общим анодом) RC или LC-фильтр — ну и подключить его прямо к выходу ИС стабилизатора напряжения.
«Основной заказчик» устройства за год-то уже вырос, и реализованный функционал ему уже не совсем по возрасту. Нужно либо начинать проектировать что-то типа электрического беговела, либо планировать следующего «основного заказчика» ;)
Диапазону изменения емкости от приложенного напряжения этих конденсаторов позавидует иной варикап! И еще — интересно, какую форму будет иметь, например, пила с амплитудой в пару десятков вольт, пропущенная через такой переходной конденсатор?
Кстати, у ChibiOS в версии 3.0 (я, правда, пока экспериментировал только с 2.6.2 на STM32) заявлено разделение на автономные модули RTOS и HAL, причем RTOS для сложных построений можно использовать более богатую на фичи (ChibiOS/RT — список фич здесь) и минимальную (ChibiOS/NIL — список фич и сравнение с RT). NIL при этом не использует динамики вообще, легко работает на 8-битных ядрах, и весит всего порядка 1кБайт.
Я исходил из того, что в закрытых системах создавать потоки в рантайме практически всегда лишено смысла, так как конфигурация железа и реализуемый устройством функционал задан жестко — соответственно, еще в дизайн-тайме можно определить потоковую архитектуру системы — кто за что отвечает. Создание же потоков в рантайме может понадобиться, например, в plug-n-play конфигурациях, когда устройство обнаруживает у себя, скажем N активных UART-передатчиков, и для обслуживания каждого выделяет поток динамически. Но тогда возникает следующий вопрос — что с этим делать остальному коду — где брать *смысловое* значение того или иного потока, как им взаимодействовать с остальной частью системы, условно говоря — «на что хардкодиться?» Проблему можно (частично) решить метаданными, но они в эмбеде не в почете — так как требуют большого оверхеда на их трансляцию в бизнес-действия. Способ же, когда поток создается под какое-то однообразное действие, и по завершении убивается, тоже очень дорог — для этой цели проще и быстрее рестартить статически созданный поток.
Если это так, то динамический список можно заменить простым массивом дескрипторов известного в дизайн-тайме размера, а вместо перешивки указателей при упорядочивании задач к запуску использовать простой массив байт, содержащий индексы дескрипторов задач. Циклический индекс этого массива будет «указателем» на текущую выполняемую задачу, а индекс следующей к выполнению будет лежать в следующей (по модулю N) ячейке этого массива. Планировщик будет упорядочивать лишь этот вспомогательный массив, ставя, например, -1 в случае, если передачу кванта некоторой задаче нужно пропустить (по причине wait или freeze)
Насчет связных списков в структуре дескрипторов потоков — а не быстрее ли будет использовать циклический буфер и массив индексов дескрипторов в буфере? Адресная арифметика же в МК обычно совсем неразвитая, кроме того, ссылки на предка и потомка занимают больше, чем сам дескриптор. Итерация простым сложением вместе с каким-нибудь битом отсутствия дескриптора в массиве по данному индексу в переводе на ассемблер имхо видится гораздо компактнее и быстрее, чем реализация двусвязного списка.
Таненбаум — это как Пушкин. Читали все, а написать даже похоже — дано далеко не каждому. Дьявол там в деталях кроется, которых в свою очередь до черта, даже если на Си писать. Так что автору респект по-любому, даже если один-в-один реализовывал :)
У автора ChibiOS, кстати, многоплатформенное тестирование построено хоть и синхронно (то есть средствами встроенной периферии), но по выходу нового коммита сразу пачками для всех платформ и надолго — где-то на его сайте chibios.org была инфа об этом. BTW, как вы решали проблему вложенности запрета/разрешения прерываний при вызовах функций ядра из разных «колец» — обычного процесса, ISR и изнутри самого ядра?
И еще — вроде бы ваша оценка стека ISR — порядка 1Kбайт — почему так много?
Позволяете ли вы вызывать из ISR все вызовы RTOS, или только подмножество?
Как код переноса SP в область ISR после входа (и по все видимости, сохранения минимального контекста — флагов и IP) обрабатывает ситуацию вложенных прерываний? Насколько он эффективен (какая латентность привносится в обработчик прерываний до пользовательского кода)?
Насчет тестирования критических мест — попробуйте а) добавить внешний генератор событий, асинхронный по отношению к тестируемому SoC, генерируя события как по внутренним таймерам, так и по edge-activated interrupts от этого генератора; b) искусственно расширить критичные области, хотя бы добавив NOPов под условной компиляцией — чтобы увеличить вероятность сбоев синхронизации на них — поскольку тестирование корректности работы многопоточных систем методом интенсивной генерации событий — вещь вероятностная, и если вы ошибочно «приоткрылись» всего на одну команду — ошибка при синхронном с тактированием ядра режиме на процессорах синхронной же архитектуры может не вылезти вообще никогда. Искусственное же расширение критических секций позволяет не только увеличить вероятность сталкивания потоков на критических местах, но и сымитировать состояние ядра, близкое к насыщению внешними событиями, и выявить ошибки, возникающие при приближении интенсивности запросов на прерывания к этому пределу
Я написал «семафор», как наиболее базовое определение синхронизационного примитива, который опирается непосредственно либо на машинную реализацию атомарных команд «проверка-изменение», либо на синтетически созданную атомарность (запрещение прерываний)
Мьютекс — тот же двоичный семафор плюс тэг ID процесса, в данный момент его удерживающего, обновляемый атомарно со значением самого семафора. С точки зрения же пользовательского кода мьютекс — просто более частное и более удобное средство межпоточной синхронизации по сравнению с бинарным семафором для *конкретных* применений — и все, так как он а) защищен от повторных входов тем же тредом, б) защищен от случайных или злонамеренных действий других процессов, ну и c) может быть проверен перед захватом (не уверен, что эта возможность есть во всех реализациях)
Например, мы можем точно так же написать ожидание семафора в начале критической секции и просигналить освобождение его в конце, как и захватить и освободить мьютекс. Проблема инверсии приоритетов для семафоров тоже будет проявляться точно так же:
LowPriA прошел семафор
HighPriC встал на ожидание семафора, пройденного А
MiddlePriB вытеснил A
Вместо «прошел семафор» можно написать «захватил мьютекс» — суть от этого не поменяется. ЕМНИП (здесь могу ошибаться) эта проблема была описана еще Дийкстрой как раз на примере семафоров, а мьютексов у него тогда еще даже не было
интересно, у вас есть динамическая приоритезация задач? Что будет, если высокоприоритетная задача A ждет семафора, открываемого низкоприоритетной задачей B, которая не получает квант от планировщика ввиду низкого приоритета?
девайс, анализирующий аналоговый сигнал с автомобильной свечи
— уж не занимаетесь ли вы системами, оптимизирующими УОЗ через анализ функции тока плазмы от времени?
А вообще, синхронизация внутри ISR-обработчиков ядра и в частности, реакция на вложенные прерывания — это очень тонкие места — надо быть реальным параноиком, чтобы а приори умозрительно отследить и выловить все нарушения синхронизации — чуть раньше разрешил общие прерывания или сбросил маску контроллера — и привет. Причем, тесты на целостность ядра средствами собственного кристалла (из-за синхронности счетной периферии с тактированием ядра CPU) могут не падать вообще — а интенсивные истинно асинхронные события — валить систему.
BTW, я подобное поведение видел даже в аппаратном (!) исполнении еще на 8085 в связке с ИС контроллера прерываний 8259 — множественные асинхронные запросы (например, от дребезга входа) переполняли стек, несмотря на гарантированный спекой аппаратный автосброс маски в самом контроллере. Помогла тогда только явная синхронизация запросов с системным клоком через D-триггер )
я помню, что geometry работает в MSSQL крайне медленно — причем похоже не только вычисления, но и само инстанциирование geometry — в итоге, например, поиск POI в окружности заданного радиуса я делал в два этапа — на первом вычислял геокоординаты квадрата, в который вписана окружность поиска, затем искал объекты внутри этого квадрата по составному индексу. Индекс строился по вычислимым persisted колонкам, которые добавлялись к таблице свойств объекта со снесенными туда lat и long свойствами точки. На втором этапе производилось отсечение уголков между окружностью и квадратом уже с использованием свойств объекта geometry
Перед тем, как что-либо трогать, полезно проверить programmability в БД на отсутствие ссылок на это что-то в тексте сторед-процедур (там может быть и динамика!), функций и триггеров — например, испустив следующее:
select * from syscomments where text like '%<object_to_change>%'
Ну и вообще, полезно знать, где и зачем используется динамика — для этого можно найти все EXEC и sp_execute_sql в текстах всех процедур и посмотреть, насколько хитро там формируются стейтменты — иногда может оказаться, что строки на исполнение берутся из полей таблиц ;)
Можно получить метрику степени доверия BLE-позиции (например, исходя из количества видимых маяков или стабильности уровня их сигнала в небольшой временной окрестности), параллельно вести расчет интегрированием акселерометра, и взвешивать результат этих двух методов динамически, исходя из этой метрики — фактически замещая расчетную точку по радио расчетной по акслерометру в случае, когда степень доверия низка, и наоборот, корректируя уплывание интегрирования в случаях, когда достоверность радиометода высока.
кроме того, можно ограничивать динамику по BLE анализом динамики по акселерометру и сглаживать сильнее когда нужно
поработайте над качеством перевода плз, прежде чем представлять свой труд на обозрение широкой публике — тема граблей при разработке железа ведь очень актуальная, но перлы типа
уровень сгорания может меняться от месяца к месяцу
портят восприятие всей статьи напрочь. Речь ведь идет не об отоплении зимнего дома газовым котлом. Подозреваю, что в оригинале стоит burn rate — то есть скорость «паления бабла» проектом :)
или
Отличная команда может сотворить чудеса с посредственной концепцией, когда средняя команда может провалить и блестящую идею
— вместо когда — «в то время, как» — видимо, в оригинале был while
то вы можете заполучить десятки заинтересованных клиентов в рамках нескольких дней
— «в рамках» меняется на «за» после первого же беглого прочтения
А почему нельзя разделить AC и DC цепи, например кондером и дросселем? И никто тогда не обяжет использовать для ввода сигнала в линию генератор тока — можно будет вводить генератором напряжения через конденсатор
И к слову, брать «медленные» ИС только потому, что быстрые звенят по питанию, когда драйвят мощную нагрузку — это не очень честное решение. Лучше ограничить скорость роста тока, включив в цепь питания светодиодов (надеюсь, индикаторы применены с общим анодом) RC или LC-фильтр — ну и подключить его прямо к выходу ИС стабилизатора напряжения.
Если это так, то динамический список можно заменить простым массивом дескрипторов известного в дизайн-тайме размера, а вместо перешивки указателей при упорядочивании задач к запуску использовать простой массив байт, содержащий индексы дескрипторов задач. Циклический индекс этого массива будет «указателем» на текущую выполняемую задачу, а индекс следующей к выполнению будет лежать в следующей (по модулю N) ячейке этого массива. Планировщик будет упорядочивать лишь этот вспомогательный массив, ставя, например, -1 в случае, если передачу кванта некоторой задаче нужно пропустить (по причине wait или freeze)
И еще — вроде бы ваша оценка стека ISR — порядка 1Kбайт — почему так много?
Позволяете ли вы вызывать из ISR все вызовы RTOS, или только подмножество?
Как код переноса SP в область ISR после входа (и по все видимости, сохранения минимального контекста — флагов и IP) обрабатывает ситуацию вложенных прерываний? Насколько он эффективен (какая латентность привносится в обработчик прерываний до пользовательского кода)?
Мьютекс — тот же двоичный семафор плюс тэг ID процесса, в данный момент его удерживающего, обновляемый атомарно со значением самого семафора. С точки зрения же пользовательского кода мьютекс — просто более частное и более удобное средство межпоточной синхронизации по сравнению с бинарным семафором для *конкретных* применений — и все, так как он а) защищен от повторных входов тем же тредом, б) защищен от случайных или злонамеренных действий других процессов, ну и c) может быть проверен перед захватом (не уверен, что эта возможность есть во всех реализациях)
Например, мы можем точно так же написать ожидание семафора в начале критической секции и просигналить освобождение его в конце, как и захватить и освободить мьютекс. Проблема инверсии приоритетов для семафоров тоже будет проявляться точно так же:
LowPriA прошел семафор
HighPriC встал на ожидание семафора, пройденного А
MiddlePriB вытеснил A
Вместо «прошел семафор» можно написать «захватил мьютекс» — суть от этого не поменяется. ЕМНИП (здесь могу ошибаться) эта проблема была описана еще Дийкстрой как раз на примере семафоров, а мьютексов у него тогда еще даже не было
А вообще, синхронизация внутри ISR-обработчиков ядра и в частности, реакция на вложенные прерывания — это очень тонкие места — надо быть реальным параноиком, чтобы а приори умозрительно отследить и выловить все нарушения синхронизации — чуть раньше разрешил общие прерывания или сбросил маску контроллера — и привет. Причем, тесты на целостность ядра средствами собственного кристалла (из-за синхронности счетной периферии с тактированием ядра CPU) могут не падать вообще — а интенсивные истинно асинхронные события — валить систему.
BTW, я подобное поведение видел даже в аппаратном (!) исполнении еще на 8085 в связке с ИС контроллера прерываний 8259 — множественные асинхронные запросы (например, от дребезга входа) переполняли стек, несмотря на гарантированный спекой аппаратный автосброс маски в самом контроллере. Помогла тогда только явная синхронизация запросов с системным клоком через D-триггер )
Ну и вообще, полезно знать, где и зачем используется динамика — для этого можно найти все EXEC и sp_execute_sql в текстах всех процедур и посмотреть, насколько хитро там формируются стейтменты — иногда может оказаться, что строки на исполнение берутся из полей таблиц ;)
кроме того, можно ограничивать динамику по BLE анализом динамики по акселерометру и сглаживать сильнее когда нужно
или — вместо когда — «в то время, как» — видимо, в оригинале был while
— «в рамках» меняется на «за» после первого же беглого прочтения