Здравствуйте форумчане!

Посоветуйте способ выхода из прерывания FIQ в микроконтроллере ADuC702x (ядро ARM7TDMI) на адрес нужной функции.
Из прерывания FIQ вызывать эту функцию не хочу, так как она по времени выполнения занимает порядка 30 мс, к тому же в процессе ее выполнения
может произойти прерывание от монитора напряжения питания в случае возникновения которого необходимо корректное остановка работы микроконтроллера.
Если у кого-то есть такой опыт, прошу поделиться примером кода. Использую в проекте Keil.

А что, разрешение прерывания в обработчике и мутекс для запрета повтороного входа в ту же функцию не помогает?

Я так понимаю, что в случае вызова нужной мне функции из FIQ, работа контроллера прерываний будет восстановлена только после выхода из FIQ.
Мне необходимо максимальная реакция микроконтроллера на прерывание, поэтому установка флага в прерывании с последующей его проверкой в основном цикле программы не устраивает. Хотелось бы завершить прерывание переходом не в точку, предшествующую его возникновению, а на адрес нужной мне функции. Когда-то давно еще на архитектуре 8051 это было возможно путем манипуляции со стеком при помощи ассемблерных инструкций. Я думаю, что и на архитектуре ARM7TDMI это возможно....

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

Когда вы попадает в FIQ прерывание, у вас снимается флажок реакции на прерывания, по выходу из FIQ он ставиться снова. Никто вам не мешает, при переходе в вашу функцию из FIQ опять поставить этот флажок.

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

Одна сложность вам надо сделать так чтобы повторно вы опять в FIQ не полетели, за этим просто надо следить.

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

мне помниться что для FIQ был свой флаг, нет? То есть можно просто обычные прерывания разрешить, а FIQ не разрешать. или он все равно забьет обычные и пока он стоит, обычные не вызовутся?

Берёте любую RTOS. Например: uCOS. ЗавОдите высокоприоритетную задачу, которая ждёт события на каком-то мэйлбоксе.
В ISR посылаете сообщение в этот мэйлбокс. Задача просыпается, делает работу и опять уходит на ожидание мэйлбокса. Всё.
Стандартный подход построения задач-обработчиков событий.


В ARM7 всего два внешних прерывания: FIQ и IRQ. У каждого свой флаг и свой бит разрешения.
При срабатывании одного из них, процессор переключается в соотв. контекст (FIQ или IRQ) со своим стеком. При входе в FIQ, насколько помню, автоматом запрещается IRQ.
Как правило - прерывание от любой периферии можно направить на любой из входов: FIQ или IRQ. Так что - прерывание любой периферии может быть как FIQ так и IRQ (по крайней мере в LPC23xx).

У меня алгоритм работы устройства довольно простой - после возникновения прерывания FIQ максимально быстро перейти к функции регистрации данных с АЦП (записать данные в массив), затем записанный массив данных перезаписать в FLASH память и выключить прибор. Но в процессе регистрации возможна ситуации срабатывания монитора напряжения питания (из-за разряда батареи). В этом случае мне необходимо остановить процесс регистрации и завершит программу с установленным флагом в FLASH 'сбой напряжения питания'. В данный момент функцию регистрации я вызываю из FIQ, поэтому если происходит сбой по напряжению питания я теряю зарегистрированные данные и флаг с информацией о сбое напряжения питания тоже не устанавливается.

Зачем всё на FIQ повесили??? Прикладные ISR - расположите на IRQ, а монитор питания - на FIQ. Тогда он прервёт любой обработчик IRQ.

Выбрал FIQ потому, что фоновая задача выполняется на низкой тактовой частоте ядра, а FIQ в ADUC702x обеспечивает аппаратное переключение на максимальную частоту тактирования ядра при возникновении прерывания FIQ. У прерывания IRQ такой возможности нет, а значит реакция на прерывание гораздо медленнее происходит.

А если в фик поставить флаг новые данные, а данные пихнуть в буффер, а всю обработку дальше в основном цикле? Или опять беда с малой тактовой вне?. Кстати переход с частоты на частоту разьве не требует ожидания плл?

Нужные биты в PLL устанавливаются аппаратно, после выхода из FIQ устанавливаются в исходное состояние. Ждать выхода PLL на режим не нужно. Может стоит попробовать ваше предложение на практике. Спасибо.

Т.е. во флеш пишите из прерывания?? Знаете, сколь по длительности запись идет?? А прерывать запись флеши далеко не в каждом контроллере разрешается.


