anet a8

[manotroll]

has support for anet a8 do you have support for automatic leveling? Do you have temperature protection?

[C4g2]

So I've read up on fuses and locks enough to know I wont be immediately picking up on this and also wont feel comfortable just doing it, that said I havnt given up. I found enough detail to put together this monstrosity: sudo avrdude -p atmega1284p -C /avrdude_rpgpio.conf -c rpgpio -b 57600 -v -v -U lock:w:0x3F:m -U lfuse:w:0xFF:m -U hfuse:w:0xDC:m -U efuse:w:0xFC:m -U flash:w:/optiboot_atmega1284p.hex:i -U lock:w:0x2F:m

The RPGPIO nonsense at -C and -c is for the rasppi programmer I'm using. -b 57600 as per tilsonm. And -v -v for very verbose, cause I like when text scrolls past quickly. Avrdude will process the following -U in the order presented it.

-U lock:w:0x3F:m Unlocks the chip or area to write the bootloader. -U lfuse:w:0xFF:m Sets the clock. This is frankly the most overwhelming list I've seen in quite a while. Fortunately I have yet to find a guide that says anything other than 0xFF, still, considering the danger when messing with this fuse I'd like conformation before setting. -U hfuse:w:0xDC:m Seems to be reserving space for the bootloader? Optiboot is 1.37kB, ~702 words, needing 1024 words. -U efuse:w:0xFC:m This one looks to exclusively deal with the brownout detection? +5v means this should be set to 4.3v yes? -U flash:w to load the Optiboot code on the chip... -U lock:w:0x2F:m Locks again. The 0x2F was suggested by an Optiboot author so anything flashed after can read the boot area.

This may be a gross oversimplification, but hopefully not enough to be wrong.

[mabl]

@KevinOConnor Thanks for this fix (5a86391). However the ANET board also needs its baud rate set to 57600, which is not currently menuconfig option, correct? It might make sense to make this configurable too. When doing so, I can successfully flash klipper on my ANET board.

[KevinOConnor]

On Sat, Jan 06, 2018 at 03:17:44PM +0000, Matthias Blaicher wrote:

@KevinOConnor Thanks for this fix (5a86391). However the ANET board also needs its baud rate set to 57600, which is not currently menuconfig option, correct? It might make sense to make this configurable too. When doing so, I can successfully flash klipper on my ANET board.

Okay, thanks. Can you run the following commands and copy-and-paste the output for me?

cd ~/klipper/ avrdude -patmega1284p -carduino -P/dev/ttyUSB0 -D -Uflash:w:out/klipper.elf.hex:i avrdude -patmega1284p -carduino -b57600 -P/dev/ttyUSB0 -D -Uflash:w:out/klipper.elf.hex:i

[KevinOConnor]

On Sat, Jan 06, 2018 at 03:17:44PM +0000, Matthias Blaicher wrote:

@KevinOConnor Thanks for this fix (5a86391). However the ANET board also needs its baud rate set to 57600, which is not currently menuconfig option, correct? It might make sense to make this configurable too. When doing so, I can successfully flash klipper on my ANET board.

Which bootloader did you flash to your ANET board? Looking at the directions from:

http://www.instructables.com/id/Flashing-a-Bootloader-to-the-CR-10/

it recommends writing the bootloader from:

http://lauszus.github.io/Sanguino/

which has a boards.txt file with an unpload speed of 115200:

https://github.com/Lauszus/Sanguino/blob/master/avr/boards.txt

-Kevin

[lucashpandolfo]

¿Does the Anet A8 uses a Melzi too?

I have a Tronxy p802ma (also uses Melzi) and also had some problems flashing the firmware.

First, as someone else said, it appears the only baudrate supported is 57600. Surprisingly enough, just changing the baudrate worked for me and allowed me to flash the firmware. I later reflashed the original firmware to test something. When I wanted to flash Klipper again, I couldn't do it. I tried for hours. In the end I had to reflash a bootloader.

Using my raspbery and this guide I successfully flashed a bootloader to the Melzi (this one from a guide at reprap.org ) but for some reason the Melzi still refused to let me flash the firmware.

In the end I flashed this other bootloader and it worked flawlessly. But again, I could not get it working with another baudrate besides 57600.

[tilsonm]

@lucashpandolfo The Anet came with Melzi boards at one point and I think the Anet v1.x boards that are supplied now are considered a Melzi clone, but I think if I remember right, the pinout is different. I think the Tronxy board is similar. Not sure why you're having issues flashing klipper again though.

[tilsonm]

@kevinoconnor I think the Anet boards come with a bootloader loaded by default. I've never had to jump through any hoops to flash Marlin. You can choose to load Optiboot but it's not required to flash firmwares from ArduinoIDE.

Biggest benefit of Optiboot on the Anet, unless you soft-brick your board, is that it takes up less space allowing you to have a bigger firmware footprint. Marlin features eat up a lot of space. Klipper is so small in comparison that there is no obvious benefit (that I can think of) to flash Optiboot before flashing klipper. especially given the unforgiving nature of possibly messing up the locks and fuses.

[lucashpandolfo]

I WAS having issues due to the bootloader (or lack of) it seems. And looking at the config supplied in this thread looks like the pinout is a bit different.

Anyway, for the ones in need of a bootloader, just keep in mind you can use your raspberry as an spi programmer.

Cheers.

[C4g2]

Alright so finally back at it today. Was thinking about it earlier and polled my chip for the fuses as is avrdude: safemode: Fuses OK (E:FD, H:DA, L:D6) My line of thought is leave the Low Fuse alone at 0xD6, as thats the one dependent the boards external hardware, and swap in my High 0xDE and Extended 0xFC for appropriate bootloader space and brownout detection. Can anyone confirm these, or my previous, fuse settings?

[mabl]

I believe the ANET boards to be mostly identical, as seen from the firmware. This is supported by not finding alternate firmware versions by ANET for different boards. On my "V1-5" board, I had good success flashing marlin (using their example settings) and the "standard" board file from here using the "Anet V1.0" (not the optiboot) settings:

https://github.com/SkyNet3D/anet-board/blob/master/hardware/anet/avr/boards.txt

It has been a long time since I did AVRs last, so I don't know if flashing via bootloader includes flashing the a new bootloader, probably not? Maybe I could switch to optiboot without ICSP. Anyways, the current state of things is fine. It's just that it wants a different baud rate by default. And this is also how it came from China.

@KevinOConnor: Sure thing. I hade hacked the baud rate into the Makefile before, but it obviously also works on the command line:

pi@octopi:~/klipper $ avrdude -patmega1284p -carduino -P/dev/ttyUSB0 -D -Uflash:w:out/klipper.elf.hex:i
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x01
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x9e
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xff
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x92
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xd3
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x68
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x0a
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x26
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x48
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x3d

avrdude done.  Thank you.

pi@octopi:~/klipper $ avrdude -patmega1284p -carduino -b57600 -P/dev/ttyUSB0 -D -Uflash:w:out/klipper.elf.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9705
avrdude: reading input file "out/klipper.elf.hex"
avrdude: writing flash (13340 bytes):

Writing | ################################################## | 100% 3.26s

avrdude: 13340 bytes of flash written
avrdude: verifying flash memory against out/klipper.elf.hex:
avrdude: load data flash data from input file out/klipper.elf.hex:
avrdude: input file out/klipper.elf.hex contains 13340 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.72s

avrdude: verifying ...
avrdude: 13340 bytes of flash verified

avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done.  Thank you.

[mabl]

@tilsonm: Thanks for the config file. You still have an error in the extruder speed. It ought to be step_distance: .01. Apart from this I got it working! Nice!

[KevinOConnor]

On Sun, Jan 07, 2018 at 08:13:38AM +0000, Matthias Blaicher wrote:

I believe the ANET boards to be mostly identical, as seen from the firmware. This is supported by not finding alternate firmware versions by ANET for different boards. On my "V1-5" board, I had good success flashing marlin (using their example settings) and the "standard" board file from here using the "Anet V1.0" (not the optiboot) settings:

https://github.com/SkyNet3D/anet-board/blob/master/hardware/anet/avr/boards.txt

It has been a long time since I did AVRs last, so I don't know if flashing via bootloader includes flashing the a new bootloader, probably not? Maybe I could switch to optiboot without ICSP. Anyways, the current state of things is fine. It's just that it wants a different baud rate by default. And this is also how it came from China.

To the best of my knowledge, the only way to flash the bootloader is to use an external programmer. Just to be clear, you've never done this - you've only ever written to the flash via the existing USB port?

@KevinOConnor: Sure thing. I hade hacked the baud rate into the Makefile before, but it obviously also works on the command line:

Thanks!

-Kevin

[mabl]

Just to be clear, you've never done this - you've only ever written to the flash via the existing USB port?

Indeed, I have only touched the ANET board via USB, hence leaving the bootloader intact.

I have been using Klipper on my A8 all day today and it is really nice. Thank you!

[KevinOConnor]

On Sun, Jan 07, 2018 at 08:14:50AM -0800, Matthias Blaicher wrote:

Just to be clear, you've never done this - you've only ever written to the flash via the existing USB port?

Indeed, I have only touched the ANET board via USB, hence leaving the bootloader intact.

I have been using Klipper on my A8 all day today and it is really nice. Thank you!

Thanks.

If you can post a confirmed working config, I'll add it to the repo. (Your printer is from 2017, right?)

-Kevin

[mabl]

Yes, I have a 2017 printer using a V1-5 board (but if one believes Marlin it will work on all previous revisions too). The config file is based on the work of @tilsonm and @C4g2.

# This file contains common pin mappings for ANET v1 boards. To use
# this config, the firmware should be compiled for the AVR
# atmega1284p.

# See the example.cfg file for a description of available parameters.

[stepper_x]
step_pin: PD7
dir_pin: PC5
enable_pin: !PD6 
step_distance: .01
endstop_pin: ^!PC2
position_endstop: -33
position_max: 220
position_min: -33
homing_speed:  100

[stepper_y]
step_pin: PC6
dir_pin: PC7
enable_pin: !PD6
step_distance: .01
endstop_pin: ^!PC3
position_endstop: -10
position_min: -10
position_max: 220
homing_speed: 100

[stepper_z]
step_pin: PB3
dir_pin: !PB2
enable_pin: !PA5
step_distance: 0.0025
endstop_pin: ^!PC4
position_endstop: 0
position_max: 235   # When not using a glass bed, this could be 240 mm

[extruder]
step_pin: PB1
dir_pin: PB0
enable_pin: !PD6
step_distance: .01
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: ATC Semitec 104GT-2 
sensor_pin: PA7
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250

[heater_bed]
heater_pin: PD4
sensor_type: ATC Semitec 104GT-2
sensor_pin: PA6
control: watermark
min_temp: 0
max_temp: 130

[fan]
pin: PB4

[mcu]
serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0

[printer]
kinematics: cartesian
max_velocity: 400
max_accel: 2000
max_z_velocity: 8
max_z_accel: 100

[C4g2]

Can confirm @mabl is the solution to the problem!!

make flash FLASH_DEVICE=/dev/ttyUSB0
  Flashing out/klipper.elf.hex to /dev/ttyUSB0 via avrdude

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9705
avrdude: reading input file "out/klipper.elf.hex"
avrdude: writing flash (13344 bytes):

Writing | ################################################## | 100% 3.33s

avrdude: 13344 bytes of flash written
avrdude: verifying flash memory against out/klipper.elf.hex:
avrdude: load data flash data from input file out/klipper.elf.hex:
avrdude: input file out/klipper.elf.hex contains 13344 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.85s

avrdude: verifying ...
avrdude: 13344 bytes of flash verified

avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done.  Thank you.

