Sry i was having complete network disconnection for 2 days.
And Writing a driver for Windows is currently out of scope as it defintely need lots of work and testing for perfect working driver.
I have finally taken the approach of Using a Raspberry Pi Pico 2 with Ethernet on LWIP Protocol for 10 Sockets on Dual core Platform just like the USB to UART Model of USB on Core 1 and Serial on Core 0.
I am looking at different methods i can communicate peripherals with PC without Extra IC.I suspect you're over thinking this. What's preventing you from using two Picos, two cables, and two ports on the USB host?
Or two Picos and an upstream USB hub?
I have seen RFC2217 ways to implement where the data has to be proccessed based on protocol it is doable for 1 or 2 but having 8 can be hectic for processing on a raspberry pi pico so i will see for more other ways in implementationI don't know much about RFC2217 and didn't get far when trying to insert a RFC2217 bridge to Telnet so I could uses 'mpremote' RFC2217 with a Telnet host running under MicroPython.
It seems you will need one of three things -
- Something on the RP235X board which understands and can handle RFC2217.
- Something to bridge between RFC2217 and whatever the RP235X board can understand and use.
The Driver code in the above diagram, as per its original incarnation, simply sends data bytes out which the remote receives, and receives data bytes returned.
- An alternative protocol other than RFC2217.
If it connected to multiple virtual ports it could send a byte indicating which port the data byte came from before that. On the return the remote can indicate which UART a byte was received from and the Driver would use that to direct received bytes to the appropriate virtual port.
An alternative would be to use multiple ethernet ports so raw byte data could be sent in the data stream with the port indicating which UART and virtual serial port each related to.
Either would be simple because I have control over the Driver code doing the interfacing. If you use something else you will have to deal with whatever that is using.
The huge advantage of what I have shown above is that it doesn't actually have to use ethernet. It could equally use USB, with a single CDC serial port used on the remote side, which would simplify things greatly, in terms of code and hardware costs.
And Writing a driver for Windows is currently out of scope as it defintely need lots of work and testing for perfect working driver.
I have done this once i guess on a Pico for 10 Serial Ports where 8 RX are the 8 Statemachines and the 2 are the Onboard UART. For the TX i Used a Demultiplexer where 1 TX is connected and controlled. It was good to use that way as we need RX Data being constantly monitored and buffered it was useful having Multiplexed TX Line.That's not strictly true.How are you working around the fact that you only have 12 statemachines?
I think the maximum you can get is 8 UARTs. Two hardware and 6 PIO. You need one for rx and one for tx.
If you can accept only one PIO controlled TX signal being active at any time then you have 11 State Machines available to do asynchronous receives in parallel, giving a grand total of 13 UART.
In many cases, perhaps almost all, not transmitting in parallel won't cause a problem.
You can also drop a UART and have 2 State Machines controlling TX signals which would only block once both were in use. And so on down to having 6 State Machines for TX where all can transmit in parallel.
I have finally taken the approach of Using a Raspberry Pi Pico 2 with Ethernet on LWIP Protocol for 10 Sockets on Dual core Platform just like the USB to UART Model of USB on Core 1 and Serial on Core 0.
Statistics: Posted by akash614 — Fri Nov 07, 2025 4:41 pm