Arduino IO Expansion

Yeah Tommy is pretty much correct in the fact that 1.5Mbaud does not equal 1.5Mbit because there are wasted bits.....start, stop, parity, address, etc

In a purely digital system, one voltage equaling zero (0v) and another voltage equaling 1 (5v) baud rate with be the same as bit rate. It's when they start using voltage levels other than 0v & 5v, as given as the values (this includes single end voltage converted to differential voltages), that the difference starts happening. This is for simple serial comms, have not studied how manchester encoding for example would affect this.

I noticed your definition seems to be google's AI definition.

blazini36 wrote:

Yeah Tommy is pretty much correct in the fact that 1.5Mbaud does not equal 1.5Mbit because there are wasted bits.....start, stop, parity, address, etc
 

That will affect the overall byte rate, not the overall bit rate. If fact Tommy's definition made no mention of of protocols, which stop-start-parity etc would be part of.
When designing hardware for the transmission of serial data any control bits or bytes don't come into the equation.

I still believe that spi can be used instead of serial communication and have a real time component.
If possible, have someone with the necessary hardware try this and report back
Many thanks

Yep have the hardware.
Nope doesn't work the way you propose.

Tried with a 500mm cable between my RPi5 and a 7c81 board, SPI fails even below the rates for a USB to arduino serial connection. In actual fact even having a grounded conductor between each SPI signal and trying to send signals from one pcb to another is not reliable over a distance of about 75mm.

From experience high speed serial communications, RS-422, SATA or whatever you want to try requires differential signalling, which causes timing issues with SPI. I researched this about 12 months ago.

cornholio wrote:

blazini36 wrote:

Yeah Tommy is pretty much correct in the fact that 1.5Mbaud does not equal 1.5Mbit because there are wasted bits.....start, stop, parity, address, etc
 
That will affect the overall byte rate, not the overall bit rate. If fact Tommy's definition made no mention of of protocols, which stop-start-parity etc would be part of.
When designing hardware for the transmission of serial data any control bits or bytes don't come into the equation.
 

So your argument is that Baud rate = Bit rate?

This started cuz you said "a Mesa card using a smart serial daughter card would be the go, operates at 2.5M bits per second over a Cat5 cable"

"and from Mesa manualsIn the operate mode, the baud
rate is set to 2.5M baud (default)."

You said
"In a purely digital system, one voltage equaling zero (0v) and another voltage equaling 1 (5v) baud rate with be the same as bit rate."

OK but a 1/2 duplex RS485 line at 115.2Kbaud is running the same baud rate of a full duplex RS485 line running at 115.2Kbaud right? You don't say full duplex is double the baud rate do you? Full duplex does not have to switch the data line from Rx to Tx or vice versa to switch directions so it can technically transfer up to double the amount of data depending on whether the 1/2 duplex link has to switch directions at all.

If it switches even once you can't say that both links transmitted the same amount of data in the same amount of time at the same baud rate unless you say "well overall, not accounting for direction".....OK well in that case the full duplex link can still potentially transmit literally double but it's completely unpredictable.

data rate, or "bit rate" is ALWAYS "theoretical" or average, it is never absolute. Baud Rate is not absolute either but it is relative. Bus frequency is absolute, even if it is dynamic. It's all semantics covered in nonsense, personally I would say "Mbit" and mean "Mbaud" and not expect to be corrected but I won't argue that they are the same thing.

Fuck there goes my new year's resolution, getting caught up in stuff like this.

cornholio wrote:

When setting the baud rate (divisor) on a 8250 or the later variants it will always be tied directly to the time allowed for each bit.
 

Lol yeah, that's how all asyncronous serial works. What do you think you are setting when you set "115200" on a COM port? Divide that baud rate into 1 and get the "time allowed for each bit". It's just easier to ask people to set the baud rate on the COM port than it is to say "gimme the period of time in us/ms". Anything that happens a specific number of times within a second is a period, you just forgot to do the division.

Yeah sure there are serial protocols the will define a zero has being so many us and one has being another value, which no one has yet to mention, but each period for either 1 or 0 will be an absolute value. 

Like what? What protocol is that? That would literally be something that has no predefined data rate because the rate you can transfer data specifically relies on the difference between how many 1s are in that package vs how many 0s are in that package.

Morse code is not a serial protocol, it's a method of spelling the alphabet by using human understandable events, like flashes of light or sound. There is no precise timing involved, just perception. You can't perceive the difference between 1us and 1ms and a machine would have a hard time trying to figure out what the hell some outrageously long and inconsistent "dot" is.
 

This one is close to 30 years old, I wrote a win95 device driver in assembly many many moons ago, ones & zeros of different length. I also manged to squueze a basic master station into a 16f84 all done in assembly.
www.nmra.org/sites/default/files/standar...C/S/s-92-2004-07.pdf


www.testandmeasurementtips.com/morse-cod...munication-protocol/

Then there's "Manchester encoding" used by ethernet.

We can also encode 1 & 0 as a certain frequency or shifting the phase.

The PCIe bus transfers data serially, at far greater rates than the parallel ISA & PCI buses could.

PS/2 is another way of sending data serially.

SPI is somewhat different in that the transfer of data is controlled by a clock are controlled by a clock. Bits can be shifted in & out depending on the clock polarity, of course you wanna define this beforehand.

Human generated speech is serial in nature, supposedly Tibetan throat singers can generate more than one sound at a time. Then again sound is serial in nature, as is light.

Even the written word is serial in nature, unless of course you are some rare type that can ingest a whole page of words at once. I don't know if this is even possible.

Even the parallel port could be considered serial in nature, talking to printer requires sending the data at one byte at a time, even 32 bit transfers end up being broken into 8 bit chunks.

PAL, SECAM and NTSC sent data in a serial fashion.

This is kind of going off the rails now. I quite happy to not totally agree with you but also not think you are a fascist.

Wow, off the rails is definately where that went.....fascist? Where on earth did that come from? We're talking about serial protocols....I don't think I tried to suppress your freedom from my keyboard.

Point was you theres some kind of misunderstanding about how asyncronous serial works, even though that post was edited out of existance now. I have no idea what this last post has to do with anything. All I said was in service to Baudrate != Bitrate. Though it's generally OK to colloquially just say it like it does.