gladov

Ни чего я не порчу, я поднял вопрос, который был решён. И если не поднял бы, то кто этих нюансов не знал, просто так не проскочили. Когда в начале топика задавались вопросы типа как с UART работать, все молчали. :( Были лишь изредкие фразы типа “вы отлично варитесь в собственном саку, ну и варитесь там!”. Чтож… Я не спорю, даже скажу согласен с этим. Но когда “поварившись” результатом чего явился РАБОТОСПОСОБНЫЙ проект и был выложен, что бы им пользовались такие как, я был неделю назад (если мне дали тогда этот проект, то я бы поблагодарил). Целью проекта было постепенное наращивание, освоение новой периферии (выкладывание промежуточных результатов) и КОНСТРУКТИВНОЕ обсуждение отдельных алгоритмов, не поливая помоями чужие варианты! Если бы кто, например, сказал, вот тут (x=1; x<100;x++) пауза будет не точной, потому что используется такая инструкция проца (которая в режиме таком то выполняется за два такта), другой бы сказал что он применил другую конструкция, которая меньше места занимает, а третий бы предложил более большую конструкцию, но с более богатыми возможностями. Но нет!!! Как этот “презренный” посмел обратиться к нам, небожителям! И надругаться над нашими священными постулатами. Он даже ПОСМЕЛ! :angry2: , стыдно сказать, bin использовать! Так умри же за это! :maniac: Когда надо было, так нет никого, а сейчас налетели как коршуны, и каждый пытается клюнуть побольнее. :twak: При чём вместо самообучение, я получил публичную порку, и вместо предложений и обсуждений по коду я должен оправдываться за каждое сказанное слово. Оправдаться то я могу, но надоело уже :( . Может быть местные гуру иногда и бывают резки, но в общем и целом они правы. Нельзя "научить" человека программировать. Можно только помочь ему научиться, причем, чем меньше отвечают вам на ваши вопросы, тем (иногда) лучше - знание, приобретенное собственными потугами не забыватеся, в отличие от регулярных подсказок. Обратите внимание: на конструктивные вопросы (читай не совсем "детские") были даны ответы. А разжевывать все "от" и "до" НИКТО не будет. Конференция нужна для того, чтобы вас поправили в некоторых местах, а не сделали все за вас. Именно поэтому никто на попытался ответить на вопрос "как работать с УАРТ" (этот вопрос мне напоминает вопрос секретарши по телефону: "у меня винда не работает! Что делать???"). Зато когда вами был предложен вариант решения, опытные люди показали на ошибки и/или пожелания к культуре программирования. Повторюсь: это единственно правильный вариант общения в конференции. А готовых приверов полно компиляторах. Отдельный :a14: sonycman'у за проявленное терпение и понимание. PS: прошу не обвинять меня в неграмотности: "вам" намеренно писал с маленькой буквы, т.к. обращался ко всем новичкам, общающимся в этой ветке форума.

Конечно, т.к. на то оно и "прерывание", что прерывает основную работу, и его, по идее, имеет право приостановить лишь более высокоприоритетное прерывание, но никак не другая задача ОС. В любом случае, нужно взводить флажок о том, что требуется перепланирование, но оно должно происходить после обработки всех ожидающих прерываний. А вообще, см. совет Andy Mozzhevilov - книга действительно стоящая!

Спасибо. Так, конечно, правильнее.

Тема закрыта. Для тех, кому интересно, вот причины такого странного поведения: 1) При работе из ОЗУ отладчик выполняет макросы: - execUserPreload() перед загрузкой кода в ОЗУ - execUserReset() после загрузки перед стартом - execUserSetup сразу после execUserReset() 2) Смотрим на код макро-файла sam7_ram.mac, который я взял из какого-то примера для моего кита: /********************************************************************* * * _MapRAMAt0() * * Function description * Maps RAM at 0. */ _MapRAMAt0(){ __message "Changing mapping: RAM mapped to 0"; __writeMemory32(0x00000001,0xFFFFFF00,"Memory"); } /********************************************************************* * * _InitRSTC() * * Function description * Initializes the RSTC (Reset controller). * This makes sense since the default is to not allow user resets, which makes it impossible to * apply a second RESET via J-Link */ _InitRSTC() { __writeMemory32(0xA5000001, 0xFFFFFD08,"Memory"); // Allow user reset } /********************************************************************* * * _InitPLL() * Function description * Initializes the PMC. * 1. Enable the Main Oscillator * 2. Configure PLL to 96MHz * 3. Switch Master Clock (MCK) on PLL/2 = 48MHz */ _InitPLL() { __message "Set Main Oscillator"; __writeMemory32(0x00004001,0xFFFFFc20,"Memory"); // MOSC while( !(__readMemory32(0xFFFFFc68,"Memory") & 0x1) ); __message "Set PLL to 96MHz"; __writeMemory32(0x10483f0e,0xFFFFFc2c,"Memory"); // LOCK while( !(__readMemory32(0xFFFFFc68,"Memory") & 0x4) ); __message "Set Master Clock to 48MHz"; __writeMemory32(0x00000004,0xFFFFFc30,"Memory"); // MCKRDY while( !(__readMemory32(0xFFFFFc68,"Memory") & 0x8) ); __writeMemory32(0x00000007,0xFFFFFc30,"Memory"); // MCKRDY while( !(__readMemory32(0xFFFFFc68,"Memory") & 0x8) ); } /********************************************************************* * * execUserReset() : JTAG set initially to Full Speed */ execUserReset() { __message "execUserReset()"; __emulatorSpeed(30000); // Set JTAG speed to 30kHz to make a hardware reset __hwReset(0); // Hardware Reset: CPU is automatically halted after the reset _InitPLL(); // Allow to debug at JTAG Full Speed _MapRAMAt0(); // Remap RAM to address 0 __emulatorSpeed(0); // Set JTAG speed to full speed } /********************************************************************* * * execUserPreload() : JTAG set initially to 32kHz */ execUserPreload() { __message "execUserPreload()"; __hwReset(0); // Hardware Reset: CPU is automatically halted after the reset (JTAG is already configured to 32kHz) _InitPLL(); // Allow to load Code at JTAG Full Speed _MapRAMAt0(); // Remap RAM to address 0 _InitRSTC(); // Enable User Reset to allow execUserReset() execution } 3) Видим, что перед загрузкой в макросе execUserPreload() делается ремап, т.е. ОЗУ проецируется на адреса 0000-FFFF. После загрузки, перед стартом в execUserReset() делается опять ремап! Хоть он делается и после __hwReset(0), но он отменяет действие предыдущего, и ОЗУ уже не отображается в начало памяти. Отсюда и проблемы с отладкой. Интересно, а __hwReset(0) должен сбрасывать ремап или нет?

Действительно, если задать области RAM и ROM в диапазон ОЗУ (0х200000 - 0х20FFFF) и в макросе выставить PC=0х200000, то отладка работает не зависимо от того, сделан ли ремап. Соответственно, можно только задать правильно области и сделать ремап, а РС не трогать. Спасибо за ценный совет. Дальше попробую сам докопаться до причин такого поведения...

Доброго времени суток! Весь день пытался освоить отладку софта в IAR. Имеем Wiggler + H-JTAG. В IAR работаю через RDI.При отладке из флеша все как положено - не более 2 бряков. Но ведь при работе в ОЗУ их должно быть сколько угодно? ИАР так не думает :( 1) Создаем в IAR новый пустой проект: int main() { return 0;}. Для линкера берем файл из примеров at91SAM7X256_ram.xcl, предварительно осознав что там написано и не выявив никакого криминала. Для отладчика берем макро (тоже из примеров) sam7_ram.mac. На вкладке Download никаких галок не стоит. Галка run to main снята. Отладчик запускается, рисует стрелку на 0 адресе. При любой попытке трассировки в окошке debug log RDI ругается, что все бряки уже использованы и еще одну добавить низя! Смотрим Breakpoint Usage и точно - стоят 2 служебных точки самой среды: C-SPY Terminal I/O и что-то про стек (сейчас точно их названия воспроизвести не могу - под рукой нет проекта). Странно, но я думал, что при отладке из ОЗУ я не ограничен двумя бряками :blink: 2) Файлы xcl и mac не меняем, но поставим галки на вкладке Debug/Download "Verify download" и "Use flash loader". Тогда, если я правильно понимаю, среда зашьет бинарник во флеш, но при этом опять будет выполнять софт из ОЗУ. О, чудо!!! Отладка работает. Нет ограничений на количество БП. Готов застрелиться.... :smile3046: Я, конечно, могу оставить все как есть, т.е. при каждом сеансе отладки перешивать еще из флэшку, но это как-то, мягко говоря, неправильно. Подскажите, в чем может быть засада?

