Первое знакомство с микроконтроллерами Atmel, STM и другими.

Первый рассказ
Предэксплуатационный ремонт отладчика Atmel AVR Dragon
Цветное изображение на монохромном LCD
Конвертер растровой графики для монохромного LCD (128х64)
Дизеринг для монохромных LCD и конвертер растровых изображений
ZP-STM32 и беспроводной последовательный порт
Куда уходят миллисекунды? Способ повышения FPS
Open Logic Sniffer в действии
AVR XMEGA – разгон, вольтмод и производительность SDRAM

Fasterpast
Ну - дизайн платы - это дело интимное. У меня тоже на обороте только три десятка пассивных элементов и микрофонный усилитель, куча еще свободного места. А если бы еще примянить 2.54 разъемы для поверхностного монтажа, так вообще пустыня была бы.
А у тебя придраться можно и к разъему в центре платы. И вот чего это у тебя не видно системы крепления платы, это вопрос. Или она приклеивается?


Джиттер встроенного клока несоизмеримо выше кварцевого, с кварцем все тайминги предсказуемы и стабильность должна быть выше (НО: это зависит и от пересчета частот PLL и выбранных делителей, так что может потребоваться тюнинг таймингов). Если это не связано с пересчетом делителя частоты PLL, то что-то у тебя не так, нужно смотреть сигнал клока от кварца и от встроенного, либо настраивать тайминги EBI. Питание через фильтр тут ни при чем (если оно само по себе в норме, ессно), тем более, судя по всему, у тебя и SDRAM низкоскоростная (70нс?).

Кстати, экземпляр XMega128A1 на моей платке устойчиво работает на 52МГц, 104МГц EBI. 10нс асинхронная память 512КБ CY1049 работает отлично на этих частотах, синхронная 2МБ CY62167 после 64МГц EBI начинает чуток подглючивать, не хватает ей длительности импульсов nWR, хотя и так при 64МГц EBI она двойной рубеж по ТТХ взяла, гораздо лучше чем AS6C4008.

Да, тут нет предела совершенству, сам не люблю всё делать в спешке, но пришлось...
Плата крепится в пазы и зажимается там.

Да действительно. Будет время, обязательно попробую "пощупать" что там творится при использовании кварца. Может кварц сам тухлый какой?
Есть у меня еще подозрение, что питание шумноватое получилось, но только проверить нечем и не понятно почему... Питание на LM2596, конденсаторы, дроссель, диод Шоттки - всё как в даташите...

Память - HY57V641620E. Пробовал и по даташиту задержки ставить, и просто самые большие и самые маленькие. От внутреннего источника работает с нулевыми задержками на 64МГц (32 на проце), от кварца либо не запускается, либо запускается, но в процессе передачи данных - куча ошибок.

Это вряд ли, скорее номинал его нагрузочных конденсаторов можно перепутать (был в свое время у меня случай) - вместо, скажем, 22пФ впаять 22нФ.
Если отношение частоты PLL к частоте МК не кратно степени двойки, то длительность тактовых импульсов и с кварцем будет неодинакова.


Тут сильно влияет топология, и правильное расположение блокировочных емкостей.
Но без визуализации, конечно, трудновато все это "на глазок" делать. Я все проверяю осциллографом и сниффером. Вот пример записи в 10нс SRAM с ALE12 на клоке EBI 100МГц, все как в учебнике:

#77
Размер 1200x759, 33КБ, Увеличить

Да вроде 22пФ. Мож какие-то наводки на кварц или место для него выбрано не совсем удачно. Если как-нибудь получится решить, отпишусь обязательно =)
А то, что одно цифровое питание в воздухе висит - не может влиять?
Надо было конечно тест-поинтов понаделать, сейчас там лог.анализатор уже некуда подключать Подпаивать к дорожкам и переходным отверстиям не хочется.
Еще по привычке запаял туда DS1307 в качестве часов и где-то пол часа не мог понять почему он не хочет работать. А он от 3.3В не работает. Самому за такие косяки стыдно... Повезло, что есть полный его аналог на 3.3В.

Не понял, что имеется в виду? Если внешний преобразователь-стабилизатор питания без нагрузки, то не должен.
Если у МК какие-то ножки питания не подсоединены - то еще как может. Все ножки питания МК всегда должны быть подключены и запитаны.

Ножки висят, две штуки... GND и VCC. Ща буду проволочки вешать...