Странно, почти везде требуется время...

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

Запись во внутреннюю флэш это вещь такая... но с другой стороны для нее все равно надо прерывания запрещать в 90% так что можно и из прерывания это делать они будут автоматом запрещены... без запрета проц вроде не просто флэш запорит, а вообще повиснуть может, нет?

Что мешает в обработчике IRQ сделать то же самое программно?
И что именно там делается с частотой аппаратно?: включается и разгоняется PLL или меняется источник тактирования (PLL/внутренний RC) или просто меняется делитель тактовой перед CPU?
Если первое - то время стабилизации PLL довольно велико и много больше времени входа в любой ISR.
Если второе или третье - то программно переключить источник (при условии, что он уже работает и готов) или изменить делитель тактовой CPU дело одной-двух записей в регистры на входе в обработчик IRQ.
Если Вы не вынесете монитор питания в FIQ, а прочие прерывания - в IRQ, а всё повесите на FIQ, то новый FIQ монитора у Вас не вызовется никак до окончания обработки текущего ISR
(у Вас наверное и другие ISR в системе есть?). Ну если только не предпринять каких-то хитрых манипуляций с режимами работы CPU.

Да и вообще - говорить о скорости реакции на прерывание, учитывая какую Вам работу на сделать по его обслуживанию (работа с ADC, запись флешь) смешно.
Она будет несравнима мала по сравнению со временем доступа к флешь.
Флешь у Вас кстати какая? SPI или ...?
А учитываете, что если сработал монитор, а у вас уже идёт, не дай бог, операция стирания, сколько придётся ждать?
Может всё-таки Вам лучше для записи событий монитора поставить батарейное ОЗУ или FRAM?


Заменить на MSP430 из серии с FRAM-памятью
Там что запись в ОЗУ, что во FRAM - никакой разницы. Не хватает ОЗУ - отрезал от памяти программ скока надо

Нет, FLASH пишется уже не из прерывания, во время записи прерывания запрещены все. Вот такие контроллеры ADI делает, ждать выхода PLL на режим не нужно.



АЦП должно регистрировать сигнал который вызвал срабатывание компаратора и прерывание FIQ. Фронт сигнала достаточно крутой, поэтому задержки начала регистрации сигнала приведут к потере информации о форме сигнала. При возникновении FIQ в регистре PLL аппаратно сбрасываются биты, задающие коэффициент умножения, так что при в входе в функцию-обработчик FIQ контроллер работает уже на максимальной частоте (впрочем эту возможность можно отключить в файле конфигурации МК), источник тактирования не меняется - всегда работает от собственного RC генератора 32768 Гц. PLL у МК ADUC какая-то хитрая - необходимости ждать выхода PLL на режим не нужно (в документации про это нет информации, да и соответствующих бит в регистрах тоже нет). Запись во FLASH осуществляется после окончания регистрации, при этом используется собственная FLASH память МК. Стирание FLASH заранее - при подготовке прибора к работе. Прибор очень миниатюрный - диаметр 11 мм, высота порядка 15 мм :-), поэтому схемотехнической мысли растекаться особенно некуда :-)?

ну так кто вам мешает руками этот делитель перебросить? У вас ПЛЛ всегда настроена и шарахает, потому и ждать не надо, просто делитель перебрасывается и всех делов.

Ну в общем я не вижу противоречий и с переходом в фик. Зачем вам после прерывания и снятия данных обязательно сразу же их записывать. При штатной работе задержка записи ни на что не повлияет, она будет порядка миллисекунд, а при аварии уже не важно что там было, ИМХО

я бы предложил сделал так:
Когда появляется прерывание FIQ вы снимаете данные (очевидно вы снимаете какую-то кривую) и пихаете ее в массив RAM и выходите из прерывания с флажком есть данные.
В основном цикле вы по флажку есть данные пихаете их во flash, процедуры проверки флажка можно поставить сколь угодно часто в основном цикле, потому задержки почти не будет.
Чтобы не терять данные можно сделать 2 буффера. то есть один стоит ждет данные, а другой готов для сохранения во флэш, тогда даже если будет 2 прерывания подряд не успев добраться до процедуры записи ничего не потеряется. А можно сделать кольцевой буффер на большее число массивов, и все будет хорошо и красиво.

