Joining Teensy support

[Traumflug]

DaveX aka. drf aka. drf5n has uploaded his branch for the Teensy 3.0: http://forums.reprap.org/read.php?146,195325,199577#msg-199577 Great work!

I had a look into this and see a lot of commits duplicating commits already on the master branch. These could vanish by rebasing this branch to more recent commits of the master, or even Gen7 branch. Rebasing would also allow a better overview of what actually makes the Teensy support.

Are you fine with me doing this rebasing, David? The code at the top of the teensy3 branch wouldn't change, but before pushing, you'd have to follow upstream first, like:

git pull

in case you're already on the teensy3 branch, or

git pull
git checkout teensy3
git rebase origin/teensy3

in case you were elsewhere. If you have different ideas, I'm all open. :)

[drf5n]

I'm fine with you doing the rebasing. I had long been doing "git fetch" with "git merge" to get my working directory up to date with the changes external to me, but it sounds like instead of "git merge" a "git rebase" at interesting points in my working directory's history would have been more useful.

If you are willing to rebase/revise the .../teensy3 history to something more sane, I'm happy with it.

[Traumflug]

Wether rebasing or merging is better, is probably a matter of taste. Rebasing is a potentially lossy process while merging, especially if done rarely, can create huge commits. The latter makes bisecting (going back in the repo's history to find the introduction of a bug) often pointless.

For my part I rebase very often and avoid merging at all. The more often a rebase happens, the simpler potential conflicts are.

I'm just done with rebasing the teensy3 branch onto the Gen7 branch. On top I added a commit with all the unintentional changes introduced with the rebase (due to solving the 50+ conflicts) to make sure the result is identical. Now we can got through all the commits left, from early to recent, to either eliminate or cherry-pick them. "rebase -i Gen7" is your friend. At the end of this process, teensy3 should be fully integrated into master.

[Traumflug]

Reduced the number of commits on the teensy3 branch from 44 to 34. The result should remain pretty much the same, most of the deleted commits actually canceled each other.

[Traumflug]

Down to 21 commits. Some minor comment modifications and picked some of the intermediate debug code onto the Gen7 branch to keep it.

drf5n, what's the situation about usb_serial.h/.c? The teensy3 branch deletes them. Perhaps I've lost overview over all the USB-Serial code variations, but deleting doesn't intuitively look good. We want to keep the Teensy 2.0, too, after all. :-)

[drf5n]

Regarding the usb_serial.{c|h}, there was a different usb stack for the teensy3 using some of the same names. It would probably be better to keep and #ifdef the same old Gen7 usb_serial.* for the AVR and make it disjoint with the usb_serial_t3, usb_dev, usb_desc, and usb_mem teensy3 code, or maybe blend those together into a single #ifdef-exclusive usb_serial_ARM.* alternative.

For the Arduino/Teensyduino build process, it seems like it might be creating a new working directory and then copies the .../hardware/teensy/cores/teensy3/* stuff into the working directory, copies the sketches files in, then creates something from the .ino file and then compiles and links everything together using the options in the hardware/teensy/boards.txt file. If that's right, it seems like that process could have issues with name clashes as well.

[Traumflug]

Over a year later ( :-) ), I rebased the teensy3 branch to master again. 14 commits left, mostly the lookahead stuff is gone (because it's already on master).

Along the way I edited these patches to make the result compiling for AVR. IMHO, there's still an urgent need for sorting architecure dependent stuff. How about such an approach (fictive example):

File: cpu.c

#include "cpu.h"  // to guarantee common function declarations

/** \file
  \brief Initialize the system to a known state.
*/

#if defined __AVR__
  #include "arch-avr/cpu.c"
#elif defined __ARMEL__
  #include "arch-arm/cpu.c"
#else
  #error Unknown system architecture.
#endif

This should be compatible with Arduino & Co.

Another question I haven't found an answer so far: is the Cortex-M4 (Teensyduino, many others) similar enough to the Cortex-M0 (Gen7-ARM) to allow a common architecture for both?

[drf5n]

That seems reasonable.

I'm not sure. I'll dig up a teensy3 board and try this out.

[drf5n]

Added a couple changes to allow 'make -f Makefile-teensy3' compile per #93.

Would the arduino 'compile everything' approach compile the arch-*/ subdirectories?

[Traumflug]

Would the arduino 'compile everything' approach compile the arch-*/ subdirectories?

Yes, because 'everything" applies to code in the main directory, only. Stuff inside arch-*/ subdirectories isn't compiled directly, only through #include's in files in the main directory.

[drf5n]

I just learned to use the USER_CONFIG environment variable, as in:

 USER_CONFIG=config.teensy3.h make -f Makefile-teensy3

It makes switching between branches and config files much easier--thanks.

Also, the Arduino compile for teensy3 fails because teensy stuff is mostly copied from the Arduino addons for teensy, so, for example, the usb_serial_t3.c duplicates the /Applications/Arduino.app/Contents/Resources/Java/hardware/teensy/cores/teensy3/usb_serial.c code and then clashes with duplicate symbols.

If I'm interpreting it correctly for the AVRs, Arduino copies all the files from its cores/... directories into the build directory, potentially overwriting the distribution files with local copies, so you don't have clashes For the teensyduino ARM build within Arduino, it seems to build directly from both sources into the temporary build directory, then tries to link them multiply.

The easy way to fix it might be using a Makefile cflag -DTEACUP_MAKEFILE to ifdef out the Teacup versions when compiling in Arduino, but that seems like you could get unexpected behavior with by using one set of code for makefiles and another in Arduino. Renaming things to avoid name clashes might be cleaner, but harder to maintain.

[Traumflug]

Looking at Arduinos' verbose output, it compiles with this flag: -DARDUINO=105 This might help distinguishing between an Arduino and a Makefile build.

[Kenzu]

If I want to use teacup on Teensy 3.1, does it have to be a real teensy or can I just use the same chip MK20DX256VLH7 as the one on teensy 3.1? Is there some bootloader/compiler problems with that?
And if I can use just the same chip, could it be any chip in the same series?

Thanks

[Traumflug]

@Kenzu, comparing these chips' data sheets should give you an answer. If there are different requirements it's possible to change the code, of course. As your question doesn't exactly sound like you want to jump into hacking, I'd go with a Teensy.

[Kenzu]

I'am in the process of making my own electronic. As I can read on Teensy, there is a closed source bootloader to support arduino IDE. It would be cheaper/easier to use a chip in the same series on my board rather than a hole teensy.
So this patch, does it make use of the teensy bootloader?

[Traumflug]

Nope, a bootloader isn't part of Teacup, neither makes Teacup any use of a possibly existing bootloader.

[Traumflug]

@drf5n, do you still know how you compiled this thing? With which Arduino version? There's a user asking in the RepRap forum: http://forums.reprap.org/read.php?147,469915

He gets errors on lines containing "BSS".

I just checked out the teensy3 branch and tried to compile, but don't get far:

$ make -f Makefile-teensy3 
  CC        build/usb_dev.o
usb_dev.c:3:23: fatal error: mk20dx128.h: No such file or directory

[michaeljball]

Thank you Traumflug. The mk20dx128.h ( or mk20dx256.h ) is part of the Arduino Teensy extension. Compiling from within the Arduino IDE (yeah... I know...) provides this...
Any help appreciated.

[Traumflug]

Now, did you swap to Arduino IDE 1.5?

[Traumflug]

Also, installing Git is a good idea:

sudo apt-get install git gitk
git clone https://github.com/Traumflug/Teacup_Firmware.git

Then you can swap between branches in a snap. Like

git checkout <branchname>

And fetch updates like

git pull

Much easier than downloading and unpacking tarballs.

[michaeljball]

[shameful admission] I have Git installed, just not very good at the command line... I know... I know... [/shameful admission]

[michaeljball]

Downloading Arduino 1.5.8. will install Teensyduino extensions and try recompiling.

[michaeljball]

Sorry... The Teensy3.1 Developer has stated that they do not yet support Arduino 1.5.x, but are working on a port for 1.6.x currently.

https://forum.pjrc.com/threads/27740-Arduino-1-6-0-any-plans-to-support-it?p=64407&viewfull=1#post64407

[Traumflug]

I take this 1.5 recommendation back. Teensyduino package apparently comes with a comiler, see Forum discussion.

[Traumflug]

I've just rebased the teensy3 branch to master, so you get the newer goodies. Let's cross fingers it still compiles. :-)