А зачем printf? Можно ведь, например, настроить DBGU (или УАРТ) с PDC, и в прерывании УСБ только скопировать куда-нть i и пнуть PDC. По времени совсем некритично, зато легко можно узнать любые интересующие значения любых переменных.

Может быть и я некорректно выразился про разную природу, но если ядро работает от MAINCLK, то клоки для USB, пройдя через PLL, могут получить некий фазовый сдвиг (кто его знает как там ПЛЛ устроен?) и изменят частоту, а это уже совсем другой клок получится. А вот с максимальным временем синхронизации я согласен. Оно обязательно должно быть. И писать вечный цикл на ожидание выставления битика мне тоже очень не нравится.

Думаю, что NOP'а может быть недостаточно. Частоты MCK и UDPCK, теоритически, могут быть разной природы, следовательно, в модуле USB появляется механизм синхронизации, который, как правило, представляет собой цепочку триггеров, что вносит дополнительную задержку в пару клоков.

Просмотрел я даташит ещё раз - похоже я таки не прав. Максимальная частота 55 МГц, но тогда вопрос - зачем нужна возможность гнать PLL аж до 200 МГц? И второй вопрос почему же, всё таки процесор работал, когда я ставил PLL 192, а прескалер в 1? Смотря что значит "работал". Ведь любой производитель, анонсируя максимальную частоту, дает ее для худшего случая допустимых условий эксплуатации. Кроме того, для различной периферии допустима различная максимальная частота. Поэтому в большинстве случаев возможен некий оверклокинг, только к чему это может привести? Можно огрести очень редкие, практически недиагностируемые, но очень большие проблемы. Вполне возможно, что в проце стоит быстрое ядро, а максимальную тактовую занизили для периферии, вот он и задышал у Вас на столе при идеальных для него условиях

Итак, подводим итоги. Может быть кому-нибудь пригодится. Вообще-то я пришел к выводу, что RTT в sam'ах кривоват. И кривой он из-за своей природы, т.к. тактируется от RC-цепочки, котороая по-определению нестабильна в той или иной степени. Поэтому использовать его как средство для отсчета равных точных промежутков времени (как обычно используют таймеры) не получается. А раз так, то и прерывания от него особо не нужны... Но мне все-таки было интересно из принципа доковырять этот девайс до максимальной ясности. При использовании прерываний по уровню все работает (см. посты от aaarrr). С прерываниями по фронту есть проблема, но ее решать смысла нет, т.к. (опять же см. aaarrr) системные прерывания по фронту включать крайне нежелательно. А проблема в том, что сброс RTT, а именно бит RTTRST, не сбрасывает бит RTTINC в регистре RTSR. Поэтому после сброса ядра процессора бит RTTINC может оказаться в активном состоянии, следовательно, фронта никогда не произойдет, поэтому и прерывание не стработает, а тогда не будет чтения из регистра RTSR и бит RTTINC не сбросится. Выход - после сброса RTT читать RTSR один раз чтобы принудительно сбросить флаг инкремента. Спасибо всем за помощь в изучении проблемы :cheers:

Отлаживаете через JTAG? Учитываете, что кнопка "сброс" в оболочке сбрасывает только ядро, но не периферию, т.е. если перед нажатием кнопки "сброс" таймер был включен, то он продолжает тикать? Учитываете, что если открыто окно с регистрами периферии, это вызывает их чтение и сброс некоторых флагов (и другие действия по чтению некоторых регистров)? Нет, JTAG'а нет вообще. А сброс непричем, т.к. я же в начале программы даю резет для RTT.

errat'у свежую смотрел, но там написано только что SR нельзя часто опрашивать, иначе он теряет события. На этот глюк я тоже нарывался :) Инициализация одной строкой тоже не помогла - не сбрасывается он корректно! Ну и черт с ним. Проехали и забыли. Будем считать это багом, хотя я ни разу еще в железках не нарывался на недокументированные ошибки...

Согласен полностью Почему системное прерывание не желательно использовать по фронту понятно, но я больше никакие системные прерывания кроме RTT не разрешаю. Конечно они могут быть у какой-либо периферии разрешены после старта (я конечно весь DS пока не прочитал), но здравый смысл подсказывает, что после старта вся периферия должна быть выключена. Выяснились новые подробности. Если перед основным циклом прочесть RTTC_RTSR то все работает как часы, из чего я делаю вывод, что иногда при старте прерывание от RTT уже активно! Сбросить его некому, т.к. у меня чтение его производится только из прерывания. Отсюда вопрос: а почему оно может быть активно после старта? Я же делаю ему (RTT) резет! Может я что-то не так инициализирую? В принципе, глюк ясен и понятен. Как бороться тоже ясно и вопрос почти снят, но хочется узнать где же были грабли....

А поясните, пожалуйста, почему этот таймер не так прост и не рекомендуется использовать прерывания? Тоже только недано начал ковырять АРМ на AT91SAMx256 борде. И тоже попробовал поднять RTT. Поллинг работает, а прерывание стартует только в режиме LEVEL, но почему-то рабоает нормально без запрета прерывания в прерывании и последующем его разрешении в основном цикле. Если меняю режим на EDGE то прерывание просто не запускается. Вообще. Если кому не напряжно глянуть в мои каракули, может подскажете где грабли? // Initialize the timer AT91F_RTTC_CfgPMC(); //Enable a clock source AT91F_RTTClearAlarmINT(AT91C_BASE_RTTC); AT91F_RTTSetPrescaler(AT91C_BASE_RTTC, 0x4000); AT91F_RTTRestart(AT91C_BASE_RTTC); AT91F_RTTSetRttIncINT(AT91C_BASE_RTTC); // AIC initialization AT91F_AIC_CfgPMC(); AT91F_AIC_ConfigureIt(AT91C_BASE_AIC, AT91C_ID_SYS, AT91C_AIC_PRIOR_LOWEST, // AT91C_AIC_SRCTYPE_HIGH_LEVEL, AT91C_AIC_SRCTYPE_POSITIVE_EDGE, (void (*)())isr_system); AT91F_AIC_EnableIt(AT91C_BASE_AIC, AT91C_ID_SYS); // Loop forever while (1) { int c; c = AT91F_RTTReadValue(AT91C_BASE_RTTC); if (c != cval) { cval = c; if (AT91F_PIO_IsOutputDataStatusSet(AT91C_BASE_PIOB, led_mask[1])) AT91F_PIO_ClearOutput(AT91C_BASE_PIOB, led_mask[1]); else AT91F_PIO_SetOutput(AT91C_BASE_PIOB, led_mask[1]); } } __irq void isr_system() { if (AT91F_PIO_IsOutputDataStatusSet(AT91C_BASE_PIOB, led_mask[3])) AT91F_PIO_ClearOutput(AT91C_BASE_PIOB, led_mask[3]); else AT91F_PIO_SetOutput(AT91C_BASE_PIOB, led_mask[3]); //If this is RTT interrupt if (AT91F_RTTGetStatus(AT91C_BASE_RTTC) != 0) { if (AT91F_PIO_IsOutputDataStatusSet(AT91C_BASE_PIOB, led_mask[0])) AT91F_PIO_ClearOutput(AT91C_BASE_PIOB, led_mask[0]); else AT91F_PIO_SetOutput(AT91C_BASE_PIOB, led_mask[0]); } AT91C_BASE_AIC->AIC_EOICR = 0; }

