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

Cкpипaч, пророк (22.06.2024 18:27, просмотров: 523) ответил 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)

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