All streams
Search
Write a publication
Pull to refresh
206
0.5
Send message
В такой статье надо перечислять на каких конкретно чипах тестировалось.
В Kinetis на Cortex-M хаотичное сканирование периферии не инициализированной должным образом приведет к сбросу, без всякого bus fault.
Это только доказывает мои утверждения.
Т.е. были апноты и были факты уже до того как вы начали изыскания.
Может изысканий и не было, а была лишь проверка правильно ли работают акселерометры. Нужно было всего лишь реализовать по пунктам порядок действий из апнота.
Это не принижает работу инженера, наоборот, я считаю, что это суть работы стартапа.
Беда в том что инженеры нашедшие такие апноты и агрегировавшие информацию из них позиционируют это как изыскания, тем самым нивелируя смысл настоящих многолетних научных изысканий.
Но стартап находит возможность быстро найти применение вот таким открытиям. Нюанс в том, что такое желание возникает у сотен инженеров по всему миру. И тут важна гонка со временем.
Стартапер не исследователь, он гонщик.
Вот такой метафоры я бы вам предложил придерживаться.
«большой степенью вероятности» — одна из тех фраз, когда нет результата.
Снять осциллограммы — это не изыскания.
Приятно что вы отвечаете на мои возражения.
Я не то чтобы в пику, а просто хочу сам четче понять вашу тактику и сверить со своей по критерию наибольшего правдоподобия.
Скажу сразу, что метафоры про голубой и красный океаны (читал, знаю) я не признаю. Слишком уж не по теме встраиваемой электроники там приводятся примеры.
Далее, я не собираюсь обсуждать стартапы из горнорудной или, скажем, пищевой промышленности, т.е. отвлеченные от контекста статьи.

Так как ищут ниши стартапы?
Я видел много раз как это начиналось. Большинство стартаперов начинало продавцами. Продавцы имеют доступ к реверсу. Они изо дня в день смотрели динамику цен и оценивали себестоимость для изготовителя. А потом раз и выскакивали из чужого бизнеса и делали свой, когда начинали понимать всю цепочку.
И да у них очень мало времени, пока конкуренты не очухаются и не выкатятся на ту же нишу. На это уходит год. Год — это выставочный период. Все тусуются на одних и тех же выставках.

Скажем вот ваша фича с трекером — это не ниша.
За пять минут можно придумать и наговорить тучу арестантов как вы собираетесь применять акселерометр с частотой опроса с несколько секунд.
Но ничего вы вы там не выжмете пока на поднимете частоту опроса хотя бы до килогерц, но и сразу же потеряете экономичность.
Ниша была у вас была только в цене! И не знаю как вы меня сможете переубедить.
Задав себе границу цены вы можете там извиваться и ухищряться, придумывать некие «полезные» фичи, строить себе в облаках модель потребителя и проявлять креативность. Это броуновское движение может иногда приводить к повышению показателя цена-потребительская ценность, но фундамент уверенности — цена.

Да, вы можете настаивать в своей рекламе на неких новых ценных качествах, но цена им будет — копейки. Поскольку у стартапов нет времени проводить изыскания. Посмотрите, как фичи одного семейства микроконтроллеров появляются у других буквально через год. Никто никого сильно не опережает и не отстает. Лаг — один год или около того. Вот в таком промежутке и работает стартап. А иначе с чего бы он назывался стартапом?
Нет, ваше описание стартапа не соответствует общепринятому.
Стартап коротко живет, т.е. НИОКР и серьезная промышленность с их бюрократическими проволочками идут мимо.
И стартап занимается масштабируемой бизнес-моделью. Спец. ниши с заранее известным объемом потребления — это не масштабируемая модель.
Да и протекционизм в промышленности не дает той степени неопределенности какая есть у настоящих стартапов.
Т.е. стартап работающий на одного заказчика это как хищник выращенный в неволе. Т.е. ни то ни се.
Короче, личный мелкий бизнес — это одно, а стартап совсем другое.

Описанная история с трекером, а считаю, подана немного искаженно.
Начать надо было честно с того, что на тот момент уже была ясна высокая популярность трекеров и их завышенная по сравнению с себестоимостью цена.
Вот тут и копаем.
Следим за рынком, вскрываем все что под руку попадет и анализируем себестоимость. Если видим неадекватность, то объект наш.
Одновременно оцениваем алгоритмическое наполнение. В трекере с очень ограниченным ресурсом энергии применять инерциальную навигацию скажем будет утопией.
Но это не очевидно пока вы в теме дилетант.
Здесь находится основной риск, многочисленные ролики и открытые проекты могут создать ложное впечатление достижимости результата.

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

