AVRASM: Диспетчер задач RTOS 2.0 (псевдо кооперативная ОС)

AVR
Отрефакторил код «Диспетчера задач RTOS» (псевдо кооперативной ОС), оптимизировал и универсализировал, добавил новые фичи, декларировал чёткое API, и опубликовал на GitHub… Фактически, весь код был переписан сызнова, по прототипу DI HALTа.

Operating system placement


Назначение


«Диспетчер задач RTOS» предназначен для решения нескольких независимых параллельных задач на одном микроконтроллере (реализация многозадачности).

Главной особенностью этой примитивной ОС «Диспетчер задач RTOS» является: исключительная простота и малый объём служебного кода! Позволяющие использовать данную ОС даже на самых слабых микроконтроллерах (вплоть до семейства AVR8L CPU: ATtiny10, ATtiny20, ATtiny40).

Быстрый и легкий в освоении «Диспетчер задач RTOS» предназначен для решения относительно простых задач, с небольшим объёмом кода. Для сложных задач, с тяжёлой математикой и сложной логикой — лучше использовать другие полноценные промышленные кооперативные RTOS (e.g. Salvo, SCM или AVRX)…

Новые функции (анонс)


1) Универсальный код инициализации RTOS_INIT: единственное что нужно, это вручную сконфигурировать несколько констант (режимных параметров). При использовании аппаратного таймера Timer/Counter0 (по-умолчанию) — настройка его аппаратных регистров, конфигурация режимов, производится полностью автоматически.
Поддерживаются ВСЕ МИКРОКОНТРОЛЛЕРЫ AVR (кроме семейства ATxmega): от самых мелких (ATtiny10), до разумно больших (ATmega64). Добавлена поддержка семейства AVR8L CPU… Разумеется, полная универсальность и совместимость со всеми МК сейчас не гарантируется — код нужно ещё проверить, и возможно допилить, с помощью Сообщества.

2) Вдобавок к «Базовой диспетчеризации задач» (последовательный запуск, в порядке очереди) и «Диспетчеризации Задач по Таймеру» (безусловно отложенный запуск на миллисекунд), добавлена поддержка «Флаговой автоматизации» (Диспетчеризация Задач по состоянию бита в Управляющем Регистре/Порте или в ячейке SRAM: запуск, если бит в байте установлен? Или, если бит в байте снят?)

3) Директивами условной компиляции можно отключать отдельные возможности RTOS, уменьшая размер ядра и используемую оперативную память (оптимизация под простые задачи и слабые МК).

4) Чётко декларированный API, для разработки прикладных Задач (читай комментарии в коде, чтобы здесь не повторяться).

И многое другое…

Код

Код «RTOS» опубликован на GitHub (это веб-сервис для хостинга IT-проектов и их совместной разработки), на условиях лицензии MIT (разрешительной opensource, т.е. практически без ограничений к использованию). Авторство и Copyright (C) 2014 «Сообщество EasyElectronics.ru». Ответвляйтесь!

Релизы:


Kickstart Kit: Обратите внимание, что код RTOS поставляется в комплекте с «Шаблоном нового проекта» — интегрировано, для мгновенного старта разработки программной прошивки (firmware) в среде «AVR Studio 4»… Здесь, чистый «Шаблон + ОС», без прикладного кода. Код содержит единый стиль форматирования, и комментарии с рекомендациями и описанием секций кода…
Код самого «Диспетчера задач RTOS» расположен в трёх отдельных файлах: «RTOS_data.inc» (данные), «RTOS_macro.inc» (API), «RTOS_kernel.inc» (ядро).

Зависимости: После рефакторинга Celeron, в коде RTOS используется, и требует подключения, нестандартная внешняя «Библиотека базовых Макроопределений (macrobaselib.inc)»… Последнюю версию которой, можно скачать на GitHub...


Примечание: GitHub был выбран для распространения кода — как наиболее прогрессивный, удобный и функциональный метод взаимодействия opensource-разработчиков. Развивайте и дополняйте код — затем, сможете легко контрибутить...

Ликбез для неискушённых пользователей: те кто не используют системы управления версиями, могут просто скачать архив с кодом: нажав на кнопку «Download ZIP» на странице репозитория GitHub, по ссылкам выше.

Настройка системы


  1. Основной файл, в котором производится настройка режимов Системы: «RTOS_macro.inc» (API). Здесь, директивами условной компиляции, нужно выбрать те функции RTOS, которые требуются для решения задачи — это обусловливает всю дальнейшую разработку прикладного кода (какие методы API будут доступны; как разделяются РОН между прикладным кодом и системными методами; и т.п. фундаментальные вещи). Это нужно выбрать в первую очередь!
  2. Также, требуется настроить: размеры системной «Очереди Задач» и «Пулов Таймеров» и «Выжидателей», в файле «RTOS_data.inc» (данные).
    Замечу: Переполнение очереди и пулов — деструктивно, для логики многих Задач! ОС это не завалит, но может привести к сбоям или «зависаниям» отдельных задач… Что делать? Используйте ловушку RTOS_METHOD_ErrorHandler, для выявления ситуаций переполнения, на этапе отладки устройства.
  3. А ещё нужно подкрутить: константы Настройки Скорости МК (CPU clock) — в макросах инициализации RTOS_INIT, USART_INIT… (их невозможно настроить автоматически, нужно править вручную)


Итак, директивами условной компиляции можно отключать отдельные возможности RTOS, уменьшая размер ядра (оптимизация под простые задачи и слабые МК):
.EQU	RTOS_FEATURE_PLANTASK = 1		; поддержка Базовой диспетчеризации задач
.EQU	RTOS_FEATURE_PLANTIMER = 1		; поддержка Диспетчеризации Задач по Таймеру
.EQU	RTOS_FEATURE_PLANWAITER = 1		; поддержка Флаговой автоматизации

;.EQU	RTOS_OPTIMIZE_FOR_SMALL_MEMORY = 1	; используйте это только для самых младших МК!


«Базовая диспетчеризация задач» (RTOS_FEATURE_PLANTASK) строго необходима для работы всех функций RTOS! При её отключении — отключаются и все другие функции RTOS. «Базовая диспетчеризация задач» обеспечивает: инициализацию RTOS; поддержку «Очереди Задач»; функцию «Добавления Задачи в очередь»; и «Диспетчер очереди Задач» (системный метод, который обрабатывая Очередь, непосредственно запускает Задачи на выполнение). Замечу: «Служба таймеров RTOS» (занимающая аппаратный таймер) не требуется в этом «базовом режиме», и отключена.

Вдобавок к базовому функционалу, Задачи можно «диспетчеризовать по Таймеру» (RTOS_FEATURE_PLANTASK): выполнять безусловно отложенный запуск на фиксированное время, равное целому числу миллисекунд. Эта функция особенно часто востребована при решении задач — используется вместо тупой задержки «пустым циклом CPU».

Наконец, поддержка простейших «Флаговых автоматов» (RTOS_FEATURE_PLANWAITER) — призвана заменить Архитектуры, построенные на Суперцикле + Флаговый автомат. Позволяет диспетчеризовать Задачи по состоянию одного конкретного бита в оперативной памяти (в РОН, Управляющем Регистре/Порте, или в ячейке SRAM). Запуск задачи откладывается на неопределённое время, пока этот указанный бит не будет «установлен» или «снят» (условия запуска программируются при постановке Задачи в Пул). Уточню: таким образом, здесь, управление Задачей не может осуществляться группой бит, в одном или нескольких байтах — нет, автомат простейший, способный отслеживать только один бит…

Код каждого из трёх вышеозначенных режимов подвержен модификатору «Оптимизации под малую память» (RTOS_OPTIMIZE_FOR_SMALL_MEMORY) — рекомендуется использовать его только для самых младших МК, с малым объёмом памяти! Включение «Оптимизации под малую память»: отключает в системных методах RTOS защиту «временных регистров» стеком; отключает некритичные проверки целостности данных; выкидывает второстепенные методы из ядра; отключает всё что только можно — чтобы минимизировать объём кода RTOS, и главное, минимизировать используемый/требуемый объём ОЗУ/стека.

RTOS v2.1:
В режиме со включенной оптимизацией RTOS_OPTIMIZE_FOR_SMALL_MEMORY, для работы Системы — в Стеке требуется гарантированно оставить [всего лишь] 8 байт (восемь) байт! При этом, из кода Задач, можно вызывать Подпрограммы одного уровня вложенности (в т.ч. PLAN_TASK-методы)… Напомню: Ещё требуется выделить SRAM под «Очередь Задач», «Пулы Таймеров» и «Выжидателей» (настраиваются в <RTOS_data.inc>)… Оставшееся ОЗУ — можно использовать для прикладных данных.

