After a recent bad experience with a clone UNO (which I sent back to seller) I have some questions which I would appreciate answered.
When using the Arduino IDE (version 1.0.2) in "serial monitor" mode is the transmission any different depending on which board may have been selected? I do not mean the content but the protocol. For example if I type "qwerty" and click on send is that straightforward ASCII going out at some baud rate and being echoed back or is the data somehow different depending on which board (UNO or other) is selected? The reason I ask is that not only did my clone UNO fail but a friends similar unit also failed even though the sellers site has many good feedbacks about the board. I have no trouble in loopback with my "Boarduino" but it does not have the 16U2 handling the USB connection as it uses FTDI. I am sure that the wiring of the jumpers was correct. I read the UNO description in the Arduino Store site and could find answer to the question. If the loopback test does not care about baud rate (because send and receive are one and the same because of the RX -> TX jumper) then a working UNO jumpered for loopback should not care which board is selected since the AT328 and its programming is being bypassed. Am I missing something?
I had contemplated trying to reprogram the 16U2 but decided to return the board and this raised the question of whether a UNO could program its own 16U2 using the onboard ISP sockets which are separate for the AT328 and 16U2. Of course the 328 would have to be loaded with the correct program and the ISP jumpers would have to be correct etcetera but I am curious it the process has been tried by anyone.
I am waiting for a new (non-clone) UNO and hope someone can answer the above questions.
Thanks in advance.
P.S. the original discussion in the forum is here:
I had contemplated trying to reprogram the 16U2 but decided to return the board and this raised the question of whether a UNO could program its own 16U2 using the onboard ISP sockets which are separate for the AT328 and 16U2. Of course the 328 would have to be loaded with the correct program and the ISP jumpers would have to be correct etcetera but I am curious it the process has been tried by anyone.
In principle this could probably be done. To program /RESET has to be held low, but as far as I can see the 16U2 has its own reset (net name RESET2). I haven't attempted it myself. You would, of course, not be able to get serial debugging messages out (the USB port) while you were doing it. If it failed for any reason you wouldn't be able to use the bootloader any more, so you would then need an external programmer to fix things up, so you may as well get one of those initially.
In principle this could probably be done. To program /RESET has to be held low, but as far as I can see the 16U2 has its own reset (net name RESET2). I haven't attempted it myself. You would, of course, not be able to get serial debugging messages out (the USB port) while you were doing it.
Good point and reason enough to use a regular programmer, still it might be fun to try it on a spare board.
as far as:
All serial monitor does is open up the serial port. That's it.
Yes it is a serial port, and yes the port is simply opened but the question still remains: is what comes out when I type "qwerty" any different when different boards are selected? I do not know of any reason for a difference, and I could assume that there is no difference but I would rather know than assume.
turbosnail:
Yes it is a serial port, and yes the port is simply opened but the question still remains: is what comes out when I type "qwerty" any different when different boards are selected?
No. The board selected has absolutely no difference to what happens when you open the part of the IDE that simply opens the serial port.
If, for example, one board firmware uses parity bits and another does not use parity bits and one opens the serial port then depending on the board it would/wouldn't need a parity bit. Before you say that the boards do/don't use parity I am merely using the example of a possible difference in the characters of the data stream. If you do not like the parity example use BigEndian and LittleEndian. Again I do not know of any difference so my question remains, if different boards are selected would the data remain the same. To state that the serial port is simply opened does not answer the underlying question: "Is there any difference in the data?" I am not privy to the internal workings of the IDE and what it may or may not do when the different boards are selected and when a serial port is opened but I am loath the assume that there is no difference.
turbosnail:
"Is there any difference in the data?"
I don't know how much more clear I can make this. The serial monitor opens the serial port. It prints what it received. And sends what it is told to send. That's it.
turbosnail:
If, for example, one board firmware uses parity bits and another does not use parity bits and one opens the serial port then depending on the board it would/wouldn't need a parity bit. Before you say that the boards do/don't use parity I am merely using the example of a possible difference in the characters of the data stream. If you do not like the parity example use BigEndian and LittleEndian. Again I do not know of any difference so my question remains, if different boards are selected would the data remain the same. To state that the serial port is simply opened does not answer the underlying question: "Is there any difference in the data?" I am not privy to the internal workings of the IDE and what it may or may not do when the different boards are selected and when a serial port is opened but I am loath the assume that there is no difference.
The board in question is not a factor because if you recall the instructions for performing the loop back test, one wires pin 0 to pin 1 and then puts the controller chip into permanent reset condition by wiring the reset pin to a ground pin. So when the serial monitor sends out characters they go out the USB port into the on-board USB serial converter chip out the rec wire looped back to the tx wire and then back to the PC usb port to the serial monitor where the data will be displayed. So as you see the data is not even going into or out of the avr chip as the loop back is via a jumper wire and the AVR chip is in hard reset the whole time. Therefore it's pretty clear the what board is selected in the arduino IDE software has no bearing on the serial loop back test. It's simply testing the ability of the on=board USB serial converter chip to receive characters and echo them back to the PC.
Let us consider this question answered.
To satisfy myself I used the only board I have, a BoArduino with an FTDI, with reset grounded and TX jumpered to RX. I created a 62 character string, a~zA~Z0~9, and stored it on the clipboard. I opened the IDE and opened the serial monitor and starting at the top of the board selections I sent the string using every board selection. As you all who have contributed to this posting would expect all echoes were identical. This is what I would have hoped for and expected. I knew that with the RX jumpered to the TX the AT328 on my board was bypassed. Had I done this first I would have never asked the question but since I had an anomaly with a UNO board (see the link above for the original posting) I did not know then what I know now. Since I did not know if there was a different communication protocol for different boards (which I would have thought poor planning) I asked the question here. In retrospect I should have tried my experiment first. Such is life!
To encapsulate my findings:
All board types use the same communication protocol for the data stream. (not the same content to be uploaded or stored)
With the standard loopback wiring it does not matter which board the Arduino IDE is set for. (it would matter for other tasks: uploading, programming etc.)
All of this is as I would have hoped, it was that I was just unsure.