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



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

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

А вы никогда не пробовали подключать красный или синий светодиод через 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 метров весит, и там, конечно-же, есть таблица с расшифровкой всех битов.

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

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

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

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

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

Сообщение отредактировал Alex_inventor - Jan 31 2007, 00:47

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 библиотечный файл?

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

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

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

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

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

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

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

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

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




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

Понятно.

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

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

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

Сообщение отредактировал sonycman - Feb 1 2007, 02:59