Например: на МК ATtiny10 (при 32 байтах SRAM), можно использовать RTOS:
	с одним Таймером (-3байта) 
	и одним Флаговым Автоматом (-3байта), 
	и очередь глубиной 5шт. Задач (-5байт), 
	не забыть про Счётчик "таймерной службы" (-1байт); 
	ещё (-8 байт) на Стек для RTOS; 
	остаётся 12 байт SRAM на прикладную логику (10 на данные + 2 про запас). Profit!
	/Замечу: при этом, в сегменте кода, вся система будет занимать 350-450 байт - остальное на прикладную логику./


Итого, выходит 6 вариантов (фрагментов) кода ядра: 3 фичи по 2 варианта (полный и обрезанный). И 8 режимов компиляции… При этом, код грамотно обёрнут макросами условной компиляции так, что при любой комбинации режимов — стандартный Дистрибутив будет компилироваться без ошибок. При отключении всех фич RTOS — функционал будет эквивалентен простому «Шаблону нового проекта».

Результирующий объём ядра RTOS в сегменте кода, в зависимости от выбранных режимов компиляции (сводка):

RTOS v2.0:
Результирующий объём ядра RTOS v2.0 в сегменте кода,  в зависимости от выбранных режимов компиляции (сводка)
RTOS v2.1:
Результирующий объём ядра RTOS v2.1 в сегменте кода,  в зависимости от выбранных режимов компиляции (сводка)
Примечание: К этому нужно прибавить ещё код базовой инициализации МК (это исключая инициализацию RTOS), таблицу прерываний и т.п. (+80..100 байт). Не забудьте также, кроме кода Задач (+X байт), прибавить размер «индексной таблицы» RTOS_TaskProcs (в базовом шаблоне: 10 задач = +20 байт).

Доступные методы прикладного программного интерфейса RTOS (API), в зависимости от выбранных режимов компиляции (сводка):

Доступные методы прикладного программного интерфейса RTOS (API), в зависимости от выбранных режимов компиляции (сводка)

Идеология системы


«ЗАДАЧИ кооперативной RTOS» — это особые Подпрограммы:

1) ОФОРМЛЕНИЕ
Как и обычные процедуры — они имеют «метку входа» (адрес/имя), а выход из них осуществляется только через RET (нельзя использовать RETI — это не обработчики прерываний!)

2) ПАРАМЕТРЫ
Но «Задачи кооперативной RTOS» не могут иметь «регистровых параметров»! Т.к. они запускаются опосредованно, через «Диспетчер Задач RTOS», в порядке очереди — то между запусками разных запланированных задач проходит неопределённое время, и происходит множество неконтролируемых операций с РОН.
Таким образом, Задачи должны управляться только данными в SRAM и в регистрах ввода/вывода! (Примечание: исключение могут составлять выделенные Задаче «регистровые переменные», но это редкость — см. обсуждаются в п.5.1)

3) ЗАПУСК
«Задачи RTOS» никогда не запускаются непосредственно, через CALL <адрес>, как обычные подпрограммы! Все Задачи запускаются только опосредованно — через механизмы RTOS («очередь задач» и «диспетчер задач»).

3.1) Задачи могут быть «запланированы к запуску» (по их порядковому номеру в индексной таблице «RTOS_TaskProcs»):
  • либо «как можно скорее» (через PLAN_TASK),
  • или «отложенный запуск, спустя заданное время, в мс» (через PLAN_TIMER, см. ниже п.7),
  • или «при наступлении внешнего события, состояния аппаратного устройства, состояния флага в памяти» (через PLAN_WAITER, см. ниже п.8).
В любом случае, передача управления между задачами никогда не происходит мгновенно — между ними происходит, как минимум один, проход цикла «Диспетчера задач»…

3.2) Поэтому, все Задачи необходимо предварительно зарегистрировать в системе: внести <адрес> в индексную таблицу «RTOS_TaskProcs», под определённым порядковым номером <индекс>; и для облегчения последующей идентификации, можно присвоить этот номер символической константе: .equ TS_TaskX = <индекс>.

3.3) Исключение составляет: системная задача «холостой цикл» Task_Idle, под номером =0 в индексной таблице. Никогда не планируйте/не добавляйте задачу Task_Idle в очередь на выполнение! (она сама, особым образом, обрабатывается RTOS: запускается при пустой «очереди задач»)

4) ХОД ВЫПОЛНЕНИЯ
Во время исполнения «кооперативной Задачи» управление не может быть насильно передано никакой другой «Задаче», ни службам RTOS! (только аппаратные прерывания всё-ещё могут прервать эксклюзивный ход выполнения Задачи)

4.1) Поэтому «кооперативная Задача», во время своего выполнения, может не опасаться за сохранность данных в РОН, SRAM, и регистрах ввода/вывода (состояниях аппаратной периферии, ПУ):
в этом наибольшая выгода «кооперативной ОС», перед «вытесняющей ОС» — что каждой Задаче не надо отдельно заботиться/защищаться от всех других «конкурирующих процессов», код проще! (не требуется покрывать код критическими секциями, использовать мьютексы для разделения критических ресурсов, использовать прочие прелести «синхронизации межпроцессного взаимодействия»)

4.2) С другой стороны, во время исполнения Задачи, всё-ещё может произойти «запуск прерывания»! Но код всех прерываний, безусловно, должен сберегать содержимое всех используемых РОН, через стек — они защищены. Однако, поскольку прерывание может влиять на содержимое иных разделяемых ресурсов (содержимое SRAM и состояния ПУ) — при работе с критическими аппаратными ресурсами (например, при записи в EEPROM), в коде задач допускается использовать CLI/SEI экранирование отдельных секций!

4.3) Впрочем, Задачам недозволенно запрещать прерывания надолго (дольше 1мс), чтобы не нарушать работу RTOS! Также, Задача не может запретить прерывания перманентно — как только завершится текущая Задача, то RTOS автоматически разрешит прерывания (SEI).
Например, невозможно реализовать функционал: Задача1 запретила прерывания, а запущенная следом Задача2 их вновь разрешила. Но это и бессмысленно: если запретить прерывания, то остановится «таймерная служба RTOS» — все «отложенные Задачи» будут заблокированы, не исполнятся никогда; и прерывания также никакие не возникнут — поэтому нет смысла так разбивать Задачу на подЗадачи...
Все «критические секции» необходимо отрабатывать в рамках одной Задачи! Вставляйте пустые циклы задержки, между CLI/SEI, если требуется («тупить фиксированное число циклов» или «ожидать бит в системном регистре»).

5) ОСОБЕННОСТИ ПРОГРАММИРОВАНИЯ
У «кооперативных Задач», есть важная привилегия, которой не обладают (асинхронно запускаемые) обработчики прерываний: Задачи могут не защищать СОДЕРЖИМОЕ РЕГИСТРОВ (РОН) через стек, вообще, как будто задачи выполняются на процессоре эксклюзивно. (Повторюсь: не требуется сохранять в стек никакие используемые регистры перед исполнением кода Задачи, и затем восстанавливать после выполнения перед выходом!) Но при этом, всё пространство регистрового файла РОН следует рассматривать только как «временные переменные»!

6) МЕТОДИКА ПРОЕКТИРОВАНИЯ
Функционально, алгоритм решения сложной прикладной задачи разбивается на подзадачи — каждая из которых оформляется в код отдельной «кооперативной Задачи». Таковые Задачи могут выполняется относительно других: последовательно, или условно (отдельные ветки IF-THEN-ELSE можно оформить как отдельные Задачи, и запускать через PLAN_TASK), или спустя определённую задержку времени (Задачи, планируемые через PLAN_TIMER), или спустя неопределённое ожидание внешнего события или состояния аппаратного устройства: приход данных в порт, завершение операции с ADC или EEPROM, событие компаратора и т.п. (Задачи, планируемые через PLAN_WAITER)

6.1) Код каждой Задачи должен быть атомарен. Каждая Задача при запуске: вычитывает, всё что нужно её алгоритму, из SRAM и регистров ввода/вывода; делает полезную работу; сохраняет результаты в SRAM; завершается (RET).

6.2) Код каждой Задачи должен выполняться максимально быстро, как и обработчики прерывания. Никогда не используйте «тупые задержки» в коде! Вместо этого, разделите Задачу на две подЗадачи: в первой части, сохраните в SRAM все промежуточные данные, нужные алгоритму второй части, и запланируйте запуск второй подзадачи (через PLAN_TIMER)…

