Перейти к содержанию
    

А безумные char, напротив, постоянно. Вот буквально сейчас вожусь с Jennic контролером у у которого ВООБЩЕ нет описания и только API, причем все байтами усыпано и чувствую себя очень, очень! стремно. Для себя такой "восьмибитовый" тип дефинирую для краткости, как bint (то-ли базовый, то-ли байтовый int - за давностью лет не помню :) ) и спокойно таскаю исходники по 8-16-32 битникам.

Это лишние эмоции. Кому-то валерьянка помогает, кому-то - медитация. Ну, будут там лишние инструкции, ну и фиг с ними. "Работает - не трогай". "Преждевременная оптимизация - корень всех зол". И так далее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это лишние эмоции. Кому-то валерьянка помогает, кому-то - медитация.

Увы, это один из показателей КАЧЕСТВА кода. И если он оказывается глюкавым дерьмом, то ни один из Ваших "рецептов" не поможет.

Ну, будут там лишние инструкции, ну и фиг с ними. "Работает - не трогай".

А если НЕ работает. Причем иногда и далеко-глубоко? Ваши действия?

"Преждевременная оптимизация - корень всех зол"

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

Опитимизация должна начинаться уже на уровне задумки системы. А в самом низу, все компиляторы должны быть отстроены под нужные и максимальные оптимизации. Надо просто УЧИТЬСЯ правильно и четко излагать свои мысли и требования компилятору. Причем СРАЗУ, а не потом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Была важна быстрая реакция на прерывание, а не через сколько-то там тактов и короткий обработчик этого FIQ на фоне не менее жесткого и несколько синхронизированного 2ms прерывания.

ну тут вопрос сколько тактов занимает переход по FIQ, и сколько это времени в той частоте проца.

 

Ну на 10 МИКРО секунд перрывание вешать то, что Вы перечислили, это какой-то безумный прдход к делу sad.gif

То-же TCP стек ни сном ни духом МИКРОСЕКУНД не требует и работает по собственным прерываниям и таймаутам. Это если его правильно писать.

очень важно было чтобы действия повторялись на одном расстоянии от этой 10 мкСек границы, а ТСР стэк имел свои прерывания, и какое-то время в них тратилось да и прочии прерывания системы, стек просто. Потому иногда граница попадала на серидину-начало другого прерывания, и действия бы смещались. Но благодаря системе вытеснения я точно знал что повторяемость будет 2-3 такта на 100 МГц для 10 мкСек события это 2-3%, то есть хорошо.

 

Да на старом арме я бы повесил это прерывание на FIQ, а если бы оно было не одно? То есть NVIC мне дает возможность иметь несколько прерываний которые корректно вызовутся как вложенные, без рукописного шедулера. А плата за это 12 тактов на 100 МГц, может так оказаться что это быстрее чем FIQ на старых армах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ну тут вопрос сколько тактов занимает переход по FIQ, и сколько это времени в той частоте проца.

 

Еще учтите, что сам вызов прерывания по себе еще ни о чем, еще нужна процедура, которая берет из массива векторов тот, который нужно по индексу дистрибутора. а это еще такты, такты...

 

Ну на старом контроллере такая вещь на FIQ может быть повешена. Ну на 10 МИКРО секунд перрывание вешать то, что Вы перечислили, это какой-то безумный прдход к делу

 

Ну а что тут такого безумного, в прерывании 100к раз в сек, при частоте проца в 100МГц, скажем?? Если это полностью оправдывает задачу.. Безумно повесить на это прерывание код в 1000 тактов, это да, чистой воды дурь.

Изменено пользователем mantech

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну а что тут такого безумного, в прерывании 100к раз в сек, при частоте проца в 100МГц, скажем?? Если это полностью оправдывает задачу.. Безумно повесить на это прерывание код в 1000 тактов, это да, чистой воды дурь.

Ну да... "100к раз в сек, при частоте проца в 100МГц" это не дурь... а "1000 тактов" при частоте проца в 100МГц... 10мкС это дурь... не говоря о приоритете прерываний... Логика где??? Или опять "слова пико-аврщика который просто жутко боится даже ознакомится с чем-то другим"(С)???

Изменено пользователем HHIMERA

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

логика в том что 10 мкСек на 100 МГц это как раз 1000 тактов:)

потому сделать такое прерывание реально дурь, ибо только оно и будет работать.

 

Кстати в той системе в нем от 300 до 700 команд в зависимости от условий, то есть да оно грузит проц на 30-70% но так как это его основная задача, то не страшно....

 

 

Еще учтите, что сам вызов прерывания по себе еще ни о чем, еще нужна процедура, которая берет из массива векторов тот, который нужно по индексу дистрибутора. а это еще такты, такты...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Так то оно так, можно и irq на один вектор задать, а если требуется более чем одно прерывание?

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

Изменено пользователем mantech

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

логика в том что 10 мкСек на 100 МГц это как раз 1000 тактов:)

потому сделать такое прерывание реально дурь, ибо только оно и будет работать.

Спасибо... посмеялся...

