When I runt the program, the serial data from the Uno goes to /dev/ttyACM0. I was wondering why this is the case. I know that the Rx and Tx pins are shorted to the Atmega16U2 chip on the PCB which allows it to transfer data to/from the USB on my PC. BUT in my case, it is also connected to another USB port via the USB-to-UART bridge. How does the board decide to use the /dev/ttyACM0 port?
that doing implies you are connecting two outputs together.
Thanks, I was thinking about that but I am not educated enough on digital design to know it honestly. I'll be looking into this.
Did someone already wonder why you are doing
I just ran some code that was meant for the Mega by mistake on the Uno and I got really curious about what was happening. Thanks for all the responses.
I have an UNO on COM1 and I have FTDI USB-TTL board connected to COM3
I have a putty terminal connected to COM3.
The UNO TX pin is connected to the FTDI RX pin.
The UNO is printing to Serial.print and I see the data in the serial monitor and putty terminal
to mean that @jim-p is "listening in" on the UNO TX pin by routing it through the FTDI to a second port on the PC.
Your Python receiver is adequate, but real terminal programs like PuTTY and CoolTerm make all kindsa experiments with serial communications very easier.
ManY times it is fruitful to play with a serially controlled device using just a terminal emulator. Obvsly this is less useful if the serial protocol uses non-printing characters.
You have to appreciate the tradeoff, but I like things like NMEA, all carried out in printable characters so you can see and generate the traffic with just a terminal program.
Naturally the price is paid in the larger number of characters required.