AHTOXA 25 April 5, 2012 Posted April 5, 2012 · Report post Собственно, субж. Ссылки: Что нового (en); Migration Guide; Download; svn (trunk). User Manual (русский) User Manual (en) Кроме того, незадолго до этого была выпущена версия 3.11. Это завершающая, багофиксная версия 3.x. Ссылки: Download; svn. Quote Share this post Link to post Share on other sites More sharing options...
haker_fox 163 April 6, 2012 Posted April 6, 2012 · Report post Искренние поздравления! Использовал несколько раз третью ветку. Доволен! Самое то для маленьких МК) Быть может в будущем четверку возьму в проекты. Quote Share this post Link to post Share on other sites More sharing options...
FatRobot 8 April 6, 2012 Posted April 6, 2012 · Report post Молодцы! Quote Share this post Link to post Share on other sites More sharing options...
aprox 0 April 9, 2012 Posted April 9, 2012 · Report post Уважаемые авторы новой 4-ой версии! Позвольте пару вопросов от новичка, который только приглядывается к использованию OS и напряженно думает, зачем оно ему надо. 1. Вы ввели новое обзначение для типов переменных. Вопрос- чем не устраивают классические имена типов из С++? Зачем изобретать u32_t вместо всем знакомого из классики unsigned long? 2. В STM32 применен новый контроллер прерываний, отличный от старого VIC тем, что грамотно и надежно исполняет nested прерывания. Это nested каким-то образом нашло отражение в вашем порте на STM32? Или все по-старому, никаких nested ? Quote Share this post Link to post Share on other sites More sharing options...
Артём__ 1 April 9, 2012 Posted April 9, 2012 · Report post Или все по-старому, никаких 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(); } Quote Share this post Link to post Share on other sites More sharing options...
bookevg 1 April 9, 2012 Posted April 9, 2012 · Report post 1. Вы ввели новое обзначение для типов переменных. Вопрос- чем не устраивают классические имена типов из С++? Зачем изобретать u32_t вместо всем знакомого из классики unsigned long? Для embedded привычно указание в типе его разрядность. Quote Share this post Link to post Share on other sites More sharing options...
Сергей Борщ 187 April 9, 2012 Posted April 9, 2012 · Report post 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 слишком длинно. Quote Share this post Link to post Share on other sites More sharing options...
aprox 0 April 10, 2012 Posted April 10, 2012 · Report post А что по вашему раньше нельзя было? Наверное можно. Но при этом нельзя было размещать внутри 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), реализован умный редактор текстов, который подсказывает тип переменной и даже сам его вписывает. Quote Share this post Link to post Share on other sites More sharing options...
demiurg_spb 1 April 10, 2012 Posted April 10, 2012 · Report post Зато кросплатформенность соблюдается.Какраз наоборот:( Я бы поменял местами встречающуюся в коде последовательнсть: INLINE static на static INLINE Ибо попадались Си-шные компиляторы дающие предупреждение на то что сначала должен идти storage квалификатор. Хотя тут С++, может и не быть никаких предупреждений, но у меня в голове это засело крепко и я уже как бык на красную тряпку реагирую... Quote Share this post Link to post Share on other sites More sharing options...
Сергей Борщ 187 April 10, 2012 Posted April 10, 2012 · Report post Мне представляется, заботу об оптимальности использования памяти или скорости выполнения кода берет на себя компилятор C++. По крайней мере, в IAR это именно так. Пользователю знать, в какой размер битов упакована его переменная, как правило не обязательно.Никакой заботы компилятор предоставить не может . Вот укажете вы какой-нибудь переменной unsigned int чтобы было быстро на ARM, и компилятор будет вынужден использовать 2 байта на AVR, хотя может быть и достаточно одного. А укажете unsigned char - и компилятор для ARM будет вынужден после каждой арифметической операции обрезать 24 старших бита, ибо делать арифметику с байтами ядро делать не умеет. А укажете uint_fast8_t и все будут довольны. Чем плохо? По делу, ему важно знать только пределы изменения переменной. А эта информация представлена в мануалах на любой компиляторТо есть для каждой переменной мы должны просматривать мануалы на все компиляторы всех процессоров, под которые портирована ОС и искать тот тип, который удовлетворит нас для этой переменной на всех платформах/компиляторах? Но зачем, если специально для такого случая придуман stdint.h? И во многих случаях один стандартный тип не будет одинаково хорош на всех платформах, пример выше. Зато кросплатформенность соблюдается. Причем в мощных системах проектирования (Visual Studio), реализован умный редактор текстов, который подсказывает тип переменной и даже сам его вписывает.Кроссплатформенность еще лучше соблюдается с типами из stdint.h. И с этими типами прекрасно себя чувствует умный редактор типа Eclipse. Если Студия спотыкется на стандартных заголовочных файлах - увы. Как же она тогда работает с остальными typedef, в том числе и пользовательскими? Quote Share this post Link to post Share on other sites More sharing options...
dxp 218 April 10, 2012 Posted April 10, 2012 · Report post Я бы поменял местами встречающуюся в коде последовательнсть:INLINE static на static INLINE Причина? Quote Share this post Link to post Share on other sites More sharing options...
demiurg_spb 1 April 10, 2012 Posted April 10, 2012 · Report post ответил в предыдущем посте. Quote Share this post Link to post Share on other sites More sharing options...
_pv 107 April 10, 2012 Posted April 10, 2012 · Report post Зато кросплатформенность соблюдается. помимо приведённого примера с uint_fast8_t, который хоть и медленее, но работать будет, могут быть еще замечательные грабли вида for (int i = 0; i < 100000; i++){...} если тип int вдруг внезапно окажется 16 разрядов вместо 32 и 100000 в него уже не влезет. Quote Share this post Link to post Share on other sites More sharing options...
AHTOXA 25 April 10, 2012 Posted April 10, 2012 · Report post Вот, я и спрашиваю - учтены ли эти новации периферии в новой версии scmRTOS? Вложенные прерывания у Cortex-M3 порта можно использовать, как в новой, так и в старой версии scmRTOS. Quote Share this post Link to post Share on other sites More sharing options...
dxp 218 April 10, 2012 Posted April 10, 2012 · Report post Я бы поменял местами встречающуюся в коде последовательнсть:INLINE static на static INLINE Ибо попадались Си-шные компиляторы дающие предупреждение на то что сначала должен идти storage квалификатор. Хотя тут С++, может и не быть никаких предупреждений, но у меня в голове это засело крепко и я уже как бык на красную тряпку реагирую... Ну, как только (если) возникнет такой вопрос, так сразу и будем решать. Пока, вродь, не было прецедентов. Quote Share this post Link to post Share on other sites More sharing options...
