ARM discussion

[chamnit]

Freely discuss your opinions on an ARM platform for Grbl, moving forward after v1.1.

[alpharesearch]

I think Grbl success is partly to the fact because of standardising on Arduino. It it easy to get an Arduino all over the world. This allows for easy entry with Grbl.
So my question is what board with the right hardware fits the bill for the future. I didn't spend much thought on this yet, but i was interest if someone has any good idea.
Like the Teensy 3.5/6, however these boards are not FOSS as far as I understand. This may be an issue for some people. The Arduino Due is only M3 and @Strooom suggested to use something with M4F for faster floating point math.
I just think it would be good to have one common platform at first to develop and test and know this works.
The next question is how easy is it to connect this to stepper drivers end stops buttons displays etc pp.

[chamnit]

There have been a lot of questions about what Grbl is going to do and how it'll move into the ARM world. Several dozen in the past and again just today from (@alpharesearch and @Strooom). I think it's time to start publicly talking about Grbl's long term strategy now that v1.1 is finally out.

I have an extremely strong feeling against monolithic processor models with a very large codebase, supporting everything on one chip. This does two things:

• Even if its designed to be modular, it's much more difficult to port the code to another processor, whether it be newer, faster, better, or has a new built-in technology.
• You constantly have to worry about breaking something or screw with the critical timing of the core motion processes. This is a headache I'd like to avoid and is the main reason why I've never accepted pull requests.

To improve the core motion control problem that everyone wants, it's critical to retain tight control of what the processor is doing at anytime. So, I think Grbl should remain somewhat independent of the noise and provide just a set of high-bandwidth communication methods to it, not just USART serial. This will allow Grbl to continue developing the hard motion control problem.

As for what processor gets used by Grbl ARM, personally I don't think it really matters. Here's why:

• Grbl, on a slow 16Mhz 8-bit 328p processor, runs great for a vast majority of CNC applications and then some. The new laser mode has been reported to do raster jobs with 0.1mm pixels at a rate of 700 pixels/sec. I've heard a report that Smoothie on a 32-bit ARM 100MHz Cortex M3 can only do 0.5mm pixels at a rate of 500 pixels/sec. I know that it's not quite apple to apples and just one data point, but I was quite surprised that Smoothie isn't running at least 10 times faster. It seems like it's only a minor speed improvement.
• If Grbl's code is that efficient, Grbl should run on any ARM processor selected and run very well on it. Even if Grbl uses a much cheaper Cortex M0 processor, it is theoretically 4x-10x times faster than the 328p. If Grbl on an M0 can just be 2x-3x faster in real-world performance, this can still address a nearly all of the CNC needs now and in the future.
• With my experience as a researcher, developing fast and efficient code and algorithms always trumps using a faster processor. I think Grbl on an M0 will be fine. Grbl on an Cortex M4F could be way overkill.
• If Grbl ARM is written to be small, portable, and independent of peripheral support, the processor selected shouldn't matter. It should be easily portable by design to a Cortex M4F if needed or to any manufacturer.

@alpharesearch : I totally agree with you that Grbl is successful because of the easy of trying CNCing with an Arduino and being able to compile custom or new versions easily through the IDE. I think the Teensy is a good platform, but isn't that great for OEMs due to the bootloader issue. This is why I'm targeting the SAMD21 Cortex M0 series. In my tests, it's more than adequate for everything I intend to do in the short term. It retains the core principal of keeping Grbl easily accessible due to the increasing popularity of the platform.

As for supporting peripherals, I think this really needs to be a separate community project, MIT-licensed, and on a separate MCU directly connected to Grbl ARM as a co-processor model. This will bring in the interest and the help of OEMs and allow users to help out with the project. There is no worry about breaking the motion controller timing and critical processes. The co-processor idea isn't anything new, but I think it really needs get rolling and be officially supported.

[usbcnc]

I have done initial porting of 1.1e to stm32F103RBT6, it can be viewed here https://github.com/usbcnc/grbl.
The spindle control porting should be done next week. (I am a little busy this week).
It does use USB VCP. It does run on my desktop CNC 3020.

I use free coocox IDE to compile and program (STlinkV2).
I am new to CNC and cannot judge the performance difference. I will be more motivated if more people are interested.

[Strooom]

@alpharesearch I think the succes of GRBL is due to:

• good performance on a standard Arduino Uno, which is cheap and available
• running very well on a wide range of HW, due to plenty of configuration settings

Still, I think it makes (IMHO) an entry-level CNC controller. After some years of experience, you may want something with more features and more performance :

• more axis, more limit switches, 3rd order speed profile, larger buffers... (just to name some that I'd like).

As GRBL on an Arduino already does an excellent job at that entry-level, I think the ARM-version should go in the direction of that 'next-after-entry-level' controller. GRBL will still be there when you build your first machine..

When you are upgrading your CNC (or other machine) with this kind of controller, it only makes sense if you also upgrade your hardware. (motor controllers - spindle - bearings - ...) so in the total picture, the cost of the controller board is very small, and should play no important role.

@chamnit I agree that GRBL does a great job on the 16 MHz 328P, but (IMHO) this comes with a price of complexity of the code : in order to fit in the ROM/RAM/CPU-cycles, features are implemented in ingenious, smart ways, but not easy to understand and certainly not easy to modify or extend. Other examples are buffer sizes which are rather small, due to the limited resources on the Arduino (eg. its Rx buffer is too small for GCode maximum block size of 256 bytes). The move to ARM should (IMHO) also relax those constraints. By having 'plenty' of ROM/RAM/CPU I think the code could be more modular and simpler, with more people contributing to it.

I am not aware of Teensy bootloader problems: I program it via the Arduino IDE, I agree you need to manually put it in program mode - minor inconvenience imho.

About Teensy SW not being open - I am not aware of that either - would like more info on that. In general it is my opinion that the ARM sw libraries are better quality than the Arduino...

Thanks for this great discussion!

@Stroom, there is only one @Strooom :-)

[chamnit]

@Strooom @usbcnc : Grbl ARM will not be a direct port of Grbl on the 328p. For same reasons that (one and only) @Strooom stated. Grbl's code is the way it is because of flash, memory, and speed constraints. You simply can't modularize things without effect any one of those. As for complexity, it's not complex to me! :) But don't worry, I plan on re-writing things to be of a more functional programming style so it's easier to test and port.

@Strooom : I hear you on all those things: more axes, higher order motion control, more inputs, and larger buffers. All of that can be accommodated on the SAMD21 series. There is a J-variant that has 64-pins. In the off-chance it isn't adequate, it'll be easy to port to STM or Freescale, as @usbcnc and others has already shown.

The plan has always been to be the LinuxCNC replacement at a minimum. Things like real-time feed hold and overrides needed to be figured out first. Which they now have. Higher-order motion control is next, along with more axes. The crux of the higher-order motion control problem has been solved already. Now it's implementation. A better streaming interface is already planned as well to remove streaming constraints, particularly at high data rates.

Like I said before, I don't accept pull requests in large part due to the sensitivity of maintaining a jitter-free step output without effecting performance. If a separate co-processor model is used and created, the host for Grbl (that would stream directly to it and support LCDs, joysticks, SD cards, Wifi, BLE, native USB, etc.) can be contributed to by everyone. There is no concern of breaking the motion controller with code alterations. You just have to maintain a stream of motions for Grbl ARM to execute. Like you said, the cost of the micro controller is nothing. So having one Grbl ARM controller and a Grbl Host controller is completely feasible and the right way to approach this problem for future proofing.

As for Teensy, Teensy's bootloader chip is proprietary and $8 a piece. This makes it very unfavorable for OEMs or hardware people, but it also protects the Teensy from out-right clones. I understand why Paul has this model, but it's not ideal for companies to use Teensy, which is why you don't see a lot of Teensy-based hardware.

Also, I still don't plan on using any Arduino or Teensy libraries, which Grbl never has. Things are being built on existing software frameworks from manufacturers that are not GPL based.

[alpharesearch]

I was thinking more about a reference design (line the Arduino now) that just works for end users. I guess a plus would be if some of the existing components like stepper drivers can be recycled and other components like displays and buttons from other systems can be used. I just think it would be nice if people can use mainly off the shelf part and create a system with ease and quick.

@Strooom I think is Teensy HW is the only thing that is not open, but the SW should be all good. By the way I personally have no issues with that.

@chamnit if I look around for M0 and M4F development boards at mouser it looks like both have plenty of options and many are priced the same ($10-$40). Do you have a particular development board with M0 in mind?

[gerritv]

SAMD21 example is Arduino Zero. Sparkfun also has a SAMD21G board. The best example is Atmel SAMD21 Xplained board. It is inexpensive and has a J chip, with the full 64 pins. Also has a hardware debug interface on the board which makes it IMO the only choice for development.

Keep the drivers etc off the Grbl board. If you don't then you are stuck with whatever that design is. No changing pins, adding/altering interfaces etc. Keep your HW designs modular.

One thing to keep in mind is that ARM specifies the core cpu and a very few peripherals only. (e.g. interrupt controller). All the other stuff such as USB, I2C, SPI, Can etc is up to the chip vendor. And they all do that differently for the most part. Thus it is not enough to say M0 ARM, you need to pick a vendor to get the details.

[chamnit]

So I spent some time today re-analyzing my decision for SAMD21 and did some benchmarks of the important metrics. While the SAMD21 is indeed at least 3 times faster than the 328p, I'm starting to have doubts again about it. It'll definitely work short-term, but it might be too short. I'll be stuck in another 328p situation. (Surprisingly the stm32F103RBT6 is only twice as fast as an SAMD21. Good but not great.)

This brings me back to the Teensy. There was a time I was committed to the Teensy 3.x series, but the bootloader issue was the main problem. Does anyone have a workaround for this?

[Strooom]

Teensy's bootloader chip is proprietary and $8 a piece

I was not aware of this.
From a personal point of view, 8$ looks justified. From an OEM point of view I understand it may be a problem.
I am a defender of the 'fair share' : for a long term success, all contributors need to get a fair share of the profits and credits. So when considering Teensy as a candidate for the future of GRBL, we need to discuss this with Paul Stoffregen and the top 5 'customers' (Carbide3D, Inventables, Openbuilds, ...)

It's a non-technical thing, but also important to get solved, and better to tackle it early.

[alpharesearch]

I just try to understand the situation, please correct me if I have a wrong assumption.
As far as I understand using Teensy for development would at first would lock Grbl to Freescale Kinetis K64 ARM MCUs. The Teensy has a proprietary programming interface (is this a bootloader too?) that can be used with Arduino IDE. This allows for a easy entry for anybody that used Arduino before.
Do the OEMs create their own boards from scratch right now? What other programming interface/bootloader exists for the Freescale Kinetis K64 ARM MCUs (from my short google search it looks like there is a "FRDM-K64F: Freedom Development Platform for Kinetis K64, K63, and K24 MCUs" with open source hardware and bootloader)?
I would guess if OEMs have multiple options, include a original Teensy with their product or make there own programming interface/bootloader or use the FRDM-K64F design and bootloader.
I just noticed the FRDM-K64F board today for the first time, would this be a reference design option?

[Strooom]

@alpharesearch FRDM-K64F looks interesting. Will look into its spec over the weekend.

[109JB]

It seems most of this discussion is in terms of what platform to use. As an end user, who is by no means as expert in programming, microcontrollers, etc, all I can say is that the means of uploading the Grbl firmware should be easy or I think you will be driving a bunch of potential users away. The current method of uploading via the Arduino IDE is super simple and user friendly. I am not saying that this method has to be the one, but something just as easy would be best. Perhaps once a platform is chosen, a simple interface for uploading can be created by one of the gurus here.

My only other comment about the platform is that it should have enough input and output pins to allow for future expansion. 4 or more axes, limits separate from home switches, spindle encoders, axis encoders, all come to mind.

As for non-platform specific enhancements for Grbl, My biggest vote would be for Spindle feedback for lathe threading and mill rigid tapping- Lack of ability to thread on a lathe makes Grbl almost useless on a lathe since threading is pretty common for lathe operations. On a mill this isn't as big a deal, but would definitely be a benefit. I believe this limitation sends a lot of potential users away for a couple reasons. People who have lathes don't want to switch back and forth the controller they use and so will chose something else like linuxCNC or Mach3/4, and then on their mills they are likely to use the same program rather than have to learn another one. Also, some people using only milling machines will also use them for lathe operations by mounting a chuck to the mill spindle. I do this myself from time to time. and it would be awesome to be able to sync and thread in that case too. This would of course require adding the feedback and also the G-code commands for threading.

[chamnit]

Ok. I think I was jumping the gun a bit on the Teensy or an alternative to the SAMD21. I was reminded of a long term plan that makes the speed of the MCU not as important. However, I think it'd be wise to have the Teensy (or another faster MCU) as a backup. I'll make sure to decouple all MCU processes to facilitate this.

@109JB : As for number of pins, the SAMD21 J variant has 64 pins. Plenty for 4+ axes and limit pins. Even the normal G-variant has enough (38 I/O, 48 total), but they are often not all connected or used for dedicated SPI, USB serial, etc.

I hear you on the lathe threading. It's actually something pretty easy to do. Rigid tapping, on the other hand, is a little more difficult because you need a spindle capable of precise synchronized motions.