[Domnitch 0]

Дано: Philips LPC-2214, Micrium uC/OS-II, IAR 4.11

От таймера 0 идут прерывания (100 тиков/с), они заведены через VIC на OSTimeTick()

Кроме этого, прерывания генерируются по фронтам/спадам на входе P0.10, P0.11 - по этим прерываниям запускается таймер 1, замеряющий длину импульса на входе

 

Проблема:

Входные импульсы на P0.10, P0.11 периодически теряются.

Есть подозрение - из-за того, что OSTimeTick() запрещает прерывания на время своей работы (порядка 20 мкс), а потому прерывание от входа, случившееся во время этого запрета, просто пропадает.

 

Спрашивается:

1) возможны ли другие причины потерь импульсов (на входе они заведомо есть, тест-вертушка без ОС их обнаруживает надежно)

2) как настроить VIC и обработчики прерываний, чтобы прерывание от входа не пропадало, а лишь задерживалось на время запрета прерываний?

 

Помогите, пожалуйста.

[one_man_show 0]

На мой взгляд, если Вы используете РТОС, то процессы, которые хотите обслуживать, не должны быть соизмеримы по времени с тикером. В операционке тикер - это самый быстрый процесс. Если есть какой-то процесс быстрее тикера, то операционка не будет успевать обрабатывать этот процесс. Что и наблюдается в Вашем случае. (Если я правильно понял Вашу проблему)

[Domnitch 0]

one_man_show

В принципе Вы правы - прерывание от тикера должно быть наиболее приоритетным и более быстрые процессы должны обрабатываться аппаратно.

 

Однако в любой реальной системе неизбежны случаи, когда прерывание от какого-либо источника (пусть это прерывание 2) возникает в тот момент, когда уже идет обработка прерывания от другого источника (1). Хороший контроллер прерываний в этом случае должен держать запрос 2 до момента отработки именно прерывания 2, а хорошая программа обработки прерывания - сбрасывать по завершении лишь тот запрос, который она отработала, а не все разом. По крайней мере так меня учили 20 лет назад...

 

Я готов смириться с тем, что обработка прерывания 2 будет задержана на некоторое время (в моем случае - потребное для отработки тика), но у меня стойкое ощущение, что оно пропадает вообще.

 

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

[emerg_reanimator 0]

Не могу себя назвать знатоком в практическом примении этой ОС и процессора, но теоретико-логическом плане определённые знания имеются.

 

Мне почему-то подумалось вот, что:

Такая ситуация может возникнуть на процессорах LPC в момент когда перырвания запрещаются (Spurious interrupts). Периферия обнаруживает прерывания и посылает запрос на обработку прерываний к ядру. Но в этот момент ядро выполняет команду запрета прерывания. После выполнения этой команды, прерывания обрабатываеться и вашем случае передаётся управление контроллеру прерываний. А так как прерывания запрещены, то контроллер не может определить источник прерываний и возвращает нулевой адрес обработчика прерываний.

 

Насколько я помню, в микроКОСе таки прерывания обрабатываются заглушками (DummyInterrupt Handlers, если я не ошибаюсь). И система никак не фиксирует такие события.

 

На мой взгляд в вашем случае стоит попробывать без контроллера прерываний (1), аппаратно буфферизировать прерывания (2).

 

Хотелось бы увидеть код обработки прерывания для работы с ОС и без неё. Тест запрещает прерывания?