Оно само решается.
Допустим Вы сделали засечку в 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
Всё понял, спасибо!

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

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

Заявка:

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

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

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

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

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

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

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

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

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

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

Вот смотрю я на принцип. схему платы Olimex SAM7-P256.
Там два светодиода подключены к PA17 и PA18 соответственно.
И вот только что прочитал, что макс. ток по этим линиям не должен превышать 2 мА. Там что - сверхяркие LEDы стоят, способные от 2 мА зажечся? Или фирмачи недосмотрели чего?



Ну, там на торцах корпуса площадки для пайки есть. Подумал, может тонким жалом не трудно будет припаять...
Понятно

А вы никогда не пробовали подключать красный или синий светодиод через 6.8 кОм на 5 вольт? Да, днем его на солнце не видно. А при комнатном нормальном освещении - очень отчетливо. С зелеными конечно хуже, они не такие чуствительные.



Ну я б не сравнивал QFN и BGA. Первый паяльником паяется. Флюса побольше - и ничем он не хуже TQFP. Все равно по отдельными выводам не попадаешь при 0.5 шаге...

Ну а какой в этом смысл? Там полно ног с током 8 (есть и 16) миллиампер, а светодиоды прицепили почему-то на самые слабые выводы?

Вообще-то если номинальное напряжение светодиода 2 вольта и стоит токоограничивающий резистор на 560 ом, то при питании проца 3.3 вольтами через диод как раз будет протекать около 2 ма.
Хм... ну посмотрим, как ярко они будут светиться...

Сделал тест:
V 3.3
R 560 Ом
5 uCd
VD зелёный 2.17mA
VD кпасный 2.18 mA
2 Cd
VD красный 1,7 mA
Т.к. в цепи ещё и внутренне сопротивление миллиамперметра (нехилое сопротивление), поэтому реальные значения на 10-20% больше.


Я в шоке! Меня user manual на lpc210x достал уже. В нём только 173 страницы. Правда когда обнаружил следующее:

Подумал, что может, где полный лежит. Скачал вариантов 5, все одинаковые. Вот выше советовали подробно читать о регистре VICRawIntr, на там про него только пару строк (впрочем, как и про большинство регистров):

A должна быть ещё и таблица какой бит какому источнику соответствует. Или я ошибаюсь?
Вопрос, есть ли более подробный мануал?

Это ты в Протеусе тестил?

У меня тоже Preliminary, почему-то. Самый последний качал.
А у тебя User Manual, или может просто даташит?
Потому что мануал для LPC214x 6.5 метров весит, и там, конечно-же, есть таблица с расшифровкой всех битов.

Разобрался с вываливанием в SWI. Это не реальное SWI, а физический прыжок. Среда с толку сбила. При отладке по шагам если в другой файл попадаешь то почемуто RUN запускается. А в дизосемблере всё OK.

Нет, в реале, я же железячник, мне это 1 минута. Хотя в PROTEUS тоже можно.

Нет, у меня как раз User manul. У филипок всё раздельно. Errata, datasheet, user manual. Не как у Atmela. В datasheett у филипок только электрические данные, типы корпусов и т.п.

Спасибо за информацию. Только где ты 6.5 метров откапал? Я вот сейчас качаю LPC214x User Manual 2,7 весит.

AAAA!!! Сказка!!! В LPC214x_User_Manual.pdf расписаны все регистры! Филиппы козлы! На прошлой неделе всю жизнь мне испортили. Я по ихниму user_manual lpc2106-10.pdf ARM осваивал, ничего не понимал. С VIC вообще ступор получился. Ни как не мог врубится как определяется адрес прерывания. Смотришь в исходник, потом в user_manual и ,как говорится, видишь фигу! Я уже испугался, за себя, думал, деградация пошла. Не могу разобраться в архитектуре. Но сейчас быстро наверстаем упущенное. Быстро расколем этот орешек ARM.

81, 100, 200, 24
Где 24 есть (80+200)%256.

При запихивании 1:
100: 1 <= (100-80) - ДА, ставим 1+80=81 перед 100.
Получился список 81, 100, 200

При запихивании 200:
81: 200 <= (81-80) - Нет, идём по списку дальше
100: 200 <= (100-80) - Нет, идём по списку дальше
200: 200 <= (200-80) - Нет, идём по списку дальше
Конец списка, добавляем 200+80=24 (модуль 256 сам получится).
Получился список 81, 100, 200, 24

Воот.

Ну и для примера давайте туда ещё 220 и 210 запихнём.
При запихивании 220:
81: 220 <= (81-80) - Нет, идём по списку дальше
100: 220 <= (100-80) - Нет, идём по списку дальше
200: 220 <= (200-80) - Нет, идём по списку дальше
24: 220 <= (24-80) - Нет (24-80 = 200 ), идём по списку дальше
Конец списка, добавляем 220+80=44
Получился список 81, 100, 200, 24, 44

При запихивании 210:
81: 210 <= (81-80) - Нет, идём по списку дальше
100: 210 <= (100-80) - Нет, идём по списку дальше
200: 210 <= (200-80) - Нет, идём по списку дальше
24: 210 <= (24-80) - Нет (24-80 = 200), идём по списку дальше
44: 210 <= (44-80) - Да (44-80 = 220), добавляем 210+80=34 между 24 и 44
Получился список 81, 100, 200, 24, 34, 44

Усё, надеюсь нигле не очепятался.
Естественно все вычисления беззнаковые.
Если вдруг у Вас не связанный упорядоченный список, а например какойнить несортированный массив, то для сравнения/сортировки, как я уже говорил, достаточно просто вычитать текущее значение таймера (оно в примере выше так и есть).

Alex_inventor предупреждён за хамство и лишён прав на 15 дней.

Получился улучшенный вариант с инкремементом счетчика. Тоже рабоает за счет специфичного упорядочивания при постановке. Теперь начинаем работать - периодически контролируем текущий счетчик на превышение первого значения в очереди и .... "ой" при контроле в диапазоне
201...23 у нас преждевременно сработает таймер .
Таким образом, это будет работать при двух условиях - обязательное обязательное упроядочивание и обязательный контроль на каждом тике.
В случае с очередями принудительное и неизменное упорядочивание
является опциональным и позволяет надежно использовать его в случае операционной системы, когда Task_Control_Block-и задач содержащие в том числе и счетчики могут быть упорядочены/переупорядочены по другим критериям, например по приоритету задачи. Ну и естественно могут быть
пропущены тики.

Работаю с компилятором RealView.
Написал __SWI функцию, думаю, дай проверю, как будет работать.
Компилер функцию создал, но при вызове проц попадает на заглушку по вектору SWI_Handler: B на этот-же адрес. Ну это понятно, так задано в Startup.s.
А можно как-то вызвать библиотечный хендлер, чтобы не писать свой на асме?
Просто запись IMPORT SWI_Handler даёт ошибку - Undefined symbol.
Может, надо включить какой-то определённый .h или .c библиотечный файл?

Там есть пример (в папке Кейла), но в нём хендлер написан свой...

Согласен, но...
Если контролировать на жёсткое равенство непосредственно после каждого инкремента то всё нормально.

Согласен. Видимо надо уточнять "условия игры".
В первую очередь, пропуск тиков. Откуда идут тики?
Если програмно инкрементируются (в таймерном прерывании), то и очередь можно тутже обслужить, даже если времени в обрез, то по крайней мере перенести из списка ожидающих таймаута в expired список ожидающих обработки (например очень приоритетной задачей).

Если тики более другие, то и подход соответствующий. Либо вообще, либо по "догонянию" времени.
Ваш же пример с для пропусков тиков не катит.

ЗЫ Истина (оптимальные варианты) гдето рядом.

Условия игры естественно в корне меняют дело. То, что я пишу относится к поминанию
Сергеем операционных систем а отнюдь не локальной конкретной задачи работы с кучей таймеров. Вещи достаточно отличающиеся и естественно имеющие разные оптимальные решения.

Насчет тиков и пропусков отношении системы, я конечно не четко объяснил - речь естествено не идет о
формальном пропуске тика приводящего к ненаращиванию аппаратного или программного счетчика.
Дело о случае, когда четко зафиксировав заявленное время система по каким-либо причинам не может в тот-же момент произвести действия заявленные на достижения тамаута получается, что проскальзывает не собственно счетчик. Конечные результаты схожи - время настало, а действие пришлось отложить. Потом, когда, например, полнировщик разморозят он должен иметь возможность
максимально корректно обработать пропущенные заявки.

P.S.
Не знаю, как понятнее обьяснить Ну если в простой программе, то например работая четко по таймеру,
наращивая и сравнивая тики при каждом тике с первым значением в очереди и четко фиксируя сей момент мы вдруг выяснили, что, например не можем выполнить нужное в данный момент действие - послать байт в UART по причине занятости буфера передачи . Система таймеров "не виновата",
но выкручиваться надо. Механизмы выкручивания могут быть разные.




Писать свой на ASM - точнее править всего несколько строк в исходном. Хотя в некоторых компиляторах есть соответствующие прагмы ломового для изменения точек входа в default стартапе. Я бы правил ручками - как-то спокойнее и уж явно переносимее.

Понятно.

Что-то не нашёл в даташите на SAM7 как у него обстоят дела с защитой от статики.
С AVRами, правда, проблем никогда не было, надеюсь, сэмы в этом отношении не хуже.

Насколько я понял, для их прошивки используют две проги:
SAM-BA.exe и
SAM-PROG.exe

А какая получше будет?
Эти проги кушают только .bin файлы?
Тогда конвертить откомпиленные .hex можно обычной утилитой hex2bin, наверное?

А что, где-то эта проблема еще актуальна? Мне казалось, она канула в лету со 176й серией. Или я неправ? Ответьте, кто сталкивался.

При работе с ЖКИ Мэлт MT16S2D (или H) индикатор немедленно вышел из строя после небольшого статического щелчка от прикосновения пальцем к металлической рамке его дисплея (которая соединяется с GND сего девайса).
Микроконтроллер (уже не помню, PIC это был или AVR) при этом никак не пострадал.
Эти ЖКИ практически не имеют антистатической защиты. С ними надо быть особенно осторожным.

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

У нас тут один товарищ при запуске ПЛИС (алтера EPM240...) решил проверить не греется ли, "молния" между чипом и пальцем была весьма внушительная, чип потом выкусывали.

Решил запостить сюда, не стал создавать новую тему, чтобы не засорять форум своими вопросами...

Запутался с типами данных применительно к ARMам.
Оказывается, и int, и long имеют совершенно одинаковый размер - 32 бита.
Но для чего тогда нужен этот long? Для совместимости?
Наверное, его можно не использовать в программе, ведь достаточно будет int?

Помню что есть какая-то зависимость размера указателя и разрядностью шины адрса. Т.е. AVR int - 16 бит, хотя сам он 8-битный. А ARM - 32 бита. Может и вру.

Для определенности.

Просто четко выражайте мысль в каждом конкретном случае. Там, где явно всегда независиимо от
платфрмы нужет будет 32bit - так и пишите long /ulong. Ну а для расходных целей, типа из функции возвратить пару-тройку-сотню... кодов ошибок - естественно int. При таком подходе будет меньше напрягов как для Вас, так и для контроллера (поскольку int это макcимально "естественный" и "удобный" для микроконтролера тип) при портировании на разные платформы.

char - 8
short - 16
long - 32

short <= int <= long - для разных платформ по-разному, как правило int == "битности" процессора

(Это из наблюдений. точной формулировки - почему так - не помню)

А еще лучше написать себе .h типа такого:

И там где нужен точный размер использовать эти typedef.
При переносе - проверить только эти несколько строчек.

Всем спасибо большое, теперь знаю

Платка SAM7-P256 приехала, начинаю заниматься

Для 8-ми биток 16-ти разрядный int не особо то естественный.

Такого требования (16bit) ограничения в общем случае не существует.
Стандарт "C" накладывает только следующие ограничения
sizeof( char ) <= sizeof( short ) <= sizeof( int ) <= sizeof( long )
Компиляторы для 8bit контроллеров которые принимают sizeof( int ) = 16 не слишком хорошо поступают
Хотя естественно ничего не нарушают и более того - им не приходится вводить дополнительно "лишний" 16bit тип. Лично мне по названой ранее причине много больше нравится "естественый для процессора" тип int. К счастью это условие как правило выполняется для контролеров начиная с 16bit.
Если писать на "C" для 8bit-ников, то для переносимости стоит заводить свой специальный tinyint
(а не использовать char !), который при портировании на большие контроллеры дефинируется как простой int.

Простите, а можно подробнее.
Дело в том, что определением "int" я вообще не пользуюсь, потому, как для разных платформ оно имеет разное значение.
Но мне непонятно, как "char" может даже на больших контроллерах быть интерпретирован как "int". Приведите пример, плиз.
Вопрос имеет чисто познавательное значение.

В некоторых случаях размер не имеет особого значения, но явно указывая какой-нибудь счетчик как
байтовый для 8bit платформы можем иметь ненужные напряги для, например, 32 ARM который имеет много более скромные возможности по работе с 8bit. Посему int удобен для использования как размер
на усмотрение компилятора. Для этого и пользую.

Почему не понятно? Ограничений нет. Реальные компиляторы? Под 8bit на "C" крайне мало писал, но под Z80 компилятор с управляемым размером int встречал, как и модификатор "small int".

Для решения этих проблем с С99 были введены int_least8_t и до кучи int_fast8_t типы.
В stdint.h хидерах они естественно теперь есть, но я еще ни разу не видел что кто-нибудь пользовался

Непонятно. Засада в том, что даже АВР-овские компилеры (IAR, например) интерпретируют "int" как 16-бит, что, в общем-то, неправильно, но это факт. Я, правда, на С не делал ни одного реального проекта для 8-бит процессоров, но, по-моему, использование типа "int" порождает больше проблемм, чем удобств пользования. Посему считаю его изжившим себя. Если не прав - поправьте.
Далее, согласитесь, что перенос фирмваре с одной платформы на другую (а, тем более, другой разрядности), бывает весьма редко, и для этого кому-то приходится совершать подвиг, который вовсе не ограничивается преобразованием типов.
И ещё. По-моему, АРМ с 8 (или 16) бит справится не хуже, чем с 32.

Стоп-стоп. Здесь речь идёт, вроде, о "больших" контроллерах. Но в данном курятнике я не разу не встречал интерпретации "char" как простой "int" (о специальных типах не говорим). Может, конкретный пример приведёте?

Ну мне, как Вы поняли это тоже кажется не слишком правильным, но "чаще всего встречающимся"
как написали Атмеловцы.

Совсем наоборот! C постепенным уходом даже из embedded восьмибитных контроллеров с их
тупо используемым принципом "чаще всего встречается" (а почему чаще всего тоже ясно - "C" компиляторы на 16bit расцвели, вот и "чаще" оказались на момент прихода их на 8bit платформы)
int становится НОРМАЛЬНО применимым типом. Именно по этой причине, полагаю, и ранее упомянутые типы введеные С99 никому нахрен и не понадобилитсь, ибо int он и есть тот самый и "не менее X" и "быстрый".

Отнюдь! У мения, например, контролер самая мелкая микросхемка, как правило и львиная доля наработанного кода относится к многочисленной периферии. Вот и портирутся наработки в 8bit (8085->51) на
186 -> 486 -> ARM. Да и чужой код тоже портируется - буквально на прошлой неделе MicroChip-овские
8bit исходники для работы с ENC28J60 частично использовал (точнее пытался, ибо дерьмом в общем-то оказались - в результате один header остался) для 32bit ARM.


Хуже , даже НЕ рисковый процессор типа x86 имеющий полный набор команд для работы c 8-16-32 битными значениями как в регистрах, так и в памяти хуже( медленнее) справляется с не родными размерами переменных не выровнянными на разрядность шины.

Тоже стоп! Я не говорил и "больших" (в смысле 16-32 битных?) контроллерах с 8bit int! Только о том,
что для восьмибитных int может быть и вполне логичен, допустим стандартом и я встречал компилятор для 51 контроллера (поставлялся в начале 90x для заказных коммуникационных чипов с ядром 51 ).
Компилятор, скорее всего (продукт были Израильский и контролеры и управляющие машины там все Intel/USA ) был или базировался на чем-то от Intel-овском. Все было вполне естественно, размерность int
могла быть и 8 и 16 bit на усмотрение пользователя.

Зачем в 1000й раз выдумывать самокат, пользуйте стандарт - в stdint.h есть определения int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t - и не будут возникать проблемы при переносе на разные архитектуры когда "писатель" в одном случае использует int как 32-битный, потом оказывается на другом контроллере/компиляторе что это 16-бит, возникают непонятные ошибки в вычислениях, переполнения, и тратится куча времени на поиск ошибок, переопределение типов и т.д...
Непонятно только почему многие не понимают что char,int,long давно пора перестать использовать ?

И там-же еще int_least8_t .... uint_least32_t, int_fast8_t ..... uint_32fast_t
Как-бы проблем с 1999 года вообще нет - ну просто на все случаи жизни
Только глазами о такую хрень спотыкаешься и набирать с души воротит.

А потому, что на самом деле и с ними de-facto проблем НЕТ, кроме обсасываемой здесь одной единственной - int на 8bit платформе. Ну и еще того, что char может быть по умолчанию, как знаковым, так и нет (но это слава богу обычно компиляторам можно в командной строке указать)

Посему все эти intXX_t полностью соответствуют в привычным, коротким и читаемым
char ( uchar, BYTE ) short( ushort, WORD ) long ( ulong, DWORD )
Ну а int ( uint ) в большинстве случаев прекрасно справляется с обязанностями всяких int_least8_t .... int_least32_t, int_fast8_t ..... int_fast32_t.
Главное действительно перестать использовать его где попало и как попало .

и что, все эти uchar, BYTE, WORD, DWORD, u8, i16, UI32 определены для каждого компилятора во всех библиотеках ? На практике чаще всего встречается что каждый в своих библиотеках определяет типы как попало, это мешает чтению больше чем int8_t, uint8_t. И написать uint8_t быстрее чем unsigned char.

"все эти" лично у меня идут в отдельном header и максимум, что ВДРУГ может потребоваться посмотреть header и если ВДРУГ для какого-то экзотичного компилятора потребуется - подправить.
А вот правильный header c вышеупомянутыми типами может и не быть в составе "каждого компилятора"
.

Дело исключительно привычки. К счастью язык достаточно живой и позволяет несколько облегчить жизнь не только абстрактному программисту, но и себе любимому
Посему у меня там разных своих типов вместо безликих 8-16-32 битных много определено и унионов, и структур - для удобства чтения и недопущения ошибок. Так-что несколько uxxx со товарищами погоду не делают. Надеюсь Вы не будете возражать против своих типов и не будете требовать сводить все
к безликим 8-15-32-64 с целью "не мешать чтению".

То, где однозначно напрашиваюется использование типов из C99, это конечно публикация кусков текстов относящихся к более-менее абстрактным областям программирования - иначе говоря "книжки", исходники уровня clib, ......

Ну вот и я решил влиться в ряды армоводов. Купил плату от olimex'a, скачал с сайта пример - моргание светодиодов на плате. Решил залить по usb. Я так понимаю через samba можно загружать только файлы с расширением .bin ??? Вопрос, как получить в IARe bin ?

Options-Linker-Output Format-other-raw-binary

zltigo, Вы однако, уже определитесь...

ставил так, не помогло, с светодиодами ничего не происходило. Хотя готовый бинарник с сайта работает

А Flash Release выбрана конфигурация ? Подазабыл, может в Атмеле еще какие-то телодвижения нужны, все более по LPC копаюсь

Там еще выше было:


Где протворечие, хоть какое-то, Вам увидеть удалось?
int эффективный тип хорошо работающий не на 8-bit платформах, на коих приходится для эффективности явно указывать везде, где можно явно 8-bit типы. Использование явных 8-bit типов на ARM платформах крайне не желательно. Для x86 - безразлично, если конечно они не в пакованных невыровненных структурах. Если ориентироваться на портирование на 8-bit, то тогда правильным является ... least8_t
Вторая приведенная Вами цитата из темы портирования AVR исходника.
Вопросы?