AHTOXA 15 5 апреля, 2012 Опубликовано 5 апреля, 2012 · Жалоба Собственно, субж. Ссылки: Что нового (en); Migration Guide; Download; svn (trunk). User Manual (русский) User Manual (en) Кроме того, незадолго до этого была выпущена версия 3.11. Это завершающая, багофиксная версия 3.x. Ссылки: Download; svn. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 6 апреля, 2012 Опубликовано 6 апреля, 2012 · Жалоба Искренние поздравления! Использовал несколько раз третью ветку. Доволен! Самое то для маленьких МК) Быть может в будущем четверку возьму в проекты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 1 6 апреля, 2012 Опубликовано 6 апреля, 2012 · Жалоба Молодцы! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aprox 0 9 апреля, 2012 Опубликовано 9 апреля, 2012 · Жалоба Уважаемые авторы новой 4-ой версии! Позвольте пару вопросов от новичка, который только приглядывается к использованию OS и напряженно думает, зачем оно ему надо. 1. Вы ввели новое обзначение для типов переменных. Вопрос- чем не устраивают классические имена типов из С++? Зачем изобретать u32_t вместо всем знакомого из классики unsigned long? 2. В STM32 применен новый контроллер прерываний, отличный от старого VIC тем, что грамотно и надежно исполняет nested прерывания. Это nested каким-то образом нашло отражение в вашем порте на STM32? Или все по-старому, никаких nested ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Артём__ 0 9 апреля, 2012 Опубликовано 9 апреля, 2012 · Жалоба Или все по-старому, никаких nested ? А что по вашему раньше нельзя было? Код из примера v3 #define ENABLE_NESTED_INTERRUPTS() __enable_interrupt() #pragma vector=TIMER1_COMPA_vect OS_INTERRUPT void Timer1_period_ISR() { OS::TISRW_SS ISRW; ENABLE_NESTED_INTERRUPTS(); Timer1_Ovf.SignalISR(); } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bookevg 0 9 апреля, 2012 Опубликовано 9 апреля, 2012 · Жалоба 1. Вы ввели новое обзначение для типов переменных. Вопрос- чем не устраивают классические имена типов из С++? Зачем изобретать u32_t вместо всем знакомого из классики unsigned long? Для embedded привычно указание в типе его разрядность. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 9 апреля, 2012 Опубликовано 9 апреля, 2012 · Жалоба 1. Вы ввели новое обзначение для типов переменных. Вопрос- чем не устраивают классические имена типов из С++? Зачем изобретать u32_t вместо всем знакомого из классики unsigned long?Во-первых все уже придумано до нас. эти типы являются частью стандарта C-99 (см. описание stdint.h) . Их вводили потому, что разрядность char, short, int, long, long long стандартом не определена. И еще для того, чтобы код без переписывания компилился максимально оптимально под любую платформу. И если нам нужно целое для хранения значения то 0 до 255, то на 8-битном AVR или 16-битном MSP430 для этого оптимально подходит байт (т.е. тип unsigned char на этих платформах), а для ARM более эффективен будет 32-битный unsigned int, ибо процессор не имеет 8-битной арифметики и вынужден будет постоянно преобразовывать 8 бит в 32 и обратно. Стандарт гарантирует, что тип uint_fast8_t будет удовлетворять нашим требованиям. Если копнуть глубже, то обнаружится, что для AVR этот тип будет компилиться в unsigned char а для ARM - в unsigned int. Не трогая исходников, что очень важно для многоплатформенного кода. Если пример с арифметикой вас не убеждает - подумайте о типе uintptr_t, т.е. целое, в котором умещается указатель. Размеры указателя на разных платформах отличаются. А во-вторых писать unsigned long слишком длинно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aprox 0 10 апреля, 2012 Опубликовано 10 апреля, 2012 · Жалоба А что по вашему раньше нельзя было? Наверное можно. Но при этом нельзя было размещать внутри ISR длительных операций которые блокировали бы работу OS и всей системы в целом. Теперь, с появлением nested контроллера прерываний в ISR можно размещать практически целые статические task( за исключением инициализации задачи) и не боятся блокировки всей системы. Такой прием особенно хорош еще и тем, что в STM32 периферия взаимодействует с памятью по DMA, поэтому нагрузка на систему по прерываниям резко ниже. Вот, я и спрашиваю - учтены ли эти новации периферии в новой версии scmRTOS? Во-первых все уже придумано до нас. эти типы являются частью стандарта C-99 (см. описание stdint.h) . Их вводили потому, что разрядность char, short, int, long, long long стандартом не определена. И еще для того, чтобы код без переписывания компилился максимально оптимально под любую платформу. Мне представляется, заботу об оптимальности использования памяти или скорости выполнения кода берет на себя компилятор C++. По крайней мере, в IAR это именно так. Пользователю знать, в какой размер битов упакована его переменная, как правило не обязательно. По делу, ему важно знать только пределы изменения переменной. А эта информация представлена в мануалах на любой компилятор, например там пишут : unsigned char 0 .. 255 signed char -128 .. +127 .... и т.д. А во-вторых писать unsigned long слишком длинно. Зато кросплатформенность соблюдается. Причем в мощных системах проектирования (Visual Studio), реализован умный редактор текстов, который подсказывает тип переменной и даже сам его вписывает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 10 апреля, 2012 Опубликовано 10 апреля, 2012 · Жалоба Зато кросплатформенность соблюдается.Какраз наоборот:( Я бы поменял местами встречающуюся в коде последовательнсть: INLINE static на static INLINE Ибо попадались Си-шные компиляторы дающие предупреждение на то что сначала должен идти storage квалификатор. Хотя тут С++, может и не быть никаких предупреждений, но у меня в голове это засело крепко и я уже как бык на красную тряпку реагирую... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 10 апреля, 2012 Опубликовано 10 апреля, 2012 · Жалоба Мне представляется, заботу об оптимальности использования памяти или скорости выполнения кода берет на себя компилятор C++. По крайней мере, в IAR это именно так. Пользователю знать, в какой размер битов упакована его переменная, как правило не обязательно.Никакой заботы компилятор предоставить не может . Вот укажете вы какой-нибудь переменной unsigned int чтобы было быстро на ARM, и компилятор будет вынужден использовать 2 байта на AVR, хотя может быть и достаточно одного. А укажете unsigned char - и компилятор для ARM будет вынужден после каждой арифметической операции обрезать 24 старших бита, ибо делать арифметику с байтами ядро делать не умеет. А укажете uint_fast8_t и все будут довольны. Чем плохо? По делу, ему важно знать только пределы изменения переменной. А эта информация представлена в мануалах на любой компиляторТо есть для каждой переменной мы должны просматривать мануалы на все компиляторы всех процессоров, под которые портирована ОС и искать тот тип, который удовлетворит нас для этой переменной на всех платформах/компиляторах? Но зачем, если специально для такого случая придуман stdint.h? И во многих случаях один стандартный тип не будет одинаково хорош на всех платформах, пример выше. Зато кросплатформенность соблюдается. Причем в мощных системах проектирования (Visual Studio), реализован умный редактор текстов, который подсказывает тип переменной и даже сам его вписывает.Кроссплатформенность еще лучше соблюдается с типами из stdint.h. И с этими типами прекрасно себя чувствует умный редактор типа Eclipse. Если Студия спотыкется на стандартных заголовочных файлах - увы. Как же она тогда работает с остальными typedef, в том числе и пользовательскими? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 10 апреля, 2012 Опубликовано 10 апреля, 2012 · Жалоба Я бы поменял местами встречающуюся в коде последовательнсть:INLINE static на static INLINE Причина? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 10 апреля, 2012 Опубликовано 10 апреля, 2012 · Жалоба ответил в предыдущем посте. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 71 10 апреля, 2012 Опубликовано 10 апреля, 2012 · Жалоба Зато кросплатформенность соблюдается. помимо приведённого примера с uint_fast8_t, который хоть и медленее, но работать будет, могут быть еще замечательные грабли вида for (int i = 0; i < 100000; i++){...} если тип int вдруг внезапно окажется 16 разрядов вместо 32 и 100000 в него уже не влезет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 10 апреля, 2012 Опубликовано 10 апреля, 2012 · Жалоба Вот, я и спрашиваю - учтены ли эти новации периферии в новой версии scmRTOS? Вложенные прерывания у Cortex-M3 порта можно использовать, как в новой, так и в старой версии scmRTOS. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 10 апреля, 2012 Опубликовано 10 апреля, 2012 · Жалоба Я бы поменял местами встречающуюся в коде последовательнсть:INLINE static на static INLINE Ибо попадались Си-шные компиляторы дающие предупреждение на то что сначала должен идти storage квалификатор. Хотя тут С++, может и не быть никаких предупреждений, но у меня в голове это засело крепко и я уже как бык на красную тряпку реагирую... Ну, как только (если) возникнет такой вопрос, так сразу и будем решать. Пока, вродь, не было прецедентов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться