This was one of my original ideas, perhaps to port GRBL (which runs on a
very similar AVR chip) to the Cricut's hardware.
http://dank.bengler.no/-/page/show/5473_connectinggrblThe biggest issue would be that GRBL outputs step/direction pulses, so to
run this on a Cricut we'd need to just adapt this to the proper stepper
phases.
The Cricut hardware provides "half power" and "full power" control for each
stepper phase, there are not enough PWM channels to do true sinusoidal
stepping in both X and Y directions, but I rather like the "High Torque
Half Stepping" mode described here:
http://www.piclist.com/techref/io/stepper/linistep/halfstep.htmFlow control would still be an issue since there's not enough onboard
memory to buffer more than the smallest jobs, but I think you could
probably design a RAM card for the cartridge slot, or even a flashcard
reader to completely cut the cord.
Interestingly enough, Cricut cartridges contain their own ATMEGA16
processor and 1 mbit flash memory (and a conveniently located programming
header), I bet you could even reprogram one to serve as the job buffer, no
hardware design needed.
-David
On Wed, Jun 27, 2012 at 2:04 PM, James <jamesrsweet@...> wrote:
> ∗∗
>
>
>
>
> --- In Homebrew_PCBs@yahoogroups.com, Randall Morgan <rmorgan62@...>
> wrote:
> >
> > No, what I am describing is sending the step data not the GCode which has
> > to be interpreted and compiled into step commands. It can be done using a
> > RTOS but under a non RTOS it requires either extra hardware buffering.
> >
>
> I rather like the idea of using Gcode since it's so ubiquitous in the
> world of CNC. Seems like some of the modern microcontrollers ought to have
> more than enough power to interpret Gcode and drive some stepper motors or
> servos. It has struck me a number of times that in virtually everything I
> have ever built with a microcontroller, even the lowest end ones end up
> spending 90% of their time in delay loops.
>
>
>
[Non-text portions of this message have been removed]