И что... эти 1000 тактов не могут прерваться другим прерыванием... если нужно???

Правильно говорят... "АВР - это диагноз!"(С)...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И что... эти 1000 тактов не могут прерваться другим прерыванием... если нужно???

Правильно говорят... "АВР - это диагноз!"(С)...

 

Че-то я не понял, причем тут авр вообще? Вы сами-то с чего начинали, сразу с арма, да еще наверно с А серии в стандалоне проектах? Тогда к чему это все?

А уж если так пошло, то и на авр можно прервать его другим прерыванием, если не знаете как - тогда в детский сад вообще...

 

А по сути, ну прервете его и дальше что? Основной программе вообще тактов не дадите? :biggrin:

 

Я писал это тому товарищу, который думает, что прерывания в 100к раз в секунду - это бред, поясню, нужно сделать сбор данных с порта и поместить в массив, сколь тактов потребуется? Допустим 20, плюс вход и выход в прерывание, все это хозяйство займет 3-4% процессорного времени на данной частоте. И в чем бред?? При условии, что я получаю четко детерминированную выборку по времени, это можно сделать по другому? Или, как мне тут предложили однажды - поставить ПЛИС? По-моему это бред...

Изменено пользователем IgorKossak

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А плата за это 12 тактов на 100 МГц, может так оказаться что это быстрее чем FIQ на старых армах.

Ой! Ограничили изучение рекламным буклетом :(.

Нет, 12 это только до вызова вектора. Дальше сам переход тактик. А сколько регистров еще НЕ сохраняется за эти 12 тактов? Напоминаю - 8 штук. На их сохранение и последующее восстановление, тоже такты нужны. Ну и возвратиться не забудьте, а это еще 12 тактов плюс такт на собственно команду возврата. При попадании приоритетного на вход в низкоприоритетное - еще до 6 тактов добавляется. Да, еще не забываем, что Flash из которого код выполняется не 0WS, так-что еще всякие фирменные механизмы предвыборки таки слетают при прерывании. На восстановление при входе-выходе еще затраты тактов.

 

Так-что зря Вы это вы 12 тактов помянули всуе :(.

 

На "старых" в FIQ за 5 тактов, причем оказывались в СВОЕМ СОБСТВЕННОМ стеке (а не нагло рвем одну из многих задач и пожираем ее стек) со СВОИМ банком хоть и не полным, регистров. И точка входа последняя в таблице, так-что без всяких джампов сразу можно было писать код. Это если просто тупо только о быстродействии говорить. Я же, напомню, что мне нравилось, как контроллер прерываний ложился на систему. NVIC, несоменно по своему хорош.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Основной программе вообще тактов не дадите? :biggrin:

Если у вас прога выполняется всего 10мкС... тогда да... (рукалицо)...

Я писал это тому товарищу, который думает, что прерывания в 100к раз в секунду - это бред

Т.е. ... раскатывание сферического коня в вакууме в обратном порядке???

В общем - да... частые прерывания такой же бред как и длинные... а может ещё и хуже... большие потери на вход/выход... а так... по задаче...

И вообще... все эти фобии... из области скелетов в шкафу...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

На "старых" в FIQ за 5 тактов, причем оказывались в СВОЕМ СОБСТВЕННОМ стеке

 

Ну и допустим, но это только если ОДИН вектор прерывания, в NVIC - это любой вектор из множества, а в старом контроллере нужно использовать программный селектор, который сожрет еще кучу тактов...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ужас :). Вообще-то вектора на IRQ родного контроллера прерывания от ARM были и есть, только при необходимости надо было ОДНОЙ комадой этот вектор считать-перейти. Или НЕ считывать, если не нужно было.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В общем - да... частые прерывания такой же бред как и длинные... а может ещё и хуже... большие потери на вход/выход... а так... по задаче...

 

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

 

Ужас :). Вообще-то вектора на IRQ родного контроллера прерывания от ARM были и есть, только при необходимости надо было ОДНОЙ комадой этот вектор считать-перейти. Или НЕ считывать, если не нужно было.

 

Чтоб не быть голословным, выложите сюда код обработчика irq с переходом на вектора прерываний из списка. Там и посмотрим, что это за "одна команда" ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну и допустим, но это только если ОДИН вектор прерывания, в NVIC - это любой вектор из множества, а в старом контроллере нужно использовать программный селектор, который сожрет еще кучу тактов...

Ответ выше - ровно одна команда - считать и перейти. Для особо непонятливых скопипастил из startup:

                ldr     pc,[pc,#-0xFF0]; 18 Jump directly to the address given by the AIC
                    ; from [0xFFFFF030] Curent 18h +8(conveyor)=20h

По адресу 0xFFFFF030 и находится этот самый вектор.

Причем ПО ЛЮБОМУ одна команда перехода и вектор есть и в "новом" NVIC. Вот такая НЕСУЩЕСТВУЮЩАЯ проблема :)

Если, конечно, мы говорим о продаваемом ARM контроллере. Покупатели могли и свой прицепить любой степени примитивизма.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...