3) если есть совесть.

GitHub по сути - это история ошибок.
Отсутствие возможности сразу создавать проекты на национальных языках не моя ошибка, а ошибка GitHub-а.
Думаю они скоро ее исправят.

И вам советую не симулировать в своих текстах английские комментарии, а нормально писать их на языке который лучше знаете.

Хех, я частенько открываю свои старые или чужие проекты в Keil, и если там русский текст, то начинается перебор кодировок - ANSI? UTF? Win1251? А на английском никаких проблем.
Есть и обратная сторона - с английского не все могут правильно перевести.

Иногда, комментарии на русском языке могут быть обязательным требованием заказчика/работодателя.



Поэтому я всегда стараюсь писать комменты на инглише. Эта путаница с кодировками сильно утомляет. Особенно когда одни и те же исходники редактируются в разных операционках (Win <-> macOS/Linux).

[off]


Вы уж как-нибудь определитесь, люди используют в работе HAL потому что у них совести нет, или потому что "ничего сложнее примеров от ST не делали". А то выглядит это все как какой-то подростковый максимализм. Вы наверное еще винду не любите, потому чтА "маздай"?
[/off]

Мой рунглиш и китайцы, и англикосы нормально прочитают. А что они с вашим рашкинским будут делать?

А еще тогда, когда надо чтобы работало всегда, например, safety critical. Так, к слову, некоторые очень любят исполхзовать Linux, чтобы, например, лампочкой поморгать... Выбор инструментария и ответственность эа результаты его применение целиком лежит на разработчике. Нельзя запретить желающим писать с кубическим акцентом...

Вот щас всё брошу и начну думать как же китайцы будут мои программы читать?
Если оно им действительно надо пусть приходят с мешком юаней и вежливо спрашивают - "Что уважаемый лаовай хотел сказать своим комментарием в строке 1234?".
Ну, или пусть гуглом переводят.

Взглянул я на ваш github.
У вас там просто нечего читать. У вас фактически нет коментов. То ли вы их не научились еще писать, то ли тяжко писать их на неродном языке.
С такими текстами вы не заинтересуете ни англоговорящих, ни русскоговорящих.

Я не комментирую то, что не нуждается в комментариях.
Если функция со свистом влезает на одну страницу кода, а аргументов у нее один-два, комментарии можно и не писать. Как и вещам вроде "два+два=четыре".
Остальное комментирую вполне достаточно.
P.S. И не надо на мой быдлокод смотреть! Я не программист.

Сообщение отредактировал Эдди - Feb 23 2018, 12:58

На самом деле, именно для процессоров ST, HAL просто совершенно необходима, особенно начинающим.

Это связано с тем, что их периферия сделана совершенно безобразно и, практически, не описана (I2C, RTC - это просто кошмар какой-то, DMA тоже хороший подарок и т.д.). Как она на самом деле работает, и как преодолеть ее ошибки можно понять только одновременно глядя в исходники HAL, RefMan и DS.

Можно, конечно использовать уже адаптированные RTOS, но на не слишком сложных задачах как-то не хочется.

Видал еще и индивидуумов, которые осилили только буквы и пишут на ужасном транслите

А лампочкой поморгать это safety critical? Как вообще лампочка связана с safety critical? Вообще удивительно какой бардак у многих в голове.

Ok, зайдем с другой стороны, как вы подтверждаете safety critical? Ваш софт проходит сертификацию на DO-178B, например, или вы просто по "пацанский зуб даете"?

Какой-нибудь управляемый L2 коммутатор D-link или soho роутер от них же, ни разу не лампочкой поморгать, но в нем скорее всего обычный линукс. И там это решение вполне оправдано, так как там не стоит задачи в спец. сертификации. А вот на бортовом вычислителе боинга 737 вы линукс не встретите, и не потому, что он сильно сложнее, а потому, что сделав вычислитель на линукс вы упашетесь его сертифицировать и доказывать что оно надежно. Потому что в настоящем safety critical надо доказывать, а не просто трындеть.

Если проект подразумевает safety critical с соответствующей сертификацией, то он подразумевает и соответствующее количество трудочасов и денег на него. В рамках этого проекта, естественно, разумно выделить группу для написания надежной замены ST'шному HAL'у. С которой потом, можно будет пройти все сертификации. А когда у вас задача спроектировать железку без доп. требований по надежности, а вы все равно тратите время на перепись HAL'а, полагая (почему-то?), что ваш быдло код лучше "индусского", вы просто разбазариваете время и деньги, отвлекаясь от основной задачи.

Далеко не всегда вопрос в сертификации. Например, делал в свое время вендинговую систему, требования - повышенная надежность, пришлось писать все с нуля, старался по минимуму использовать сторонние либы, особенно те, в которых плохо понимаю их принцип работы или они слишком замудрены, используют кучи всяких аллокаторов памяти и пр. В таких задачах мне не требуется какая-то сертификация, но собственные регламенты проверок и нагрузочного тестирования пришлось исполнять. Я б не смог так сделать на том же линуксе, т.к. не понимаю многое из его работы, но на кубах подобное тоже б делать не стал.

DRM довольно примитивный протокол. Гораздо проще того же Bluetooth или ZigBee. Работали небось по UART-у с чипом реализующем два первых уровня или вообще весь стек.
TCP стек и USB теперь есть в любой демке любого производителя микроконтроллеров.
Я даже не глядя скажу что это у вас был lwIP.
У вас и задач наверно было две три.

Вам на самом деле почти не нужна периферия. Поэтому извините, но мне кажется вы недостаточно в теме.

Иногда лучше жевать, а не раздавать советы по проектированию...

Во-первых, речь шла о DMR, а не о DRM;
Во-вторых, если вам человек пишет о том, что на процессоре "крутится DMR стек", это значит, что он там крутится (на процессоре), а не на каком-то специализированном ASIC'е, общающемся по UART'у c хостом. Реализованы там уровни начиная от phy. В сам процессор вводятся либо квадратуры с бэйсбенда, либо сигнал после ЧМ (зависит от версии железки);
В-третьих, по поводу стеков USB и lwIP, да, они есть в любой демке, но это не означает, что их нельзя использовать в проектах (стек USB и стек lwIP). Я работал когда-то в одной конторе, в которой зачем-то писали свой стек. Устройства, которые выпускала контора были мягко говоря так себе, потому что все были заняты изучением RFC и бдениями за Wireshark'ом, отлаживая стек, а об оконечном функционале (за который клиенты и платили деньги) вспоминали редко.



Проекты бывают разные, со своими тонкостями, но почему-то многие здесь, наплевав на тонкости, раздают идиотские советы типа "Cube и HAL" это для мигания лампочкой. Это просто признак низкого профессионализма, я так считаю.