Добавлено спустя 1 час 24 минуты 12 секунд:
Видимо всё дело было в том, что у меня ClkPer4 стоял 128МГц... Сейчас поставил ClkPer4 и 2 по 64Мгц - вроде бы работает стабильно от кварца.
Ножки припаял, но разницы не заметил...

Это стандартная рабочая частота, штатно используется для прецизионных расширений таймеров. Так что мимо. Я вообще подозреваю, что Atmel не изобретала велосипед и PLL у нее стандартные на все семейство AVR и Cortex, которая дает и 480МГц для USB. По крайней мере, на XMega легко и без проблем PLL уходит за 200МГц.

Возможно, влияет именно множитель, если кварц изначально нестабилен, то повышение множителя только усугубляет положение (как мне это видится)... Без нормального осциллографа конечно трудно понять почему такая петрушка, поэтому пока что пусть работает от внутреннего генератора.
С 64МГц от внешнего тоже, кстати ресетнулся он через час работы, с 128 вообще не запускается. А от внутреннего со 128МГц всю ночь пахал без проблем.

если хочеш это то сиди и особо не высовася, тобой объявлена не борьба,
а война с микроконроленами. Желаю удачи.

Подскажите, пожалуйста, DMA вообще умеет напрямую обращаться к >64k внешней памяти или нет?
Ибо вывести какой-то массив в пределах этих 64к у меня получается без проблем, а больше - не могу понять как это сделать.

без проблем.


Так ты, вероятно, используешь драйвер EBI для пионеров из апнота AVR1312. Там регистр старшего байта адреса 23:16 (RAMPZ) не задествован вообще (обнулен), поэтому все по модулю 64К крутится. Надо добавить RAMPZ в ассемблерный макрос.

Для работы с EBI использую вот эти функции:

Уже не помню откуда взял. Силами проца получается с помощью этих функций загнать более 64к данных и прочитать их.
А вот как это связать с DMA?... В регистр srcAddr пишу тот же адрес, что в эту функцию, включаю инкремент, dstAddr - i/o одного из уартов, триггер - софтовый. Как только ставлю бит начала передачи - мк ресетится. Если в srcAddr подсунуть адрес массива в адресуемой из компилятора памяти 64к - всё нормально работает.

Не знаю, где ты такие чудеса берешь. Кстати, у тебя в этой функции прерывания запрещаются и это не восстанавливается при выходе.


Для одиночного байта запись:



Чтение:



Подобные макросы есть и для 16, 32 и блочных операций, если не нужено одиночное чтение-запись, то будет быстрее.

Сам не знаю )) Такой она была в первоисточнике. Для себя "sei" в конце уже добавил.
Спасибо, если не сложно, остальные макросы тоже хотелось бы увидеть.

Добавлено спустя 2 часа 9 минут 9 секунд:
теперь бы понять как это засунуть в компилятор отличный от AVR-GCC...

А кто тебя знает, чем ты пользуешься.
В IAR, к примеру, указатель на 8-битках длинный, там не надо заморачиваться со старшим байтом адреса, а вот на GCC только 16-битный, приходится макросом пользоваться. У кого еще какие дела, не знаю, я на 8-битках только GCC пользую, а на ARM это уже не проблема.
Но в любом случае адрес для EBI (и для встроенной флэшпамяти мк) нужно ставить как RAMPZ:Z, а не RAMPX:X или RAMPY:Y.

Да и вставлять предохранитель в твоей функции mem_read(unsigned long addr) нужно по-другому. Нет никакого смысла в теле функции запрещать прерывания, затем сохранять старший байт адреса, затем восстанавливать его и опять разрешать прерывания, не мудрено, что ты такую низкую пропускную способность памяти получаешь - МК делает кучу бесполезной работы. Гораздо эффективнее - в процедуре прерывания сохранять старший байт адреса, затем сразу обнулить его, а в конце процедуры восстановить старший байт адреса, если вообще это будет нужно.

А ресет у тебя и происходит потому, что RAMPZ обнулен, поэтому указатель(адрес) болтается в пределах первых 64К, а не там, где внешняя память, то есть, легко стереть вектора прерываний, регистры и все что угодно, что и происходит.

