8
In short, you don't.
The SoftwareSerial implementation for AVR doesn't have an outbound buffer at all.
It just turns the interrupts off during each character outbound and it sends them all immediately.
This means a call to SoftwareSerial's write simply will block until all of the data you've tried to send has in fact been sent. If you can't afford to wait ...
7
There is an open source project that will do what you want.
http://com0com.sourceforge.net/
The com0com will create virtual com ports for the programs to connect to.
The hub4com will allow you to route data between the physical port and multiple virtual com ports.
http://com0com.sourceforge.net/hub4com/ReadMe.txt
3
If your goal is to "talk" to a computer vs. a human, then a format that can be parsed easily is better than one that is easy to read.
For example, you have:
I received: 255
I received: 247
I received: 11
I received: 0
While this could be parsed by your Uno, it will be a lot simpler if you send the data something like:
255|247|11|0
Now you can use ...
2
You can't. Putty has no way of disconnecting without closing the program (as far as I can tell).
You could try "Tera Term" which apparently (though I don't use Windows so have no experience with it) has a disconnect option (which you would have to use before uploading).
Alternatively, as @Juraj has mentioned, you could use a separate USB to TTL ...
2
The fact that you're referencing ttyUSB0 tells me you have cheap Chinese clones and not genuine Ardunios. These are usually based around the CH340 USB interface chip which is notoriously unreliable.
Your UNO is dead.
My supposition is that plugging it in cripples the CH340 driver. Any other boards that you subsequently plug in can not be recognised because ...
1
running:
sudo usermod -a -G dialout $USER
cleared the issue it was the first time I have used that machine with an Aduino not sure how it was running before with out permissions set up correctly or why it failed when I dropped that 5v, I assume that just reset the board and when it tried to reconnect it failed. Both board and PC all working fine, phew.
...
1
I can think of three distinct ways (and one that is similar to another) of doing what you want.
But first a note on polymorphism. The HardwareSerial class is itself a child of the Stream class. It's this Stream class that provides all the read/write functionality (it, itself, is a child of the Print class which provides all the print(...) functions).
If all ...
1
This is actually a huge topic, one that I could write volumes on. However I will try and be concise. But it is such a common question it's time to finally write a definitive answer.
Sending data between devices, be that computers, Arduinos, or anything else like that, is very much like speaking to someone.
It is very common to do something like you have done ...
1
After trying many different alternatives, it turns out that my mistake was that, foolishly, I had included Serial printing inside my ISR routines, which where accessed when my interrupt fired, in order to wake my uP. As a result, Serial.print was called, with Serial being closed (before issuing the Serial.begin command to restart it), thus breaking my uP.
...
1
I figured out the problem. The for loop was writing one byte at a time, which probably wasn't fast enough and caused a timeout in the arudino. The code is now:
page = 0
for x in range(128): # 128 pages in 32K eeprom
datalst = []
for i in range(256):
datalst.append(data[(page * 256) + i])
ser.write(datalst)
#wait until ...
1
I have solved the bug, you can see the writeup on the Lasersaur google group. The short of it was that this was a software bug, which was only being triggered when the hardware conspired to have some timing delays. I'm still unclear why the behavior was inconsistent previously - I must have been on the borderline of the data delays causing an issue or not.
Only top voted, non community-wiki answers of a minimum length are eligible
