Да нет, я из Тольятти...

Вроде всё нормально с твоей прогой.
Проходит инициализация, выполняется твой main() из трёх x++.
А дальше программа заканчивается, и библиотечная __main (или куда там попадаешь?) вызывает SWI.



При простом декременте это всё не нужно.

Сообщение отредактировал sonycman - Jan 30 2007, 18:46

Не совсем понял к какому варианту относится "простой декремент", если к случаю в разностными счетчиками в очереди, то не нужен. Зато нужна проверка и при необходимости коррекция текущего счетчика при занесении новой заявки в очередь, снятии заявки, и особенно приятным становится
коррекция уже заявленного таймера и всей очереди после него....
Плата за то, чтобы с этим не заморачиваться - переключение (причем крайне редкое относительно работы с таймерами) очереди. Программа обслуживания списка естественно одна и все проблемы при фиксации переполнения счетчика указать другую очередь. При постановке в очередь соответственно банальный контроль на больше/меньше текущего и выбор одной из двух очередей. При этом системный счетчик сам по себе вещь не бесполезная и получается бесплатно.
Я использую именно вариант с двумя списками.

Нет, ничего страшного не происходит, поскольку он объявлен как unsigned и сравнение делается после беззнакового вычитания. Для примера возьмем восьмибитный unsigned, и пусть сейчас uiTimer0Count = 0xF8. Тогда nStartTimerVal = 0xF8, и допустим таймаут будет 12. Тогда когда таймер будет равен 0xF0, тогда getTimer()-(s) = 0xFF - 0xF8 = 7; Теперь таймер переполнился и стал равен 0. Тогда 0 - 0xF8 = 0xFF08, но поскольку результат округляется до тех же 8 бит, то получится 8. Как видите, ничего страшного не произошло. Надо только следить, чтобы сравнение происходило в тех же типах, что и тип uiTimer0Count. Для int это происходит автоматически. Для других типов желательно в макрос ввести явное приведение типов. Проще всего ввести для этого через typedef тип "таймаут" и именно этим типом объявить и uiTimer0Count и nStartTimerVal и в макросе сделать приведения к этому же типу. Тогда при переносе из проекта в проект надо будет только выбрать подходящий тип для таймаута. Как дальнейшее улучшение я бы еще объявил макрос типа MS() и MKS() который бы пересчитывал реальное время в милли- и микросекундах в соответствующее количество тиков исходя из частоты таймера. Тогда и при смене частоты таймера достаточно будет подправить только этот макрос:



Можешь кинуть вырезку исходника?

2sonycman
У меня такие подозрения что дебагер глючит. Ну, во-первых прога не моя. Это стартовый код, который среда генерит. Я только заглушку main добавил. Во вторых, последовательность была следующая. Сделал примитивный проект. Всё OK. Добавил <stdio.h> и прога стала вываливатся в SWI ещё до того как до main дойдёт. Ну ладно. Подумал может где в библиотеке swi вызывается а я ниодного регистра VIC не инител (хотя вроде при ресете оно в default находится?) Убрал <stdio.h>, писал свои функции, всё OK. Потом поменял на <stdio.h>, опять в SWI прыгает. И самое интересное, что откат уже ничего не решал. Всё время в SWI. Пересоздал проект. Всё OK. Глюки какие-то? Выполни debug по шагам, и если он себя будет вести по другому, чем я написал в комментариях, то однозначно глюк. Меня в основном интересует почему в VICRaw заносится 0x1000? У тебя заносится? Видно придётся свежею версию скачивать?

Я тоже живу не в России (хотя русский родной) и этот факт у меня отмечен в личных данных. У вас не отмечен, поэтому считаем по умолчанию - "Если не указан город - Москва, если проц - AVR, если компилятор - IAR". Так кажется кто-то предлагал на сахаре :-) Согласитесь, исходных данных чтобы считать вашим родным языком другой было недостаточно. Здесь есть один (минимум) участник из Болгарии и ему никто замечаний не делает.

Оно само решается.
Допустим Вы сделали засечку в 0xFFFFFFFE, т.е. uiTimer0Count==0xFFFFFFFE, а таймаут хотите 4.
т.е. if(VerifyTimer(nStartTimerVal, 4))
и
#define VerifyTimer(s,t) ((t) <= (getTimer()-(s)))
тогда:
через 0 мс if(4 <= (0xFFFFFFFE - 0xFFFFFFFE)) или (4 <= 0) - ложь
через 1 мс if(4 <= (0xFFFFFFFF - 0xFFFFFFFE)) или (4 <= 1) - ложь
через 2 мс if(4 <= (0x00000000 - 0xFFFFFFFE)) или (4 <= 2) - ложь
через 3 мс if(4 <= (0x00000001 - 0xFFFFFFFE)) или (4 <= 3) - ложь
через 4 мс if(4 <= (0x00000002 - 0xFFFFFFFE)) или (4 <= 4) - истина
через 5 мс if(4 <= (0x00000003 - 0xFFFFFFFE)) или (4 <= 5) - истина
....
через (2^32-1)мс if(4 <= (0xFFFFFFFD - 0xFFFFFFFE)) или (4 <= 0xFFFFFFFF) - истина
через (2^32)мс if(4 <= (0xFFFFFFFE - 0xFFFFFFFE)) или (4 <= 0) - ложь

Т.е. Вы должны проверять чаще чем (пересчёт_таймера - таймаут)


Не совсем. Скорее неделимое действие.
Представте что таймер у Вас 64-х разрядный, а процессор 32-х, и в GetTimer() непосредственно после чтения одной части (например младшей, равной 0xFFFFFFFF) происходит прерывание и вся переменная инкрементируется. Тогда стартшую часть переменной GetTimer() вернёт некорректно по отношению к младшей.
Способы обеспечения атомарности разные.
- запрет/восстановление прерываний.
- использование спец. инструкций проца (чтение-модификация-запись например для x86)
- В многопроцессорных делах ещё и lock-и межпроцессорные.
- и т.д.

Этот регистр никакого отношения к инструкции SWI не имеет. Ассемблерная инструкция SWI вызывавет исключение независимо от разрешения/запрещения прерываний IRQ, FIQ и контроллера прерываний. А если вы внимательно прочитаете описание регистра VICRawIntr, то увидите, что это биты сработавших источников прерывания, но собственно прерывание вызовут лишь те из них, которые разрешениы в регистре VICIntEnable. Прочтя пропущенные разделы документации вы обнаружите, что двенадцатый бит означает PLL Lock. А прочтя описание PLL (а его прочитать нужно, раз вы PLL настраиваете) вы поймете что означает взведение этого бита.

Действительно! Это при простом сравнении будет криво, а если сравнивать уже с разностью...
А я и не подумал...
Ну что-же, попробую воплотить именно этот вариант в след. проекте.
Как самый менее громоздкий и по процессорному времени, и по кодированию

2Alex03
Всё понял, спасибо!

Сообщение отредактировал sonycman - Jan 30 2007, 19:30

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

Очередь ж сортированная?
При запихивании в очередь и сортировке всё делается без проблем.
Например из всех значений перед сравнением вычитается текущее значение таймера.
Т.е. если в очереди будут значения 0xB0, 0xE0, 0xFF, 0x10 - ничего страшного, Вы же знаете что в ней!

Заявка:

Переключение очередей:

Протрассировалось и выполнило твой main().
А дальше конец программы - всегда улетает по SWI.

Ты неправильно трассируешь.
Поставь единственную точку останова на свою функцию main(), а не на сишной __main.
Или в свойствах дебаггера галочку Run to main()
И запусти Run. Дебаггер остановится на main(). Всё нормально.

Из main() выхода не должно быть.

А на VICRawIntr внимания пока не обращай.
У тебя всё равно прерывания запрещены.

Сообщение отредактировал sonycman - Jan 30 2007, 19:55

Не совсем понимаю о чем это Вы. Есть, допустм 8бит счетчик и очередь 100, 200.
Текущий счетчик 80. Хочу добавить два таймера на 1 и на 200 тиков.

Запихивайте. Сортируйте. Жду.

Кто-нибудь щупал QFN корпус? Что это за зверь?
Керамика?
А что легче припаять/отпаять с платы - LQFP или QFN? Имею ввиду вручную?

Ффу-у, прочитал, наконец, весь мануал к AT91SAM7S.
600 страниц! Подробностей уже не помню, блин

Сообщение отредактировал sonycman - Jan 30 2007, 21:10

А что, по чертежу не видно, что QFN на втором месте после BGA по хренопаяемости руками?