Porting to ARM (Arduino Due, MK64F, PSOC 4200/M)

[rspievakc]

I'm in the process to port the code to ARM micro controllers and GCC toolchain. My question is, if is there any project already doing this ? In this case I could contribute to it instead of starting from ground up.
I already have the latest source code adjusted and with hardware abstraction ready. I also created a setup which uses the Segger System View + JLink to trace execution points and verify if the logic + timings are all correct. The hardware abstraction is using inline statements to avoid calling branches.
I'm also testing it with the NXP's FRDM-64F and Cypress PSOC 4200 and PSOC 4200M.
My next question is should I create a new GitHub repository or if I should share the code inside the GRBL tree ?
Thank you for the help.

[terjeio]

I am also currently porting to ARM, Texas instruments Tiva C (TM4C123GH6PM). My HAL implementation is based on pointers to functions. I will change the code into a library as my intention is to integrate it into another project for a CO2 laser controller I have made. I am in no hurry since I already have Mach3 support for my controller - GRBL port to be completed by the end of this year?

I understand the GRBL core team is also working on a HAL - but I do not know what their approach is, maybe it is restrained by the fact that 8-bit processors are still to be supported?

[cri-s]

What is the reason you make different port for tivaC ?
Il 02/lug/2016 23:05 "Terje Io" notifications@github.com ha scritto:

I am also currently porting to ARM, Texas instruments Tiva C
(TM4C123GH6PM). My HAL implementation is based on pointers to functions. I
will change the code into a library as my intention is to integrate it into
another project for a CO2 laser controller
http://www.buildlog.net/forum/viewtopic.php?f=16&t=2625&p=24072#p24072
I have made. I am in no hurry since I already have Mach3 support for my
controller - GRBL port to be completed by the end of this year?

I understand the GRBL core team is also working on a HAL - but I do not
know what their approach is, maybe it is restrained by the fact that 8-bit
processors are still to be supported?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1030 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AJEOltHQWj4jdqV1_ox0gSkJV8qBP5p6ks5qRtKwgaJpZM4JAXOb
.

[terjeio]

@cri-s Not sure what you mean by "different", anyway my main reason is that my laser controller is Tiva C based and the port is targeted for that. Another reason is that I want to do some hardware/firmware design just for the fun of it (and for learning) - even if I can buy existing controllers for less money.

[chamnit]

@terjeio : There not much of a "team" Grbl, as it's just been myself for a very long time. 8-bit support will be dropped soon after v1.0 is released. I will be moving on to investing all my time to continuing to develop the ARM version, which is a complete re-write of the Grbl base code. Grbl itself is designed specifically for the 8-bit AVR and has a lot of "unsavory" code that was written for the interest of maximizing performance and reducing compiled flash size. Mainly the latter. The ARM version has no such restriction, and there are a number of algorithmic improvements that will make it better on a fundamental level. I won't divulge what they are, but they will be awesome.

[rspievakc]

Is there a way to collaborate on the ARM's port work ?
Em 2 de jul de 2016 19:37, "Sonny Jeon" notifications@github.com escreveu:

Closed #1030 #1030.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1030 (comment), or mute the
thread
https://github.com/notifications/unsubscribe/AEa6D0-w29DE1eN7mpdlxCXy1RBqAyMZks5qRugMgaJpZM4JAXOb
.

[chamnit]

@rspievakc : No, not at this time, but I do regularly keep tabs on people port Grbl to different ARM chips. It always helps to see how other people attack the problem .

[cri-s]

@rspievakc : lasaurGrbl is a port that always targets to tivaC123,
even if that board and cpu
was sold by Ti under different name. I think 2 year ago @mschorer
ported grbl to tivaC123G , https://github.com/mschorer/grbl with
simple and clean abstraction interface.

2016-07-03 0:35 GMT, Sonny Jeon notifications@github.com:

@rspievakc : No, not at this time, but I do regularly keep tabs on people
port Grbl to different ARM chips. It always helps to see how other people
attack the problem .

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1030 (comment)

[terjeio]

@cri-s : Many thanks for the pointer to the existing Tiva port - I will look into it. I can see from a quick glance that the HAL is #define based - I am using a struct containing pointers to functions, this means that the HAL will be completely separated from the main Grbl codebase for different implementations - resulting in easier porting and maintenance (IMO).

[mschorer]

Nice to see that the "port" didn't go unnoticed .. :-)

My goals were:

• do not increase the original 328 code size
• create an as-thin-as-possible abstraction layer
• get going as fast as possible on the tiva
• possibly make @chamnit include such an abstraction layer so i wouldn't
  have to maintain it myself ;-)

