Teacup: Port to AT90USBKEY (AT90USB1287)

I'm working on a project to use up some parts I have. Several years ago I bought the components for 3 L297/L298 stepper drivers. I never got around to manufacturing boards for them, so now I'm dead-bugging them on a piece of copper clad. For control I like the idea of the FiveG/Teacup style gcode interpreter to avoid dependencies on PC control software. I happen to have a spare AT90USBKEY with its AT90USB1287 so I'd like to use that.

So far I have:

1. Ported to AT90USB1287 by creating arduino_usb1287.h and making some other minor mods.
2. Imported LUFA (the USB library) and modified the LowLevel/VirtualSerial demo to fit in the same "API" as serial.c.
3. Modified the Makefile to key off the MCU having "usb" to drop serial.h and bring in lufa_serial instead.
4. For my purposes I didn't need Z or E right away so I made those optional (if pins are undefined the code does not build in).

I still need to ensure that the pin output is correct and that there's no USB-Teacup interference, but I can build with DEBUG and observe G0/G1 cause the output of M250 to change.

Questions:

1. Is there interest in all/any of this for the main repo?
2. Should I just post here with git-format-patch attachments or can I just fork on github and post a "pull" request?
3. On configuration: The MAXIMUM_FEEDRATE_X/Y/Z seem absurdly small. They claim to be mm/min but look about 20x too low. G0 moves observed by M250 (still no steppers hooked up) seem to verify the slowness: That rapid would take a full minute to cross a mendel build platform. The "search" feedrates of 50 mm/min would take 4 minutes to home!
4. How important is it to go at 16MHz vs 8? I haven't used the AT90USB1287 in long enough that I forget the clock configuration so I'm accepting the defaults right now and I don't want to bother figuring out the fuses etc if I don't have to.

--Ben

BenJackson Wrote:
-------------------------------------------------------
> I'm working on a project to use up some parts I
> have. Several years ago I bought the components
> for 3 L297/L298 stepper drivers. I never got
> around to manufacturing boards for them, so now
> I'm dead-bugging them on a piece of copper clad.
>
> For control I like the idea of the FiveG/Teacup
> style gcode interpreter to avoid dependencies on
> PC control software. I happen to have a spare
> AT90USBKEY with its AT90USB1287 so I'd like to use
> that.
>
> So far I have:
>
> 1. Ported to AT90USB1287 by creating
> arduino_usb1287.h and making some other minor
> mods.

that's the way to do it

> 2. Imported LUFA (the USB library) and modified
> the LowLevel/VirtualSerial demo to fit in the same
> "API" as serial.c.

lovely

> 3. Modified the Makefile to key off the MCU
> having "usb" to drop serial.h and bring in
> lufa_serial instead.

I'd prefer to have this user-selectable rather than autodetected from the cpu, but we can sort that out later

> 4. For my purposes I didn't need Z or E right
> away so I made those optional (if pins are
> undefined the code does not build in).

I think a couple of patches for this already showed up in master just recently

> I still need to ensure that the pin output is
> correct and that there's no USB-Teacup
> interference, but I can build with DEBUG and
> observe G0/G1 cause the output of M250 to change.
>
> Questions:
>
> 1. Is there interest in all/any of this for the
> main repo?

yes, I'm very interested

> 2. Should I just post here with git-format-patch
> attachments or can I just fork on github and post
> a "pull" request?

pull request please, especially if you have several commits for different alterations.

> 3. On configuration: The MAXIMUM_FEEDRATE_X/Y/Z
> seem absurdly small. They claim to be mm/min but
> look about 20x too low. G0 moves observed by M250
> (still no steppers hooked up) seem to verify the
> slowness: That rapid would take a full minute to
> cross a mendel build platform. The "search"
> feedrates of 50 mm/min would take 4 minutes to
> home!

yes, the defaults are deliberately set to be absurdly low. This provides two things: 1) higher chance of initial success and 2) impetus to play with settings

> 4. How important is it to go at 16MHz vs 8? I
> haven't used the AT90USB1287 in long enough that I
> forget the clock configuration so I'm accepting
> the defaults right now and I don't want to bother
> figuring out the fuses etc if I don't have to.

use whatever frequency works best for your usb library. The firmware doesn't care what your cpu freq is, but it must know what it is in order to correctly calculate timer numbers and things. Most arduinos use 16MHz because it has lower error on the serial baud generator than 20MHz.


