Сергей Борщ

Ну если вам больше нравятся окна, в AVR-Studio они тоже есть. Меню View (в режиме отладки), а там уже то что надо, регистры/память/watch... Ну если есть - хорошо, не знал. Теперь буду знать. Спасибо, сняли психологический барьер. Теперь если понадобится - поставлю студию без предубеждения.

В AVR-Studio есть свои прелести. Особливо если дерево использовать в сочетании с JTAGом. Любой клик в дереве влияет непосредственно на МК. К примеру можно мышкой задавать на портах требуемые последовательности. В ИАРе такое проделывать сложнее (если вообще возможно) Для АВРов не пользуюсь, а для MSP430, ARM - то же самое, только не мышкой а циферки вбивать. Можно сразу на весь порт, можно в каждый бит (0/1). В AVRStudio напрягает именно листать дерево. Меня интересуют, скажем, регистры ядра и UART. В ИАРе поставил рядом два окошка, в AVRStudio - жимкать на окно и колесом или полосу прокрутки туда-сюда. "Раздражает!" :-)

ИАР через JTAG, еслои JTAG нет - мигание светодиодом + вывод диагностики через UART (иногда форт-подобный интерпретатор команд в МК через UART). Если UART занят - через программный на свободной ножке. Не могу понять чего народу так нравится AVRStudio - в нем же вся периферия в виде дерева в одном окне. В ИАРе могу открыть несколько окон, в каждом своя периферия, в AVRStudio полистал это окно с периферией минут 10, плюнул и вернулся к железу и выводу диагоностики через UART.

Кол-во процессов scmRTOS_PROCESS_COUNT надо делать таким, сколько требуется, и не больше, т.к. внутри void OS::TKernel::SystemTimer() есть цикл for(byte i = 0; i < scmRTOS_PROCESS_COUNT; i++).Другое дело, что может быть действительно сделать TProcessMap 32-разрядным, хотя это и не вписывается в идеологию scmRTOS об экономии ОЗУ :). Как вариант, ширину TProcessMap можно сделать по потребности, а ее уже приводить к 32 разрядам внутри GetHighPriority(), если позволит компилятор. Да, так и будем делать - размер TProcessMap минимально необходимый. Про 32 процесса с Гарри утрясли, про GetHighPriority() - для кол-ва процессов меньше 7 сделаю табличный метод - размер таблицы будет те же 64 байта для 6 процессоа, для меньшего кол-ва соответственно меньше. Беру тайм-аут до выходных - в пятницу надо изделие на выставку отправлять а софт еще процентов на 40 написан.

А нафиг? GetHighPriority() лежит в порте ОС, т.е. предназначена именно для ARM. Сделать внутри этой функции static_cast аргумента для ntz (на взгляд профана в С++) - из большей корзины не выпадет, а для nlz из результата вычесть 8 или 24 внутри препроцессорных #if #else. Просто в зависимости от количества процессов аргумент для ntz 8, 16 или 32 бит. Или не морочить голову - вроде много тут уже не наэкономить?

Спасибо всем, кто подсказал функцию поиска наиболее приоритетного процесса. Просмотрел все варианты на http://www.hackersdelight.org/HDcode/ntz.cc, наиболее эффективно компилится вариант подсказанный sergeeff за счет замены + на |. Теперь пытаюсь разобраться как оно работает чтобы написать такую же но для x = 8 и 16 бит. Кто-нибудь такое делал?

Нет в АРМ такой инструкции. Я так и ответил :-)

Завтра (в понедельник) буду изучать все это вдумчиво. Пока быстрый ответ такой: 1) приложение исполняется в System mode чтобы можно было запрещать/разрешать прерывания не задействуя SWI с разбором кода команды и ветвлением на функции запрета/разрешения/прочего. 2) FIQ не запрещется ибо предполагается что на то оно и быстрое чтобы из него сервисы ОС не вызывались. 3) __disable_interrupt()/__enable_interrupt() не используются именно потому что запрещает и IRQ и FIQ (см. п. 2). 4) Не разобрался до конца со SWI но мне кажется что если его вызвать внутри обработчика IRQ то проц уйдет в исключение SWI если не сразу то в момент переключения в System mode при разрешении вложенных прерываний. Буду изучать детальнее. 5) Идея при входе в критическую секцию запрещать не все прерывания а только прерывание переключения контекста была мною предложена автору scmRTOS недели 2-3 назад, он ее пока думает.