I deleted the Klipper directory and Klippy_Env to start from scratch and followed all the install instructions UP TO Make. At that point I did a Nano ~/klipper/src/avr/Makefile and changed this line at the very bottom: $(Q)avrdude -p$(CONFIG_MCU) -c$(CONFIG_AVRDUDE_PROTOCOL) -P"$(FLASH_DEVICE)" -D -U"flash:w:$(OUT)klipper.elf.hex:i"

Add -b57600 to this command. After I saved (^O to save ^X to exit) I followed the rest of the instructions, including using the /dev/ttyUSB0 line instead of By-ID.

Happily continuing the install and configuration!

[diekaines]

@C4g2 can you upload a video too how it works/moves with klipper installed ?

[rewolff]

Do you have temperature protection?

I tried flashing klipper on my "megatronics" based BEAGLE delta printer. Something went wrong, and I decided to call it a day. A few hours later I found that the black goo falls of the hotend when you overheat the hotend. I now have an "as new" clean metal hotend, but alas not the plastic in reasonable shape.....

For temperature protection to work, the firmware needs to know the safe state of each of the pins. That's "OFF" for heaters, and "ON" for things like a FAN. So before you get to the state where that sort of information is correct, things can go wrong.

[C4g2]

@kotfarepra Lenne has posted a few videos in the comments of the Hackaday article about Klipper.

I'd love to upload one myself, but after finishing the installation instructions I'm getting:

