[AHTOXA 14]

2 часа назад, Forger сказал:

Я использую третий способ, но приведенный к более кмк красивому и деликатному решению, а именно - обработчик прерываний является самым обычным методом нужного класса (НЕ static).

Это как?! Как вы умудрились в качестве обработчика назначить не-статическую функцию класса?
Вы, наверное, опять имели в виду что-то другое? :))))

[Forger 17]

6 minutes ago, AHTOXA said:

Это как?! Как вы умудрились в качестве обработчика назначить не-статическую функцию класса?

Никакой магии :) Вот подробности

 

 

[AHTOXA 14]

1 час назад, Forger сказал:

Никакой магии :) Вот подробности

Ну то есть, всё же обработчик прерывания  - обычная си-функция, которая при помощи кучи заумных наворотов, дополнительных вызовов и прочей магии вызывает функцию-член объекта? Да уж...

Вот из-за таких, как вы, люди и боятся плюсов.

[Forger 17]

33 minutes ago, AHTOXA said:

Ну то есть, всё же обработчик прерывания  - обычная си-функция

А разве возможно с помощью кода изменить архитектуру проца? ;)

 

Quote

дополнительных вызовов 

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

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

Делегат в данном месте дает возможность изолировать код от всей этой низкоуровневой "ботвы".

Оптимизатор компилятора очень правильно понимает, чего от него требуется (глянул для приличия disasm результат)!

Короче, масса плюсов ( гы )

 

Quote

Вот из-за таких, как вы, люди и боятся плюсов.

БУ!  

[AHTOXA 14]

1 час назад, Forger сказал:

А разве возможно с помощью кода изменить архитектуру проца? ;)

Я-то знаю, что нельзя. А вы выражайтесь точнее. Вы ж программист. А то у вас то через стек что-то передаётся, то вот теперь это. Но когда читаю бред типа "обработчик прерываний является самым обычным методом нужного класса (НЕ static)", то очень удивляюсь.

1 час назад, Forger сказал:

Не нужен startup, не нужно искать точные названия функций обработчиков...

Опять неточно выражаетесь. Стартап нужен, без него никак. Вы, наверное, имели в виду, что его менять не надо при добавлении векторов? Так это и мне не надо.

А вместо названий функций обработчиков нужно помнить названия функций создания делегатов и timer.installVectorxxx(). Короче, плюсов не вижу, кроме минусов.

Кроме того, я немного не понял. У вас что, на все вектора прерываний  всегда создаются эти объекты? Ну, по одному объекту timer для каждого таймера, по одному uart для каждого UART-а, и так далее, более сотни объектов? Если так, то это жесть:)

 

[Forger 17]

 

Quote

Я-то знаю, что нельзя. А вы выражайтесь точнее. Вы ж программист.

А то у вас то через стек что-то передаётся, то вот теперь это. Но когда читаю бред типа "обработчик прерываний является самым обычным методом нужного класса (НЕ static)", то очень удивляюсь.

Цепляние к словам и фразам воспринимаю как банальную эмоцию, свойственную тем, кто может быть в общих чертах хоть понял о чем речь, но не понимает как это повторить или сделать под себя ) И поэтому, чтобы не "потерять лицо", вынужден как-то выкручиваться. 

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

Короче, предлагаю вернуться к к теме.

 

 

Quote

Опять неточно выражаетесь. Стартап нужен, без него никак.

Стартап сделан один раз, отлажен и забыт. Его не нужно менять и копаться в нем. Он рассчитан на целое семейство камней, а не на конкретные камни, как в "стоке". У меня он вообще является частью предсобранной библиотеки для периферии того или иного семейства, туда же "зашита" RTOS.

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

 

Quote

А вместо названий функций обработчиков нужно помнить названия функций создания делегатов и timer.installVectorxxx(). Короче, плюсов не вижу, кроме минусов.

Не нужно их помнить. Они везде одинаковые - installVector, а приписку "XXX" это вы только что придумали.

 

 

Quote

Кроме того, я немного не понял. У вас что, на все вектора прерываний  всегда создаются эти объекты?

Все вектора имеют свои static обработчики, они чуть больше по размеру, чем "стоковые" (с припиской weak).

Обработчик прерываний является частью некого периферийного модуля. Точнее не обработчик, а всего лишь делегат (8 байт в озу), который инициализируется как раз через installVector. У некоторой периферии бывает по несколько обработчиков (зависит от камня).

Обработчик вы подключаете свой - он может быть методом любого класса. Обязательное условие - тип void(void).

 

 

Quote

Ну, по одному объекту timer для каждого таймера, по одному uart для каждого UART-а, и так далее, более сотни объектов? Если так, то это жесть:)

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

Не знаю камней, где есть сотня аппаратных таймеров. Хотя, если такие и существуют, то там и ОЗУ измеряется в соотв. единицах объема ;)

Попытка создания более одного экземпляра одного и того же аппаратного узла пресекается соотв. предупреждениями.

 

