Сергей Борщ

1. Неизвестно. Возможно стартап слинкован из двух кусков который писали разные люди. Всегда делаю один раз. Этак можно в любой регистр по нескольку раз записывать. 2. Разработчики компилятора не имели возможности знать какой именно таймер свободен в вашем проекте, как он настроен или может он и занят но свободно одно из его прерываний. Написать универсальный код для этого невозможно. А через циклы - оно дает гарантированную задержку "не менее чем" и должно использоваться там где ошибка в задержке "плюс лапоть" некритична. Например при выводе на индикатор.

Киньте мне проект на serzh(ухо)rrt.lv. Погоняю через JTAG, посмотрю куда падает. Правда у меня только SAM7S64, но думаю это непринципиально. Я не пользовался библиотеками с at91.com, прописывал все необходимые регистры вручную по даташиту. И ногами дергал через макросы on() off() имени Аскольда Волкова. С самбой пока не работал.

Там есть одна засада: в стандартных .xcl почему-то считается, что сегмент NEAR_N лежит во внешней памяти. Например у меги-8 он вообще в .xcl не описан. X_EXT_NV_BASE и X_EXT_NV_SIZE - это переменные через которые оболочка передает содержимое полей Project->General Options->System->External memory configuration для столбца Non-Volatile. Если внешней памяти у вас в проекте нет, то можно просто переписать .xcl добавив сегмент NEAR_N в ту же строчку что и NEAR_Z. Если же внешняя память есть, а данные с __no_init хочется держать во внутренней - то надо объявить свой сегмент и вместе с __no_init использовать размещение данных в указанный сегмент: __no_init int Abc @ "new_segment";

Я думаю ошибка в строке int time; Должно быть volatile int time; Компилятор считает что раз в цикле ничего не происходит этот цикл просто не нужен и спокойно его выкидывает. Т.е. нога скорее всего дергается, но очень быстро.

Тексты семинара есть, а планируемые ветки ? Не понял вопроса. На семинаре раздавали диски по AVRам, про ARM только то, что в памяти отложилось.

Вывод? Не поддерживает. Да и ног адреса/данных не видно. На семинаре показывали таблицы планируемого развития семейства. Были там несколько веток и с внешней шиной. Если склероз не изменяет - обещали массовый выпуск в конце этого года.

Финик сказал. И даже показал. Вот в этом сообщении я описывал: http://electronix.ru/forum/index.php?s=&sh...ndpost&p=117135

Как победить эти warnings не знаю, они рождаются линкером при использовании прилагающихся к пакету заголовочных файлов ioxxx.h. А что касается обработчика прерывания - его можно сделать статическим членом класса.

Когда-то я тоже хотел так сделать. Начал разбираться: 1) PCI шина это 32 двунаправленных сигнала +еще примерно 10 входов + около 10 выходов. Так что ног у твоего ПИКа может сильно не хватить. 2) Твоя программа должна уметь общаться с конкретным контроллером на сетевухе. Разные контроллеры между собой совсем не похожи. В виндовсе/линуксе это делает драйвер сетевухи, идущий с ней в комплекте на диске. Есть большая вероятность что когда ты закончишь разработку тебе придется писать программу заново - нужную сетевуху сняли с производства. И так до бесконечности :-) Если тебя все это не останавливает - начинай с чтения стандарта на PCI-шину. Если не найдешь - могу выслать. ISA сетевуха могла работать в 8-битном режиме и это сильно упрощало ее подключение.

Может надо не открывать, а сделать Project->Add existing project. И путь совсем не обязательно тот же самый делать. Постоянно таскаю проекты между компами и на компе между папками, все нормально.

В Риге был вчера. Даже на презентацию не тянул. Первые 15 минут поляк рассказывал откуда есть пошел тексас и сколько они выпускают по сравнению с конкурентами. Оставшееся время (2.5 часа с двумя перерывами) сонный финн быстро прокрутил слайды читая по одной строчки с каждого, Потом спросил есть ли интерес к чипкону, пролистал слайды чипкона со словами "ну здесь ничего интересного нет", останавливался на двух-трех секунд на 10. Несколько раз повторял "вижу что вы сооные, я сам тоже спать хочу". Показал мигание светодиодом на отладчике (причем не с первой попытки ему удалось), сказал что "IAR" - это самое трудно выговариваемое слово которое он встречал, попинал по этому поводу шведов, но отметил что компилятор - самый лучший, "тексас со своим пытается догнать, но за это время IAR уходит вперед". Потом запустил CodeComposer, сказал "продукт сырой, у меня вот тут хрень какая-то в меню вылазит (и действительно в меню у него были пункты в виде кусков кода)" и закрыл CodeComposer. Приятно, что отладчик раздавали всем, даже опоздавшим. В остальном осталось впечатление самого слабого семинара из всех на которых был до этого.

Ну если вам больше нравятся окна, в 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 мкс