Hello guys, first let me say that I am new in using the arduino and I'm not familiar with GRBL, I noticed that originally the firmware is not compatible with the MEGA board 2560, but I could also see that it is possible to make a change in code for everything to work. I would like, if possible, could someone tell me how to do it and if these changes are related to the file config.h. And please remember that I am new to the subject and forgive my lack of wisdom.
I am using grbl on a sangunino. You will have to find the data sheet for the Atmega2560 and look at the pin configuration. Change the config.h to arrange the pins as you need. any pin that are in the same group, ie step/dir, limits, etc need will need to be on the same port. If you are planning to use this with a shield, you might not be able to change the pins around to suit. I am pretty new to this too, so there will be other that can give you more direction
I ported it over a while ago to the 2560, it hasn't got the very latest updates to the code but it is a good starting point for you https://github.com/EliteEng/grbl.git
There's an error in config.h. CPU speed is set to 20000000. It should be 16000000. After setting that, you should be able to communicate with the board at the proper baudrate.
It's base GRBL 0.8c changed to work on Mega 1280, for 2560 I think that you must change in Makefile
DEVICE ?= atmega1280
Hi All... I am working on a similar project. I have converted GRBL into Arduino Library so you can upload it with the Arduino IDE.
The last changes I have made was to make it Arduino Mega 2560 comparable. Everything compiles and the when I connect to it with Putty it looks like normal. So from the software side it looks good.
Hardware side has not been tested so I can't guarantee anything but I think its a huge step ahead.
I've checked out the enhanced work on the EliteEng/grbl repo, and it works indeed on my mega2560 based board. I would like to see about getting those features merged into the grbl mainline code, as having forks sounds good, but ultimately just causes confusion over which code base to use. I am happy to help work on this, either by forking (again) and cherry-picking patches and making pull requests, or by direct commit to the grbl code base.
Me and other future QU-BD RPM owners might be able to test when the hardware arrives (I do have a ramps board not used currently). Is there any progress?
The RPM uses the Panucatt Azteeg X3 with 2560.
All of those ports are ugly forks, with (apparently) no thought of integration into upstream. I'm having a go at manually cherry picking the needed changes, and creating pin mappings etc. for the azteeg.
My fork is here: https://github.com/elmom/grbl (master)
It's against the current master, v0.8c
I'm trying to keep it clean, but I don't have the target board yet, so no real testing.
Actaully, the azteeg X3 uses the same pin mapping as RAMPS, which means that the stepper pins aren't assigned to the same port, which would unnecessarily complicate things. So unless someone wants to enable that in GRBL, We'll just have to look into adding spindle control etc. into marlin or some other general purpose firmware.