caxapa.ru :: Т.е. желание впихуйнуть операции над битами в совершенно иной слой абстракции - неистребимо. Принято. Лично я так делать не буду. И подчиненным не позволю.

Cкpипaч^пророк (22.06.2024 18:27, просмотров: 824) ответил Costic на Для инженерных задач, думаю, такая библиотека не нужна. Но манипулирование битами это то средство в языке С, с помощью которого предметная область "электротехники" отображается (mapping) в алгоритмах и программах. По-хорошему, нужны средства (классы, операторы, функции, множества) для описания предметной области. Современный С++ может предоставить эти средства.

Т.е. желание впихуйнуть операции над битами в совершенно иной слой абстракции - неистребимо. Принято. Лично я так делать не буду. И подчиненным не позволю.

... но не любой ценой.

Ответить

- Тут вот какая штука... Дополнительная абстракция бит, позволяет оптимизировать код на этапе компиляции. Причём так, что последовательность действий над волатильными регистрами аппаратуры сохраняется, обеспечивая требуемые последовательности ввода-вывода. И, при этом, биты разных объектов, принадлежащие одному регистру, упаковываются в одну операцию, а не в последовательность. 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)
        
        За более чем тридцать лет в бизнесе, не припомню ни одного договора, в котором бы оговаривался размер кода в байтах :) - 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)
        
        Так вы, коллега, "шататель основ"?! 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)
        
        В прикладном коде вам нужно будет найти инициализацию объекта 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)
        
        Бугага! (только пожалуйста не обижайтесь, это не переход на личности) А как насчет необходимости по-быстренькому подменить пару входов заглушками, потому что в целевом 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)
        
        Я не знаю что такое "в 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)
    - Я максималист. И преждевременная оптимизация - моя слабость и смысл жизни. К счастью, современные компиляторы позволяют расслабиться. Уже можно не оптимизировать. И так получится хорошо... За исключением простыней конфигураций ввода вывода и прочего жонглирования битами. Абстракция позволяет тонко отделить необходимость обращения к аппаратуре как указано, без оптимизации самого обращения, от комбинирования данных при этом обращении. Честно говоря, я до сих пор не программирую 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)

Средства и методы разработки