Gen7 working with Marlin_v1

250000 wouldn't work for me, though theoretically it is the best rate. 115200 isn't, but does the job. The following table shows the UBRR and % error rate for various baud rates and processor speeds.
[www.wormfood.net]

Hi droftarts,

Super table you found, I often find myself making one in excel when I ponder bit rates because I have lost my previous table.
It indicates the available bit rates very well and should be recomended reading for all async comms designers.

The 250k on the ATmega is spot for both crystal freqs on but it is possible suitable dividers are not available on the PC or USB converter device and the error for 250k may be more than 5% from that side while two similar converters (or loop back) may work because the error is in the same direction. I had not realised that the dividers were at such low integers already so picking a good frequency is pretty important, some will just not be available at high speeds.

It should also be noted that RS-232-C was never designed for those speeds though RS-232-D may be specified to 150k bits IIRC There have been a number of charge pump (single rail) level shifting IC's that were not able to support those speeds used in consumer gear, the direct 'TTL' output USB converters should do the job but having a USB to RS-232 converter and then converting it back to TTL levels may cause slew-rate problems at those high speeds.

droftarts Wrote:
-------------------------------------------------------
> 250000 wouldn't work for me, though theoretically
> it is the best rate. 115200 isn't, but does the
> job. The following table shows the UBRR and %
> error rate for various baud rates and processor
> speeds.
> [www.wormfood.net]

Hi JazzyMT,

My suggestion was to stay with 115k2 rather than go to 250k as long as the rate was within 5% (which the linked tables indicate) as the popular rate is likely to have better compatibility even though the theoretical bit rate for the 250k might be spot on. So I was just reinforcing your decision, no intention to suggest wasting time trying 250k.

Could you see which side the timing was wrong? Perhaps the ATmega was ok.

JazzyMT Wrote:
-------------------------------------------------------
> I don't understand your point. 115200 bps is THE most common rate in modern devices. I didn't change to it for no good reason - 250k would not
> work. I tried to read it on my logic analyzer and the timing was all screwed up. I don't know what the cause was, but it works fine at 115k so
> that's what I'm using. If someone else has trouble communicating at 250k, I'd recommend they try 115k too.

Kalle
--
Johannesburg, South Africa

can someone help me here with marlin cause I got no clue how to configure it got a regular 1.31 board and well a 664p or a 1284p @ 20 mhz traumflug has updated the bootloaders and such to work with the 1.x arduino software but I dunno if you can compile marlin on this but I have the old standard 664@20mhz bootloader on my chip I dunno if I need to change the bootloader or not . I can give all my data here
I got no endstops wired at the current moment
and this is my other data
steps per mm on x and y = 114.285714
steps on z= 1133.85827
steps on e= 325
bed size achivable currently is 175 on x and 185 on y
I'm going to try to tweak more out of this in the future
help
please
terramir

Where did you read that Traumflug updated the bootloader ?

All I get in his post is that he provided it along with his new Gen7 Arduino IDE Support package, not that it has to be flashed again.


Edit : as for Marlin, github still says to use "the arduino software IDE/toolset v22", so if you try to compile it on arduino studio 1.0 and meet errors, you'd probably get no support.

Edited 1 time(s). Last edit at 05/03/2012 04:36AM by DeuxVis.

---

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.

The new bootloader is a few bytes smaller, but this doesn't really matter. The reason why it was released is it's 1284P support.

As long as the bootloader works, i.e. one can upload a firmware, there's no need to replace it. Bootloader and firmware are entirely independend from each other. The bootloader doesn't influence firmware compilation either.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

as for Marlin, github still says to use "the arduino software IDE/toolset v22", so if you try to compile it on arduino studio 1.0 and meet errors, you'd probably get no support.

The new Arduino IDE Support is meant to make this part of Marlin obsolete. If there are errors I'd be interested in reading them.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Ah, nice to get corrected. I'll try that soon as a penitence.

---

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.

so I can upload this bootloader on my 1284p @ 20 mhz and then use the aruino --23 package to complileht e firmware right?
now if I can get someone to help me see through all the things I need to figure out I'll be running marlin in no time
terramir

Quote

so I can upload this bootloader on my 1284p @ 20 mhz and then use the aruino --23 package to complileht e firmware right?

No. The avrdude coming with Arduino 0023 doesn't know about the ATmega1284P.

If you insist on compiling with Arduino 0023, compile the firmware, fish the .hex file out of the temporary directory -- on Linux that's in a sub-folder of /tmp -- and upload it with the avrdude coming with Arduino 1.0.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

scuba I got a 1.31 board and I really need decent instructions as of right now I cannot find any tried sprinter and I can't get anythiung to move even though 1.31 is supposed to be supported I dunno why, so I really need some help

terramir

Sorry I haven't worked with "sprinter" till now... you can send me an pm and describe what you've done so far. Maybe I can guide a little with some more information.

KalleP Wrote:
-------------------------------------------------------

> Hi JazzyMT,
>
> Could you see which side the timing was wrong?
> Perhaps the ATmega was ok.
>
> Kalle
> --
> Johannesburg, South Africa

Wups - didn't see your reply until now. I did see which side - I connected the logic analyzer to the ATmega without a computer - I just watched the "ok" message over serial on startup. The timing wasn't off by a small amount of error - I can't remember the number, but it was off by a significant multiplier. I suspect it is a configuration issue when using Marlin with Gen7 and 20Mhz. 115k seems to work perfectly, but 250k must not have all the timing settings change correctly because it's way off.

For what it's worth - I've been using 115k for weeks now and it works fine on everything so far.