6.3) Разумеется, для решения каждой отдельной прикладной задачи — потребуется определить целую серию подпрограмм «кооперативных Задач». Чтобы упорядочить этот колхоз — рекомендуется использовать разные трюки:
  • Имена давать Задачам, сформированные особым образом, префиксно: TS_TaskX_Begin, TS_TaskX_Check, TS_Task_Finish...
  • Перечислять Задачи в индексной таблице «RTOS_TaskProcs» последовательно, группами...
  • Давать описания коду и разделять его по секциям… и т.п.


7) Порядок установки Таймера:

  1. Добавить новый Таймер, вызвав API-метод: PLAN_TIMER tasknumber,delay
    • Если в пуле уже существует Таймер для задачи <tasknumber>, то его текущий «счётчик времени» будет переписан на значение <delay>. Прикол с апдейтом таймера кажется лишним, но реально часто пригождается. Например, когда по условию надо отложить событие. Берешь и перезаписываешь таймер, подобно программному watchdog.

    • Иначе, при наличии в пуле свободного места, регистрируется новый Таймер: для запуска задачи <tasknumber>, через время <delay> = [0..65535] ms.
  2. При необходимости перепланировать таймер на другое время, до того как он сработал — вновь вызвать API-метод: PLAN_TIMER tasknumber,delay
  3. Перепланировывать таймер можно неограниченное количество раз, лишь бы — делать это до того, как он сработает...]
  4. При необходимости же вовсе отменить запланированный запуск задачи — удалить таймер, вызвав API-метод: REMOVE_TIMER tasknumber
  5. Каждую ~1ms реального времени, по прерыванию, запускается «Служба таймеров RTOS», которая:
    • Декрементирует счётчики, всем активным Таймерам в пуле, на (-1)...
    • Если, при этом, значение счётчика достигает =0? То связанная Задача <tasknumber> добавляется в очередь RTOS_TaskQueue, на выполнение; А сам сработавший Таймер, при этом, деактивируется/самоудаляется, освобождая Элемент пула...

  6. Задача, посланная в «системную очередь» RTOS_TaskQueue, будет выполнена в порядке общей очереди...


Побочные эффекты:
  • API-методы PLAN_TIMER/REMOVE_TIMER, при исполнении, портят содержимое в некоторых регистрах: в зависимости от режима RTOS_OPTIMIZE_FOR_SMALL_MEMORY, либо только «параметровые регистры», либо также и «временные регистры» (см. комментарии в секции «Subroutine Register Variables», соответствующего системного метода).
  • Для управления Таймерами предлагаются также API-методы: SAFE_PLAN_TIMER/SAFE_REMOVE_TIMER, которые гарантированно не портят вообще никаких регистров, но они доступны только в режиме выключенной оптимизации RTOS_OPTIMIZE_FOR_SMALL_MEMORY (при этом, используется Стек — нужна дополнительная оперативная память).


8) Порядок установки Выжидателя:

  1. Добавить новый Выжидатель, вызвав API-метод: PLAN_WAITER tasknumber,address,bit,state
    • Если в пуле уже существует Выжидатель для задачи <tasknumber>, то его текущие «условия запуска» будет переписаны на значения <address,bit,state>.
    • Иначе, при наличии в пуле свободного места, регистрируется новый Выжидатель: для запуска задачи <tasknumber>, при наступлении «заданных условий» (значения бита в памяти), которое может произойти через любое неопределённое время (проверка состояния бита осуществляется периодически, каждые 1ms).

  2. При необходимости перепланировать выжидатель, на новые условия, до того как он сработал — вновь вызвать API-метод: PLAN_WAITER tasknumber,address,bit,state
  3. Перепланировывать выжидатель можно неограниченное количество раз, лишь бы — делать это до того, как он сработает...]
  4. При необходимости же вовсе отменить запланированный запуск задачи — удалить выжидатель, вызвав API-метод: REMOVE_WAITER tasknumber
  5. Каждую ~1ms реального времени, по прерыванию, запускается «Служба таймеров RTOS», которая:
    • Проходясь по всем активным Выжидателям в пуле, вычитывает байт из памяти по адресу <address>, и проверяет в нём значение бита номер <bit>...
    • Если значение бита = <state>? То связанная Задача <tasknumber> добавляется в очередь RTOS_TaskQueue, на выполнение; А сам сработавший Выжидатель, при этом, деактивируется/самоудаляется, освобождая Элемент пула...

  6. Задача, посланная в «системную очередь» RTOS_TaskQueue, будет выполнена в порядке общей очереди...


Побочные эффекты:
  • API-методы PLAN_WAITER/REMOVE_WAITER, при исполнении, портят содержимое в некоторых регистрах: в зависимости от режима RTOS_OPTIMIZE_FOR_SMALL_MEMORY, либо только «параметровые регистры», либо также и «временные регистры» (см. комментарии в секции «Subroutine Register Variables», соответствующего системного метода).
  • Для управления Выжидателями предлагаются также API-методы: SAFE_PLAN_WAITER/SAFE_REMOVE_WAITER, которые гарантированно не портят вообще никаких регистров, но они доступны только в режиме выключенной оптимизации RTOS_OPTIMIZE_FOR_SMALL_MEMORY (при этом, используется Стек — нужна дополнительная оперативная память).


Теория RTOS


Дополнительную документацию по теме — можно найти по ссылкам:

Курс от DI HALT (лучшее):
easyelectronics.ru/tag/rtos

Статьи в Блоге Сообщества:
we.easyelectronics.ru/blog/os-rtos/
we.easyelectronics.ru/tag/RTOS/

Смотри также следующую статью:
Пример использования «Диспетчера задач RTOS 2.0» (установка и настройка)...

Предпосылки

Разбирая исходники RTOS, меня не покидала одна навязчивая мысль: «DI HALT — либо гений, либо учителя у него хорошие были… Но в исходниках у него — говнокод ещё тот!» Т.е. много светлых идей, а framework до конца не доведен. Я не смог использовать такой код, пока не привёл его к Завершённой Форме. Пришлось потратить много времени и усилий… Но результатом я доволен — красивый инструмент!

Чтобы сэкономить время и усилия другим — делюсь своей редакцией кода RTOS, присваиваю ей номер: релиз 2.0. Она полностью совместима с версией DI HALT'а, по API на уровне макросов! (Хотя, замечу, прототипы системных методов были изменены и дополнены.) Можете мигрировать на неё свои проекты.

Пожалуйста, пробуйте и тестируйте этот код. При нахождении ошибок в коде (багов), или неуниверсальности на некоторых микроконтроллерах (самому всего не протестировать) — пишите багрепорты: здесь в комментариях, или на багтрекере GitHub. Постараюсь исправить…

  • +7
  • 13 февраля 2014, 16:49
  • Celeron

Комментарии (84)

RSS свернуть / развернуть
ВСЕ МИКРОКОНТРОЛЛЕРЫ AVR
atxmega8e поддержана?
0
ВСЕ МИКРОКОНТРОЛЛЕРЫ AVR: от самых мелких (ATtiny10), до разумно больших (ATmega64).
Ету ачепятку можно было автору в личку написать
0
На семейство AVR XMEGA, признаться, не рассчитывал/не тестировал. А оно востребовано?
0
Ну а как вы думаете? Атмел в убыток себе их делает?
0
Мне кажется, что нет.

За все платит потребитель, который не имеет возможности перейти на Кортексы.

ХМЕГА была бы хороша, если бы не было более лучшего варианта на рынке. А он есть. И стоит несоизмеримо дешевле, и имеет более широкую экосистему (больше распространен), и еще много чего вкусного и интересного.

Собственно, вопрос выгодно/не выгодно производить ХМЕГИ сводится к вопросу есть ли всё ещё в этом мире потребители этого дорогого устройства с ограниченной экосистемой.

В дальней перспективе ХМЕГА — это дорогая дорога в никуда. Но ведь не все это понимают. К тому же многие разработчики/производители просто не могут позволить себе пересесть на другой проц. Поэтому согласны платить дорого.

А АТМЕЛУ — что? Если заказчик платит, и эта плата покрывает расходы, то почему бы не клепать?

