FIQ/IRQ, Некоторые неувязки ... в голове :) Опции

[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]

Вызывается типа так:
if(Flag.EnShow) VICSoftInt = (1<<SHOW_INT);
Сбрасывается так:
VICSoftIntClear = (1<<SHOW_INT);
VICVectAddr = 0;

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

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

Причина редактирования: Излишнее цитирование.

[SasaVitebsk]

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

Спасибо. А можно узнать почему? У меня из этого места только FIQ вызывается. соответственно мне необходимо сделать примерно так:

Код

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

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

Вот подонки.
И зачем тогда линкер спрашивает у меня размер стека FIQ?
И как это сделать? Если Вас не затруднит приведите примерчик инициализации стека.

[GetSmart]

Может долго сидит в совтовом прерывании потому, что из него вызываются ещё и другие прерывания? Ну там UART0 например.

Спасибо. А можно узнать почему? У меня из этого места только 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 возврат из прерывания

Вот подонки.
И зачем тогда линкер спрашивает у меня размер стека FIQ?
И как это сделать? Если Вас не затруднит приведите примерчик инициализации стека.

ЫЫЫ
Я сам на эти грабли встал когда впервые 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]

Работаю под 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 не нужен.

__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

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

Листинг обработчика IRQ хотя бы приведите. Это кусок файла *.lst, в котором лежит обработчик IRQ.

Сообщение отредактировал GetSmart - May 22 2009, 13:09

[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 подключённый к проекту

Прикрепленные файлы

 cstartup.zip ( 2.04 килобайт ) Кол-во скачиваний: 26
 cstartup.zip ( 2.04 килобайт ) Кол-во скачиваний: 17

 

[zltigo]

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

[SasaVitebsk]

А листинг 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

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

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

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

Тем не менее принципиально работать должно со всеми типами. Всё сделано в рамках стандарта.

Причина редактирования: Уменьшение видимого размера цитаты исходника.

[zltigo]

Прога переносилась с 8-ми битника. И там всё это было естественно.

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

Он довольно приличный по объёму.

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

[GetSmart]

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

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

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

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

Продолжительность его слишком велика. Я сейчас с него выкинул почти всё. Оно должно обрабатываться 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 Кстати, еще оптимально, чтобы все влезло в банковые регистры, без стека. Огласите, кстати, количество тактов, отпускаемое на FIQ по Вашим расчетам.

[SasaVitebsk]

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

Синий это тестовый для IRQ. Он демонстрирует вход и выход из IRQ. При том, что там сейчас ничего нет, то должен начинаться сразу после завершения широкого импульса FIQ и закончится практически сразу же. Но нарушение работы может произойти только если бы это прерывание по ширине превысило 24 импульса FIQ. Этого не происходит. Интересно такжн что если чтото я вставляю в IRQ - длина его не меняется.

[GetSmart]

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

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

Кстати, какая частота FIQ ? (минимальный период)

[SasaVitebsk]

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

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

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

По измерению FIQ исполняется приблизительно 120 мкс. Меня это вполне устраивает.
Кадр = 16.7мс за кадр выполняется 24 прерывания FIQ. соответственно это составляет 17% времени.
Причина в работе с портами. Был бы FIO было бы значительно меньше.

[Rst7]

С трудом понимаю Вас. Давайте, наверное, сделайте как надо - самой первой командой (оператором) в FIQ лапа=1 и самой последней - лапа=0 и осциллограмы в студию.

[SasaVitebsk]

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

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

[Rst7]

Но почему?????

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

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

Я знал Больно симптомы классические - торможение менее приоритетного уровня...

[SasaVitebsk]

Я знал Больно симптомы классические - торможение менее приоритетного уровня...

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

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

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

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

2) Здесь синим обозначено IRQ прерывание.
Нулём - начало.

Эскизы прикрепленных изображений

 

[Rst7]

Понятно что ничего не понятно. По отдельностям вроде бы ахинеи не наблюдается. Давайте целиком проект. Точнее, минимально нерабочий вариант. Либо чтото упускаем, либо во взаимодействии модулей софта кроется зопа.

[SasaVitebsk]

Собрал минимальный проект, готовый к отправке.
Правда не резал старый, а создавал новый.
Работает как положено.

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

Пока всем большое спасибо и извиняйте за потраченное время / силы / нервы.

[SasaVitebsk]

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

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

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


Я вывожу код строки. Объявление в файле - такое:
#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: Больно не бейте.

Эскизы прикрепленных изображений

 

[SasaVitebsk]

PS: Всё разобрался. Действительно ночью переклинило. Вот баран.
Всем огромное спасибо.

Особенно GetSmart - он вселил в меня уверенность что всё должно работать, а дело в обычном хомуте.
Спасибо также Rst7.

[GetSmart]

А чего было то?

[zltigo]

Moderator:
Темы разделил.
http://electronix.ru/forum/index.php?showtopic=63310&hl=