It is so cool to see this working with minimal (if annoying) changes to the Pi! Thanks for taking the time to explore this topic. I will be leaning on your work for my own 6502 SBC.
I certainly thought it was worth covering a little bit - it’s easy to overlook when you learn the RX/TX basics and don’t need flow control until much later :)
Neat! I'm often frustrated, while trying to get a serial connection (a "simple" serial connection) between two computers by how many different possibilities there are for flow control and no flow control, and the problems that arise when two computers both eschew flow control, but they still drop characters, showing that they clearly need it. It's interesting to see it implemented on your 65uino!
For the kernel boot messages: check the kernel command line. The documentation says that the console=ttyS0 line takes flow control information from the second passed parameter. So to have ttyS0 be configured for RTS/CTS flow control at 9600 baud with no parity you’d have this: console=ttyS0,9600n0r
That part is actually in the video :) For the kernel in Raspbian though, that part doesn't seem to be compiled in, so console=ttyAMA0,4800n8r only sets 4800 baud, no parity and 8 bits ... but doesn't make it respect CTS.
Short version of how RS-232C flow control is supposed to work: If XOFF/XON flow control is used, the transmitter is supposed to monitor incoming bytes and if an XOFF byte is received, the transmitter side should pause transmission and wait for an XON byte to be received before continuing sending. If CTS/RTS flow control is used, then the transmitter is supposed to check RTS before sending each byte and wait for RTS to be enabled before transmitting the byte. Unfortunately, the advent of very fast CPUs has caused many programmers even at the system level to just assume that the receiver can handle whatever speed has been selected and so the transmitter programs often do not implement any form of flow control. This is a very common but very poor practice and illustrates how common "lazy programming" has become.
Yup. But note the transmitter should check (its) CTS - not RTS. I hope the correct meaning came across in the video even if I misnamed RTS as CTS in the 6502 code.
Leave a comment and come say hi on Discord - I promise nobody bites: discord.gg/kmhbxAjQc3 :)
It is so cool to see this working with minimal (if annoying) changes to the Pi! Thanks for taking the time to explore this topic. I will be leaning on your work for my own 6502 SBC.
I certainly thought it was worth covering a little bit - it’s easy to overlook when you learn the RX/TX basics and don’t need flow control until much later :)
Hey Anders, GREAT explanation of flow control. Keep it up man!
Neat! I'm often frustrated, while trying to get a serial connection (a "simple" serial connection) between two computers by how many different possibilities there are for flow control and no flow control, and the problems that arise when two computers both eschew flow control, but they still drop characters, showing that they clearly need it. It's interesting to see it implemented on your 65uino!
There's also matter of noise - doesn't take very long wires to make serial data into complete nonsense. But at least 9600 baud is rather forgiving :)
For the kernel boot messages: check the kernel command line. The documentation says that the console=ttyS0 line takes flow control information from the second passed parameter. So to have ttyS0 be configured for RTS/CTS flow control at 9600 baud with no parity you’d have this: console=ttyS0,9600n0r
That part is actually in the video :) For the kernel in Raspbian though, that part doesn't seem to be compiled in, so console=ttyAMA0,4800n8r only sets 4800 baud, no parity and 8 bits ... but doesn't make it respect CTS.
Hi I would send gcode from esp32 to an old CNC could you help me? My friend said me this CTS control
If it's a really old CNC router you might need RS-232 (+-10V signal levels). Hard to say without knowing anything about the device :)
@@AndersNielsenAA we should talk another place. It's a sigma vc1000
You’re welcome to come hang out on Discord and ask in the #project-help channel - it doesn’t sound like I’ll be of much help though
@@AndersNielsenAA ok thanks I'm writing there
Short version of how RS-232C flow control is supposed to work: If XOFF/XON flow control is used, the transmitter is supposed to monitor incoming bytes and if an XOFF byte is received, the transmitter side should pause transmission and wait for an XON byte to be received before continuing sending. If CTS/RTS flow control is used, then the transmitter is supposed to check RTS before sending each byte and wait for RTS to be enabled before transmitting the byte.
Unfortunately, the advent of very fast CPUs has caused many programmers even at the system level to just assume that the receiver can handle whatever speed has been selected and so the transmitter programs often do not implement any form of flow control. This is a very common but very poor practice and illustrates how common "lazy programming" has become.
Yup. But note the transmitter should check (its) CTS - not RTS.
I hope the correct meaning came across in the video even if I misnamed RTS as CTS in the 6502 code.
@@AndersNielsenAA Yeah, I got confused. The receiver requests sending, and the transmitter checks that it's clear to send. I have to remember that.
Murazik Terrace
I'll assume that's a name - but I'm not sure you can tag people in UA-cam comments :)