Running Marlin Firmware on a Printrboard

As of this writing, the official version of Marlin firmware from github does not yet work with Printrboard.  Printrboard is a fork of Teensylu, designed by the folks at Printrbot. Printrboard isn’t yet available for purchase, but since the design is open source, anyone can download it and get the PCB’s manufactured themselves. Sprinter is currently the only RepRap firmware works with Teensylu and Printrboard out of the box.  I am now successfuly running Marlin on my Printrboard.  Below is a video of Printrboard virtually printing a Printrbot with Marlin:

Last month, I submitted an issue with ErikZalm to get the compile errors fixed when compiling Marlin for Teensylu.  The main branch of Marlin now compiles for Teensylu by setting MOTHERBOARD = 8.  Unfortunately, this build setting won’t work with Printrboard, because some of the pins are different.  Also, there is a kill function that Marlin calls if it detects certain things like a shorted thermistor, etc… but it’s not able to send the error messages back to the host, so it looks like your board is just dead.
I think Erik is too busy right now getting V1 out the door to deal with making fixes for a couple of not so popular boards, so I’ve forked Marlin on github with my fixes for making it behave nicely with Teensylu and Printrboard.  You can download it here:  lincomatic/Marlin.
For Firmware Hackers Only
For those who want to know what’s special about my branch of Marlin, it has to do with the mappings of the I/O pins.  The code in Marlin has two different ways to access digital I/O pins: 1) the Arduino digitalRead/Write() functions 2) fastio – there are macros and pin assignments in fastio.h.  In ErikZalm’s Marlin branch, the pin numbers are different between Arduino and fastio functions, which leads to confusion and bugs.  What I have done is use the digital pin definitions in Teensyduino’s core_pins.h and updated the pins in fastio.h to match them.  This way, a call to digitalRead(28) is equivalent to _READ(28).
  1. in pins.h, analog pins use ADC numbering instead of digital pin numbering.  Therefore, even though B_THERM -> F0/ADC0 and E_THERM -> F1/ADC1, we are using them as ADC pins, so B_THERM=0 (ADC0) and E_THERM=1 (ADC1).
  2. Printrboard uses some pins that aren’t supported by Teensyduino, since they aren’t exposed in the Teensy hardware.  Therefore, those pins aren’t listed in core_pins.h.  I have added them to fastio.h, so they are accessible only with fastio macros.  They are digital pins 46 and 47 see the “//– Begin not supported by Teensyduino
    ” section of fastio.h


XSTEP = physical pin 51. Looking at the AT90USB1286 spec sheet, pin 51 = PA0 (AD0)
in core_pins.h, #define PIN_A0 28
in fastio.h,

#define DIO28_PIN PINA0
#define DIO28_RPORT PINA
#define DIO28_PWM NULL
#define DIO28_DDR DDRA

so in pins.h, X_STEP = 28

X_MIN = AT90USB1286 pin 9 = PE3
core_pins.h doesn’t have a definition for PIN_E3, because the pin isn’t accessible in Teensy++, so we can’t talk to that pin at all with the Arduino functions.  However, it’s in fastio.h:

//– Begin not supported by Teensyduino
//– don’t use Arduino functions on these pins pinMode/digitalWrite/etc
#define DIO47_PIN PINE3
#define DIO47_RPORT PINE
#define DIO47_PWM NULL
#define DIO47_DDR DDRE

so X_MIN = 47

There are 85 Comments to "Running Marlin Firmware on a Printrboard"

  • John says:

    I have four Printrboards arriving this afternoon (1 for me, 3 shipping out).

    Sprinter compiles, but Marlin will not, even with with your revised pin configuration. It compiles fine if I set the board to “Arduino Mega 2560”, but errors out when set to Teenslu++ or Printrboard as you did here…

    Could you send me a copy of your files?

    • lincomatic says:

      I updated my posting above.. There were several more issues to get it functioning properly.
      I’ve forked Erik’s repository until he gets Printrboard support into his main branch.
      Download my fork for plug & play running:

      • John says:

        Thanks! Your fork compiled, but it’s stuck in an infinite loop complaining about an invalid temperature. Must be a configuration error.

        I’ll be updating the Printrboard Wiki as soon as I have everything running smoothly. Still haven’t had success directly uploading firmware from Arduino, but a USBTiny + avrdude works perfectly. Kind of a pain to manually grab the .hex files.

        • lincomatic says:

          That’s what tripped me up at first. If you don’t have a valid thermistor hooked up, it assumes your printer is going to melt down, and kills itself. But the kill code locked up the serial output before you could read it, so it just looked like the board was dead. I have a blog entry telling how to upload directly to Printrboard from within Arduino with USBtinyISP I’ve also figured out how to do it with bootloaders, but haven’t had time to write it up yet. It’s like 10x faster uploading the firmware with a bootloader, because the USB serial is so fast.

          • John says:

            Came back to the desk with success, but you’d already replied. Thanks! Yeah, just had to plug in the rest of the printer. All seems functional now!

            I use a batch file with a USBTinyISP which sets the fuses, loads the CDC bootloader, and then uploads the firmware. It takes about 8 seconds + 8 seconds to verify the upload. This is great for production, but not so great for tweaking settings directly from Arduino via the ‘Upload to Board’ method (no problem with Atmega644p). Have you figured out how to do this? When I try to use the [BootloaderCDC]/Teensylu/Printrboard configuration, Arduino always fails to compile. I have to compile using the “Teensy++ 2.0” board config, grab the temporary .hex file, and upload it using my USBTiny script…

  • lincomatic says:

    I think you mean it fails to upload, not fails to compile, correct? Arduino versions < 1.0 have an old version of avrdude that fails with the avr109 protocol... some sort of DTR not set error. Just get a new version of avrdude and drop it into your Arduino folder. Also, to get into the bootloader, you need to reset it while the HWB jumper is out.

  • John says:

    Arduino 022 gives a compile error upon clicking “Verify” if your [BootloaderCDC]Teensylu//Printrboard is the selected board. Attempting to verify/compile Marlin produces the following error: ‘Serial’ was not declared in this scope.

    With Sprinter, the error changes to: ‘HIGH’ was not declared in this scope.

    Both firmwares compile fine with the “Teensy++ 2.0″ board selected. Seems like my copy of Arduino is missing something.

    • lincomatic says:

      That’s very strange. You’re using my boards.txt from and it’s in the hardware/teensy directory?

    • PxT says:


      I hit the same (or similar) problem. Not sure if you were able to resolve this yet, but if not, I got around it by:

      * Doing the steps here:
      * Downloading the copy of Arduino 0022 from here:
      * Unzip the above then copy hardware/at90usb1286/cores/at90usb1286/ directory within it to your ARDUINODIR/hardware/teensy/cores/ directory
      * Launch Arduino and it should compile correctly with the Teensylu/Printrboard selected.

      If not then you can go into Arduino’s preferences and turn on verbose compilation which should give you some more hints about exactly what is going wrong.


      • lincomatic says:

        PxT, thanks for providing the step by step. The linked copy of Arduino 0022 that you provided above is actually what I provided to John!

      • John says:

        @ PxT: Yes, that’s our site. I wrote the wiki article for Printrboard based on Lincomatic’s help. Printrbot decided to use our picture…

      • doctek says:

        If you download the reprap version of Arduino 0022, you don’t need to do the steps in the blog as in step 1. That part is already done. The necessary files are in the AT90USBZ1286 directory and the Teensylu/Printrboard configuration is available. You don’t need to move any files either. Just unzip the Arduino 0022 from RepRap and start Arduino.

      • Matt Gingras says:


        Thank you for providing your valuable information here on your blog, you have helped me to get pretty far, however I’m in need of help.

        I have CDC, PrintrBoard, and have successfully compiled, uploaded, and verified marlin firmware as described in this blog. However I was only able to connect to the PrintrBoard ONCE using Pronterface (printrun)….I was able to move my machine for the first time on all axis, and was toying with setups. However I disconnected from the PrintrBoard (went to lunch) and have not been able to connect back to it ever since, even with the same setup, and even with redoing all my reloading steps again, many times. =\

        I’m using windows 7, arduino 0022 for uploading/compiling marlin (using directions on this blog entry), and have rebooted win7 and printrboard multiple times thinking the comm port was being a jerk in windows….but no luck….I’ve also tried realterm, and connecting to the printrboard, with the boot jumper installed, and it’s almost like the firmware isn’t running, it’s not taking input…..I don’t know what to do, any suggestions would be greatly appreciated and probably very helpful.

        thank you,

        —Matt G

        • lincomatic says:

          1) Although some other users have not reported the same behavior, on my Win7 x64 machine, if I have any program running which has the Printrboard’s serial port open, it will not properly detect the serial port. Make sure there are no programs running with the comm port open.
          2) Make sure the jumper next to the MCU on the Printrboard is installed and shorting its 2 pins.
          3) press and release the reset button on the Printrboard
          4) Use the Arduino UI Tools->Serial menu to make sure you’re trying to open the correct comm port.

          • Matt Gingras says:

            Sorry for the delay of getting back,

            ….but I figured out the problem….This problem only occurs when the Y-endstop is engaged. And the reason I was only able to connect to it once that day was the first move was to “home” engaging all endstops. Now all I do before I connect is slide the bed to disengage the endstop. I have not investigated further as to why the microcontroller doesn’t like that start condition…annoying problem, yes, but whatever….still cool. =)

            I’m now onto a new problem where I lose communication between printrboard and pronterface during a print…..this is highly annoying……

            I’m investigating USB cable, power supply, and the schematic to printrboard.

            One thing I noticed, (observation, I’m NOT saying this IS the problem) when I have the USB pluged in and the external ATX power supply plugged into printrboard and NOT on the fan on the ATX supply spins, slow, but it’s powered. I then noticed on the printrboard schematic, and by probing with a scope there’s a switching regulator (U1) which is allowing bleed current from the USB to backfeed into the 12v rail, thus powering the fan on my atx (which the fan is directly internally soldered to the 12v rail on the ATX). This made me realise there’s no diode to protect that power bleed to happen and it occured to me this may be a problem in disguise; since two power supplies both source 5volts (one usb from computer, one atx supplied through (U1) on printrboard) are not using auctioneer diodes and could be potentially fighting each other (one sources the other does not, or they switch off when one can’t source enough) which MAY be why communications randomly drop out due to small power transients during print operations (I’m currently scoping this to investigate). The diodes will also take care of that bleed back “problem” on the 12v rail.

            Just thought I’d share in case someone else is having similar troubles or has a solution.


            —Matt G

            P.S. I have REV C of PrintrBoard, running Marlin FW, on CDC boot, controlled by Pronterface (printrun)

          • lincomatic says:

            I am not currently using endstops, but I haven’t heard of anyone else having your lockup issue.
            Are you sure you have the correct values for Y_ENDSTOPS_INVERTING, Y_HOME_DIR, etc?

            I have been using Pronterface with my Printrboard RevC for hours at a time, and the communications have been rock solid.
            Do you have a load on the 5V rail of your ATX supply? Many ATX supplies don’t provide stable output unless you have an appropriate load on the 5V (sorry, I don’t remember how much current you need to draw … I use an old hard drive).

            When the ATX supply is powered, the current should not flow back up the 12V rail, since it’s a higher voltage than the USB. Are you sure your 12V rail can source enough current to power your heaters + motors simultaneously?

      • Paul says:

        I got a dumb question… i hit the same problem and im struggling to understand why exactly it is (im in linux 64bit) that the teensy installer doesnt end with an arduino that contains that at90usb1286 directory.

        I’ve tried installing the teensy installer on both 0022 and 1.0 arduino ide’s and both end the same way, how did they get that dir on the arduino-0022 on the reprap-usa site? was there a component i missed in the steps somewhere?

        • lincomatic says:

          If you run teensyduino’s installer, you will end up with a subdirectory called teensy instead. I renamed the directory to at90usb1286. I gave them my setup to play with, not realizing that they would post it for download. What you said “i hit the same problem and im struggling to understand..” which problem are you referring to?

          • Paul says:

            Back at the top of this thread where john is talking about “Attempting to verify/compile Marlin produces the following error: ‘Serial’ was not declared in this scope.”

            There appears to be a number of differences between …./hardware/teensy/cores/teensy and …/hardware/teensy/cores/at90usb1286 though (though i was only quickly looking thru a recursive diff of the two directories). tbh, i was just really curious where that at90usb1286 directory came from originally, ty for the answer 🙂

          • lincomatic says:

            BTW, you can’t just copy the teensy or at90usb1286 directory… you also need to run teensyduino’s installer … it modifies some of the java files in Arduino directly.

  • John says:

    Yeah, is there any way I could grab a copy of your Arduino directory? Email me and I can give you an FTP account.

    Really appreciate your help with this!

  • John says:

    @Matt Gingras: Lincomatic pointed me to your post. Our shop produced the only batch of Printrboard RevC’s in existence at this time.

    First, the 5V USB supply and 5V switching supply should have been isolated in this batch. There was an SMT solder jumper on RevB, but we bridged all jumpers on RevC because they couldn’t be machine manufactured (every RevB board required manual touch up work). The bridged 5V supplies shouldn’t affect reliability, and indeed have not had an impact, as far as I know. If you want to eliminate the possibility, you can slice the trace coming from the USB 5V pin.

    Onto your Y-endstop issue: I can’t reproduce that here. Our boards connect regardless of any endstop position, including Y. Our main Printrboard RevC prints for 8-10 hours a day and has never lost a connection or had a failed print due (besides mechanical/plastic flaws of course). Printrboard uptime is measured in days on that machine…it’s only disconnected when we have to reboot the PC.

    So, either you’ve found a faulty board, or there’s a wiring issue with your Y-enstop. I’ve seen this happen on Gen6 and Sanguinololu boards. Incorrect wiring can short the microcontroller to 5V or GND. When the endstop is tripped, the electronics lose power.

    Try swapping the Y-endstop with another axis. If the problem persists, contact your supplier for an exchange. Printrboard should be 100% reliable.

  • Travis says:

    I can confirm the Y-endstop issue. Connection to printrboard will hang unless the Y-endstop is engaged beforehand.

  • Alex says:

    I’ve gotten almost everything to run i’ve compiled the firmware loaded it onto a printrboard but when i go to connect with pronterface, the printer never comes online? I’ve tried several different Marlin configurations? Any ideas where i should look?

    • lincomatic says:

      After loading the firmware, did you put the boot jumper back in (shorting the 2 pins) and reset the board?
      If you don’t put the jumper back in, the board stays in bootloader mode.
      Try opening the serial port with Arduino’s serial monitor, and typing some gcode into it (e.g. G0 X0 Y0 Z0).
      Does it respond?

      • Alex says:

        Yeah, I’ve reset the board. I’m loading the firmware using FLIP and that seems to work everytime. I’ve tried a few different versions of Marlin but no luck. It doesn’t respond when i type G-code into the arduino serial monitor. Though i know it is out of bootloader mode since it’s detecting the COM port and not the atmel chip, Any other suggestions. Thanks for the help

        • lincomatic says:

          Try stripping it down the the basics first.. run a simple serial echo sketch and see if that works.

  • Alex says:

    Got it. The endstops were causing the problem… I am using endstops hopefully some adjustments to the firmware will fix it.

    • lincomatic says:

      So enabling the x-endstop made the serial comms die?
      I don’t have endstops enabled in mine yet, but several people are having problems.. I’ll try to get to it later this week.

  • Alex says:

    I’m trying to get the endstops to work below is relevant part of configuration.h

    //=============================Mechanical Settings===========================

    // Endstop Settings
    #define ENDSTOPPULLUPS // Comment this out (using // at the start of the line) to disable the endstop pullup resistors

    // The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins.
    const bool X_ENDSTOPS_INVERTING = false; // set to true to invert the logic of the endstops. // PREVIOUS false
    const bool Y_ENDSTOPS_INVERTING = false; // set to true to invert the logic of the endstops. //PREVIOUS false
    const bool Z_ENDSTOPS_INVERTING = false; // set to true to invert the logic of the endstops. //PREVIOUS false
    //#define DISABLE_MAX_ENDSTOPS // Not commented out previously

    // For Inverting Stepper Enable Pins (Active Low) use 0, Non Inverting (Active High) use 1
    #define X_ENABLE_ON 0
    #define Y_ENABLE_ON 0
    #define Z_ENABLE_ON 0
    #define E_ENABLE_ON 0 // For all extruders

    // Disables axis when it’s not being used.
    #define DISABLE_X false
    #define DISABLE_Y false
    #define DISABLE_Z false
    #define DISABLE_E false // For all extruders

    #define INVERT_X_DIR true // for Mendel set to false, for Orca set to true
    #define INVERT_Y_DIR false // for Mendel set to true, for Orca set to false
    #define INVERT_Z_DIR true // for Mendel set to false, for Orca set to true
    #define INVERT_E0_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
    #define INVERT_E1_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
    #define INVERT_E2_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false

    // Sets direction of endstops when homing; 1=MAX, -1=MIN
    #define X_HOME_DIR 1 // PREVIOUS -1
    #define Y_HOME_DIR -1
    #define Z_HOME_DIR -1

    Does anyone have any ideas?

  • Alex says:

    The y and z endstops are working, though the x is not.

  • Alex says:

    I adjusted the pins.h my limit switch was on the +ve side not negative side, after that everything worked.

  • Paul says:

    Just out of curiosity, has anyone had any success uploading a firmware from linux via the cnc bootloader? i’ve tried with ubuntu 10.10-12.04 and fedora and they all do the same thing. I pull the jumper, hit reset, i get a new serial port (but it also comes up on ttyACM0) but that serial port is incapable of any communication (I/O errors when anything tries to talk to it) and i get messages like this in dmesg:

    tty_port_close_start: tty->count = 1 port count = 0.

    From windows it’ll work no problems, but just cant get linux to talk properly to it, is there something i’ve missed possibly?

  • Tony says:

    i just got delivery of a printrboard for testing and wondered where the pin definitions for the AT90usb1286 for arduino are? I looked in the obvious place core_pins.h in the at90usb1286/cores/at90usb1286 directory but that appears to be missing a definition for the X_MIN_PIN which is pin number 47 where are the defines in core_pins.h only go up to 45.

    Also confusingly the D and E port pin numbers appear different in the core_pins.h to the numbers that are used within marlins pins.h for example physical pin 60 which from the schematics here and here is port F1. F1 is assigned to number 39 within core_pins.h but number 1 within pins.h (number 1 within core_pins.h is assigned to D1). This mismatch only applies to ports D and F, all the other pin numbers match.

    Any ideas what is going on?

    • lincomatic says:

      the reason you can’t find pin 47 in the core_pins.h is because the Teensy doesn’t expose that pin, and the files are from the Teensyduino distro. The files in at90usb1286 are actually just renamed from the files you get when you install Teensyduino. I just renamed the teensy folder to at90usb1286. Originally, my plan was to make an Arduino distro that would support all of the I/O pins of the AT90USB1286, but then I found out that the Teensyduino installer is making some changes to the Java files, so you can’t just copy my at90usb1286 folder… you have to install Teensyduino, delete the teensy folder, and then replace it with my at90usb1286 folder… too messy, but that’s in the copy of Arduino-0022 that you got from John Seaber (I wasn’t expecting him to post it for download).

      OK, it took me a while to remember what’s going on with Pin 60. The B_THERM/E_THERM pins are being used as ANALOG pins… ADC0/ADC1, not as digital F0/F1.
      That’s why they’re assigned as 0 and 1.

      I’ve updated the article above with a detailed explanation of the mappings.

      • Tony says:

        Thanks for the detailed explanation. I have been through all the pins on the printrboard expansion header toggling them using the code below (LED connected to each pin in turn):

        void setup() {

        void loop() {
        int incomingByte1,incomingByte2;
        int pin;
        if (Serial.available() > 0)
        incomingByte1 =;
        incomingByte2 =;
        pin = ((incomingByte2- ‘0’)+(incomingByte1-‘0’)*10);
        Serial.print(“pin toggled: “);
        pinMode(pin, OUTPUT);
        if (digitalRead(pin) == HIGH) {
        digitalWrite(pin, LOW);
        } else {
        digitalWrite(pin, HIGH);

        I realise that for PE2 and PE3 this code wont work (I found the issue you raised about fastio/arduino incompatibility on the marlin issue tracker). All the other pins work fine with digitalwrite() other than PF4,PF5,PF6,PF7 (42,43,44,45) which are the JTAG interface pins. Changing the high fuse setting to “DB” (-U hfuse:w:0xdb:m) to disable the JTAG interface gave me access to these pins on the expansion header.

        I think it would be better to have the JTAG interface disabled by “default” as most people will probably want to use the expansion header pins as I/O.

        • lincomatic says:

          Thanks for testing. I’d like to add the missing pins to Teensyduino and make a distro that doesn’t rely on PJRC’s installer, but I need to figure out what it’s editing in the core Arduino java files. That would be the ideal scenario for Printrboard and other generic AT90USB128x projects.

          I agree with you that turning off JTAG is a good idea. More I/O’s are probably more useful for most people.

  • Tony says:

    Than ks agin for your work and help, allowed me to get the Panelolu up and running on a Printrboard, see my blog entry:

  • Alex says:

    I’ve gotten Marlin working with my printrboard. Thanks very much lincomatic. I’m having one odd issus connecting to the board with USB. Sometimes i need to unplug everything including USB and power and then replug it in to get pronterface to detect the printer. The com port comes up just fine in windows

    • lincomatic says:

      The only similar problem I have is if the port is open (e.g. in pronterface), and then I physically disconnect or reset the printer without first disconnecting it in software first, the computer won’t detect the port.

  • Alex says:

    I can confirm the Y Endstop issue, Does anyone have a fix or understand why that might be an issue?

    • lincomatic says:

      What kind of endstop are you using? Switch? normally open or closed?
      I’ll test

      • RustyPaint says:

        Same issue here. Using mechanical endstops that are normally closed. All 3 must be engaged (open) for the board to boot in Marlin. The board will boot into the boot loader no problem (with boot jumper pulled).

        Also, if the SD card is read while the endstop switches are closed, it will lock up the micro. I can read from the card while everything is homed, but it will die in the middle of the print when it goes to fill the gcode ring buffer. Same thing (the lock up) if I try to pull up the file list on the SD card if not everything is in the home position.

        • RustyPaint says:

          Ok… tried an experiment. I put my y-stop switch on the e-stop header and changed my pins.h from:
          #define Y_MIN_PIN 20
          #define Y_MIN_PIN 37

          My start up problem is gone and I can read the SD card now without having everything homed. Trying a print now to see if it works.

          Looking at the Schematic:

          The y-stop is on the same pad as the SD card reader. Maybe the SD card library doesn’t like sharing the same pad with the y-stop?

          • mkeveney says:

            When I first read this, I thought you were doing some kind of exotic debugging with the extra breakout pins. I didn’t register that the ‘e-stop header’ you mention is simply the extra plug right next to the z-stop plug.

            Since this is unused anyway, your ‘experiment’ is in fact a perfectly reasonable workaround. …just thought I’d clarify, in case anyone else missed this. I’ve just set mine up this way, and it’s working great.

            I did have to change the the nn_ENDSTOPS_INVERTING values false. I wired my endstop switches as instructed here:

            Thanks for a great tip.

  • Jared says:

    I came across the Y endstop issue too.

    At first I noticed the AVR chip was getting hot with the default firmware, turns out the Y endstop was not being configured properly. X/Z measured 30kohm to VCC, but Y measured 0ohm. I think we fixed it by uploading a different firmware.

    However I still get a connection problem. After resetting I have to unplug the Y endstop pin so it goes logic high (endstop pulls it low), or it will not boot at all. I even tried adding a resistor inline in case it was being overloaded, but nope, same problem. Looks like a firmware issue.

    • lincomatic says:

      I just double checked to make sure that Y_MIN_PIN = 20 is correct. From the schematic, it’s PB0, so it’s correct.
      Sorry, still too busy too debug this.. I will try to figure it out and fix the problem as soon as I can find the time.

  • Fede Heinz says:

    I’m trying to compile your branch, but when I set the board type to Teensy++ 2.0, the compiler complains:

    In file included from temperature.cpp:32:0:
    Marlin.h:32:25: fatal error: Arduino.h: No such file or directory
    compilation terminated.

    Any ideas?

    • lincomatic says:

      Something’s wrong with your Teensyduino setup. Try reinstalling it.

      • Fede Heinz says:

        Indeed, a reinstall of teensyduino fixed that (which was odd, because I could compile other teensy stuff). Anyway, now I get:

        collect2: error: ld terminated with signal 11 [Segmentation fault]

        Looks like my setup is quite badly hosed 🙁

        • lincomatic says:

          If you want to save yourself from some hassle, just download my whole Arduino-0022 setup for compiling Marlin for Printrboard at

          • Fede Heinz says:

            Sounds like good advice… only that seems to be for Windows, and no use for me under Debian GNU/Linux 🙁

          • Fede Heinz says:

            Installing binutils-avr 2.22 fixed the problem. It’s not in Debian yet, but I found a deb that worked in Ubuntu’s Launchpad.

            Now I’m back to square one, unfortunately: I can compile Marlin OK if I select board “Teensy++ 2.0”. However, if I select “[usbtinyisp]Teensylu/Printrboard”, I’m back at the “Arduino.h: No such file or directory” problem. WTF?

          • Fede Heinz says:

            I must be doing something fundamentally wrong.

            I guessed my problem was that I was running Debian’s arduino 1.0.1 instead of 0022, so I installed 0022 and redid the whole teensyduino/ dance once again… I still can’t compile.

            The scoreboard is as follows:

            Arduino 1.0.1, Board Teensy++ 2.0: compiles, doesn’t upload (no surprise, actually).

            Arduino 1.0.1, [usbtinyisp|BootloaderCDC]Teensylu/Printrboard: compilation fails with:

            In file included from temperature.cpp:32:0:
            Marlin.h:32:25: fatal error: Arduino.h: No such file or directory
            compilation terminated.

            Arduino 0022, Board Teensy++ 2.0: compilation fails with:

            In file included from cardreader.h:6:0,
            from cardreader.cpp:2:
            SdFile.h: In copy constructor ‘constexpr SdFile::SdFile(const SdFile&)’:
            SdFile.h:36:7: internal compiler error: Segmentation fault
            Please submit a full bug report,
            with preprocessed source if appropriate.
            See for instructions.

            Arduino 1.0.1, [usbtinyisp|BootloaderCDC]Teensylu/Printrboard: compilation fails with:

            In file included from temperature.cpp:32:0:
            Marlin.h:35:25: fatal error: WProgram.h: No such file or directory
            compilation terminated.

            I have been doing some Teensy projects before, and I can still compile those fine, both on 1.0.1 and 0022, but Marlin just won’t.

            The question is, of course, what is the Very Stupid Thing(TM) I’m overlooking?

          • lincomatic says:

            Segmentation fault in the compiler? Ouch. That’s not a configuration error, that’s the compiler itself.
            The last one is very puzzling.. it should be looking for Arduino.h instead of WProgram.h if the version is >1.0.0

          • Fede Heinz says:

            No, the version that throws that error is 0022.

    • Francis says:

      Ok. I just struggled with this and got it to compile and it SAYS that it uploaded… whether or not it did, I’ll see when I try to connect with RepetierHost.

      I had the same issue as you… I got the Teensy2.0++ to compile Marlin, but it wouldn’t upload because I didn’t have the “reset” button it was looking for (Also it stopped looking for ttyACM0 and only gave me ttyS0). Switching to “[BootloaderCDC]Teensylu/Printrboard” would point at ttyACM0, but it wouldn’t compile because of missing definitions and header files. So I compared the two configurations and found the following…

      On your boards.txt in your “teensy” directory, the specified core is wrong. The line:

      should say:

      That way when it’s compiling, it will build off of the “teensy” subdirectory for the header files. There is [probably] no subdirectory in your install that is named, “at90usb1286”

      I hope this works!!!

      (And as per normal unspoken forum rules, I will probably forget to post here my results when I get distracted printing toys out of my RepRap.)

  • […] I had some trouble using the PrintrBoard’s built in SD card reader using Marlin firmware.  I also had an issue with the Y-endstop, which I thought was unrelated, as the board would not boot if the Y-endstop was press (ie. if the bed was homed). The only help I found was from Lincomatic’s blog again but this time in a comment from “RustyPaint”, found here. […]

  • mkeveney says:

    I’ve successfully installed your fork to my Printrboard, but I’m having occasional problems with a ‘skewed’ axis. Usually the layers are shifted along the Y axis to produce a slant, about 45 degrees; sometimes the X axis. I’ve verified that the GCode is okay. When it happens, the error is far too regular to be blamed on an intermittent hardware error… I suspect firmware; maybe a rounding error somewhere.

    I found a few vague references to the problem in relation to Marlin, so I’m trying to update your firmware to the latest Marlin code. I simply rebased your commits (except for the version merge) onto ErikZalm’s latest Marlin branch. It compiles & loads fine; my host software connects,but displays no Marlin sign on/version info; and then nothing. It seems that the host is stalled trying to deliver its initialization sequence.

    It’s not the thermistor thing you mention above. The sensor is connected and works fine with your fork.

    I’m an experienced programmer, but new to firmware. How do I diagnose this? Is it possible to somehow insert some logging code? …dare I hope for a debugger? Please point me to the right resource.


    • mkeveney says:

      Well, it has turned out to be a hardware issue after all… though I’m amazed that a slipping pulley could produce such a precise artifact. The G-Code must have had exactly the same number of abrupt moves per layer, and the pulley friction must have been very consistent… Anyway, the immediate problem is solved.

      But I’d still like to know how to troubleshoot that firmware!


  • I’m trying to get Printrboard support into Marlin upstream. I was hoping to make it work without changing fastio.h to match Teensyduino’s incomplete pin mapping (e.g. PE3 missing which is X-STOP on Printrboard). I’d love to get some advice on my pull request:

    • lincomatic says:

      Thanks for getting the Marlin team to take notice. I submitted a pull request at the same time that I submitted one to the Sprinter team, and the Marlin team completely blew me off, while the Sprinter team immediately applied my changes. Personally, I would prefer to make a new AT90USBxxx version of Arduino, which seems easy at first, but the problem is that in order to get the correct parameters to AVRdude to work with a CDC bootloader, Teensyduino’s installer edits the Arduino Java files. Therefore, someone would have to write a new installer (or do a messy install procedure: 1) install Teensyduino 2) drop in the files for the new distro). The easiest approach would be to do what Sprinter does, which is use fastio exclusively, and not have to worry about digitalread/write, but it appears that they’re not willing to do that.

  • kalpesh says:

    Hey there
    I have rapidboard 3.0 implemented. unfortunately problem is regarding printrboard Rep. sometimes + Y axis works then -Y axis not works. +X axis works then -X notworks properly..
    What to do in this situation plz tell me anyone…..

  • kalpesh\ says:

    Well might be…

    Here is another problem after successfully uploading bootloader using USBtinyISP loader computer cann’t detect Port on which printrboard is attached. Also Many times unplugging the printrboard. But getting failure every time.. This happens in many printrboard..
    For this problem any solution???

  • kumadon says:

    Hi all,

    I have some problem with Printrboard(rev D), that is, Printrboard with X-endstop can’t connect to Pronterface, but without X-endstop it can connect to Pronterface.

    Does not someone have an idea about what causes this problem?

  • kumadon says:

    Thank you for replying to my post.

    Sorry that my description about the problem was not accurate. It’s accurately like the following,
    ‘With X-endstop Pronterface shows only “Connecting…”, but I think it might be connecting to 3D printer because of no error message in the pronterface.exe.log even after hitting ‘Reset’, so maybe the problem is that 3D printer doesn’t respond, I think. Of course I don’t know why.
    And with X-endstop ‘SD’ on Pronterface isn’t highlighted,but without X-endstop ‘SD’ on Pronterface is highlighted and when I hit ‘SD’ on Pronterface, Pronterface shows
    ok T:10.64 B:3.00 @:0
    Printer is now online.
    echo:SD init fail
    workDir open failed
    Begin file list
    End file list”
    To tell the truth, I don’t know whether the messages show something wrong happens or not.

    • lincomatic says:

      I don’t use endstops, so I can’t comment directly, but I’ve heard that there’s a conflict between endstops and the SD card reader, which is why I was wondering if it works OK w/ the SD disabled when endstops are turned on. Are you using a <= 2GB SD card? It won't work with bigger ones. Only SD... SDHC is not supported

  • kumadon says:

    I don’t use any SD card.
    Now I’m testing the movement of motors and so on, just after assembled my 3D printer.
    So I haven’t printed one piece yet.

    I would like you to tell me how you print without using endstops. Thank you.

    • lincomatic says:

      I just manually position the printer to the place where I want (0,0,0) using Pronterface, and then send G92 X0 Y0 Z0 to set the origin.

      • kumadon says:

        Thank you for teaching me how to use the printer without endstops.

        Y and Z endstops work now, so I decided to print without X-endstop, instead of changing the firmware of Printrboard.

        It might be wrong English, but I want to say “There is nothing to have to be.”
        I think pliability is best at any time.

        Thank you so much.

  • kumadon says:

    I’m planning to change the firmware of Printrboard from Marlin to Repetier.
    If I change it like above, can I resolve the problem of X-endstop?

  • RAmy says:

    differences bet. sprinter and Marlin and which is the best ??

    • lincomatic says:

      I can’t really say which one is better. I played with both, and decided to go with Marlin. Sprinter has much tighter, cleaner code, but I wanted some of the functionality in Marlin.

  • Sally Tortellinie says:

    Wow! A lot of good information here! I’ve read everything here three times and am nearly out of the woods. But I just can’t make sense of something.

    I have a PrintrBoard (Rev. D) and want to use the extra I/O pins on the expansion headers. I have the Marlin firmware compiled and running on the PrintrBoard. I have parts on order to implement the Automatic Bed Leveling.

    The problem is even with all the information here I can’t make sense out of the Pin definitions. I ended up adding an M command modeled after M42 to scan all the pins and pulse them so I can watch the results with a volt meter. The new M command prints out which Pin it is on, and if it is not a ‘Sensitive’ Pin, it uses pinMode() to set it to an output, then does a digitalWrite(Pin,LOW). Then after a delay(1000) it does a digitalWrite(Pin,HIGH) and does another delay(1000). Then, just to make sure I’m not driving something that should not be, pinMode() is called again to set that pin to be an input and the code moves on to the next pin.

    Here is the problem: The Expansion Port Pins that I have found do not make sense at all. So far I have not been able to find and use any of the Port-D pins. This may be because JTAG is enabled on my board. This issue aside, moving my probe from pin to pin and running the scan code, the schematic is claiming PE0 is Pin 8. PE1 is Pin 9. PC0 is Pin 10. PC1 is Pin 11. PC2 is Pin 12. Looking at Pins.h and Fastio.h does not confirm this information. In Fastio.h Pin 8 is PB0, Pin 9 is PB1, Pin 10 is PB2, Pin 11 is PB3 and Pin 12 is PB4.

    And it gets even more confusing! Looking at how things like X_STOP_PIN or Z_STEP_PIN are defined, everything seems correct. For example, the schematic shows X_STOP_PIN on PE3 and Fastio.h has that defined as Pin 35 which is what it is set to in Pins.h Similarly, for Z_STEP_PIN the schematic shows that connected to PA4 with Fastio.h claiming that is on Pin4 and Pins.h defining it to be 4.

    Are the Fastio.h definations wrong for the expansion headers??? What don’t I understand? And one more question, can I disable JTAG without an ISP by using the Arduino library : Fuse Support ? It pretty much looks like that will generate the required fuse settings but I don’t want to brick my PrintrBoard!

    Thanks so much for all the good information here!!!!!!

    • lincomatic says:

      Yes, the Marlin code is a mess. I tried to get the devs to integrate my fastio changes, but they ignored me. That was a while ago. Some other guys finally got native Printrboard support into the mainline code, but I haven’t looked at it, and don’t know if they accepted my changes or not. My changes were specifically to make fastio and and the Teensyduino Arduino functions use the same pin numbers, because they were using different numbers, which made it so that you had to use different pin numbers depending on whether you were using fastio or the Arduino functions.

      OK, I just looked at ErikZalm’s Marlin code on github. He still has X_STOP = 35, which in fastio.h maps to PE3 as it should. But the problem is, if you look in Teensyduino’s core_pins.h, pin 35 maps to PA7, and there’s no pin number assigned to PE3. So what does this mean? You’re OK if you use fastio on pin 35. But if you use digitalWrite(), pin 35 will talk to PA7. And digitalWrite() can’t even talk to PE3. My fastio.h at least maps pin 35 to PA7, so both digitalRead/Write() talk to the same pin 35.

      Can you send me a link to the schematic you’re looking at? Why are you trying to get pin numbers from the schematic? The schematic uses physical pin numbers, not logical pin numbers as used by the software functions.

      Tell me which pins you’re trying to access, and I’ll see if I can get you the pin numbers to use w/ fastio.

      I’m not familiar w/ the Fuse Support library. I recommend that you get an ISP if you want to mess around w/ fuses. And be careful. If you mess up the clock bits, you could brick the board. I did that to mine, but luckily, was able to use a signal generator on an external clock pin and fix the fuses.

      • Sally Tortellinie says:

        This is a little bit out of order from your reply, but the PrintrBoard schematic I’m using is at:

        It seems only Revision B is available. But elsewhere it claims that up until Revision F the expansion headers are pretty much the same between the versions. ( )

        I am not trying to get Pin #’s from the schematic. (Actually, I did go down this path until I found your blog that explained the pin numbers are all virtual and arbitrary! THANKS SO MUCH!) What I’m doing with the schematic is seeing what Data I/O port and bit is on a given expansion port pin. And that seems totally messed up.

        What I would like to do is have access to PD4, PD5, PD6 and PD7 which are all on the second expansion header. (One more nit-pick! The second expansion header seems to be numbered as if the header is soldered on the bottom of the board, and not on the same side as all the parts and the first expansion header. This just causes confusion! )

        As for the Fuse Library… Please take a look at:

        and specifically:

        It kind of looks like the integrated Arduino development environment can send updated fuses to the part? Or maybe I’m just hoping for the impossible!!!

        THANKS AGAIN for your help!!!!!

        • lincomatic says:

          If you’re using fastio, then PD4=28,PD5=29,PD6=30,PD7=31
          If using Arduino functions, then PD4=22,PD5=23,PD6=11,PD7=12
          I know it, confusing, but that’s what you get because Erik et al ignored my pleas to fix fastio.h.

          I’m not 100% sure, but it appears the fuse api is just to put some data into your ELF file, so that certain programming tools can fetch them to use w/ a programmer.

Write a Comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>