Как уже сказал ув. Golikov A., в прерываниях FIQ и монитора питания не нужно делать никакой работы - просто поставить флажки (т.е. - активизировать фоновую задачу).
А в фоновой задаче выполнять все чтения АЦП/сохранения во флешь. Всё равно если у вас уже идёт запись во флешь, то пока она не закончится, данные монитора питания Вы не запишете.
В фоновой задаче, после обнаружения флажка, можно программно переключить делитель PLL на макс. частоту.

А вообще - по-моему раз у Вас должна захватываться какая-то осциллограмма с АЦП по сигналу аварии, то мне кажется начинать её сохранять после события уже поздно.
Наверняка нужна какая-то предыстория. Поэтому думаю - АЦП должно всегда работать, писать поток данных в кольцевой буфер, а по сигналу аварии защёлкнуть позицию буфера
(за N отсчётов до события), после защёлкивания захватить ещё сколько-то данных и записать их во флешь.
В нашем устройстве тоже как раз должен делаться подобный захват осциллограммы по одному из сигналов события. С предысторией. И кольцевой буфер у нас к тому-же в энергонезависимой памяти.


Это Вы про мой совет использовать FRAM?
Так я вообще-то имел в виду, что у TI есть серия MSP430FRxxx - там вместо флешь в качестве энергонезависимой памяти используется FRAM. Так что никаких доп. элементов паять не нужно.
И код и данные (журнал событий), если их не много, можно хранить в ней. И корпус очень миниатюрный.
И алгоритм получается очень простой: пишете поток данных с АЦП непрерывно в кольцевой буфер во FRAM (буфер размером N+M, где N - размер предыстории события, M-размер послеистории события).
После возникновения события, в ISR выставляете флаг==M, в фоновой задаче видите если флаг установлен - декрементируете его с каждым записанным в кольцо сэмплом, после обнуления счётчика останавливаете запись. Если нужна возможность регистрации неск. событий - после защёлкивания текущего буфера и исчерпания M, не останавливаете поток записи в кольцо, а просто - переключаетесь на второй кольцевой буфер, третий и т.п.
И при наличии FRAM никаких проблем с занятостью её текущей записью при возникновении аварии монитора питания нет - можете хоть сразу в ISR и записать что надо во FRAM.

Да и тактирование в MSP430 очень удобно сделано:
Запускаете АЦП с тактированием от какого-то низкочастотного источника, с записью потока через DMA. Усыпляете CPU. Высокочастотный RC тактировавший ядро отключается, потребление падает до неск. мкА.
При возникновении прерывания события или монитора питания, ядро пробуждается, его ВЧ RC-генератор (DCO) быстро запускается и во время выполнения ISR работает на высокой частоте.
При выходе из ISR буквально одной командой можно выставить состояние завершения ISR: вернётся он в сон или продолжит выполнение уже фоновой задачи на полной частоте.
Т.е. - CPU будет почти всё время спать изредка просыпаясь при завершении очередного блока DMA, для его перепрограммирования и для обслуживания событий компаратора и монитора питания.

Что-то мне говорит что ADuC - это фигня со встроенной АЦП... да еще какой-то хитро много канальной или многодиапазонной. Это же для всяких мультитесторов спец проц да?

и jcxz прав, как он предлагает, еще лучше. АЦП просто долбит по кругу и сохраняет в кольцевой буфер, а по событию оно просто до сохраняет хвост данных и пихает это дело во флэш. В такой организации у вас от прерывания события надо просто поставить флажки и все. Частота АЦП связана с основной частотой проца? Можно ее всегда запустить на максимуме?

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

В MSP430FRxxx FRAM тоже как обычная ОЗУ - так же в ней переменные объявляешь и так же модифицируешь как хочешь - никакой разницы с ОЗУ, только после выключения сохраняет данные.

ну учитывая габариты не думаю что там много место под еще батарею. FRAM - реальное решение, тоже делал на фрам озу для дата логера.

У рассматриваемого ADUC7021 есть одно хорошее качество - корпус QFN40 размером 6х6 мм. Есть новые контроллеры на Cortex-M0+ c еще меньшим корпусом QFN32 и всеми наворотами включая DMA. Но руководство возлюбило ADUCи, поэтому приходится крутиться на этой МК.



Если бы в ADUC было DMA, так бы и сделал. Но там его нет и с АЦП приходится работать программно, а чтобы успевать обрабатывать поступающие данные и кольцевой буфер нужна частота ЦПУ порядка 10 МГц. Поэтому пишу кривую без предыстории, вернее с предысторией но с очень низкой частотой дискретизации на минимальной тактовой частоте ЦПУ.