[michaeljball]

"I've just rebased the teensy3 branch to master, so you get the newer goodies. Let's cross fingers it still compiles. :-)"

Very much appreciated!!!

Teensy3 branch? Or the Teensy3.1 branch? The former compiled but does not function. The latter is fully functional.

[Traumflug]

Teensy3 branch? Or the Teensy3.1 branch?

It's the teensy3 branch, without .1. This branch is the one which got a commit recently, so I assumed this is the currently working one.

Fine to see teensy3.1 working, but it's now some 200 commits behind. For example, no adaptive homing feedrates, no CoreXY support. Rebasing is no rocket science if done commit by commit, like

git checkout teensy3.1
git rebase experimental~500
git rebase experimental~499
git rebase experimental~498
...

Can also be done in bigger steps if you're brave. Compiling and trying occasionally is a good idea. You always have the origin/teensy3.1 branch as backup.

Probably you noticed, all this ARM stuff is a bit messier than AVR. There is no MCU support (no -mmcu) in arm-gcc and no hardware support (register definitions) in arm-libc. It's nice that what we currently have it working on the Teensy, but it's a solution which works only there. Nowadays we also have the Arduino Due, the Gen7-ARM and quite a number of other ARM based controllers.

I've put some research into finding a solution which works for all these MCUs. Two of them are on the gen7-arm branch (each of the two commits there), just a proof of concept. The second commit uses MBED as a subrepository, but then I was notified the MCU of the Arduino Due isn't in MBED. Code in MBED is also somewhat wasteful with resources, a simple Hello World for the serial line builds to > 8 kB.