Наверно как-то так.
+1
И стоит несоизмеримо дешевле
Вы цены на xmega смотрели? Где там «несоизмеримо»?
0
Возможно, мы живем в разных городах. Я обычно отовариваюсь в Промэлектронике (http://www.promelec.ru/)

Может я не туда смотрю. Где Вы видите, что цена ХМЕГИ меньше цены на аналогичную (по вычислительной мощности, объему памяти, укомплектованности периферией) STM32?
0
меньше цены на аналогичную
Что значит аналогичную? Любая xmega проиграет по производительности STM32.
Но есть задачи где не нужна производительность Cortex-M.
Сколько будет стоить STM32 с ~256 кБ флеш и 6-7 последовательными интерфейсами?
0
Вижу, Вы — любитель поспорить. Что ж, давайте порезвимся на потеху публике!

Выражение «аналогичная по вычислительной мощности, объему памяти, укомплектованности периферией» — означает что, объем флешь-памяти у ХМЕГИ и у СТМ32 должны быть одинаковыми — по 128 или 256 кБайт. К сожалению, ХМЕГ с другими объемами памяти в продаже нет. Поэтому и предмет спора тоже отсутствует. Выражение так же означает, что объем Оперативной памяти тоже должен быть одинаковым. Иначе, проигравшая сторона получает минус. Выражение означает что и вычислительная мощность в МИПСах тоже должна быть одинаковой. В противном случае аутсайдеру нужно рисовать жирный минус. И так далее. Я думаю, что Вы это и так всё хорошо понимаете, без расшифровки. Это ж очевидные вещи! Но я так же думаю, что я Вас просто задел за больное место. Поэтому такая неожиданная реакция с Вашей стороны.

Ладно. Идем дальше. Там, где не нужна производительность Кортекс-М, можно устанавливать 20-ти рублевые Кортексы-М0 (STM32F030). А можно вообще опуститься до уровня STM8. Это еще раза в два снизит цену. Заметьте, что в эту категорию ХМЕГА вообще не вписывается! Ни по кузову, ни по стоимости — вообще никак! Это вообще не ее ниша. А на своей нише она жестко побита Кортексами-М3 и М4.

На сколько я в курсе, СТМ32 с более чем пятью ЮАРТ-ами не выпускаются. Как бы Вам это сказать… просто в этом нет необходимости. Понимаете, если возникает вопрос о том, что Вам нужно реализовать более 5 ЮАРТОВ, то скорее всего вы решаете свою задачу не совсем правильно, не в ту сторону думаете. Ваш вопрос сводится не к стоимости микроконтроллера с дюжиной ЮАРТов на борту, а к компетентности разработчика, которому их столько нужно в одном микроконтроллере. Я призываю Вас подумать на эту тему, и не сейчас (чтобы мне тут же что-нибудь ответить, а как-нибудь на досуге, основательно-так подумать.

Вы где-то ошибаетесь в своих рассуждениях, но я не знаю — где именно. Я только вижу, что Вы говорите вещи, которые не соответствуют жизни. Вот и всё, вся правда.

Мои извинения, если что не так!
+1
Вы — любитель поспорить
Не особо, но иногда можно ведь…
означает что, объем флешь-памяти у ХМЕГИ и у СТМ32 должны быть одинаковыми — по 128 или 256 кБайт.
Это если сравнивать МК «сферические в вакууме». А если сравнивать в реальности, то нужно учитавать размер кода который потребуется для решения конкретной задачи. И тогда 16к АРВ равно 32к CM3.
ХМЕГ с другими объемами памяти в продаже нет
Так прямо и нет? Всё есть и 8 и 16 — до 256. Не там ищете. тут… к тому же есть ещё digikey, mouser, farnell
Выражение так же означает, что объем Оперативной памяти тоже должен быть одинаковым.
C чего бы это? У cortex объём ОЗУ однозначно должен быть больше — стек расходуется быстрее, МК лучше не заставлять работать с переменными не 32-битными…
Выражение означает что и вычислительная мощность в МИПСах тоже должна быть одинаковой. В противном случае аутсайдеру нужно рисовать жирный минус.
А если эти МИПСы для задачи не нужны, то за что же минус?
СТМ32 с более чем пятью ЮАРТ-ами не выпускаются.
Точно? Или не нашли. Или ST не научилась ещё?
Вам нужно реализовать более 5 ЮАРТОВ, то скорее всего вы решаете свою задачу не совсем правильно,
Ну, 2-3 УАРТа в устройстве не такая уж экзотика. Плюс 1-2 SPI тоже вполне реально. Плюс какая-нибудь 1- wire. Плюс УАРТ для отладки. 5 serial не такая уж роскошь.
Но я так же думаю, что я Вас просто задел за больное место
Не… врядли мне вообще придётся в будущем с АВР работать…
Мои извинения, если что не так
Пока всё так… не за что извинятся…
0
нужно учитавать размер кода который потребуется для решения конкретной задачи. И тогда 16к АРВ равно 32к CM3.
Не согласен!

Кортексы используют набор команд Thumb2. Это двухбайтовые команда. Но и у ХМЕГИ команды, если я не ошибаюсь, — тоже двухбайтовые. Это значит, что для одной и той же задачи, и ХМЕГЕ, и СТМ32 потребуется примерно одинаковые объемы флешь-памяти. Ни о каком двукратном перерасходе не может быть и речи! Но если продвинуться еще чуть дальше в своих рассуждениях, то на более тяжелых задачах, где требуется обрабатывать данные размер которых превышает один байт, однозначно выигрывают Кортексы. Например, это могут быть тривиальные задачи оцифровки и обработки данных с АЦП, работа с 16-тью разрядными счетчиками и так далее. Да, мало ли в программе объявлено переменных, которые двух и более байтовые, или более того — работа с float-арифметикой!..

На обработке байтовых данных, Кортексы, скорее всего продуют ХМЕГЕ по объему флеш-кода. Но на сколько я понимаю, такие задачи не являются тяжелыми. Для их решения можно взять дешевые Кортекс-М0, тактовая частота, к стати, у них аж 48 МГц! То есть недостатка дури не будет, а цена… В прочем, я уже начинаю по второму кругу бежать.

Из моей практики, дурная задача моргания светодиодом на СТМ32 выливается в размер кода от примерно 250 байт (код написан на асме) до примерно 1200 байт (код написан на Си). Причем, следует заметить, что одна только таблица прерываний, которая к размеру кода не имеет прямого отношения, съедает несколько сот байт.

Но это не важно! Важно то, что при добавлении дополнительной функциональности к программе расход флешь-памяти будет примерно одинаковый у там, и там. Конечно, надо проверять практически, но… кто это будет делать! Поэтому придется остановиться на вере в то, что и там, и там — команды двухбайтовые. Я не думаю, что эффективность Кортесовских команд хуже, чем у ХМЕГИ.

А Вы можете привести доказательства со своей стороны?

Так прямо и нет? Всё есть и 8 и 16 — до 256. Не там ищете. тут… к тому же есть ещё digikey, mouser, farnell
О-о, да! Целых шесть позиций! На две из которых цена неизвестна. А половина позиций, имеющаяся на складе в самой Москве, а не где-нибудь в Тьму-Таракане, имеет запас 2 штуки, 3 штуки и даже — 10 штук.
Впечатлён, нет слов!

C чего бы это? У cortex объём ОЗУ однозначно должен быть больше — стек расходуется быстрее, МК лучше не заставлять работать с переменными не 32-битными…
Всяко бывает. Про других разработчиков и проекты я ничего не могу сказать, но лично у меня в основном по жизни используются 32-битные переменные (как нативные для Кортексов) и используются байтовые массивы данных. Так какой расход оперативной памяти будет? У нас опять получился «сферический конь». Привязаться не к чему, нет ориентиров.

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

Точно? Или не нашли. Или ST не научилась ещё?
Да, я, собственно, и не искал специально. Я ж говорю — нет в этом никакой необходимости. Если требуется много ЮАРТов в одном камне, значит, Вы что-то делаете не правильно. А ирония «не научились ещё» — ну, не к лицу Вам так. Оставьте это школярам.

Ну, 2-3 УАРТа в устройстве не такая уж экзотика. Плюс 1-2 SPI тоже вполне реально. Плюс какая-нибудь 1- wire. Плюс УАРТ для отладки. 5 serial не такая уж роскошь.
Вот тут согласен, несколько последовательных портов, используемых одновременно на одном чипе, — это не такая уж экзотика. Но когда для решения задачи однотипных портов требуется много в самый раз задуматься — а правильно ли я вообще решаю задачу? Может быть имеет смысл пересмотреть архитектуру девайса и выделить на каждое направление свой, какой-нибудь мелкий микроконтроллер с ЮАРТ-ом, а потом их, добрый десяток, объединить на какой-нибудь адресуемой шине? (На шине, на которой устройства имеют свои адреса)

Я не знаю, решений может быть множество. Например, ведь не зря ж множественные однотипные переменные в языках можно объединять в массивы. Зачем натягивать трусы, изображая из них смокинг. Не используйте для решения сложных задач уж слишком «натянутые» решения. Вы сэкономите на камне, у которого семь ЮАРТ-ов, а «резинка» порвется в другом месте. Зачем эти хитрожопые решения, кого хотим надуть?

Так что, в моем понимании, СТМ32 — это единственный достойный кандидат на ближайшие 5-10 лет. ХМЕГА будет занимать очень незначительный размер секгмента на рынке. Будет так и расти — засыхающей веточкой. Что же касается АВР-ок, то как это ни печально, они медленно-медленно, сократят свою долю. По крайней мере, мне было приятно сними работать, и я о них отзываюсь с печалью в голосе. Для своего времени они были очень даже хороши. Но мир продолжает совершенствоваться. И этот процесс нельзя повернуть вспять. Но можно, зарыв глаза, и уши твердить своё. Только кого Вы своими речами убедите?
0
Так что, в моем понимании, СТМ32 — это единственный достойный кандидат на ближайшие 5-10 лет.
А почему именно STM32, а не другие ARM'ы?
0
+0x100
Как будто нет LPCxx, SAM, EFM32, Kinetis, Infineon, Toshiba, Nuvoton, Stellaris?
0
Ну, стеллариса таки уже нет)
Хотя, конечно, по доступности с STM32 только LPC тягаться могут.
0
Ну, стеллариса таки уже нет)
TIVA, точно…
по доступности с STM32 только LPC тягаться могут.
Что вы понимаете под доступностью? Чтобы в соседнем ларьке продовались?
Те же EFM-ы или Kinetis-ы, SAM-ы купить нельзя что ли?
0
Купить можно все, но что-то нужно искать, а что-то валяется в соседнем ларьке. По этому параметру из кортексов STM32 явно лидирует.
EFM я пытался на сэмплы развести, и даже развел — но UPS (или кем они там шлют) в наш город не возит. А в магазинах, где обычно закупаюсь, вообще их не видел. Не из фарнелла же тащить, в самом деле.
0
Например? Конкретезируйте вопрос и я Вам смогу ответить на него.
Основных критериев не очень много.

