Arduino-Pi Ramblings

Update on the Dancing Brushbot:

In my last posting, I mused about the potential of making this cheap wind-up toy actually move about...

possibly avoid obstacles...

Well, I've had some time to think and plan, and dismember the cheerful little dude...

Here is the sum of his parts.

You'll notice the little white box lower middle of the picture. That is the spring wound mechanism that made him dance...

It fit inside the body, in an area roughly 2.5cm high by 1.5cm wide by 1cm deep.

The is the space I have for electronics...

This is the underside of our friendly Hexbot Nano, with the battery removed. I'll be simply connecting to the positive and negative battery wires for this build.

Opened up, you can see the miniature "pager" motor with the offset weight that vibrates the Hexbot Nano.
I've also placed the protection diode inside the body of the Hexbots, as there was no room on the main circuit board.

I then hotglued the Dancing bot's feet onto the tops of the Hexbot Nano's and drilled a hole to pass the motor wires through.

Here is the blank board in it's body casing. That's it. That's all the room I have for electronics.

Luckily, an Attiny84 in socket, as well as a power connector and the ISP header all fit exactly on the board! I couldn't have asked for a better fit!

The Sharp GP2Y0A21YK Infrared Distance Sensor is hotglued onto the stub that held the original Dancing bot's head, and the LiPo battery is velcroed onto the front of the body.

Here, the ATtiny84 control board is placed into the body for sizing.

Assembled, and ready to code. I've placed the AA battery in the picture to demonstrate the size of this guy.

Watch this space over the next few days, as I get this guy up and dancing...

(currently having problems with balance/center of gravity... this too will be conquered)

References:

Programming an ATtiny w/ Arduino 1.0
LetsMakeRobots: Mogul - Program standalone ATtiny / ATmega chips through an Arduino
LetsMakeRobots: Ladvien - Robot Metallurgy 101 -- AVR Lesson Journal
LetsMakeRobots: attiny85 h-bridge ldr robot
LetsMakeRobots: Lumi - TinySpider
http://www.iheartrobotics.com/2009/12/upgrade-led-hexbug-hack.html

I am revisiting my code for the OSLRF01 Open Source Laser Range Finder, as the thought occurred to me that I should be using the ATmega built-in Analog Comparator to determine the rise time of the return pulse.

I will outline the new code in an upcoming post, however.....

This post is about my failure to clearly RTFM:

In this case, it would be the Atmel 8bit Microcontroller Datasheet specifically Section 22 on the Analog Comparator (Page 246) and Table 13-9 on page 88:

So let me state a simple fact that I ignored:

AVR digital pins AIN0 (D6), and AIN1 (D7) are NOT the same as AVR Analog pins A0 and A1.

Nick Gammon has this simple diagram on his site for using the AVR Analog Comparator, that I've looked at a dozen times:

It Clearly shows AIN0 and AIN1 associated with Digital pin D6 and D7 respectively. Yet I continued to try using A0 as my reference voltage, and A1 as the incoming analog signal.

I mean *Why on god's green earth would I compare analog signals on digital pins, right?*

It was only by chance that I was reading a similarly puzzled users question on the Arduino Forum:

Re: comparator to compare between AIN0 and AIN1
« Reply #2 on: March 01, 2012, 08:28:47 am »
Quote
It is possible to select any of the ADC7..0 pins to replace the negative input to the Analog Com-
parator. .....
If ACME is cleared or ADEN is set, AIN1 is applied to the negative input to the Analog
Comparator.
A0 and A1 are not the same as AIN0 and AIN1.
Quote
PC1 (ADC1/PCINT9) pin and PC0 (ADC0/PCINT8)
PCINT23 /AIN1 - pin D7 and PCINT22/OC0A/AIN0 - pin D6)
There is "working" example:
Code:
//Configure Analog Comparator, Video Input Capture
  ADCSRB &= ~(1<<ACME);
  ACSR   &= ~(1<<ACD) ;           // Analog Comparator disable off
  ACSR   |=  (1<<ACIC);

  ACSR   |=  (1<<ACIS1);          // comparator detection edge
  ACSR   |=  (1<<ACIS0);          //** 10 - falling, 11- rising:  ACSR &= ~(1<<ACIS0)
  DIDR1  |=  (1<< AIN0D);         // disable digital input buffer AIN0/1
  DIDR1  |=  (1<< AIN1D);
Digital pins 6 and 7 as comparator inputs.
BTW, should you clear a flag after printing?
<Insert the sound of a hard forehead smack here>

References:
http://www.arduino.cc/en/Reference/PortManipulation
http://www.billporter.info/2010/08/18/ready-set-oscillate-the-fastest-way-to-change-arduino-pins/
https://github.com/projectgus/digitalIOPerformance
digitalWriteFast, digitalReadFast, pinModeFast etc <--- needs to be updated for Arduino 1.0+
https://code.google.com/p/digitalwritefast/downloads/list <--- needs to be updated for Arduino 1.0+
http://www.lightware.co.za/shop/en/laser-sensors/24-oslrf-01.html
http://arduino.cc/en/Hacking/Atmega168Hardware
https://github.com/TMuel1123/Arduino/blob/master/FastPins/FastPins.h <-- this one looks promising but needs the pins mapped...
http://tmuel1123.blogspot.ca/2014/01/fastpinsh-or-way-to-realize-really-fast.html
http://forum.arduino.cc/index.php/topic,94534.0.html
http://www.avr-tutorials.com/comparator/utilizing-avr-analog-comparator-aco
http://www.avr-tutorials.com/sites/default/files/ATMega8515%20Analog%20Comparator_1.pdf

I am an UBUNTU biggot... there, I said it!

I use Ubuntu 13.10 as my primary Operating System day in and day out. If I *have* to use something else, I have access to MS Windows XP, Windows 7, and OSX Mountain Lion through the magic of VirtualBox. <---- you Really want to try this!!

As part of my Dancing Brushbot project, I had to move out of my comfort zone in programming AVR chips. I'm quite familiar with using the Arduino IDE to program *Arduino* boards, and have also used the IDE to program ATtiny8x chips by connecting them to an Arduino UNO ...

For the current Brushbot project, I had made a small standalone ATtiny84 board with a builtin AVR ISP connector for programming without having to remove it from the robot.

I went to my local Robots Supply Store and purchased this Pololu AVR ISP programmer.
As I had previously programmed ATtiny chips with the UNO, I already had the proper Boards.txt configuration.

This should be simple right?

Wrong!

I plugged it in to my laptop USB port,
plugged the AVR ISP plug into the robot board
From the Arduino IDE, selected "Tools/Board/ATtiny84 (internal 8 mhz clock)"
Also from the IDE Selected Tools/Programmer AVR ISP
Selected the correct USB serial port (/dev/ttyACM0)
attempted to upload the compiled "Blink" sketch.

and it failed...

AVRDUDE (the application that actually communicates with the Atmel processors) could not sync, told me to check my serial ports, etc...

Now if you read my previous posting, you'll understand that I am RTFM challenged.

So I dug in, and did a little research, and quickly found http://openenergymonitor.org/emon/buildingblocks/avrisp

3. AVR ISP V2 - Pololu USB AVR Programmer (http://www.pololu.com/catalog/product/1300). This is quite a cheap programmer that works well on Linux Ubuntu, it can only programmed at 5v (needs 4V on MOSI pin to initialize) and requires the board to be externally powered. The following lines need to be added to programmers.txt in the Arduino Hardware folder:
avrispv2.name=AVR ISP v2
avrispv2.communication=serial
avrispv2.protocol=avrispv2

Using sudo, I opened /usr/share/arduino/hardware/arduino/programmers.txt, and added the following 3 lines:

avrispv2.name=AVR ISP v2
avrispv2.communication=serial
avrispv2.protocol=avrispv2

I closed and reopened the Arduino IDE, and the new programmer showed up. I selected it from the Tools/Programmer menu, and again attempted to upload.

and it failed...

Remember that RTFM issue?

Looking at what I posted here from the Openenergy blog a paragraph up...

This is quite a cheap programmer that works well on Linux Ubuntu, it can only programmed at 5v (needs 4V on MOSI pin to initialize) and requires the board to be externally powered.

This lead me to read the Pololu manual for the ARV ISP programmer (gasp!)

And this comment on the pololu forum:

Re: Pololu USB AVR Programmerby JeremyT » Fri Sep 13, 2013 3:34 pmYou can configure the Pololu USB AVR Programmer through Linux using PgmCmd from the Pololu USB Software Development Kit. PgmCmd is a command-line status and configuration utility. More information, such as how to compile the code, can be found in the README.txt in the SDK. By the way, I still recommend configuring it via Windows, as it would probably be easier.
I have programmed an Atmega8U2 running at 3.3V with the Pololu USB AVR Programmer in Windows, and I do not expect there be a difference in programming with Linux, as long as the programmer is configured correctly.
Using a level shifter, like the one you linked, would probably work. A resistor voltage divider would also suffice. However, I did not have any voltage divider when I programmed the Atmega8U2.
- Jeremy

(Note: as the AVR chips can run at up to 5.5v they do not need a level shifter)

I then downloaded the Pololu USB Software Development Kit for Linux. and read the Readme.txt file (I know, eh?)

To compile their C# applications, you need mono installed:
sudo apt-get install libusb-1.0-0-dev mono-gmcs mono-devel libmono-winforms2.0-cil

In the top level directory of the downloaded SDK, type "make".

From there, I was able to cd to the pololu-usb-sdk/UsbAvrProgrammer/PgmCmd folder, and execute the AVR ISP programmer's command line utility

./pgmcmd --list

PgmCmd: Configuration and status utility for the Pololu USB AVR Programmer.

Version: 1.0.1.0

Options:

-l, --list list available devices

-d, --device SERIALNUM (optional) select device with given serial number

-s, --status display complete device status

--freq NUM sets the ISP frequency (in units of kHz)

--linea ID

or --lineb ID set serial control signal associated with line A or B.

Valid IDs are: none, cd, dsr, ri, dtr, rts.

Warning: dtr and rts are outputs: -f option is required

--swminor HEXNUM AVR ISP software version minor (in hex, e.g. A)

--swmajor HEXNUM AVR ISP software version major (in hex)

--hw HEXNUM AVR ISP software hardware version (in hex)

--vddmin NUM set minimum allowed target vdd (units of mV)

--vddmaxrange NUM set maximum allowed target vdd range (units of mV)

--restoredefaults restore factory settings

--bootloader put device in to bootloader (firmware upgrade) mode

then ./pgmcmd --status revealed...

Serial number: 00060244
Firmware version: 1.07
Settings:
ISP Frequency: 200 kHz
Line A Identity: None
Line B Identity: None
AVR ISP hardware version: F
AVR ISP software version: 2.A
Target VDD allowed minimum: 4384 mV
Target VDD allowed max range: 512 mV
Last programming:
Error: None
Measured Target VDD Minimum: N/A
Measured Target VDD Range: N/A
SLO-scope:
State: Off
Line A output: Off
Line B output: Off

So... I ran ./pgmcmd --vddmin 3200
to set a minimum VDD value of 3.2v.. resulting in...

Serial number: 00060244
Firmware version: 1.07
Settings:
ISP Frequency: 200 kHz
Line A Identity: None
Line B Identity: None
AVR ISP hardware version: F
AVR ISP software version: 2.A
Target VDD allowed minimum: 3200 mV
Target VDD allowed max range: 512 mV
Last programming:
Error: None
Measured Target VDD Minimum: N/A
Measured Target VDD Range: N/A
SLO-scope:
State: Off
Line A output: Off
Line B output: Off

I plugged the robots battery in (remember that requires the board to be externally powered comment?), plugged in the AVR ISP cable, opened the blink sketch in the Arduino IDE, and clicked the upload icon......

(drum roll please!)

The leds under the Sharp IR distance sensor came to life!!!

Stay tuned for Funky Robotic Vibratory Dancing!

References:

Pololu USB AVR Programmer User's Guide
AVR ISP Programmers
Stackexchange: How to use a Pololu 5v AVR ISP Programmer to program an AVR at 3.3v
forum.pololu.com: Pololu USB AVR Programmer - Ubuntu
Pololu: Pololu USB Software Development Kit
http://forum.arduino.cc/index.php?topic=73027.0;wap2
http://runawaybrainz.blogspot.ca/2013/05/arduino-pololu-usb-avr-programmer.html
http://provideyourown.com/2011/arduino-program-attiny/
http://www.open-electronics.org/arduino-isp-in-system-programming-and-stand-alone-circuits/
http://www.instructables.com/id/How-to-program-attiny-using-arduino-uno/
http://www.instructables.com/id/Using-the-Arduino-Uno-to-program-ATTINY84-20PU/
http://42bots.com/tutorials/programming-attiny84-attiny44-with-arduino-uno/
http://www.batsocks.co.uk/readme/isp_headers.htm
http://highlowtech.org/?p=1695

The many features and beautiful simplicity of the venerable Arduino, have captured the minds and imaginations millions of hobbyists, programmers, and Roboteers.

Arduino, as a company, has created a diverse number of boards as Open Source Hardware . This diversity caters to various physical, electrical, and I/O requirements, allowing for a broad spectrum of applications.   That said, an entire industry has sprung up around reproducing variants of the Arduino.

All of these boards, however, have two things in common.

They use Atmel AVR 8bit microcontrollers(Typically ATmega328 or in the case of the Mega - ATmega1280 or 2560)
They have an Arduino bootloader installed to allow quick and convenient development/upload cycles with the Arduino IDE.

One of the most recent trends, has been to reproduce the Arduino form factor, complete with I/O, A/D and D/A for other microcontrollers, to allow them to utilize the hundreds (thousands?) of "shields" developed to support the Arduino family.

Many of these alternative boards have also provided plug-ins (cross compilers and compatible libraries) for the Arduino IDE, to allow a smooth transition from the comfort of developing for the Arduino's 8bit AVR chip to a more complex 16 or 32bit microcontroller.

Today, I'm going to discuss the Teensy 3.1.

https://www.pjrc.com/teensy/teensy31.html

Although not pin compatible with the Arduino family, it does leverage the Arduino IDE through Teesyduino for quick application development, while hopefully grooming it's users to step into more robust ARM development tools. If UNO form factor compatibility is a requirement (for instance to use an existing shield) then the Teensy Development board from PetitStudio will do the trick.

The Teensy 3.1 is based on the Freescale K20P64M72SF1 ARM Cortex M4 processor. It runs at 96Mhz, has 256K flash, and 64k RAM, 43 digital I/O, 21 Analog inputs, 12 PWM outputs, 12 Timers, 2 I2C ports, and 4 Serial UARTS. Whew...

In addition to that, there are two TRUE Analog to Digital Converters that can be read simultaneously ie: no multiplexing inputs. Currently, Pedvide's ADC librarycan be used to access both ADCs. Thanks to Freescale, there is also a CAN Bus.
(Controller Area Network - communication channel used in automobiles) Libraries for this will be available shortly.

Comparison Of Arduino UNO R3, Mega2560, and Teensy 3.1 specifications

Technical Specifications
Feature	Arduino Uno R3	ArduinoMega2560	Teensy 3.1	Units
Price	25	54	19.8	US Dollars
Processor	Atmega328	ATMega2560	MK20DX256VLH7
Bits	8	8	32
Core	AVR	AVR	Cortex-M4
Rated Speed	16	16	72	MHz
Overclockable	24	24	96	MHz
Flash Memory	32	256	256	kbytes
Bandwidth	16	16	192	Mbytes/sec
Cache	0	0	256	Bytes
RAM	2	8	64	kbytes
EEPROM	1	4	2	kbytes
Direct Memory Access	N/A	N/A	16	Channels
Digital I/O	14	54	34	Pins
Voltage Output	5	5	3.3V	Volts
Voltage Input	5	5	5V Tolerant	Volts
Analog Input	6	16	21	Pins
Converters	1	1	2
Resolution	10	10	16	Bits
Usable	10	10	13	Bits
Prog Gain Amp	0	0	2
Touch Sensing	N/A	64	12	Pins
Comparators	1	1	3
Analog Output	0	0	1	Pins
DAC Resolution	-	-	12	Bits
Timers	3	6 Total	12 Total	Pins
FTM Type	0	0	3
PWM Outputs	6	12	12
PDB Type	0	0	1
CMT (infrared) Type	0	0	1
LPTMR Type	0	0	1
PIT (interval) Type	1x8bit 2x16bit	2x8bit 4x16bit	4
Systick	0	0	1
RTC (date/time) **	0	1	1
Communication
USB	1	1	1
Serial	1	0	3
With FIFOs	0	0	2
High Res Baud	0	0	3
Fast Clock	0	0	2
SPI	1	1	1
With FIFOs	0	0	1
I2C	1	1	2
CAN Bus	0	0	1
I2S Audio	0	0	1
FIFO Size	0	0	8

Now, if you've happened to get this far, here is the meat of this article:
There are few "shields" available for the Teensy as yet. There are a few adapters that provide UNO form factor, there is an audio shield, a TFT display shield, and a Smartmatrix shield, as well as a few other special use shields.

What I am looking to develop, is a multifunction shield that maintains the small size of the teensy as much as possible, but incorporates a 9dof like the LSM9DS0 Teensy 3.1 Micro Shield, as well as an l293d to drive two small DC motors. I2C, as well as Remaining I/O will be brought out to right angle headers on the edge of the shield.

Before I complete the board design, I'm looking for feedback, motivation, and warnings (like "that l293 is going to get too hot!") ...

Cheers.

References:

https://www.pjrc.com/teensy/K20P64M72SF1.pdf
http://cache.freescale.com/files/32bit/doc/ref_manual/K20P64M50SF0RM.pdf
http://cache.freescale.com/files/32bit/doc/quick_ref_guide/KQRUG.pdf

My Teensy Playlist on Youtube

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=K20_72
https://www.pjrc.com/teensy/td_libs_USBHostShield.html
OSH Park: SmartMatrix Shield for Teensy 3.1
https://community.freescale.com/thread/320695
http://hackaday.com/2013/12/09/meet-the-teensy-3-1/

http://trippylighting.com/category/uncategorized/
SmartMatrix Shield for Teensy 3.1
Adafruit 2.8" TFT Touch Shield for Arduino for Teensy 3.1
https://www.tindie.com/products/loglow/teensy-31-breakout/
http://petitstudio.blogspot.ca/2014/04/teensy-3-development-board-arduino.html
Audio Adapter Board for Teensy 3.0 & 3.1 and OctoWS2811 Adapter for Teensy 3.1 – Control tons of NeoPixels!
http://www.mccauslandcenter.sc.edu/CRNL/tools/oscilloscope
Github: KurtE- Modified version of Trossen Bioloid library to user Serialx objects
https://github.com/KurtE/Teensy3.1-Breakout-Boards
http://zentasrobots.com/
http://www.circuitsathome.com/category/mcu/arduino/usb-shield

http://forum.pjrc.com/threads/26017-Teensy-3-1-and-9DOF-Stick-I2C
https://github.com/ptrbrtz/razor-9dof-ahrs/pull/20
https://www.tindie.com/products/onehorse/lsm9ds0-teensy-31-micro-shield/
https://github.com/Poofjunior/RaspPi-Teensy-USB-ServoController

Development tools:
PCJR.com : Teensyduino IDE extension
http://www.seanet.com/~karllunt/bareteensy31.html
http://embedxcode.weebly.com/
http://www.uTasker.com/freescale/Teensy_Simulator.zip
http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/overview/
Teensy 3.0 now supported by the USB Host library
Freescale Hack It Together (H.I.T.) Project Initiative - Get Excited!

YAY!!!! I got it working!

Back in the end of May, I enrolled in the beta for Kinetis Design Studio installer for Linux to allow me to develop on my Teensy 3.1 bare-metal,
only to find that it would not run on my Ubuntu 14.04 64bit. I'm running Oracle Java 7.

Kinetis Design Studio installed properly from DEB, but when I launched it, it immediately complained that it could not load the SWT library for Eclipse. It turns out that they built the Debian (Ubuntu) base on 32bit Eclipse.

After some futzing around, I opened a case with Freescale Support: (putting the details here for search engine assistance)

SR Number: 1-2152355207Date Opened: 07/28/2014 05:28:35 PHX timeSubject: kinetis-design-studio will not load in Ubuntu 14.04Description: Fresh install of Ubuntu 14.04uname -aLinux ballmik-Satellite-L305 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Running Oracle Java java version "1.7.0_65"Java(TM) SE Runtime Environment (build 1.7.0_65-b17)Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

Eclipse appears to be built for 32bit platform. is the a 64bit version ?attaching eclipse log.
Thank you.
!ENTRY org.eclipse.osgi 4 0 2014-07-28 08:06:23.472!MESSAGE Application error!STACK 1java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: /home/ballmik/.eclipse/org.eclipse.platform_4.3.2_870091379_linux_gtk_x86/configuration/org.eclipse.osgi/bundles/430/1/.cp/libswt-pi-gtk-4335.so: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directoryno swt-pi-gtk in java.library.path/home/ballmik/.swt/lib/linux/x86/libswt-pi-gtk-4335.so: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directoryCan't load library: /home/ballmik/.swt/lib/linux/x86/libswt-pi-gtk.so

Their quick response was that the DEB was built on/for Ubuntu 12.04LTS 32bit....

Not helpful... So... life got in the way, and I finally returned to this last night. With fresh eyes, I simply searched G00gle for "running 32 bit eclipse on 64 bit Ubuntu 14.04" and came up with a bunch of different solutions.

The issue is that in 64bit Ubuntu base install, the 32bit libraries are not installed. period.

Prior to Ubuntu 14.04, you used to be able to "sudu apt-get install ia32-libs", but they removed this ability recently because dpkg now has multi-arch enabled by default. MEANING, that if you actually knew what libraries were failing, you could reinstall them with a :i386 at the end of the package name. Seemed like a lot of work to find the specific libraries...

Here's what worked for me.
(from Stackoverflow: How to install ia32-libs in ubuntu 14.04 LTS)

sudo -i
cd /etc/apt/sources.list.d
echo "deb http://old-releases.ubuntu.com/ubuntu/ raring main restricted universe multiverse">ia32-libs-raring.list
apt-get update
apt-get install ia32-libs

Reboot, and voila! Kinetis Design Studio is now working!

Now, on to figuring out how to code for the Teensy 3.1...

Resources:

Freescale: Kinetis Design Studio
Ubuntu.com: Multiarch
Stackoverflow: How to install ia32-libs in ubuntu 14.04 LTS
Teensy 3.1 Bare-Metal

Right now, I use Arduinos for motor control (PID control for encoders and dc motor) as well as aggregating sensor data and feeding the Raspberry Pi on my Autonomous Rover.

The Pi runs a live stream webcam for the rover, manages the webpage control console, and maps the environment for dead reckoning navigation. This is a lot of work for one little CPU.

I've recently seen a few articles on using the dormant GPU on the Pi. and though that Simultaneous Localization and Mapping (SLAM) would be perfectly suited for the GPU's capabilities. Real world mapping and localization should be practically identical to Video Game based algorithms... It's been almost a year since Broadcom opened up the specs for this chip.

I would also use the GPU for calculating shortest path via A* routines.

So... has anyone looked into this?

(And yes... I "Googled" it first...)

References:

Andrew Holme: Accelerating Fourier transforms using the GPU
Pete Warden: How to optimize Raspberry Pi code using its GPU
GPGPU hacking on the Pi
Hacking The GPU For Fun And Profit (Pt. 1)
Broadcom released the specs for the VideoCore IV GPU
SLAM: Remotely-Processed Visual SLAM Using Open-Source Software

As I re-engage my3D Repscrap printer project, I have decided to replace the two 8bit AVR based Arduino pro minis running at 16Mhz with a single Teensy 3.1, 32bit ARM core M0 based board running at 96Mhz. The Teensy is significantly faster, more powerful, and still only $20USD.

I was considerably influenced to change my direction based on this incredibly detailed Blog over at Freescale. Nikki Verriddagari, a Freescale developer, managed to replace the typical Arduino Mega2560 seen in most Reprap style printers with the Teensy 3.1 inside of 3-4 weeks, as a side project.

Both the Teensy and Reprap communities rallied to assist Nikki through a few difficult spots, and huge kudos to the developer of the Teensy 3.1, Paul Stoffregen, for working on the Teacup code with Nikki and getting it debugged and working!

The Freescale MK20DX256VLH7 processor used on the Teensy has two hardware based Quadrature Encoder modules built in. There is a good appnote on how to use them at Freescale.

"The FlexTimer is a complex, general-purpose timer module that also possesses special features dedicated to a motor control application"

While perusing the Teensy 3.1 developer's site, I came across a forum article where tlb had created a library to use these FTM to read two quadrature encoders. This looked like as good as anything for a starting point.

Im using his QuadDecode library for the X and Y axis, and have decided to manage both Z-Axis encoders through hardware interrupts. My thoughts being that the Z-Axis travel is both minimal and predictable. I believe (I've been wrong before!) that Z-Axis movement is conducted typically after a horizontal layer of X/Y is completed. However!!! This does not preclude error correction in the Z-Axis PIDs. If something were to bump the extruder or a collision occurred that caused the Z-Axis to change, the PID would try to correct, and the interrupts must be responsive enough to handle this. Running at 96Mhz, I'm confident enough to give this a good shot.

My Design Concept:

I'm basing my requirements loosely on the RAMPS/Mega design, but for DC motors and quadrature encoders.

There will be four DC motors: One each for the X and Y axis, and two for the Z axis. All will have inexpensive DC brushed motors. The X and Y axis will have linear optical encoders, while the Z axis will have rotary optical encoders. (This is a mechanical decision for MY implementation, the electronics and firmware should not care). All motor/encoder pairs will have endstops at each end of their travel.

To manage PWM for four DC motors, as well as PWM for the Extruder heater, Bed heater, and fans, I am choosing to borrow a design from Adafruit's Motor Shield V2.3. In this shield, they employ a PCA9865 I2C 12 bit PWM controller, driving a pair of dual Mosfet H bridge TB6612FNG motor drivers.

A standard Pololu stepper motor driver board will be used to manage the extruder.

Primary communications will be via the Teensy's USB Serial interface, however I am including a uSD card reader for future plans to read G-Code directly from uSD card.

Starting with the example pinout used in the QuadDecode library, I have drafted up a connectivity chart and initial schematic that I will be wiring up over the next few days.

Teensy 3.1 Based 3D printer with DC motor/Quad Encoders

Next blog will include photos of the build.

Please feel free to provide constructive criticism as I journey down this path.

References:
PJRC Forum: Hardware Quadrature Code for Teensy 3.x
PJRC: Teensy 3.1 Encoder Library
Freescale: Configuring the FlexTimer for Position and Speed Measurement with an Encoder
Freescale: PMSM Vector Control with Quadrature Encoder on Kinetis
Kinetis: K20 Sub-Family Reference Manual
Data sheet: Supports: MK20DX64VLH7, MK20DX128VLH7, MK20DX256VLH7
Teensy 3.1: Pulse Width Modulation
Loglow: Interval Timer Library for Teensy
PJRC: New I2C library for Teensy3
PJRC: Connecting headers to those pins on the bottom of the Teensy 3.1

This will be a short post today.

I had mentioned putting up pictures as I go along, so I took this to show the first prototype of the controller board.

Here is the layout of my Teensy 3.1 based 3D printer controller.

As of this shot, I have not yet wired it. Nor have I installed the analog components (power supply, heater drivers, pullup resistors, filter capacitors, etc...). It is also missing the connector for the extruder stepper motor.

As I described in my previous post, my motor control design is based on Adafruit's Motor Shield V2.3. For my prototype... well... I'm using their shield, pilfered from one of my older robots. This fantastic design employs an NXP PCA9865 16 channel 12 bit PWM controller, intended to drive LEDs, but instead to driving a pair of dual Mosfet H bridge TB6612FNG motor drivers.

The Library for this Shield works with the Teensy 3.1 just fine. (It is just I2C after all).

Ok... I'm off to wire this up... wish me luck.

Here's some more shots of the controller prototype..

I've added a DC/DC converter for clean 5v power to the electronics (5amp). I've also added a separate 5v linear regulator for the Extruder stepper circuitry.

To get access to the extra pins on the bottom of the teensy, I used a dual row header, and bent the inside pins at a 90 degree angle, trimmed, and soldered.
The shot on the right shows the Real Time Clock crystal soldered into place.

And of course I use my
legacy 3D extruder
religiously to lay down layers of plastic "wire holders".

This is where I wish I had kept all of my old wire wrap tools... Who knew I'd pick up electronics again after almost a 20 year hiatus.

Anyway, power and ground...check.

Now to the rest of the wires..

Sorry that this is taking so long, but... (continued from last week...)

I finally have enough of the control board wired up that I can test the I2C library with Adafruit's Motor Shield V2 as well as the Adafruit LCD Backpack.

I simply took the DCMotorTest2 arduino example from the Motor Shield library, and added the LCD functionality.

Note: Both the Motor Shield Library, as well as the LiquidCrystal libraries needed to be modified to work with Teensy 3.1.

As the Teensy is not AVR based, the I2C functions a bit different (better, trust me!)

In both instances, references to the "Wire" library had to be replaced with Teensy's "I2C_T3" library. ie:

//#include <Wire.h>
#include <i2c_t3.h> // Replacement I2C library for Teensy 3.1

Also in the Motorshield library as well as it's underlying PWMServoDriver library, I had to force it to use the correct I2C channel. As the ARM processor in the Teensy has two separate I2C channels, it was defaulting to the second one.

I found this little snippet at the beginning of each library, and modified it to use the first I2C channel.

#include "Adafruit_MotorShield.h"
#include <Adafruit_PWMServoDriver.h>
#ifdef __AVR__                        // Teensy definitely is not AVR, so it defaults
#define WIRE Wire
#else // Arduino Due               // to wire1 as per the next line.
// #define WIRE Wire1           // Wire1 in Teensy world is the second I2C

#define WIRE Wire // So i simply commented out and replaced.
#endif // Not elegant, but...

And here is the example code to simply ramp the DC motor from 0-255 forward, back down to 0 and then do it again in reverse. All the while displaying status on the 20x4 LCD panel.

/*
This is a test sketch for the Adafruit assembled Motor Shield for Arduino v2
It won't work with v1.x motor shields! Only for the v2's with built in PWM
control

For use with the Adafruit Motor Shield v2
---->    http://www.adafruit.com/products/1438
*/

//#include <Wire.h>
#include <i2c_t3.h>
// wire for Teensy 3.1 per https://forum.pjrc.com/threads/21680-New-I2C-library-for-Teensy3
#include <Adafruit_MotorShield.h>
#include "utility/Adafruit_PWMServoDriver.h"

// Create the motor shield object with the default I2C address
Adafruit_MotorShield AFMS = Adafruit_MotorShield();
// Or, create it with a different I2C address (say for stacking)
// Adafruit_MotorShield AFMS = Adafruit_MotorShield(0x61);

// Select which 'port' M1, M2, M3 or M4. In this case, M1
Adafruit_DCMotor *myMotor = AFMS.getMotor(1);
// You can also make another motor on port M2
//Adafruit_DCMotor *myOtherMotor = AFMS.getMotor(2);

/*
Using with the Adafruit LCD Backpack to display information
---->    http://www.adafruit.com/products/292
*/

#include "LiquidCrystal.h"

// Connect LiquidCrystal display via i2c, default address #0x20 (A0-A2 not jumpered)
LiquidCrystal lcd(0);

int spd = 150;          // Motor PWM speed from 0 - 255
int mState = FORWARD;   // State of the motor

void setup() {
Serial.begin(9600);           // set up Serial library at 9600 bps
Serial.println("Adafruit Motorshield v2 - DC Motor test!");

// set up the LCD's number of rows and columns:
lcd.begin(20, 4);
lcd.print("Adafruit Motorshield v2");
lcd.setCursor(0, 1);
lcd.print("DC Motor test!");

AFMS.begin(); // create with the default frequency 1.6KHz
//AFMS.begin(1000); // OR with a different frequency, say 1KHz

// Set the speed to start, from 0 (off) to 255 (max speed)
myMotor->setSpeed(spd);
myMotor->run(mState);
mState = RELEASE;
// turn on motor
myMotor->run(mState);
}

void loop() {

Serial.print("tick");
lcd.setCursor(0, 3);
lcd.print("tick");

mState = FORWARD;
myMotor->run(mState);
lcd.setCursor(9, 2);
lcd.print(" Dir = FWD ");         // Display direction on LCD

for (spd=0; spd<255; spd++) {
    myMotor->setSpeed(spd);
    lcd.setCursor(0, 2);
    lcd.print("PWM = "); lcd.print(spd); lcd.print("");
}
for (spd=255; spd!=0; spd--) {
    myMotor->setSpeed(spd);
    lcd.setCursor(0, 2);
    lcd.print("PWM = "); lcd.print(spd); lcd.print("");
}

Serial.print("tock");
lcd.setCursor(0, 3);
lcd.print("tock");

mState = BACKWARD;
myMotor->run(mState);
lcd.setCursor(9, 2);
lcd.print(" Dir = REV ");         // Display direction on LCD

for (spd=0; spd<255; spd++) {
    myMotor->setSpeed(spd);
    lcd.setCursor(0, 2);
    lcd.print("PWM = "); lcd.print(spd); lcd.print("");
}
for (spd=255; spd!=0; spd--) {
    myMotor->setSpeed(spd);
    lcd.setCursor(0, 2);
    lcd.print("PWM = "); lcd.print(spd); lcd.print("");
}

Serial.print("tech");
lcd.setCursor(0, 3);
lcd.print("tech");

myMotor->run(RELEASE);
delay(1000);
}

Again, trivial, but it validated that my wiring is correct this far, and that the I2C libraries are functional.

Over the weekend, I'll get the Quadrature Decoders and PID control running, and post another update then.

I am quite happy with my results in getting the Xaxis and Yaxis PID control working Trudy's Quadrature Decoder for the Freescale Kinetis K20 (K20DX256-72MHz) used in the Teensy 3.1.
A big thank you to Miguel Sanchez for his help and inspiration.

Here's a video snip of a quick demo showing the tuned X and Y carriages tracing out a simple 1500x1500 square. The purpose of this demo was to simply allow me to tune the PID parameters for each axis.

I'm currently torn between two separate development tracks. The first track is using the Beta6 version of the PID library, cascading Velocity and Position, and defining velocity profiles for each axis. I've had a fair bit of success in this track, and will publish code and results in a few weeks.

However, the main track I'm following currently is to get my DC motor control on the Teensy 3.1, working within Teacup_firmware. For expedience and simplicity, this forces me to emulate a stepper at the moment, passing STEP/DIR commands from Teacup into my motor drive logic. The reason for splitting the tracks is that the cascaded PID control does not function well in small encoder increments. Ramp time in the Velocity PID is calculated from position delta... blah blah blah..

My Teacup inspiration came from Nikki V's awesome blog series in when she builds a Teensy 3.1/RAMPS based 3D printer controller over the course of about a month. I highly suggest you go read through it.

Anyway.... I have had some difficulty (my own lack of awareness) in getting Teacup compiled properly on Ubuntu 14.10 for the Teensy. Yesterday, I opened issue #122 and was answered within hours!

I'm currently using the newest teensy3 folder from Paul Stoffregen's git repo https://github.com/PaulStoffregen/cores

Dave "drf5n" answered my logged issue, and set me straight. (It also looks like he's working on Marlin... I should ask him about that..)

I backed up and then removed the version of Teacup_firmware I was currently working from, then issued:

git clone https://github.com/Traumflug/Teacup_Firmware.git && cd Teacup_Firmware

After downloading and changing to the directory, I checked out the teensy3 branch:

git co teensy3

Then, again carefully following instructions, updated the correct files in the folder to reflect the Teensy hardware. The makefile also needs to be modified to point to your ARM toolchain and link to the above mentioned Teensy Core library.

$ cp config.teensy3.h config.h
$ cp ThermistorTable.single.h ThermistorTable.h
$ cp Makefile-teensy3 Makefile
$ make

Aaaaaaand..... Success! Compiled!

Tonight's plan is to modify the config.teensy3.h file to properly reflect the Teensy pinouts for the hardware configuration I have built.

References:

https://community.freescale.com/thread/320695
http://reprap.org/wiki/Teacup_Firmware
https://github.com/Traumflug/Teacup_Firmware
https://github.com/Traumflug/Teacup_Firmware/issues/122

http://www.idt.mdh.se/kurser/ct3340/ht09/ADMINISTRATION/IRCSE09-submissions/ircse09_submission_22.pdf

Further update on my Repscrap 3D printer progress...

Here is the current schematic. Once I realized that I had blundered with the I2C based motor shield, I re-worked the design to directly drive four H-Bridges plus the stepper driver for the Extruder.

To get enough pins on the Teensy 3.1, I had to give up the second endstop on each axis, but I can now directly accept four Quadrature Encoders, and drive four DC motors.

Features included on this build:

Two Flex Timer Hardware controlled Quadrature Decoders (X/Y AXIS)
Two Hardware interrupt based Quadrature Decoders (Both Z AXIS)
Four PID controlled PWM DC motor drivers (X/Y/Z1/Z2)
One stepper driver for the extruder
Three thermistor inputs (Extruder and two bed)
Three heater PWM drivers ( (Extruder and hot bed)
uSD card reader
I2C interface for LCD display, etc...
Serial Interface over USB

So... On to Teacup_Firmware:

I've been conversing with the fine folk on the Teacup project"Traumflug", "drf5n", and "triffid" with regards to getting the firmware to compile on my Ubuntu Linux 14.10 desktop.

I copied his instructions verbatim..

Notice the "git co teensy3" ?   yeah... that "co" is alias for "checkout", and I checked out the teensy3 branch rather than the known-to-be-working teensy3.1 branch.

I spent a week, off and on trying to get that branch to compile and work on my Teensy3.1.   It compiled and uploaded fine, but I was not able to see the virtual serial port over USB (/dev/ttyACM0).

DAMN YOU PRIDE!

I'm already feeling stupid for taking so long to complete this project, I didn't want to admit that I was actually having troubles...

I finally sent a request yesterday to the Teacup_firmware issues log, indicating what I had done to this point and describing my inability to see the serial port.

I've also opened an issue on the Teensy forum to see if anyone can point me in the right direction.

Teacup_Firmware on Teensy 3.1 not initializing USB Serial

I've successfully compiled the latest Teensy 3.1 branch of Teacup_Firmware as per instructions on the Reprap wiki

I'm using Ubuntu Linux 14.10.

No more errors in compile using Paul's most recent teensyduino 1.21 I've associated it with Arduino IDE v1.0.6, but am actually compiling with Teacup_Firmware's Makefile using the ARM toolchain supplied with Teensyduino at the commandline.

As I said, It compiles fine, and the HEX file uploads to the Teensy, but I do not get /dev/ttyACM0 on Teensy reboot. If I replace the HEX with another sketch I compiled in the Arduino IDE (any thing) I get /dev/ttyACM0 to show up.

I know about the need to initialize the virtual serial over USB by sending a string out from the Teensy. I do not see this happening in Teacup_Firmware, however I know others have been able to compile and use it successfully on the Teensy. I'm at a loss as to where to start looking.

Any guidance would be appreciated.

Finally, I noticed my mistake.

Remember that "git co teensy3" ?

Today I backed up the branch I had been working on, and ran the proper "git co teensy3.1"

Using the proper Teensy3.1 branch of Teacup_Firmware, I started copying the correct files into place:

$ cp config.teensy3.h config.h
$ cp ThermistorTable.single.h ThermistorTable.h
$ cp Makefile-teensy3 Makefile

Then I modied the make file to point to the correct toolchain as provided by teensyduino, AS WELL AS THE POINTER TO THE CORE FILES. <-- This step is not documented as best as I can find. It's in the make file, but nowhere are you told empirically to modify it. Doh! <facepalm>

In the issue log, Dave (drf5n) also noticed that modification was required to allow the teensy3 branch to compile as below:

#if defined (_mk20dx128_h_) || defined ( __MK20DX128__ )

// Teensy 3.0 uses a MK20DX128 32 bit ARM Cortex-M4 48 MHz Test on this for config.h
    #include    "arduino_teensy3.h"
#endif

I had to also update the define for the teensy3.1 processor MK20DX256 as so:

#if defined (_mk20dx256_h_) || defined ( __MK20DX256__ )

 // Teensy 3.1 uses a MK20DX256 32 bit ARM Cortex-M4 48 MHz Test on this for config.h
    #include    "arduino_teensy3.h"
#endif

Low and behold...make clean && make && make project and I had a fairly clean compile. There were a few warnings that I was prepared for, but it compiled ... and uploaded... AND I had my /dev/ttyACM0 !!!

So at this point, I hurriedly launched Repetier Host, configured the printer port, and pressed "connect"... Mais voila!

It's a miracle!!! There is my teensy 3D printer controller, showing up in Repetier as Teacup! Yay!

Now, the real fun begins... bringing my Quadrature encoders over to Teacup, and modifying my PID loops to use Teacup's dda_clock().

Wish me luck!

My Previous blogs on this project:
(little did I know I'd be working on this on and off for a year... and the real work is just beginning)

http://www.nextdayreprap.co.uk/wiring-reprap-prusa-mendel-build-manual/

Every 3D printer I've seen
(please correct me if I've missed something!)
uses stepper motors for X/Y/Z axis.

The RepRap firmware assume that you are using steppers in your build.

That said, RepRap does introduce the concept of "RepStrap"

(from http://reprap.org/wiki/Category:RepStrap)

A repstrap is a 3D printer cobbled together from whatever parts you can find, which will eventually allow you to print the parts for a reprap machine, or to simply use as a stand alone machine. Derived from the term bootstrap, as in "to pull yourself up by your bootstraps"A RepStrap is a open-hardware rapid prototyping machine which is made by fabrication processes which aren't under the RepRap umbrella yet. These are becoming less and less common as RepRap printed parts become more available, but are still an option. You can build a 3D printer RepStrap using a tablesaw, orusing a lasercutter, and use this to make fun, beautiful, useful things.

Old commercial ink/laser printers used to use stepper motors too.

These printers typically got resolutions of 300dpi (0.08mm) or 600dpi (0.04mm)

But.... Newer printers, say within the last decade, use DC motors with a "linear strip encoder". And these printers typically get better than 1200dpi (0.02mm)

(yes, I know they use interpolation to get this resolution, but work with me here...)

According to WikiPedia: Optical linear encoders^[1]^[2] dominate the high resolution market and may employ shuttering/Moiré, diffraction or holographic principles. Typical incremental scale periods vary from hundreds down to sub-micrometre and following interpolation can provide resolutions as fine as a nanometre.

And...

Reprap already has a reference to these...

OverviewFor those who enjoy scavenging, many components useful for constructing 3D printers can be found in inkjet printers. This often includes optical encoders and strips. This page gives information on finding and using these items.
Finding printers with linear optical encoders in themCheap inkjet printers can be obtained from garage sales or recycling centers. Do not get laser printers, since they do not have the right optical components in them. Not all inkjet printers have optical encoders and strips in them. It is easy to tell by opening the lid (as if to change the ink). You should see a grey plastic strip close to the shiny metal rod and running parallel to it. The printers that people sell cheaply or recycle generally are somewhat inky inside. Do not get ink on the optical strip, though you may be able to clean it off.
The strip runs through the optical sensor, which may be quite hidden. It is probably on the back side of the assembly that holds the ink cartridges.

So...

I'm upping my game. My original goal was to simply copy a basic 3D printer using as much salvaged parts as I could, a few stepper motors, linear rails, switches, etc...

Had I done my research up front, I probably would not have even started this project, however... I have started, and am facing a new challenge...

My NEW GOAL is to create a 3D printer using DC motors and the salvaged Optical Encoder strips.

A simple test on the arduino with a pololu dual h-bridge quickly had two printer heads tracking back and forth on their carriages within minutes of wiring them up to their native cables. I haven't accounted for overrun yet, so they oscillate like crazy before getting to their destination, but this is DEFINITELY doable.

I will likely start with Marlin Firmware and write a hardware abstraction to convert stepper motor output (steps/inch, etc...) to run a closed loop DC motor with Encoder Strip feedback.

Any suggestions or prior art welcome!

Let's call these two videos ---

Inspiration....

References:

http://www.nextdayreprap.co.uk/wiring-reprap-prusa-mendel-build-manual/
http://en.wikipedia.org/wiki/Stepper_motor
http://reprap.org/wiki/Firmware
http://reprap.org/wiki/Category:RepStrap
http://benkrasnow.blogspot.ca/2010/02/linear-position-tracking-with.html
http://hackaday.com/2009/11/12/linear-optical-encoder/
http://reprap.org/wiki/Optical_encoders_01
http://www.electromate.com/db_support/downloads/lin.pdf
http://mil.ufl.edu/projects/gnuman/gnuman_pre2005/spec_sheets/heds_encoder.pdf
https://www.youtube.com/watch?v=0QLZCfqUeg4
http://makezine.com/2009/11/11/linear-optical-encoder-from-printer/
http://junkplusarduino.blogspot.ca/p/svg-image-plotter.html
http://madpenguin.ca/blog/2011/05/14/use-an-inkjet-printer-to-learn-emc2-and-servo-motor-control-part-1/
Arduino.cc: Agilent Optical encoder

So while I'm waiting for some assistance on my Teacup Firmware implementation, I thought I would poke around a bit in the Marlin fork that Paul Stoffregen started. (Also read here.)

Marlin looks like it is a bit more mature than Teacup. It has some of the same people working on it, but it supports LCD panel, as well as SD cards. Teacup was designed to be a minimalist firmware implementation to fit the constraints of many of the Arduino variants. It is written in pure C for the most part, and is better managed from the command line. Marlin is a bit larger, but not significantly so, and is written in C++.

I cloned it local, and it did "compile" clean, but didn't "do" anything. The USB serial interface did initialize, in that /dev/ttyACM0 showed up, but there was no communication.

A little bit of tinkering with MACROs, and I got the USB serial working. It is now successfully listening for and processing commands...

I've reached out to Nikki V from Freescale, to see if she has got any further in getting functionality working in Marlin.

In the meantime, I've also got the i2C_t3 Teensy variant of the Wire library installed and running the LiquidCrystal LCD library for my 20x4 LCD display.

Now I'm looking at the ADC code in Teacup and seeing how easy it might be to bring across... This is NOT my strength for sure..

Cheers.

References:

https://forum.pjrc.com/threads/26015-3D-Printer-Software-with-Teensy-3-1/page2

This is a VERY short post to describe how "I" connected permanently to the underside pins on my Teensy 3.1's

To get access to the extra pins on the bottom of the teensy, I used a dual row header, and bent the inside pins at a 90 degree angle, trimmed, and soldered. That's it. Easy peasy!

This shot shows the Real Time Clock crystal soldered into place.

There's some further discussion on the subject here...

There are also breakout boards designed to give you easy access to these pins...

(from Tindie)

I've had a few informative back and forth emails with Nikki V from Freescale regarding my failure to get connected to Repetier Host from the Marlin Firmware on my Teensy 3.1.

(Here's a link to Nikki's 3D printer blog: https://community.freescale.com/grou...on-rampsmarlin)

As mentioned in my previous article, I was finally able to compile and install the Marlin Firmware when I used the fork that Paul Stoffregen started, along with Nikki's Configuration.h and pins.h files. However, I could not connect to the firmware with Repetier.

Marlin was sending the appropriate communications out through the USB serial port, as evidenced by this screenshot:

But the Repetier connect request was not initializing Marlin, and returning the printer information.

Nikki pointed meback to the same thread on the Teensy Forum that I've already read 100 times...

Yeah... but I'm apparently blind or ignorant... or both...

She brought my attention to the fact that this issue has already been identified, and could be remediated by clicking a "fake OK" button from within the Manual control page.
I couldn't find the "Fake OK" button, so I read a little deeper.

And then Paul chimed in with a comment about compiling on Linux, and it all came together... Thank you Nikki, Thank you Paul.

Here's what Paul had to say that made all the difference:

I tried the Linux version. It also has only "OK", not "Fake OK", but it seems to work fine.
I had to edit the baud rate to 57600 in Configuration.h. The Linux driver doesn't seem to like 250000 (even though Teensy 3.1 complete ignores the baud rate).
Repetier-Host does seem to be getting hung up on something and requires the "OK" button clicked. I believe it's due to the missing temperature feature. The blue bar will stay stuck as "1 Command Waiting". Clicking "OK" gets it unstuck.

I set the baudrate in configuration.h to 57600, and recompiled and uploaded to the Teensy 3.1. I then launched Repetier, and went into the printer configuration, and selected 57600.

I applied, saved, and hit "Connect" .....

And Voila!

Marlin Firmware now connects, and provides printer information.

As of today, I have hard wired in 100k thermistors for Extruder and Bed heater temperature sensing, and set the pullup resistors for the endstops...

The Quadrature encoders are functioning on X and Y axis via the Flextimer module QuadDecode library, and *MY* PID routines (using the Arduino PID library) are successfully driving both X and Y axis DC motors from the manual controls in Repetier.

The Quadrature encoders are functioning on Z axis with Phase A/B hardware pin interrupts , and *MY* PID routines are successfully driving one Z axis DC motors from the manual controls in Repetier.

I have a functional I2C 20x4 LCD display, as well as SDcard reader.

As far as capacity on the Teensy, here is the size of code - all in - so far:

From the Arduino IDE:
Binary sketch size: 108,816 bytes (of a 262,144 byte maximum)
Estimated memory use: 14,080 bytes (of a 65,536 byte maximum)

Is it running... sure... is it printing... no... my budget hasn't allowed me the pleasure of a real extruder. I'm simply stepping a NEMA17 I had kicking around. I keep saying "next paycheck!"

TODO:

Acquire a real extruder/hotend (today I'm simply driving a NEMA17 that I had kicking around.) (anyone want to help?? LOL)
Wire up FET transistors to drive extruder and bed heater elements
Wire up endstops
Lots and lots and lots of PID tuning. Things have changed since porting/merging my DC motor code into the Marlin Firmware.
Take video this weekend and upload to Youtube! LOL
Remove MY PID routines, and create macro/wrapper to use existing Marlin PID routines meant for temperature management.
Put "conditional" code back in so I can merge this stuff back to github
Figure out how to merge stuff back to github
figure out whether 7. or 8. should come first...

Several months ago, while working on my Robotic shield for the Teensy 3.1, I had stumbled across this extremely rich and robust implementation of an ADC library, here on the Teensy forum.
(https://forum.pjrc.com/threads/25532-ADC-library-update-now-with-support-for-Teensy-3-1 ) Edit: updated as per author of library (15/04/06)

Written by a user of the Teensy, Pedro Villanueva started this library just over a year ago, but has implemented most, if not all, functions of the Teensy 3.1 including use of both ADC available in the Teensy 3.1, as well as differential readings on the two built-in differential channels (A10-A11 and A12-A13).

Along with this library, he has written a simple ring buffer implementation which will prove quite handy. There are also a number of very informative and well thought out examples.

List of methods of the library:
int ADC::analogRead ( uint8_t pin )

Returns the analog value of the pin.
It waits until the value is read and then returns the result. If a comparison has been set up and fails, it will return ADC_ERROR_VALUE.

int ADC::analogReadContinuous ( )

Reads the analog value of a continuous conversion.
Set the continuous conversion with with analogStartContinuous(pin) or startContinuousDifferential(pinP, pinN)
Returnsthe last converted value.

int ADC::analogReadDifferential ( uint8_t pinP, uint8_t pinN )

Reads the differential analog value of two pins (pinP - pinN).
It waits until the value is read and then returns the result. If a comparison has been set up and fails, it will return ADC_ERROR_DIFF_VALUE.

void ADC::disableCompare ( )

Disable the compare function.

void ADC::disableDMA ( )

Disable ADC DMA request.

void ADC::disableInterrupts ( )

Disable interrupts.

void ADC::enableCompare ( int16_t compValue, int greaterThan )

Enable the compare function to a single value.
A conversion will be completed only when the ADC value is >= compValue (greaterThan=1) or < compValue (greaterThan=0) Call it after changing the resolution Use with interrupts or poll conversion completion with isADC_Complete()

void ADC::enableCompareRange ( int16_t lowerLimit, int16_t upperLimit,
int insideRange, int inclusive )

Enable the compare function to a range.
A conversion will be completed only when the ADC value is inside (insideRange=1) or outside (=0) the range given by (lowerLimit, upperLimit),including (inclusive=1) the limits or not (inclusive=0). See Table 31-78, p. 617 of the freescale manual. Call it after changing the resolution Use with interrupts or poll conversion completion with isComplete()

void ADC::enableDMA ( )

Enable DMA request.
An ADC DMA request will be raised when the conversion is completed (including hardware averages and if the comparison (if any) is true).

void ADC::enableInterrupts ( )

Enable interrupts.
An IRQ_ADC0 Interrupt will be raised when the conversion is completed (including hardware averages and if the comparison (if any) is true).

double ADC::getMaxValue ( )

Returns the maximum value for a measurement, that is: 2^resolution.

int ADC::getResolution ( )

Returns the resolution of the ADC.

int ADC::isComplete ( )

Is an ADC conversion ready?
Returns 1 if yes, 0 if not. When a value is read this function returns 0 until a new value exists So it only makes sense to call it before analogRead(), analogReadContinuous() or analogReadDifferential()

int ADC::isConverting ( )

Is the ADC converting at the moment?
Returns 1 if yes, 0 if not

void ADC::setAveraging ( unsigned int num )

Set the number of averages.
Parameters
num can be 0, 4, 8, 16 or 32.

void ADC::setReference ( uint8_t type )

Set the voltage reference you prefer, default is vcc.
Parameters
type can be DEFAULT, EXTERNAL or INTERNAL

void ADC::setResolution ( unsigned int bits )

Change the resolution of the measurement.
Parameters
bits is the number of bits of resolution. For single-ended measurements: 8, 10, 12 or 16 bits. For differential measurements: 9, 11, 13 or 16 bits. If you want something in between (11 bits single-ended for example) select the inmediate higher and shift the result one to the right.

void ADC::startContinuous ( uint8_t pin )

Starts continuous conversion on the pin.
It returns as soon as the ADC is set, use analogReadContinuous() to read the value.

void ADC::startContinuousDifferential ( uint8_t pinP, uint8_t pinN )

Starts continuous conversion between the pins (pinP-pinN).
It returns as soon as the ADC is set, use analogReadContinuous() to read the value.

void ADC::stopContinuous ( )

Stops continuous conversion.

int ADC::startSingleRead(uint8_t pin)

Starts an analog measurement on the pin and enables interrupts. It returns inmediately, get value with readSingle(). If the pin is incorrect it returns ADC_ERROR_VALUE This function is interrupt safe. The ADC interrupt will restore the adc to its previous settings and restart the adc if it stopped a measurement. If you modify the adc_isr then this won't happen.

int ADC::startSingleDifferential(uint8_t pinP, uint8_t pinN)

Same as above but with differential measurements.

int ADC::readSingle()

Reads the analog value of a single conversion. Set the conversion with with startSingleRead(pin) or startSingleDifferential(pinP, pinN).

References:

Teensy Forum: User Pedvide
Github: Pedvide/ADC
https://forum.pjrc.com/threads/24399-quot-Complete-quot-implementation-of-Teensy-3-0-ADC-as-a-library
Freescale: K20 Sub-Family Reference Manual
Freescale: App Note - ADC measurements done properly
Freescale: Using DMA to Emulate ADC Flexible Scan Mode on Kinetis K Series
Freescale: App Note - AN2438/D 2/2003 ADC Definitions and Specifications

I've successfully replaced the Analog functions in Marlin's temperature.cpp, with calls to Pedro Villanueva's ADC library for the Teensy 3.1, and am getting good temperature readings out of it.

Here's a couple shots from Repetier Host.

Now on to updating the PID functions for the heaters...

This is looking quite doable my friends!

My Previous blogs on this project:
(little did I know I'd be working on this on and off for a year... and the real work is just beginning)

I ran across this awesome sitea couple weeks ago, and was astounded by their claims. I had to try it out!

In a nutshell, PlatformIO has automated the various build aspects of cross compiling for your favorite Microcontroller across Mac OS X, Windows, and Linux, both on Intel as well as ARM (Meaning you can run PlatformIO on your Raspberry PI, or Beagle Board!)

AND, they manage library dependencies for you!

Basically, you can write your embedded code once, and compile across several target boards with very little additional work.

PlatformIO for each Operating system includes compiler, debugger, uploader (for embedded) and a bunch of useful tools. Popular settings for most popular Embedded Platform Boards are pre-configured out of the box.

To date, PlatformIO out-of-the-box support includes:

Atmel AVR, 8bit MCUs as found on Arduino and a million clones.
Atmel SAM Smart ARM MCUs as found on the Arduino Due.
Esspressif Intelligent embedded Wifi for the Internet of Things.
Freescale Kinetis 32bit ARM MCUs in thousands of automotive and industrial products. Their FRDM series of platform development boards are
Arduino Shield Compatible.
Nordic nRF51 Series of embedded wireless (Bluetooth, etc..) communications boards.
NXP LPC, 32bit ARM MCUs also in automotive, industrial, commercial products. Their LPC Expresso development platform boards are Arduino Shield Compatible.
ST STM32, 32bit ARM MCUs. They can be found in the STM Discovery boards and the STM Nucleo development platform.
TI MSP430, 32bit ARM MCUs can be found in their Launchpad Development Platform boards.

And of Special Note, PlatformIO.org has worked with the guys that developed the Teensy 3.1 board to include it in their supported systems. I make note of this, as the Teensy does use the Freescale Kinetis K20dx256 32bit ARM cortex-4 MCU, but they have simply made this board more readily available to work with. (I also have a vested interest in this board!)

Once installed, you can get a list of the 60 or more supported boards by typing “platformio boards” ...

It's really as simple as installing PlatformIO onto your Laptop, Desktop, or Single board Computer (Raspberry Pi, BeagleBone, etc...), and choosing your target Embedded System to develop for.

You Install PlatformIO itself, then invoke it to install the toolsets and libraries for your preferred board/processor,
something akin to "platformio install freescalekinetis" and it pulls down all of the cross compiler tools, and kinetis core libraries.

You then initiate a project with "platformio init -bteensy31". It creates the directory structure, and you are free to use your favorite editor/IDE to write the code.

No... this is not Visual Studio / Programming-with-your-mouse tool, but it DOES take care of a lot of the planning, configuration, build, and upload issues for you.

Once you have written your code, again invoking PlatformIO to build and upload is a simple process.. "platformio run -t upload"...

PlatformIO Library Manager allows you to organize external libraries. Searching for new libraries can be via commandline or Web Interfaces. Python code in the background takes care of the rest. Think of this as a package manager for your embedded libraries.

My fellow Teensy developers... If you feel constrained by the limitations of the Arduino IDE (even though they did such an awesome job extending it with Teensyduino) And you are not up to the complexity of a full fledged bloated developer suite.. Please do yourself the favor, and try out PlatformIO.

References:

PlatformIO.org
Cross-board and cross-vendor embedded development with PlatformIO
Discovered a new tool for embedded development: PlatformIO
Integration of PlatformIO library manager to Arduino and Energia IDEs
Building and debugging Atmel AVR (Arduino-based) project using Eclipse IDE+PlatformIO

Very short post here:

I was cleaning the basement, and came across this. It is "brand new", as in everything was still wrapped in it's original bubble wrap and had the cardboard corner protectors... huh... go figure..

Anyway boys and girls... this is what an Arduino looked like 20+ years ago. LOL

130 rainy day electronics projects in one box...

I tend to be a very forgetful person, but I *vividly* remember MY first computer.

In 1976, Popular Electronics Magazine ran an article about building your very own personal computer.

The "Cosmac ELF" was basically a PCB that you purchased, sourcing all of the electronic parts through the mail. I think at the age of 10, it took me several months to get the components. Sending off for one of two as my allowance came in, and soldering them to the circuit board.

Picture from : http://www.homebrewcpu.com/projects.htm

Using an 8bit RCA 1802 processor meant for the newly invented digital gas pumps, the Cosmac Elf boasted 256 bytes (BYTES!) of memory, two 7 segment LEDs, 8 toggle switches for address and data input, a RUN switch, and a PROGRAM switch.

No BIOS or bootloader... nada... and yet some simple games could be loaded (in binary!) and played for hours of fun.

Two years later, I was up to 4k of memory, a cassette tape drive, and a monochrome video display of 128x64 bits... and a home rolled character generator!

Those were the days...

I'd LOVE to hear your stories in the comments below...

Dancing Brushbot assembly...

Arduino: User Error -- AIN0 IS NOT A0

Getting AVRDUDE working on Ubuntu with Pololu AVR ISP programmer and 3.3v ATtiny

Developing a Robot Shield for Teensy 3.1: Looking for feedback

Running Kinetis Design Studio (32bit Eclipse) on 64bit Ubuntu

Should I port SLAM to the Raspberry Pi's unused GPU on my Autonomous Rover?

Teensy 3.1 Repstrap printer with DC motor control and Flex Timer Quadrature Encoders

Prototype Board: DC motor/Encoder - Teensy 3.1 based 3D printer controller

Prototype Printer Controller Cont'd - Teensy 3.1 w/DC motor/encoders

Teensy 3.1 based Repstrap control board initial wiring completed - test #1

Repscrap: DC Motor Control for X-Y working - now to Teacup_Firmware

Success: Teacup_Firmware on Teensy3.1 and connected to Repetier Host!

Teacup_Firmware on Teensy 3.1 not initializing USB Serial

Using DC Motors and Encoders for 3D printer: Challenging the norm!

Marlin Firmware Compiled on Teensy 3.1 and ... well..

Connecting to those underside pins on the Teensy 3.1

Repetier successfully connected and functional with Marlin Firmware on Teensy 3.1

You have to see this Rich ADC library for Teensy 3.1 !!!

Marlin Firmware on Teensy 3.1 - Analog Temperature success!

PlatformIO - A Cross-Platform Code Builder and Missing Library Manager

How we learned about electronics pre-Arduino days...