Нужны ли коллбэки или это синтаксический сахарок сомнительно

Коллбэк - исполняемый код, передаваемый посредством указателя в функцию как аргумент.
Обычно механизм коллбэков (касательно mbed) применяется при использовании какой-нибудь обширной библиотеки, оказавшейся строго между физическим уровнем и уровнем приложения.
Классический пример - библиотека файловой системы. Разумно, что мы подключаем библиотеку для физической реализации протокола обмена данными с носителем (HDD, SD-card и т.д.) плюс библиотеку ФС. И на уровне приложения используем что-нибудь вроде функций readFile/writeFile из библиотеки ФС пробрасывая через эти функции указатели на функции readData/writeData из библиотеки физической реализации. Типа все библиотеки работают как черные ящики, всё прекрасно.

Проблема в том, что в самой популярной библиотеке ФС для mbed - FatFs - не используются коллбэки. В числе файлов библиотеки дается файлик, который нужно подправить руками. Т.е. чуточку залезть в черный ящик. Т.е. концепция "библиотека - это черный ящик, а коллбэки - это способ послать в черный ящик исполняемый код" ступает нафиг. Т.е. зачем тогда нужны коллбэки? Механизм-то их применения нихрена не простой. По сравнению с "подправить файлик в библиотеке". Не, я понимаю в библиотеках USB они буйным цветом цветут. Но в случае библиотеки USB такой механизм навязан разработчиками библиотеки. Есть ли кейсы на которые механизмы коллбэков ложаться идеально ровно? Или коллбэки - это синтаксический сахар сомнительного свойства?

0

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

0

Так очевидно же. В ядре ARM предусмотрено несколько наборов регистров общего назначения для каждого режима работы процессора. Те регистры, в которые вы смотрите в прерывании - это совсем не те регистры, в которые вы клали свои значения, а те, которые используются в режимах IRQ, или же FIQ.

0

??? Нехилый поворот событий. А где в программинг манулае или в мануале ядра Кортекс написано, что у РОН есть копии?
Сдается мне, что вы, любезнейший, читали-читали, да недочитали всё-таки.. Давайте вы быстренько прочтете это, а я сделаю вид, что не видел того вашего поста. Чтобы потом вам стыдно то не было...

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

0

Ок. Попытка не удалась.

0

Сообщение от BusMostir Ответьте лучше на вопрос, куда делись параметры из регистров (выше по тексту задача) :)))

Даже не знаю, плакать или смеяться. Вы вообще не поняли, что я имел в виду.

Сообщение от BusMostir будет интересно послушать "начальника транспортного цеха"

Да вас тут слушать не переслушать.

0

Сообщение от BusMostir Вы сути не поняли, любезнейший.

Вообще-то вы ее не поняли. Что, впрочем, было ожидаемо.

0

ну ладно, расскажите нам, что вы там представляли себе, что там имели ввиду? :)))

0

Попкорн закуплен.
Ждём появления shadow core rikystir set и shadow GPR set доступные юзеру...

0

Сообщение от BusMostir ну ладно, расскажите нам,

Вы размножились?

Сообщение от BusMostir что вы там представляли себе, что там имели ввиду? :)))

Вам все равно не поможет.

0

Сообщение от dosykus_2 Попкорн закуплен.

Вы даже не представляете как давно. Наблюдать вас и остальную автобусную илиту это такой цирк...

0

Таки ви запомятовали ?
Где же они????

0

классная тема :)))
с удовольствием прочитал.

Речь даже о паттернах заходила...паттерны тоже изучаю помаленьку(для понимания общей картины мира программирования), но вообще не понимаю как их можно применить в МК. вернее можно наверно, но тогда это будет тоже самое что десктопные программы писать на ассемблере. т.е. можно наверно, но думаю крайне неудобно и не рационально.
Паттерны нужды для нормального программирования для ПК , там они оправданы и полезны (хотя тоже не святой грааль) . Так же думаю их можно использовать в системах где есть какая то операционная система и нет требования к точности работы в реальном времени. имхо.

0

Сообщение от BusMostir Ответьте лучше на вопрос, куда делись параметры из регистров

Вы их сами затёрли, своим бесконечным бесполезным циклом. Кстати странно что он выполнялся.
Для ARM ядра.
Параметры в прерывание предавать можно, но не во все и не всегда. Прежде всего прерывание должно иметь самый низкий приоритет, и быть единственным с этим приоритетом. Второе - ждать прерывание не имеет смысла, его нужно вызывать самостоятельно. По сути это аналог запрета прерываний, код вашей функции будет выполняться вне зависимости от внешней очереди в поликлинику. Однако в этом случае все желающие только спросить - смогут зайти после вас, с сохранением очереди и уровня статуса. Главное - короткие прерывания не теряются как в случае запрета.
Параметры передаются через регистры, отдаются через стек. Для чипов st это прерывание SVC, идеальное решение для переключения контекста и приоритетного выполнения кода.

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

0

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

На вскидку:
- синглтон - практически вся периферия в МК с вводом-выводом отображенным на память это и есть синглтоны
- обсервер - те самые коллбеки, пользовательский интерфейс и так далее
- шаблонный метод (буквально то, что делают в плюсах шаблоны функций)
- стратегия - вынос алгоритма в отдельную функцию (пример с qsort уже упоминался)
- лок - захват/освобождение ресурсов (сериализация доступа к переменным, блокирование прерываний на время доступу к ресурсу/переменной)
- интерпретатор (скажем, встраиваемые интерпретаторы языков или, например, интерпретатор G-кода)
- реактор (своего рода многозадачность без RTOS, удобно обрабатывать поток разнородных событий)

0

ivsy,
если делать что-то по работе с экраном то да, имеет место быть.

у меня вот тут была задача по приходу импульса мерить его сигнал и обрабатывать внешним АЦП. И два дня пришлось убить чтобы понять что прерывание происходят с некоторой задержкой(вернее есть три типа задержек связанных с работой стека). Был удивлен когда на второй или третьей день я нашел эту особенность в RM. В итоге все извраты с кодом вылились в код на 10 строк на регистрах и все работает аппаратно. Вот в этой возможности аппаратно и точно решать сложные и быстрые задачи и есть фишка программирования МК. По моему личному мнению. В принципе dosykus_2 об этом всегда говорит. Если использовать паттерны, си++ и шаблоны , то нужно заранее брать более производительный МК и пожертвовать как минимум временем работы от батареии.

А паттерны я стараюсь использовать в софтверных приложениях где нет необходимости считать такты и +-200n секунд ничего не решают, проблем с питанием нет и процессор может "сжувать" почти любые ошибки и неточности.

короче для софтверного программиста процедурный подход скорее зло и лучше мыслить классами и паттернами. Для МК крайне трудно представить задачи где это целесообразно и в процедурном подходе я не вижу ничего плохого. Особенно если процедуры построены с учетом особенностей аппаратуры.

Хотя конечно - каждый пишет код так как считает правильным и рациональным.

OVY-srok, при заходе в прерывания все регистры уходят в стек. при выходе из прерывания они должны вернуться в свои значения. Чисто мое дилетанское мнение. Хотя возможно начальные регистры просто затерлись вычислениями в цикле, а потом уже ушли в стек.(надо будет почитать про младшие регистры.) короче в любом случае в прерывании регистры будут другими(иметь по умолчанию случайные значения). так я понимаю этот процесс.

0

Сообщение от Otomys-dm Если использовать паттерны, си++ и шаблоны , то нужно заранее брать более производительный МК и пожертвовать как минимум временем работы от батареии.

С чего бы вдруг? Нет никаких причин для того, что бы плюсовый код был, как минимум, не хуже С-шного.

Сообщение от Otomys-dm А паттерны я стараюсь использовать в софтверных приложениях где нет необходимости считать такты и +-200n секунд ничего не решают, проблем с питанием нет и процессор может "сжувать" почти любые ошибки и неточности.

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

Сообщение от Otomys-dm короче для софтверного программиста процедурный подход скорее зло и лучше мыслить классами и паттернами. Для МК крайне трудно представить задачи где это целесообразно и в процедурном подходе я не вижу ничего плохого. Особенно если процедуры построены с учетом особенностей аппаратуры.

На С++ и шаблонах можно писать процедурно, можно писать объектно. Другими словами, это ортогональные вещи. Кроме того, противопоставление процедурного и объектного подхода происходит от банального непонимания того, что объектный подход всего лишь развитие и расширение процедурного. Цель обоих подходов ровно одна: уменьшать сложность за счет уменьшения количества связей между частями программы. А досикус и прочае "илита" просто-напросто против того, что они не в состоянии осмыслить и научиться использовать.

P.S. как верно кто-то заметил в другой теме - железо это всего несколько процентов кода в любой мало-мальски сложной прошивке, остальное - алгоритмы и данные. и тут нет никакой разницы в том, пишется код для "большого" процессора или для МК, просто-напросто выбираются те решения, которые вписываются по требованиям конкретной задачи. любое искусственное отгораживание эмбеддед от остальных областей приводит только к зашориванию и косности. это особенно опасно с учетом того, что ресурсы МК постоянно увеличиваются и возможности растут, а значит расширяется круг решаемых задач и сложность кода. "Большие" компы уже имеют опыт решения задач такого уровня сложности и накопили немало информации, подходов, набитых шишек и тому подобного. Отгораживаться от этого и изобретать велосипед заново - бесполезная потеря времени и сил.

0