The solution I'm currently seeking for is to collect the neccessary files from CMSIS (sort of a sub-part of MBED) and copy them into the Teacup repo. This allows to also collect files from vendors not in MBED, e.g. the Arduino Due. This is what the first commit on the gen7-arm branch does. It's not too complicated and once the base works, the other neccessary solutions are already on these two teensy3 branches.

If you want to put some work into there: greatly appreciated. For myself I'll work on this Configtool milestone first, because that's what I consider to be the biggest bottleneck for attracting new users. Then I hope to finally find the time to get this Gen7-ARM running with the strategy described above. The board sits on my desk and has collected quite a bit of dust already :-)

[michaeljball]

Thank you for your time in all of this. I'm fairly familiar with MBED and CMSIS hardware abstraction. It is very likely the right way to go. As for the Due not being in MBED... That's a travesty. (Merely by number of Due boards purchased, I do not have one) However...
You might want to look at platformio.org They have pulled together a cross-platform compiler framework and library dependency resolver that includes over 100 boards... including the Arduino Due. I did a writeup on PlatformIO here.

I'm currently being tasked to get a GCODE firmware running on Freescale's FRDM-K64F development board, so I won't be back on the Teensy for a few weeks.

I'll look at what's involved in updating the 3.1 branch at that time.

Thanks again.

[Traumflug]

You might want to look at platformio.org

Looks like a good collection of tools. Had a look at the various blink examples and each uses different code, so apparently no hardware abstraction. Certainly worth a look when we get into trouble with the tools available/findable, though.

Configtool works nicely for building and uploading. AVR-only, so far, but nothing stopping ARM support. Whatever can be put into a script can also be run by Configtool. Configure, build, upload from one place. Perhaps even printer calibration in some nice future.

I'm currently being tasked to get a GCODE firmware running on Freescale's FRDM-K64F development board, so I won't be back on the Teensy for a few weeks.

Not Teacup? D'oh. :-)

[michaeljball]

Configtool IS looking pretty nice. Congrats, and good luck. :)

As far as Teacup on the Freescale board... They want me using the Kinetis Design Studio with Processor Expert and the SDK.

I'll admit that when you're used to cutting and pasting a few lines of code per pin/function, and it just working... going back to a visual tool is a bit of a challenge. LOL