Up until now i've done a boosterpack/shield for the tiva, added basic
support for spi, quadrature encoder ... this will drive my next home built
cnc.
Sadly, i'm not finding a lot of time to work on this recently .. :-(
Am 03.07.2016 17:25 schrieb "Terje Io" notifications@github.com:

@cri-s https://github.com/cri-s : Many thanks for the pointer to the
existing Tiva port - I will look into it. I can see from a quick glance
that the HAL is #define based - I am using a struct containing pointers to
functions, this means that the HAL will be completely separated from the
main Grbl codebase for different implementations - resulting in easier
porting and maintenance (IMO).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1030 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACW6b-tSjWjezOsy61o_vWdeJz_6H664ks5qR9RvgaJpZM4JAXOb
.

[ericwazhung]

Search-fu fails again! But this time, with a slight twist... Figures this thread came along (and to my attention) long after my work was well in progress.
So I've spent the past three+ weeks doing basically what it looks like @mschorer was doing... similar goals. Lacking an atmega with enough pins, I've been porting to PIC32, but with intent to keep the hardware-level interfacing separate from the main grbl functions such that re-porting to another architecture should be as simple as writing the appropriate macros (pin-stuff) and functions (timer-setups, ISRs, etc).
Again, lacking an atmega, I've been compile-checking all my changes with the original build through the entire process, after hundreds of changes, the atmega328p still compiles to be byte-for-byte identical to the original (.8j, as I recall).
I've added some mods to the makefile (etc.) to account for multiple architectures, #including the architecture-specific headers, and adding architecture-specific C files to the SRCs where appropriate, etc. Otherwise, basically, what I've done looks quite similar to the TivaC port.
Not quite ready to make it public, but would be willing to share with developers interested in comparing with the original.
So far all that's lacking is eeprom support... that bit is extremely architecture-specific, so still in contemplation as to how/if to go about it.
Lacking stepper-drivers with step/dir inputs, I was also planning to actually implement microstepping directly in grbl, as an option. Though, with my chips' 5pwm outputs that'd be limited to two axes, there's no reason it couldn't be extended to more on other architectures. I figured it to be more of an extension to the original grbl step/dir code, rather'n a rewrite of its stepping algorithms; basically just replacing the step/dir pin-toggles with function-calls (if enabled) as opposed to the GPIO_write() style macros they currently call.

[usbcnc]

This is my attempt to port GRBL 1.0d to STM32F103C8T6. https://www.youtube.com/watch?v=ehgXMa2spWM&feature=youtu.be. I only have 3020 CNC and no limit switch is tested. I will soon buy limit switch to install on my CNC to test the feature. Spindle or coolant features are not implented. It uses micro USB (serial port simulation). The EEPROM implementation uses 1K of flash to store the data. I use
CooCox IDE. It is still not ready to make it public but I can send to anyone who is interested. I found this module actually has 128KB flash instead of 64KB flash which is published in the datasheet.

[selenur]

"usbcnc" How can I contact you?

[usbcnc]

Here you are. There is also one WIndows simulation project (which helps to debug the code). You might need to modify the folders. The STM32 project files was under STM32GRBL. The grbl files are under grbl-masterwin. (Yes the Windows simulation files are in it). To enable EEPROM simulation for STM32 you need to uncomment NOEEPROMSUPPORT in grbl.h. There is really no need if you just run it on your machine or debug the code since it might eventually kill the life of the flash. But this feature works. What I did is use a flush function to write to flash instead using STM's EEPROM library. That one needs at least 2K flash and GRBL's EEPROM can be easily emulated. The same emulation was done for Windows too. (Check eeprom.c).

To run Windows simulation, if you do not have any serial port then it accept keyboard. If you have TWO serial port and connect TX-RX each other, you start the win-grbl with the parameter of one serial port (say grbl COM3), you can run gcode-sender on another serial port and it works, you can put break point anywhere to debug the code.

I first ported to Windows and since Windows does not like the some C style (declare variable in middle), I changed that quite a bit).
grbl-masterwin.zip.

[ericwazhung]

https://github.com/ericwazhung/grbl-abstracted/tree/master

[chamnit]

@ericwazhung : Awesome! Thanks for sharing!

[terjeio]

Here is my approach towards HAL abstraction. Code is NOT tested with physical machine and is NOT complete, it is posted here only for sharing ideas.

Stepper driver ISR executes in about 7uS on 80MHz Tiva C processor...

grbl-TivaC.zip

[usbcnc]

Finally learned how to use github to push changes.
Here is my my port for STM32F108C8T6 and a Windows simulation. https://github.com/usbcnc/grbl-Mega
Windows version is fully simulated. STM32F108C8T6 port is tested on desktop CNC3020. There is no need to remove the parallel port board for Mach 3. Just a small convert board attached to the control box and the system works just as good with very little cost.