Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: FIQ/IRQ
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > ARM, 32bit
SasaVitebsk
Явного описания нигде не нашёл. Видимо считается "само-сабой разумеющимся". Тем не менее для меня это не "само-сабой".

Исходя из архитектуры, а также из того, что я вижу под J-LINKом в прерывании IRQ разрешено прерывание FIQ - я делаю вывод о том, что прерывание FIQ должны коректно вызываться/обрабатываться как из main так и из IRQ прерываний. Тем не менее у меня какие-то неувязки. Почему-то время обработки прерывания IRQ значительно завышено. Короче что-то я не так понимаю.

Работаю под IAR.
В IAR прерывание FIQ объявляется:
__fiq __arm void FIQ_Handler()

IRQ прерывание объявляется
__arm __irq static void ShowActive(void)

Прерывание FIQ таймерное. Вызывается и завершается коректно. Никаких хомутов не вижу.
Прерывание IRQ совтовое. Вызывается из FIQ корректно - это я чётко вижу по осциллографу.
Вызывается типа так:
if(Flag.EnShow) VICSoftInt = (1<<SHOW_INT);
Сбрасывается так:
VICSoftIntClear = (1<<SHOW_INT);
VICVectAddr = 0;

Продолжительность его слишком велика. Я сейчас с него выкинул почти всё. Оно должно обрабатываться 1-2 прерывания FIQ, но на самом деле обрабатывается значительно больше и завершение связано каким-то образом с прерыванием FIQ.

Буду сам копаться, но может кто подскажет что?
Andy Mozzhevilov
Крайне мутное описание и куча "инженерных" понятий - слишком велика, значительно больше и т.п.
Один вопрос - какой смысл активировать IRQ из FIQ, ведь при активном FIQ прерывания IRQ аппаратно запрещаются ядром. В прерывание IRQ вы должны попасть только после выхода из FIQ.
SasaVitebsk
У меня идут быстрые FIQ прерывания. С каждым 24 (в плане 56) прерыванием должно запускаться IRQ. Они должны быть жёстко связаны.

Чтобы "не темнить", опишу. Идёт регенерация картинки.
FIQ прерывание отображает картинку построчно. В начале кадра вызывается IRQ прерывание. IRQ прерывание подготавливает новую картинку в копию экрана. FIQ в начале экрана переключат отображаемую копию.

Ломать структуру проекта - не буду - не надо предлогать. Всё прекрасно работает на AVR. При введении цвета и увеличении количества градаций яркости на цвет, увеличился объём экрана/ объём вычислений при обновлении. В связи с этим хочу проект перенести на ARM. С сохранением совместимости и прочего.


IRQ прерывание вызывается после завершения FIQ (так и задумано). После этого идёт IRQ прерывание и на фоне его работают FIQ прерывания регенерации картинки. Длительность IRQ плавает в зависимости от сложности объектов изображённых на картинке и заполнении экрана.
Andy Mozzhevilov
И что конкретно не работает? Какое время у вас выполняется FIQ? Какое время выполняется IRQ с запрещенными FIQ? С разрешенными FIQ? Какая частота следования FIQ?
GetSmart
Цитата(SasaVitebsk @ May 22 2009, 13:15) *
Вызывается типа так:
if(Flag.EnShow) VICSoftInt = (1<<SHOW_INT);
Сбрасывается так:
VICSoftIntClear = (1<<SHOW_INT);
VICVectAddr = 0;

В представленном здесь коде - всё нормально. Приводите более полный код. Может станет яснее. Внутри IRQ перед VICSoftIntClear нужно запрещать прерывания.

При использовании FIQ нужно "ручками" инициализировать его стек. Автоматически IAR в своём startup этого не делает.
SasaVitebsk
Цитата(GetSmart @ May 22 2009, 15:14) *
В представленном здесь коде - всё нормально. Приводите более полный код. Может станет яснее. Внутри IRQ перед VICSoftIntClear нужно запрещать прерывания.

Спасибо. А можно узнать почему? У меня из этого места только FIQ вызывается. соответственно мне необходимо сделать примерно так:
Код
__disable_fiq();
VICSoftIntClear = (1<<SHOW_INT);
VICVectAddr = 0;
__enable_fiq();


