Приступив к работе с Артери вместо СТМ, я внезапно обнаружил, что, несмотря на идентичность почти всей периферии, хедеры написаны не в дефайнах констант, а как структуры. Дефайны конечно тоже есть, но они для читабельности значений полей структур. И они не требуют перректальных инверсий и логических операций в ините. И потому очень наглядная настройка посредством определения значения поля структуры стала чрезвычайно читабельной и удобной. В отличии от.
Подход с битовыми полями для volatile регистров делает настройку еще и чрезвычайно не эффективной, потому большинство производителей его не использует.
потому большинство производителей его не использует.
Это для погромиста он не эффективный, патамушта погромист сегодня работает в одной команде. а завтра в другой. Сегодня он пишет для стм, а завтра для инфинеона. Правда не очень понятно с "эффективностью". Вы выбираете только те чипы, где есть "эффективные хедеры"? Очень странный подход. С точки зрения эмбедда выбирать чип нужно с точки зрения технической и экономической целесообразности, а не для облегчения жизни программиста. У нас, например, вообще нет специальных программистов. Есть радиоинженеры, которые умеют писать код. На Си или на АСМе, либо и на том и на другом вместе. Этот код перекрестно понятен всем участникам процесса. А вот набор чипов как раз сильно ограничен. Из-за логистической целесообразности. Естественно, что можно обосновать любой другой чип. Но только не из соображений "эффективного хедера" или удобной IDE.
Именно так. А когда имеется инициализация в критическом коде, то там нужно смотреть что генерирует компилятор. И целесообразность может быть совершенно иной. И точно она не относится к читаемости. Достаточно комментов.
чтобы PORT_A_CONFIG состоял из понятных определений.
Во-первых, макросы - зло. Во-вторых, в пределе я ничего не хочу знать о регистрах. Понятные определения это вот так - выберется только то что существует в контроллере. И само установится. Спойлер --------
в пределе я ничего не хочу знать о регистрах. Понятные определения это вот так - выберется только то что существует в контроллере.
Это все конечно хорошо, только когда касается типовых интерфейсов в типовых применениях. А как дело доходит до нестандартных применений типового или уникальных, то все эти "понятные определения" тихо идут лесом.
Покажите мне подсказку для CC1E, потому что у меня с решарпером ее нет, а мощнее решарпера я ничего не знаю.
не должны столь простые вещи вызывать затруднения. вот я создал новый файл, воткнул сверху макросы и оно само пытается угадать, чего я хочу и пытается угадать почти правильно: Спойлер я там успел только '=' ввести.. да, понятно, скорее всего оно уже подсмотрело, что я обычно делаю и начинает подсовывать наиболее подходящие варианты, но я то не против..
Цитата:
Но писать то придется, а преимущества вашего подхода слишком незначительны чтобы компенсировать это вместе с прочими недостатками. И писали вы для одного из самых примитивных мк. Структуры для F103 в стандартном хедере занимают 420 строк, а для H563 - 1450. Для H503 хедер другой, т.е. даже в рамках одной серии не надорваться нужно раз 6, а серий полно, мне нужно хотя бы 5. По нормальному это уже нужно утилитку писать )
сгущаете. простыми регулярками выдрать список всей периферии или регистров из заголовочника -- ничего сложного. пример:
вытащит все имена периферийных блоков для h573, сколько бы там строк ни было. регистры -- по аналогии. и определения битовых полей. и... и понятия не имею, какие они там. только вот не понял, зачем 6 раз? я не пишу универсальных библиотек в намерении осчастливить все человечество. я для себя пишу, а мне не нужно много.
Есть радиоинженеры, которые умеют писать код. На Си или на АСМе, либо и на том и на другом вместе. Этот код перекрестно понятен всем участникам процесса.
а я то не понял сначала, в чем дело.. знакомый надысь собеседовался в известную фирму. после собеса уже в частном порядке ему там сказали, что совершенно напрасно он припомнил свой эмбедерский опыт. у них там существует негласная установка этих самых "радиоинженеров" не брать. слишком уж своеобразно они "умеют писать код".
ему там сказали, что совершенно напрасно он припомнил свой эмбедерский опыт. у них там существует негласная установка этих самых "радиоинженеров" не брать. слишком уж своеобразно они "умеют писать код".
А зачем радиоинженеру работать программистом? У радиоинженера совершенно другие задачи. Поэтому он занимается либо чистой схемотехникой. либо схемотехникой и зависимым от нее кодом одновременно. Каждый должен делать свою работу. У нас все проекты схемозависимы. Поэтому есть очень негативный опыт использования чистых программистов.
а категоричность, надо полагать, величайшая благодетель? В ядре линукса (6.x) свыше 20 тыс. макросов. макросы -- отличнейший инструмент в руках того, кто умеет ими пользоваться. ну а неумехе, что ни дай..
Цитата:
Во-вторых, в пределе я ничего не хочу знать о регистрах.
никто не неволит. периодически наблюдаю десктопных программистов, которые накатывают ртось и ваяют совершенно без оглядки на железо -- софтом, ногодрыгом, да как получится. увлечение абстракциями -- оно порой довольно забавное. это все равно, как если бы хирург вдруг заявил, что он не желает вникать в строение организма, а хочет на некоем абстрактном уровне делать операции людям, слонам и рыбам одинаковым образом.
Цитата:
Понятные определения это вот так - выберется только то что существует в контроллере. И само установится.
смахивает на грёзы. "Создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться."
А зачем радиоинженеру работать программистом? У радиоинженера совершенно другие задачи. Поэтому он занимается либо чистой схемотехникой. либо схемотехникой и зависимым от нее кодом одновременно. Каждый должен делать свою работу. У нас все проекты схемозависимы. Поэтому есть очень негативный опыт использования чистых программистов.
насчет каких "чистых программистов" вы говорите в данном контексте, я примерно понимаю. осталось, разве что программистов 1С еще в эмбеде попробовать для полноты опыта. раз у вас радиоинженеры код пишут, то до 1С-схемотехников недалеко уж осталось. я к чему это?... если расслаивать программистов в эмбеде, то нижний уровень -- это firmware engineer, в ведении которого находятся регистры, биты, инициализация железа и все самое низкоуровневое. на втором уровне embedded software engineer -- ос, драйвера, протоколы. на третьем embedded software developer -- прикладник с эмбедерским уклоном. нету тут места радиоинженерам.
Подход с битовыми полями для volatile регистров делает настройку еще и чрезвычайно не эффективной, потому большинство производителей его не использует.
там периферийный блок описывается, как союз 32-битного целого и структуры. если писать в структуру, то доступ к каждому полю будет отрабатываться отдельно и это действительно целая портянка. если хочешь простое присваивание из трех ассемблерных команд, то используй 32-битную переменную. это довольно удобное и гибкое решение. я не очень понимаю, зачем они используют именованную структуру внутри союза. выгод совсем чуть, а громоздкость записи увеличивается.
если расслаивать программистов в эмбеде, то нижний уровень -- это firmware engineer, в ведении которого находятся регистры, биты, инициализация железа и все самое низкоуровневое. на втором уровне embedded software engineer -- ос, драйвера, протоколы. на третьем embedded software developer -- прикладник с эмбедерским уклоном. нету тут места радиоинженерам.
Вы вообще не понимаете о чем идет речь. Приведу пример. Нужно сделать обнаружитель сигналов. Например, обнаружить эффект Баркгаузена в объекте. Интерфейсы обмена у устройства самые примитивные. Пусть это будет некий проприетарный протокол на УАРТе, например. Причем обнаружитель должен быть конкурентным с какой нибудь китайской конторой, которая эти обнаружители делает уже лет 10 или 15. Тупое повторение схемотехники китайского образца дает себестоимость товара раза в 1,5 ... 2 выше, чем цена покупки у китайцев. Китайцы продают это изделие конкуренту, а конкурент демпингует. В каком месте тут firmware engineer, embedded software engineer и, не побоюсь этого слова, embedded software developer? Эта вся братия годится, чтобы сделать телематический терминал в трамвай и метро. Неплохо у них получается пожарная охранка и даже частотный преобразователь на основе референсного проекта из аппноты и готового сигнального кода из библиотеки производителя МК. И все. Сделать что то оригинальное и потому конкурентное эта публика не в состоянии. Патамушта к радиотехнике не имеет никакого отношения.
судя по всему, ваша контора либо бедная, либо руководство жадное. естественно квалифицированных специалистов вы и не могли видеть. вот поэтому радиофизики код пишут.
судя по всему, ваша контора либо бедная, либо руководство жадное.
Не вижу логической связи. Если программист ничего не смыслит в радиотехнике, то невозможно решать текущие задачи с его помощью. У нас был опыт работы с программистом. Это тихий ужас. Код он писал очень правильный. Но проще написать самому. Точнее, написать самому - это единственное решение. Его, кстати, уволили.
Извините, что вмешиваюсь, но "сделать самому" проще только в одном случае - если не можешь объяснить, что надо делать, другому ("не можешь заплатить", как я понимаю, вычеркиваем).
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
А мне было с кем обсуждать? Поделитесь своим портфолио радиотехнических проектов. Возможно вы будете нам интересны. Но меня терзают смутные сомнения. ЗЫ. Не бывает жадных или бедных. Бывают рентабельные и не рентабельные проекты. Разработчик не должен выйти из бюджета R&D. А этот бюджет определяет планируемая тиражность и сроки окупаемости. Иначе это выброшенные на ветер деньги.
Если программист ничего не смыслит в радиотехнике, то невозможно решать текущие задачи с его помощью.
Точно. В двух конторах сталкивался с такой фигнёй под названием "программист". Эти мальчики нифига не смыслят в предметной области, а мне за пересказ им учебников не платят. Поэтому проще и лучше делать работу с объектом самому, чем пытаться донести до патлатых гениев как и что следует делать.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения