Compiling GRBL for Teensy3.1

[physisisics]

I just picked up a Teensy3.1 and I'm interested in running and learning from your port of GRBL. I'm new to the arm architecture and I have a lot of reading cut out. I would greatly appreciate it if you would post compiling instructions. Specifically, how do I start from,and what do I need from your minimal k-20 environment? If I understand the Makefile correctly, all I need to do is define the compiler path from the teensy tools. Also, I need to define the vendor path from your k-20 environment, and not the default teensy vendor file, correct? Is the other code outside of the vendor file relevant (i.e. flex_test.c, int_test.c, etc)? Thanks for your time.

[physisisics]

I've managed to get a compile from the makefile with a few path changes, but the generated hex file is just 3.2KB. It uploads to the board, but doesn't seem to initiate the USB serial, since there are no visible COM ports. I've tested the USB serial interface with a simple arduino sketch and it works fine. Do you have any suggestions? Thanks again.

[matthewSorensen]

Awesome, someone interested in this! I'm sorry about the lack of documentation or polish at the moment. I really only open-sourced all of this to show my people my progress in a grbl issue discussion.

All of the code outside vendor/ is irrelevant random stuff I wrote when getting the hang of K20 development. I really should delete it.

When you were compiling it, the environment only supported the teensy 3.0. The behavior you describe sounds exactly like what happens when you try to execute a binary for the wrong processor and the chip panics and dies. I just got my hands on a teensy 3.1, so I can now actually attempt to support it - I just pushed some commits to the k20 environment that should be more or less what is required. I'll try to spend Saturday testing grbl on the 3.1 and cleaning up documentation and build procedure.

Thanks, MDS

[physisisics]

Fantastic! Thanks. I've seen so many discussions about using the teensy for GRBL that I'm surprised I'm the first to show interest!

I've made a little bit of leeway in the compiling process. Disclaimer: I am far from a knowlegable programmer, just a hobbyist. It wasn't clear to me what changes, if any, you made to the default teensy vendor files, but I grabbed the new versions of USB__, mk_dx_128._, and the new mk20dx256.ld . I had to make a few changes to the makefile. I had to define MK20DX256 at compile because the new mk_dx_128.h sets up the USB differently based on the teensy3.0 and the teensy3.1. I also switched the *.ld files in the makefile to be consistent. After all that, I'm still only getting a 3.2KB hex.

Also, I think you should keep the code outside of the vendor/ since good examples for arm processors are hard to find. Perhaps just move it to an examples/ or a tests/ directory.

[matthewSorensen]

I just updated this repo to move all of the vendor c, headers, and linker scripts from the environment to a subdirectory, and updated the Makefile to deal with that. It compiles, links (~93k hex), and uploads, but hangs after executing one move. I don't have time tonight to perform more testing on the new processor, or figure out why changing processors makes it hang.

[physisisics]

Great! It compiled! But it also hung for me after one move. I know you are busy so there is no hurry here. I just wanted to write it down while I'm thinking about it.

I get a compiler warning when compiling usb_dec.c about an ultoa() function (unsigned long to string I assume) which you've defined in your nonstd.c file. ultoa() usually is a stdlib function, but you've expressly compiled without it in the makefile. There doesn't seem to be a header file for nonstd.c so, my question is, without a header file for that how does usb_dec. access your function ultoa()?

[physisisics]

I created a header file for nonstd.c and included it into usb_dec.c and that got rid of the compiler warning. I also wonder, you have another file called init.c without a header file; What is it used for?

[matthewSorensen]

The situation with ultoa is more or less unchanged from the original Paul Stoffregen usb serial code.

init.c is called from the reset handler vector in mk20dx128.c and takes care of configuring some aspects of the hardware, such as enabling interrupt handlers for GPIO. I'm not particularly fond of it; most of that code belongs in the grbl port itself. mk20dx128.c has a declaration for the relevant function, so it sees the right type and such.

[physisisics]

I just chased the ultoa() issue down in Paul Stoffergen's code and he defines the ultoa() function in the header file "avr_functions.h". It seems, if there are no conflicts with other code, we should include that in the vendor/ directory and uncomment that header file from the nostd.c. Did you comment out some of the code in nostd.c because of conflicts, because it is there in Paul's code?

[matthewSorensen]

Ah, interesting. At the very least, I'll define a prototype for it somewhere.

I chased down the bug causing hangs after executing all of the moves currently in the queue - the delay in st_go_idle doesn't work when called from an interrupt context. Switching from spinlocking on the millisecond counter to just counting instructions seems to fix that, at the expense of less timing accuracy.

Next on my queue is getting all of the "eeprom" functionality working.

[physisisics]

My cnc is disassembled at the moment, but I've been software testing and your fix and it is also working at my end. As far as I understand, st_go_idle is not a critical function that needs timing down to even a millisecond anyway. Infact, I just keep my motors always enable. I have a few more questions and comments about the flexram/eeprom functionality. However, I think I should open another issue for that instead of posting it here.

May I add a section to the Wiki explaining the Make/Build processes (at least on Windows)? And also, perhaps add a .hex file for easy of adoption.

[matthewSorensen]

My cnc hardware is also disassembled at the moment, so this code hasn't actually controlled stepper motors that are attached to anything. Once my current school term ends in two weeks, I plan on fixing that and actually spending some time on fully testing the port.

Issue #1 is about flexram/eeprom stuff - I'm sure there's something silly with addressing, checksums, or configuration going on, but I haven't revisited that bit of the code.

Please go ahead and make whatever changes to the wiki you want - I'll be able to review them and post more documentation tomorrow. At the very least, I'll revise and edit the notes I took on the initial modifications needed to get things compiling for the K20.

[ashelly]

I'm very interested in this port also. I've got it to compile - what am I supposed to be using to download it?

[physisisics]

Once you've built the .hex file, you can install it with teensy loader. Just open the hex file, turn on the auto load function in the teensy loader program, and push the reset button on your teensy.

[ashelly]

Thanks. It's working now. I'll try to get some testing done tomorrow.

[matthewSorensen]

Cool - but please be careful if you're testing it on motors with real hardware, as neither of us seems to have gotten to that stage and I've probably made some silly error somewhere.