Антон, спасибо за развернутый ответ — в образовательных целях построение многозадачной ОС — это незаменимый боевой опыт, к тому же сильно вдохновляющий самих участников процесса.
Насчет доказательства корректной работы — все имхо тут сложнее, ибо даже многочасовой многопоточный прогон в стрессовых для механизмов синхронизации условиях не гарантирует абсолютную корректность работы. А испортить ее можно одним неосторожным коммитом, причем функциональные тесты при этом могут и не упасть — например, вложенным вызовом функций, запрещающих и затем разрешающих прерывания внутри своих критических секций, или наоборот — расчет на выполнение сервиса ОС в обработчике прерывания, которое оказывается при какой-то комбинации условий запрещенным — в обоих случаях, вуаля — прощай, стабильное ядро. И все это — кроссплатформенно.
И еще — аппаратная основа многопоточности — это возможность оставить свой контекст *целиком и без искажения* в стеке. Насколько я помню, некоторые архитектуры не позволяют это сделать иначе, как посредством аппаратного прерывания (возможность это сделать для последнего очевидна в силу самого принципа прерываний). Отсюда вывод, что алгоритмы ядра в части перехода процесса в ожидание, его реактивации (особенно по условию) и терминирования для таких архитектур должны быть реализованы с учетом этого факта — в частности, моментальные просыпания ожидающего события потока могут и не поддерживаться иначе, как симуляцией аппаратного прерывания например, через GPIO. Интересно, у вас этим моментам уделено внимание?
Почему пишете свою RTOS, тем более кроссплатформенную, а не садитесь на какую-нибудь готовую опенсорсную, например ChibiOS?
Каковы достигнутые конкурентные преимущества вашей RTOS относительно других, ради которых была проведена такая масштабная разработка?
Существует ли пруф корректной работы ядра в части работы с потоками и синхронизационными примитивами?
Однако, в любом случае подобная разработка — чрезвычайно интересное и полезное с точки зрения детального понимания механизмов работы компонетов ОС и взаимодействия их с ресурсами системы. Это, наверное, как художнику большое эпохальное полотно написать — трудно, долго, но очень увлекательно.
PS — я в 95м году написал либу на Си и Ассемблере, реализующую паралеллизм в реальном режиме x86 под Досом — со всеми переключениями контекста процессора и сопроцессора, состояниями процессов, своим менеджером памяти, очередями к нереентерабельным функциям доса и биоса, шедулингом, завязанным на таймер, привязанным другим аппаратным прерываниям (там была машина для управления оборудованием), и софтовым интам. Также был написан монитор состояния процессов на чистом асме с индикацией ресурсов, семафоров и статусов.
Помню, что управление тредами вызывало у меня ассоциацию с законом Мерфи — если уж вы открыли банку с червями… — так как породить тред было сравнительно просто, а вот грамотно придержать на ожидании ресурса, или убить внешними средствами — гораздо сложнее
Это все очень странно — с одной стороны, 300 микроампер утечек — это слишком много, даже для эпоксидки итд. С другой — вот кусок даташита на насчет потребления в low-power режимах: — судя по нему, в спящих режимах (даже в Stop с сохранением памяти) STM32 запросто может использоваться в системах с автономным питанием практически наравне с AVR. Другое дело, что в рабочем они тянут заметно больше — но тут очевидно сказывается гораздо более высокая тактовая частота * большее количество переключаемых вентилей
PS — у меня есть F103 на eval board с питанием через USB и встроенным стабом 5 -> 3.3. Надо будет зацепиться после него и посмотреть, сколько он тянет. Плата там сделана нормально, утечек быть не должно
Значит, в ядре что-то продолжает крутиться, чудес не бывает — SoC с fully static architecture на кмоп-технологии в статике вообще ничего жрать не должны, это не 8080.
По даташиту RC-генератор вотчдога берет всего несколько микроампер, остальное — это скорее всего, тактирование периферии, если само ядро спит.
BTW, если будете специально тестировать low-power режимы, сообщите сюда плз — STM32 — прекрасная замена AVR в DIY-штуках, с Атмела пора уже слезать, но вот в автономном питании как раз и есть сомнения
По даташиту потребление в Standby — единицы, а не сотни микроампер. Если у Вас SoC спит в нужном режиме, тогда забираю свое предположение обратно — потребление будет определяться скважностью фаз бодрствования и сна :) Куски кода, честно говоря, не смотрел
Однако, кажется, есть еще один источник потребления — электретный микрофон с 10КОм в плюсовом плече. Если напряжение на нем порядка двух вольт, как Вы пишете, то свои 100 микроампер цепь его подпитки гарантированно забирает. Соответственно — запитать электрет можно также от выводов порта.
600 мкА жрет скорее всего потому, что ждете не в Standby, а в Stop. Из Standby, правда, сложновато выходить — но можно попробовать завести watchdog на скажем раз в 200 мс, и просыпаясь по нему, быстро оценивать (в течение сотни миллисекунд) уровень сигнала микрофона — если на входе сигнал есть, то дальше подавлять WDT, и работать по Вашему алгоритму. Если нет — отправлять процессор опять в Standby и ждать следующего WDT wakeup. В Standby в ядре все остановлено, и потребление не превышает единиц микроампер.
Перевес не страшен — погрешность оценки DC за пару секунд при холодном старте будет ничтожна по сравнению с флуктуациями постоянной составляющей микрофона от времени или от экземпляра к экземпляру.
Потребление упадет ровно на ток, протекающий через резистор в 24кОм под напряжением в 3В — то есть на 125 микроампер, и устройство будет способно жить месяцами от 2032
Сигнал с микрофона симметричный, поэтому среднее значение не изменится при наличии шума на входе. Усреднять можно при подаче питания в течение нескольких секунд, и запоминать дальше на все время работы, чтобы не тратить ресурсы на скользящее среднее
Игрушка получилась очень забавная, возникла только пара комментов:
1. Чтобы снизить потребление, потенциометр можно питать от вывода порта в активном режиме, и переводить его в 0 или Z перед засыпанием, и обратно в 1 при просыпании по началу дутья. Пот можно кстати взять движковый, тогда получится тромбон ;). И естественно, с характеристикой A
2. Значенние постоянной составляющей лучше все-таки вычислять усреднением и вычитанием среднего — параметры микрофона могут плыть со временем, да и требование индивидуальной прошивки под каждый экземпляр — не комильфо.
Емнип, применение оконных функций само по себе лишних частот не вырезает — оно изменяет влияние факта конечности длины блока данных на результат ПФ. Если же нужно вырезать все, что выше определенной частоты, можно рассчитать и применить цифровой ФНЧ нужного порядка
Прекрасный ностальгический образец советской бытовой электроники — широкие дип-корпуса (доступный ИР12 в качестве простого регистра-защелки адреса вместо дефицитного тогда ИР22), ряды КТ315/361, электролиты К50-6, огромный кварц итд. Странно только, что ПЗУ оказалось в золоченом военном исполнении, а панелька судя по фото — одна из самых ненадежных советских с плоскими, а не цанговыми контактами. Но как бы ни было — это полноценный раритетный контроллер — можно сделать часы с будильником ;) — ресурсов должно хватить.
PS — ВЕ48 применялись еще, в частности, в клавиатурах ЕС-1840 и Искра-1030.
электродвигатель стеклоподъемников — с возбуждением постоянными магнитами, что делает его нагрузочную характеристику близкой (равной в случае нулевого внутреннего сопротивления источника питания) к оной для параллельного возбуждения, но заметно увеличивает КПД.
Ну если только для спорта, то как ни странно, требования к прошивке будут менее жесткими, чем к гражданским. Можно забить на тщательную реализацию:
а) алгоритмов пуска, прогрева, холостого хода
б) экономичность и выбросы [если в US за это не прижмут, конечно — там вроде вмешиваться в системы, влияющие на emissions (например, ставить обманку лямбда-зонда) — чуть ли не уголовка]
в) вообще работу движка не на ВСХ. Достаточно лишь обеспечить более-менее хороший выход на ВСХ с частичных нагрузок, чтобы мотор не хлебал и не дергался
Однако, подбор углов УОЗ, фаз впрыска и AFR (они взаимозависимы!) по максимуму отдачи мотора вам придется делать по-любому
[OFF] Решил Вас проверить — ведь суффикс 239 не может быть случайным. Так и есть )
По делу — я не совсем уверен, что 100% поддерживаю выбранный вами путь — так как, по моему мнению, надежно управлять двигателем, с приемлемой точностью дозируя топливо, соблюдая тайминг зажигания, поддерживая несколько режимов работы, и обмениваясь с диагостическим оборудованием неплохо удается даже на 8-битных процессорах со скромной тактовой порядка 20 МГц и производительностью 4-5 MIPS (правда, не без аппаратной поддержки), а сам по себе переход на плавающее ядро никакой существенной выгоды не даст, ибо:
а) точность расчета смеси и зажигания не имеет смысла делать выше точности стоковых датчиков, и
б) работа системы в режиме обратной связи позволяет нивелировать как производственные, так и расчетные погрешности — систематические и случайные.
Некоторый эффект может дать только снижение ошибки управления из-за практического исчезновения дискретности как в алгоритмах коррекции, так и прямого управления. Однако, все это имхо — эффекты минус-энного порядка, так как основа хорошего управления — хорошая модель, и корректно покрывающие эту модель алгоритмы. Плавающие они будут, или целочисленные — уже не столь существенно
Поэтому я не уверен, что плавающее ядро само по себе — достаточное условие успеха проекта, и начинать надо именно с него. И наоборот, удачная модель будет хорошо работать независимо от способа реализации. То есть, я бы начал не с программирования, а с теории и практики работы ДВС.
Кроме того, практический анализ существующих прошивок говорит о том, что реальный продукт — это множественные костыли, костылики и воркэраунды, призванные эвристически сгладить недостатки теормодели — а значит, вам придется пройти весь этот путь еще раз, причем этот этап шлифуется не на эмуляторе, а на реальном моторе и реальной дороге (беговые барабаны в неограниченном доступе у вас вряд ли есть). И силами коммьюнити (в отличие от отладки софта) его не сделать — только в один тред — а значит:
а) путь будет долгим,
б) результат будет хорошо применим только к конкретному двигателю (это с натяжкой, но в целом так)
Навскидку, вам придется реализовать и отладить:
а) надежную детекцию режимов работы мотора (пуск, холостой ход, экономичный, мощностной, принудительный ХХ)
б) плавный переход между режимами
в) надежную работу в а) и б) при всем диапазоне температур ОЖ и ОВ
г) управление ХХ во всем диапазоне температур
д) алгоритмы пуска во всем диапазоне температур (существенно различаются для холодного — например, вы знаете, для чего при холодном пуске меняют фазы открытия форсунок?)
е) работу с датчиком детонации и УОЗ в диапазоне температур и нагрузок
ж) учет топливной пленки при расчете времени открытия форсунок
з) алгоритмы долговременной и кратковременной коррекции в режиме ОС
и) накапливание, обработка и вывод диагностической информации
итд
Когда я ковырял прошивки отечественных ВАЗов, в том числе работу в режиме closed loop, мне пришла в голову идея вместо алгоритмической подстройки коэффициентов коррекции использовать нейронную сеть, предварительно обученную на стандартные таблицы. Понятно что на фиксированной точке ее делать не имеет смысла, а вот на вашем плавающем ядре — запросто. Вкупе с использованием широкополосного лямбда-зонда можно попробовать вообще отказаться от ручного выкатывания прошивки. Целевой функцией можно сделать, кроме стехиометрии на средних режимах, например сигнал от акселерометра (в мощностном режиме)
Во-первых, толщина фольги неизвестна. Но даже если взять 50мкм, то сечение получается 0.025, и пуская по нему ток в 2А, мы получаем 80A/мм^2 — ни один разработчик в здравом уме не будет так делать, особенно если места навалом. Вы ведь вряд ли согласились бы подключить дома стиральную машину проводом 0.75 — а это всего лишь 12А/мм^2 — я понимаю, перегрев закрытого провода и все дела — но проектирование на пределе (без веских на то оснований) — не комильфо.
Да нельзя аргументировать качество конструкции Х часами успешной работы! Вы ведь, как программист, если видите потенциально опасное место (например, выход за границу массива, передачу null-указателя, потерю значимости, или переполнение) — стараетесь ведь пофиксить, а не говорите, что от подобной причины система еще ни разу не падала.
Представьте — напряжение чуть выше обычного, пусковой ток лампы — соответственно, тоже. Или однажды вы поставите лампу чуть большей мощности. Или программно захотите сделать красный-желтый перед зеленым — в каждом из этих случаев пусковой ток превысит маскимальный, выдерживаемый дорожкой, и она сгорит!
Да тут нечего «оптимизировать» — достаточно вывести дорожку, соединяющую катоды фотодиодов, из межвыводного пространства левее, в низковольтную сторону — тогда между низковольтной и высоковольтной частями будет зазор порядка 5-6 мм с учетом площадок. Текстолит под оптронами можно не просекать — оставшегося зазора с лихвой хватит. К сожалению, как ни крути, а плата попахивает непрофессионализмом — вместо трололо лучше бы действительно подумали о грамотной разводке — помимо зазоров, площадь дорожек для стартовых токов ламп накаливания (в пике 10*Iном) просто микроскопическая — по таким только логические уровни передавать. Я бы перемонтировал МГТФом, оставив плату, как крепежный элемент для деталей, не дожидаясь проблем ;)
Да, и затрудняет автоматическое дизассемблирование, хотя при построении дерева ветвлений CALL — одна из команд, после которой продолжение ветки, как кода, не гарантировано
Подобный способ я встречал при дизассемблировании 8051 кода, сгенерированного каким-то транслятором Си, когда константные параметры писались «под себя»
И насчет костылей обхода режима хитрой зарядки — мириться с падением на проходном транзисторе только из-за гарантированного старта — не очень здорово. LC4002 имеет выход ^CHRG с открытым стоком, на котором появляется низкий уровень при режиме зарядки батареи. С другой стороны, NCP1450 имеет управляющий вход CE, отпустив от нуля который, DC-DC включается. Может попробовать сделать инвертор на транзисторе, который поднимает CE после того, как ноль появился на ^CHRG (но тогда надо быть уверенным, что ответвитель зарядного тока в цепь питания DC-DC трактуется микросхемой, как зарядка), либо просто включить в цепь CE RC-цепочку, удерживающую его в нуле на время роста напряжения на конденсаторе.
Насчет доказательства корректной работы — все имхо тут сложнее, ибо даже многочасовой многопоточный прогон в стрессовых для механизмов синхронизации условиях не гарантирует абсолютную корректность работы. А испортить ее можно одним неосторожным коммитом, причем функциональные тесты при этом могут и не упасть — например, вложенным вызовом функций, запрещающих и затем разрешающих прерывания внутри своих критических секций, или наоборот — расчет на выполнение сервиса ОС в обработчике прерывания, которое оказывается при какой-то комбинации условий запрещенным — в обоих случаях, вуаля — прощай, стабильное ядро. И все это — кроссплатформенно.
И еще — аппаратная основа многопоточности — это возможность оставить свой контекст *целиком и без искажения* в стеке. Насколько я помню, некоторые архитектуры не позволяют это сделать иначе, как посредством аппаратного прерывания (возможность это сделать для последнего очевидна в силу самого принципа прерываний). Отсюда вывод, что алгоритмы ядра в части перехода процесса в ожидание, его реактивации (особенно по условию) и терминирования для таких архитектур должны быть реализованы с учетом этого факта — в частности, моментальные просыпания ожидающего события потока могут и не поддерживаться иначе, как симуляцией аппаратного прерывания например, через GPIO. Интересно, у вас этим моментам уделено внимание?
Каковы достигнутые конкурентные преимущества вашей RTOS относительно других, ради которых была проведена такая масштабная разработка?
Существует ли пруф корректной работы ядра в части работы с потоками и синхронизационными примитивами?
Однако, в любом случае подобная разработка — чрезвычайно интересное и полезное с точки зрения детального понимания механизмов работы компонетов ОС и взаимодействия их с ресурсами системы. Это, наверное, как художнику большое эпохальное полотно написать — трудно, долго, но очень увлекательно.
PS — я в 95м году написал либу на Си и Ассемблере, реализующую паралеллизм в реальном режиме x86 под Досом — со всеми переключениями контекста процессора и сопроцессора, состояниями процессов, своим менеджером памяти, очередями к нереентерабельным функциям доса и биоса, шедулингом, завязанным на таймер, привязанным другим аппаратным прерываниям (там была машина для управления оборудованием), и софтовым интам. Также был написан монитор состояния процессов на чистом асме с индикацией ресурсов, семафоров и статусов.
Помню, что управление тредами вызывало у меня ассоциацию с законом Мерфи — если уж вы открыли банку с червями… — так как породить тред было сравнительно просто, а вот грамотно придержать на ожидании ресурса, или убить внешними средствами — гораздо сложнее
PS — у меня есть F103 на eval board с питанием через USB и встроенным стабом 5 -> 3.3. Надо будет зацепиться после него и посмотреть, сколько он тянет. Плата там сделана нормально, утечек быть не должно
По даташиту RC-генератор вотчдога берет всего несколько микроампер, остальное — это скорее всего, тактирование периферии, если само ядро спит.
BTW, если будете специально тестировать low-power режимы, сообщите сюда плз — STM32 — прекрасная замена AVR в DIY-штуках, с Атмела пора уже слезать, но вот в автономном питании как раз и есть сомнения
Однако, кажется, есть еще один источник потребления — электретный микрофон с 10КОм в плюсовом плече. Если напряжение на нем порядка двух вольт, как Вы пишете, то свои 100 микроампер цепь его подпитки гарантированно забирает. Соответственно — запитать электрет можно также от выводов порта.
Перевес не страшен — погрешность оценки DC за пару секунд при холодном старте будет ничтожна по сравнению с флуктуациями постоянной составляющей микрофона от времени или от экземпляра к экземпляру.
Сигнал с микрофона симметричный, поэтому среднее значение не изменится при наличии шума на входе. Усреднять можно при подаче питания в течение нескольких секунд, и запоминать дальше на все время работы, чтобы не тратить ресурсы на скользящее среднее
1. Чтобы снизить потребление, потенциометр можно питать от вывода порта в активном режиме, и переводить его в 0 или Z перед засыпанием, и обратно в 1 при просыпании по началу дутья. Пот можно кстати взять движковый, тогда получится тромбон ;). И естественно, с характеристикой A
2. Значенние постоянной составляющей лучше все-таки вычислять усреднением и вычитанием среднего — параметры микрофона могут плыть со временем, да и требование индивидуальной прошивки под каждый экземпляр — не комильфо.
PS — ВЕ48 применялись еще, в частности, в клавиатурах ЕС-1840 и Искра-1030.
а) алгоритмов пуска, прогрева, холостого хода
б) экономичность и выбросы [если в US за это не прижмут, конечно — там вроде вмешиваться в системы, влияющие на emissions (например, ставить обманку лямбда-зонда) — чуть ли не уголовка]
в) вообще работу движка не на ВСХ. Достаточно лишь обеспечить более-менее хороший выход на ВСХ с частичных нагрузок, чтобы мотор не хлебал и не дергался
Однако, подбор углов УОЗ, фаз впрыска и AFR (они взаимозависимы!) по максимуму отдачи мотора вам придется делать по-любому
По делу — я не совсем уверен, что 100% поддерживаю выбранный вами путь — так как, по моему мнению, надежно управлять двигателем, с приемлемой точностью дозируя топливо, соблюдая тайминг зажигания, поддерживая несколько режимов работы, и обмениваясь с диагостическим оборудованием неплохо удается даже на 8-битных процессорах со скромной тактовой порядка 20 МГц и производительностью 4-5 MIPS (правда, не без аппаратной поддержки), а сам по себе переход на плавающее ядро никакой существенной выгоды не даст, ибо:
а) точность расчета смеси и зажигания не имеет смысла делать выше точности стоковых датчиков, и
б) работа системы в режиме обратной связи позволяет нивелировать как производственные, так и расчетные погрешности — систематические и случайные.
Некоторый эффект может дать только снижение ошибки управления из-за практического исчезновения дискретности как в алгоритмах коррекции, так и прямого управления. Однако, все это имхо — эффекты минус-энного порядка, так как основа хорошего управления — хорошая модель, и корректно покрывающие эту модель алгоритмы. Плавающие они будут, или целочисленные — уже не столь существенно
Поэтому я не уверен, что плавающее ядро само по себе — достаточное условие успеха проекта, и начинать надо именно с него. И наоборот, удачная модель будет хорошо работать независимо от способа реализации. То есть, я бы начал не с программирования, а с теории и практики работы ДВС.
Кроме того, практический анализ существующих прошивок говорит о том, что реальный продукт — это множественные костыли, костылики и воркэраунды, призванные эвристически сгладить недостатки теормодели — а значит, вам придется пройти весь этот путь еще раз, причем этот этап шлифуется не на эмуляторе, а на реальном моторе и реальной дороге (беговые барабаны в неограниченном доступе у вас вряд ли есть). И силами коммьюнити (в отличие от отладки софта) его не сделать — только в один тред — а значит:
а) путь будет долгим,
б) результат будет хорошо применим только к конкретному двигателю (это с натяжкой, но в целом так)
Навскидку, вам придется реализовать и отладить:
а) надежную детекцию режимов работы мотора (пуск, холостой ход, экономичный, мощностной, принудительный ХХ)
б) плавный переход между режимами
в) надежную работу в а) и б) при всем диапазоне температур ОЖ и ОВ
г) управление ХХ во всем диапазоне температур
д) алгоритмы пуска во всем диапазоне температур (существенно различаются для холодного — например, вы знаете, для чего при холодном пуске меняют фазы открытия форсунок?)
е) работу с датчиком детонации и УОЗ в диапазоне температур и нагрузок
ж) учет топливной пленки при расчете времени открытия форсунок
з) алгоритмы долговременной и кратковременной коррекции в режиме ОС
и) накапливание, обработка и вывод диагностической информации
итд
Вы к этому готовы?
Представьте — напряжение чуть выше обычного, пусковой ток лампы — соответственно, тоже. Или однажды вы поставите лампу чуть большей мощности. Или программно захотите сделать красный-желтый перед зеленым — в каждом из этих случаев пусковой ток превысит маскимальный, выдерживаемый дорожкой, и она сгорит!
Подобный способ я встречал при дизассемблировании 8051 кода, сгенерированного каким-то транслятором Си, когда константные параметры писались «под себя»