1. Это должны быть реальные камни, кторые можно пойти и купитьт, а не «теоретические», ссылки на которые существуют только на бумаге и в интернетах.

2.Камни должны поддерживаться компиляторами/отладчиками в Линуксе (Да, я Лунукс-упертый). Виндовс идет лесом вместе с теми уникальными камнями, которые только под ней и окучиваются. Я знаю, что отказываясь от Виндовс-платформы, я ограничиваю разнообразие. Но сегодня зоопарк камней на столько огромный, что вычеркивание СТМ8, ХМЕГА и других линеек, не оказывает ни какого отрицательного влияния. Более того, из-за того, что выбор типов микроконтроллеров/ядер (а не реализаций или модефикаций внутри выбранноого типа) становится меньше, то высвобождается возможность для более глубокого изучения конкретного выбора. Можно знать о многом, но быть на уровне делитанта, но можно иметь глубокие знание, но по отдельным направлениям.

3. У линейки микроконтроллеров должна быть хорошо развитая инфраструктура или экосистема. Другими словами, МК должен быть популярным.

Почему нам в России лучше разговаривать на русском, ну в крайнем случае на английском, и очень мало в нашем окружении людей, кто говорит на японском, итальянском, шведском? Чем больше людей в твоем окружении говорит на каком-то языке, тем быстрее и легче прокачиваются твои знания в этом языке. Так и с микроконтроллерами.

4. Личные предпочтения или личная симпатия (предрасположенность) к производителю. Например, несколько лет назад я ориентировался на Кортексы от NXP. Хорошие камни. Но неадекватное поведение фирмы по отношению конкретно ко мне, оттолкнуло её. Прошел срок выбора, на что мне сориентироваться, выбор сделан. Девушка вышла замуж. (с) Теперь мне LPC не надо даже бесплатно. Я отдаю свои рубли за НАУКОЕМКИЙ/ИНТЕЛЛЕКТУАЛЬНЫЙ товар тому, кто смог заполучить мое расположение. Точнее — тому, кто постарался это сделать.

Неплохие кортексы у TI. И даже книжка Joseph Yiu вышла на русском по ядру Кортекс-М3 в контексте микроконтроллеров от TI… Но, к сожалению, девушка уже замужем…

Я могу упомянуть маложрущие Гекконы, кортексы от той же АТМЕЛ, и даже отечественные Миландры… Но толку-то от этого разнообразия! Все они мало распространены, либо вообще тяжело доступны, либо описание на них бедное, либо еще какая-то причина.

У меня нет жутко-специфичных задач, требующих того такого процессора. Напимер, если стоит задача малого потребления, то я скорее всего возьму MSP430, а не Геккона. А если нужно интенсивно пощелкать арифметикой, то сгодится практически любой кортекс. Но поскольку у меня наработан опыт по СТМ32, то зачем мне под тривиальную задачу ставить то, что я не очень хорошо знаю?

Сравните, широту предложений СТМ32, которые РЕАЛЬНО можно купить в магазине, с раритетными камнями. Кроме того, нужно учитывать, «мы живем в России» (с), и мягко говоря, политика поставки из-за бугра может очень сильно поставить вас раком в самый неожиданный момент. Во многих продажных фирмах Рашын Федерейшн даже в списках нет! Укарина — есть, Белорусия — есть. Даже Кыргызыстан есть! А вот Россиия по политическим мотивам — отсутствует. Пример? Зайдите на «Элемент-14» и попробуйте что-нибудь купить. А кто его знает, как оно будет после Олимпиады?

Поэтому, в случае чего, пересесть с одного кортекса на кортекс другой фирмы легче, чем с ХМЕГИ на ПИК.

Может быть я где-то ошибаюсь. Время покажет.
0
Ну и простыня.
1) Они вполне реальны, а LPC по распространенности практически аналогичны STM32.
2) Насколько я знаю, большинство кортексов шьется одними и тем же отладчиками, вполне поддерживаемыми линухом.
3) Ну, популярность STM32 среди любителей, конечно выше. С другой стороны, производители вполне предоставляют все необходимое для специалиста.
Сравнение с языками некорректно. И язык, и МК прокачивается при практике, но если практика с МК зависит только от тебя самого (то, что твой сосед ковыряет STM32 не добавит тебе опыта), то для практики языка необходимы собеседники.
4. Ну, это сугубо личное. Меня больше интересуют менее субъективные причины.
Поэтому, в случае чего, пересесть с одного кортекса на кортекс другой фирмы легче, чем с ХМЕГИ на ПИК.
Почему? Учитывая, что ныне практически все МК программируются на ЯВУ (С/С++), разница сводится только к отличиям периферии. А она между кортексами разных фирм отличается не меньше, чем между теми же кортексами и пиками.
0
Ну и простыня.
:)))))

1. Да, не интересуют меня LPC. Я ж сказал по какой причине. Облажалась NXP на старте. Время упущено.

2. Да, с тулчейнами под Линух у кортексов проблем нет. И у АВР, и У МСП430 всё хорошо. Проблемы в Линухе только у СТМ8 и еще чего-то.

Или Вы в своем вопросе имели в виду исключительно Кортексы? Тогда, я просто не понял Ваш вопрос.

3. На начальной стадии изучения, когда только-только начинаешь изучать нечто новое, ой-как нужна коммьюнити! Хоть какая-нибудь коммьюнити. Понятно, что когда ты научился моргать светодиодом и привязался к компу через ЮАРТ или по ЮСБ, тебе уже мало-что нужно от других. Ты юзаешь только документацию на камень и веришь только своему осциллографу. Ты самодостаточен. Но в начале, без поддержки других людей, кто уже хоть что-то знает, вставать на новые лыжи тяжко.

4. «сугубо личное» и «субъективные причины» — разве это не из одной бочки?

Не-не!.. Я считаю, что освоиться с несколько другой периферией легче, чем освоиться с другой периферией, другим ядром, накатить другой тулчейн, освоить новые средства отладки и программирования, освоить новые форматы и документации, и т.д.

А периферия даже у Кортексов разная. Несколько месяцев назад раскурил STM32F030. Порты другие. ЮСАРТ — другой. Но я не считаю, что это есть какая-то непреодолимая проблема. Посидел, вечерок, прокачал скилзы по портам. Другой вечерок — ЮСАРТ. А подходы к работе что с STM32F1xx, что с STM32F0xx — одинаковые. Поэтому особых проблем не было.