[jcxz 184]

9 часов назад, Forger сказал:

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

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

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

[jcxz 184]

7 часов назад, Forger сказал:

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

Регулярные неточности в терминологии, многословные разговоры "в общих чертах" но с кучей красивых звучных слов - считаю признаком поверхностных знаний. Как то так.

[ViKo 1]

А делегат - это просто указатель на функцию. Которых (указателей) нет в C#, вот и придумали замену. 

[AHTOXA 14]

9 часов назад, Forger сказал:

Обработчик прерываний является частью некого периферийного модуля. Точнее не обработчик, а всего лишь делегат (8 байт в озу), который инициализируется как раз через installVector. У некоторой периферии бывает по несколько обработчиков (зависит от камня).

Правильно ли я понял, что вы каждый раз расходуете на свою красоту (8*число_векторов) байт ОЗУ?
То есть, например, для STM32F030 я, пользуясь вашим методом, потеряю 29*8 = 232 байта из 4К доступного ОЗУ? Почти 6%?

[jcxz 184]

2 минуты назад, AHTOXA сказал:

Правильно ли я понял, что вы каждый раз расходуете на свою красоту (8*число_векторов) байт ОЗУ?
То есть, например, для STM32F030 я, пользуясь вашим методом, потеряю 29*8 = 232 байта из 4К доступного ОЗУ? Почти 6%?

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

А вот лишнее время на каждый вход в ISR только для того чтобы было "красиво" - это уже совсем не красиво.

[AHTOXA 14]

1 час назад, ViKo сказал:

А делегат - это просто указатель на функцию. Которых (указателей) нет в C#, вот и придумали замену. 

Не совсем просто указатель. Он может указывать на функцию класса. Тогда он хранит два указателя - на функцию, и на экземпляр класса (объект).

Только что, jcxz сказал:

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

А вот лишнее время на каждый вход в ISR только для того чтобы было "красиво" - это уже совсем не красиво.

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

Ну и потери времени, да.

[Forger 17]

 

5 hours ago, AHTOXA said:

Правильно ли я понял, что вы каждый раз расходуете на свою красоту (8*число_векторов) байт ОЗУ?
То есть, например, для STM32F030 я, пользуясь вашим методом, потеряю 29*8 = 232 байта из 4К доступного ОЗУ? Почти 6%?

Если проект расходует, например, всего 50% от этого ОЗУ, то эти 6% не имеют никакого значения.

Если же ваш проект находится на грани, скажем 94..95% ОЗУ, то закладывание таких жестких ограничений впоследствии может обернуться боком.

 

 

5 hours ago, jcxz said:

А вот лишнее время на каждый вход в ISR только для того чтобы было "красиво" - это уже совсем не красиво.

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

А если вызываете виртуальный метод, то как раз очень сильно проигрывает.

Компилятор же очень грамотно понимает суть моей затеи.

 

 

7 hours ago, jcxz said:

Куча словесной шелухи

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

 

[AHTOXA 14]

58 минут назад, Forger сказал:

Если проект расходует, например, всего 50% от этого ОЗУ, то эти 6% не имеют никакого значения. 

Если же ваш проект находится на грани, скажем 94..95% ОЗУ, то закладывание таких жестких ограничений впоследствии может обернуться боком.

Допустим, мы считаем, что допустимый расход ОЗУ - 60% (или 70, или 80, или 90 -- неважно). Так вот, ваш подход снижает эту границу независимо от её абсолютного значения.

Таким образом, существуют конфигурации такие, когда без вашего подхода я ещё впишусь в допуск, а с вашим - уже нет.

15 часов назад, Forger сказал:

Цепляние к словам и фразам воспринимаю как банальную эмоцию

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

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

[Forger 17]

34 minutes ago, AHTOXA said:

Допустим, мы считаем, что допустимый расход ОЗУ - 60% (или 70, или 80, или 90 -- неважно). Так вот, ваш подход снижает эту границу независимо от её абсолютного значения.

МК от этого не будет медленнее работать, не будет тупить или дольше "загружаться". От этого НИЧЕГО не изменится.

В конечном счете покупателю изделия совершенно до лампочки, сколько там ОЗУ в МК используется или не используется программером. 

К тому же существует такой термин - "накладные расходы". Их никто не отменял.

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

С другой стороны можно по-прежнему как аборигены сидеть на голом С, бить себя "пяткой в грудь", а при этом даже самые дохлые современные МК по внутрянке обгоняют некоторые компы из прошлого века (не говорю уже про более серьезные МК).

Через десятилетие, другое самый дохлый МК будет иметь уже несколько десятков кБ ОЗУ как минимум. Но, уверен, все равно найдутся деятели, которые будут "экономить  на спичках". Просто, их будет уже намного меньше 

 

Quote

К тому же вы, судя по всему, претендуете на то, чтобы ваши посты читали начинающие,

Это вы верно заметили. Раздел-то я упустил из виду. Пардон ))