Сергей Борщ

#include <stdint.h> #include <ioAT91SAM7S64.h> void main() { AT91C_BASE_PIOA->PIO_PER = (uint32_t)-1; // all outputs are IO AT91C_BASE_PIOA->PIO_OWER = (uint32_t)-1; // direct write to all pins allowed for(;;) { AT91C_BASE_PIOA->PIO_ODSR = 0; // all outputs = 0 AT91C_BASE_PIOA->PIO_ODSR = (uint32_t)-1; // all outputs = 1 AT91C_BASE_PIOA->PIO_SODR = (1<<0); // PIOA.0 = 1 AT91C_BASE_PIOA->PIO_CODR = (1<<0); // PIOA.0 = 0 } } примерно так...

У меня как правило работает часть прерываний. Можно, конечно попробовать и сбросы всего, что попало в скрипт инициализации добавить. Попробую на досуге. Может не совсем правильно выразился, вот sgrig понял. Под сбросом я понимал вот что: Почему-то мне запомнилась фраза "This will reset VIC logic", хотя сейчас в мануале ее не нашел, видимо сам ассоциативно выдумал ;-). Для AT91 аналогичное происходит при записи в EOICR.

PORT = (PORT >> 1) | (PORT << 7); Вроде так? Нет, или так: PORT = PORT ? PORT >> 1 : (1<<7); или так: PORT = (PORT >> 1) | ( (PORT == 0) <<7);

Было подобное. То генрятся то нет. Соображения такие: при сбросе отладчиком происходит только сброс ядра, но не контроллера прерываний. Если перед этим обрабатывалось какое-то прерывание и логика контроллера не была сброшена (VICVecAddr = 0 или AIC_EOICR = 0) то следующее прерывание не генерится. Поборол принудительным сбросом контроллера прерываний в процедуре инициализации.

1) использовать const __flash 2) обратить внимание на описание параметров функций, которым эти константы передаются (тоже должны быть описаны как const __flash)

Ага, посмотрел проект - файл .xcl по умолчанию линкует для неизвестного процессора в результате ОЗУ попадает на адреса 0x10000. Отсюда все грабли.

Что это? В 2000г Аскольд Волков посылал в конференцию ru.embedded свои макросы работы с портами для AVR. А это творческая переработка: #ifndef ASCOLD_SAM7_H__ #define ASCOLD_SAM7_H__ #ifdef __IAR_SYSTEMS_ICC__ #define _setL(port,bit) do { AT91C_BASE_PIO##port##->PIO_CODR = (1 << bit); } while(0) #define _setH(port,bit) do { AT91C_BASE_PIO##port##->PIO_SODR = (1 << bit); } while(0) #define _clrL(port,bit) do { AT91C_BASE_PIO##port##->PIO_SODR = (1 << bit); } while(0) #define _clrH(port,bit) do { AT91C_BASE_PIO##port##->PIO_CODR = (1 << bit); } while(0) #define _bitL(port,bit) (!(AT91C_BASE_PIO##port##->PIO_ODSR & (1 << bit))) #define _bitH(port,bit) ( AT91C_BASE_PIO##port##->PIO_ODSR & (1 << bit)) #define _cpl(port,bit,val) do { AT91C_BASE_PIO##port##->PIO_ODSR ^= (1<<bit); } while(0) #define _dir_out(port,bit,val) do { AT91C_BASE_PIO##port##->PIO_OER = (1<<bit); } while(0) #define _dir_in(port,bit,val) do { AT91C_BASE_PIO##port##->PIO_ODR = (1<<bit); } while(0) #define dir_out(x) _dir_out (x) #define dir_in(x) _dir_in (x) #define _set(port,bit,val) _set##val(port,bit) #define on(x) _set (x) #define SET _setH #define _clr(port,bit,val) _clr##val(port,bit) #define off(x) _clr (x) #define CLR _clrH #define _bit(port,bit,val) _bit##val(port,bit) #define signal(x) _bit (x) #define BIT _bitH #define cpl(x) _cpl (x) #endif // __IAR_SYSTEMS_ICC__ #endif //ASCOLD_SAM7_H__ Вот его комментарий по использованию: Ну а для AT91 это будет выглядеть так: #define LED A,0,H // PIOA, bit 0, active high #define KEY A,20,L // PIOA, bit 20, active low if(signal(KEY)) on(LED); else off(LED); Из IAR C-SPY через JTAG.

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 бит. Кто-нибудь такое делал?

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