Does your computer have a real RS-232 port?
Most computers I am aware of no longer have RS-232 ports. These have been replaced by USB ports.

 

With a $2 microcontroller chip, you can have as many I/O pins as you desire.

 

Does your computer have a real RS-232 port?
Most computers I am aware of no longer have RS-232 ports. These have been replaced by USB ports.

I have a USB -> serial adapter and it does seem to work as expected. The only downside is that there's only 1 pin on the port that's worth anything. The data-transmit line will pass a series of bits extremely fast (of course). But that's it. I can't do anything else. No clock signals (as pointed out, it's async), no 2nd transmission line. I either need to use a 2nd computer on the receiving end, or some kind of UART shift register that can automatically detect the baud rate (based on an initial 0x55 data signal), then begin processing. I haven't had any luck with locating a single, solid solution for this approach. Again, probably because I'm too green on this stuff.

 

With a $2 microcontroller chip, you can have as many I/O pins as you desire.

Do share. Link?

 

Let's say you are using 9600 baud.. this means you have 9600 symbols per second.. since a typical 8-bit transmission ends up being 10 symbols, you get 960 bitss per second = 120 bytes/sec....not fast enough... so, move up to the next common level for UART transmissions until you get one that meets your requirements...

38400 baud gives you 480 bytes per second, which should be enough...

Some of those USB to TTL converters can only operate at 9600 baud...

assuming my math is right, of course...

 

I design networked systems for industrial applications. I can put as many I/O devices on to one USB network as you wish.

 

Let's say you are using 9600 baud.. this means you have 9600 symbols per second.. since a typical 8-bit transmission ends up being 10 symbols, you get 960 bitss per second = 120 bytes/sec....not fast enough... so, move up to the next common level for UART transmissions until you get one that meets your requirements...

38400 baud gives you 480 bytes per second, which should be enough...

Some of those USB to TTL converters can only operate at 9600 baud...

assuming my math is right, of course...

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!!!

 

I design networked systems for industrial applications. I can put as many I/O devices on to one USB network as you wish.

Hmmm... interesting idea..... two USB-serial adapters...... use one for data flow, the other for clock signal.... basically hack it into a clocked system. Maybe that's not what you're suggesting but.... maybe I'll try that.

 

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!!!

You can pack your "unused bits" with pertinent data... since you say you are only using 3 bits from the byte, why not two 3-bit peices of data? Can't the uC generate clocking signals on it's own, instead of transmitting output clock pulses?

 

You can pack your "unused bits" with pertinent data... since you say you are only using 3 bits from the byte, why not two 3-bit peices of data? Can't the uC generate clocking signals on it's own, instead of transmitting output clock pulses?

Good point on the clock signal I just have to make sure it's in sync with the updates reflected on the GPIO pins because this would just be a distribution point for the data as it spreads out into 256 separate pins.

As for the data packing.... Not sure how that could work. The data has to be used in sequence or the whole data flow would trip over itself. I added those extra bits in there only because I don't think there's a way to configure my serial port to send any fewer than 5 pins, and it mandates a stop bit. Just wasted data bandwidth.

Leaving work now... thanks for all your help!

 

If a microcontroller is going to let me pass binary between C# and a set of digital in/out pins at a very high speed, then can you recommend one that can do this faster than the pokey 142hz digital i/o board I've already tried? I know there are a lot of fancy microcontrollers out there but if I use one it's sole job is literally going to be to herd bits from a USB/serial port onto a set of GPIO pins as fast as possible.

Thanks for tolerating my idiocy.

Okay, now you have thrown USB into the mix. Up to this point everything you have said has strongly implied you were talking about an RS-232C serial port.

Which is it? The two are nothing alike.

There are boards you can purchase that connect to your USB port and do just what you want, provided you can accept the latency issues associated with USB. They are cheap and pretty mcuh plug and play.

 

Okay, now you have thrown USB into the mix. Up to this point everything you have said has strongly implied you were talking about an RS-232C serial port.

Which is it? The two are nothing alike.

There are boards you can purchase that connect to your USB port and do just what you want, provided you can accept the latency issues associated with USB. They are cheap and pretty mcuh plug and play.

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.

 

Hmmm... interesting idea..... two USB-serial adapters...... use one for data flow, the other for clock signal.... basically hack it into a clocked system. Maybe that's not what you're suggesting but.... maybe I'll try that.

You have your mind fixated on a clocked serial shift register.

In a networked system, each node is uniquely addressable. All nodes receive the same packet of data but each node only accepts data addressed to it. No serial shift register is needed.

 

They are cheap and pretty mcuh plug and play.

I bought and tried a Measurement DAQ digital I/O board which has 24 i/o pins. I thought this would be the right way to go. It connects via USB and has a universal C# library.

The problem: I can only change the 1/0 value on any given pin once every 7 or 8 milliseconds due to the way the library is implemented and/or the way the device works, and that is is multiplied by the pin numbers too, so updating all 24 pins via C# takes a 1 or 2 tenths of a second This is not nearly fast enough.

If you know of another digital I/O board that can do this faster, I'm all ears. I even have funds to go above the cheap-o range of products.

 

You have your mind fixated on a clocked serial shift register.

In a networked system, each node is uniquely addressable. All nodes receive the same packet of data but each node only accepts data addressed to it. No serial shift register is needed.

Understood, but then if they decided long ago that serial data would not contain any timing information or clock signals, why didn't they go the full distance? Now when you have data like this: 1000000001 the receiving end just sees two ups with a long down in the middle, and it's up to the receiving end to interpret what the long "down" means. A third value used as a kind of data parser would have been really helpful and allow us to skip a boatload of awkward interpretation/timing issues:

1 -1 0 -1 0 -1 0 -1 0 -1 0 -1 0 -1 1

 

Now you have to get down to the dirty details:

1) Is this an industrial where conditions can be extreme?
2) Exactly how many inputs and outputs do you require?
3) What are the output current and voltage requirements?
4) Do you require isolation on all I/O lines?
5) What is the distance between the PC and each node?
6) Do you need RS-485 interface?
7) What update rates are you requiring?

If you are willing to pay for industrial components, here are some examples of USB interfaces:

http://www.bb-elec.com/Products/Remote-I-O/USB-I-O/Plug-and-Play-Data-Acquisition-Modules.aspx

 

Understood, but then if they decided long ago that serial data would not contain any timing information or clock signals, why didn't they go the full distance? Now when you have data like this: 1000000001 the receiving end just sees two ups with a long down in the middle, and it's up to the receiving end to interpret what the long "down" means. A third value used as a kind of data parser would have been really helpful and allow us to skip a boatload of awkward interpretation/timing issues:

1 -1 0 -1 0 -1 0 -1 0 -1 0 -1 0 -1 1

You need to read up on NRZ and phase encoding (Manchester coding).

 

You need to read up on NRZ and phase encoding (Manchester coding).

Good lead..... will check this out...

 

Good lead..... will check this out...

Interesting data manipulation but it seems this is still highly dependent on the duration of each data pulse, so what do we gain by this? The receiving end still has to decide whether the rising/falling edges are meaningful or overhead, and use timing guesses to make those decisions. ???

 

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.