I think you can do what the OP wants, with a bit of lateral thinking.

The serial data out of the PC serial port always starts with a start (LO) bit, then has the 8 data bits, then a stop (HI, which we can just ignore).

Assuming the baudrate is known, you need an external device to generate clock pulses, as the serial port is already generating the data. This turns the asynch serial into SPI type clk+data two wire serial that can go directly into shift registers.

The external device would detect the start bit, then after a delay of approx 1.5 baud makes a clock pulse, followed by 7 other clock pulses with 1 baud between each. This task could be done with a PIC etc or could even be done using discrete logic chips if you are a masochist.

But the premise is sound; that the PC sends standard serial data and a clock stream is added on another wire, and the two signals can be sent directly into a long chain of shift registers as the OP requested.

thank you for this

 

How I feel:

"I have a really fast and powerful computer which I can run programs on. I want to write a program that sends raw binary data out to a set of metal pins, which I will connect to an otherwise isolated electronic circuit which does things with that data, such as turn on lights, motors, servos, etc., all directly commanded by my fast computer."

You want to send digital data out on in a serial signal and then you want an isolated electronic circuit to do things with that signal by taking the data on the serial siignal and interpreting that signal as a bunch of commands.

Gee, sounds like you want that isolated serial signal to process the digital data presented to it on that serial signal.

Gee, what do we generally call an electronic circuit that processes digital data?

What I keep hearing:

"Your really fast computer can't do that. You have to send the binary data to a small, really slow, incredibly inferior computer first. That computer has general input/output pins as you request. Unfortunately, the small computer is really slow, has almost no memory, and also will not run your programs because it's such a limited device. Good luck."

You very much can build a circuit to do what you want without using an FPGA or a micro or any such thing., particularly if you are willing to give up auto baud rate detection. But if you want to do anything more than update about eight individual signal levels with each byte sent over the link, then you can do that fairly easily, though not necessarily very reliably.

You are missing a couple of big points here:

First, the RS232 and USB protocols are intended to allow two *processors* to communicate with each other! Generally, one of them is much more capable than the other -- thats why they are communicating in the first place. The small one is small and cheap because it isn't being asked to do a whole lot, so it sends data to the big one, which does the heavy processing, and the little one is only asked to do the processing it is intended to do.

Second, yes, your computer can do lot's of things that a braindead microcontroller can't do on it's best day, but what you need done CAN be done by a braindead microcontroller and it can do it in several ways that your high-powered computer can't - namely it can do it while taking up less space than a dime, probably run completely off power sucked off the serial data lines, and do it at a cost of under a buck.

 

I started with serial ports because many are fond of pointing out how trying to program through a USB port is so much trickier than serial. That said, I'm open to ANYTHING that will allow me to connect C# and a circuit in the described way. Serial seems to be the best bet, but then again, the serial port I'm using is actually just a USB adapter.

If USB will work somehow, I'm open to it. Please recommend the device you feel will be a good path for me to explore.

This is information provided mainly by people who don't program USB.

It is actually easier and cheaper.

 

I figure it this way:

To get 256 uniquely refreshed bit values all the way out onto my imaginary 256-pin register, I must send 1 value signal and 1 clock signal for each bit (512 so far), plus 1 latch bit (513 now), and each of those 513 bits is accomplished by one "bit chunk" from the PC to microcontroller, and that's 6 to 10 bits apiece (most of those are wasted, I'll only use 3 for the register shifting), which means 513x10 (worst case scenario) or 5130 bits of data send from my PC to completely refresh the 256-bit register. To do that at 9600 baud would not even be twice per second. If I can just send 5 bits from PC to microcontroller then I get close to 4 updates per second.

Need more speed!!!

What speed do you need?! The story seems to keep changing. you've talked about 24 bits, now your talking about 256 bits.

What is it you NEED?

How many independent digital channels?

Maximum time to update all channels with a new value?

Do all channels need to be updated simultaneously?

If you want 256 channels, then are you planning on stringing a dozen or two discrete shift registers together?

If you want that many outputs, then use an FPGA and put the UART or SPI or USB or whatever interface in it? I did a similar interface in an FPGA many years ago. I had 256 bytes of register space that was writable from the PC and 256 bytes of register space that was readable from the PC. I used an ASCII command interface and writing to each register required six characters be sent at 19200 baud. So I could update 32 registers (256 bits) in about 100ms. Some very simply changes and I could have updated a run of 256 bits in less than 40ms at that same baud rate. I could have cut that in have by using binary instead of ASCII. The UART I designed for that supported software flow control and echo-back.