WinAvr в вопросах и ответах

ARV · Сообщение **ARV** » Пт мар 04, 2016 19:21:18

OKF писал(а):Вопрос к ARV. хотя, и не только.))
Нужна быстрая реакция на прерывание. И хотелось что бы вся задача крутилась в прерывании.
Но, т.к. в задаче имеются функции, будет увеличен и пролог, что крайне нежелательно.
Собственно вопрос. Возможно ли что бы прологом/эпилогом были оформлены уже сами функции?
Т.е., что бы этот огромный пролог располагался не с самого начала обработчика?

OKF писал(а):А нет ли возможности принудительно запретить формирование пролога?
Т.е., что бы функции брали на себя эту заботу. Либо "не светить" функции в ISR, что аналогично?
Инлайн, как я понимаю, не гарантирует инлайн на 100%?

если хотите, используйте "голый" обработчик прерываний

Код: Выделить всё

ISR(TIMER0_OVF_vect, ISR_NAKED)

в этом случае компилятор не будет генерировать ни пролог, ни эпилог функции обработчика - делайте, что хотите

если надо, чтобы функция ГАРАНТИРОВАННО инлайнилась, используйте атрибут always_inline

Код: Выделить всё

inline void my_func(void) __attribute__((always_inline)){
//}

учтите, я ответил на ваши вопросы, но что вы там при помощи этих советов накодите, будет целиком на вашей совести

P.S. кстати, static-функции достаточно неплохо инлайнятся автоматически при включении оптимизиции, особенно, если вызываются из одного места

Реклама

OKF · Сообщение **OKF** » Пт мар 04, 2016 20:11:02

ARV писал(а): учтите, я ответил на ваши вопросы, но что вы там при помощи этих советов накодите, будет целиком на вашей совести

P.S. кстати, static-функции достаточно неплохо инлайнятся автоматически при включении оптимизиции, особенно, если вызываются из одного места

ОК. Спасибо.
Пожалуй я смогу выйти из своего затруднительного положения с малой кровью. Для этого нужно оформить все функции в "фиктивном" прерывании. И которое буду вызывать программно перед выходом из основного. Единственный недостаток - потеря 1 вывода чипа.

Реклама

L.O.D

OKF писал(а):Для этого нужно оформить все функции в "фиктивном" прерывании. И которое буду вызывать программно перед выходом из основного.

Неясно, каким образом это избавит код от пролога и эпилога?

OKF писал(а):Единственный недостаток - потеря 1 вывода чипа.

Снова непонятки - как перенос кода из одной процедуры в другую приводит к потере "ноги" в карте занятости I/O?

OKF · Сообщение **OKF** » Ср мар 09, 2016 18:25:02

L.O.D писал(а):Снова непонятки - как перенос кода из одной процедуры в другую приводит к потере "ноги" в карте занятости I/O?

А если подумать... Программное прерывание к.о. будем вызывать?
"Сейчас буду обьяснить. Возможно с ногой..." Молдавский юмор.

Реклама

ARV · Сообщение **ARV** » Ср мар 09, 2016 18:26:27

OKF писал(а):Программное прерывание к.о. будем вызывать?

зачем?!

Реклама

OKF · Сообщение **OKF** » Ср мар 09, 2016 18:29:19

Что бы "большой" пролог был не в начале.

Реклама

ARV · Сообщение **ARV** » Ср мар 09, 2016 18:44:35

у вас какое-то странное понимание поведения компилятора.
искусственно генерируемое прерывание в конечном итоге ничем не лучше простого обращения к функции.
пролог в обработчике прерывания делается только на основе двух фактов:
1. используемые переменные в обработчике
2. обращения к функциям из обработчика
первый пункт означает, что если переменных в обработчике задействовано минимум, минимальным будет и пролог. всегда в прологе сохраняется SREG и один из регистров (точно не помню, какой именно). если одним этим регистром удастся обеспечить логику обработчика, ничего больше в прологе не будет. соответственно и в эпилоге
второй пункт означает, что если в обработчике есть обращение к функциям из библиотек или других модулей, то в прологе всегда будут сохранены ВСЕ РАБОЧИЕ РЕГИСТРЫ в стек, если я не ошибаюсь, это начиная с r16 и далее по порядку. ну и SREG с дополнительным регистром, само собой
если же в обработчике используются функции из этого же модуля, пролог с эпилогом будут какими-то средними по отношению к описанным вариантам.
если используемые в обработчике функции будут static, то с большой долей вероятности они могут быть проинлайнены в обаботчик, но это не гарантия - надо контролировать по листингу

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

OKF · Сообщение **OKF** » Ср мар 09, 2016 19:21:57

Я уже писал, что мне нужна быстрая реакция на прерывание.
А функций из других модулей не позволяют иметь короткий пролог.
Оформив функции в искусственном прерывании. и программно вызывая его (уже после быстрой реакции на прерывание), я получу требуемый эффект. И в этом как раз и будет отличие программного прерывания от функции/функций внутри прерывания.

ARV · Сообщение **ARV** » Ср мар 09, 2016 19:57:49

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

из ваших слов я понял такое:
1. возникло прерывание
2. вы попадаете в "быстрый" обработчик
3. перед завершением быстрого обработчика дрыгаете ножкой, которая вызывает запрос на очередное прерывание, "медленное"
4. выходите из "быстрого" прерывания, программа отрабатывает 1 команду и попадает в "медленный" обработчик
5. в медленном обработчике с большим прологом что-то страшное делаете с помощью всяких функций
6. завершаете "медленный" обработчик

я верно все понял? в каком месте по-вашему происходит "быстрая" реакция на первый запрос прерывания?

OKF · Сообщение **OKF** » Ср мар 09, 2016 20:09:01

Да, Вы всё правильно поняли. И поэтому мне непонятен Ваш вопрос...
Очевидно же, во 2-м пункте. Именно в нём я отвечаю на прерывание по изменению сигнала в линии.

hybroid

Очевидно лишь то, что во втором пункте никакой реакции не происходит. Реакция на внешнее событие явно где-то дальше. Толку от того, что быстро вошли в обработчик, если никакой поставленной задачи не выполнено, ничего не обработано.
Не понятно, что мешает показать код. Или огласить полностью задачу.

OKF · Сообщение **OKF** » Ср мар 09, 2016 20:34:44

"Я фигею, дорогая редакция!"
Вы лучше меня знаете что происходит во 2-м пункте и даже ещё раньше.

Alexeyslav

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

OKF · Сообщение **OKF** » Чт мар 10, 2016 05:58:46

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

hybroid

OKF писал(а):"Я фигею, дорогая редакция!"
Вы лучше меня знаете что происходит во 2-м пункте и даже ещё раньше.

"Мы" ничего не знаем. Сплошные тайны. Хочется возложить на прерывание - надо возлагать

L.O.D

OKF писал(а):А если подумать... Программное прерывание к.о. будем вызывать?

Пардон, полагал, что под "фиктивным прерыванием" имеется ввиду функция.

Apparatchik

Подскажите пожалуйста как определить структуру в сегменте кода и по указателю на эту структуру, передаваемому как параметр, обращатся к её полям? В мануалах везде только про строки и их массив.

WiseLord

Сама структура объявляется как обычно. Переменные - экземпляры структуры создаются как обычно, с указанием const PROGMEM. Ну а доступ к полям - через pgm_read_xxx, где xxx зависит от разрядности поля.

SerF

Здравствуйте!
Давно уже пользуюсь WinAVR, ни когда не было ни каких проблем.
Устанавливал на Windows 8.1, 10 x64 все прекрасно работало.
И вот сегодня возникла проблема: при компиляции появилась ошибка.

Couldn't reserve space for cygwin's heap, win32 error 0

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

P.S. Проверил на AVR Studio 4.19, та же ошибка.

WiseLord

Подобная манипуляция с msys-1.0.dll не помогает?