I do have one question though; how do you prevent the timer interrupts from upsetting the hard real-time requirements of usb, or vice versa?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> > 3. Modified the Makefile to key off the MCU
> > having "usb" to drop serial.h and bring in
> > lufa_serial instead.
>
> I'd prefer to have this user-selectable rather
> than autodetected from the cpu, but we can sort
> that out later

Part of the reason I did that was that the AT90USB1287 doesn't have a USART0. I didn't feel like parameterizing serial.c for an option I'd never use.

> > 4. For my purposes I didn't need Z or E right
> > away so I made those optional (if pins are
> > undefined the code does not build in).
>
> I think a couple of patches for this already
> showed up in master just recently

I'll double check this and avoid duplicating it in my fork.

Oh, I will also be committing (to my fork) a version of LUFA, since it is not the kind of library you pre-build but one you build with specific options for each application. It is MIT licensed so it can be included in Teacup but you may choose to require someone to unpack LUFA into the tree when building for USB instead.

> > 3. On configuration: The
> MAXIMUM_FEEDRATE_X/Y/Z
> > seem absurdly small.
>
> yes, the defaults are deliberately set to be
> absurdly low. This provides two things: 1) higher
> chance of initial success and 2) impetus to play
> with settings

Ok, just a misunderstanding then: I assumed that the less technically inclined were using pre-compiled firmware.

> use whatever frequency works best for your usb
> library. The firmware doesn't care what your cpu
> freq is, but it must know what it is in order to
> correctly calculate timer numbers and things. Most
> arduinos use 16MHz because it has lower error on
> the serial baud generator than 20MHz.

The AT90USBKEY has a 8MHz crystal and I'm pretty sure I could turn on a PLL to get a higher internal frequency (without disrupting USB ) but I won't if it's not necessary.

> I do have one question though; how do you prevent
> the timer interrupts from upsetting the hard
> real-time requirements of usb, or vice versa?

I don't know that I won't yet because I've not hooked up the full system. I'm pretty sure that all the key parts of the USB spec are implemented in hardware. The vector number for USB is lower than any of the ones in use by Teacup so if there's disruption it's likely to be USB disrupting the timers. Since my initial hardware target is going to be an Etch-a-Sketch I doubt I will see any problems unless I can measure them with my scope.

--Ben

BenJackson Wrote:
-------------------------------------------------------
> Part of the reason I did that was that the
> AT90USB1287 doesn't have a USART0. I didn't feel
> like parameterizing serial.c for an option I'd
> never use.

leave it as is for the time being then

> Oh, I will also be committing (to my fork) a
> version of LUFA, since it is not the kind of
> library you pre-build but one you build with
> specific options for each application. It is MIT
> licensed so it can be included in Teacup but you
> may choose to require someone to unpack LUFA into
> the tree when building for USB instead.

is it available via a git repository? git supports sub-repositories, and this sounds like an ideal use for that feature.

> Ok, just a misunderstanding then: I assumed that
> the less technically inclined were using
> pre-compiled firmware.

They'll be able to when we've actually decided to make a release, but we're not quite there yet (almost!)

> I don't know that I won't yet because I've not
> hooked up the full system. I'm pretty sure that
> all the key parts of the USB spec are implemented
> in hardware. The vector number for USB is lower
> than any of the ones in use by Teacup so if
> there's disruption it's likely to be USB
> disrupting the timers. Since my initial hardware
> target is going to be an Etch-a-Sketch I doubt I
> will see any problems unless I can measure them
> with my scope.

It's not so much interrupt priority that I was wondering about, more that when an interrupt is running, no other interrupts can fire until it's finished, which if we have long-running interrupts can affect timing of various things. Both usb and stepper motors require fairly precise timing, although the usb is more sensitive I think.

I think most of the timing issues will occur regardless of having any hardware connected, so see if you can dump a large (>~100k) g-code file with all the non G1 commands removed and make sure it doesn't generate any usb errors. Let it run overnight if you can find a way to monitor for usb issues. Crank the speed limits right up first, so it's running the step interrupt fairly quickly

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I successfully CNC'd my Etch-a-Sketch with the Teacup firmware and a dead-bug L297+L298 stepper setup. No problem at 5000mm/min (though only 6.3 steps/mm due to 7.5 deg Airpax steppers and only room for 2.6x gear reduction).

I sent a pull request on github. I sorted out some clash where I made E & Z optional in one commit so there's a separate commit for optional Z. May not be generally useful.

I have not pushed changes related to LUFA yet. I see that the author has a "mirror" on github (he really works in a private svn repo) so I can look at making a submodule pulling from that.

Sadly my first attempt to get Inkscape to make gcode with [cnc-club.ru] failed so the most complex thing I've drawn so far is a slice copied from skeinforge output.

I'm curious to know if func.sh mendel_print can normally keep up with fast moving curves. On my setup (I plotted a big spiral I made in Inkscape) the curves are limited by the command round trip (with 8000mm/min feedrate). I see that the CDC descriptor I took from LUFA is requesting 1ms poll interval and I doubt FTDI goes any faster (I think 1ms is the lowest interval).

I can go full speed with:

(cat <&3 & cat ~/proj/makerbot/etch-a-sketch/whee.gcode >&3) 3<>/dev/ttyACM0

Where the first cat is required or things get really slow when some buffer somewhere fills up with "ok".

I'm not sure what exactly happens for output flow control in that setup but no commands are lost and there are no pauses between commands.

usb has its own flow control built into the specification, I'm sure lufa leans on it heavily. What segment length does your spiral have, that needs 500+ commands per second? I didn't think the chip could run dda_create that fast...

Try increasing your movebuffer length perhaps, to 16 or even 32 if the chip has enough ram (movebuffer is huge- about 70 bytes per entry). Size must be 2^n because we use bit manipulation on the pointers rather than proper math

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Ok, that's what I needed to know. I wasn't getting 500 cmds/sec. More like 4-5. Looks like the time for "ok" to come back is 200-250ms. I'm not sure why, but I'm looking into it.

that's probably how long it takes dda_create() to run. only way to speed that up is somehow make the math faster while still doing most of the same calculations

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> that's probably how long it takes dda_create() to
> run. only way to speed that up is somehow make the
> math faster while still doing most of the same
> calculations

But I am able to go much, much faster if I just cat the whole file to the firmware. It appears to be (correctly) feedrate limited in that case. I assume dda_create() is still doing its thing every time no matter how I send the commands. What's making things terribly slow is the 'send command, wait for OK' loop which sees a big gap waiting for each "OK".

It's not really a big deal for my etch-a-sketch (heh) but I want to get to the bottom of it in case someone tries to use an AT90USB in a mendel!

hm, usb is a packet based protocol.. is lufa waiting for a whole packet, before deciding to send what it's got?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

BenJackson Wrote:
-------------------------------------------------------
....
> Sadly my first attempt to get Inkscape to make
> gcode with
> [cnc-club.ru] failed
> so the most complex thing I've drawn so far is a
> slice copied from skeinforge output.

Hi. I'm one of the Gcodetools developers. Why your attempt has failed? Probably I can help you with that.

Hi BenJackson,

I am currently trying to use the Teacup Firmware on an AT90USB1286 for an RepRap 3D printer. I am trying to use your contributions to it and already edited the settings to match my electronics, but I can't get it to make. I have already dowloaded the LUFA repository and found out that apparently I had to put it in a folder that was called "trunk" (is this right?), but still it isn't working. I have already asked Triffid_Hunter, but he told me he didn't know the solution, because it was not him that implemented the port to the AT90USB1286/7.

Do you have any suggestion about how what I should do to let it make. It would also really help if you would like to send me the version of firmware you use on your machine, although it is not for an 3D printer, but maybe I can restore the old settings, so I can get it to make and just change the setting, without having to worry about how to implement the LUFA library.

Webfp

Webfp Wrote:
-------------------------------------------------------
>
> I am currently trying to use the Teacup Firmware
> on an AT90USB1286 for an RepRap 3D printer. I am
> trying to use your contributions to it and already
> edited the settings to match my electronics, but I
> can't get it to make. I have already dowloaded the
> LUFA repository and found out that apparently I
> had to put it in a folder that was called "trunk"
> (is this right?),

Sorry for the delay -- I don't hang out on this forum. You can email me (my email is in the commit log).

It's a git submodule. I think from a clean checkout you do `git submodule init` and then `git submodule update` and it will check the right version of LUFA out for you in a subdirectory of the Teacup firmware.

Can you post the build errors? I have rebuilt it somewhat recently (I used it briefly to control a laser cutter) but I am not closely tracking the teacup trunk because I'm not using it in a 3d printer.

--Ben