Для сравнения. А пересаживался я бы к примеру с STM32 на ту же ХМЕГУ — вот бы где горя хлебнул!
0
Для сравнения. А пересаживался я бы к примеру с STM32 на ту же ХМЕГУ — вот бы где горя хлебнул!
Не думаю, что пересесть с STM32 (которые все же родственны друг другу) на LPC проще. Ну разве что, действительно, другой тулчейн поднимать и новый отладчик покупать или паять. Но я все же имел в виду само освоение, а не поднятие среды.
0
Сложно сказать. Несколько лет назад, когда начинал изучать LPC17xx, я читал на него даташит. Разбирался с адресацией, с системой тактирования, с портами. Мне показалось не сложно. Просто это как выучить еще одно стихотворение Пушкина. Возможно это было так из-за того, что я еще до этого успел поработать с АРМ7-ми и от NXP, и от АТМЕЛА. Поэтому особых неожиданностей в LPC17 я не встретил.

Но без железа было мало толку от теории. Переписка с NXP ни к чему не привела. Они обещали, извинялись, снова обещали… Мне надоела эта канитель и в какой-то момент я послал их проведать избушку на болоте. И они пошли лесом… :)

А вот освоение STM32 после попытки приручить LPC17xx мне показалось не таким уж и сложным.
0
Переписка с NXP ни к чему не привела. Они обещали, извинялись, снова обещали…
Что обещали-то? Отладчик копейки стоит — можно самому купить — не разорит.
Да вообще NXP без проблем высылает, в отличие от ST (так дискавери и не выслали жлобы — пришли им описание проекта, то да сё ...)
0
Во-во! Это точно — жлобы! Поэтому, когда я понял, что NXP — жлобы, я пошел и прикупил пару плат того производителя, платы которого были в наличие в магазине. Благо, они копейки стоят!
0
Хм, а у меня с точностью до наоборот были. Экспрессо за расстрелянный МК обещали вроде (в духе «уже едет» в письме), но так и не прислали, а вот дискавери приехала.
0
:) Нет, нет! Вы не правильно поняли.

В течении нескольких месяцев я пытался людей из NXP заставить выполнять обещания, я пытался привести их к пониманию, что за свои слова нужно отвечать. Бесполезно! Видимо в NXP в то время происходило что-то серьезное, и они физически не могли обеспечить свои обещания.

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

В Проме в это время уже лежали платы STM32VLDISCOVERY… Ну, мне и оставалось сделать полшага, что бы войти в мир Cortex. Поэтому я и слил эту ненадежную компанию и повернул оглобли в сторону STM. Тогда было трудно это сделать, но сейчас я ни капли не жалею. Со жлобами иметь дело — будет всяко себе дороже.

Потом, на одном из семинаров по Кортексам, Томас Дреслер (представитель STM) на (мой) вопрос — «не в курсе ли он, что там происходит у NXP? Зачем им это балаган нужен?», поделился своими секретами по развитию NXP. Он сказал, что у NXP действительно проблемы — учредители вынимают из NXP свои капиталы и вкладывают их в какой-то другой, более прибыльный бизнес.

То есть в NXP в то время было реально трудно с оборотными средствами, поэтому они всячески пытались делать хорошую мину при плохой игре. Бизнес NXP постепенно разрушался, и как NXP будет выглядеть в ближайшем будущем на фоне множества других поставщиков Кортексов — никто не мог ничего определенного сказать.

Я не думаю, что Вы бы поступили как-то иначе обладая этой информацией. Как говорится — ничего личного, это всего лишь бизнес.
0
Вы прям такие выводы делаете...одна бабка на базаре сказала Представитель STM (конкунентов NXP между прочим) сказал на семинаре что у NXP дела плохи — значит не надо их продукцию использовать…
Я не думаю, что Вы бы поступили как-то иначе обладая этой информацией.
Да, инсайд знатный…
Не разорилась NXP пока… Как и STM впрочем — про неё такие же слухи ходят: мол процов понавыпускали и инвесторы из них деньги выводят. Ничего работают.
0
и новый отладчик покупать
Jlink лучше купить — оно ж для всего CMx
0
Я сравниваю переход с одного кортекса на другой с переходом между двумя разными архитектурами, и про новый отладчик относится именно ко второму.
0
Я сравниваю переход с одного кортекса на другой с переходом между двумя разными архитектурами
Ничего сложного нет. Среда, отладчик — все одно и то же. Я c Stellaris на STM32 код переводил — никаких проблем.
0
По моему, «среда и отладчик те же» — последнее, что создает проблемы при переносе. И изначально контекст был не перенос кода, а освоение камня.
0
Когда один Cortex освоен, следующие уже проще пойдут.
0
Не вижу между ними ничего общего, кроме ядра — но оно нынче все равно скрыто компилятором. Разве что рассматривать с позиций «освоил первый МК — следующие пойдут проще».
0
Не вижу между ними ничего общего, кроме ядра
Верно — общее только ядро. Но и тулчайн можно тотже использовать. И отладчик. И прерывания также работают.
Всё-таки начальный этап проходить заново не нужно — на этом время экономится.
0
Целых шесть позиций
Вы невнимательны — Там ещё есть
На farnell-е штук сорок позиций… На mouser-е — больше 50…
0
Да. Действительно более 6 штук.
Простите, не внимательно посмотрел.
0
какой-нибудь мелкий микроконтроллер с ЮАРТ-ом, а потом их, добрый десяток, объединить на какой-нибудь адресуемой шине?
Вот уж точно такого не надо. И каждый мелкий МК считывать по УАРТУ или SPI? Не-не-не… И отладкой не глянуть.
0
Для их решения можно взять дешевые Кортекс-М0, тактовая частота, к стати, у них аж 48 МГц!
Да мелковаты эти М0. Ни памяти ни периферии…
P.S. У xmega — 32 Mhz кстати.
0
Да ради Бога, используйте иксмеги. Мне Атмел прислал нашару иксплейн с этой иксмегой. Мне этот кал без надобности, поспрашивал у знакомых — тоже никто не заинтересовался. Щас выляется где-то в ящиках на работе.
Атмел правильно делает, что развивает свое семейство ARM, хоть и несколько с опозданием. А ХМЕГА — это перекачанный стероидами АВР — глупость полная. Лучше бы выпустили линейку AVR8 с тактовой частотой мегагерц 50 — и то больше толку было бы.
0
Мне этот кал без надобности, поспрашивал у знакомых — тоже никто не заинтересовался.
МК как МК. Кусок кремния в корпусе из пласмассы. Такой же как и другие.
Щас выляется где-то в ящиках на работе.
Аналогично — есть discovery F4, лежит на полке пару лет уже — некуда заложить его. А рядом stk с Gecko, lpc13, lpc17.
Атмел правильно делает, что развивает свое семейство ARM, хоть и несколько с опозданием.
Как будто раньше их Атмел не делал — уже лет 10 клепает.
А ХМЕГА — это перекачанный стероидами АВР — глупость полная
Всего-то переферию расширили и улучшили.
Лучше бы выпустили линейку AVR8 с тактовой частотой мегагерц 50 — и то больше толку было бы.
А xmega — это что по вашему? Оно и есть AVR8 с тактовой до 32 МГц, 3-х уровневым контроллером прерываний, с 2-мя АЦП, ДМА-DAC-системой событий-кучей таймеров-UART-ов-AES/DES/CRC-PLL.
ЗЫ. До 50 МГц не получилось у них — видимо есть технологические причины не загонять такой МК на такие частоты. Но 32 не намного меньше 50-ти.
ЗЫ2. Cortex-M0 тоже почему-то выше 50 МГц мало кто делает. Почему не на 200 МГц? Так надо видимо…
0
Ну, как бы у каждого свои тараканы в голове. Мне проще работать по принципу «разделяй и властвуй».

Небольшой функциональный узел, легче собрать и отладить. Когда система состоит из нескольких узлов, которые исключительно хорошо выполняют свои мелкие функции, то и управлять такой системой одно удовольствие. С другой стороны иметь мега-комбаин в одном корпусе, функциональные узлы которого нужно как-то «разводить по разным углам», чтобы они не мешали друг другу в конкурентной борьбе за процессор, память, порты и другие ресурсы. Это, в общем-то, всё только слова. Нужно говорить конкретно по задаче. Но я уверен, что гипотетическую задачу с десятком ЮАРТов можно и нужно решать методом делегирования части функционала на мелкие микроконтроллеры.
+1
можно и нужно решать методом делегирования части функционала на мелкие микроконтроллеры

