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

Лучший тред за последние полгода по поднятию настроения.
Жду аргументов что asm круче це.
Удивляет сдержанность авторов scmRTOS.
Обещаю всем участникам отсутствие репрессий.

P.S. Может выделить все страницы креме первых в "Общение" ?

Это открытие, вероятно, было сделано после изучения обычных прерываний и усвоения, что же они такое из себя на самом деле. А когда были обнаружены кортексы с аппаратной поддержкой вложенного их варианта - это вызвало бурю эмоций, переворот микровселенной, повальный отказ от ОС в силу их внезапной но уже дремучей отсталости и попытки образумить толпу необразованных, продолжающих пользоваться ОС по явному недоразумению

Я посмотрел бегло эту ветку, как неравнодушный пользователь порта для BF.

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

Аргох, у меня к Вам вопрос:
Чего Вы хотите в связи с выходом 4-й версии scmRTOS? Ведь именно этому событию посвящено обсуждение в этой ветке.

Похоже, что главное Ваше желание - самовыразиться за чужой счет. Мало того, что это не очень хорошо, но еще и не полезно для кармы.

Успехов.

Я делаю просто: есть класс-UART, в нём содержатся очереди на приём и передачу:

И в прерываниях происходит обслуживание очередей:

Всё. Теперь любая задача, требующая работы с uart, выглядит вот так:


Посмотрите ещё вот эту ветку, там есть несколько вариантов.

Конкретный пример с цифрами не приведу, потому что не занимался таким исследованием. Зато могу сослаться на IAR, который предлагает два варианта компиляторв с С++ : -1: урезанный Embedded C++ для мелких кристалов, где надо экономить ресурсы памяти и -2. полнофункциональный Extended Embedded С++ с тяжелыми библиотеками. Так вот, темплейты C++ поддерживаются только тяжелым Extended. Отсюда и непонятное противоречие в scmRTOS- с одной стороны вроде заботятся о мелких кристаллах, а с другой- тут же все портят использованием темлейтов. Причем, как я понимаю, ради абстрактной красоты.

Могу вспомнить свой случай, к чему приводит использование темплейтов. В IAR сделал проект С++ без темплейтов для STR911FAM44 с ядром ARM-9. Приложение заняло примерно 160K кодов и констант во флеш. Потом соблазнился красотой темплейтов и оформил то же самое с темплейтами. Пришлось включать компиляцию с опцией Extended. Размер использованой флеш сразу вырос до 210K. "Имеющий уши- услышит".

Господа, давайте перестанем кормить тролля. Не хочется портить радостную ветку.

Мой мотив очень прост, решил исследовать вопрос - какой будет выигрыш от использования scmRTOS в моих задачах? Именно эта OS привлекла внимание тем, что она по-моему единственная предполагает использование C++. Начал с пары очень простых вопросов к авторам и апологетам. Ответы не впечатлили. Стало понятно, что продукт чисто софтовый, абстрактный, не учитывает развитие периферии современных микроконтроллеров. На этом собственно и все, диспут заканчиваю.



Были бы знакомы с современной периферией микроконтроллеров, то заменили бы кучу мелких прерываний от каждого символа, всего одним прерыванием по окончанию работы канала DMA, который сейчас имеется у каждого приличного UARTа. Глядишь, и очереди оформлять для многозадачной OS не потребовалось бы. На stm.com даже AN такой есть.

Кстати, у вас метод uart_t::irq_handler() представлен как член класса uart_t. Позвольте каверзный вопрос, как это удается в С++ оформить метод класса в виде ISR? Да еще и зарегестрировать соответствующий вектор в контроллере прерываний?

Хм, тут в теме такая жара, а я со своим контекстом лезу
Собрал из своих исходников файл с функцией tn_sem_signal() - собственно инкрементирует семафор и освобождаем ожидающую задачу. По возможности почистил от всяких фич других портов (оставил только относящееся к Cortex-M3), TN_ASSERT-ы, отладочные фичи и прочее, н еотносящее к вопросу. Файл даже компилируется - при желании можно посмотреть листинг.

Порядок исполнения такой:
- tn_sem_signal() - ставим семафор
- task_wait_complete() - пробуждаем ждущую задачу
- task_to_runnable() - переводим задачу в исполняемое состояние
- переключение контекста при первом же разрешении прерываний tn_unlock_interrupt() (PendSV)

Функция find_next_task_to_run() при этом даже не используется - нужна только при засыпании задачи, когда нужно выбрать задачу для исполнения из осташихся.

Если разблокируемая задача ждала без тайм-аута (с бесконечным таймаутом), то при пробуждении она удаляется из списка ожидания объекта и вставляется в список диспетчера - две операции со списками. Если был конечный тайм-аут - то задача удаляется еще и из списка системного таймера. В-общем, тут round-robin-а вообще не видно - естественно, он не исключен, просто никак на процесс пробуждения задачи не влияет.



"Огласите весь список пжлста" © "современных микроконтроллеров".
А у меня вот такой пример - PowerPC MPC83xx от Фрискейла, там PCI/PCIe, SATA, GbE, USB HS и еще всякая мелочь, линейка разработки 2005-2011 годов. Там нормально так периферия развита - куда уж современнее. И, представляете, оно вообще не поддерживает вложенные прерывания. И где Вы с Вашим подходом окажетесь? А, ну да, щаз скажете что Линукс наше фсе

Думаю, не надо. Тут, пусть и в размазанном виде, но есть рекомендации по разделению работы на «драйверную» и «процессовую» части, линки на другие темы по этому поводу. Пусть живёт.

Зато у не-современных Fujitsu MB90, у M16C, у Siemens C16x и STM ST10 — есть. Оно ведь как — решили что нужно сделать — сделали, хоть и давно. Решили что не нужно - не сделали, хоть и недавно. Они ведь слово «современный» без придыхания произносят, просто работу свою делают :-D


Уже сижу и вижу такой сам весь из себя экстрасенсорный канал ПДП, который знает, сколько я в терминале символов набрал, чтобы не по заполнению буфера прерывание выдать, а по последнему набранному мной символу.
Не бойтесь — когда надо, ПДП задействуется. Или FIFO. Или оба.

Не надо было скипать без прочтения код из http://electronix.ru/forum/index.php?s=&am...t&p=1049089.
Стоило сходить по ссылкам из сообщения http://electronix.ru/forum/index.php?showt...p;#entry1049007
Естественно, нестатический метод обработчиком не поставить. Естественно, статический можно либо вызвать из обработчика либо назначить обработчиком — в зависимости от возможностей компилятора.
С++ знаете так же хорошо, как и историю развития микроконтроллеров?

Тогда надо сравнить ещё время переключения на низкоприоритетную при постановке на ожидание высокоприоритетной.
У scmRTOS тут симметрия.

А вообще стоило бы мне наконец-то с TNKernel познакомиться ближе :-)


Зависит от. Если UART от отладочной консоли, то как AHTOXA показал — в прерывании тупо заталкивать принятые байты в очередь, а уже в процессе анализировать, включая редактирование строки и т.п.
Если данные пакетами ходят, то лучше весь пакет принять в прерывании, потом отдать его в процесс http://electronix.ru/forum/index.php?showt...mp;#entry841330
Проверка целостности пакета... CRC я бы в процессе проверял. Всё равно ему думать, что делать дальше. Хотя если это slave в каком-то протоколе, то, возможно, и не стоит теребить процесс битыми пакетами. Хотя если они не часто бывают, то не стоит в прерывании тратить считать контрольную сумму каждого пакета...
Вкусовой попрос. Куча <-> не куча.

А мужики-то не знают В том же мануале на эту ОС сказано, что пользователю вовсе не обязательно писать приложение на Си++. Для справки: микс из Си, Си++ и даже Асм прекрасно уживаются вместе. Предупрежу удивление: только не надо все в один файл помещать!


Исследовали?
Вот на этом Ваши исследования должны прекратиться, а Вы могли бы заняться полезной работой.





Кстати, высокомерие в любых проявлениях - это грех по христианским законам. Вы какого вероисповедания?

Отлично. Ждем порт на AVR и STM8

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

А вот здесь тоже не всё так однозначно. Дело в том, что пока мы сидим в прерывании, ОС не может сделать перепланировку. Представь, что мы, кроме UART-а, должны окучивать что-то быстрое, критичное ко времени реакции. Скажем, какие-нибудь импульсы измерять. Мы назначаем прерыванию от этих импульсов высокий приоритет, в прерывании делаем какую-то минимальную обработку, и взводим event для задачи с максимальным приоритетом. Вроде бы, мы должны практически сразу после прерывания попасть в высокоприоритетную задачу, но нет. Пока не доработает прерывание UART - мы не при делах

Весь список конечно не оглашу, но намекну на практически любой 32-бит чип с ядрами ARM-9/11 или Cortex M3/4. Я лично исторически прирос к продукции STM. Ее линейка STM32 имеет периферию, насыщенную дополнительными фичами. И эти фичи устраняют на аппаратном уровне узкие места в паралелльных задачах управления и связи, вытесяющие RTOS попросту становятся не нужны.

Я просто не стану связываться с допотопными архитектурами. А Линукс- да, вашей задаче супер-сервера в самый раз. Бессмысленно же изобретать велосипеды.



Да, посмотреть на себя со стороны критическим взглядом - очень полезно.

Ну, а как вы оцениваете на "современность" недавне появление DMA у периферии? Причем в любой комбинации, можно даже сквозной канал передачи организовать, например от UART прямо в SPI, минуя память и процессор. Зачем в этом случае посредники в виде RTOS?

Я-то не боюсь. Потому, что прерывание вырабатывается UART-ом не по фиксированному кол-ву принятых символов, а по time-out в конце непрерывной посылки. Фактическое число принятых символов можно посмотреть потом в контроллере DMA. Этот прием охватывает даже ваш пример следования одиночных символов, я уж не говорю про пакетный MODBUS.