Цитата
При использовании FIQ нужно "ручками" инициализировать его стек. Автоматически IAR в своём startup этого не делает.

Вот подонки. smile.gif
И зачем тогда линкер спрашивает у меня размер стека FIQ?
И как это сделать? Если Вас не затруднит приведите примерчик инициализации стека.
GetSmart
Может долго сидит в совтовом прерывании потому, что из него вызываются ещё и другие прерывания? Ну там UART0 например.

Цитата(SasaVitebsk @ May 22 2009, 17:29) *
Спасибо. А можно узнать почему? У меня из этого места только FIQ вызывается. соответственно мне необходимо сделать примерно так:
Код
__disable_fiq();
VICSoftIntClear = (1<<SHOW_INT);
VICVectAddr = 0;
__enable_fiq();

Не, не так. Я имел ввиду только запрет IRQ. Так:
Код
__disable_irq();  // запрет только irq !!!
  VICSoftIntClear = (1<<SHOW_INT);
  VICVectAddr = 0;
// __enable_irq();  // это делать не нужно
}  // - сразу после VICVectAddr = 0 возврат из прерывания


Цитата(SasaVitebsk @ May 22 2009, 17:29) *
Вот подонки. smile.gif
И зачем тогда линкер спрашивает у меня размер стека FIQ?
И как это сделать? Если Вас не затруднит приведите примерчик инициализации стека.

ЫЫЫ smile.gif
Я сам на эти грабли встал когда впервые IRQ применил. Линкер спрашивает чтобы просто кусок памяти выделить. А вот компилер не инициализирует указатель SP для FIQ на этот блок памяти. Поэтому его надо ручками инициализировать.
SasaVitebsk
Оставил в прерывании следующее:

Код
__arm    __irq    static void    ShowActive(void)
{
// объявление переменных
OUT_EN_RS485; // Для отладки

__disable_fiq();
VICSoftIntClear = (1<<SHOW_INT);
VICVectAddr = 0;
__enable_fiq();
// TST_CLR;

//******************************************
IN_EN_RS485;
}



6.5 мсек как с куста. Столько же сколько и при работе с нормальной прогой. Причём странная связь завершения прерывания IRQ с прерыванием FIQ.

Может из-за инициализации стека?
Неизвестно как оно вообще без этого работает.
GetSmart
Цитата(SasaVitebsk @ May 22 2009, 13:15) *
Работаю под IAR.
В IAR прерывание FIQ объявляется:
__fiq __arm void FIQ_Handler()

IRQ прерывание объявляется
__arm __irq static void ShowActive(void)

О!!! Косяк нашёл!

IRQ обработчик надо объявлять вот так:
__arm __irq __nested void ShowActive(void)

То есть обязательно __nested. Если конечно внутри этого прерывания разрешаются другие IRQ. Если же другие не разрешаются, то нужно быть уверенным, что для алгоритма этого IRQ хватит стека IRQ. Если в объявлении обработчика используется __nested, то сам обработчик работает в основном на стеке основной программы, а из стека IRQ потребляет только 3-4 DWORDа кажется, то есть для __nested IRQ большой стек IRQ не нужен.

