Комментарии 18
Часть 2. Проверка идеи
Ахаха. Всё давным-давно украдено до нас, например: https://habr.com/ru/companies/ruvds/articles/766250/
Прям дежавю :) С COM-портами в былинные времена так извращались, то модемные линии как эрзац-GPIO использовали, то вообще "лишние" контакты не по назначению использовали (например, +5V подвести) :)
В камере Aqara g2h D+ D- используется для UART как RX TX
А я плюсанул.
Вот серьёзно, читаю и думаю, ну для чего это может пригодиться, ну ведь отлаживаемся всегда и так на проводках и нормально. И в продакт такое не закинешь: если есть вариант не так воткнуть кабель, то его именно не так и будут всегда втыкать.
А потом дочитал, что отлаживать изделие в корпусе. И тут что-то проникся идеей. Ну реально есть такие кейсы, когда не удобно, или опасно вскрывать корпус при отладке, или вообще корпус на работу завязан.
Так что автору спасибо, в копилку интересных идей себе закину.
Однако, следует помнить, что для отладки программатор нужно втыкать определенной стороной.
Так возьмите microUSB - там не перепутаешь, тем паче вы выбрали SWD (2 сигнала всего). Зачем с тайп-си так заморачиваться?
Так я же написал, USB должен работать как нормальный порт. Я считаю плохой практикой вешать на D+/D- (и RXn/TXn+/- тоже) что-то левое, тем более в устройствах, которые выпускаются не в единичном экземпляре
Т.е. в доступном пользователю тайп-си будет в числе прочего прямой доступ к SWD? Считаю плохой практикой вешать на пользовательский что-то левое, способное окирпичить девайс, тем более в устройствах, которые выпускаются не в единичном экземпляре.
Когда деревья были зеленее, а контактов в разъёме USB было меньше, использовались аппаратные решения на базе микросхем USB-switch: в кабель на стороне device добавлялся резистор на пин ID, а USB-switch на основе анализа номинала сопротивления внутри девайса аппаратно коммутировал DP/DN к USB/UART/SWD/whatever you want...
Я сейчас погуглил назначение пина ID, и мне ваш вариант автосвитчинга понравился. То есть, если установить определенное напряжение на ID со стороны устройства (не ноль и не питание), и пользователь воткнет в устройство OTG-кабель (ID в ноль установится), то он ничего не нарушит в логике работы. И при этом, зная "кодовый" уровень напряжения на ID, мы (разработчики) можем переключить функционал D+\D-.
Один минус - отладить USB не получится, т.к. ноги заняты другим интерфейсом.
Во первых, это не документированная функция, во вторых обновление прошивки также возможно через бутлоадер (т.е. потенциальное окирпичивание) без SWD.
Если стоит задача защитить устройство от окирпичивания путем прошивки, то можно просто не выводить никаких интерфейсов наружу, даже через id switching
Считаю ваш пример проблемы надуманным
В последнее время заказчики хотят Type-C - это для них модный тренд, видимо. Не понимают только, что это привнесет в устройство проблемы и повышение стоимости.
Почему нельзя по аналогии с D-линиями использовать SBU1 и SBU2 для SWDIO, а СС1 и CC2 для SWCLK (соединив SBU1 и SBU2, CC1 и CC2)? Тогда бы можно было подключать программатор любой стороной.
А я не понял. Вот есть обычный клон ST-LINK, который работает по USB 2.0 с ST-LINK Utility. Чтобы сигналы SWDIO и SWCLK передавать по линиям SBU1/2, нужно пилить свой софт для отладки, который будет этими линиями на компьютере управлять?
На плате (Зелёная на фото) распаян кастомный ст-линк, на входе у него обычный стандартный USB, на выходе - SWD over SBU
Программируем и отлаживаем STM32 через USB Type-C порт, не нарушая спецификации USB