next topic »

[Reply #15 on:]

I think I like set #2 better, mostly because of step 2, which is missing in #1set and could be the cause of many comm failures because miswired external connections to pins 0 & 1.

Lefty

[Reply #16 on:]

I hope I'm not splitting hairs but this is for beginners.

Windows produces a device insertion tone

Not if sound is disabled.

I'd vote for #2.

______
Rob

[Reply #17 on:]

I think I like set #2 better, mostly because of step 2, which is missing in #1set and could be the cause of many comm failures because miswired external connections to pins 0 & 1.

Excellent point.  Thanks.

Anything else?

I hope I'm not splitting hairs...

That is one of my favourite cartoons!    I miss Chuck Jones.  Moving on...

Windows produces a device insertion tone ... Not if sound is disabled.

If you (or anyone reading this) can think of a way to reword that step let me know.  I'm stuck with variations that are too wordy or difficult to read.

I'd vote for #2.

Thanks.

Anything else?

[Reply #18 on:]

That'll teach me to open my big mouth.

Yes you have to be careful it doesn't get so complex you need a flow chart. How about

5. Connect the board to your computer.  After a brief pause Windows will produces a device-insertion tone if sound is enabled.  Linux may or may not produce a device-insertion tone; an entry is added to the system log.

_____
Rob

[Reply #19 on:]

That'll teach me to open my big mouth.

Was it really that painful?

Yes you have to be careful it doesn't get so complex you need a flow chart.

That's what I was talking about.  My brain was flooded with ... What about no sound output device?  What if the volume is turned down?  What if the device is muted?  Must be sleep deprivation.

How about

Perfect.  #14 modified with the suggestion.


Anything else?

[Reply #20 on:]

#2.

I amwas tempted to test this - I did not think baudrate was irellevant. But rather than voice  an uinformed opinion I tested - and now I know. With hindsight, obvious.

I will do the #2 doing exactly what it says. WIthout enganging too many brain cells (Nice evening here, dusk, beer in hand ... attached picture as proof)

Excellent instructions. I skipped one (by accident) and things did not work - then I did not skip it - and everything worked. It will be interesting to see if the sticky will have many false alarms for the same reason. And no, I cant think of any instruction to add to stop that from happening.

My only comment for possible improvment is that at point 8. If it does echo everything, then the USB/driver/chip is working

(edited this pst to reflect the test was done, rather than just intended)

[Reply #21 on:]

That'll teach me to open my big mouth.

Yes you have to be careful it doesn't get so complex you need a flow chart. How about

5. Connect the board to your computer.  After a brief pause Windows will produces a device-insertion tone if sound is enabled.  Linux may or may not produce a device-insertion tone; an entry is added to the system log.

_____
Rob

You may also like to add that under linux a new /dev/ttyUSB*  device driver will appear.

The reason is that on (at least fedora or redhat) linux  the 'messages' file is root only readable for security reasons.  where as the existence of a new device driver is something any user can check on.  Basically it is a more convenient thing for a user to look for.

Also note that users will need to be members of the right groups to enabled locking for serial communications. That is something that is noted in the web sites software installation and setup page. The step-by-step instructions however can just point to the right web page for that sort of detail.

[Reply #22 on:]

beer in hand

Looks exotic and foreign.  And tasty.

Excellent instructions.

Thanks.

It will be interesting to see if the sticky will have many false alarms for the same reason

With a few years of working technical support under my belt I can say beyond any doubt that there will be false alarms.

My only comment for possible improvment is that at point 8. If it does echo everything, then the USB/driver/chip is working

Excellent!  Every story needs a conclusion and mine was certainly missing one.

Post #14 updated...
http://arduino.cc/forum/index.php/topic,67509.msg504175.html#msg504175

[Reply #23 on:]

You may also like to add that under linux a new /dev/ttyUSB*  device driver will appear.

Appear where?

The step-by-step instructions however can just point to the right web page for that sort of detail.

Link please.

Thanks.

[Reply #24 on:]

With a few years of working technical support under my belt I can say beyond any doubt that there will be false alarms.

Ever read the story of a PC telephone support tech trying to get a person's PC working, it was hilarious, seemed it took over 30mins before the person managed to inform the tech that the building also had a total power outage along with the persons PC problem!

Not sure if it was a true story or not, but it was a great read.

Lefty

[Reply #25 on:]

I have not read it but I can believe it's true!

One thing that used to drive me nuts... I'd go on a support call.  I'd arrive to find the computer connected to the hardware and the supposedly technically competent human grumbling over the keyboard.  They would get up, give me a rundown of what they had tried and leave.  I'd spend about an hour trying to troubleshoot the problem arriving at the conclusion that the cable was the culprit.  When the human returned I would ask, "where did you get this cable?"  The typical reply was, "I found it in a box of old cables.  It had the right connectors on the ends so it has to be the right one."

[Reply #26 on:]

Last chance.  Any suggestions...

1. Disconnect power from the board

2. Remove all connections and shields from the board

3. Force the processor to remain in reset by connecting a jumper from RESET to GND

4. Connect a jumper from the TX pin (Digital Pin 1) to the RX pin (Digital Pin 0)

5. Connect the board to your computer.  After a brief pause Windows will produce a device-insertion tone if sound is enabled.  Linux may or may not produce a device-insertion tone; an entry is added to the system log.

6. Start your favourite terminal application.  Serial Monitor will work fine.

7. Connect the terminal application to the serial port for your board.  The baud rate is irrelevant.

8. Send data by typing.  Everything you type should be echoed back.  To send data, some terminal applications, like Serial Monitor, require pressing the Enter key or clicking a Send button.  If exactly what you send is echoed back then the board passes the test.  This means that the host computer hardware driver, USB cable, and USB to serial converter are all working.

9. Shutdown the terminal application

10. Disconnect the board from the computer

11. Remove the two jumpers

[Reply #27 on:]

Why the word Uno in step 4? Applies to all arduino boards, might confuse.

4. Connect a jumper from the TX pin (1 on the Uno) to the RX pin (0 on the Uno)

How about:

4. Connect a jumper from the TX pin (Pin 1) to the RX pin (Pin 0)

Or:
 4. Connect a jumper from the TX pin (Shield pin 1) to the RX pin (Shield pin 0)
Or:
 4. Connect a jumper from the TX pin (Arduino Pin 1) to the RX pin (Arduino Pin 0)

Lefty

[Reply #28 on:]

Why the word Uno in step 4?

Huh.  Good question.  Digging through my brain reveals... not much.   

I guess because I didn't know if pins 0 & 1 are RX & TX on other boards.  Is that consistent with Arduinos?  Is that consistent with compatible boards?

[Reply #29 on:]

Why the word Uno in step 4?

Huh.  Good question.  Digging through my brain reveals... not much.  

I guess because I didn't know if pins 0 & 1 are RX & TX on other boards.  Is that consistent with Arduinos?  Is that consistent with compatible boards?

Yes, if you are talking about the AVR hardware UART channel, even on the mega it uses (shield) pins 0 and 1 for the Serial channel, where the other three hardware UART channels are in the pins 14 to 19.

You software guys crack me up, often.  

Lefty