[aprox 0]

Естественно, нестатический метод обработчиком не поставить.

Отчего же? Что нам мешает динамически изменять вектора в контроллере прерываний? Дело же в другом- ISR должна быть оформлена по другому, не как обычные процедуры и функции.

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

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

Вполне достаточно, чтобы понять- методы в классах нельзя назначать как ISR. В принципе нельзя, независимо от возможностей компилятора. На эту ошибку я и указал Antoxa. Что же касается вызвать метод класса из настоящей ISR, то последняя должна размещаться в программном модуле, тоже написанном на С++. И вот, я действительно не знаю- есть ли в компиляторе С++, например IAR, такие служебные слова, которые превращают обычную функцию в ISR? Если знаете- буду очень признателен услышать.

 

 

 

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

:bb-offtopic: Кстати, высокомерничать не я первый начал. Однако, поступаю по-христиански: "Око за око, зуб за зуб" (с)-Нагорная проповедь

 

[Nixon 4]

Ржу, аки конь. Со слезами на глазах.

2 Aprox - читать вам еще не перечитать книжки по C++. Иначе вас размажут аки блин местные спецы. Через полгода заходите.

[IgorKossak 0]

Такая настойчивость уже начинает раздражать.

Aprox, специально для Вас объясняю.

1. У любой, сколько-нибудь сложной задачи существует более одного способа решения, основанных на целой куче исходных данных, выходных результатов, имеющихся инструментов, наработок, time to market, способности к расширению, изменению и т. д.

2. Любое решение будет в той или иной степени приемлемым и имеющим право на жизнь.

Поэтому Ваши безапелляционные суждения вроде "RTOS себя изжили" Вам следовало бы произносить примерно так: "Конкретно мной, отталкиваясь от моих личных, весьма предвзятых и далеко не исчерпывающих опыта, знаний, предпочтений, религиозных убеждений, в моей частной задаче было принято решение, которое никоим образом не относится к данной теме. Извините, что вклинился". И произнести это надо было именно про себя, т. е. даже не вслух. Ибо Ваши сообщения в этой теме, начиная с первого, являются ни чем иным как нарушением правил форума.

Считайте это предупреждением.

Модератор.

[aprox 0]

А вот здесь тоже не всё так однозначно. Дело в том, что пока мы сидим в прерывании, ОС не может сделать перепланировку.

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

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

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

[Артём__ 0]

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

А что, разве scmRTOS и nested interrupt - несовместимы?

[AHTOXA 18]

Господа, мы кормим тролля. Ему абсолютно до лампочки все объяснения, его невозможно в чём-то убедить. Единственное действенное средство - игнорировать. ( Ну или забанить:) )

[blackfin 32]

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

Как ни крути, а "чтобы успеть за всеми быстрыми процессами" нужно каждому прерыванию по отдельному процессору!

 

Welcome to FPGA!

 

Такая настойчивость уже начинает раздражать.

Считайте это предупреждением.

Модератор.

Так ведь, если время от времени публика не будет принимать участия в "боях без правил", она же захиреет..

 

А так - синяки, эмоции, тонус, адреналин.. Жизнь!

[ReAl 0]

Ну, а как вы оцениваете на "современность" недавне появление DMA у периферии?

Вы знаете — ну прекрасно отношусь!

Только давайте уточним, что опять имеется ввиду под «современностью» и что означает «недавнее» —

Десять лет (MSP430x15x/16x)?

Пятнадцать-двадцать (M16C, Fujitsu MB90).

Или все двадцать-двадцать пять? PTS (Peripheral Transaction Service) в однокристалках Intel MCS196 (оно и в MCS96 было, но я с ними не работал совсем) был таким хитрым DMA, который при разрешении отрабатывал по тому же запросу, что запрос прерывания, т.е. специальной линии запроса DMA не было, но при разрешении PTS оно перехватывал прерывание на себя, делал пересылку. Когда его задание заканчивалось — он просто переставал перехватывать прерывание на себя и отрабатывал назначенный обработчик.

Или ещё больше — в многокристальных микропроцессорных комплектах, например, КПДП 580ВТ37 aka i8237, перекочевавший позже внутрь чипа в контроллеры на базе i186 и в материнки IBM PC.

 

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

И какой смысл пересылать по одному байту через DMA, чтобы потом по таймауту узнать, что это был один байт?

 

Естественно, нестатический метод обработчиком не поставить.

Отчего же? Что нам мешает динамически изменять вектора в контроллере прерываний?

Кгм... Вы имеете понятие о разнице между свободной функцией либо статической функцией-членом класса и нестатической функцией-членом? О неявной передаче указателя this? Что указатель на свободную функцию/статический метод и на функцию-член имеют разные размеры (указатель на нестатический член класса — целая структура из нескольких полей)?

Что аппаратура контроллера по вектору может только вызвать функцию void (*)(void), но не может передать ей указатель на экземпляр класса?

Мдааа.... Я начинаю уставать.....

 

Дело же в другом- ISR должна быть оформлена по другому, не как обычные процедуры и функции.

Несомненно. Для устаревших контроллеров. Для современных Cortex-ов это не так — Вы что, действительно этого не знаете?!!

Но и для устаревших контроллеров некоторые компиляторы поддерживают назначение статических методов класса на вектора, так как указатель на статический метод по форме не отличается от указателя на С-функцию, а их компиляторы умеют оформлять как обработчкик прерываний (это IAR для AVR):

class uart_t
{
public:
...
private:
...
    #pragma vector = USART_RXC_vect
    static __interrupt void  RxHandler(void);
    #pragma vector = USART_UDRE_vect
    static __interrupt void  TxHandler(void);
}

 

Вполне достаточно, чтобы понять- методы в классах нельзя назначать как ISR. В принципе нельзя, независимо от возможностей компилятора.

Вы бы таки сходили по предложенным ссылкам. И подумали о различии статических и нестатических функций-членов. Потом говорили бі «невозможно» по поводу того, что работает (цитаты кода из так и непросмотренных Вами ссылок).

#pragma vector = USART1TX_VECTOR
__interrupt void TUART::TxBUF_Empty_ISR()
{
    U1TXBUF = TxBuf.pop();
    if(TxBuf.get_count() == 0) DisableTxInt();
}

class    TUart1 : public TCustomUart
{
   public:
       TUart1(uint32_t baudrate) {hw_init(baudrate);}
   protected:
       ...
       virtual void hw_init(uint32_t baudrate);
       virtual void write_tx_reg(char ch) { TXBUF0 = ch; }
       static interrupt(UART0RX_VECTOR) usart0_rx(void);
       static interrupt(UART0TX_VECTOR) usart0_tx(void);
};

...

interrupt(UART0TX_VECTOR) TUart1::usart0_tx(void)
{
   OS::TISRW ISR;
   char ch;
   if (Uart1.TxChannel.get_count())
   {
       Uart1.TxChannel.pop(ch);
       TXBUF0 = ch;
   }
   else
   {
       Uart1.tx_active = false;
   }
}

 

Что же касается вызвать метод класса из настоящей ISR, то последняя должна размещаться в программном модуле, тоже написанном на С++. И вот, я действительно не знаю- есть ли в компиляторе С++, например IAR,

Ну я опять Вас отправлю к моему сообщению с кусокм кода, про который Вы написали «коды skipped».

Там это было продемонстрировано для avr-gcc в виде модификации main.cpp из одного из примеров scmRTOS. В C++ файле свободная функция - обработчик прерывания, которая объявлена другом класса и вызывает приватный нестатический метод класса.

И там же я написал, что всё было проверено в железе. Т.е. я и так был уверен. что всё работает, но, как обычно, не хотел выкладывать код с возможными описками.

 

В примерх scmRTOS обработчики прерываний сидят себе в main.cpp, обработчик системного таймера — в OS_Target_cpp.cpp и всё работет.

IAR же вообще позволяет прямо в описании класса непосредственно статический метод объявить обработчиком, ссылки на примеры по форуму я Вам тоже уже давал.

 