Я так понимаю, что эта FRAM - разновидность EEPROM, а след. у нее есть кол-во циклов перезаписи, после которого начинаются "чудеса"...Или я что-то путаю??



"Очень низкая" это сколько?

частота ЦПУ 300 кГц, частота пробуждения ЦПУ - 1 Гц, между пробуждениями ЦПУ находится в режиме STOP

да, но оно очень большое 10^5 а бывает и больше сильно

Если идет постоянная и интесивная запись, то 100000 быстро закончатся...



Мне все-таки одно не понятно из задачи ТС, это то, зачем нужно так быстро реагировать на сигнал монитора питания? Непонятно то, что даст такая скорость? Батарея вдруг вот так, за 30 мсек не разрядится, и вполне можно, просто зафиксировав факт сработки монитора питания, "неспеша" записать показания и отключить контроллер...

FM23MLD16 (8 Мбит)
10^14 циклов перезаписи, малюсенькая, я подобную гонял для RAM датологгера, писал кольцевые буферы в нее, если питание слетало буфер оставался...


А скорость реакции, думаю как обычно в таких делах никто не знает сколько она должна, потому закладываются на чем лучше тем больше

MSP430FR57xx: корпуса от VQFN24 до VQFN40. Так что и здесь - получше ADUC
Выбор элементной базы и обоснование этого выбора, имхо - это прерогатива разработчика.
Неужто начальство такое невменяемое, что не смотря ни на какие сравнительные характеристики просто хочет потому что хочет???


А зачем их обрабатывать? Пока не наступило событие Вашего компаратора, их не надо обрабатывать. Писать и писать поверх. Обрабатывать только при наступлении события.


Вообще-то не 10^5, а 10^15, а это, если писать с частотой 1МГц, на неск. десятилетий непрерывной записи хватит. К тому-же там указано, что это теоретический предел, так как в реальности состояние износа достигнуто не было никогда.
К тому-же во FRAM (в отличие от Flash) минимальной записываемой единицей является байт. Поэтому в случае записи кольцевого буфера, кол-во циклов перезаписи можно умножить на размер кольцевого буфера.


Это совершенно другой тип ячейки памяти. Технологически. Где-то пишут: "ferroelectric random access memory", где-то: "память на сегнетомагнетиках".


Какие требования по потреблению устройства?


Монитор питания обычно подразумевает, что есть источник (LDO или импульсник) понижающий Uвх до Uвых защищаемого узла.
Детектор пропадания питания работает по Uвх. Соответственно - время между выставлением сигнала аварии питания и снижением Uвых до уровня срабатывания супервизора питания защищаемого узла определяется энергией, запасённой в конденсаторах.
Т.е. - ёмкостью кондёров на Uвх и Uвых, разницей Uвх-Uвых и током потребления защищаемого узла.
И это время должно рассчитываться на этапе проектирования монитора питания и соответствовать заданному в ТЗ.
А "чем больше тем лучше" - это радиолюбительство

я вас умоляю...



похоже что тут будут оценены бюджет потребления и величина емкостей?

В ADUC7021 даже есть кусок программируемой логической матрицы, это проц для мультиметров ИМХО, а не для миниатюрных логеров процесса. Так что чем лучше тем больше и никакого радиолюбетельства)...

кстати в первых MSP430F149(449) фрамке как раз ставили 10^5, это потом появились значения 10^14, кстати 10^15 мне не попадалось, наверное взяли очередной рубеж на тестах и увеличили на порядок

Может это была всё-таки EEPROM?
Иначе - какой смысл тогда во FRAM (более дорогой) если кол-во перезаписей меньше, чем обычно бывает в EEPROM?
Кстати: в даташите на серию MSP430FR57xx указано, что с буквой 'F' - это флешевые чипы, 'FR' - FRAM, 'G' - Flash+FRAM. Так что MSP430F149 это похоже первый случай.
10^15 указано конкретно для MSP430FR57xx.
Может у них там стоит какой-то тестовый девайс, который непрерывно пишет и пишет во FRAM. И вот прошло ещё неск. лет с тех пор как писали 10^14 и теперь уже этот девайс преодолел рубеж 10^15,
и теперь уже в даташитах можно гордо писать 10^15

Да верно, это я чего-то напутал. MSP430F149 просто были с EEPROM, FRAM в том нашем проекте была внешняя