Цитата(SasaVitebsk @ May 22 2009, 17:40) *
__arm __irq static void ShowActive(void){

А без "статика" не работает?

SasaVitebsk, кастрируйте проект до минимума. Если будут такие же аномалии выкладывайте сюда, я проверю более конкретно. Гадать надоело.
SasaVitebsk
__nested я не ставил. Других IRQ нет. Они все равноправны. Я хотел бы чтобы вызывался только FIQ из IRQ.

Прошу вас ещё раз привести пример инициализации стека в FIQ. Может в этом загвоздка. Static убрал.
GetSmart
Ну вот кусок для инициализации стеков.
CODE
MODULE stk_startup

SECTION IRQ_STACK:DATA:NOROOT(2)
SECTION FIQ_STACK:DATA:NOROOT(2)
SECTION CSTACK:DATA:NOROOT(2)

SECTION .text:CODE:NOROOT(2)
EXTERN ?main
PUBLIC ?cstartup
ARM

?cstartup:

; Initialize the stack pointers.
; The pattern below can be used for any of the exception stacks:
; FIQ, IRQ, SYS.
; The USR mode uses the same stack as SYS.
; The stack segments must be defined in the linker command file,
; and be declared above.
;
; --------------------
; Mode, correspords to bits 0-5 in CPSR
MODE_BITS DEFINE 0x1F ; Bit mask for mode bits in CPSR
USR_MODE DEFINE 0x10 ; User mode
FIQ_MODE DEFINE 0x11 ; Fast Interrupt Request mode
IRQ_MODE DEFINE 0x12 ; Interrupt Request mode
SVC_MODE DEFINE 0x13 ; Supervisor mode
ABT_MODE DEFINE 0x17 ; Abort mode
UND_MODE DEFINE 0x1B ; Undefined Instruction mode
SYS_MODE DEFINE 0x1F ; System mode

MRS r0, cpsr ; Original PSR value

BIC r0, r0, #MODE_BITS ; Clear the mode bits
ORR r0, r0, #FIQ_MODE ; Set FIQ mode bits
MSR cpsr_c, r0 ; Change the mode
LDR sp, =SFE(FIQ_STACK) ; End of FIQ_STACK

BIC r0, r0, #MODE_BITS ; Clear the mode bits
ORR r0, r0, #IRQ_MODE ; Set IRQ mode bits
MSR cpsr_c, r0 ; Change the mode
LDR sp, =SFE(IRQ_STACK) ; End of IRQ_STACK

BIC r0 ,r0, #MODE_BITS ; Clear the mode bits
ORR r0 ,r0, #SYS_MODE ; Set System mode bits
MSR cpsr_c, r0 ; Change the mode
LDR sp, =SFE(CSTACK) ; End of CSTACK

;
; Add more initialization here
;

; Continue to ?main for C-level initialization.

LDR r0, =?main
BX r0

END


Цитата(SasaVitebsk @ May 22 2009, 17:54) *
Прошу вас ещё раз привести пример инициализации стека в FIQ. Может в этом загвоздка. Static убрал.

Листинг обработчика IRQ хотя бы приведите. Это кусок файла *.lst, в котором лежит обработчик IRQ.
SasaVitebsk
CODE
1373 //__arm __nested __irq static void ShowActive(void)// Исполнение комманд

\ In section .text, align 4, keep-with-next
1374 __arm __irq void ShowActive(void)// Исполнение комманд
1375 {
\ ShowActive:
\ 00000000 0F002DE9 PUSH {R0-R3}
1376 uint8_t i, c, x1,y1,x2,y2,xt,yt,Color2, *adrnpict;
1377 int16_t x,y;
1378 int16_t volatile TekTm;
1379 uint16_t l,ll;
1380 #ifdef DEBUG_SPEED
1381 uint16_t MaxT; // %%%% Для отладки
1382 #endif
1383 uint8_t static AdrMstToSlv=0; // Адрес передачи структуры Status
1384
1385 //******************************************
1386 OUT_EN_RS485;
\ 00000004 4E02A0E3 MOV R0,#-536870908
\ 00000008 A00B80E3 ORR R0,R0,#0x28000
\ 0000000C 4018A0E3 MOV R1,#+4194304
\ 00000010 001080E5 STR R1,[R0, #+0]
1945 VICSoftIntClear = (1<<SHOW_INT); // Сбросить совтовое прерывание
\ 00000014 E320E0E3 MVN R2,#+227
\ 00000018 F02EC2E3 BIC R2,R2,#0xF00
\ 0000001C 0230A0E3 MOV R3,#+2
\ 00000020 003082E5 STR R3,[R2, #+0]
1946 VICVectAddr = 0;
\ 00000024 0030A0E3 MOV R3,#+0
\ 00000028 143082E5 STR R3,[R2, #+20]
1947 // TST_CLR;
1948
1949 //******************************************
1950 IN_EN_RS485;
\ 0000002C 081080E5 STR R1,[R0, #+8]
1951 }
\ 00000030 0F00BDE8 POP {R0-R3}
\ 00000034 04F05EE2 SUBS PC,LR,#+4 ;; return
\ 00000038 REQUIRE _A_VICSoftIntClear
\ 00000038 REQUIRE VICVectAddr
\ 00000038 REQUIRE _A_IOSET
\ 00000038 REQUIRE _A_IOCLR


Спасибо за помощь.
Разбираюсь пока


Проверил CSTARTUP
Стек инициализирован
Rst7
А листинг FIQ?

Может там что-то не так?
SasaVitebsk
Вот cstartup подключённый к проекту
zltigo
Цитата(SasaVitebsk @ May 22 2009, 16:50) *

Листиг не читал, с проблемой не разбирался, но не по делу - случайно зацепился взглядом за обилие неестесвенных 8 и 16 бит переменных. Надо изживать в себе восьмибитовики и использовать в большинстве случаев портируемые типы (хоть свои, хоть С99 ) переменных со смыслом "не менее 8bit", не "менее 16bit"
SasaVitebsk
Цитата(Rst7 @ May 22 2009, 16:51) *
А листинг FIQ?
Может там что-то не так?

Он довольно приличный по объёму.
Пока кину начало и конец.
Если с Вашей помощью ничего не найду, то урежу до немогу и выложу проект

CODE
799 __fiq __arm void FIQ_Handler() // ╬ЄюсЁрцхэшх ърЁЄшэъш Master, Slave
800 {
\ FIQ_Handler:
\ 00000000 04E04EE2 SUB LR,LR,#+4
\ 00000004 FF402DE9 PUSH {R0-R7,LR}
\ 00000008 04D04DE2 SUB SP,SP,#+4
\ 0000000C 68039FE5 LDR R0,??FIQ_Handler_0 ;; MinX + 20
\ 00000010 000090E5 LDR R0,[R0, #+0]
\ 00000014 010010E3 TST R0,#0x1
\ 00000018 0C00001A BNE ??FIQ_Handler_1
\ 0000001C E014A0E3 MOV R1,#-536870912
\ 00000020 A01B81E3 ORR R1,R1,#0x28000
\ 00000024 001091E5 LDR R1,[R1, #+0]
\ 00000028 400B11E3 TST R1,#0x10000
\ 0000002C 0700001A BNE ??FIQ_Handler_1
801

.....
897 if(Flag.RMaster)
\ 0000035C 010010E3 TST R0,#0x1
898 {
899 T0IR = (unsigned)-1; // сбросить флаги прерываний таймера
\ 00000360 900B4912 SUBNE R0,R9,#+147456
\ 00000364 0010E013 MVNNE R1,#+0
900 }
901 else
902 {
903 EXTINT=0x1; // Разрешить прерывание по INT0 (от мастера)
\ 00000368 ........ LDREQ R0,??DataTable5 ;; 0xe01fc140
\ 0000036C 0110A003 MOVEQ R1,#+1
\ 00000370 001080E5 STR R1,[R0, #+0]
904 }
905 // VICVectAddr = 0;
906 }
\ 00000374 04D08DE2 ADD SP,SP,#+4 ;; stack cleaning
\ 00000378 FF80FDE8 LDM SP!,{R0-R7,PC}^ ;; return
\ ??FIQ_Handler_0:
\ 0000037C ........ DC32 MinX + 20
\ 00000380 ........ DC32 Status + 98
\ 00000384 ........ DC32 EkrToPort
\ 00000388 REQUIRE _A_VICSoftInt
\ 00000388 REQUIRE _A_IOPIN
\ 00000388 REQUIRE _A_IOSET
\ 00000388 REQUIRE _A_IOCLR
\ 00000388 REQUIRE _A_S0SPSR
\ 00000388 REQUIRE _A_S0SPDR
\ 00000388 REQUIRE _A_T0IR
\ 00000388 REQUIRE T0MR0
\ 00000388 REQUIRE _A_EXTINT


Цитата(zltigo @ May 22 2009, 16:58) *
Листиг не читал, с проблемой не разбирался, но не по делу - случайно зацепился взглядом за обилие неестесвенных 8 и 16 бит переменных. Надо изживать в себе восьмибитовики и использовать в большинстве случаев портируемые типы (хоть свои, хоть С99 ) переменных со смыслом "не менее 8bit", не "менее 16bit"

Прога переносилась с 8-ми битника. И там всё это было естественно. Тем не менее написано было так, чтобы одна операция обслуживала несколько точек. В связи с этим ожидаемый перенос ядра на 32 бита должен дать увеличение производительности именно за счёт увеличения разрядности. В голове я сделал необходимые изменения в переменных. Уже выровнял всё.

В прерывании по "картинке", пока не начинал, так как придётся вместе с изменениями разрядности менять также базовые процедуры работы с точками. Всё это будет сделано.

Тем не менее принципиально работать должно со всеми типами. Всё сделано в рамках стандарта.
zltigo
Цитата(SasaVitebsk @ May 22 2009, 17:16) *
Прога переносилась с 8-ми битника. И там всё это было естественно.

Это понятно, речь идет о том, что-бы писать оптимально преносимо и с восьмибитовиков без какой-либо специальной правки.
Цитата
Он довольно приличный по объёму.

Полагаю, что для начала уж точно листиг не нужен - исходники читать много удобнее, а листинг без локализации проблемы это верный способ за деревьями леса не увидеть.
GetSmart
Цитата(SasaVitebsk @ May 22 2009, 18:50) *
Спасибо за помощь.
Разбираюсь пока

Обработчик IRQ нормальный. Не может проц долго в нём сидеть. Если только софтовый флаг постоянно устанавливается в FIQ. Хотя даже в этом случае линия OUT_EN_RS485 должна непрерывно (очень часто) дёргаться.

Либо может быть управление залетает в исключение. Обработчиков исключений в cstartup-е нет. Они где-то снаружи непонятно из чего состоят. Из исключения вполне может вызываться FIQ как будто из софтовой IRQ.

Посмотрите ещё нет ли в других местах программы обращения к IN_EN_RS485 и к OUT_EN_RS485. Возможно этот сигнал сигнализирует не только софтовое прерывание, а ещё что-нить.

Цитата(SasaVitebsk @ May 22 2009, 13:15) *
Продолжительность его слишком велика. Я сейчас с него выкинул почти всё. Оно должно обрабатываться 1-2 прерывания FIQ, но на самом деле обрабатывается значительно больше и завершение связано каким-то образом с прерыванием FIQ.

Каким образом связано?

Ещё может быть проблема в том, что внутри FIQ проц долго сидит, то есть дольше чем поступает сигнал от таймера для FIQ. То есть проц постоянно сидит в FIQ. Из-за чего времени не остаётся на выполнение IRQ. Но если в зависимости от условий внутри FIQ кол-во его тактов снизится, то уже после этого IRQ дойдёт до своего конца.
SasaVitebsk
1) Совтовый флаг нормально устанавливается и сбрасывается. Во-первых потому что прога была отлажена и нормально работает на другом проце, а во-вторых потому, что я это вижу J-Linkом.

2) Исключения я не обрабатываю. В некоторых я просто торчу в цикле, а из default просто выхожу.
Это очень возможная причина. Особенно меня настораживает флаг ARMCore1 (бит 3 в VICRawIntr). Он уменя взводится где-то во время инициализации. Что это такое я не нашёл. Больше пока ничего крамольного не вижу.

3) Обращений к RS485 нет, так как я их пока убрал. Точнее RS485 я пока не переписывал. Очень большая разница м/у AVR и ARM. Линию использую как тестовую.

4) Внутри FIQ сидит как раз нормально. Примерно соответствует ожидаемому.

Вставляю 3 картинки.
1. Общая картина
2. вход в прерывание.
Кадр отмечен более широким импульсом синхронизации. Таким обр. на осциллограмме виден правильный вход в IRQ.
3. выход из прерывания.
видно что выход тоже осуществляется после обработки FIQ прерывания.
GetSmart
Что за сигналы жёлтый и синий?

Почему у жёлтого разная ширина? (это FIQ?)
Rst7
Если я правильно понял осциллограмы, запрос FIQ не снимается, в результате IRQ выполнятеся по одной комманде (и сразу происходить опять влет в FIQ). Ищите, почему не снимается запрос - не сбросили флаг, не тот флаг сбрасываете, разрешен еще какой-то источник запросов, про который забыли и т.д.

PS Кстати, раз у Вас на FIQ сидит регулярное прерывание, не делайте там больше никаких лишних действий. Пусть будет только Software-DMA smile.gif Кстати, еще оптимально, чтобы все влезло в банковые регистры, без стека. Огласите, кстати, количество тактов, отпускаемое на FIQ по Вашим расчетам.
SasaVitebsk
Жёлтый это FIQ. Только сигнал не тестовый а реальный синхронизирующий. Там где ширина широкая - начала кадра. Реальная длительность прерывания составляет чуть больше чем широкий импульс. Разный период следования FIQ - это ШИМ, фактически, для
яркости. То есть здесь всё как нужно.

Синий это тестовый для IRQ. Он демонстрирует вход и выход из IRQ. При том, что там сейчас ничего нет, то должен начинаться сразу после завершения широкого импульса FIQ и закончится практически сразу же. Но нарушение работы может произойти только если бы это прерывание по ширине превысило 24 импульса FIQ. Этого не происходит. Интересно такжн что если чтото я вставляю в IRQ - длина его не меняется.
GetSmart
Цитата(SasaVitebsk @ May 22 2009, 22:12) *
Жёлтый это FIQ. Только сигнал не тестовый а реальный синхронизирующий. Там где ширина широкая - начала кадра. Реальная длительность прерывания составляет чуть больше чем широкий импульс. Разный период следования FIQ - это ШИМ, фактически, для яркости. То есть здесь всё как нужно.

Вставьте в начало и в конец FIQ дрыгание ножкой для осциллографа. Чтобы в начале FIQ ножка сбрасывалась, а в самом конце устанавливалась. И приведите осциллограмму.

Кстати, какая частота FIQ ? (минимальный период)
SasaVitebsk
Цитата(Rst7 @ May 22 2009, 20:11) *
Если я правильно понял осциллограмы, запрос FIQ не снимается, в результате IRQ выполнятеся по одной комманде (и сразу происходить опять влет в FIQ). Ищите, почему не снимается запрос - не сбросили флаг, не тот флаг сбрасываете, разрешен еще какой-то источник запросов, про который забыли и т.д.

Почему? Источник FIQ один. И обработчик один. Если бы он не снимался, то мы бы увидели частокол жёлтый. Вроде как красивые импульсы чётко определённые. Период совпадает с расчётами.
А.. Вы про то что он нулём? Так задумано. Это идёт далее на слэйв контроллеры на прерывание. Таким образом синхронизация по строкам/кадрам осуществляется.

Цитата
PS Кстати, раз у Вас на FIQ сидит регулярное прерывание, не делайте там больше никаких лишних действий. Пусть будет только Software-DMA smile.gif Кстати, еще оптимально, чтобы все влезло в банковые регистры, без стека. Огласите, кстати, количество тактов, отпускаемое на FIQ по Вашим расчетам.

По измерению FIQ исполняется приблизительно 120 мкс. Меня это вполне устраивает.
Кадр = 16.7мс за кадр выполняется 24 прерывания FIQ. соответственно это составляет 17% времени.
Причина в работе с портами. Был бы FIO было бы значительно меньше.
Rst7
С трудом понимаю Вас. Давайте, наверное, сделайте как надо - самой первой командой (оператором) в FIQ лапа=1 и самой последней - лапа=0 и осциллограмы в студию.
SasaVitebsk
Цитата(Rst7 @ May 22 2009, 20:11) *
Если я правильно понял осциллограмы, запрос FIQ не снимается, в результате IRQ выполнятеся по одной комманде (и сразу происходить опять влет в FIQ). Ищите, почему не снимается запрос - не сбросили флаг, не тот флаг сбрасываете, разрешен еще какой-то источник запросов, про который забыли и т.д.

Да действительно Вы угадали. Правда по тем осциллограммам это не видно.
Но почему?????
Rst7
Цитата
Но почему?????


Ответ на этот вопрос можно дать, только посмотрев на полноценный исходник. Готовьте пациента на вскрытие. В смысле - минимально возможную зопу в студию.

Цитата
Да действительно Вы угадали. Правда по тем осциллограммам это не видно.


Я знал smile.gif Больно симптомы классические - торможение менее приоритетного уровня...
SasaVitebsk
Цитата(Rst7 @ May 22 2009, 20:56) *
Я знал smile.gif Больно симптомы классические - торможение менее приоритетного уровня...

Неа.
Это я после инвертора посмотрел - баран. А потом пока сообразил. Щас ослиллограмы выложу. Там всё Ок.

1) Жёлтым сигналом идёт сигнал тестовый для FIQ. 1 - длительность прерывания.
Синим, выходной сигнал (синхроимпульс). То что я на предыдущих осциллограммах жёлтым выдавал.

Когда хомутнул, - начал искать причину "зацикливания" FIQ. Заремил кусок прерывания и длительность единицы уменьшилась.
Так что данные - объективные.

Кроме того все времена совпадают с расчётными.

2) Здесь синим обозначено IRQ прерывание.
Нулём - начало.
Rst7
Понятно что ничего не понятно. По отдельностям вроде бы ахинеи не наблюдается. Давайте целиком проект. Точнее, минимально нерабочий вариант. Либо чтото упускаем, либо во взаимодействии модулей софта кроется зопа.
SasaVitebsk
Собрал минимальный проект, готовый к отправке.
Правда не резал старый, а создавал новый.
Работает как положено.

Теперь буду вносить постепенно данные, чтобы выловить момент истины.
Найду - отпишусь.

Пока всем большое спасибо и извиняйте за потраченное время / силы / нервы.
SasaVitebsk
Видимо уже совсем мозги не соображают. Глаз замылился. Надо туда стукнуть чем поприличней.
Такая версия звучала:

В порт выводится значение. Я честно ответил, что я туда ничего не вывожу из других мест. Оказывается это происходит по моему недопониманию. Я и сейчас непонимаю. Или переклинило мозг.

Поясните без обид, что я делаю не так. Мне и так уже стыдно. crying.gif


Я вывожу код строки. Объявление в файле - такое:
#define STR0 19 // Выход дешифратора строки
#define STR1 20 // Выход дешифратора строки
#define STR2 21 // Выход дешифратора строки

Хомут происходит в следующей строке прерывания FIQ
_IOCLR = 7UL<<STR0; _IOSET = (uint32_t)Str_Dec<<STR0; // Вывести в порт E адрес строки

Я пытаюсь обнулить предыдущее значение и вывести новое.
Строка выводится начиная с 20.

Вкладываю Вам скриншот из под J-Link.

Там видно следующее:
В позиции 4 видно что значение Str_Ekr = 1, а адрес его 40009136
В позиции 3 видно, что по адресу ..35 размещена 2, а в 36 - 1
В позиции 2 виден асмовый листинг этого куска, где видно что значение извлекается по адресу r2 со смещением 97. (я не силён в ARM асме. Это я так полагаю)
В позиции 1 видно значение R2 = ...90d4. Если прибавить 97, то получаем ..9135 на калькуляторе. Там как мы видим находится 2.
В позиции 5 видно, что в R12 загрузилась именно эта 2. По листингу далее видно, что её планируется сдвинуть на 19 позиций, в результате чего 1 окажется в бите D20, а не D19 ка бы мне того хотелось на ночь глядя.

Если присмотрется выше позиции 2, то видно что в R12 заносится число 0x380000. Это 7 сдвинутая на 19. Что говорит о том, что STR0 действительно 19, да и ниже видно тоже.

Где я заблуждаюсь.
PS: Больно не бейте. smile.gif
SasaVitebsk
PS: Всё разобрался. Действительно ночью переклинило. Вот баран.
Всем огромное спасибо.

Особенно GetSmart - он вселил в меня уверенность что всё должно работать, а дело в обычном хомуте.
Спасибо также Rst7.
GetSmart
А чего было то?
zltigo
Moderator:
Темы разделил.
http://electronix.ru/forum/index.php?showtopic=63310&hl=
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.