Pull to refresh

Comments 24

1. Зачем вытягивать максимальное время переключение светодиода на сферической в вакууме задаче? на практике если его не хватает — то пересматриваем требования и структуру, если нельзя то ставим CPLD и получаем сразу максимальное время реакции на уровне 10нс и меньше.

2. Извините, но IoT тут причём? И где управление входами, и где силовое управление и всякие оптронные и тиристорные включатели чтоб лампочку и прочую нагрузку включить? Где модули связи (антенну на плате какую-то вижу, но в статье про неё не слова). Где внешние датчики и внутренние хотя-бы (температура и напряжение питания на МК например)? Вещь в себе пока что вижу. Остальное не вижу.

3. Зачем автомат состояний на светодиоды вообще нужен? Мне вот например интересен автомат состояний на измерение аналоговых величин при помощи ДМА и хотя-бы с усреднением и медианной фильтрацией. Или автомат управления тиристором для ловли перехода через ноль. Вот это интересно особенно если подключить их парой строк можно — мне лет 10 назад надоело делать свои велосипеды каждый раз на такие тривиальные случаи.

4. почему качество кода такое… хм, хм… странное? и откуда взялись все эти волшебные константы 0 + LSHIFT(0x00, 19) + LSHIFT(0x00, 18) и тд? эту магию может кто-нибудь когда-нибудь всё таки нормальными константами уже написал… надеюсь? Можно нормальную либу хотя-бы на регистры -самого МК? Или как нибудь можно это не делать в комментариях мне самому?

5. Зачем терминал VT100? Очистку экрана при желании можно сделать кучей \n\r. Я то думал будем рисовать менюшки псевдографикой и мышью управлять? (классная тема кстати, особенно для производственных прошивок к которым некогда делать нормальный виндовый интерфейс)

6. Честно не понял зачем контроллеру так быстро включаться? ну будет не 3мс а 50...100мс, чего плохого? всё равно его основной цикл работы вход в сон или глубже если делать упор на энергопотребление?
и ещё добавлю:
Советую поглядеть в сторону нормальных сред с полностью открытыми исходниками на все библиотеки.
Стремление использовать ассемблер, недоверие к сторонним библиотекам и прочее, я часто видел у людей которые пишут на IAR и Кейл.
Давно всё что надо писать на асме написано за Вас самим АРМ консорциумом, разработчиками ОС и тд.
И вообще не пишите на ассемблере, он не для того создан. 21 век в конце концов.

Не используйте задержки на НОПах. За них по рукам давали ещё во времена ДОС, в мк давно есть таймера и разнообразные счётчики тактов с системным таймером. Они удобны, честно!

«Т.е. получаем частоту в 90 МГц на светодиоде.» — по осциллографу я вижу частоту чуть меньше чем 90мгц, всё таки одна инструкция перехода никуда не делась. Не удалось сделать из мощного МК простой генератор стабильной частоты без джиттинга.
Критика это здорово, просто статья «не для вас» написана, мне кажется. Автор старался на простых примерах всё разжевать для любителей ардуино, и понизить порог вхождения для простых смертных.
На ЭТИ простыни кода которые назвали «простыми примерами» Вы вообще смотрели? Их прокручивать то замучаешься!
Да ардуино тут рядом не стоял! это антипод ардуино потому что автор отрицает готовые библиотеки «Поэтому я всегда начинаю с создания _своей_ минималистичной библиотеки функций работы с периферией.»

В статье проблемы:
1. Адовый быдлокод (даже констант нормальных именованных нет, про макросы типа LSHIFT, BIT и тд я вообще молчу).
2. Велосипедостроение (долой сдк!)
3. Самопротиворечия (на асме задержка якобы идеальная… пока прерывания не включились, но при этом на осциллографе видим «Странные паузы между пачками монотонных переключений — это задержки при считывании блоков кода из Flash»)
4. Явные ошибки включая метрологические и несоответствие осциллограмм и текста.
5. Ассемблер там где он не нужен и даже недопустим (задержка и первичная инициализация МК файл стартапа)
6. Решение надуманных проблем (зачем то надо превратить контроллер в делитель частоты на два или генератор 90Мгц — очень частая задача!).
7. Оверинжениринг и подключение непонятно зачем лишних библиотек и технологий (время включения 3мс и VT100 терминал ради очистки экрана).

это как учить новичка сортировке назвав пузырьковую сортировку слишком сложной и «давайте сравнивать и менять местами в случайные пары элементов массива, если массив в 10 элементов то через миллион случайных сравнений он точно будет отсортирован» а потом героически решить проблему миллиона сравнений сведя её до 1000 но оставив рандом.

нет, давайте учиться сразу правильно.
и вообще определитесь, или мы скетчи пишем, или вспоминаем 90ые — пишем на ассемблере простыни на тривиальные действия.
Эта статья для разработчиков. И конкурирует этот проект не с ардуино. Просто стало забавно как заморочено все в ардуино и по сути ардуино довольно закрытый фреймворк.

Быдлокод не быдлокод, но я проповедую рефакторинг. Это значит что за секунды я могу превратить LSHIFT, BIT в ">>" или "<<" или во что угодно.
Это не должно напрягать разработчика. Выбор имен у меня диктуется исключительно моими представлениями о красивом форматировании. В статье к сожалению невозможно воспроизвести оригинальный вид этих исходников в моем редакторе кода.
Поэтому остается верить что там он красивее. Простыни также выглядят совсем не простынями.
Кто видел что творят автогенераторы кода типа Kinetis Design Studio или инструменты подобные STM32 CubeMX тот должен оценить.

Задержка помещается в 32-е команды, если внимательно читали то должны понять нюансы размещения и использования этой задержки.

Насчет ассемблера ваша мысль не ясна. Пару дней отладки, и любой разработчик будет знать ассемблер на зубок, хочет он того или не хочет.

Статья не для начинающих программистов, а для тех кто начинает осваивать платформу KInetis.
Поэтому внимание концентрируется на отличиях от других платформ или на вопросах которые не раскрываются обычно, но приводят к необъяснимым результатам.

А примеры приложений я еще не окончил публиковать. У меня есть и с десяток реализаций медиан со сравнением быстродействия алгоритмов. Так что про сортировку может еще напишу…


«Задержка помещается в 32-е команды, если внимательно читали то должны понять нюансы размещения и использования этой задержки.»
проблемы задержки:
1. включаем прерывания и она съезжает и уже не 20мс а 22 или 50мс в зависимости от загрузки проца в прерываниях.
2. Сменили тактовую и она не 20мс а 160мс.
3. Будут проблемы с разными компиляторами и разными режимами инструкций.
И вообще зачем делать такую тривиальную вещь ТАК грубо?
Аналогично относится к стартап файлу — зачем он на асме?
средств Си не хватает?
Пожалуйста изучите документацию на GCC (атрибуты и секции линковки и LD файл) — они не кусаются!

«Пару дней отладки, и любой разработчик будет знать ассемблер на зубок, хочет он того или не хочет. „
Извините но на календаре не 90ые!
Это как надо не доверять компилятору или не уметь им пользоваться чтоб такое утверждать?
Я за много лет так и не выучил написание кода на асме для АРМ потому что это реально не нужно.
Мне хватает примерно прикинуть кол-во инструкций и примерно и очень грубо понять что куда пересылается и дальше PUSH/MOV не знаю.

Спасибо но для пик микро и 8051 накодился на асме в 90ых ВДОВОЛЬ! и был страшно рад как только нормальные компиляторы Си для них вышли и сразу забыл как страшный сон.
Хочу отметить что GCC и другие компиляторы я рассматривать больше не буду, поскольку уже сделал выбор компилятора.
Сравнения компиляторов я проводил много раз на своей практике. И даже дал ссылку на статью с исследованием.

Задержка с точностью до такта нужна для калибровки таймеров и правильности настройки системных частот.
И признаюсь эта задержка единственный такой длинный фрагмент на ассемблере который я написал за последние 10! лет.
Так что в предыдущих и следующих статьях вы вряд ли увидите что-то от меня на ассемблере.

Помимо того, что сказал Mirn, — у вас банальная каша в подаче материала. То есть, непонятно, зачем вообще вы совершаете минимум половину пассов руками.

Почему именно эта платформа? Почему именно эти чипы? Какое отношение всё это имеет к IoT (ответ: никакого)? Зачем вы проводите такие процедуры, какой смысл имеет то же время включения и не всё ли равно нам, 20 мс там или аж целых сорок (ответ: в 99,9999999 % случаев — всё равно)? Нафига вы, заявив IoT (ответ: для красного словца), дальше работаете не просто без RTOS (ответ: а нет для этой платформы приличных RTOS), а ещё и пихаете куски на ассемблере?

