Перейти к содержанию
    

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

Не относится. Шины работать будут:

When Processor Sleep Mode is entered, the current instruction is finished before the clock is

stopped, but this does not prevent data transfers from other masters of the system bus.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не относится. Шины работать будут:

Что-же, тогда замечательно.

 

ЗЫ: а на практике Вы пробовали?

Вот эта табличка тоже говорит, что память перестаёт тактироваться:

post-19695-1309528516_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ЗЫ: а на практике Вы пробовали?

Вот эта табличка тоже говорит, что память перестаёт тактироваться:

Нет, не пробовал. К табличкам нужно относится осторожнее, как мы знаем :)

В Sleep Mode отключается HCLK, память и шины тактируются от MCK.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В Sleep Mode отключается HCLK, память и шины тактируются от MCK.

Отлично, тогда отправлять CPU в сон, загрузив DMA по самые гланды, ничего не помешает :)

 

Нет, не пробовал. К табличкам нужно относится осторожнее, как мы знаем :)

Это верно!

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

Вот ещё один момент:

post-19695-1309530458_thumb.png

и цитата из текста:

The Master Clock Controller is made up of a clock selector and a prescaler. It also contains a

Master Clock divider which allows the processor clock to be faster than the Master Clock.

Каким образом клок процессора может быть не то что быстрее, а вообще хоть как то отличаться от мастер клока, не понятно :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Каким образом клок процессора может быть не то что быстрее, а вообще хоть как то отличаться от мастер клока, не понятно :)

Скопипастили откуда-нибудь, это сплошь и рядом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Провозился вчера весь день с блоком таймеров, реализовывая свою задумку сформировать путём соединения цепочкой один 32 битный таймер с разрешением в 1 микросекунду.

 

Сделал так: TC0->TC1->TC2, выход TC0 (TIOA0) завожу на вход TC1, а выход TC1 (TIOA1) завожу на вход TC2.

 

TC0: играет роль прескалера с входной частотой MCK\2, равной 48 МГц, по событию RA Compare (RA = 24) выход TIOA0 устанавливается в 1, по событию RC Compare (RC = 47) счётчик сбрасывается и выход TIOA0 сбрасывается в 0, получаем меандр с частотой 1 МГц.

 

TC1: младшая половинка 32 битного счётчика, по событию RA Compare (RA = 0xFFFF) выход TIOA1 устанавливается в 1, по событию RC Compare (RC = 0) счётчик сбрасывается и выход TIOA1 устанавливается в 0, получаем импульсы с частотой 1/65536 МГц.

 

Но тут оказалась первая непонятка - такая конфигурация давала инкремент старшей половины 32 битного счётчика сразу по достижении 0xFFFF младшей, что есть переход выглядел так: 0x0000FFFE->0x0001FFFF->0x00010000.

Чего я как то не ожидал, поэтому угрохал на вычисление проблемы целый день :)

 

Пришлось задать настройки для компараторов вот так:

TC1: младшая половинка 32 битного счётчика, по событию RA Compare (RA = 0) выход TIOA1 устанавливается в 1, по событию RC Compare (RC = 0x8000) счётчик сбрасывается и выход TIOA1 устанавливается в 0, получаем меандр с частотой 1/65536 МГц.

 

Ну а последний счётчик TC2 является старшей половинкой получившегося 32 битного регистра и просто тупо инкрементируется 0->0xFFFF безо всяких компараторов.

 

По мере тестов теперь возникла ещё одна проблема - таймер немного "бежит", за час на минуту-другую.

Оценка грубая, но видно это хорошо.

 

Отсюда возникли вопросы к "прескалеру" на базе TC0, который должен считать от 0 до 47 и снова с 0 до 47, но, вероятно, считает от 0 до 46, а на 47 происходит сброс сразу на 0, отсюда получаем "бегущий" таймер.

Пока что это предположение, надо будет проверить его на практике.

 

В мануале, жать, не приводятся точные цифры по различным режимам счётчиков... :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пришлось задать настройки для компараторов вот так:

TC1: младшая половинка 32 битного счётчика, по событию RA Compare (RA = 0) выход TIOA1 устанавливается в 1, по событию RC Compare (RC = 0x8000) счётчик сбрасывается и выход TIOA1 устанавливается в 0, получаем меандр с частотой 1/65536 МГц.

На самом деле, достаточно было бы просто отинвертировать входной клок для TC2 (бит CLKI).

 

Ну а последний счётчик TC2 является старшей половинкой получившегося 32 битного регистра и просто тупо инкрементируется 0->0xFFFF безо всяких компараторов.

А здесь все же был бы уместен программный счетчик. Но хозяин - барин.

 

Отсюда возникли вопросы к "прескалеру" на базе TC0, который должен считать от 0 до 47 и снова с 0 до 47, но, вероятно, считает от 0 до 46, а на 47 происходит сброс сразу на 0, отсюда получаем "бегущий" таймер.

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

 

В мануале, жать, не приводятся точные цифры по различным режимам счётчиков... :(

Не понял, какие цифры?

 

Все же не понимаю вашу систему. Зачем такое сумасшедшее разрешение? А еще ведь при чтении счетчика придется проверять граничные условия с запретом прерываний и корректировать при необходимости старшее слово.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не понял, какие цифры?

 

Все же не понимаю вашу систему. Зачем такое сумасшедшее разрешение? А еще ведь при чтении счетчика придется проверять граничные условия с запретом прерываний и корректировать при необходимости старшее слово.

Цифры значений счетчика, потактово,чтобы было понятно на 100%, когда происходит инкремент/сброс и т.п, иначе лично у меня возникли неясности...

 

Что касается разрешения - мне так удобно на стадии отладки и разных тестов.

Считывать половинки действительно приходится несколько раз (старшую половину), но запрещать прерывания не нужно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Цифры значений счетчика, потактово,чтобы было понятно на 100%, когда происходит инкремент/сброс и т.п, иначе лично у меня возникли неясности...

Так из картинок и текста все в общем-то понятно, они его давно уже копипастят :)

 

Считывать половинки действительно приходится несколько раз (старшую половину), но запрещать прерывания не нужно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати, ещё одна фишка по поводу странной работы счётчика в режиме upcounter со сбросом по Compare C.

 

При вот таких параметрах TC0: RA = 0, RC = 47, совпадение по RC устанавливает TIOA0, совпадение по RA его сбрасывает - инкремента TC1 не происходит вообще.

Если в RA записать 1 - всё работает.

Странно... :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Странно... :(

Всё законно :):

Note: In all cases, if an external clock is used, the duration of each of its levels must be longer than the

master clock period. The external clock frequency must be at least 2.5 times lower than the master

clock

В вашем случае это условие нарушается - импульс слишком короткий.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В вашем случае это условие нарушается - импульс слишком короткий.

Понятно, спасибо :)

Что-то не подумал, что это "внешний" сигнал...

 

Теперь осталось только выяснить, почему счётчик "бежит" вперёд на две минуты в час.

Хз, может быть, косячу при замере, а может дебаггер как то влияет (через него смотрю состояние переменных/регистров)...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Нет, он обязан считать до 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 минуте.

Всё, что меньше этого периода, внести ошибку не в состоянии, по моему...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Впрочем, легко обходится :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...