Хм, откопал у себя апноут 1312... Так, вроде бы, там приведены те же макросы для чтения и записи?
Видимо придётся самому что-то придумывать.
А эти Сишные функции работают, в том то и дело. Медленно, но работают на весь 1мб. Ресет возникает при обращении DMA к памяти, причем я читаю, а не пишу ведь... Скорее я где-то с настройкой DMA накосячил, но повысить скорость работы EBI тоже хочется, конечно...
А где вообще можно почитать про работу с RAMPX, RAMPZ и т.д.?

Вот смотрю на асм листинг, который выдал компилятор по сишной функции:

В принципе, если отсюда убрать сохранение RAMPX и перенести его в прерывание, а так же убрать return data и превратить это в ассемлерную вставку, поидее должно побыстрее работать?

Листинг, говоришь . А макросы из моего поста ничего не напоминают? Не тот же хрен сбоку?

Я к тому, что для повышения производительности нужно применять либо инлайн-функцию, либо макрос, иначе основные потери идут на работу со стеком при вызове функции и выходе из нее, и это на каждый байт. Посчитай, сколько времени тратится на CALL __SAVELOCR4 и CALL __LOADLOCR4 из своего листинга. В несколько раз больше, чем на само тело функции.
Мне макрос удобнее, так как можно все сразу контролировать.

Теоретически EBI должна работать с любой группой регистров RAMPZ:Z, RAMPX:X, RAMPY:Y, которая формирует 24-битный адрес.
RAMP - простое расширение регистра. Т.е. выполняются запись

или чтение


что макрос и делает, предварительно сохраняя RAMPZ, больше там ничего нет. Просто инлайновая вставка ассемблерного кода в Си всегда выглядит устрашающе, особенно, если кто не разбирался с написанием подобных примочек. Поэтому в соответствии с синтаксисом своего компилятора (кстати, ты на чем компилишь?) и делай ассемблерную вставку. Кстати, в AVR5 проблему с длинным указателем вроде решили, но там пока много заморочек, я хоть и установил вторую бету, но дождусь финального релиза. Блин, звери, со второй бета опять выкинули поддержку МК AT32UC3C (которые с плавающей точкой) из Dragon, что-то глючит у них совместная работа.

Технически, если (регистровая пара + RAMP) при операциях ld или st попадает в диапазон, определенный в EBI, то (регистровая пара + RAMP) транслируется в адрес EBI. Но у меня это с RAMPX:X и RAMPY:Y не работает, только с RAMPZ:Z. А вот как в твоей функции, когда у тебя задан явно RAMPX, указатель всегда попадает в пару XH:XL? Или это особенность компилятора?

Что касается прямого упоминания про RAMPZ, RAMPX, RAMPY и RAMPD - то это в рефмануале "XMEGA A MANUAL". А в даташите ATMega128 (которая не XMega), там прямо говорится, что "RAMPZ предназначен для работы с внешней памятью, хотя, так как поддерживается всего 64К RAM, RAMPZ используется только при работе с флэшпамятью МК". Правда, там и нет ни RAMPY, ни RAMPX.

Пишу на CodeVision, нравится он мне как-то.
Всё, вник в даташит, наконец всё понял, вроде бы =)
Наваял функции:

Оказалось не так сложно. Работает довольно быстро, правда DMA всё равно ресетит контроллер, видимо для DMA тоже буду писать свои функции, ибо апноутовские работают криво как-то, по крайней мере, у меня.
Большое спасибо за помощь!

Вообще говоря, можно RAMPZ не сохранять, а обнулять при выходе , поэтому не нужна будет строчка


У тебя как-то странно адрес задается, может, Code Vision поддерживает длинный указатель?

Вся бодяга с RAMP - из-за размера 16-битного указателя в GCC компиляторе, поэтому и требуется для внешней памяти RAMP установить, а потом сбросить в 0, чтобы обычные операции с "коротким" указателем не лезли в EBI. Если компилятор поддерживает длинный указатель, то никакие примочки для работы с EBI и не нужны.


С DMA наверняка где-то накосячил, я всегда смотрю сначала даташит и разбираюсь с регистрами, а в апноты авр редко заглядываю.

Если и поддерживает, то только для флеша, ибо про оперативку в нескольких местах написано, что не более 64к...
А если убрать in R0, RAMPZ, он туда какую-то фигню пишет по ходу... Ибо начинает глючить. Видимо в R0 какой-то мусор сидит на момент начала макроса. Можно конечно clr R0 делать, но смысла не вижу, всё равно плюс одна команда.
А вот ldd R23,Y+4 я убрал, всё равно 4й байт не нужен.