Отлично! Гарри как раз спрашивал, если такая аппаратная функция в ARM. Обязательно добавлю. Дело в том, что SWI всем хороша кроме одного - она исполняется независимо от того - разрешены прерывания или нет. Когда переключение вызывается из потока проблем нет, а вот когда из прерывания возникают сложности - обработчик прерывания уже наложил в стек своей информации. Идеология scmRTOS предполагает, что при возникновении необходимости переключения контекста внутри обработчика прерывания взводится запрос на переключение а собственно прерывание переключателя вызывается в момент выхода из обработчика, когда разрешаются глобальные прерывания и стек содержит только данные текущего потока. Я подумывал о использовании SWI при вызове из потока и "честного" прерывания при переключении в обработчике прерывания, но это потребовало бы изменения "непортируемой" части ОС, хотя и ускорило бы переключение. В общем я пока в раздумье. Есть идеи? Спасибо, не знал (только начинаю ARM осваивать). Изучу и учту. Собственно ради таких замечаний и открыл это обсуждение.

Это особенность всех ЖКИ 16*1. Дело в том, что логически это ЖКИ 2*8 у которого две строки склеены. Инициализировать его надо как двухстрочный а информацию во вторые 8 знакомест выводить начиная с адреса 0x20

Ну а быстренько и Вашими руками, то можно быстренько вместо ОТСУТСТВУЕЩЕГО во FreeRTOS семафора сваять аналогичную моргалку на банальном флаге Или что-то недопонял или в FreeRTOS флагов тоже не нашел. Можно хотябы в общих словах пример кода, я его погоняю.

самый эффективный способ: main.c #include <stdint.h> uint8_t const __flash Array[8] = {1,2,3,4,5,6,7,8}; extern void AsmFunc(void); void main (void) { AsmFunc(); } Asm_fish.c: #include <stdint.h> extern uint8_t const __flash Array[8]; uint8_t Tmp; void AsmFunc(void) { uint8_t i; for(i = 0; i < 3; i++) { Tmp = Array[i*2]; } } Ставишь галочку "генерить ассемблерный файл" в опцияк компилятора на вкладке листинг, компилишь, внимательно изучаешь полученную "рыбу". Или пишешь нужную функцию полностью на С, компилишь, получаешь ассемблерный исходник и его оптимизируешь. Только не забудь прочитать в документации какие регистры функция может портить, а какие должна сохранять.

Угу. Что называется "между глаз лежало". И ведь не раз и не два перечитывал и с языком проблем нет. Снимаю возражения полностью. Если есть желание можем сравнивать. Жду предложений. Выкладываю тут последнюю на данный момент версию, если не будет особых нареканий будем ее же и на офф. сайт выкладывать. Вроде даже в симуляторе работает, хотя не совсем вовремя прерывание вызывается. scmRTOS_ARM.zip

Сразу как-то прощляпил "не компилится" :-( Причем поминанием документации. Посмотрел - никаких препятствий, работает, только один битик, естественно,в SPSR подправить надо: Ну что сказать? Полез я снова читать доку и вынужден признать что Вы правы: мне в голову запала фраза из доки: It should be noted that some of the macros defined in portmacro.h can only be called from ARM mode code, and use from THUMB code will result in a compile time error. В принципе я где-то прав. Согласно этой фразе собрать весь проект в чистом ARM не получится. Решил я посмотреть что за ошибки. Скомпилилось без ошибок, ничего криминального в тех макросах не нашел. Да, portINITIAL_SPSR пришлось дописать руками. Но в целом свою фразу насчет "не компилится" беру взад, однако Вы сами признали, что без "доработки напильником" и не работает. Заодно каюсь - вчера измерял вариант Flash Debug, т.е. без оптимизации. Сегодня подправил переключение контекста в своем порте (теперь и симулятор и железо живут одинаково, да и скорость поднял) и попробовал разные варианты оптимизации, результат такой: ОС светодиод горит светодиод не горит FreeRTOS THUMB (Size, max) 67 мкс 33 мкс FreeRTOS ARM (Size, max) 62 мкс 35 мкс scmRTOS THUMB (Size, max) 6.3 мкс 6.3 мкс scmRTOS ARM (Size, max) 4.6 мкс 4.6 мкс FreeRTOS THUMB (Speed, max) 65 мкс 33 мкс FreeRTOS ARM (Speed, max) 58 мкс 35 мкс scmRTOS THUMB (Speed, max) 6.3 мкс 6.3 мкс scmRTOS ARM (Speed, max) 4.6 мкс 4.6 мкс

Греем одну площадку. Прислоняем олово. растеклось. Кладем олово. Берем освободившейся рукой пинцет. кладем деталь на залуженную площадку. Греем. Один вывод припаян. Кладем пинцет, берем в освободившуюся руку олово, припаиваем оставшуюся площадку. Зубы чистые :-)

Ось не моя, а порт будет выложен на scmRTOS.narod.ru

Ваше неравнодушие к семафорам я уже заметил :-) Хорошо, очередь требует 8 байтов накладных расходов :-)

Нет, не изучал. Я в свое время портировал ОС CREx от компилятора Introl с мотороллера HC12 на MSP430. Тоже вся на асме была. функциональность примерно как у FreeRTOS - т.е. динамическое создание/удаление процессов, семафоров и прочего. Ошибки вылавливал долго. Потом с Гарри сравнили время переключения контекста с scmRTOS и я забросил CREx в архив :-) И вообще стараюсь с асмом поменьше связываться. Перефразируя принцип IBM "Компилятор должен работать, а я - думать". Первый проект на ARMe сделал на чистом С и про ядро начал читать и асм изучать только сейчас когда переключатель задач писал.

Сравнил по скорости с FreeRTOS. Тест простой: низкоприоритетный процесс сигналит семафор, более высокоприоритетный его ждет. Код: /****** FreeRTOS **********/ static void Task1( void * pvParameters ) { for(;;) { xSemaphoreTake( xSemaphore, ( portTickType )-1 ); off(LED0); } } static void Task2( void * pvParameters ) { for(;;) { on(LED0); xSemaphoreGive( xSemaphore ); } } void main( void ) { prvSetupHardware(); vSemaphoreCreateBinary( xSemaphore ); xTaskCreate( Task1, "Task1", 300, 0, tskIDLE_PRIORITY + 2, ( xTaskHandle * ) NULL ); xTaskCreate( Task2, "Task2", 300, 0, tskIDLE_PRIORITY + 1, ( xTaskHandle * ) NULL ); vTaskStartScheduler(); } /******** scmRTOS ***********/ OS_PROCESS void TProc1::Exec() { for(;;) { ef.Wait(); off(LED0); } } OS_PROCESS void TProc2::Exec() { for(;;) { on(LED0); ef.Signal(); } } Результат (частота 49,152МГц): ОС светодиод горит светодиод не горит FreeRTOS THUMB 59 мкс 35 мкс FreeRTOS ARM не компилится согласно документации scmRTOS THUMB 7.5 мкс 7.5 мкс scmRTOS ARM 5 мкс 5 мкс При этом семафор в scmRTOS занимает 4 байта в FreeRTOS - 76, процесс занимает 4 байта + стек, в FreeRTOS - 76 + стек. Сколько ОЗУ требует ядро FreeRTOS я не искал. Ну начинаем выкручиваться: 1. Амперсандик добавили, спасибо, что не (xQueueHandle) :-) результат &x где x-int имеет тип *int, так что не принимается. Вот тут да. Согласно рекомендациям в поле suppress those warnings стоит pe815, pe191, pa082, pe167. Заметьте, не я их туда поставил а авторы FreeRTOS. Тоже из MAP. MAP в тестовом виде прилагается, кстати, был в свое время обрадован IARовским HTML мапом. Смотрите в приложении: Понял, спасибо. Буду посмотреть. Если мне не изменяет память, то я получил на уровне 7us. Но это при ЧЕСТНОМ измерении, от момента ВНЕШНЕГО а не таймерного прерывания и до проднятия задачи дергающей PIN. Время это время для FreeRTOS, естественно, не фиксированное. Задач было около 6. Можно повторить под протокол, но через недельку - болею сейчас. нда, такой эксперимент я не проводил, может завтра рискну. О своих результатах написал чуть выше. P.S. к семинару Тексаса выздоровишь (24-го)?

А здесь-то криминал-то в чем? Совершенно разные типы. Я 'дико извиняюсь', но это typedef а не define - любой компилятор находясь в твердом уме и здравой памяти обломает подмену безвариантно. Совсем не уверен. Во всяком случае int x,y; xQueueReceive(&x, &y, 0); IAR съел молча, хотя int* это совсем не xQueueHandle. И что-то мне казалось что в С это не разные типы а синонимы, это в С++ будут разные типы. По сравнению объемов мне непонятно откуда такие цифры? Чего-то вы напутали. Заглянул в .map, получил там такое: OS::Kernel 0x28 IdleProcess 0x6c Proc1 0x134 ( 8 + 0x12C stack) Proc2 0x134 ( 8 + 0x12C stack) Proc3 0x134 ( 8 + 0x12C stack) Т.е. ядро+Idle занимает 148 байт плюс по 8 байт на каждый процесс. Остальное - стеки прцессов. Счас буду делать аналогичный тест с FreeRTOS, сравню сам. Еще особенность - я не правил .xcl из ИАРовского примера, поэтому возможно погрешность ползет оттуда: в качестве IRQ_STACK в scmRTOS используется CSTACK, да и его размер в .xcl определен как 0x400 что явно замного. Продолжаю эксперименты. Счас попробую замерить время переключения контекстов. Еще один? :-))

