Доброго времени суток!
Начал потихоньку осваивать SAM3U4C, сделал темку, так как возникают различные вопросы, которые хотелось бы обсудить.

В этом камне, не смотря на два банка, RAM можно использовать как единый блок по адресам 0x20078000 - 0x20083FFF.

Можно ли такую же методику применить к флеш?
В комплекте с ИАРом идёт флешлоадер, который шьёт сразу два банка по адресам 0x000E0000 - 0x0011FFFF.

Сделал в .icf файле также, посмотрим, как получится на практике, если вместо 0x00080000 везде в программе использовать 0x000E0000.

Ещё хотел спросить про встроенный RTC, если кто им пользовался.

Я так понял, что модифицировать время тут не так просто - надо сначала остановить часы, записать новые значения, запустить их, и подождать около 1 секунды, пока можно будет проводить следующую модификацию.
Вот что интересно - после записи и запуска часов сбрасывается ли прескалер секунд? То есть переход на следующую секунду наступит ровно через секунду после запуска, или раньше, в зависимости от значения прескалера?

Теоретически ничего не мешает.


Это так принципиально? Я бы думал, что сбрасывается, а вообще - проверьте.

Привык пользоваться отдельными ИС для RTC, в частности DS3231 позволяет совершенно не заморачиваться с записью, там всё реализовано прозрачно.
Теперь же придётся вводить ограничения в интерфейсе при установке времени, то есть городить некий огород...

Да, придётся испытывать, плохо, если при установке, допустим, минут, будут сбрасываться секунды, ну да ладно.

Ещё интересно, сможет ли RTC сэма хоть как то приблизиться к точности в +- 2 ppm DS3231?

Огород там совсем небольшой, написать один раз и забыть.


Конечно будут - они же в одном регистре


Не знаю. Мне вообще откровенно не понравилось поведение батарейного блока 3U.

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


А можно подробнее?
Вы часто сначала обмолвитесь про что-либо интересное, но потом таинственно замолкаете...

Жаль, что Атмел не встроили два диода для переключения питания с VDD на VBAT при исчезновении первого, как в тех же STM32...

ИМХО, это уже излишний перфекционизм.


Могу сказать только, что я как минимум трижды наблюдал зависание этого блока - дважды на атмеловском EK и один раз на своей железке.
EK зависал оба раза после прогулки по морозу (сразу оговорюсь, что питание RTC при этом точно не страдало, а температура платы не снижалась ниже 0).

Да, в даташите довольно много ошибок\опечаток и неточностей

Например, сказано, что чип имеет восемь General Purpose Backup Registers (GPBR), то есть восемь 32 битных регистров с батарейным питанием.
Однако адреса приводятся только для четырёх: 0x400E1290 [0], 0x400E1294 [1], 0x400E1298 [2], 0x400E129C [3]

Надеюсь, что их всё же восемь - то есть 32 байта.
Поменьше, конечно, чем в STM32 High Density Devices, но всё же более менее

Увы, атмеловцы этим грешат. Скажем, описание HSMCI иначе как куцым назвать нельзя. Приходится заниматься исследовательской работой.

Да уж. Я некоторое время не мог понять, каким боком работа батарейного блока (в частности контроллера сброса) может зависеть от напряжения VDDUTMI (это USB) ??? Только спустя некоторое время дошло, что имеет место банальная путаница.
Теперь уже не считаю такой даташит как истину в последней инстанции.

Но сейчас этим грешат многие, и ST, и даже NXP.

Поскорее бы обновили документацию на сайте Атмела, может, поправят чего нибудь.

Кстати, тоже буду ковырять HSMCI в плане сопряжения с SD картой.
Надеюсь на Вашу помощь, если что
Там, к слову, в режиме с DMA, можно ли считывать сектора в память, задав один большой буфер? По доке вроде показалось что нет, и надо кроить linked list дескрипторов для каждого сектора...

Это пожалуйста


Можно, хотя я не пользовался. Для каждого сектора никакого linked list не нужно, только для группы.

Спасибо!


Вот для группы я и имел ввиду.
Показалось, что набор регистров управления MCI весьма внушительный, можно задать и кол-во секторов, и их размер, так зачем ещё и нарезать дескрипторы для DMA?

Можно было бы задать ему задание, к примеру, в виде считывания 16 секторов по 512 байт в линейный буфер размером 8к, и пусть себе занимается.
Зачем для линейного буфера задавать кучу дескрипторов и списков?

На самом деле, никто не мешает сделать один большой буфер - со стороны DMA разницы никакой не будет. А пример они просто привели более универсальный.
Скажем, в моем случае при записи linked list нужен, так как из-за особенностей построения буферизации сектора могут располагаться в памяти произвольно.

А, ну тогда это другое дело, тогда это гораздо веселее

ЗЫ: чёрт, привык уже к STM32, что под ресетом у них пины подтягиваются вниз, к земле, а на сэме наоборот - вверх, к VDD, а это у меня активный уровень
Вот бы вендоры сделали не поленились в будущих чипах конфигурирование подтягивающих резисторов к любому плечу по выбору

Их уже ругали за SAM7, где толерантные к 5V IO тоже были подтянуты к VDD, что приводило к проблемам при старте. Здесь их несколько оправдывает то обстоятельство, что пины более не толерантны.

Из мануала не совсем понятно, в режиме Sleep Mode будет ли работать DMA и RAM?

Написано, что в этом режиме снимается клок с ядра, но периферия может тактироваться.
Но оперативка, как я понимаю, относится к ядру, и, если она не тактируется, то и DMA не сможет её читать\записывать...