Словом что ни тезис в статье, то повод к сомнениям.
Честно не верю в стартапы что-то делающие и не имеющие перед глазами аналогов.
Если нужен НИОКР (R&D), то это уже не стартап, а прожигание кем-то выделенных денег.
Эт могут себе позволить работая за ученую степень или другие сторонние эффекты, но не за подъем бизнеса.
Железное правило стартапа — вливайся только в струю уже имеющую ясные перспективы. Т.е. копируй и улучшай.
Есть и другой способ. Добраться до закрытой элементной базы типа чипсетов Qualcomm или Broadcom (пример — Raspberry PI) или подобных и лепить не имея конкуренции в согласованной нише. Был бы у вас чипсет со встроенным GPS и GSM вы б писали совсем другие статьи.
Надо признать что в мире встраиваемой электроники существует огромная дискриминация.
Слегка она проскальзывает в жалобах на дешевых китайцев, но проблема не в китайцах.
Думаю осознав дискриминацию вы лучше поймете пути.
Еще вариант — написать или агрегировать просто огромный набор технологий и софта и развить бурную PR деятельность (пример — Arduino). Но это не для интровертов-разработчиков. Это даже не совсем разработка, а социальная технология.
О, даже вас не убило!
Меня десятки раз било фазой. В разных ситуациях.
Был случай даже в ванной. Схватился за металлический держатель который был прикручен к стене винтом который в стене прорезал изоляцию и касался фазового провода.
И тем не менее мы тут с вами переписываемся.
Статья противоречит бытовому опыту большинства.
Поэтому смело можно причислить ее к некого рода фэйку.
Ну а гугле, как известно, от фэйков не защищает, она их плодит.

Да, и про емкость я не с вами полемизирую.
Читать тяжеловато. Язык нелитературный, а текст при этом переполнен беллетристикой.
Не стоит так делать.
Алгоритм действий и идентификация от чьего лица он исполняется остался неясен.
Но скажу по опыту.
Все стартапы начинаются с реверса.

Т.е. все кто работал с электрикой касались пальцем фазного провода и их не убило. Максимум неприятные ощущения.
А когда фаза подносится к уху через изолятор наушников, то убивает.
Получается когнитивный диссонанс.
Емкость тела тут тоже притянута искусственно, почему бы тогда не рассмотреть человека как антенну и еще атмосферное электричество (100 В на метр). Просто страшно жить.
Статья подозрительная и тема путей воздействия напряжения на человека не раскрыта.

Молнии оставим в покое, при их прямом попадания в ближнюю электросеть жизнь не спасут никакие технические средства созданные человеком.
Но mbed нельзя просто так обновить и забыть, как Windows.
Я его затачиваю на реальное время, трачу силы на профилирование, на свои драйвера. Поэтому никакие изменения не могут пройти незамеченными.
Значит любую новую версию должен изучить с ног до головы, прежде чем переходить на нее.
Но такое изучение удобнее делать без лишних прослоек.
По крайней мере не придется изучать еще и json файлы.
RTOS от обычной OS отличается лишь детерминизмом. Т.е. в RTOS если измерили длительность переключения задачи, то она всегда такой и будет плюс-минус десяток тактов. Либо ставите жесткий таймаут после которого любой сервис должен вернуть управления.
В МАКС для измерений вставлен сервис профайлинга, как понимаю.
Т.е. первое что делаете с этой RTOS — это профилируете после своего компилятора. Когда сделан профайлинг, вы можете хоть разрешать хоть запрещать вытеснение (т.е. оставить только кооперацию), сути не меняет, детерминизма вы достигнете. Тем более что в МАКС вы по прежнему можете использовать прерывания уровня ядра без блокировок, т.е. достигать детерминизма на уровне долей микросекунды.
Посмотрел исходники.
Довольно интересно. Видно влияние Mbed.
Но не стали использовать шаблоны, это хорошо. В Mbed шаблоны несколько утяжеляют понимание.
Непонятно как работает защита стека. В чем ее функция? Если что-то пошло не так, то стек все равно не увеличить, т.е. как понимаю это не защита? а такое раннее предупреждение о крахе. Я правильно понял?
Что там за странные комментарии в svc_handler.S? У вас все хорошо с переключением контекста?
То что вы не запрещаете прерывания полностью, а только повышаете приоритет, эт хорошо, но в других осях еще умеют и объем сохраняемого контекста уменьшать для задач по выбору если задача не использует FPU.

Но беда всех таких самодельных RTOS в отсутствии какого либо промежуточного ПО.
Например Mbed идет с несколькими файловыми системами, со стеком TCP/IP v6 с TLS и IoT протоколами, с беспроводными протоколами, с отладочными мониторами Для защиты там целый супервизор разработан.
Чтобы RTOS без промежуточного софта, как я такие называю — голая, могла привлечь внимание за ее использование надо доплачивать.
Могу предложить портирование ОСРВ МАКС на свои платы с семейством Kinetis.

