I had to put it in code because it reads somewhere as code. xD
The easiest way I can:
1. You connect the cable
2. arduino gets current on 5v and gnd wires
3.The application in arduino starts (void loop () {
// set username
while (username == ""))
4.starts broadcasting:
void setup () {
Serial.begin (115200);
Serial.println ("Enter username ...");
5. Data is sent by arduino to the serial port without checking whether it is open. (I'll check if it can be fixed as well)
6. You turn on the application.
7. The application resets arduino when opening the serial
8. The DTR feature allows the app to initialize the serial and open the serial
I tried to give in the loop:
while (! Serial)
but nothing helped.
And in this sketch, the point is that the radios are still listening, if you add ACK then there is no problem with sending and confirming delivery as it is at the moment. I even made such a picture, it is the simplest explanation:
Some notes, but I don’t have an Arduino Mega so I can’t verfify this:
You can reset the CPU if you toggle Dtr as described. You have to test if it is reset by a 1 or 0, You also have to test if you need an Dtr and/or Rts set to 1 to enable communication. That depends on the program in the 16U2. (I think it preprogrammed to do USB-serial communication, but it can be reprogrammed by the user to do something else)
The explanation that the 16u2 generates spikes that will be decoded as character at this baudrate seems reasonable.
The Arduino readStringUntil() has a timeout (default 1000ms). After a timeout it probably returns what has been received so far. This means that you will always receive this “strange” characters.
It seems strange that the app ask for device “null”. You can’t open an OTG serial device until the USB cable is connected to the Mega. (there is no serial device until it’s connected). This also power up the Mega and your program is started after a short delay.
My English is poor and I don't understand a bit but for sure in Arduino Mega after checking with your program (Serial OTG) DTR must be set to 1 to reset arduino and RTS to 0 (sure works)
Ok, Rolf's notes very helpful. Main issue here is the Sketch prematurely sending the 'Welcome' message.
I have edited the Sketch to try to prevent that - it compiles but I can't test it here. I have concentrated on the App-Arduino Serial comms and largely left the radio comms as they were (except addresses).
The attached AI2 Project incorporates Rolf's notes re DTR toggle and supports sending an acknowledgement (ACK) to the Arduino to indicate the App is ready.
The serial USB terminal activates Rts, Dtr as default before opening the device. You can try if this (Set Rts, Dtr to 1 before call to Open() ) eliminates the "strange" characters. It also states that Rts should be set to 1 to enable communication for 32U4 devices like original UNO. This may also be true for Arduino Mega with a 16U2 as USB to serial converter. You can set Rts, Dtr as a property or in the program.
What I wanted to say with my previous replay was: If you get this spikes from the 16U2 when opening the serial device, the sketch will receive them as “strange” characters in the readStringUntil() statement. After a timeout you get the characters in string username. The sketch decodes this as a true input from the user.
If you set Rts, Dtr to 1, then the Arduino using 16U2 will be reset and the received characters from the open of the USB serial will be deleted. This together with the default value of Rts, Dtr explains the difference between using USB terminal and SerialOTG. It would be interesting if someone can verify this.
Sorry but you destroy my ideas completely. XD I just wanted to remove the characters from the beginning of the connection, the programs on UNO and MEGA I wanted them to be the same. The APP INVENTOR application was also supposed to be a simple application with as little code as possible. And now you give me some programs and you want me to test no matter what, my problem has been solved by DTR. If I want to cancel reading the characters at the beginning, it is very easy to do it in arduino so as not to reset the tile and not use the DTR. I dont know what you want from the test, what oyu waiting, what is target?
That is what I have done by introducing ACK into the Project and the Sketch. Toggling DTR isn't necessarily going to be a true fix for that issue, but it is incorporated in the Project as your boards may or may not have a known chip issue.
So I don't see how my work 'destroy my ideas completely' when it is simply trying to fix the problem you reported. During that process I noticed that the radio addresses were not unique and fixed that for you too.
It is.
Go ahead and do that instead then, but why raise this Topic and waste my time?
You reported a possible problem with SerialOTG. I tried to find a solution to help you and also help other users that may have the same problem. That is also why I asked that you or someone else would verify the difference in behavior between SerialOTG and the use of serial terminal.
I also want to point out that if there is a problem in software (so called bug), it’s not just about hiding it. Its about verifying what is the problem, evaluate solutions, implement a solution and verify that you have solved that problem, and not another problem.
