Can we do 300khz serial communication using PBP and entry level MCU's ?

Hello.
For reduction of part count, efficiency increase and total cost decrease :) I'm implementing powering from generally available power sources, such as phone/laptop ac adapters/chargers. With 5V there are no questions, but sometimes, for proper operation of electronics, higher voltages, like 9-12-15-20V might be needed.
Currently there are several (incompatible) protocols for having higher voltages over the USB (Samsung AFC, MediaTek Pump Express, Oppo VOOC, Dart, DASH, QUALCOMM QC, USB-PD) with later two taking the dominant position on the market.

There are several ways of implementing all these in your hardware. QC (Quick Charge) is the simplest thing to do, and can be done via simple port voltage level altering at startup (can be done even using discrete components). USB PD appears to be far more complicated, but there is at least one dedicated IC, Injoinic IP2721, which can do the trick - no programming needed. However, it only supports USB PD, no support for Qualcomm Quick Charge and I'd like to have support for both for my projects. So, software solution should be made.

Details about USB-PD protocol can be found here:
https://www.embedded.com/usb-type-c-...very-protocol/

All PD messages are transmitted at 300KHz +/- 10% over the CC line. The first 64 bits (Preamble ) are an alternating 1, 0 pattern so that the receiver can synchronize with the actual transmitted clock. The next 16-bit word (Address or Type ), contains the message address, indicating the message recipient or other type information (SOP* communication explained below). The next 16-bit field contains the message header, which is encoded as shown in Figure 9. The header field includes a data object count (#Data Objects). If the data object count is 0, then the message type is “control.” If it is 1 through 7, then up to seven 32-bit data objects follow, and the message type is “data.” A 32-bit CRC is transmitted, followed by a 4-bit end of packet (EOP) token that completes the message.

Since we don't need any complex messaging, like host role exchange and other yada-yada, I guess, a simple, fixed message delivery should be enough to get the required voltage. I think I can do this via simple port bit banging and measuring each delays with scope, but maybe, there are more simple and automatically speed adjusting ways for doing this, with using something simple like PIC16F1947 and so on, without going to 18 and 24 series?

If you run Fosc at 48 MHz, then the divisor is 160 (48,000,000 / 300,000 = 160). I'm only aware of USB type PICs capable of 48 MHz. Normal 4-8-16-32-64 MHz Fosc speeds result in fractions. Maybe this helps.

Thanks!
I think, this is not standard "USB" thing, there is no need for synchronous transfers and so on. All is needed is to send proper sequence of bytes.
So I've ordered that IP2721, and when it will arrive, will just try to "record" it's output byte sequence with analyzer and just replicate it with PIC.
Existing, software based PD/QC triggers are based on STM8 chips, so I guess, PICs should also be capable.