Комментарии 14
Чет я смотрел этот либопенсм3, он скорее мёртв, чем жив. Апдейтов в репе почти нет, тяжёлая периферия поддерживается не вся, не везде и не полностью.
Может я не прав и не туда смотрел?
Пс подгон хала и лл под смейк делается за пару дней в первый раз.
Меня в проекте libopencm3 их замашки впечатлили, столько много контроллеров. А в этом прожекте я замахнулся не на сборку а на написание еще одного такого же хала. Но пока готов разве что нормальный api под GPIO и три USB примера (HID клавиатура, геймпад, USB-UART). Вообще все такие проекты я считаю обреченными, т.к. ИМХО, невозможно создать мало мальски универсальный APi для работы с железом, тру вариант всегда ручками флаги в регистрах выставлять.
Это можно реализовать через хорошую систему типов языка, когда по сути те же флаги в регистрах превращаются в имена типов. Тогда можно на compile-time проверить допустимость комбинации флагов. Я когда-то реализовывал это на шаблонах C++, сейчас это же реализовано в экосистеме Rust (низкоуровневый набор библиотек там сгенерирован автоматически по SVD-файлам). А вот в libopencm3, к сожалению, так и не появилось, там предлагают только набор из большого количества функций под готовые варианты, а то, чего в этих вариантах нет, действительно приходится конфигурировать вручную флагами в регистрах. Примерно так же сделано в CMSIS, но в CMSIS код обычно генерируют тулкитом производителя чипов.
Я тут не решаюсь обычный C++ подкинуть, потому что тащусь когда прошивка в 5 килобайт упихивается (а с плюсами будет все 8-10). А про rust не слышал, помню разве что попытки утолкать java в МК и те были неудачными, потому как те МК уже стоили как полноценный ARM с линуксом.
Кстати когда пересобирал speex, явно ощутил что оперативки в притык, и это на обычном Си. А еще я помню времена Attiny когда printf был непозволительной роскошью.
За то, если работает, то код получается в два раза компактнее (проверено на stm32f7 + usb). Там надо смотреть на многочисленные pull-реквесты и их выборочно применять, если что-то не работает
Вот я для того и писал еще раз что бы васины пулл реквесты не разглядывать. Вы кстати на фамилии авторов USB ST HAL внимание обращали? Фиг пойми кто, каких то аборигенов наняли на аутсорсе, а потом копайся в их вызовах функций по указателю, тройных переобертках каждого регистра и макаронинах из ифов на 200 строчек без всякого намека на последовательность. Ага, типо в просмотрщике pdf забанили нуну, буду я там в реквестах копаться.
Здесь имеется ввиду opencm3, а не ST HAL
Ничего против карла п не имею, даже себе блок питания на opencm3 импульсный с регулировками собирал, разобрал на доработку, как соберу обратно будет пост. Реализация USB не впечатлила, понял что проще еще раз чем в ней разобраться. А главный прикол это расхождение в том, как должны выглядеть макросы. У libopencm3 перед битом название регистра, у меня просто название бита, вот поэтому еще раз и начал писать тоже самое. По периферии у меня не густо, но по USB уже больше практических примеров.
Сейчас состояние дел в Rust для STM32 лучше, чем в C для STM32. Из коробки работает не только периферия процессора, но и большая часть распространенных внешних устройств. Для USB из коробки поддержаны профили модема, HID, MIDI и может быть еще какие-то.
По разводке примечательно то что можно не брезговать выводить контакты
из под чипа через неиспользуемые порты, главное не подать на них
случайно единицу в коде, в остальном такой грязный хак помогает получить
очень компактные платы.
Возможно я ошибаюсь, но ГЛАВНОЕ не включить "пин" как "выход" , если необходимо оставить его в пассивном состоянии, тогда он не повлияет на состояние даже если в выходной регистр записать 1.
И даже если, по не ведомым причинам, хочется "пин" держать как "выход", тогда его надо как раз держать в "1", и режим "открытый исток", потому что при записи "0", пин как раз БУДЕТ влиять на выход. Если "пуш.пул" тогда "нога" при любом раскладе влияет и мешает.
В общем тут какая то двойная ошибка рассуждений.
Хорошо, подать уровень напряжения соответствующий логической единице при замыкании контакта на землю, вместо просто подать единицу. Зачем расписывать так подробно если вы и так все поняли? Или не поняли, главное что плата компактная, я вот о чем говорил.
я пытаюсь указать на ошибку в словах:
"выводить КОНТАКТ",
под это понятие попадает ЛЮБОЙ контакт,
и люди не имеющие опыта могут не правильно понять
и наломать дров.
про землю в изначальном тексте не сказано ни слова.
и иногда бывает так что под брюхом ИМС проложены
сигнальные дорожки для компактности.
особенно когда сигнал высокоскоростной и
любой лишний миллиметр портит фронт или
срывает фрагмент в "звон", на частотах 10 МГц "огибающая" частота может быть хоть 1 ГГц, хоть 10 ГГц.
(подробности в книге:
Грэхэм Мартин, Джонсон Говард, Конструирование высокоскоростных цифровых устройств )
Инстинктивно придерживаюсь правила из ANок к STM. Так что бы один слой был землей, а второй питанием, при чем оба должны быть похожи на сплошной полигон. Понятно что там говорилось про трех слойку (земля/сигналы/питание), но и так пойдет. Сигнальные дорожки прямые, как можно короче. В обеих платах перевернул входы/выходы USB порта, обведя один из выводов через соседний неиспользуемый GPIO. В обеих платах под контроллером только земля, которая в нескольких местах соединена через неиспользуемые порты.
Компактный make для STM32 с USB