таки да. особенно на всяких «исследовательских» поделках, где обычно нужна электронная Мега-Система, а что она в итоге должна будет делать никто изначально и не знает:)
0
камрад, твои опечатки можно отливать в гранит:)

зарыв глаза, и уши

укращать свое г*вно разноцветными рисом

я без злости, коварства и подъебов, честное слово:) но когда читаешь такие шедевральные строки — основная тема улетучивается из башки напрочь моментально!!!:)
+2
Это если сравнивать МК «сферические в вакууме». А если сравнивать в реальности, то нужно учитавать размер кода который потребуется для решения конкретной задачи. И тогда 16к АРВ равно 32к CM3.
Абсолютно наоборот!
Код MSP430 в среднем в 1.8 раза компактнее, чем AVR, а код Thumb-2 ещё компактнее. То есть, как раз 32к AVR равны 16к Cortex-M.
Не надо заблуждаться относительно 8-16-32-битности.
Чтобы не прослыть самизнаетекем, вот ссыль

M0 code size is 51% smaller than PIC18
M0 code size is 49% smaller than Atmel AVR8
0
Абсолютно наоборот!
Да врут небось… Да и смотря задачи какие.
У меня не получалось компактней чем на АВР сделать. Увы мне?
+1
Да врут небось…

да почему врут? ты даташыты, что ли, не видел никогда?:) приводится Мега-параметр, а после звездочки — еще на полстраницы условий, при котором данный параметр получен:)

Да и смотря задачи какие.

в корень. да еще плюс доставаемость нехуевое значение имеет:)
0
Компактнее, и даже не по одной причине.
Условные команды, адресация относительно счетчика, пред и постинкрементные адресации, равномерный регистровый файл.
Один и тот же алгоритм реализуется значительно проще.
0
8 уартов есть в TM4C1231C3PMI например :)
0
Надеюсь вы убрали «дамоклов меч», «обезьяну с гранатой» из этой «RTOS»? Поясняю, в примере DI HALT-а был один очень существенный косяк (да не обидится он за мои слова). Таймерная служба. В очереди таймеров болтаются задачи. Как только время пришло, задача запускается. Теперь представим, что мы делаем станок на этой «RTOS». Задачи в таймерной службе запускаются из других задач. Вот сидят задачи, ждут своего часа. И тут БАЦ! Аварийная ситуация. Хорошо, основная задача увидела аварийную ситуацию. Но в таймерной службе болтаются другие задачи. И в один примечательный момент сработал пресс. И отдавил руку оператору. И турма тебе! Вы скажете, что можно «убить задачи» в таймере. Но откуда нам знать, какие задачи нужны-не нужны в данный конкретный момент. Я когда увидел впервые эту РТОС, думал вот оно решение многих моих проблем. Пока не увидел косяк таймерной службы. В дальнейшем я перешел на автоматное программирование. И поверьте, такая РТОС мне ни разу не потребовалась. Да и вообще ни одна. Main, список функций и все. Мои принципы — нет долгих циклов. Выполнение кода, проверка условий, выход.
Так что если у вас та же самая таймерная служба, висящая «дамокловым мечом» над шеей воспользовавшихся вашей «RTOS», то я даже вникать в ваш пример не буду.
0
Да, здесь, та же самая таймерная служба!
Задачи в таймерной службе запускаются из других задач.
И не только Таймеры, но и Выжидатели, и регулярная Очередь Задач — все они запускаются из других Задач...




«Дамоклов меч» аварийной ситуации можно разрулить по разному:
можно «убить задачи» в таймере. Но откуда нам знать, какие задачи нужны-не нужны в данный конкретный момент
При возникновении критической аварийной ситуации — я бы убил ВСЕ задачи, и запустил одну задачу аварийного режима (всё равно система заблокирована), но это подходит только для простейших станков:
RCALL  RTOS_METHOD_ClearTimers
RCALL  RTOS_METHOD_ClearWaiters
RCALL  RTOS_METHOD_ClearTaskQueue
PLAN_TASK  TS_Task_EMERGENCY_MODE


Также, я бы, в обязательном порядке, ввел «глобальный регистр статуса» в системе (хранил бы байт в SRAM), одним из битов которого был бы: FAILURE_OCCURRED_EMERGENCY_MODE. И каждая Задача, управляющая резаками и прессами — должна, при запуске, в первую очередь, проверять этот бит: если установлен — мгновенный выход… Но это уже элемент «автоматного программирования»!




Но «дамоклов меч» — это ещё далеко не все недостатки данной [ограниченной] RTOS. Остановить Задачи — это не Проблема, а вопрос логической организации… А вот как быть с запуском Задач по цепочке, если «Очередь Задач» или «Пул Таймеров/Выжидателей» переполнен?

Если в некоторый момент МК будет перегружен, Очеред Задач переполнена, и тут срабатывает Таймер или просто вызывается метод PLAN_TASK из прикладного кода — Задачу добавить некуда, она игнорируется! (Примечание: для отслеживания и разруливания таких ситуаций, предназначена Ловушка Исключений RTOS_METHOD_ErrorHandler. Но, по сути, это костыль...)

Дальнейшая цепочка воспроизводства Задач нарушается — система «зависает», причём функционал отпадает по частям, в хаотичном неконтролируемом порядке. Пример и Предупреждение об этих ситуациях — я выложу в следующей статье: «Пример использования RTOS 2.0»…



Выводы:

Для программирования ответственных устройств, типа станков, использовать данную RTOS — нельзя, я считаю! Тут нужно использовать дубовое «автоматное программирование» — примитивное и надёжное. Надёжное! Пусть и сильно ограничивающее логические навороты. Во избежание ситуации: как с той «заклинившей дроссельной заслонкой в автомобиле Toyota Camry, приведшей к резонансной аварии»

А вообще, при мало-мальски сложной задаче, данная RTOS позволяет наговнокодить «спагетти-код» гораздо быстрее иных систем (поскольку каждый кусок кода «Задача» — слабо и неочевидно связан с другими)… «Диспетчер задач RTOS» предназначен только для простой автоматики.

Я не буду выгораживать данную RTOS. Я знаю её недостатки. Но мне нравятся также её преимущества и красота…
0
Сразу хочу сказать, что у меня нет цели обкакать труды DI HALT-а или ваши. На самом деле идея неплохая. Просто нужно «доработать напильником».

Нельзя было выкладывать как есть эту, так называемую, «RTOS». Был довод, что это учебный полигон. И ошибки пользователи должны были сами найти. Да, тоже верно. Но! Также есть немалое кол-во участников, неподготовленных, с малым опытом, «лишь бы работало», ну и так далее. Короче, у любого программиста наступает период, когда все, что он наляпал, нужно правильно увязать в нечто целое. Скажем, связать вместе клавиатуру, дисплей, периферию. На это требуются определенные знания, опыт, навыки. И эта «РТОС», казалось бы, на первый взгляд, решает эти проблемы. Но на самом деле, в том виде, как оно есть, только усугубляет. Да хотя бы, потому что расслабляет. Все заработало и ладно.

Если говорить о надежном программном обеспечении, то при кривых руках, недосмотрах, просчетов и мэйнлуп может так сглючить, что мало не покажется.

Поэтому при разработке более-менее серьезных устройств методы защиты комплексные. Программные и аппаратные.

Идем дальше. На тот момент, когда я наткнулся на цикл статей DI HALT-а, то казалось бы вот оно решение моих проблем. Когда я столкнулся с «дамокловым мечом», я был в затруднении. До тех пор, пока начал изучать автоматное программирование. Вы упираете на RTOS, я на состояние. В чем главная беда вашей «RTOS»? В том, что таймерная служба работает в ПРЕРЫВАНИИ. Когда я переработал и вынес ее в основной цикл, многие проблемы снялись. Осталось лишь одно. Как удалять задачи из службы? Следующий шаг был: вместо массива из номера задачи и счетчика — статусный байт и счетчик, нужный таймер в задачах определяется на этапе компилирования.
С автоматным программированием стало еще проще. Есть цикл статей Татарчевского об автоматном программировании. И если у вас слабо с автоматным программированием (это вообще-то касается всех программистов), то самое время начать изучать. И этом цикле замолвлено словечко о программынх таймерах. То что я сейчас использую, почерпнуто в этих статьях.

Вы сделали упор на RTOS, хотя на самом деле задача RTOS, м-м-м, иная, чем думают многие начинающие. Задача RTOS — распараллеливание задач. Чтобы процессор не простаивал в холостую, и решал поставленные задачи. «Много» задач одновременно.

