[_pv 79]

Неужели не в курсе, что современные чипы позволяют организовать работу всего этого одновременно в псевдопараллельном режиме c вытеснением по приоритету?

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

[Nixon 4]

Лучший тред за последние полгода по поднятию настроения. :)

Жду аргументов что asm круче це.

Удивляет сдержанность авторов scmRTOS.

Обещаю всем участникам отсутствие репрессий.

 

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

[sonycman 1]

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

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

[FatRobot 4]

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

 

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

 

Аргох, у меня к Вам вопрос:

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

 

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

 

Успехов.

 

[AHTOXA 18]

Интересуют соображения о распределении действий между обработчиками прерываний (USART и т.д) и задачами ОС.

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

class uart_t
{
private:
    OS::channel<char, 32, uint32_t> RxChannel;
    OS::channel<char, 32, uint32_t> TxChannel;
...
public:
    virtual void putch(char ch) { TxChannel.push(ch); enable_tx_interrupt(); }
    virtual int getch(int timeout = 0);
    virtual int keypressed(void) {return RxChannel.get_count(); }
    virtual int cansend(void) {return TxChannel.get_free_size(); }
    virtual int tx_empty(void) {return !TxChannel.get_count(); }
...
}

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

void uart_t::irq_handler()
{
    uint16_t status = USARTx->SR;
    if (status & USART_SR_RXNE) {
        uint8_t ch = USARTx->DR;
        if (RxChannel.get_free_size())
            RxChannel.push(ch);
    }

    if (status & USART_SR_TXE) {
        if (TxChannel.get_count()) {
            char ch = 0;
            TxChannel.pop(ch);
            USARTx->DR = ch;
        } else {
            disable_tx_interrupt();
        }
    }
}

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

template<>
OS_PROCESS void TUartProcess::exec()
{
    for(;;)
    {
        char ch = uart.getch();
        handle_char(ch);
    }
}

 

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

 

[aprox 0]

И сколько-же именно будет впустую истрачено такими-сякими темплейтами? Сотни байт? Килобайты? Можете привести конкретный пример с кучей "впустую" истраченных байт?

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

 

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

 

 

[AHTOXA 18]

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

[aprox 0]

Аргох, у меня к Вам вопрос:

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

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

 

 

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

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

 

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

 

 

[VslavX 0]

Хм, тут в теме такая жара, а я со своим контекстом лезу :)

Собрал из своих исходников файл с функцией 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 годов. Там нормально так периферия развита - куда уж современнее. И, представляете, оно вообще не поддерживает вложенные прерывания. И где Вы с Вашим подходом окажетесь? А, ну да, щаз скажете что Линукс наше фсе

tn_test.rar

[ReAl 0]

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

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

 

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

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

 

 

Были бы знакомы с современной периферией микроконтроллеров, то заменили бы кучу мелких прерываний от каждого символа, всего одним прерыванием по окончанию работы канала DMA, который сейчас имеется у каждого приличного UARTа.

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

Не бойтесь — когда надо, ПДП задействуется. Или FIFO. Или оба.

 

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

Не надо было скипать без прочтения код из http://electronix.ru/forum/index.php?s=&am...t&p=1049089.

Стоило сходить по ссылкам из сообщения http://electronix.ru/forum/index.php?showt...p;#entry1049007

Естественно, нестатический метод обработчиком не поставить. Естественно, статический можно либо вызвать из обработчика либо назначить обработчиком — в зависимости от возможностей компилятора.

С++ знаете так же хорошо, как и историю развития микроконтроллеров?

 

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

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

У scmRTOS тут симметрия.

 

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

 

 

Интересуют соображения о распределении действий между обработчиками прерываний (USART и т.д) и задачами ОС. Например, анализ пакета на целостность (I) и анализ данных (II): a) I - в обработчике прерывания полностью, II - в задаче ОС, б) I - прием данных в обработчике, целостность в задаче ОС, II - в задаче ОС. Можно разбить на другие подзадачи. Такое разбиение должно зависеть от задачи, но как правильно разбить? Из каких критериев исходить?

Зависит от. Если UART от отладочной консоли, то как AHTOXA показал — в прерывании тупо заталкивать принятые байты в очередь, а уже в процессе анализировать, включая редактирование строки и т.п.

Если данные пакетами ходят, то лучше весь пакет принять в прерывании, потом отдать его в процесс http://electronix.ru/forum/index.php?showt...mp;#entry841330

Проверка целостности пакета... CRC я бы в процессе проверял. Всё равно ему думать, что делать дальше. Хотя если это slave в каком-то протоколе, то, возможно, и не стоит теребить процесс битыми пакетами. Хотя если они не часто бывают, то не стоит в прерывании тратить считать контрольную сумму каждого пакета...

Вкусовой попрос. Куча <-> не куча.

 

[haker_fox 61]

Вы же этим и юзера заставляете писать на C++.

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

 

Мой мотив очень прост, решил исследовать вопрос - какой будет выигрыш от использования scmRTOS в моих задачах?

Исследовали?

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

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

 

 

 

Были бы знакомы с современной периферией микроконтроллеров

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

[Nixon 4]

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

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

 

[mdmitry 0]

Зависит от. Если UART от отладочной консоли, то как AHTOXA показал — в прерывании тупо заталкивать принятые байты в очередь, а уже в процессе анализировать, включая редактирование строки и т.п.

Если данные пакетами ходят, то лучше весь пакет принять в прерывании, потом отдать его в процесс http://electronix.ru/forum/index.php?showt...mp;#entry841330

Проверка целостности пакета... CRC я бы в процессе проверял. Всё равно ему думать, что делать дальше. Хотя если это slave в каком-то протоколе, то, возможно, и не стоит теребить процесс битыми пакетами. Хотя если они не часто бывают, то не стоит в прерывании тратить считать контрольную сумму каждого пакета...

Вкусовой попрос. Куча <-> не куча.

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

Спасибо, буду думать.

[AHTOXA 18]

Если данные пакетами ходят, то лучше весь пакет принять в прерывании, потом отдать его в процесс

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

 

[aprox 0]

"Огласите весь список пжлста" © "современных микроконтроллеров".

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

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

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

 

 

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

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

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

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

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

Не бойтесь — когда надо, ПДП задействуется. Или FIFO. Или оба.

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