Изучаем STM32 Cortex M3

[Yuri222]

А вообще в природе есть отладочные платы под это дело? За вменяемые деньги?

Есть. У СТМ - ардуиноподобная платка (на STM32F072) со вторым этажом (там 2 стм-овских контроллера USB PD и 2 разъема USB-C). Стоит очень дешево, что-то около $15.
Также есть отладка (STM32F072 + FUSB307). Стоит намного дороже.
Преимущество FUSB307 - делает и sink, и source, сама считает crs и автоматом отправляет подтверждение по USB_C, соединяется только одной шиной I2C с контроллером. В то время как STM-овская микра (1602 кажется) сама crc не считает и к контроллеру нужно цеплять и I2C, и SPI.
По ценам оба контроллера (1602 и FUSB307) примерно одинаковы.
Для подешевле можно взять "ардуину" на 072-м и микру FUSB307 припаять проводками (у нее более-менее нормальный корпус QFN-16 c шагом 0,5 мм).

[p_v]

А появление STM32G серии я походу пропустил ...
Неужели с USB-PD все так плохо?

Ну как сказать...

- Если STM часть кода распространяет в виде блоба, создавая лишний гимор по встраиванию, это плохо или нет?
- Если единственная осмысленная опенсорсная реализация требует RTOS, это плохо или нет?
- Имплементации коммерческого происхождения сопровождаются мутными лицензиями, вместо MIT.

Оно, с одной стороны, вроде формально есть, и даже наверное работает. Только вот хочется руки вымыть с мылом. Я как-то отвык, что разработчики библиотек сопровождают свои поделия странными дополнительными требованиями, на ровном месте.

Вот систематизированная инфа по всем интернетам: https://gist.github.com/puzrin/f737b...1bb4d8525e6606

Я конечно могу понять STM32G.
Но FUSB302 - там чисто I2C дергать с соответствии с стандартом. Что там может пойти не так?

Интерфейсы библиотек там пошли не так. То что есть, кратко описывается словами "говно говна".

На аппаратном уровне, железки по-моему даже по регистрам совпадают. Разница в том, что у FUSB302 обмен идет через i2c (с которым логично работать через DMA ) + пин прерывания. А у STM32G DMA и прерывание напрямую.

А вообще в природе есть отладочные платы под это дело? За вменяемые деньги?

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

Пример кода для FUSB302B: https://github.com/ReclaimerLabs/USB-PD-Breakout
В формате Ардуино, но как как пример.

В том-то и дело, что больше чем на пример это не тянет. А мне нужна нормальная библиотека с простым интерфейсом (понимание как это может выглядеть у меня есть).

[p_v]

Есть. У СТМ - ардуиноподобная платка (на STM32F072) со вторым этажом (там 2 стм-овских контроллера USB PD и 2 разъема USB-C). Стоит очень дешево, что-то около $15.
Также есть отладка (STM32F072 + FUSB307). Стоит намного дороже.
Преимущество FUSB307 - делает и sink, и source, сама считает crs и автоматом отправляет подтверждение по USB_C, соединяется только одной шиной I2C с контроллером. В то время как STM-овская микра (1602 кажется) сама crc не считает и к контроллеру нужно цеплять и I2C, и SPI.
По ценам оба контроллера (1602 и FUSB307) примерно одинаковы.
Для подешевле можно взять "ардуину" на 072-м и микру FUSB307 припаять проводками (у нее более-менее нормальный корпус QFN-16 c шагом 0,5 мм).

Как разработчик опенсорсов, я вижу разницу только в наличии библиотек. В плане удобства они везде одинаково уродские .

По железу в нынешнее время есть смысл смотреть только FUSB302 и STM32G. Они достаточно доступны, максимально дешевы, и перекрывают большинство потребностей, которые можно вообразить.

По фичам, учитывая когда это все может понадобится в кастомном девайсе, я бы забил болт на все фиксированные профили из PD 2.0 и юзал только PPS из PD3.0. То есть, делать:

- только SINK, 1шт, на выделенном порту если i2c
- только PPS
- без поддержки управления зарезервинованной мощностью (когда текуще устройство не активно и зарядник хочет перекинуть резерв на другой порт)

Тогда получится простой интерфейс, который перекроет 99% задач (если вы конечно не разработчик зарядников и хабов).

Остальные фиксированные профили поддерживать можно, но смысла нет. Все новые зарядники идут с PPS за те же самые деньги. Через пару лет других на рынке просто не останется.

[DanilinSA]

Если договоримся, я куплю и пришлю, в вечное пользование.

Тут есть один нюанс: у меня основной язык - Паскаль. Соответственно софт для "большого брата" пишется на Embarcadero® Delphi 10.3 А софт для ARM пишется на "mikroPascal PRO for ARM". Я конечно разберусь и напишу либу, но это это будет модуль для mikroPascal
Хотя потом можно портировать без проблем. Ибо программы на Паскале с листа читают да-же малограмотные в программировании лица.
Так что покупать мне не стоит - либы на Си написать не смогу. Максимум портирую на "mikroC for ARM". Так что если "разобраться" - возможно подпишусь. Если "написать библиотеку на Си" - я пас.

P.S: Сейчас трахаюсь с BLE стеком на STM32WB55. Трахаюсь со стандартным софтом и доками так, что после этого секс с женщинами это скучное и утомительное занятие

[p_v]

К сожалению, тут паскаль не подойдет. Во-первых, потому то для широких масс он нафик не уперся (я ж хочу не только для себя лично). Во-вторых, там нужна особая макросовая магия типа прототредов, чтобы просто сесть на таймер и не юзать RTOS (но так чтобы код не скатился в ад).

Кому интересно - пока осилил завернуть сборку кубовского выхлопа в PlaformIO https://github.com/puzrin/reflow_mic....ini#L116-L139.

Я видимо пока кубовский вариант помучаю. Но если у кого-нибудь возникнет желание прославиться в веках, сделав нормальную библиотеку, то предложение насчет ковра и телевизора в силе. И с проектированием тоже помогу, расписав "правильное" апи.

[p_v]

Есть вопрос про GPIO speed (low/medium/high). А как это аппаратно реализовано? Если я выберу низкую скорость, ток тоже упадет?

Вот мне надо рулить симистором. Скорость (фронты) там по меркам процессора без разницы. А вот ток довольно приличный, 10-40ма, в зависимости от типа. Для тяжелых случаев аж 3 ножки MCU надо параллелить. Этим ножкам надо скорость на максимум загонять, чтобы необходимый ток тянули, или ток со скоростью не связан?

[NewWriter]

Ну ёлки-палки, уж про "скорость портов" то давно вопрос снят то. Это обычный формирователь крутизны фронта. Как крутизна фронта формируется при переключении мосфета? Номиналом резистора в затворе. Чем меньше резистор в затворе, тем больше скорость перезарядки ёмкости затвора и тем круче фронты на выходе. Соответственно, чем меньше резистор в затворе, тем больший ток протекает через этот резистор, и тем больше сказывается на обсчем потреблении в целом.

[DanilinSA]

Не нужно ноги MCU паралелить. Хорошим это не кончится. Просто поставь простенький драйвер для управления симистора. Например полевик с управлением логическим уровнем.

[NewWriter]

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

[p_v]

Не нужно ноги MCU паралелить. Хорошим это не кончится.

Это стандартное решение для трика, которое широко используется. Например AN863. Для stm32 тоже были упоминания, неохота искать. Нет смысла лепить в схему лишние детали без нужды.