Есть такое магическое выражение — use case. Оно должно отвечать на вопрос «зачем всё это?». Вот у вас ответа я не вижу, а вижу какую-то беспорядочную кашу.

Ну то есть вы не поверите, но для примерно 99,9999999999 % людей «освоить Kinetis for the sake of it» не является значимой целью в жизни.
Я думаю Kinetis все сильнее будет теснить STM после покупки Freescal-а корпорацией NXP. Поэтому все больше разработчиков будет поглядывать на Kinetis.
Я оцениваю их число в пару десятков тысяч.
Этого достаточно чтобы писать статьи на эту тему.

Почему эта платформа, я стараюсь показать во всех своих статьях. Первые статьи есть на хабре.
Там же есть и перечисление более сложных разработок.

Темы я беру из форумов по мотивам обсуждений. Это точно не надуманные use case, а вопросы интересующие электронщиков.
Хотя может и наивные для кого-то.

Конкретно как связать интернет с модулем я планирую описать позже. Не вижу смысла начинать с конца.
И операционки есть, и не одна.
Словом не торопите события.

Messed in so many ways I can't even count them all.

Ну то есть, у вас опять какая-то каша.

У вас в заголовке слова «интернет вещей». При чём тут какой-то STM? STM нет в IoT, потому что для IoT таки нужна связность, а у STM с SoC с радиочастью примерно никак. В IoT есть TI, Semtech, Nordic, Axsem, вот этот ваш Freescale/NXP. А STM — нет.

Почему эта платформа, вы пока не показали вообще никак. Ну платформа. Ну микроконтроллер. И что? Мы сейчас используем CC1310 и CC2650, имеет с них смысл переходить на KW40Z? Не имеет.

Зачем вы что-то берёте в форумах, а отвечаете здесь? Вам не кажется, что читателям было бы интересно видеть, не только ответ, но и собственно вопрос? Я вот не могу представить себе реального случая, в котором критично время старта процессора из POR — так может, вы мне расскажете? Или вы тоже его не представляете?

Связать модуль с интернетом можно тремя десятками способов. Можно ардуину связать с интернетом, причём за пять минут. В IoT, однако, есть набор общепризнанных протоколов — ZigBee, 6LoWPAN, LoRa и т.п. Для них есть реализации сетевых стеков, например, в проектах на 6LoWPAN обычно используют ОС Contiki или более новую RIOT.

Оно для вашего чипа есть? Я не вижу. Contiki его не поддерживает. RIOT его не поддерживает. FreeRTOS поддерживает, но там с сетевым стеком примерно никак.

Или вы планируете по UART через внешний модуль связываться, в лучших традициях ардуины? Поднять на KW40Z блютус и посмотреть на него со смартфона?

Я не уверен, что это те события, которые вообще имеет смысл торопить.
Сетевые стеки не привязаны ни к какой RTOS. Поэтому я не думаю что буду описывать стеки вместе с какой-то OS.
Тот же LoRa или 6LoWPAN c успехом будут работать и без OS и на FreeRTOS и на uCOS.

Потом не забывайте что это не рекламная статья и стоит меня провоцировать на рекламу.
Я пишу о том, что мне нравится и что востребовано сообществом по моим наблюдениям.
Тот же LoRa или 6LoWPAN c успехом будут работать и без OS и на FreeRTOS и на uCOS


Конечно, будут! Вам просто надо взять сторонний сетевой стек, выбрав стабильно работающий на вашей архитектуре, а потом сделать прослойку между ним и вашей ОС, потому что без ОС вы в общем случае ничего сложного писать не хотите, если, конечно, у вас нет мазохистских наклонностей (впрочем, после вставок на ассемблере и дрыгания ножкой в цикле я уже не уверен).

Тот же LoRa или 6LoWPAN c успехом будут работать и без OS и на FreeRTOS и на uCOS


Вот только соотношение геморрой / бенефиты реализации IPv6 или LoRaWAN на всём этом будут такие, что никто в здравом уме этого не делает. И за то время, пока вы будете IPv6 запиливать без ОС, конкурирующая контора не только решение на RIOT продаст заказчику, но и успеет уже радостно пропить заработанное.

Потом не забывайте что это не рекламная статья и стоит меня провоцировать на рекламу


