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

На данный момент у меня такой план - запаять rx на pio11, а tx, на pio10. На pio11 повесить функцию piodebounce с интервалом 1мс, длительность 10мс. И по приходу события, переводить pio10 в низкое на 10мс.

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

2. Что-то паять придется в любом случае. Какая разница припаять пару проводов или мелкий простой чип.
Соединять напрямую между собой PIO концы, запрограммированные как выходы, не очень хорошая идея. CSR не дает точной информации, как аппаратно выполнен этот двунаправленный порт внутри чипа. Поэтому и микруха у китайцев появилась не просто так. Судя по всему таким способом они соорудили схему "ИЛИ по нулям" смешивания сигналов TxD и какого-то PIO, запрограммированного под сигнал BRAKE

Совершенно верно. И скорее всего управление идет
по 2-й ноге чипа 74 ( лог. 1 в режиме транслятора и лог. 0 в режиме брик), а 5-я нога посажена на питание (+), а выход со следующим входом соединен для того, что бы вернуть инвертированный сигнал обратно к прямому.. Нельзя просто так взять и посадить шину UART. Надо сделать точно так же как у китайцев.
lprot
покупай чип 74

veloseeped а почему ИЛИ? Разве там не 2И-НЕ ?
А свой АМБ ты наверное убил статикой.

На BC417 PIO умеют работать как в режиме входа так и в режиме выхода.
Как weak pullup с большим сопротивлением так и strong pullup с маленьким.
Читать как минимум должно получиться.

Ну а с посылкой break, посмотрю сегодня open drain ли у нас TX...

Глянул даташит и собственно:
UART_TX CMOS output, tri-state, with weak internal pull-up UART data output
UART_RX CMOS input with weak internal pull-down UART data input
PIO[11] Bi-directional with programmable strength internal pull-up/down Programmable input/output line
PIO[10] Bi-directional with programmable strength internal pull-up/down Programmable input/output line

Ну а что если с выхода тх сигнал завести ( перемычкой ) на свободный порт ( в режиме входа) и прошивкой транслировать его на еще один свободный порт но уже в режиме выхода. И из него уже брать наш ТХ? Тогда с этим выходным портом можно в прошивке делать что угодно.
Пришла команда на выход из прозрачного режима - сбросил этот порт на нужное время и опять его транслируешь.

Задержка будет больше. Обновил инфу выше. Буду пробовать от простого к сложному...
Идея попробовать сначала weak pull down запараллеленый на TX.

А как обратно в прозрачный режим переключается модуль и что он должен выдать инфинеону?

Ничего не выдает, так как перед посылкой команды перевода обратно в прозрачный режим, Infineon шлет SET_EVENT_FILTER 02 - требуя докладывать ему только о разрыве соединения при помощи UART break сигнала.

Ну тогда дело за малым))) надеюсь у тебя все получится))

----------

А сразу с rx нельзя принять команду чтобы не использовать pio11? Нужно же правильно принять команду ( в рамках временного пакета и с учётом стартового и стопового бита ) иначе могут быть ложные переходы и тем самым глюки в работе.

Нельзя принять через RX, так как длина низкого сигнала в три раза превышает длину 10бит. И контроллер UART ловит его как ошибку передачи не индицируя сообщением в программу которая выполняется в виртуальной машине.