Atmel SAM3U4, Различные вопросы Опции

[sonycman]

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

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

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

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

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

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

[sonycman]

Нет, он обязан считать до 47.

А вот и нет!
На практике оказалось не так!

Уже был уверен, после Ваших слов, что глюк с "убеганием" таймера вносит мой софт, но всё же когда пришёл с работы решил прогнать простенький цикл и сохранить значения счётчика TC0 на протяжении его цикла так:

Код

    byte    dbuf[4096];
    for (int i = 0; i < sizeof(dbuf); i++)
    {
        dbuf[i] = (byte)AT_TC0->TC_CV;
    }

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

Код

    AT_TCB0->TCB_TC0.TC_CMR =    AT_TC_CLKS_TIMER_DIV32_CLOCK | AT_TC_WAVESEL_UP_AUTO | AT_TC_WAVE | AT_TC_ACPA_SET |
                                AT_TC_ACPC_CLEAR; //| AT_TC_ASWTRG_CLEAR;
    AT_TCB0->TCB_TC0.TC_RA = 24;
    AT_TCB0->TCB_TC0.TC_RC = 48;

то есть upcounter со сбросом по RC compare, RC = 48(!).
И что же получил:

Код

00 00 00 01 01 01 01 02 02 02 02 03 03 03 03 04 04 04 04 05 05 05 05 06 06 06 06 06 07 07 07 08 08 08 08 08 09 09 09 09 0a 0a 0a 0a 0b 0b 0b 0b 0c 0c 0c 0c 0d 0d 0d 0d 0e 0e 0e 0e 0e 0f 0f 0f 10 10 10 10 10 11 11 11 11 12 12 12 12 13 13 13 13 14 14 14 14 14 15 15 15 16 16 16 16 16 17 17 17 17 18 18 18 18 19 19 19 19 1a 1a 1a 1a 1b 1b 1b 1b 1c 1c 1c 1c 1c 1d 1d 1d 1e 1e 1e 1e 1e 1f 1f 1f 1f 20 20 20 20 21 21 21 21 22 22 22 22 23 23 23 23 24 24 24 24 25 25 25 25 25 26 26 26 27 27 27 27 27 28 28 28 28 29 29 29 29 2a 2a 2a 2a 2b 2b 2b 2b 2c 2c 2c 2c 2d 2d 2d 2d 2d 2e 2e 2e 2f 2f 2f 2f 2f 00 00 00

то есть прекрасно видно, что значением 48 - 0x30 - и не пахнет!
Сброс идёт мгновенно и после 0х2f сразу получается 0!
Теперь понятно, почему была такая погрешность.

К слову, весьма необычная особенность аппаратуры, первый раз сталкиваюсь с таким поведением

Так из картинок и текста все в общем-то понятно...

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

Если прерывания гарантированно укладываются в 65мс, то не нужно.

Хм, да хоть прерывания будут длиться 650 миллисекунд - что изменится?
Код считывания таймера такой:

Код

dword    sys_counter()
    {
        dword hw, lw;
        do
        {
            hw = AT_TCB0->TCB_TC2.TC_CV;
            lw = AT_TCB0->TCB_TC1.TC_CV;
        }
        while (hw != AT_TCB0->TCB_TC2.TC_CV);
        return (hw << 16) | lw;
    }

Переполнение 32 битного счётчика возможно за период равный 71 минуте.
Всё, что меньше этого периода, внести ошибку не в состоянии, по моему...

[aaarrr]

К слову, весьма необычная особенность аппаратуры, первый раз сталкиваюсь с таким поведением

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

Странно действительно, так как прямо противоречит описанию 36.5.6 Trigger Посмотрю на досуге.

Хм, да хоть прерывания будут длиться 650 миллисекунд - что изменится?

Да, все правильно. С прерываниями я погорячился.

[sonycman]

Странно действительно, так как прямо противоречит описанию 36.5.6 Trigger Посмотрю на досуге.

Наверное, это бага. Но в еррате про неё ничего нет.
Впрочем, легко обходится

[aaarrr]

Наверное, это бага. Но в еррате про неё ничего нет.

Надо будет сравнить с SAM7. Описания у них не отличаются.
Впрочем, не припоминаю, чтобы мне приходилось использовать UP_RC с малым значением этого самого RC, а 0.01% мог и не заметить, конечно.

[sonycman]

Надо будет сравнить с SAM7. Описания у них не отличаются.
Впрочем, не припоминаю, чтобы мне приходилось использовать UP_RC с малым значением этого самого RC, а 0.01% мог и не заметить, конечно.

Да я бы тоже не заметил, в других чипах (от AVR до C-M3 разных производителей) никогда не сверял получаемые клоки, так как не использую их для точных измерений.
Только тут, раз уж взялся ковырять модуль и с наскоку заставить заработать как хотелось не удалось, стал проверять всё досконально...

Однако в моём случае ошибка в 2% через всего лишь час дала погрешность, легко заметную на глаз

Процессор, кстати, нормально прожорливый - на 96 МГц кушает почти 60 миллиампер, из периферии включены только TC0-TC2 и PIOA-PIOB.
Если включить всю остальную периферию (без её конфигурирования) - получается красивая циферка 100 ма