Дорогой друг, я вас провоцирую на то, чтобы вы прямым текстом сказали — на черта мне переходить на KW40Z. Потому что если мне на него переходить не надо — то тогда, видимо, другим IoT-разработчикам тоже не надо, а значит, вашу следующую статью надо начинать со слов «Извините, в прошлый раз я ошибся с выбором платформы для Интернета вещей».
>Насчет ассемблера ваша мысль не ясна. Пару дней отладки, и любой разработчик будет знать ассемблер на зубок, хочет он того или не хочет.
Смею с Вами не согласиться.
Сам начинал embedded путь с завета уважаемого DIHALT и писал на ассемблере для AVR, потому понимаю этот самый ассемблер для AVR и могу читать свободно.
Сейчас пишу для различных платформ — stm32, stm8, atxmega и не припоминаю случая, чтобы мне пришлось глядеть, что творит компилятор.
Возможно, это не такой востребованный навык?
Извините, но IoT тут причём?


А его сейчас модно в любую тему пихать, чтоб был. Есть Wi-Fi — IoT. Есть Bluetooth — IoT. Дико избыточная 6-слойка с огромным и дорогим процессором, на которую ради ZigBee поставили ещё один процессор — тоже IoT. Мигаем на ней светодиодами — считай, целый IoT-проект сделали.

И пофигу, что ни один вменяемый человек это в настоящем IoT использовать никогда не будет. Писать «изучаем работу с микроконтроллерами NXP» теперь нельзя, потому что надо про IoT.

KW40Z сам по себе был бы интересен в IoT, но… автор, а стек 6LoWPAN на него есть?
+1

Помню 10 лет назад научник вернулся с заседания президиума РАН, где обсуждалось перераспределение денег в сторону более модных в то время направлений, со словами:
— Всё, меняем название наших работ. Записывай: "Нанотехнологии, исследование крупномасштабных структур в галактиках"

Шутки шутками, но мода обязывает делать странные вещи…
Шутки шутками, но мода обязывает делать странные вещи…


Так она не обязывает, вот в чём проблема. Это просто карго-культ — «давайте теперь везде будет этикетка IoT»; при этом без этикетки будет ничуть не хуже, а местами даже лучше — но вера в этикетку непоколебима.

Причём эта движуха настоящему IoT на самом деле помогает, правда, немного косвенно: когда люди понимают, что из ардуины и вайфая они себе ни SCADA, ни АСУНО не сделают, к ним можно придти с коммерческим предложением на нормальную систему.

P.S. Посмотрел, что у KW40Z с IoT. А ничего. Рекомендуемая операционка — FreeRTOS, ни в Contiki, ни в RIOT поддержки чипа нет.
с огромным и дорогим процессором

HS USB наверно сильно хотелось.
A всякие там IoT в реальной жизни нафик никому не нужны, да и не знает никто что это такое. )))
A всякие там IoT в реальной жизни нафик никому не нужны, да и не знает никто что это такое. )))


Здесь я не просто смеялся, здесь я от души хохотал.

Ну то есть если вы чего-то не знаете — это не значит, что остальные придерживаются той же позиции.
А можно пример IoT устройств, которыми пользуется не только разработчики этих устройств? Кроме NEST ничего не приходит в голову.
http://www.cisco.com/c/dam/en_us/solutions/industries/docs/manufacturing/c36-732293-00-stanley-cs.pdf
http://www.cisco.com/c/dam/en_us/solutions/industries/retail/downloads/bc-hydro-cisco.pdf

Подойдёт?

Вообще промышленные системы сбора данных и управления всех их сортов уже начали переезжать на типовые IoT-технологии и по железу (IP-сети, беспроводные сети), и по методам сбора и обработки данных, и будут очень активно это делать ближайшее десятилетие. Более того, этими системами обзаводятся отрасли, в которых классические технологии неприменимы вообще или применимы плохо — конвейер ещё туда-сюда, но в сельском хозяйстве к датчикам состояния почвы, например, RS-485 проложить проблематично.
А для простых людей есть что нибудь, ну так стоб в быту?
Старый добрый умный дом? Zigbee, Z-Wave, SmartThings там всякий?
Спасибо, интересные статьи.
Правда, уже в трёх статьях так и не затронута тема IoT.
Жду продолжения!
Господа, зачем же вы автора так клюёте? Такими темпами мы рискуем не увидеть четвёртую часть. Замечаний много справедливых, но в целом очень любопытно, что автор из этого всего сделает, какое же IoT-устройство появится.
Sign up to leave a comment.

Articles