Так Вы и исходники scmRTOS не смотрели перед тем, как, извините, трындеть тут?

 

Господи, я думал, Вы хоть язык С++ да его компиляторы знаете... Так же ж страдали за поддержку возможностей языка современными микроконтроллерами...

 

Господа, мы кормим тролля. Ему абсолютно до лампочки все объяснения, его невозможно в чём-то убедить.

Согласен.

Убедить можно того, кто что-то по теме знает и готов слушать.

[Nixon 4]

Aprox'у медаль за совершение невозможного - я ранее считал что Александр не умеет ругаться вообще. :)

[aprox 0]

Как ни крути, а "чтобы успеть за всеми быстрыми процессами" нужно каждому прерыванию по отдельному процессору!

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

Welcome to FPGA!

Уже.

 

 

1. У любой, сколько-нибудь сложной задачи существует более одного способа решения, основанных на целой куче исходных данных, выходных результатов, имеющихся инструментов, наработок, time to market, способности к расширению, изменению и т. д.

2. Любое решение будет в той или иной степени приемлемым и имеющим право на жизнь.

Согласен, что решений много. Но категорически не согласен, что все они равноценны и имеют право на жизнь.

Поэтому Ваши безапелляционные суждения вроде "RTOS себя изжили" Вам следовало бы произносить примерно так: "Конкретно мной, отталкиваясь от моих личных, весьма предвзятых и далеко не исчерпывающих опыта, знаний, предпочтений, религиозных убеждений, в моей частной задаче было принято решение, которое никоим образом не относится к данной теме. Извините, что вклинился".

Интересно, а как вы представляете себе еще можно оценить достоинства некого универсального инструмента вроде эхотажной scmRTOS, кроме как не примерив этот инструмент к своим лично целям и практическим задачам? Ну, как еще? Слепо довериться авторитету авторов? Поддаться очарованию их знаниям языка С++?

 

И потом, я не говорил, что все "RTOS себя изжили", а только вытесняющего типа. Потому что, грубо говоря, заботу об "вытеснении" в значительной степени теперь берет на себя встроенная в микроконтроллер периферия. Вполне допускаю, что этот медицинский факт в данной конференции у многих вызывает раздражение и обиды. Не возражаю перенести обсуждение в другую ветку с более спокойной реакцией на очевидные вещи.

 

[IgorKossak 0]

Всё, терпение лопнуло. Aprox получил 15 суток read only за троллинг.

Модератор.

[Nixon 4]

Не успел :( Хотел попросить Игоря не наказывать, но не успел. Уж больно забавная тема получилась.

 

P.S. Не забыть попросить о том же модераторов в ветке FPGA. Судя по всему нас и там ждут незабываемые открытия.

[mdmitry 0]

... как не примерив этот инструмент к своим лично целям и практическим задачам?

Задачи у каждого свои. Надо ли применять конкретный инструмент для конкретной задачи разработчик решает сам. При этом разработчик IMHO, не должен навязывать другим свое мнение о применимости или не применимости конкретного инструмента.

 

Извините.

[bav 0]

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

а IgorKossak ничего не обещал... жестоко...

 

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

мое мнение - если нет надобности в ОС, то и не надо.

 

также затронул тему про ненужность новых типов (uint8, uint16 и т.п.) - опять же кому как удобно.

 

а по-поводу scmRTOS - использовал в нескольких проектах. работают стабильно.

в одном пришлось отказаться, т.к. пришлось добавлять функциональность, а места для хранения и обработки данных в камне не хватило.

 

разработчикам уважуха :cheers:

было бы не плохо в состав ОС добавить обработчики прерываний для UART, SPI, и т.п. с буферами, обработчиками ошибок и т.д.

[Nixon 4]

а IgorKossak ничего не обещал... жестоко...

Это его ветка, он тут хозяин.

было бы не плохо в состав ОС добавить обработчики прерываний для UART, SPI, и т.п. с буферами, обработчиками ошибок и т.д.

Ни в коем случае! Что вы! Даже жестко коммерческие проекты разделяют собственно OS и middleware.