search

gnea / grbl

An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino
https://github.com/gnea/grbl/wiki
Other
4.07k stars 1.61k forks source link

Grbl for Mega 2560 #714

Open MartinLedesma opened 5 years ago

MartinLedesma commented 5 years ago

Hi! I'm proving an arduino MEGA 2560 + RAMPS 1.4 + Grbl - mega but I can't get the steppers motors move! I used XLoader and Universal GCode Sender. I had proved with simple code uploaded with Arduino IDE, and the motors worked. Please, a I need some help!

adammhaile commented 5 years ago

@MartinLedesma there's a different grbl for the mega -> https://github.com/gnea/grbl-Mega

wdunn001 commented 4 years ago

@adammhaile why does the mega have its own?

adammhaile commented 4 years ago

@wdunn001 Don't know for sure. Was just pointing it out.

3RD-Dimension commented 4 years ago

@adammhaile why does the mega have its own?

Different pin assignments etc than the Uno so some things need to be changed.

bdurbrow commented 4 years ago

Actually, the whole processor is different - more/different peripherals, etc. Uno uses an ATMega328, the Mega uses an ATMega2560.

wdunn001 commented 4 years ago

@bdurbrow wouldnt the processor not matter though to the codebase it's just a different compile target.

wdunn001 commented 4 years ago

Different pin assignments etc than the Uno so some things need to be changed.

any estimate on how hard it would to add checks for compile target to each pin assignment?

I'm thinking like a configuration file if (compile target == '2560') { pinForX = 1} else { pinForX = 5 }
or use a switchcase for more targets. then use pinForX variable throughout the application.

It may be way harder than I think lol this isn't my wheelhouse but I'd be willing to help.

bdurbrow commented 4 years ago

There's more differences between the chips than just the pinouts. Timers are different, as are the serial ports. Could the codebases be unified via #ifdef directive's? Yes... but... that doesn't really provide an advantage; considering that the ARM version is going to be a major re-write; and the AVR versions are considered mature products at this point (only major bugs will be fixed; and as far as we know, there aren't any major bugs). In other words, having them be the same body of code doesn't provide an advantage when they are stable and not being extended with new features.

Also, FWIW, unless you are careful, using regular control flow keywords (if, switch, etc) can end up generating tests that happen at run time instead of at compile time; using the pre-processor makes that impossible to happen. For a codebase that is dependent on real-time performance, as a matter of general programming style, it's a good idea to take approaches that avoid this potential pitfall.