Marlin
Marlin copied to clipboard
bkubicek
Baud Rate
I tried to increase the baud rate from 115200 to 250000. It did now work. According to this forum entry http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1274739897 the max baudrate is 230400.
There is a boud-rate calculator here: http://www.wormfood.net/avrbaudcalc.php?postbitrate=200000&clock_speed_table=on&postclock=16 for 200000 also a a non-jittering communication should be possible.
The baudrate of 250000 is working ok.
The link with 230400 is using hyperterminal. This selects 230400 and the next is 460800. The 230400 is not the limit according this document. 230400 is working 460800 is not.
Best regards,
Erik van der Zalm
----- Original Message ----- From: "Bernhard Kubicek" [email protected] To: "ErikZalm" [email protected] Sent: Thursday, November 3, 2011 8:37:26 AM Subject: [Marlin] Baud Rate (#30)
I tried to increase the baud rate from 115200 to 250000. It did now work. According to this forum entry http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1274739897 the max baudrate is 230400.
There is a boud-rate calculator here: http://www.wormfood.net/avrbaudcalc.php?postbitrate=200000&clock_speed_table=on&postclock=16 for 200000 also a a non-jittering communication should be possible.
Reply to this email directly or view it on GitHub: https://github.com/bkubicek/Marlin/issues/30
You are right, it's not a limit, but its a proven working maximum, although the jitter is pretty high for this frequency according to the baud-rate calculator.
I do understand that the strange numbers occur by the outdated baud rates, and have used special frequency quartzes myself.
I will try to change the baud rate again tonight.
Have you really tested with an arduino Mega2560, or with the ramps board? According to the schematics, the USB transfer is handled by a atmega8 controller with a dedicated 16mhz quartz. The relevant firmware of this usb<>ttl-rxtx seems to be here: https://github.com/arduino/Arduino/tree/master/hardware/arduino/firmwares/arduino-usbserial However, it was not obvious from a 5-min screening what it should be capable of. Also, I am wondering how it "guesses" the baud rate before translating to USB.
I just tested 230400 seems to work on linux in replicatorg, if the machine/.xml is edited of course. 250000 did not work, neither in pronterface nor in replicatorg.
Could it be that this is dependent on the operating system and the drivers capabilities? I am using Ubuntu 11.04 x64
see also http://pyserial.sourceforge.net/pyserial_api.html
Under windows it works. I printed a long time with it. On the gen6 I use 250000 for months now. Almost all Marlin user are using 250000. It works under windows. Linux seems to have a problem with selecting this baudrate.
If I don't use 250000 but 115200 I get communication errors. The retransmissions influence the printing quality.
Best regards,
Erik van der Zalm
----- Original Message ----- From: "Bernhard Kubicek" [email protected] To: "ErikZalm" [email protected] Sent: Thursday, November 3, 2011 11:23:05 AM Subject: Re: [Marlin] Baud Rate (#30)
I just tested 230400 seems to work on linux in replicatorg, if the machine/.xml is edited of course. 250000 did not work, neither in pronterface nor in replicatorg.
Could it be that this is dependent on the operating system and the drivers capabilities?
Reply to this email directly or view it on GitHub: https://github.com/bkubicek/Marlin/issues/30#issuecomment-2615244
Just tried 250000 with pronterface on a DFRobot 1280, working ok, no problem. Arch Linux on Thinkpad X41.
Hi, Evdz and me have done some further investigations what could be the trouble. The unavailability of the 250k baud rate can come from two sources: First the hardware on the host, aka the USB chipset. However, for this we have not found a single proof or indication. I found two platform independent C++ Libraries for serial access (with a QT focus): QExtSerial and QSerialDevice. The latter seems more advanced and has a lot of defines for Baudrates. Both however, at least in the windows build, seem to rely on the same system interface (that QT made private in recent versions, and hence there is a also a fork who works with recent QT, don't have the name ready). The story is, at least QSerialPort did not work with 250kb in OSX. But, EvdZ was able to change some inner workings very close to the system layer, and add support. So from this indications, I would think that at least 80% depends on the access to the actual USB driver, that might allow the baud rate or not. Whats strange that on a thinkpad x201 in ubuntu 10.4 x64, it does neither work in repg (rxtx library) nor in pronterface (some python lib?).
my system is 32bit btw... and python is 2.7.2 the DFrobot has a different USB chip from the original arduino
replicatorG does NOT work: [java] SEVERE: Connection error: Error opening serial port '/dev/ttyUSB0'.
When I set the replicatorG-machine to 115200, it tries to connect but hangs at [java] INFO: Attempting to reset RepRap (pulsing RTS)
The max baudrate on the UART of the ATMega2560 is 1MBit with the 16Mhz crystal. (This actually puts the divider at 0, running the UART as fast as possible). See the datasheet.
The problem however, is the USB serial chips&interference&drivers. I've seen serial ports (both USB and normal PC port) regally drop bits at 115200. The ATMega2560 is actually talking to an ATMega8 running V-USB to do the USB->Serial conversion. The chance of bits going corrupt here are pretty low, because on the same baudrates they will have the same 'error'. Traces are short, and won't catch much interference. However, the V-USB implementation on 16Mhz doesn't do CRC checking. So bits can get corrupted on the USB side. But this is independent of the UART speed. The USB side is only communicating at 1.5 Mbit/s. So at high baudrates you might flood the ATMega8 with data. Making it lose bytes. It's doing all the USB communication in software.
Then there is the driver/software issue. Not all software likes the none-standard baudrates above 230400, some drivers and some UART chips will choke on it. Using none-standard baudrates under linux requires a different api (TCSETS2), which is why quite a few tools might not like using those baudrates.
In my experience, going beyond 115200 is not worth it unless you control every piece of hardware&software. And going beyond 38400 already introduces problems on some serial ports.
The major problem is that 115200 is not a clean baud rate if you use a 16mhz quartz, it is faked by a close approximation frequency (IIRC 5-7% change), that creates bit-errors. You would need a baud-rate quartz for that to have the exact speed. 250k is clean on 16mhz, and thats why it would be nice. Do you have a link about tcsets2, google was not my friend.
Normally, yes, that 5-7% is a big problem. But, the USB<->Serial on the ArduinoMega2560 is also an AVR (the ATMega8A), using the same type of UART, with the same offset.
It's almost impossible to find info about TCSETS2, I'll copy&paste some code tomorrow. You'll need to include termios2.h if I remember right.
http://pastebin.com/Uv9JiKMj This is part of the code from the linux serial library I use. If it can find TCGETS2 it will use that to configure any baudrate you want. Else it will fall back to the old tcsetattr methode, which doesn't support al baudrates.
(I need to support both linux 2.4.17 and 2.6.27 with the same library)
250000 even works from repsnapper on a FreeBSD machine via remote serial (socat) to the linux box where the DFrduino is plugged in.