AT91SAM9263 Interrupt Vectors TABLE?, Не могу въехать в таблицу векторов прерываний. Опции

[Amper25]

Здравствуйте товарищи !

У меня проблема - не могу въехать в принцип организации таблицы векторов прерываний данного процессора.
То что Reset по адрессу 0x0000 0000 - это понятно. Источников прерываний - 32. Так как команды 4-х байтные, то адреса должны идти с шагом 4.

Т.е. что нибудь наподобии:
0x0000 0000 - Reset
0x0000 0004 - INT1
0x0000 0008 - INT2
.....
0x0000 007C - INT31

Но вот вопрос, почему компилятор IAR выделяет под таблицу только 32 байта:

Disassembly of section .data:
...
0x00300000 ldr pc, [pc, #24] ; 0x00300020
0x00300004 andeq r0, r0, r0
0x00300008 ldr pc, [pc, #24] ; 0x00300028
...

Или я не правильно понял организацию таблици векторов прерываний, или это IAR глючит?
Вообще, если кто имел дело с этим процом, подскажите каким образом у него организована таблица векторов. В Datasheet на AT91SAM9263 её почемуто нет.

Или может есть только 8 векторов, в зависимости от приоритета прерывания. А обработчик должен сам искать источник прерывания?

Заранее спасибо.

[DASM]

Неправильно поняли. У ARM7 "прерываний" только два FIQ и IRQ. Еще есть исключения (собственно прерывание - тоже исключения), есть SWI , но пока их оставим в покое. Пожтому при любом IRQ процессор исполняет команду по вектору IRQ , а уж там он может считать адрес процедуры источника - этим занимается AIC. Вобщем советую курить даташиты - там все расписано
0- вектор reset
0x4 - undefined instruction
0x8 - SWI
0xC prefetch abort
0x10 Data abort
0x14 reserved
0x18 IRQ
0x1C FIQ
вот по адресу 0x18 и прыгаем на дальнейший обработчик ВСЕХ IRQ в системе. А там уж выяснем кто виноват и что делать

[Amper25]

Я вообще то имел ввиду SAM9 а не SAM7.

А по поводу прерывания - мне нужен TimerCounter0 Interrupt.
Он получается относится к SWI?

[DASM]

Он относится к IRQ или FIQ . Без чтения док - извините, пусть другие разжевывают

[aaarrr]

Я вообще то имел ввиду SAM9 а не SAM7.

Система прерываний у них одинаковая.

А по поводу прерывания - мне нужен TimerCounter0 Interrupt.
Он получается относится к SWI?

Он относится к блоку таймеров (Peripheral ID 19). Именно этот номер и нужно будет сообщить AIC'у.
SWI - программное прерывание, к AIC и прочему железу отношения не имеет никакого.

[Amper25]

Спасибо, что просветили. Я просто предполагал, что тут таблица векторов организована как в AVR-е.
То есть на каждое прерывание свой вектор.
А оказалось все гораздо хуже.

Вообще я только недавно начал изучать ARM, поэтому и туплю. Или это Datasheet так коряво построен. С AVR все было гораздо проще.

[aaarrr]

Вообще я только недавно начал изучать ARM, поэтому и туплю. Или это Datasheet так коряво построен. С AVR все было гораздо проще.

Даташит нормально построен, просто Вы начали осваивать ARM с топового камня от Atmel. Сюрпризов будет еще много.

[kizeev_e]

........
0x18 IRQ
0x1C FIQ
вот по адресу 0x18 и прыгаем на дальнейший обработчик ВСЕХ IRQ в системе. А там уж выяснем кто виноват и что делать

DASM, скажите пожалйста, ... из это следует ли что если установить начальный адре для компиляции не 0x100000 а 0x102000, то прерывание должны попрежнему срабатывать ? ( я так понимаю что адрес вызываемой фунции в обработчике буде в этом случаи X+0x2000....но у меня не работает ((....к примеру мигание сведодиодами работает а вот прирывание не срабатывают..просто "виснет" )

[aaarrr]

DASM, скажите пожалйста, ... из это следует ли что если установить начальный адре для компиляции не 0x100000 а 0x102000, то прерывание должны попрежнему срабатывать ? ( я так понимаю что адрес вызываемой фунции в обработчике буде в этом случаи X+0x2000....но у меня не работает ((....к примеру мигание сведодиодами работает а вот прирывание не срабатывают..просто "виснет" )

Процессор всегда вываливается в 0x18/0x1C. Куда он пойдет дальше всецело зависит от контроллера прерываний.
Граждане, читайте документацию.

[kizeev_e]

Процессор всегда вываливается в 0x18/0x1C. Куда он пойдет дальше всецело зависит от контроллера прерываний.
Граждане, читайте документацию.

...пожалуйста, подскажите или поправте меня если что-то не усмотрел в документации....после возникновения прерывания процессор вываливается в 0x18(для nIRQ) - далее контроллер прерываний смотрит AIC_AVR что за прерывание и после этого загружает значение AIC_SVR - адрес программы обработки прерывания, а тут ему разве не все равно где этот обработчик прирывания, если в регистр AIC_AVR загружено значение этого опработчика?
..из примера....
AT91F_AIC_ConfigureIt ( pAic, AT91C_ID_US0, 7, AT91C_AIC_SRCTYPE_INT_EDGE_TRIGGERED,
( void (*)())UART_int_handler );
так работает
-DROMSTART=00000000 /
из map файла
UART_int_handler 0x0010021c ARM Code 224 main.o(.text)

так Не работает
-DROMSTART=00002000 /
из map файла
UART_int_handler 0x0010221c ARM Code 224 main.o(.text)


Заранее благодарен за ответ

[aaarrr]

...ему разве не все равно где этот обработчик прирывания, если в регистр AIC_AVR загружено значение этого опработчика?

Ему совершенно все равно.

так Не работает
-DROMSTART=00002000 /

А что в этом случае лежит по адресу 0x18?
Там должна быть инструкция чтения вектора прерывания, например ldr pc, [pc, #-0xf20].
Не "уехала" ли она при смене DROMSTART?

[kizeev_e]

Ему совершенно все равно.
А что в этом случае лежит по адресу 0x18?
Там должна быть инструкция чтения вектора прерывания, например ldr pc, [pc, #-0xf20].
Не "уехала" ли она при смене DROMSTART?

......мде....действительно.... а тамато нули или фыфы одни ( в зависимости от компилятора )
и все это сдвинуто... ровно на DROMSTART, вот и виснет.
Спасибо, буду дальше испытывать , надеюсь все получится .....

[DASM]

aaarrr "ldr pc, [pc, #-0xf20]."
Мое личное мнение - жутко не люблю эти трюки. Для профи может и сойдут, типа 10-15 тактов сэкономить, но зачем такие неочевидные вещи как сворачивание через адрессное пространство давать новичкам в примерах - не понимаю. Может по- человечески просто прочитать VicVectAdddr (в Атмеле он похоже как-то обозван)

[aaarrr]

aaarrr "ldr pc, [pc, #-0xf20]."
Мое личное мнение - жутко не люблю эти трюки. Для профи может и сойдут, типа 10-15 тактов сэкономить, но зачем такие неочевидные вещи как сворачивание через адрессное пространство давать новичкам в примерах - не понимаю. Может по- человечески просто прочитать VicVectAdddr (в Атмеле он похоже как-то обозван)

А по-моему, все очевидно и нормально. Даже трюком это обозвать язык не поворачивается. Можно добавить комментарий типа: "Читаем VicVectAddr/AIC_IVR", если это так смущает.

[DASM]

угу. читаем с минусом с перелетом на 4 Гб. А вот в новых ARM64 звиняйтте - код измениться. Это именно трюк, а никак иначе

[aaarrr]

Если это трюк, то зачем производители упорно кладут VIC/AIC в последние 4 килобайта адресного пространства?

[DASM]

Это их проблемы. Я не говорю Запрещенный трюк. Я говорю, что это прием, не приспособленный для тренингов студентов, и все. Мне самому этот трюк не нравится, хоть и не студент - он непереносимый. Ну да о чем спорим ? Нравится - пользуйте. Я не пользую, потому что часто атмель с филипсом меняю. Вообще еще раз спасибо Юрию - с TNkernel я вообще половину проблем забыл. Остались только личные.

[aaarrr]

Да я и не навязываю этот "трюк" никому. Просто метод общепринятый.

Я не пользую, потому что часто атмель с филипсом меняю.

Так часто, что одно значение поменять трудно? Не верю.