Проект под лицензией Apache 2.0
Т.е. без гарантий. Могу только сказать что светодиод моргает без ошибок уже целый час.
До АЦП еще не дошли руки.
Автор хоть и начинает статью с модульных тестов, но в его проекте на github сделаны интеграционные тесты. Он на самом деле не использует модульных тестов в своем проекте на микроконтроллере. Идет скорее спекуляция на громком названии.

Интеграционные тесты абсолютно необходимы если мы имеем дело с двигателями. Прежде всего для отлова проблем со сбоями и ошибками вызванными помехами или ошибками планирования ресурсов времени. Что автор старательно и выполняет, причем достаточно неэффективно, поскольку для таких тестов можно было бы и пользовательский интерфейс разработать на целевой платформе и инструментальные утилиты на PC.
Спорный вопрос в том действительно ли написание и отладка модульных тестов таких простейших функций, как в статье по времени сравнима с аппаратной отладкой.
Тесты конечно писать приходится, здесь спору нет, но это тесты действительно сложных вещей типа файловых систем, как например, вот эти
А функции работающие в жестком реальном времени проверять и надо в жестком реальном времени. Для этого у микроконтроллеров на ARM Cortex-M (Arduino делают и на них) есть механизм трассировки.
Проблему отладки управления шаговым двигателем он бы решил за пару минут.
Трассировочные вставки там тоже пришлось бы писать, но они во-первых очень короткие и могли бы остаться даже в релизном коде, во-вторых их можно написать не менее чем в 10 раз быстрее чем любые модульные тесты, и переделывать архитектуру кода этот подход не требует.
Смешно звучит фраза «Моторы, которые он ищет, называются «частотно-регулируемые приводы»»
Словно компетенция автора очень далека от этой сферы и он даже не собирается посмотреть что там глубже.
А я бы в первую очередь PLC Siemens и рассматривал как источник вируса.
Я б придумал такую теорию заговора:
Stuxnet — это муляж, прикрытие для настоящего источника вируса.
Сам вирус находится во Flash микроконтроллеров частотного преобразователя.
Либо он там сразу сидит, либо попал во время ремонтов или тех. обслуживания.
Возможно в SoC-ах частотников сидят микро RF приемопередатчики. Скажем замаскировать RF часть под микросхему гальванического изолятора. Тогда перепрошить их мог персонал дистанционно.
Все частотники соединены Ethernet сетью. Это стандартное решение у Siemens-а. Но протоколы в той сети проприетарные, и даже речи не идет о их контроле сторонним оборудованием. Т.е. у Siemens полная свобода и безнаказанность действий в локальной сети.
Самая сложная вещь во всем этом деле была поднять хайп вокруг флешек со Stuxnet чтобы никто не вспомнил про Siemens.
Кстати подъем частоты центрифуги в два раза вызовет увеличение потребляемой мощности в 4-е раза т.е. в квадрате. На такие скачки потребления мгновенно должна была среагировать автоматика, если она опять же не была от Siemens.


«Идеально» у меня даже Polar не работал. Пульсометры всегда периодически дают большие ошибки. Одни чаще другие реже.
Конечно пробовал. Это не работает.
Кожа сама должна стать влажной для этих сенсоров.
Просто их аналоговая часть сделана топорно.
Они используют штатный АЦП микроконтроллера на котором сделан Bluetooth, т.е. очень грубую периферию.
Имею опыт дешевого пульсометра с aliexpress. Все они одинаковые.
Не начинают измерения пока не вспотеешь. Т.е. на сухой груди не включаются.
Однако потом когда ремень пропотеет они не выключаются и продолжают сажать батарею даже когда ремень не надет. Менять батарею приходится каждый месяц.
Когда потихоньку начинают включаться запросто могут выдавать пульс в >200 ударов в минуту, не фильтруют заведомо ложные данные. В тренажерном зале где много народа, могут быть заглушены другими пульсометрами.
Потом наступает момент когда грудной ремень просто перестает нормально работать. На нем ведь токопроводящие площадки. Так китайский ремень у меня через пару месяцев и стирок сильно деградировал. Причем шло это постепенно, почему и понял что дело в ремне.
Склоняюсь к более надежным сенсорам типа Polar H10
Про зеленые и красные огни на крыльях похоже на байку.
Часто бываю в офисе стоящем у одного из концов взлетной полосы. Смотрю как самолеты снижаются прямо на меня и ни разу! не видел на концах крыльев ни красных ни зеленых огней.
Фары есть, у кого сколько, от одной до четырех, но цветных огней не видел.
Да и посмотрите на фотки в Google ночных посадок.

Information

Rating
2,051-st
Registered
Activity