Ну такуж и на любой. Семафоры ака очередь это отдельная песня и при необходимости иметь оные несомненно буду встраивать 'семафористые' семафоры :-). typedef void * xQueueHandle; typedef xQueueHandle xSemaphoreHandle; typedef void * xTaskHandle; Собственно других открытых пользователю сервисов там вроде и нет. Нет, особого желания нет. Порядок "платы" ясен и меня совсем не смущают пару сот байт, особенно по отношению к размеру стеков (особенно при отсутствии даже простейших механизмов контроля обьема использования стека присутствующих в FreeRTOS) задач :-(. Надо будет этот вопрос изучить, спасибо за наводку. Нет, я работал с 3.2.2, как проект сдал больше на FreeRTOS.org не заглядывал. Посмотрю обязательно, спасибо.

Основной механизм - вытесняющая многозадачность. Таймер может вызвать переключение если истек тайм-аут какого-либо процесса. Каюсь, здесь я промухал. Посыпаю голову окурками :-) Это долгая история. Сначала увидел такую конструкцию в исходниках линукса и тоже был озадачен. Задал вопрос на сахаре и ReAl мне наглядно объяснил, что поскольку в макрос может быть добавлена еще одна команда то его лучше сразу заключить в {}, но макрос с {} нельзя использовать в лоб в конструкции if(cond) Macro(); else ....; а если добавить do while(0) то смысл не изменится но ограничений уже не будет. Системное время, ОС по нему считает тайм-ауты. Угу, мне об этом говорили. Я, наивный, подумал что в атмеловском SAM7 так же. И тут же получил граблями в лоб - у атмела неиспользуемые биты не реализованы физически, т.е. "атакой, не атакуй...". С тех пор я слегка пуганый, и когда увидел в описании специально заточенный бит подумал "ВОТ!" и глубже решил не копать. Я еще не измерял сколько у меня получилось время переключения - наверное сегодня выделю минутку. Вообще мы с автором scmRTOS обсуждали идею как сильно сократить время запрета прерываний, но пока это на уровне идеи - должно какое-то время повариться в мозгу.

В частности по этой причине не смог пройти спокойно мимо вышеотцитированого :-(. "Кривизну", в виду неопределенности формулировки, оставим в покое (хотя можем и побеседовать - тут есть подходящие ветки ) Объясню очень просто: указатели на любой объект передаются как void* что легко позволяет мне передать вместо указателя на семафор указатель на процесс или очередь. Зачем же в "языке высогага уровня Ц" был придуман контроль типов на этапе компиляции? Далее это же void * передается в другие функции место указателя соответствующего типа, а чтобы компилятор не выдавал предупреждения вместо элементарного создания локальной переменной нужного типа и приведения типа signed portBASE_TYPE xQueueSend( xQueueHandle xQueue, const void *pvItemToQueue, portTickType xTicksToWait ) { xQueuePtr pxQueue = xQueue; в описании предлагается задавить предупреждения этого типа в опциях компилятора. Причем предупреждения возникают при компиляции кода самой ОС. Что же это как не кривизна? 46 байт на битовый семафор мне показалось расточительно. Они его реализуют как очередь из одного элемента нулевого размера. Да и на очередь 46 байт ОЗУ накладных "жаба душит". Я не отрицаю большого потенциала в FreeRTOS. Однако в моем примере из базовой функциональности был только один сервис Sleep(). Оно и понятно - надо было отладить переключатель контекста. Более серьезный пример идет в исходнике scmRTOS с сайта автора. Там есть и семафоры и очереди. Если есть желание - можем сравнить. Еще раз - я не хоче наступить на горло FreeRTOS, просто мне она субъективно не понравилась.

Я пользуюсь оригинальной англоязычной документацией, но в данном случае в ней написано то же самое. В данном контексте (R15 нет) ^ означает доступ к user-банку. Но поскольку R0 небанкируемый, то в этом конкретном варианте наличие ^ не играет роли. Вот тут появляется тонкость, которая не позволила мне восстановить весь контекст одной командой: если в списке есть R15, то ^ означает копирование SPSR в CPSR а не восстановление user-банка. Т.е. значения со стека попадут вместо необходимого мне SP_user, LR_user в SP_irq, LR_irq. Это ответ на Влияет. В STM если есть галочка будут сохранены регистры user mode.

Ну вот хоть какая-то польза :-) Нет, нельзя. Если идет ^ и в качестве опроного используется банкируемый регистр то нельзя писать в него обратно и в следующем такте обращаться к нему тоже нельзя. Вот цитата из того же ARM DDI 0029E: Да, вот из старого сообщения: На самом деле это одни и те же команды, разработчики зачем-то дали этим командам по два имени " to support stacks or for other purposes." Так что STMDB == STMFD, LDMIA == LDMFD