-
- Этот код - демонстрация НЕ смешивания областей определения. Там где
определен Fucking_Silly_Led_On() не используются биты. Вообще. Ни в
явной форме, через ООП-прослойку. Cкpипaч(328 знак., 22.06.2024 18:27, ссылка)
- Класс Led необходим, т.к. он должен иметь ряд операций -
включить/выключить/другое и варианты создания/удаления. Led можно
включить записью 1 или 0 в порт, путём управления ШИМ, ЦАП тоже
можно... Всё это должно быть скрыто в слое абстракции. Пользователю
класса Led должно быть безразлично как включается светодиод на
конкретной плате. Он потом на другой плате будет пользоваться таким
же классом, но с другой реализацией (в идеале от производителя). Вы
же используете Costic(145 знак., 22.06.2024 18:55)
- А "необходим" именно класс? Модуль точно не устроит? :) - Cкpипaч(22.06.2024 19:48)
- Класс лучше оптимизируется. - VladislavS.(22.06.2024 22:35)
- В языке С++ модулей нет. %) - Costic(22.06.2024 19:55)
- Вы таки удивитесь, но есть :) VladislavS.(7 знак., 22.06.2024 22:38, ссылка)
- спасибо. интересненько - Vit(23.06.2024 10:25)
- А мне похер, я пишу на Паскале, просто компилирую компилятором С++. - Cкpипaч(22.06.2024 19:59)
- Вы таки удивитесь, но есть :) VladislavS.(7 знак., 22.06.2024 22:38, ссылка)
- "(в идеале от производителя)" Ну вот... Кто-то должэн написать и
отладить класс, который кому-то можэт быть полезен(а можэт и
никому), красиво упаковать и выложить на всеобщее использование.
Аналогия с секторами не канает по простой причине: архитектура ПЦ и
МС-ДОС/Вынь/Линь, это стандартная вещь и "производитель" вполне
себе, можэт заморочиться созданием стандартных классов. А вот
создатель какой-нить CH32V***, да хер с ним, сама STM, просто
умается ваять хоть какой набор mse homjak(96 знак., 22.06.2024 19:24)
- POSIX, STL, BSD Sockets тоже не сразу появились. STM - "пуп Земли"
только в России. Я уже писал, что ARM занимается классами, только
пока хреново у них получается. - Costic(22.06.2024 19:44)
- Разожгу срач. Считаю BSD Sockets наглядным примером крайне
неудачной и "дырявой" абстракции. "Посмотрите дети, как не надо
делать" - LightElf(05.07.2024 18:52)
- +100500 - =AlexD=(08.07.2024 15:33)
- Я не про это. Я про другое. mse homjak(634 знак., 22.06.2024 19:52)
- Спасибо. Хорошая формулировка того, с чем я тут ко всем плюсовикам доколупываюсь. Чувствуется класс :) - Cкpипaч(07.07.2024 14:53)
- +1. Редкая разумная мысль в угаре абстрактизации. - 3m(07.07.2024 11:13)
- Сейчас мы все ограничены CMSIS... и немного LL. - Costic(22.06.2024 19:57)
- Настоящщие мущщины не ограничены, потому что они кодят в хексе!* SciFi(40 знак., 07.07.2024 11:20)
- Ну вот, для каких-то кусков, которые поддаются стандартизации, это работает. Как и в стандартных библиотеках С. - mse homjak(22.06.2024 20:06)
- Разожгу срач. Считаю BSD Sockets наглядным примером крайне
неудачной и "дырявой" абстракции. "Посмотрите дети, как не надо
делать" - LightElf(05.07.2024 18:52)
- POSIX, STL, BSD Sockets тоже не сразу появились. STM - "пуп Земли"
только в России. Я уже писал, что ARM занимается классами, только
пока хреново у них получается. - Costic(22.06.2024 19:44)
- А "необходим" именно класс? Модуль точно не устроит? :) - Cкpипaч(22.06.2024 19:48)
- Класс Led необходим, т.к. он должен иметь ряд операций -
включить/выключить/другое и варианты создания/удаления. Led можно
включить записью 1 или 0 в порт, путём управления ШИМ, ЦАП тоже
можно... Всё это должно быть скрыто в слое абстракции. Пользователю
класса Led должно быть безразлично как включается светодиод на
конкретной плате. Он потом на другой плате будет пользоваться таким
же классом, но с другой реализацией (в идеале от производителя). Вы
же используете Costic(145 знак., 22.06.2024 18:55)
- Вам реально нужна библиотека для манипуляции битами и регистрами?
Мне - нет. - Cкpипaч(22.06.2024 15:40)
- Всем нужна, все <gpio.h> используют. Но написать GPIO
толково на С++ пока никто не может. Средства С++ и современные IDE
имеют подсказки и помогают писать код. Т.е. на этапе написания кода
уже могут исключаться ошибки, т.к. IDE предложит только
ограниченное множество портов, пинов и иных объектов в зависимости
от контекста. Даже компилировать не надо, как у Владислава. А это
повышение производительности труда, которая тебе очень нравится. - Costic(22.06.2024 19:40)
- Да, но подсказки они берут от написанных кем-то *.h файлов. И иногда, это вырождается в "обнять и плакать". - mse homjak(22.06.2024 20:00)
- Для инженерных задач, думаю, такая библиотека не нужна. Но
манипулирование битами это то средство в языке С, с помощью
которого предметная область "электротехники" отображается (mapping)
в алгоритмах и программах. По-хорошему, нужны средства (классы,
операторы, функции, множества) для описания предметной области.
Современный С++ может предоставить эти средства. - Costic(22.06.2024 16:39)
- Т.е. желание впихуйнуть операции над битами в совершенно иной слой
абстракции - неистребимо. Принято. Лично я так делать не буду. И
подчиненным не позволю. - Cкpипaч(22.06.2024 18:27)
- Тут вот какая штука... Дополнительная абстракция бит, позволяет
оптимизировать код на этапе компиляции. Причём так, что
последовательность действий над волатильными регистрами аппаратуры
сохраняется, обеспечивая требуемые последовательности ввода-вывода.
И, при этом, биты разных объектов, принадлежащие одному регистру,
упаковываются в одну операцию, а не в последовательность. Nikolay_Po(107 знак., 22.06.2024 18:45)
- Я вот выше писал что классы для работы с битами это перебор, но вспомнил как делал обёртку над системой команд RISC-V. Там при доступе к полям спецрегистров куча разных ассемблерных команд. Чтобы не думать как правильно и/или оптимально с ними работать пришолось обернуть в класс и переложить заботы на компилятор. В результате код обходит написанный вендором на асме. - VladislavS.(22.06.2024 23:21)
- А ЗАЧЕМ перемешивать работу с регистрами и прикладной код? Ради половины процента экономии по памяти программ? Я даже не
говорю "преждевременная оптимизация". Я просто молчу. Со скорбным
видом. - Cкpипaч(22.06.2024 18:54)
- А почему бы не экономить, особенно если это бесплатно делает
компилятор? И не преждевременно, а всегда и без устали. - VladislavS.(22.06.2024 22:49)
- Перечитал ветку еще раз - мы говорим о разном и друг друга не
слышим. Cкpипaч(556 знак., 23.06.2024 07:39)
- Вы противоречите своему примеру идеалного метода включения диода в
который поместили работу с битами и регистрами конкретного
контроллера. Вы этот метод будете переписывать раз за разом, а я
нет. Битовая арифметика с регистрами на каком-то уровне всё равно
появится, но этот уровень ниже чем у вас. Gpio, spi, i2c, usb - это
всё должно быть прослойкой абстракциией, позволяющей писать
прикладной уровень не думая для какого контроллера ты пишешь.
Написана эта абстракция VladislavS.(97 знак., 23.06.2024 08:28 - 09:05)
- Я - буду. Поменяю имя регистра или номер бита, если нужно. А как вы
получили гарантию что не регистр, не не номер бита никогда не
изменится в вашем случае? - Cкpипaч(23.06.2024 08:41)
- Гарантия одна, в методе включения светодиода не использовать ни имя
регистра, ни номер бита. Использовать абстракцию, я же приводил код
метода LED::On(); VladislavS.(123 знак., 23.06.2024 09:03)
- У вас есть неявное предположение что все LED гарантировано ведут
себя одинаково. Я в таком случае введу прикладной номер LED, а то какой номер, к какому биту какого регистра
относится - спрячу внутри модуля bsp. Cкpипaч(236 знак., 23.06.2024 09:12)
- Никак нет, проектирование начинается с создания кирпичиков из
которых строится дом. Панельный дом собирается куда быстрее. Как
нумерация или название связано с битами показано прямо в сообщении
на которое вы отвечаете. И да все светодиоды ведут себя одинаково -
погашены, горят (с разной яркостью) или мигают. Пишете их поведение
один раз и больше туда не лазите. - VladislavS.(23.06.2024 09:23)
- У Nuvoton есть процы с глубокой спячкой и локом GPIO при проходе
через ресет при выходе из спячки. Так что не всегда при переходе на
вектор ресет имеем дефолтное состояние периферии. Деинит играет
новыми красками. И даже сам вопрос необходимости (или нет)
запускать инициализацию может повергнуть в уныние кишки самого кода
инициализации. Особенно если ретеншн есть на совсем небольшую часть
ОЗУ, или нужен более мелкожручий режим без ретеншна, т.е. даже
сохранять стек нет смысла - Vit(1 знак., 23.06.2024 09:59)
- Светодиод должен обо всём этом знать? - VladislavS.(23.06.2024 10:08)
- Если будете писать конструктор, то должны будете знать. Светодиод
это рафинированный пример обернутого битового обращения от вас же.
Представьте себе, что это выключатель питания GSM-модуля. Всё тот
же GPIO, но с полной, а не с ограниченной отвественностью:) - Vit(23.06.2024 10:21)
- Ну если это выключатель GSM-модуля, то у него и логика будет не от
светодиода. А метод включения будет всё равно GSM::On(). И дёргать
ногой он будет точно так же через пин (gpio или расширителя -
пофиг) как и светодиод не думая об его портах и битах, ибо это не
его зона абстракции. - VladislavS.(23.06.2024 10:42)
- у него вводные условия появляются - прежде чем собственно поднять
ногу нужно осмотреться, а доступна ли она, а не получится ли вдруг
вступить в кучу:) - Vit(23.06.2024 10:48)
- Всегда есть космический крейсер, кореллийские лучи смерти,
галактическая чума, угрожающая погубить всю планету... И чтобы
обыватели не сошли с ума, они ничего не должны об этом знать! (c)
MiB - VladislavS.(23.06.2024 11:05)
- toggle выполняет действие со скрытым от юзера предыдущим
состоянием. иногда не пофигу результат. ЗЫ. если у класса GSM и
ключ, и светодиод, то и ключу нужен класс GPIO, и классу LED.
вывод: класс LED сам по себе не нужен:) - Vit(23.06.2024 11:38)
- Кто-то запрещает прочитать состояние, если это надо для работы
модуля? Класс LED нужен, иначе вы описываете логику его работы в
классе GSM, тем самым усложняя его и делая менее переносимым. - VladislavS.(23.06.2024 11:54)
- насчет запрещает - не совсем так, но почти, потому как глобальные
разрешения (снятие лока GPIO) это вопрос не одного класса. а насчет
класса LED - он по сути алиас для части GPIO. такое при построении
сверху вниз чаще не нужно как класс, ибо лишний уровень абстракции.
но в отдельной программе-тесте приходится затягивать из кода
приложений, и по сути ручками делается тот же класс. это хоть и
ручками, но не дольше, чем наоборот. - Vit(23.06.2024 13:02)
- Даже одна возможность того что светодиод может включаться 1 или 0
уже отличает его от простой ноги. Вот захардкодите вы дёргание
ноги, а завтра схему поменяют... - VladislavS.(23.06.2024 13:17)
- Не стесняюсь писать Up и Down, а в On и Off указывать вызовы,
соответствующие полярности. Бывало с рулением полярностью, но как
показала практика - скорее правится плата и появляется BSP для неё
в виде набора файлов, чем калечится предыдущий код путём вставок
ветвления. В приложении нужны On и Off, при миграции код приложения
остаётся. - Vit(23.06.2024 17:10)
- Никаких ветвлений в рантайме нет. Инверсия - константный пареметр.
Он на этапе компиляции работает. - VladislavS.(23.06.2024 17:26)
- Щщазз! Инверсия получается после чтения входа этого же gpio. В
качестве примера посмотрите strapping для любого ethernet phy как
там подключаются индикаторные светодиоды. - 3m(25.06.2024 17:49)
- Внимательно следим за руками. Определяю два светодиода - один с прямым включением, второй с инверсным. Делаем LED::On() обоим и смотрим что получается. VladislavS.(119 знак., 26.06.2024 15:31, картинка, картинка)
- даже на Си, если не на макросах, то если полярность указывается
константно, обычно мелкое инлайнится до отсутствия ветвления самим
компилятором - Vit(23.06.2024 17:41)
- Да не даже на С, а это любой компилятор должен константные данные
оптимизировать. Если ему руки всякими "отлаженными модулями" не
выкручивать. - VladislavS.(23.06.2024 18:21)
- насчет "любой" и "должен" я бы не был столь категоричен. хотя да,
это теперь скорее норма. только не говорите это мелкочипам - они
даже GCC так кастрировали, что это обобщение не к ним:) ЗЫ я
уверен, что вам не досталось счастья использовать "компилятор"
MPLAB C16. оно могло один оператор в строке и никаких структур... - Vit(23.06.2024 19:21)
- Возможно мне повезло, но моё мнение по выбору чипов всегда
учитывали. А я в свою очередь всегда учитывал наличие вменяемых
средств разработки. - VladislavS.(23.06.2024 19:39)
- это прям тост. категорически поддерживаю. Vit(396 знак., 23.06.2024 20:04)
- Возможно мне повезло, но моё мнение по выбору чипов всегда
учитывали. А я в свою очередь всегда учитывал наличие вменяемых
средств разработки. - VladislavS.(23.06.2024 19:39)
- За более чем тридцать лет в бизнесе, не припомню ни одного
договора, в котором бы оговаривался размер кода в байтах :) - Cкpипaч(23.06.2024 18:24)
- Зато я помню проекты, где сотни каналов АФАР нужно за микросекунды
перестроить. - VladislavS.(23.06.2024 18:37)
- такое делать без запаса по быстродействию с упором на одно
программирование не комильфо. полагаю, что выбор кремния был не
пальцем в небо. Vit(1032 знак., 23.06.2024 19:57)
- Естественно, программирование лишь часть проекта, без fpga такое не взлетает. А язык даёт выигрыш, опыт это подтверждает. Естественно, руками можно всё то же самое и на С написать. Но когда за тебя это делает компилятор работа быстрее идёт. - VladislavS.(23.06.2024 20:20)
- Ввиду полного отсутствия ограничений по ресурсам на стороне компилятора, какой-либо практической пользы в Си против Плюсов - не вижу.
Когда пишешь на Паскале, какой компилятор вообще похер.- Cкpипaч(23.06.2024 20:15)
- такое делать без запаса по быстродействию с упором на одно
программирование не комильфо. полагаю, что выбор кремния был не
пальцем в небо. Vit(1032 знак., 23.06.2024 19:57)
- Зато я помню проекты, где сотни каналов АФАР нужно за микросекунды
перестроить. - VladislavS.(23.06.2024 18:37)
- насчет "любой" и "должен" я бы не был столь категоричен. хотя да,
это теперь скорее норма. только не говорите это мелкочипам - они
даже GCC так кастрировали, что это обобщение не к ним:) ЗЫ я
уверен, что вам не досталось счастья использовать "компилятор"
MPLAB C16. оно могло один оператор в строке и никаких структур... - Vit(23.06.2024 19:21)
- Да не даже на С, а это любой компилятор должен константные данные
оптимизировать. Если ему руки всякими "отлаженными модулями" не
выкручивать. - VladislavS.(23.06.2024 18:21)
- Щщазз! Инверсия получается после чтения входа этого же gpio. В
качестве примера посмотрите strapping для любого ethernet phy как
там подключаются индикаторные светодиоды. - 3m(25.06.2024 17:49)
- Никаких ветвлений в рантайме нет. Инверсия - константный пареметр.
Он на этапе компиляции работает. - VladislavS.(23.06.2024 17:26)
- Не стесняюсь писать Up и Down, а в On и Off указывать вызовы,
соответствующие полярности. Бывало с рулением полярностью, но как
показала практика - скорее правится плата и появляется BSP для неё
в виде набора файлов, чем калечится предыдущий код путём вставок
ветвления. В приложении нужны On и Off, при миграции код приложения
остаётся. - Vit(23.06.2024 17:10)
- Даже одна возможность того что светодиод может включаться 1 или 0
уже отличает его от простой ноги. Вот захардкодите вы дёргание
ноги, а завтра схему поменяют... - VladislavS.(23.06.2024 13:17)
- насчет запрещает - не совсем так, но почти, потому как глобальные
разрешения (снятие лока GPIO) это вопрос не одного класса. а насчет
класса LED - он по сути алиас для части GPIO. такое при построении
сверху вниз чаще не нужно как класс, ибо лишний уровень абстракции.
но в отдельной программе-тесте приходится затягивать из кода
приложений, и по сути ручками делается тот же класс. это хоть и
ручками, но не дольше, чем наоборот. - Vit(23.06.2024 13:02)
- Кто-то запрещает прочитать состояние, если это надо для работы
модуля? Класс LED нужен, иначе вы описываете логику его работы в
классе GSM, тем самым усложняя его и делая менее переносимым. - VladislavS.(23.06.2024 11:54)
- toggle выполняет действие со скрытым от юзера предыдущим
состоянием. иногда не пофигу результат. ЗЫ. если у класса GSM и
ключ, и светодиод, то и ключу нужен класс GPIO, и классу LED.
вывод: класс LED сам по себе не нужен:) - Vit(23.06.2024 11:38)
- Всегда есть космический крейсер, кореллийские лучи смерти,
галактическая чума, угрожающая погубить всю планету... И чтобы
обыватели не сошли с ума, они ничего не должны об этом знать! (c)
MiB - VladislavS.(23.06.2024 11:05)
- у него вводные условия появляются - прежде чем собственно поднять
ногу нужно осмотреться, а доступна ли она, а не получится ли вдруг
вступить в кучу:) - Vit(23.06.2024 10:48)
- Ну если это выключатель GSM-модуля, то у него и логика будет не от
светодиода. А метод включения будет всё равно GSM::On(). И дёргать
ногой он будет точно так же через пин (gpio или расширителя -
пофиг) как и светодиод не думая об его портах и битах, ибо это не
его зона абстракции. - VladislavS.(23.06.2024 10:42)
- Если будете писать конструктор, то должны будете знать. Светодиод
это рафинированный пример обернутого битового обращения от вас же.
Представьте себе, что это выключатель питания GSM-модуля. Всё тот
же GPIO, но с полной, а не с ограниченной отвественностью:) - Vit(23.06.2024 10:21)
- Светодиод должен обо всём этом знать? - VladislavS.(23.06.2024 10:08)
- Так вы, коллега, "шататель основ"?! 8) Что-ж, не вы один такой,
вырывание из задачи кусков с последующим "к пуговицам претензии
есть?" - очень характерно для плюсовиков, видимо язык накладывает
отпечаток. - Cкpипaч(23.06.2024 09:52)
- Причём тут претензии? В области вашей работы всегда есть сущности,
которые вы используете из проекта в проект. Вполне логично написать
для них качественные классы, которые потом просто и быстро
использовать. В итоге вы просто занимаетесь прикладухой, а не
переписываете раз от раза метод включения светодиода. А ведь у него
ещё и метод выключения есть :) - VladislavS.(23.06.2024 10:15)
- Вообще-то, именно так. Переписываю. Порядка трети тикетов - перенос
уже отработанных прикладных алгоритмов на другой bsp (точнее,
укладка нескольких алгоритмов в один bsp). Он состоит в
переписывании двух десятков функций, большая часть из которых
состоит из одной строки - поднять или опустить где-то какой-то бит. - Cкpипaч(23.06.2024 10:23 - 10:40)
- Итить колотить! Вам больше заняться нечем, как сидеть и
переписывать функции? И эти люди запрещают мне ковырять в носу (с)
:) - VladislavS.(23.06.2024 10:40)
- Лол. Это приносит деньги фирме :) Причем в человеко-часах это
существенно эффективнее чем плодить классы, наследование и
вот-это-вот-всё. - Cкpипaч(23.06.2024 10:41 - 10:43)
- Могло бы приносить больше, если бы вы занимались делом, а не
переписыванием одного и того же. - VladislavS.(23.06.2024 10:43)
- Меньше. И не давите на меня, я - директор, я считал и сравнивал. - Cкpипaч(23.06.2024 10:45)
- та же фигня:) - Vit(23.06.2024 11:05)
- Меньше. И не давите на меня, я - директор, я считал и сравнивал. - Cкpипaч(23.06.2024 10:45)
- Могло бы приносить больше, если бы вы занимались делом, а не
переписыванием одного и того же. - VladislavS.(23.06.2024 10:43)
- Лол. Это приносит деньги фирме :) Причем в человеко-часах это
существенно эффективнее чем плодить классы, наследование и
вот-это-вот-всё. - Cкpипaч(23.06.2024 10:41 - 10:43)
- Итить колотить! Вам больше заняться нечем, как сидеть и
переписывать функции? И эти люди запрещают мне ковырять в носу (с)
:) - VladislavS.(23.06.2024 10:40)
- Вообще-то, именно так. Переписываю. Порядка трети тикетов - перенос
уже отработанных прикладных алгоритмов на другой bsp (точнее,
укладка нескольких алгоритмов в один bsp). Он состоит в
переписывании двух десятков функций, большая часть из которых
состоит из одной строки - поднять или опустить где-то какой-то бит. - Cкpипaч(23.06.2024 10:23 - 10:40)
- Причём тут претензии? В области вашей работы всегда есть сущности,
которые вы используете из проекта в проект. Вполне логично написать
для них качественные классы, которые потом просто и быстро
использовать. В итоге вы просто занимаетесь прикладухой, а не
переписываете раз от раза метод включения светодиода. А ведь у него
ещё и метод выключения есть :) - VladislavS.(23.06.2024 10:15)
- У Nuvoton есть процы с глубокой спячкой и локом GPIO при проходе
через ресет при выходе из спячки. Так что не всегда при переходе на
вектор ресет имеем дефолтное состояние периферии. Деинит играет
новыми красками. И даже сам вопрос необходимости (или нет)
запускать инициализацию может повергнуть в уныние кишки самого кода
инициализации. Особенно если ретеншн есть на совсем небольшую часть
ОЗУ, или нужен более мелкожручий режим без ретеншна, т.е. даже
сохранять стек нет смысла - Vit(1 знак., 23.06.2024 09:59)
- Никак нет, проектирование начинается с создания кирпичиков из
которых строится дом. Панельный дом собирается куда быстрее. Как
нумерация или название связано с битами показано прямо в сообщении
на которое вы отвечаете. И да все светодиоды ведут себя одинаково -
погашены, горят (с разной яркостью) или мигают. Пишете их поведение
один раз и больше туда не лазите. - VladislavS.(23.06.2024 09:23)
- В прикладном коде вам нужно будет найти инициализацию объекта LED и исправить
там. А если окажется что еще и способ нужно поменять, то искать
"способ" придется уже где-то в другом месте. Два места вместо
одного, специально выделенного в отдельный модуль. Я это называю
"объектный спагетти-код". - Cкpипaч(23.06.2024 09:04)
- Зачем вы свои проблемы на меня перекладываете? Беру схему, в
заголовочном файле описываю (именно описываю) что куда подключено.
Для светодиода это пин и наличие инверсии, для eeprom порт i2c, для
синтезатора частот порт spi и пин gpio для контроля ФАПЧ и т.д. А
дальше забота компилятора всё это связать. Нет никаких двух и более
мест, по которым вы зачем-то рыскаете. - VladislavS.(23.06.2024 09:12)
- Эти идеальности не всех посещают. У меня вполне уживаются и светики
на GPIO, и светики, подключенные через I2C расширители. И для этой
группы устройств в базовом проекте туча таргетов для 6-и процов
(один кетайский), 2 типа ядер, 3 типа периферии проца, под
конкретные конфигурации плат (там есть несколько исполнений с тучей
разных интерфейсов и т.п.) с выбранной индикацией (со своими
разношерстными расширителями)... Сильно проще идти от прикладной
задачи, имея подготовленные Vit(3 знак., 23.06.2024 09:30)
- У вас же расширитель имеет интерфейс обычного порта и предоставляет
доступ к пинам так же как gpio контроллера? И повесить светодиод на
пин расширителя можно так же как на пин контроллера? - VladislavS.(23.06.2024 09:49)
- у меня расширители PCF8574/A и PCA9534/A с жесткой адресацией на
шине. естественно стоит автодедект. но в зависимости от варианта
аппаратной сборки подключается разный набор светодиодов (да и
некоторых ключиков питания). причем сами эти расширители имеют
внутри разную физически конфигурацию выводов - в PCF8574/A
неотключаемая подтяжка, а в PCA9534/A включаемая. для управления
ключиками это важно. светодиоды всегда можно погасить и тут же
зажечь как нужно (вспомная анекдот о Vit(114 знак., 23.06.2024 10:16)
- Сам бог велел спрятать всё это непотребство в класс расширителя и
выдать светодиоду интерфейс пина к которому он подключен. - VladislavS.(23.06.2024 10:26)
- Это впорос реализации, но не применения. У меня приложение вызывает
функцию управления функциональным узлом - светодиод обмена данными
включить. Под капотом оно и проверит, а инициализирован ли драйвер,
если нет, то запустит инициализацию, и другие проверки, ну или
просто дёрнет GPIO. Класс там у драйвера или модуль (как
идентифицированная единица компиляции) с набором функций - это не
суть важно. - Vit(23.06.2024 10:57)
- Всегда есть особенности реалищации, но не надо делать из этого
винегрет. Светодиод не должен заниматься проверкой инициализации
порта. Это дело самого порта. Если у вас такой хитрый порт, то и
наворачивайте его логику. Оставьте светодиоду светодидово. Так код
будет проше и понятней. - VladislavS.(23.06.2024 11:14)
- При чём тут винегрет? Да, есть драйвер I2C_GPIO, он сам себя
инициализирует, если до того не вызывали. Да, оно под капотом и
кишки наружу не торчат. Но функция включения светодиода в
приложении вызывает ручками вписанную (назначенную) функцию от
этого драйвера или от CPU_GPIO (драйвер, как ни странно, тоже
бывает нужен). И она действительно чихать хотела как оно
реализовано. В CPU_GPIO может быть bit banding, работа с Set/Reset
регистрами, может быть чтение-модификация запись Vit(890 знак., 23.06.2024 12:44)
- Вы всё красиво и правильно расписываете. Я лишь за то чтобы код
gsm-модуля ничего об этом не знал. - VladislavS.(23.06.2024 13:10)
- :) я ж вроде как за то же. - Vit(23.06.2024 17:13)
- Вы всё красиво и правильно расписываете. Я лишь за то чтобы код
gsm-модуля ничего об этом не знал. - VladislavS.(23.06.2024 13:10)
- Бугага! (только пожалуйста не обижайтесь, это не переход на
личности) А как насчет необходимости по-быстренькому подменить пару
входов заглушками, потому что в целевом bsp нет свободных? 8) Тоже
броситесь прикладной алгоритм переписывать? У вас это дешевле? :) Cкpипaч(176 знак., 23.06.2024 11:25 - 11:38)
- Когда вы принимаете решение использовать чужую библиотеку на
развитие которой не можете влиять, то приниманте на себя все риски.
Какая разница как она написана? Даже если вляпались в какашку,
кто-то держит пистолет у виска с требованием обновить её? - VladislavS.(23.06.2024 12:26)
- Мы живем не в стране розовых пони, вы забыли? :) - Cкpипaч(23.06.2024 12:29)
- В голове должно что-то срабатывать задолго до момента когда вы
решаетесь править чужие библиотеки. - VladislavS.(23.06.2024 12:42)
- Вы меня с кем-то перепутали. - Cкpипaч(23.06.2024 12:45)
- Не я предлагал gsm-библиотеку править. - VladislavS.(23.06.2024 12:51)
- И не я. Cкpипaч(86 знак., 23.06.2024 12:53)
- Значит показалось. А как вы вообще библиотеки делаете, если там
постоянно в функциях что-то переписывать приходится? Это то мне
хоть не показалось? - VladislavS.(23.06.2024 12:54)
- Нужно не путать библиотеки и модули. Есть собственно программа,
состоящая из дерева модулей и есть используемые библиотеки. Если
заказчику понадобилась хоть немного иная программа - дерево модулей
копируется в отдельный, новый проект. А библиотеки - нет. Cкpипaч(644 знак., 23.06.2024 13:29)
- Можно поподробней о разнице между библиотекой и модулем? И то и
другое переиспользуется в разных проектах, в чём разница то? - VladislavS.(23.06.2024 14:00)
- Django это библиотека, а алгоритм регулирования давления двумя
насосами на одном частотнике - модуль :) Cкpипaч(529 знак., 23.06.2024 14:15 - 14:34)
- Библиотека это цивилизованное переиспользование кода, а модуль
тупая копипаста из проекта в проект? Чёт сомнительно. - VladislavS.(23.06.2024 14:23)
- Несовсем копипаста, CVS-репозитарий никто не отменял, но в принципе - да. Самый короткий путь - прямой. - Cкpипaч(23.06.2024 14:29)
- Библиотека это цивилизованное переиспользование кода, а модуль
тупая копипаста из проекта в проект? Чёт сомнительно. - VladislavS.(23.06.2024 14:23)
- Django это библиотека, а алгоритм регулирования давления двумя
насосами на одном частотнике - модуль :) Cкpипaч(529 знак., 23.06.2024 14:15 - 14:34)
- Можно поподробней о разнице между библиотекой и модулем? И то и
другое переиспользуется в разных проектах, в чём разница то? - VladislavS.(23.06.2024 14:00)
- Нужно не путать библиотеки и модули. Есть собственно программа,
состоящая из дерева модулей и есть используемые библиотеки. Если
заказчику понадобилась хоть немного иная программа - дерево модулей
копируется в отдельный, новый проект. А библиотеки - нет. Cкpипaч(644 знак., 23.06.2024 13:29)
- Значит показалось. А как вы вообще библиотеки делаете, если там
постоянно в функциях что-то переписывать приходится? Это то мне
хоть не показалось? - VladislavS.(23.06.2024 12:54)
- И не я. Cкpипaч(86 знак., 23.06.2024 12:53)
- Не я предлагал gsm-библиотеку править. - VladislavS.(23.06.2024 12:51)
- Вы меня с кем-то перепутали. - Cкpипaч(23.06.2024 12:45)
- В голове должно что-то срабатывать задолго до момента когда вы
решаетесь править чужие библиотеки. - VladislavS.(23.06.2024 12:42)
- Мы живем не в стране розовых пони, вы забыли? :) - Cкpипaч(23.06.2024 12:29)
- Я не знаю что такое "в bsp нет свободных". У заглушки в любом
случае должен быть штатный интерфейс и вы его напишете. Какая
разница в модуле или классе? У меня, например, есть готовый
порт-пустышка. Светик будет думать что всё работает, а реально он
никуда не подключен. - VladislavS.(23.06.2024 11:40)
- Разница огромная. Если у вас есть функция, где происходит переход
от прикладного уровня к аппаратно-зависимому, то можно нужные две
строчки поставить там. Без (1) введения новых классов и
прочесывания прикладного кода, на предмет где подправить
инициализацию, и без (2) засорения библиотек, ради частных случаев
применения. - Cкpипaч(23.06.2024 11:41)
- Это потому что у вас спагетти-код и неправильное разделение на
абстракции. - VladislavS.(23.06.2024 12:03)
- Вам виднее :) *Именно на этом мы и зарабатываем деньги. - Cкpипaч(23.06.2024 12:14 - 12:55)
- . - VladislavS.(26.06.2024 23:06)
- Вам виднее :) *Именно на этом мы и зарабатываем деньги. - Cкpипaч(23.06.2024 12:14 - 12:55)
- Это потому что у вас спагетти-код и неправильное разделение на
абстракции. - VladislavS.(23.06.2024 12:03)
- Разница огромная. Если у вас есть функция, где происходит переход
от прикладного уровня к аппаратно-зависимому, то можно нужные две
строчки поставить там. Без (1) введения новых классов и
прочесывания прикладного кода, на предмет где подправить
инициализацию, и без (2) засорения библиотек, ради частных случаев
применения. - Cкpипaч(23.06.2024 11:41)
- Когда вы принимаете решение использовать чужую библиотеку на
развитие которой не можете влиять, то приниманте на себя все риски.
Какая разница как она написана? Даже если вляпались в какашку,
кто-то держит пистолет у виска с требованием обновить её? - VladislavS.(23.06.2024 12:26)
- При чём тут винегрет? Да, есть драйвер I2C_GPIO, он сам себя
инициализирует, если до того не вызывали. Да, оно под капотом и
кишки наружу не торчат. Но функция включения светодиода в
приложении вызывает ручками вписанную (назначенную) функцию от
этого драйвера или от CPU_GPIO (драйвер, как ни странно, тоже
бывает нужен). И она действительно чихать хотела как оно
реализовано. В CPU_GPIO может быть bit banding, работа с Set/Reset
регистрами, может быть чтение-модификация запись Vit(890 знак., 23.06.2024 12:44)
- Всегда есть особенности реалищации, но не надо делать из этого
винегрет. Светодиод не должен заниматься проверкой инициализации
порта. Это дело самого порта. Если у вас такой хитрый порт, то и
наворачивайте его логику. Оставьте светодиоду светодидово. Так код
будет проше и понятней. - VladislavS.(23.06.2024 11:14)
- Это впорос реализации, но не применения. У меня приложение вызывает
функцию управления функциональным узлом - светодиод обмена данными
включить. Под капотом оно и проверит, а инициализирован ли драйвер,
если нет, то запустит инициализацию, и другие проверки, ну или
просто дёрнет GPIO. Класс там у драйвера или модуль (как
идентифицированная единица компиляции) с набором функций - это не
суть важно. - Vit(23.06.2024 10:57)
- Сам бог велел спрятать всё это непотребство в класс расширителя и
выдать светодиоду интерфейс пина к которому он подключен. - VladislavS.(23.06.2024 10:26)
- у меня расширители PCF8574/A и PCA9534/A с жесткой адресацией на
шине. естественно стоит автодедект. но в зависимости от варианта
аппаратной сборки подключается разный набор светодиодов (да и
некоторых ключиков питания). причем сами эти расширители имеют
внутри разную физически конфигурацию выводов - в PCF8574/A
неотключаемая подтяжка, а в PCA9534/A включаемая. для управления
ключиками это важно. светодиоды всегда можно погасить и тут же
зажечь как нужно (вспомная анекдот о Vit(114 знак., 23.06.2024 10:16)
- У вас же расширитель имеет интерфейс обычного порта и предоставляет
доступ к пинам так же как gpio контроллера? И повесить светодиод на
пин расширителя можно так же как на пин контроллера? - VladislavS.(23.06.2024 09:49)
- Эти идеальности не всех посещают. У меня вполне уживаются и светики
на GPIO, и светики, подключенные через I2C расширители. И для этой
группы устройств в базовом проекте туча таргетов для 6-и процов
(один кетайский), 2 типа ядер, 3 типа периферии проца, под
конкретные конфигурации плат (там есть несколько исполнений с тучей
разных интерфейсов и т.п.) с выбранной индикацией (со своими
разношерстными расширителями)... Сильно проще идти от прикладной
задачи, имея подготовленные Vit(3 знак., 23.06.2024 09:30)
- Зачем вы свои проблемы на меня перекладываете? Беру схему, в
заголовочном файле описываю (именно описываю) что куда подключено.
Для светодиода это пин и наличие инверсии, для eeprom порт i2c, для
синтезатора частот порт spi и пин gpio для контроля ФАПЧ и т.д. А
дальше забота компилятора всё это связать. Нет никаких двух и более
мест, по которым вы зачем-то рыскаете. - VladislavS.(23.06.2024 09:12)
- У вас есть неявное предположение что все LED гарантировано ведут
себя одинаково. Я в таком случае введу прикладной номер LED, а то какой номер, к какому биту какого регистра
относится - спрячу внутри модуля bsp. Cкpипaч(236 знак., 23.06.2024 09:12)
- Гарантия одна, в методе включения светодиода не использовать ни имя
регистра, ни номер бита. Использовать абстракцию, я же приводил код
метода LED::On(); VladislavS.(123 знак., 23.06.2024 09:03)
- Я - буду. Поменяю имя регистра или номер бита, если нужно. А как вы
получили гарантию что не регистр, не не номер бита никогда не
изменится в вашем случае? - Cкpипaч(23.06.2024 08:41)
- Вы противоречите своему примеру идеалного метода включения диода в
который поместили работу с битами и регистрами конкретного
контроллера. Вы этот метод будете переписывать раз за разом, а я
нет. Битовая арифметика с регистрами на каком-то уровне всё равно
появится, но этот уровень ниже чем у вас. Gpio, spi, i2c, usb - это
всё должно быть прослойкой абстракциией, позволяющей писать
прикладной уровень не думая для какого контроллера ты пишешь.
Написана эта абстракция VladislavS.(97 знак., 23.06.2024 08:28 - 09:05)
- Перечитал ветку еще раз - мы говорим о разном и друг друга не
слышим. Cкpипaч(556 знак., 23.06.2024 07:39)
- Я максималист. И преждевременная оптимизация - моя слабость и смысл
жизни. К счастью, современные компиляторы позволяют расслабиться.
Уже можно не оптимизировать. И так получится хорошо... За
исключением простыней конфигураций ввода вывода и прочего
жонглирования битами. Абстракция позволяет тонко отделить
необходимость обращения к аппаратуре как указано, без оптимизации
самого обращения, от комбинирования данных при этом обращении.
Честно говоря, я до сих пор не программирую Nikolay_Po(75 знак., 22.06.2024 19:04)
- преждевременная оптимизация - смертный грех для инженера, прямиком
в ад. - General(22.06.2024 20:12)
- К счастью, благодаря прогрессу компиляторов, грешу всё меньше. - Nikolay_Po(22.06.2024 20:30)
- Вы меня не услышали. Операции с регистрами НЕ ДОЛЖНЫ БЫТЬ размазаны по прикладному коду. Настройка ли периферии, команды ли
в регистры общего назначения, они должны быть внутри функций,
реализующих (при взгляде снаружи) действия прикладного понятийного
уровня. Cкpипaч(576 знак., 22.06.2024 19:58)
- Ну да. И функции для управления периферией - тоже не должны "быть размазаны". Samx(288 знак., 10.07.2024 00:49)
- Возможно, вы сильно обобщаете. В конкретном коде с вводом-выводом,
я не припоминаю каких-то особых излишеств. Просто красиво
настраивается периферия. Без лишних повторных обращений к одним и
тем же регистрам, чем грешит, в частности, HAL STM. И защищаю плюсы
с этой точки зрения. Вроде, ничего там по прикладному коду не
размазывалось. - Nikolay_Po(22.06.2024 20:34)
- Есть такое, чрезмерное обобщение грех того же порядка что и преждевременная оптимизация :) - Cкpипaч(22.06.2024 20:39)
- преждевременная оптимизация - смертный грех для инженера, прямиком
в ад. - General(22.06.2024 20:12)
- А почему бы не экономить, особенно если это бесплатно делает
компилятор? И не преждевременно, а всегда и без устали. - VladislavS.(22.06.2024 22:49)
- Тут вот какая штука... Дополнительная абстракция бит, позволяет
оптимизировать код на этапе компиляции. Причём так, что
последовательность действий над волатильными регистрами аппаратуры
сохраняется, обеспечивая требуемые последовательности ввода-вывода.
И, при этом, биты разных объектов, принадлежащие одному регистру,
упаковываются в одну операцию, а не в последовательность. Nikolay_Po(107 знак., 22.06.2024 18:45)
- Т.е. желание впихуйнуть операции над битами в совершенно иной слой
абстракции - неистребимо. Принято. Лично я так делать не буду. И
подчиненным не позволю. - Cкpипaч(22.06.2024 18:27)
- Лишний слой абстракции - это как полиэтиленовый пакетик, в который
заворачивают пульт от ТВ, чтобы сохранить его первозданную красоту.
В растрёпанный от долгой эксплуатации полиэтиленовый пакетик.
Подсмотрено у старшего поколения :-) - SciFi(22.06.2024 16:01)
- Не надо думать о слоях и о том что лишнее, а что не лишнее. Главное
- написать решение задачи/алгоритма понятно (для людей) и в
терминах предметной области. Об эффективности компилятор и др.
позаботятся. - Costic(22.06.2024 16:42)
- Вредный совет detected. НУЖНО думать о слоях. НУЖНО проектировать
системы "сверху - вниз". НУЖНО изолировать аппаратно-зависимые слои
от чисто прикладных. Я потом объясню почему. - Cкpипaч(22.06.2024 18:00)
- Я выше написал про fread/fwrite. Никто же не думает о слое с секторами. И пользователи (программисты) socket'ов не думают как там PHY работает и какие регистры там нужны. И о socket-ах тоже не все хотят думать, т.к. есть классы-обёртки в том же Boost.Asio. - Costic(22.06.2024 19:00)
- Мы пробовали писать так, как рекомендует товарищ Costic. Мой коллега умышленно добавлял уровени абстракции везде, где ему
только показалось, что это может хоть когда-нибудь пригодиться. Я удивился. А он пояснил (не дословно, смысл): "Я не
знаю, как потом я буду развивать этот код дальше. Поэтому
предусматриваю эти абстракции, чтобы можно было удобно вмешаться на
любом уровне." На моё возражение, что, быстродействие может
пострадать, он ответил: "Какое у Nikolay_Po(870 знак., 22.06.2024 18:59)
- Ключевое: symbions(266 знак., 23.06.2024 13:08)
- Вот, на мой взгляд, неплохой пример класса, описывающего полностью всё семейство eeprom 24C. Можно ещё концептами обложить, но в угоду совместимости с отсталыми компиляторами это не сделано. VladislavS.(5 знак., 23.06.2024 08:59, ссылка)
- Я всегда ввожу уровень абстракции, если в этом месте может быть применена разная реализация. Тот же пин на котором висит светодиод может быть портом AVR или STM32 или быть проброшен по радиоканалу и включать шифрованными сообщениями "к чёрту подробности" на другом континенте. Код светодиода от этого не меняется, компилятор сам всё свяжет. - VladislavS.(22.06.2024 23:05)
- ЧИ-ТА-БЕЛЬ_НО-СТЬ! (орет) Мужики, вы издеваетесь?! Представьте, вы
пришли на новое место работы, получили в руки работающую систему и
несколько относительно несложных задач. Вопрос - сколько раз вы
скажите "спасибо" человеку, нагородившему сто-пятьсот промежуточных
классов и сотворившему форменный ооп-спагетти код?! Cкpипaч(375 знак., 22.06.2024 20:15)
- Человека, "нагородившего сто-пятьсот промежуточных классов и сотворившего форменный ооп-спагетти код", я пойму. И пойму его код. Или сделаю заново... - Nikolay_Po(22.06.2024 20:17)
- Вредный совет detected. НУЖНО думать о слоях. НУЖНО проектировать
системы "сверху - вниз". НУЖНО изолировать аппаратно-зависимые слои
от чисто прикладных. Я потом объясню почему. - Cкpипaч(22.06.2024 18:00)
- Не надо думать о слоях и о том что лишнее, а что не лишнее. Главное
- написать решение задачи/алгоритма понятно (для людей) и в
терминах предметной области. Об эффективности компилятор и др.
позаботятся. - Costic(22.06.2024 16:42)
- Всем нужна, все <gpio.h> используют. Но написать GPIO
толково на С++ пока никто не может. Средства С++ и современные IDE
имеют подсказки и помогают писать код. Т.е. на этапе написания кода
уже могут исключаться ошибки, т.к. IDE предложит только
ограниченное множество портов, пинов и иных объектов в зависимости
от контекста. Даже компилировать не надо, как у Владислава. А это
повышение производительности труда, которая тебе очень нравится. - Costic(22.06.2024 19:40)
- Этот код - демонстрация НЕ смешивания областей определения. Там где
определен Fucking_Silly_Led_On() не используются биты. Вообще. Ни в
явной форме, через ООП-прослойку. Cкpипaч(328 знак., 22.06.2024 18:27, ссылка)