Вы изобразили скопление простейшей периферии. Задачу очередности включения периферии сейчас легко решают генераторы кода типа ModusToolbox, STM32CubeMX, e2studio и т.п. Тут как раз проблем нет.
Я говорил о задачах уровня middleware, которые надо поднимать после периферии. Такие как: стеки полевых шин, TCP стек и все прикладные протоколы поверх него, логеры, файловые системы и USB классы, BLE профили, GUI и проч. Там не построить каких-то простых однозначных графов. Поскольку эти задачи могут давать отказы на старте и их приходится деинициализировать и снова инициализировать. Какие-то, как файловые системы, могут уходить в долгое восстановление. Тут графы не работают, а массивы вредны. Только дебагинг и постоянный рефакторинг. Да еще не забыть, что задачи могут отключать, реинициализировать и включать периферию. Такой вообще не место в массивах.
Правильно, программист. А значит он должен долго дебажить все эти функции, пока не добъется правильного их порядка. Следовательно массив ему окажет медвежью услугу, превратив прямые вызовы в косвенные.
Вся инициализация идёт максимально параллельно в асинхронных функциях. И тогда мистический порядок вызовов не нужен и массив не нужен. А иначе будет не embedded дивайс, а черепаха с временем загрузки сравнимым с Windows.
Массивы удобны именно с точки зрения оформления кода, когда выровнены столбцы. И можно редактировать код блочными операциями. А в статье именно это удобство и не упомянуто, а в коде даже игнорируется.
Про "уровни отвественности" - какой-то непонятное определение. Если дивайс планируется для реально ответственных применений, то там вот такие делают схемы. В вашей архитектуре об ответственности явно думалось меньше всего.
Когда бывают разные напряжения питания, то сразу специфицируют верхнюю границу, делают аналоговые входы с делителями и работают во всем диапазоне.
Про удобство ремонта тоже не понял логику. Какое это удобство если надо заниматься двумя источниками вместо одного.
Вы там не нарастите так количестов выходов что прям понадобится более мощный источник для управления оптосемисторами или реле. Поставили источник на пару ампер и хватит за глаза для такой системы. Один пин на ваших разъемах специфицирован на 3 ампера.
"Грязное" питание по полной программе вы получите когда подключите два источника питания (особенно если они на разных фазах сидят) с двух концов этой этажерки. Даже оптроны не спасут от FTB помех. Кстати, не забывайте ставить резисторы и в подключенных к земле ногах оптронов.
Не нужен никакой внешний источник питания. Какой ток будут потреблять входы определяет сам контроллер, он же и ограничивает ток. Он же и контролирует замыкания во внешних цепях. Т.е. добавляет диагностику.
Диод в схеме управления реле не лучший вариант. Он замедляет отключение реле в 10 раз.
Все же такая многоплатная архитектура вызывает вопросы по цене владения. Тут дорого все. - Небольшая модификация межмодульной шины приведет к необходимости переделки всех плат. Либо дизайн быстро морально устареет. Уже сейчас восходит I3C и другие перспективные интерфейсы. - Узкая межмодульная шина удорожает дизайн из-за допролнительных микросхем расширителей IO - Такое количество плат обойдется дороже чем одна или две. - Печать уникального корпуса тоже дорого. - Собирать и разбирать такую сборку - трудоёмко. - Отлаживать осциллографом тоже нереально трудоемко. До промежуточных плат просто не добраться.
При всем при этом этом страдает помехоустойчивость, поскольку уже нет сплошного плэйна и помехи будут гулять непредсказуемыми путями. В цепи общей земли появляются существенные индуктивности вызванные разъемами. В догонку проприетарный медленный JTAG.
И только одинокий ESP32 как бы намекает, что по задумке наверно хотели сделать бюджетно.
Думаю если бы был конкурс на худшую архитектуру, то эта бы победила.
Есть очень разные места установки дисплеев. Например в одном нашем агрегате есть четыре дисплея, они не выведены наружу. Они внутри, их не видит юзер. Они только лишь для обслуживающего персонала, чтобы быстрее диагносцировать проблемы. Дисплеи настолько дешевы, что их дешевле ставить чем светодиоды. Но при этом они гораздо информативней.
Насколько там мелкий шрифт имеет мало значения. Гораздо важнее поместить максимум информации. Поэтому шрифт выбирается самый мелкий. Кому надо может посмотреть через камеру мобильника, он увеличит изображение.
Дисплей на I2C выносится в любое место и на любое расстояние на раз-два. Например дисплей моего ПЛК выносят на два метра. А он работает между тем по SPI на 20 МГц!
то конечно микродисплей типа такого по I2C подключит без проблем.
Но как он из этого сделает открытый фреймворк для разработчиков будет интересно. Конструкторы - нереально сложная вещь в плане программного фреймворка, да еще на ограниченных ресурсах памяти. Придется делать невероятно абстрактный и запутанный слой. Достаточно посмотреть на HAL известных производителей.
Возможно автор и не планирует дисплей. У него для дисплея даже нет подходящего интерфейса. Скорее всего планирует управлять со смартфона через браузер. Это ж всё упирается в сценарии использования. Хотя без дисплея их станет сильно меньше.
Когда делают такие конструктивы, то уже знают заранее всё что может быть размещено. Конструктив потому и рождается, когда есть полная ясность с его применением. Но общее правило - чем модули меньше, тем универсальней, если это только не силовые модули.
M5Stack, полагаю, был выбран из анализа размеров аккумуляторов и дисплеев на тот момент. И у них обособленная экосистема. Я бы не брал с них пример. Завтра аккумуляторы, модули и дисплеи станут меньше и они сами пожалеют о выбранных габаритах.
И все притензии по поводу ESP32S3 по ходу мимо. Там большое разнообразие микроконтроллеров со своими экосистемами. По сути next.module - это хардварная оболочка вокруг M.2 Вполне нормальный бизнес. Вокруг Arduino и Pi возникло много оболочек и неплохо живут.
Вот только модульность добавляет головной боли с логистикой. Думаю больше десятка плат в проекте не появится, да и то не все будут доступны. В этом плане придется делать как Flipper, предлагая шаблоны для сторонних плат.
На плате 6 слоев. И все залиты землей! Землей заливают в последнюю очередь. А потом землю еще пробивают переходными, чтобы не оставалось резонирующих островов.
Но фанатеть с переходными тоже нельзя, поскольку от этого зависит цена платы.
Интересно что вы используете как эталон, когда сравниваете точности пульсометров. Если ни один из них не точен, то и судить о их точности вам по идее нечем. Скорее всего за самый точный вы принимаете тот кто сильнее всего сглаживает, т.е. врёт.
Потом кажется несовсем правильным брать среднее от пульса. Человек не механизм, для него важнее влияние максимальных нагрузок, чем просто наличие каких-то нагрузок.
Я думаю интересней была бы медиана. Или даже пульсовая стоимость по формуле отношение меданы пульса к максимальному пульсу, а не по той что вы придумали. Кстати, откуда вы ее взяли? В вашей статье не хватает ссылок на сторонние исследования.
Я как раз сейчас занимаюсь исследованиями измерителей пульса. Там все печально. Даже Garmin Pro представляет собой слабое средство измерения. Применяют непонятное сглаживание. Акселерометр вычисляет фазы бега непонятно по каким критерям, работает только по ANT+ и только с их часами.
В этой индустрии все либо засекречено, либо хиромантия. Сенсоры в основном заточены на экономию батареек. Только поэтому они не ставят гироскопы, иначе батарейки быстро сядут. Из этого одинокого акселерометра на груди они вытаскивают своими эвристиками кучу сомнительных параметров включая фазы бега, амлидуду вертикальных осциляций, мощность и т.д. Но не могут их никак интерперетировать и осмыслить, сенсор то один.
Но поскольку их часы тоже должны быть экономичными они не могут себе позволить больше сенсоров.
Т.е. не стоит ориентироваться на массовые гаджеты, их возможности и сценарии использования. Они просто не затачиваются для исследований и оптимизации личного прогресса. Тот же VO2 Max измеритель легко делается из респиратора и доступных микросхем.
Про DSP вас кто-то ввел в заблуждение (может ChatGPT?). Не бывает ни КИХ, ни БИХ фильтров без задержек. Бывают короткие фильтры где задержка незаметна. Бегущее среднее есть КИХ фильтр, и он внесет очень сильную задержку. Поэтому и не можете его применить.
Если бы были фильтры без задержек в мире все бы управлялось идеально. А так у вас проблема управления собственным состоянием именно из-за дилемы: либо смотреть на шумы, либо запоздалая реакция. Нестабильность биологических систем и есть один из шумов, который надо фильтровать. Это не то что бы принципальная неэргодичность. Иначе бы вообще никакие методики бы не работали.
Оксигенация не вам должна давать доп. инфу, а фильтру Калмана. Как она там сыграет фильтр сам решит. Хуже в любом случае не будет.
А акселерометры и именно с гироскопами (просто акселерометры не подходят, они не дают полное представление о движении) должны быть на ногах и на руках.
А так моя мысль в том что графики малоинформативны потому что сильно зашумлены. Применить простую фильтрацию усреднением или БИХ фильтры вы не можете потому что получите из-за них лаг по времени и войдете в поведенческие осцилляции. Это когда будете повторять паттерны поведения с запозданием на изменения, и получите только рост выбросов в результатах. Технические системы так и идут в разнос или в пульсирующий режим.
Вам нужна фильтрация без лагов во времени. И такую фильтрацию дает фильтрация Калмана. Но для ее использования нужны сторонние каналы данных. Вот тут-то и надо подумать что еще измерять. Я бы подумал приспособить измерители окисигенации.
И как я понял конечная физическая величиина кторую вы хотите улучшить - это энергоэфективность организма в целом и при беге в частности. Может тогда технику бега регулировать? Тогда нужна сеть акселерометров c гироскопами.
Но по вашим графикам не скажешь, что что-то немедленно видно. Там тренды еле прослеживаются. Мне кажется проблема в малом объеме данных. Пульсометра явно недостаточно. Последние разработки для умной одежды делают по 1000 отсчетов сердечных ритмов в сек чтобы четче определять состояния организма.
Вы изобразили скопление простейшей периферии. Задачу очередности включения периферии сейчас легко решают генераторы кода типа ModusToolbox, STM32CubeMX, e2studio и т.п. Тут как раз проблем нет.
Я говорил о задачах уровня middleware, которые надо поднимать после периферии. Такие как: стеки полевых шин, TCP стек и все прикладные протоколы поверх него, логеры, файловые системы и USB классы, BLE профили, GUI и проч.
Там не построить каких-то простых однозначных графов. Поскольку эти задачи могут давать отказы на старте и их приходится деинициализировать и снова инициализировать. Какие-то, как файловые системы, могут уходить в долгое восстановление. Тут графы не работают, а массивы вредны. Только дебагинг и постоянный рефакторинг. Да еще не забыть, что задачи могут отключать, реинициализировать и включать периферию. Такой вообще не место в массивах.
Правильно, программист.
А значит он должен долго дебажить все эти функции, пока не добъется правильного их порядка. Следовательно массив ему окажет медвежью услугу, превратив прямые вызовы в косвенные.
Факт в том, что массивы тоже иногда неуместны.
Что это !?
Спрашивается, как узнать из этого кода какой порядок вызовов правильный?
И где тут те макросы которые были тут
Чтобы такое неприличное шаманство не делать, первым вызовом идет запуск RTOS.
А последним на старте идет ожидание флагов инициализации всех задач периферии.
Вся инициализация идёт максимально параллельно в асинхронных функциях. И тогда мистический порядок вызовов не нужен и массив не нужен.
А иначе будет не embedded дивайс, а черепаха с временем загрузки сравнимым с Windows.
Массивы удобны именно с точки зрения оформления кода, когда выровнены столбцы. И можно редактировать код блочными операциями.
А в статье именно это удобство и не упомянуто, а в коде даже игнорируется.
Про "уровни отвественности" - какой-то непонятное определение. Если дивайс планируется для реально ответственных применений, то там вот такие делают схемы. В вашей архитектуре об ответственности явно думалось меньше всего.
Когда бывают разные напряжения питания, то сразу специфицируют верхнюю границу, делают аналоговые входы с делителями и работают во всем диапазоне.
Про удобство ремонта тоже не понял логику. Какое это удобство если надо заниматься двумя источниками вместо одного.
Вы там не нарастите так количестов выходов что прям понадобится более мощный источник для управления оптосемисторами или реле. Поставили источник на пару ампер и хватит за глаза для такой системы. Один пин на ваших разъемах специфицирован на 3 ампера.
"Грязное" питание по полной программе вы получите когда подключите два источника питания (особенно если они на разных фазах сидят) с двух концов этой этажерки. Даже оптроны не спасут от FTB помех. Кстати, не забывайте ставить резисторы и в подключенных к земле ногах оптронов.
Однако и тут опять выбран самый дорогой путь.
В промышленных устройствах делают так:
Не нужен никакой внешний источник питания. Какой ток будут потреблять входы определяет сам контроллер, он же и ограничивает ток. Он же и контролирует замыкания во внешних цепях. Т.е. добавляет диагностику.
Диод в схеме управления реле не лучший вариант. Он замедляет отключение реле в 10 раз.
Все же такая многоплатная архитектура вызывает вопросы по цене владения.
Тут дорого все.
- Небольшая модификация межмодульной шины приведет к необходимости переделки всех плат. Либо дизайн быстро морально устареет. Уже сейчас восходит I3C и другие перспективные интерфейсы.
- Узкая межмодульная шина удорожает дизайн из-за допролнительных микросхем расширителей IO
- Такое количество плат обойдется дороже чем одна или две.
- Печать уникального корпуса тоже дорого.
- Собирать и разбирать такую сборку - трудоёмко.
- Отлаживать осциллографом тоже нереально трудоемко. До промежуточных плат просто не добраться.
При всем при этом этом страдает помехоустойчивость, поскольку уже нет сплошного плэйна и помехи будут гулять непредсказуемыми путями. В цепи общей земли появляются существенные индуктивности вызванные разъемами. В догонку проприетарный медленный JTAG.
И только одинокий ESP32 как бы намекает, что по задумке наверно хотели сделать бюджетно.
Думаю если бы был конкурс на худшую архитектуру, то эта бы победила.
Есть очень разные места установки дисплеев. Например в одном нашем агрегате есть четыре дисплея, они не выведены наружу. Они внутри, их не видит юзер. Они только лишь для обслуживающего персонала, чтобы быстрее диагносцировать проблемы. Дисплеи настолько дешевы, что их дешевле ставить чем светодиоды. Но при этом они гораздо информативней.
Насколько там мелкий шрифт имеет мало значения. Гораздо важнее поместить максимум информации. Поэтому шрифт выбирается самый мелкий. Кому надо может посмотреть через камеру мобильника, он увеличит изображение.
Дисплей на I2C выносится в любое место и на любое расстояние на раз-два. Например дисплей моего ПЛК выносят на два метра. А он работает между тем по SPI на 20 МГц!
Если он думает вывести пару линий из M.2,
https://cdn.sparkfun.com/assets/learn_tutorials/1/2/0/6/SparkFun_MicroMod_Interface_v1.0_-_Pinout.pdf
то конечно микродисплей типа такого по I2C подключит без проблем.
Но как он из этого сделает открытый фреймворк для разработчиков будет интересно.
Конструкторы - нереально сложная вещь в плане программного фреймворка, да еще на ограниченных ресурсах памяти. Придется делать невероятно абстрактный и запутанный слой. Достаточно посмотреть на HAL известных производителей.
Но интерфейса то нет! Значит не планирует.
А то сразу бы озаботился вместо Ethernet контроллера поставить тачскин контроллер или клавиатурный контроллер.
Возможно автор и не планирует дисплей.
У него для дисплея даже нет подходящего интерфейса.
Скорее всего планирует управлять со смартфона через браузер.
Это ж всё упирается в сценарии использования. Хотя без дисплея их станет сильно меньше.
Когда делают такие конструктивы, то уже знают заранее всё что может быть размещено. Конструктив потому и рождается, когда есть полная ясность с его применением. Но общее правило - чем модули меньше, тем универсальней, если это только не силовые модули.
M5Stack, полагаю, был выбран из анализа размеров аккумуляторов и дисплеев на тот момент. И у них обособленная экосистема. Я бы не брал с них пример.
Завтра аккумуляторы, модули и дисплеи станут меньше и они сами пожалеют о выбранных габаритах.
Да не трудно, размер минимизирован настолько чтобы на него помещались модули M.2 https://www.sparkfun.com/search/results?term=m.2
И все притензии по поводу ESP32S3 по ходу мимо.
Там большое разнообразие микроконтроллеров со своими экосистемами.
По сути next.module - это хардварная оболочка вокруг M.2
Вполне нормальный бизнес. Вокруг Arduino и Pi возникло много оболочек и неплохо живут.
Вот только модульность добавляет головной боли с логистикой. Думаю больше десятка плат в проекте не появится, да и то не все будут доступны. В этом плане придется делать как Flipper, предлагая шаблоны для сторонних плат.
На плате 6 слоев. И все залиты землей! Землей заливают в последнюю очередь. А потом землю еще пробивают переходными, чтобы не оставалось резонирующих островов.
Но фанатеть с переходными тоже нельзя, поскольку от этого зависит цена платы.
Интересно что вы используете как эталон, когда сравниваете точности пульсометров. Если ни один из них не точен, то и судить о их точности вам по идее нечем. Скорее всего за самый точный вы принимаете тот кто сильнее всего сглаживает, т.е. врёт.
Потом кажется несовсем правильным брать среднее от пульса. Человек не механизм, для него важнее влияние максимальных нагрузок, чем просто наличие каких-то нагрузок.
Я думаю интересней была бы медиана. Или даже пульсовая стоимость по формуле отношение меданы пульса к максимальному пульсу, а не по той что вы придумали. Кстати, откуда вы ее взяли? В вашей статье не хватает ссылок на сторонние исследования.
Я как раз сейчас занимаюсь исследованиями измерителей пульса.
Там все печально. Даже Garmin Pro представляет собой слабое средство измерения. Применяют непонятное сглаживание. Акселерометр вычисляет фазы бега непонятно по каким критерям, работает только по ANT+ и только с их часами.
В этой индустрии все либо засекречено, либо хиромантия. Сенсоры в основном заточены на экономию батареек. Только поэтому они не ставят гироскопы, иначе батарейки быстро сядут. Из этого одинокого акселерометра на груди они вытаскивают своими эвристиками кучу сомнительных параметров включая фазы бега, амлидуду вертикальных осциляций, мощность и т.д. Но не могут их никак интерперетировать и осмыслить, сенсор то один.
Но поскольку их часы тоже должны быть экономичными они не могут себе позволить больше сенсоров.
Т.е. не стоит ориентироваться на массовые гаджеты, их возможности и сценарии использования. Они просто не затачиваются для исследований и оптимизации личного прогресса. Тот же VO2 Max измеритель легко делается из респиратора и доступных микросхем.
Про DSP вас кто-то ввел в заблуждение (может ChatGPT?). Не бывает ни КИХ, ни БИХ фильтров без задержек. Бывают короткие фильтры где задержка незаметна. Бегущее среднее есть КИХ фильтр, и он внесет очень сильную задержку. Поэтому и не можете его применить.
Если бы были фильтры без задержек в мире все бы управлялось идеально. А так у вас проблема управления собственным состоянием именно из-за дилемы: либо смотреть на шумы, либо запоздалая реакция. Нестабильность биологических систем и есть один из шумов, который надо фильтровать. Это не то что бы принципальная неэргодичность. Иначе бы вообще никакие методики бы не работали.
Оксигенация не вам должна давать доп. инфу, а фильтру Калмана. Как она там сыграет фильтр сам решит. Хуже в любом случае не будет.
А акселерометры и именно с гироскопами (просто акселерометры не подходят, они не дают полное представление о движении) должны быть на ногах и на руках.
Давайте все что имеете. Очень интересно.
А так моя мысль в том что графики малоинформативны потому что сильно зашумлены. Применить простую фильтрацию усреднением или БИХ фильтры вы не можете потому что получите из-за них лаг по времени и войдете в поведенческие осцилляции. Это когда будете повторять паттерны поведения с запозданием на изменения, и получите только рост выбросов в результатах.
Технические системы так и идут в разнос или в пульсирующий режим.
Вам нужна фильтрация без лагов во времени. И такую фильтрацию дает фильтрация Калмана. Но для ее использования нужны сторонние каналы данных. Вот тут-то и надо подумать что еще измерять. Я бы подумал приспособить измерители окисигенации.
И как я понял конечная физическая величиина кторую вы хотите улучшить - это энергоэфективность организма в целом и при беге в частности. Может тогда технику бега регулировать? Тогда нужна сеть акселерометров c гироскопами.
Но по вашим графикам не скажешь, что что-то немедленно видно. Там тренды еле прослеживаются. Мне кажется проблема в малом объеме данных.
Пульсометра явно недостаточно. Последние разработки для умной одежды делают по 1000 отсчетов сердечных ритмов в сек чтобы четче определять состояния организма.
Однако не ясен целевой показатель.
Не ясно также есть ли опасность в слишком сильном снижении Ч.У.С.на.К-а.
Т.е. где здесь оптимум.