Так вот. В автоматном программировании аварийная ситуация, пауза, стоп — это все СОСТОЯНИЯ! Главного или подавтомата уже не столь важно. И если, скажем «пауза», то это состояние. И таймер в этом состоянии либо не обрабатывается, либо приостановлен. И не будет спонтанного из прерывания срабатывания задачи. Так же, как нет теперь «дамоклого меча» и «обезьяны с гранатой»!
0
Забыл добавить. Когда наступил период собирать из кусочков и непонятно, как все это собрать в кучу, и как все это должно взаимодействовать между собой, то следующий шаг — автоматное программирование.
0
Всякие «RTOS», диспетчеры, службы уже идут после автоматного программирования.
0
Если интересно, могу свои ассемблерные наработки дать. С таймерами точно могу примеры найти, а вот на «RTOS» DI HALT-а не обещаю. Как переделал таймерную службу несколько лет назад, так больше к этой «RTOS» не возвращался.
0
по моему опыту:
автоматы годятся только для логики уровня термостата.
если уровень выше, автомат на автомате превращается из красивой логики
в кучу говна, в которой весьма трудно разобраться.
К тому же тогда взникает куча условных переходов.

Ваш пример с прессом — некорректный. Аварийный датчик можно обслужить в прерывании, в этом же прерывании можно и переключить текущую задачу на аварийную, которая засуспендит или прибьёт всё что нужно.
Может, у диХальта и есть этот косяк, но это не означает, что он есть в любой RTOS и => RTOS — это плохо.
0
К тому же тогда взникает куча условных переходов.
Это если автомат реализовывать руками. Если же его организовать как табличный автомат, то там условных переходов практически не будет.
0
я же верно понимаю, что значения в таблице меняются в зависимости от ситуации?
И, скорее всего, где-то будет анализ — а что в этой ячейке, или что надо туда положить?
А это те же самые условные переходы.
0
я же верно понимаю, что значения в таблице меняются в зависимости от ситуации?
Нет. Строка и столбец таблицы это текущее состояние и входящее событие. По этим двум координатам из таблицы выбирается точка входа на код, который надо в этом случае выполнить. В процессе выполнения этого кода текущее состояние может измениться. Собственно, табличное описание конечного автомата это классика. Причем весьма древняя, если не ошибаюсь, оно старше компьютеров как таковых. Замечу, что одной из очень важных особенностей такого подхода является полное покрытие всех комбинаций состояния и входящих событий, в том числе запрещенных. Если писать такой автомат на проверках, проглядеть запрещенную комбинацию очень просто и если она приключится в реальной работе, поведение кода становится непредсказуемым.

P.S. еще бывают многотабличные автоматы, в частности это один из вариантов реализации LR(k) парсеров. только таблицы для таких автоматов, как правило, руками не генерят, это делается с помощью специальных программ, «компиляторов компиляторов» (самый известный из них — yacc/bison). как вариант, простой конечный автомат тоже можно описать грамматикой и сгенерить обработчик с помощью yacc/bison (хотя скорее всего хватит flex, он как раз под конечные автоматы заточен). впрочем, чаще всего это из пушки по воробьям, типовые задачи, как по мне, значительно проще и там табличку вполне можно соорудить руками.
0
это всё хорошо, но есть ли примеры относительно больших проектов построенных на конечных автоматах?
0
Из того, что мне попадалось — user level ppp для FreeBSD (правда давно, году эдак в 99-м). Что бы оценить сложность, можно на досуге полистать RFC которые посвящены ppp.
А вообще что именно вы понимаете под «относительно большими проектами»? Какое количество состояний и входящих событий вы считаете достаточно большим?
0
Да, полное покрытие всех комбинаций состояния и входящих событий — вещь полезная. Может, где-нибудь и применю.

Кстати, есть в Boost(MSM). Так что спасибо за идею.
0
Переписать диспетчер на ассемблере! AVR!, а потом еще и такую статью накропать!
Вам наверное совсем-совсем нечем заняться?
Нет, серьезно, как вы зарабатываете, что столько свободного времени?
0
По моему, этот диспетчер изначально на асме был.
0
Вам наверное совсем-совсем нечем заняться?
Студенты видимо — первые шаги в освоении МК. Нормально.
Нет, серьезно, как вы зарабатываете, что столько свободного времени
А кто их знает как? Может нам такие деньги и не снились?
0
Переписать диспетчер на ассемблере
А так да — нехрен делать людям: на асме диспетчеры писать, да ещё и забесплатно. Видать времени вагон и дури хватает на десятерых как минимум…
-1
Есть такой человек… И у него было просто хобби
+1
Есть такой человек…
Ага — на ассемблере написал… как же…
у него было просто хобби…
В одну реку не войти дважды — если кто-то давным-давно заработал деньги-известность на чём-то, то это не значит что идя его путём можно достичь того же… потерять время — это запросто…
0
хобби
PS. Это было хобби? Он вроде курсач делал? Финский студент…
0
Ну всё! Обосрали идею :) Не пешите операционок на ассемблере, а если уж написали, не выкладывайте их в блог :)))
0
Не пешите операционок на ассемблере,
А зачем их на ассемблере писать? Смысл сего действа? Сделать программу непереносимой на другие МК?
+1
+1. Как только начался период подключения много кнопок, клавиатуры, дисплея, это признак того, что пора переходить на Си. Мне начало тяжело далось, поэтому я долго еще на асме сидел. Как только начались сдвиги на си, быстро переполз.
0
Как только начался период подключения
Сейчас можно сразу с Си начинать. Как и 10 лет назад…
0
Не согласен. Асм нужно хоть немного знать. Бывают проекты, памяти мало, критичные по времени моменты.
0
Асм нужно хоть немного знать
Берите МК побыстрее…
Бывают проекты, памяти мало, критичные по времени моменты.
От ошибок никто не застрахован.
0
Да что вы говорите? А если тинька малоногая? Ну устройство такое, только тиньку всунуть. мегу128 молотком забивать будем?
0
Ну устройство такое, только тиньку всунуть. мегу128 молотком забивать будем?
Нет, не будем. Поставим LPC8xxx в корпусе SOIC8 (CortexM0).
А если тинька малоногая?
Для тин тоже на Си писать можно (почти для всех за небольшим исключением).
0
Совершенно согласен.
Мой самый большой проект на асме, причем Пик (там команд 35 всего), был вольтметр сетевого напряжения с семисегментником. После этого я понял, что Си не хуже в смысле кода, но намного удобнее в смысле написания. Просто я его не знал, поэтому первое время тупил в синтаксис, да и сейчас в книгу заглядываю постоянно.
Однако асм совсем не исключаю, допуская, что некоторые проекты лучше на нем писать.
0
На досуге попробуйте выкачать сорсы линуха версии 0.1 и посмотреть.
0
Расскажи для особо ленивых — что мы там увидим?) Ну и где скачать?
0
www.kernel.org/pub/linux/kernel/Historic/

Ничего сверхособенного там нет. Чуток файлов на асме (процессоро-специфичные вещи типа переключения контекстов, работы со страницами и стартапа). Остальное — С.
0
Логичное разделение по языкам, да.
0
Именно. Никакого «на голом асме» и близко нет. Хотя, замечу, объем там совсем не больщой и написать на асме труда бы не составило.
+2
Есть и на голом асме — MenuetOS/KolibriOS. Впрочем, заодно наглядно показывает, кому такая ОС нужна.
0
Такой вот вопрос у меня возник: в начале статьи красивый такой рисунок user<->application<->RTOS<->Hardware. Как-то оно отражает принципы построение программы — идеалогию написания софта — … — тд и тп.
Или так, для красоты вставлено? У меня создалось впечатление что автор (как и многие) кроме таймерной службы в Оси ничего не видит… А таймерная службы на самом деле это… тьфу и растереть. Ничто — нонче tickless на острие прогресса.
0
Релиз!RELEASE: RTOS v2.1-alpha

+ Что сделано: "Служба таймеров RTOS" была вынесена из прерывания в "рабочий цикл"...
  Код ядра оптимизирован: занимает меньше места (за счет повторного использования метода RTOS_METHOD_AddTask).
  Но главный Profit: теперь Системе требуется глубина Стека на 4 байта меньше (ранее требовалось 12 байт, теперь 8 байт). Что актуально для МК с малым объёмом ОЗУ.
  Логика работы Системы и API - не изменились!
0
Автор топика запретил добавлять комментарии