next topic »

[on:]

I know this is a pretty specific question, but I'm hoping someone here has some insight.
So I'm working on a program to do serial input/output (on the Rx/Tx lines) of the arduino. Simply, you type "1" into the serial monitor, and it puts out "one", etc.
So in testing our programs out in class, we noticed that a program with settings for the Duemilanove did NOT work for the Uno. When debugging, a student noticed that the ASCII character (which has the most significant bit zeroed) seemed to be high on the Uno. (That is, when typing in a "H", the code read in should have been 0x48 according to ASCII tables, but instead was 0xC8).
Because both boards use the ATMega328 chipset, my instructor seems to think the Uno's USB-to-RS-232 converter chip is setting that bit high, but no one knows.
We managed to figure out a solution, but my question is, does anyone know the hardware setup that would cause this? By masking the RX ISR with 0x7F, it forces a 0 into the MSB of every byte. But we want to know what is happening at the HARDWARE level.
To my understanding, the USB to serial on the Uno uses the ATMega8U2 chip, whereas the Duemilanove uses the FTDI FT232RL chip. However, I can't find anything that says there are major differences, other than not having to use drivers for the ATMega8U2.
Can anyone add some insight?

[Reply #1 on:]

Could you post your complete sketch first before we guess at your symptom.

Lefty

[Reply #2 on:]

I might be wrong, but I don't think this involves a sketch (and my sketch isn't done, anyways).  I'd more just like someone to point me towards a website or a schematic that could show the difference between USB-to-serial converters on the Uno and Duemilanove. (Or, if anyone has noticed this problem before).   
I can still post the code I have done, if you want.

[Reply #3 on:]

I might be wrong, but I don't think this involves a sketch

Giving the fact that there are literally hundreds (or even thousands) of people using the Uno who do not have this problem there is a very good chance that you are wrong.  The most logical and time efficient place to start troubleshooting is with your Sketch.  Post your Sketch if you'd like help.

A few other things that would be helpful to post...

Operating system?

Terminal application?

[Reply #4 on:]

Because both boards use the ATMega328 chipset, my instructor seems to think the Uno's USB-to-RS-232 converter chip is setting that bit high, but no one knows.

You ran the absolutely identical sketch? May we see it?

In any case the high-order bit being high sounds to me like the wrong number of bits. Serial has LSB first and MSB last, and the MSB is followed  by the stop bit which is a 1. So if you configured the port to use 7 data bits you would get those symptoms.

Does the class run to a logic analyzer? You might be able to see what is actually arriving.

[Reply #5 on:]

I might be wrong, but I don't think this involves a sketch

Giving the fact that there are literally hundreds (or even thousands) of people using the Uno who do not have this problem there is a very good chance that you are wrong.  The most logical and time efficient place to start troubleshooting is with your Sketch.  Post your Sketch if you'd like help.

A few other things that would be helpful to post...

Operating system?

Terminal application?

I also doubt that many of those individuals using the Uno are writing serial write/read programs, and then testing the same program on a Duemilanove. We were given predetermined registers to use, and we determined their values via the data sheet. The assignment was written before the Uno was even released.
The program that was tested was not mine; it was my instructors. I'm asking for the differences in HARDWARE, not software. If I thought it was a software problem, I would have said so. If I ever obtain the application that he has, I will post it.

Operating system was OSX (10.6.7), Windows 7, and Windows Vista.

All individuals were using the Arduino compiler.

Because both boards use the ATMega328 chipset, my instructor seems to think the Uno's USB-to-RS-232 converter chip is setting that bit high, but no one knows.

You ran the absolutely identical sketch? May we see it?

In any case the high-order bit being high sounds to me like the wrong number of bits. Serial has LSB first and MSB last, and the MSB is followed  by the stop bit which is a 1. So if you configured the port to use 7 data bits you would get those symptoms.

Does the class run to a logic analyzer? You might be able to see what is actually arriving.

There was no logic analyzer, that's something I didn't think of. I'll have to check on that.
I understand the idea of having the wrong number of bits, but why would that make a difference between the Duemilanove and the Uno? Would that be what's causing the problem? I appreciate the insight, I'm going to look into this.

[Reply #6 on:]

We were given predetermined registers to use, and we determined their values via the data sheet. The assignment was written before the Uno was even released.

Whoa! Registers? So you aren't using the serial library then?

The program that was tested was not mine; it was my instructors. I'm asking for the differences in HARDWARE, not software. If I thought it was a software problem, I would have said so.

Whether you think it is a software problem or not, it might be.

Because both boards use the ATMega328 chipset, my instructor seems to think the Uno's USB-to-RS-232 converter chip is setting that bit high, but no one knows.

Yes, but when I use serial to talk to my Uno, the 8-bit is not set high. So putting aside whether or not the Duemilanove works, I think it is clutching at staws a bit to assume that there is a serious design issue with the Uno's USB-to-RS-232 converter chip that no-one else in the world has noticed.

[Reply #7 on:]

Yes, but when I use serial to talk to my Uno, the 8-bit is not set high. So putting aside whether or not the Duemilanove works, I think it is clutching at staws a bit to assume that there is a serious design issue with the Uno's USB-to-RS-232 converter chip that no-one else in the world has noticed.

I agree, there is no programming information passed from a running 328 sketch to the serial converter (8u2 or FTDI) about the format (speed, data bits, parity, stop bits) of the serial data.  So please post as small a sketch as possible showing a serial data bit 8 difference/problem on serial data between running on a Duemilanove Vs a Uno board. Unless it's reproducible by peers (us) then it is just conjecture on your part in my opinion.

PS: If you indeed using direct register control for your serial functions rather then the standard arduino serial library then I'm sure there are those around here that can validate that it's being done properly or not.

Lefty

[Reply #8 on:]

nkdy
I was thinking about your issues the other night.
The UNO and Duemilanove present themselves as different Com Ports.

I presume you have checked the Com Port settings to ensure they are set appropriately (ie baud, Parity, Bits, Stop bit).
It is possible the two are different, but will not be affected by uploads, since these are overwritten by other parts of the upload process.

The other option may be to monitor the rx/tx pins using another communications program.
In theory it should show exactly what you send in, or what the 328 sends out.
This will be at TTL level, so you may need to convert it, using a suitable level converter (max232, etc)

the ATmega8u2 should be capable of converting incoming and outgoing data at whatever speed it gets it at, so the only thing affecting data flow is the machines com port settings, and the sketch loaded into the 328.
Windows seems to consider the UNO as a modem, as it uses the mdmcfg.inf file when it installs the UNO drivers, while the FTDI supplies a lot more information to windows.

It is possible to reflash the ATmega8u2 using Atmel's flip program http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3886 if you are in any doubt about it.

Good luck with your program.
Mark