Recv: // retry in a few moments.
Recv: !! Printer is not ready```

at OctoPrints terminal. I've restarted the pi and the printer, waited quite a few moments but nothing seems to happen on its own. And nothing but ok's when I send either 'restart' or 'status'.

[C4g2]

I'm getting the "Recv: // The klippy host software is attempting to connect. Please" too, it just wont post with markdown.

[C4g2]

Okay nevermind that last messed up post, I checked the log and saw it was still trying to connect to the by-id, I switched it to ttyusb0 in config file and printer is responding now!!

[rewolff]

I spent 15 minutes looking for that video in the hackaday commends.... https://www.youtube.com/watch?v=clixTeZ3fJA

[C4g2]

My bad, I remembered it being embedded not a link, but still, more videos there and I'm sure theres even more if ya Youtube 'klipper firmware' or the such.

Thanks again to everyone who helped me get this running!

[diekaines]

@C4g2 i was thinking more about a video specific to anet a8 . Interested if the default extruder/hotend keeps up OK with 100/250mm/s2

[lenne0815]

@kotfarepra That actually was an A8 at one point in the video ;) guess the A8 tops out around 60mms / 2500 accel for fine detailed prints. 100 should be okay, make sure to run tiny retracts like 0.5 for 250 reduce layer height, maybe even down to 0.08 if the default stepper drivers can keep up at all.

[tilsonm]

I've added a configuration file for the Anet A8 and sent a pull request. It's based on my work and that of @C4g2.

[KevinOConnor]

On Sun, Jan 07, 2018 at 02:54:42PM -0800, tilsonm wrote:

I've added a configuration file for the Anet A8 and sent a pull request. It's based on my work and that of @C4g2.

Thanks. I've added the example config file for the anet a8 (commit f183871e).

-Kevin

[MrWu-at-msv]

I successfully flash Anet Board with: make flash FLASH_DEVICE=/dev/ttyUSB0 On anet-a8-2017.cfg file you must add: baud: 115200 under [mcu] because anet board use CH340 chip and on this chip 250000 baud is not working or errors % make very the connection very unstable https://www.olimex.com/Products/Breadboarding/BB-CH340T/resources/CH340DS1.PDF (this also apply to many arduino mega2560 or arduino duo, cheap clones that also are equipped with CH340 chip)

on Make menuconfig set also baud to 115200.

however my board had already the Bootloader on it, re flashed using arduino IDE and https://github.com/SkyNet3D/anet-board.

[hg42]

the CH340 Problem seems to be vodoo, do you have definite knowledge or own experiences with it or did you only read about it?

My TronXY board has a CH340G and works well with 250000, though it usually prints 2-3 hours.

[MrWu-at-msv]

Any vodoo don't worry ;-) , is enough reading the datasheet of CH340 and AVR ATmega to have definite knowledge and is very well known problem. If you use baud speed on Microcontroller in conjunction with Serial chip who don't support that baud speed you will face high frequency(clock speed) percentage errors, is not because apparently is 'working' that means is the right way to do it. The main problem with CH340 and Avr ATmega micro-controllers running with quartz at 16Mhz (or 20Mhz) is that arduino 0% errors baud speed is at 250000 (or 0.5M or 1M)) due to the UART divisor and quartz speed. Arduino board/Avr ATmega micro controller at 16Mhz at 230400 baud have 8.5% frequency(clock speed) errors, when you try use 250000 baud speed on CH340 the chip try to communicate at the closest speed that is 230400. At 115200 baud frequency errors on arduino/ Avr atmega is 3.5% who is acceptable in somes cases.

Furthermore, theoretical calculations correspond to practical test (8 data bit+ parity), if you try transfert data and you do check consistencies of transferred data you will see is not 100% reliable.

This will not occurs with FTDI-USB chip (original Arduino Mega) because baud rates are compatible with the speed of 250000 baud, usually using a integer divisor of 12 and the internal chip quartz generator.

Moreover if you don't use OctoPi on original raspberry PI, who is already patched, you must be sure your OS can support 250000 baud. For example CH340 Driver In Windows can't go over 128000 (yes some people use Octoprint under windows, i know that sound crazy but someone do)

To conclude, i can say the CH340 is not 100% reliable at that speed (250000 Baud) in conjunction with a ATMega microcontroller running at 16Mhz. 99.9999% reliable that isn't enough for me. For some it may be, but not for me. But at least at 115200 baud you have less chance to encounter a critical error. If you want lowering the risks even more for sensible data transfer you can lower at 76800 baud for 0.2% error.

[hg42]

the only sentences in the data sheet of CH340 about baud rates tell us some examples and the last Chinese word of these means something like "etc.". There is no clear statement, that 250000 is not supported. Rates are from 50 to 2Mbaud. For IR it seems to be more restricted.

Instead it tells that the error will be <0.3% without stating for which baud rates exactly. It cannot be a simple divider because then the error would be similar to the errors of the AVR cpus (and for a 12MHz xtal, which is worse for some baud rates), which is much higher. So there is something like a PLL or some other means to reach such tolerances with a 12MHz xtal.

Up to now I have no numbers about the baud rate error of the CH340 at 250000 baud. Someone with an oscilloscope or a frequency counter could measure it instead of speculating.

We at least know AVR has big baud rate errors and at 250000 this error is 0%.

For me the current knowledge is still kind of vodoo (meaning someone read something somewhere, but no concrete data), as an engineer, I am used to clear data sheets and I wouldn't call the CH340 sheet a real "data sheet", at least in respect to the baud rates. I know there are many problems with serial communication over USB, but there are so many reasons, that we need real facts.

[KevinOConnor]

On Sat, Jan 13, 2018 at 11:40:03AM +0000, MrWu-at-msv wrote:

To conclude, i can say the CH340 is not 100% reliable at that speed (250000 Baud) in conjunction with a ATMega microcontroller running at 16Mhz. 99.9999% reliable that isn't enough for me. For some it may be, but not for me.

Klipper places a CRC on every message block, validates the CRC, and does automatic retransmission. (See docs/Protocol.md for the details.) Further, the stats include information on how many retransmits occur and how many "invalid" messages are found.

I'd like to see some logs after a long print with this chip when the mcu and host are set to 250000.

-Kevin

[hg42]

I don't understand why you say this:

when you try use 250000 baud speed on CH340 the chip try to communicate at the closest speed that is 230400

CH340 is designed to work with 12MHz xtal (as it is on my TronXY board) and this divided by 48 is exactly 250000. I cannot imagine that such a simple divider doesn't work. For 115200 it would be about 104.17, so I guess they use 104 which gives you 115384.62 baud. The 3.5% for the AVR is -3.5% in reality giving you 111111 baud, so it's an even higher difference of 3.7%.

[hg42]

I'd like to see some logs after a long print with this chip when the mcu and host are set to 250000

you already looked into mine, where my TronXY board was included for Y and E...

The board has a CH340G on 12MHz and a 1284p processor and runs on 250000 all the time. I admit I don't pay attention to the stats because it always worked for me with Printrun on Linux before using Klipper.

[hg42]

last line is this: Stats 20811.8: gcodein=958987 print_time=16165.836 buffer_time=0.000 print_stall=0 ramps: mcu_awake=0.002 mcu_task_avg=0.000034 mcu_task_stddev=0.000039 bytes_write=1024420 bytes_read=192019 bytes_retransmit=0 bytes_invalid=0 send_seq=21675 receive_seq=21675 retransmit_seq=0 srtt=0.003 rttvar=0.001 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=15993291 tronxy: mcu_awake=0.006 mcu_task_avg=0.000072 mcu_task_stddev=0.000061 bytes_write=1467878 bytes_read=747252 bytes_retransmit=0 bytes_invalid=0 send_seq=29133 receive_seq=29133 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=16000143 adj=16006848

so, for tronxy:

bytes_write=1467878
bytes_read=747252
bytes_retransmit=0
bytes_invalid=0

and with

99.9999% reliable

there probably are very few retransmits and because Klipper sents everything asynchronous ahead of time, it will not influence anything... another great advantage of Klipper

[rewolff]

On Sat, Jan 13, 2018 at 12:36:39PM -0800, Harald wrote: CH340 is designed to work with 12MHz xtal (as it is on my TronXY board) and this divided by 48 is exactly 250000.

Many, many serial chips divide the system clock to 16 times the baud rate. That is the input clock to the async serial module.

So, if your system clock is 6 MHz, you might think you'd be able to make 250000 baud with 0% error, but in fact, you get to chose between 375000 (divisor 1) and 187500 (divisor 2).

This, like so many posts of mine in this thread to increase understanding: The 12 MHz crystal divides by three exactly to create the 4Mhz base-clock for serial communication at 250kbps.

Modern serial chips might have fractional divisors. So that would mean that you can divide by say 2.5 instead of by either 2 or three. usually only two bits. The physical implementation is that when hitting the top value of the divisor, instead of resetting the whole counter register, you reset all the bits except the lowest one. That one gets loaded with the carry from adding the fractional part to a temporary (2-bit) register. (i.e. it only requires rewiring of one bit of the divisor circuit and adding four flipflops and two full-adder sections. Really nothing compared to 512 bits required for an USB-packet-buffer)

[hg42]

@rewolff ok, thanks for mentioning that, I didn't explicitely think of that.

However, you used 6Mhz for a reason, I guess :-)

For 12Mhz (which is used by the CH340) the divider would be 3 and 250000 would still have 0%

[hg42]

especially this:

when you try use 250000 baud speed on CH340 the chip try to communicate at the closest speed that is 230400

is very unlikely, because for 12MHz the 230400 is much more misaligned than 250000 in any case. 12MHz/230400 = 52.083333 ~= 13 x 2 x 2 via 12MHz/250000 = 48 ~= 3 x 2 x 2 x 2 x 2, so much more exactly fitting divider combinations for 250000 and always an additional error for 230400. (sorry for all those edits)

[rewolff]

I agree with you that it is likely that the CH340 does something like all other chips to generate baud rates. But without looking into the datasheet you can guess that it divides the 12MHz down to the requested baud rate, but you can't be sure. With "baud rates up to 2Mbps" it might be dividing the 2 MHz or 4MHz down to 250kHz and get it exact. But you really can't tell. The datasheet that I found: https://www.olimex.com/Products/Breadboarding/BB-CH340T/resources/CH340DS1.PDF does not specify anything except that baud rates like 230400 (and many others) are generated with better than 0.3% error. And that is impossible with our theory that the serial-communications-module requires a 16x the baud rate clock. So.... In short: there is some unknown trickery going on inside the CH340, and we cannot rule out that it has a high baudrate error at 250kpbs. On the other hand, someone posted a log file without any errors at 250kbps above. So that indicates that even if there might be a baud rate error, it might be small enough.

Yes, I used 6MHz for a reason. Most "serial communications" modules require a clock of 16x the baud rate: This enables them to detect the EDGE of the start bit, and then start sampling in the middle of the following bits. Moreover they sample at cycle 7-8-9 and do majority voting to filter noise. Even with a 12MHz crystal, they will be using a PLL to make 48MHz to do USB. So the base frequency is likely to be 48MHz. Then using that directly as the clock for the UART module would lead to 3Mbps as being the highest baud rate. Some UART modules will allow you to set "high speed" mode. That means not 16 but 8 is used as the main divider. Less accurate "sample in the middle of the bit". But it should still work. A fractional 1.5 divider or that "high speed" mode would then allow 2mbps. Maybe the divider needs a minimum count.

On the other hand, maybe they have a PLL to generate 14.7456 as their base baud rate. This would allow perfect generation of the common baudrates that are a power of two times 300 bps or 900bps. Read the datasheet to find out....

[hg42]

does not specify anything except that baud rates like 230400 (and many others) are generated with better than 0.3% error

the sentence is very indefinite, so I would not even like to derive this as a fact from it, nor that these baud rates are better than those that are missing. The given rates are just some of the usual ones.

So.... In short: there is some unknown trickery going on inside the CH340, and we cannot rule out that it has a high baudrate error at 250kpbs

yes, that was my point above, most so called "facts" about this topic are speculations and therefore I can only accept them as such. There are too many other reasons for failing communications. Measurements or robust statistical data could help given the lack of definitive data sheet information (if you trust the manufacturer at all).

The log was mine, btw. :-) and that's only one sample and not a really long print.

On the other hand, maybe they have a PLL to generate 14.7456 as their base baud rate.

from my state of knowledge (many years ago) PLLs use dividers on a variable oscillator and then "lock" by comparing the phase between the divided frequency and a reference. Which means it is kind of multiplier. A fraction would use the PLL to multiply with the numerator of the fraction and then divide through the denominator. The fraction would be: 9216 ∕ 625 which would generate fairly high frequencies. But I agree it could use a fraction with more error but lower numbers.

I already said:

So there is something like a PLL or some other means to reach such tolerances with a 12MHz xtal

[rewolff]

With the chip generally not having to do anything above 48MHz, it is unlikely to be able to run the oscillator at much above that. So it's not doing 12*9212 and then dividing that by 625.

But from UARTs we know that fractional dividers are possible. Hints might be found in the Linux kernel driver.

I just looked and from the driver it looks as if they indeed have BOTH a PLL AND fractional dividers. In software with 5 bits behind the binary point, you could just pretend they have a 2^5 times higher base clock. That's what happens. The kernel starts by declaring the base baud to be: 1532620800, 1.5GHz. I suspect that they have 5 bits of fractional divider and a PLL to generate 47.8944 MHz from the 12Mhz crystal.

From reading the kernel driver (for the CH341) I would say that the CH34x comes pretty close.

OK. I went ahead and did some measurements. My FT232 has 0.2% offset at 230400. and 0.05 at 250kbps. My aruduino with CH341 (or similar) gets 0.72% at 230.4kbps and 0.5% at 250kbps.

Note that this was just a quick measurement. I might have made an error somewhere. I measured the elapsed time across 1 million bit-times by sending a 100001 byte file to the port. I then measured the difference between the startbit of the first and last byte.

Still,.... Even if the errors are 10 times larger, they are still well within tolerance: Async serial will continue to work with a bit-time error of max 5% between the two communications partners. When one is perfect, the other could have a 4.9% offset. Anything below 1% is not going to introduce bit errors. Not ever.

Keep in mind that my measurements also have "the frequency offset of my logic analyser" that plays a role. Also the offsets of the crystals on the two boards will play a role. Hmm. My FTDI board does not have a crystal. It's freeloads off the crystal in my PC, doing some PLL stuff to recreate the 48MHz that USB runs from.

[hg42]

nice...thanks for measuring that.

today a (digital) PLL can indeed have fractional dividers. This is done by switching the divisor between N and N+1 (or N and M) in a certain ratio: see http://www.ti.com/lit/an/swra029/swra029.pdf

According to the acceptable errors: The error for baud is to be multiplied by the bits you use, usually is 1 start + 8 data + 1 stop = 10. You must do this because synchronization only happens at the edge from stop to start bit. So with 5% error on each bit (= baudrate) you get 50% shift of the sample point of the last bit, which is the absolute maximum if the sample point is placed in the middle of a bit (you usually want tolerance in both directions). 1% baudrate error would mean 10% for the last bit, which should be pretty safe (40% clearance instead of 50%).

Keep in mind that my measurements also have "the frequency offset of my logic analyser" that plays a role

were both errors in same or different directions?

[rewolff]

IIRC, all measurements gave a baud rate that was TOO FAST. I got 2304xx/230400 = 1.0007xxx Those numbers were always larger than one. So, maybe my logic analyser is terribly slow. (i.e. sampling at only 11.9MHz instead of the claimed 12MHz. It's a cheap chinese device after all...).

[hg42]

so if we assume the likely case that one of the frequencies is exact, it would mean the other is only 0.25% off. I would expect such rates from a fractional-N PLL implementation. And for integer N one of them would be much higher. So I think we can conclude that the simple baudrate error will probably not cause the mentioned transmission errors.

Of course there are other considerations, like manufacturing variations or faults. May be older versions of CH340 had some problems or bad production batches are/were sold cheap. btw what's the difference between CH340 and CH341?

[rewolff]

As far as I know, ch340 is the more recent version that's even cheaper than the '341. I expect that it's more or less the same chip, but possibly with some stuff left out. Like most of the handshake lines. That allows a low cost (SO14) package instead of the larger and finder pitch tsop28 of the 341. I would not assume "one of them is correct". There are small variations, and all devices probably test at less than 1% error: The conclusion must still be that any transmission errors are not the result of bitrate errors.

I have two "arduino mega" clones. One of them is currently running my delta 3D printer, using klipper. One of them was advertized as: "Will NOT work in a 3D printer.... ". As I forgot which one, Either I got lucky or my setup "octoprint/marlin" and now "octoprint/klipper" works better than expected.

[girlpunk]

To confirm, is Klipper currently usable on an Anet A8? This issue seems to have drifted slightly off-topic.

[KevinOConnor]

On Thu, Jan 18, 2018 at 01:49:36PM +0000, Jacob Mansfield wrote:

To confirm, is Klipper currently usable on an Anet A8? This issue seems to have drifted slightly off-topic.

There have been several reports of success. See the config/anet-a8-2017.cfg as a starting point.

-Kevin

[manotroll]

avrdude -v -p atmega1284p -c arduino -P /dev/ttyUSB# -b 57600 -D -U flash:w:/home/pi/klipper/out/klipper.elf.hex:i

now when I connect to the computer I get the unknown device message Is there any way to reverse it?

[manotroll]

re-recorded and resolved but I could not make it work

[manotroll]

pi@octopi:~/klipper $ avrdude -v -p atmega1284p -c arduino -P /dev/ttyUSB0 -b 57600 -D -U flash:w:/home/pi/klipper/out/klipper.elf.hex:i

avrdude: Version 6.1, compiled on Jul 7 2015 at 10:29:47 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch

     System wide configuration file is "/etc/avrdude.conf"
     User configuration file is "/home/pi/.avrduderc"
     User configuration file does not exist or is not a regular file, skipping

     Using Port                    : /dev/ttyUSB0
     Using Programmer              : arduino
     Overriding Baud Rate          : 57600

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xf8 avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x21 avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xee avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xb8 avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x31 avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xba avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xe6 avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xd6 avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0xc8 avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xc8

avrdude done. Thank you.