Спасибо большое :cheers:

А, если не секрет, каков порядок цен на чтение МК с битом защиты?

Доброе время суток всем. Решил попробовать IAR для меги и возник вопрос: для чего компилятор заводит второй стек (CSTACK) для хранения данных? Чем ему аппаратный не нравится? Имхо такой подход менее прозрачный, а значит, более подвержен ошибкам как со стороны разработчиков самого компилятора, так и со стороны пользователей оного при написании асмовых вставок. Кроме того, постоянно занята регистровая пара Y, в скорости работы приварка нет, да и 2 раздельных области памяти всегда больше скушают, чем одна общая. Я конечно понимаю, что разработчики компилятора совсем не дураки и сделано это с определенной целью, но с какой??? :blink:

Есть еще такой FUSE: CLKDIV8. Если он включен, то частота делится на 8. По дефолту он в меге выставлен - его снимать надо. Но дело имхо не в нем, т.к. такого падения частоты, конечно, не было бы. Если проблема в питании, то можно попробовать переключить фьюз, который отвечает за старт МК (время ожидания стабилизации кварца после ресета). Если он ресетится по питанию, то переключив время можно заметить изменение частоты "моргания" пина

У меня PORT95NT решил проблему. WinXP CE SP2

Спасибо! :cheers:

Ну в общем, да. :) Если под наше изделие обязательно должны быть пластмассовые "нестандартные" корпуса, есть ли какая-любо альтернатива изготовлению пресс-формы и отливке собственных корпусов? Имхо нет... А раз так, вся "экономика" сводится к вопросу "Влезать ли мне в проект вообще?" а не к воросу "делать ли мне пресс-форму под этот проект или и так сойдет?". Тут как раз и получается что есть форму сделать за 10-30 K$ то все гуд, а если около 100 то нафиг такой проект никому не нужен. :unsure: Спасибо за наводку. Обязательно позвоню узнаю условия...

И еще одна просьба о помощи! Я тоже новичок в ПЛИС и тоже хочу литературу. Уже 2 книги прочитал: Полякова и Суворову. И тут я понял что не то читаю! Раньше занимался программированием МК. Стало интересно изучить ПЛИС. А оказывается для такого перехода нужно менять идеологию в голове. Подход принципиально другой должен быть, а голова по-старому работает. Кто-нибудь может подсказать книгу, наиболее хорошо раскрывающую не языки программирования а именно концепции и подходы в решении задач на ПЛИС?

Серия планируется, но порядка 20000 корпусов в год. Для пресс-формы это не нагрузка вообще, поэтому я и сказал, что "объемы небольшие". Тут и холодное литье подойдет. Насколько я знаю под холодное формы дешевле т.к. техпроцесс проще. "За дешево" я и не надеюсь. Халявы тут не бывает. Но имхо тысяч за 10-20 (за одну форму) где-то найти можно. Вопрос лишь где? Подошел бы и китай и тайвань и любые другие дружественные страны :)

CASCADE - это дополнительная связь между соседними ячейками в некоторых (ACEX- точно, вроде бы во FLEX еще есть) семействах. В более поздних (Cyclone) ее кажется нету. Использовать можно для, скажем, объединения по И двух соседних ячеек. Нужно это для того, чтобы уменьшить задержку распространения сигнала. Большое спасибо! :cheers: