Здравствуйте, у меня это.. Опции

[Step_ARM]

Половину не понял из того, что написано...
Хотя вопрос сильно интересует.
Проц. LPC2364
INT2(Р2.12) & INT3(Р2.13) подключены как счетные входы. Частоты примерно 400-500 Гц и 200-250Гц.

Обработчики такие:

__irq __nested __arm void EINT2_Handler (void)
{
EXTINT|= EINT2; /* clear interrupt */
__enable_interrupt(); /* handles nested interrupt */
//***********************************************************

ssf_o++;

//***********************************************************
VICVectAddr = 0; /* Acknowledge Interrupt */
}
__irq __nested __arm void EINT3_Handler (void)
{

EXTINT|= EINT3; /* clear interrupt */
__enable_interrupt(); /* handles nested interrupt */
//***********************************************************
count_msr++;


//***********************************************************
VICVectAddr = 0; /* Acknowledge Interrupt */
}

Короче работает только один счетчик , прерывание которого имеет больший приоритет.
Если убираю _nested и __enable_interrupt(); дела не меняет, тоже самое.

Тоже самое на 51-х, Меге и NEC работает прекрасно. Вопрос КАК извернуться? Объясните, пожалуйста , что не так...

[Tanker]

Здравствуйте, у меня это.. LPC2364 и IAR 4.42A (32kB лимит)

В программе, 2 UARTa тянут данные из одной области памяти (каждый интерфейс использует MODBUS RTU, в связи с чем, есть прерывания от UART (RX,TX) и от таймера (считает FrameEnd,TimeOut, DIR - переключение драйвера RS485 с приёма на передачу), т.е. образуется группа UART/TIMER) самая длительная операция - разбор принятого пакета (ну там CRC16 посчитать и т.п.)
Добавятся прерывания от АЦП, ШИМа и ещё 2-х таймеров.
Само собой запросы данных поступают асинхронно, и я вижу (наблюдаю на монике осциллограммы полученные от разных интерфейсов) что когда настроенный на более высокий приритет группа UART/TIMER включается в работу, та что с менее высоким- заметно подтормаживает, если задать им одинаковый приоритер, то "дёргаются" оба - теряют байты в основном. По отдельности работают отлично.
Перевожу прогу с MCS51-го, там всё работает идеально (и на асме была прога, и вот сейчас на Сях, одинаково отличный результат) и в основном цикле почти пусто, 99% кода работает в прерываниях.
Если я сейчас 4-ре прерывания подружить не могу, что дальше будет? На 51-м же они друг другу не мешают, ни разу ни где в проге прерывния не запрещал (только при записи флэшки)
Смотрел и много читал о __nested
В арме я так понял пока выполняется IRQ, другие обработчики не могут выполнятся, что теоретически приводит к пропаданиям события прерывания и сбою алгоритма что я у себя и наблюдаю. Пока надежда на __nested и Ваши советы.
Быстродействия АРМа должно с огромным запасом хватать для этой задачи.
Хочу начать с того, как в стартапе прописать код "прыгающий" сразу на мои вектора? тут был пример для SAM
но в асме пока не силён поковырял cstartup.s79 куда там что добавить?
сделал
EXTERN VICADDRESS
..................................................................
org 0x18
; ldr pc,[pc,#24] ; Branch to irq_handler
ldr pc,VICADDRESS ; Branch to irq_handler VICADDRESS-содержит адрес обработчика
при линковке получил ошибку
Warning[w52]: More than one definition for the byte at address 0x18 in common segment INTVEC. It is defined in module "main" as well as in module "?RESET"
на чём и споткнулся

[Tanker]

Я делал на LPC хаб, где запросы от трёх уартов ретранслировались на 1 уарт, т.е. 3 потребителя инфы обращались через LPC к подопытному "девайсу"... так решилась проблема одного уарта у "девайса"
И всё работает в ~100 экз. раскидано по стране.
В проекте не используются прерывания вообще, работа выполняется "пуллингом" в основном цикле.
Ничего не дёргается (субъективное восприятие периодичности получаемых пакетов данных)
По сути я добавил в новый проект проект прерывания, и началось :-(
На скорости 115200, 1 байт это примерно 87мкс - это же бесконечность для 72МНz процессора!
Делаю вывод, что прерывание захватившее управление блокирует все остальные (в процессе разбора принятого пакета, это длительная операция)... а мне такого не надо!

[Qwertty]

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

Естественно блокирует. Только лечить надо не вложенными прерываниями, а пересмотром алгоритма. В прерываниях не должно быть 99% работы, там должны быть маленькие быстрые обработчики. Основная работа выполняется в основном цикле, а из прерывания только сообщается о событиях. В случае с UART - в прерывании извлекается принятое, помещается в буфер и взводится соответствующий флажок. Все - никаких обсчетов CRC в прерывании не ведется. Можно разве что еще таймер запустить, для определения 3,5 байтового интервала для modbus. Хотя вполне возможно, что таймер и не потребуется - в LPC имеется свое прерывание через 3,5-4,5 байтовых интервала. Я не пользуюсь modbus rtu, так что это лишь предположение. Но при правильно спроектированном алгоритме все должно и с таймерами работать.