Arduino's examples and working tutorials do not address the bootloader in programming using Processing, Wiring, or 'C'. They tell that the bootloader is only for easy IDE access via USB. Ease of use since many of us (me) are not programmers. Note from me: RepG uses AVRdude, the arduino bootloader (~2K), and USB to program the firmware onto the Arduino. USBISP is a programmer and uses no bootloader but, does use AVRdude. AVRdude is an application run from a PC and is not on the mcu.
As to using our bots without a bootloader. The bootloader is for easy USB access and is used to check to see if we are accessing it to load a program prior to it running the onboard program/firmware. Thus, a tiny delay. Within the bootloader, there are no pins set for any use or timers tweaked according to arduino.cc's descriptions of the bootloader. The Arduino for several years has come with the bootloader AND a 'blink' sketch installed. The sketch uses pin 13 and the sketch is over written with any new installed sketch/firmware.
I've programmed more than 11 bare devices via USBISP. Burning fuses and bootloader. When one writes their Processing or 'C' code they initialize/assign environment, pins, timers, etc in their code and/or it will be done through a library call for special use within their application. This then is compiled using avr-gcc into assembler/hex which then is programmed to the board/chip. This is often done through the Arduino USB IDE via a bootloader. Or, as what brought this discussion to light, without a bootloader it is programmed via USBISP or other programmer and AVRdude via commandline or a GUI interface to the same.
Since MBI has not made mention to have a custom bootloader it is likely they had enough on their plates making our Uber Cool toys to just use what Arduino had installed. If so, then you real Programmers - dump the bootloader. Give yourselves ~2k of elbow room to develop within. It is not hard to program the chips. -- I knew - NOTHING -- four months ago and did not need to ask on any forums to learn. With the right tools: Google, my very expensive ($5.49 + Free Shipping) eBay bought USBISP programmer, some wires and downloaded open source software I can load a program or a bootloader in < 2 minutes.
Suggested Development process: 1) Program over the bootloader. 2) Test, tweak, refine. 3) Debug and Optimize to allow for bootloader space. 4) Compile for distribution. 5) Announce and release to prove.
FWIW..... ALL you guys are GREAT! This is fun and History making. :-)
----- Reply message ----- From: "Whosawhatsis" <whosawhat...@gmail.com> Date: Wed, Mar 7, 2012 3:50 pm Subject: [MakerBot] Re: help setting up toolchain To: <makerbot@googlegroups.com> Cc: "Jetty" <clelland...@gmail.com>
Again, good point. Now, you have me thinking more. Could a core of the firmware start on the ATmega then call sub-routine from external ram? This could allow the features to become fuller.
Jetty - Rob and I've not remembered you other gifted programmers names yet -
Could the above work to increase the capabilities of our bots?
----- Reply message ----- From: "Whosawhatsis" <whosawhat...@gmail.com> Date: Wed, Mar 7, 2012 4:38 pm Subject: [MakerBot] Re: help setting up toolchain To: "sto...@gmail.com" <sto...@gmail.com> Cc: "makerbot@googlegroups.com" <makerbot@googlegroups.com>
Remember that RAM is volatile, working memory. It cannot be used for persistent storage (at least not without hacks involving a backup power supply), and with the harvard architecture you should not be able to load programs into it. Additional RAM added this way should only be usable for working with larger data sets than the internal RAM is able to.
On Wednesday, March 7, 2012 at 3:48 PM, sto...@gmail.com wrote: > @Whosa
> Again, good point. Now, you have me thinking more. Could a core of the firmware start on the ATmega then call sub-routine from external ram? This could allow the features to become fuller.
> Jetty - Rob and I've not remembered you other gifted programmers names yet -
> Could the above work to increase the capabilities of our bots?
> ----- Reply message ----- > From: "Whosawhatsis" <whosawhat...@gmail.com (mailto:whosawhat...@gmail.com)> > Date: Wed, Mar 7, 2012 4:38 pm > Subject: [MakerBot] Re: help setting up toolchain > To: "sto...@gmail.com (mailto:sto...@gmail.com)" <sto...@gmail.com (mailto:sto...@gmail.com)> > Cc: "makerbot@googlegroups.com (mailto:makerbot@googlegroups.com)" <makerbot@googlegroups.com (mailto:makerbot@googlegroups.com)>
> I have seen mentions of Atmel chips being hooked up to external RAM. What I was talking about is that the program can only be loaded from the chips onboard flash, which AFAIK cannot be added-to to STORE larger programs.
> On Wednesday, March 7, 2012 at 1:15 PM, sto...@gmail.com (mailto:sto...@gmail.com) wrote:
> > @ whosa
> > Ahhh. OK.
> > I just remember years ago I wanted to repartition my giant 1GB HD and then use other and different FSs to load another operating system. Some hotshots I knew then said it was impossible because of ??? Anyway a few months later I bought an unknown 'Partition Magic' (only on OS2 - a better OS) and was good with repartitioning on the fly and running OS2, windoze 3.11 and later Solaris - Intel.
> > Oh well. It was just a thought since ATmega can R/W data to SD I guessed it could be tricked to work some remote RAM.
> > IIRC, these microcontrollers use a Harvard architecture which makes that impossible. You would need a Von Neumann architecture to execute code from external memory like that.
> > On Wednesday, March 7, 2012 at 12:17 PM, sto...@gmail.com (mailto:sto...@gmail.com) wrote:
> > > @ Jetty,
> > > Re: Non-programmers
> > > Yes, that's why I aimed at you and Rob and the other coders posting. I was curious - while you are re-writing if it would be more flexible to chuck the bootloader work your code. Then debug and optimize with some head room.
> > > @ All others > > > Q.: Couldn't code be generated to use external memory, read/write? Then a daughter add on could become part of the mix?
> > > Yes you could, you'd probably have to change the starting addresses > > > for the code, but that's a pretty minor change.
> > > However it would make it difficult for non programmer owners.
> > > > Say, to you hard core coders and compiling types. Do you know if the bootloader is actually required to run YOUR bots? Could you disregard the bootloader and burn firmware directly with a $5.00 mcu programmer then just run?
> > > -- > > > You received this message because you are subscribed to the Google Groups "MakerBot Operators" group. > > > To post to this group, send email to makerbot@googlegroups.com (mailto:makerbot@googlegroups.com). > > > To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com (mailto:makerbot+unsubscribe@googlegroups.com). > > > For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
> > > -- > > > You received this message because you are subscribed to the Google Groups "MakerBot Operators" group. > > > To post to this group, send email to makerbot@googlegroups.com (mailto:makerbot@googlegroups.com). > > > To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com (mailto:makerbot+unsubscribe@googlegroups.com). > > > For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups "MakerBot Operators" group. > > To post to this group, send email to makerbot@googlegroups.com (mailto:makerbot@googlegroups.com). > > To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com (mailto:makerbot+unsubscribe@googlegroups.com). > > For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "MakerBot Operators" group. > To post to this group, send email to makerbot@googlegroups.com (mailto:makerbot@googlegroups.com). > To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com (mailto:makerbot+unsubscribe@googlegroups.com). > For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
On Mar 7, 3:50 pm, Whosawhatsis <whosawhat...@gmail.com> wrote:
> The bootloader also does a few other things, like setting the default modes for various pins and probably configuring clocks and whatnot. Your code can do all of this for itself, but if it doesn't your code will not function as expected without the bootloader.
> From: "Jetty" <clelland...@gmail.com
(mailto:clelland...@gmail.com)>
> A bootloader's job is to "maybe" initialize a few things, delay a
> little watching for an incoming program upload, write that
> program upload to flash, and if there isn't one, execute the
program
> on flash.
> So, if you dump the boot loader, don't expect the software to still
> run without some alteration, because what's calling the main
program?
> I.E. You need both unless you make changes to allow for there being
no
> boot loader.
Actually, your both a bit off the mark. Here's how it works:
1. When the compiler builds your application (or a boot loader) it
assumes nothing is setup. The only thing the default start up code
does is to init some RAM and setup the stack before calling the main()
function. The Arduino startup which runs in main() sets up some timers
and stuff. If you don't believe me, setup the compiler to generate a
listing file and look at the code yourself. The only difference
between a boot loader and any other application is that the boot
loader is linked to run from the boot loader start address.
2. You do not need a boot loader to start your application. The
application does not know or care if a boot loader ran first. When you
program the AVR you set a fuse bit that tells the chip where to start
executing code after a reset. Either at the start of the boot loader
(you can also choose the boot loader start location from a short
list), or at zero where the application is stored. All the boot loader
does to start the application is jump to zero. Take a look at the
description of the BOOTSZ1, BOOTSZ0, and BOOTRST fuse bits in the
extended fuse byte in the AVR data sheet.
3. If you want to test that your Arduino app can run without the boot
loader, just load it the normal way and then change the fuse bits to
disable the boot loader, your app will still run fine. (The Arduino
web site even says that you can use the full flash for a sketch by
using a programmer to burn it)
>there are no pins set for any use or timers tweaked according to arduino.cc's descriptions of the bootloader
There's a custom boot loader that's burnt onto your extruder
controller before MBI sends it to you.
It switches the FET's off that control the heater etc / fan. I.E.
Channel A/B/C.
They say they've issued this custom boot loader to stop damage to the
FET's / circuitry by having it powered on at boot. You can find this
boot loader under:
That is interesting about the EC bootloader. Was a bootloader customized for lack of space in the firmware?
Since the bootloader loads then steps aside to run the app. What is the advantage to put that setup in the bootloader? Do you think it was to assure an 'all off' during a firmware upgrade?
----- Reply message ----- From: "Jetty" <clelland...@gmail.com> Date: Thu, Mar 8, 2012 12:29 am Subject: [MakerBot] Re: help setting up toolchain To: "MakerBot Operators" <makerbot@googlegroups.com>
>there are no pins set for any use or timers tweaked according to arduino.cc's descriptions of the bootloader
There's a custom boot loader that's burnt onto your extruder controller before MBI sends it to you.
It switches the FET's off that control the heater etc / fan. I.E. Channel A/B/C.
They say they've issued this custom boot loader to stop damage to the FET's / circuitry by having it powered on at boot. You can find this boot loader under:
-rwxr-xr-x 1 staff 29297 19 Feb 20:05 ATmegaBOOT_168.c -rw-r--r-- 1 staff 5513 19 Feb 20:05 ATmegaBOOT_168_ec22.hex -rw-r--r-- 1 staff 5529 19 Feb 20:05 ATmegaBOOT_168_ec3x.hex -rw-r--r-- 1 staff 5513 19 Feb 20:05 ATmegaBOOT_168_ec3x_328.hex -rw-r--r-- 1 staff 11122 19 Feb 20:05 ATmegaBOOT_168_mb2x.hex -rwxr-xr-x 1 staff 7487 19 Feb 20:05 Makefile
There's also an mb2x.hex, I'm guessing for the motherboard, but I've never seen this documented anywhere.
Of course, you could still switch off the FETs as part of the startup in the main code, if you were going to dump the bootloader.
-- You received this message because you are subscribed to the Google Groups "MakerBot Operators" group. To post to this group, send email to makerbot@googlegroups.com. To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
>Was a bootloader customized for lack of space in the firmware?
See previous post.
>Since the bootloader loads then steps aside to run the app. What is the advantage to put that setup in the boot loader?
>Do you think it was to assure an 'all off' during a firmware upgrade?
I customized mine to add an I2C display to the EC.
> Do you think it was to assure an 'all off' during a firmware upgrade?
The pins to the heaters and (early on) to the DC motor needed to be controlled during a firmware update.
I ran the EC without a bootloader for a while, and that's when I learned that some of the pins were never setup on the main firmware. I corrected it and makerbot merged the changes in, but that's been at least a year ago and many things have changed.
OK. Between your direct handling and jetty pointing me to the EC wiki they had floating pins. Seems pull down resistors on the board would help. And if not then use transistors to power the mosfets. This would, obvious, have the mosfets off till turned up by application.
----- Reply message ----- From: "Rob Giseburt" <giseb...@gmail.com> Date: Thu, Mar 8, 2012 10:47 am Subject: [MakerBot] Re: help setting up toolchain To: "makerbot@googlegroups.com" <makerbot@googlegroups.com> Cc: "Jetty" <clelland...@gmail.com>
I customized mine to add an I2C display to the EC.
> Do you think it was to assure an 'all off' during a firmware upgrade?
The pins to the heaters and (early on) to the DC motor needed to be controlled during a firmware update.
I ran the EC without a bootloader for a while, and that's when I learned that some of the pins were never setup on the main firmware. I corrected it and makerbot merged the changes in, but that's been at least a year ago and many things have changed.
-Rob
-- You received this message because you are subscribed to the Google Groups "MakerBot Operators" group. To post to this group, send email to makerbot@googlegroups.com. To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
They can float for a small amount of time. Just as long as you set them low as soon as possible, which is either at the beginning of the bootloader or the beginning of the firmware (or, better, both, like it should be now.)
-Rob
On Mar 8, 2012, at 10:42 AM, "sto...@gmail.com" <sto...@gmail.com> wrote:
OK. Between your direct handling and jetty pointing me to the EC wiki they had floating pins. Seems pull down resistors on the board would help. And if not then use transistors to power the mosfets. This would, obvious, have the mosfets off till turned up by application.
----- Reply message ----- From: "Rob Giseburt" <giseb...@gmail.com> Date: Thu, Mar 8, 2012 10:47 am Subject: [MakerBot] Re: help setting up toolchain To: "makerbot@googlegroups.com" <makerbot@googlegroups.com> Cc: "Jetty" <clelland...@gmail.com>
I customized mine to add an I2C display to the EC.
> Do you think it was to assure an 'all off' during a firmware upgrade?
The pins to the heaters and (early on) to the DC motor needed to be controlled during a firmware update.
I ran the EC without a bootloader for a while, and that's when I learned that some of the pins were never setup on the main firmware. I corrected it and makerbot merged the changes in, but that's been at least a year ago and many things have changed.
-Rob
-- You received this message because you are subscribed to the Google Groups "MakerBot Operators" group. To post to this group, send email to makerbot@googlegroups.com. To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
On Thu, Mar 8, 2012 at 12:08 PM, Rob Giseburt <giseb...@gmail.com> wrote: > Are you designing a new EC?
> They can float for a small amount of time. Just as long as you set them > low as soon as possible, which is either at the beginning of the bootloader > or the beginning of the firmware (or, better, both, like it should be now.)
> -Rob
> On Mar 8, 2012, at 10:42 AM, "sto...@gmail.com" <sto...@gmail.com> wrote:
> OK. Between your direct handling and jetty pointing me to the EC wiki they > had floating pins. Seems pull down resistors on the board would help. And > if not then use transistors to power the mosfets. This would, obvious, have > the mosfets off till turned up by application.
> ----- Reply message ----- > From: "Rob Giseburt" <giseb...@gmail.com> > Date: Thu, Mar 8, 2012 10:47 am > Subject: [MakerBot] Re: help setting up toolchain > To: "makerbot@googlegroups.com" <makerbot@googlegroups.com> > Cc: "Jetty" <clelland...@gmail.com>
> I customized mine to add an I2C display to the EC.
> > Do you think it was to assure an 'all off' during a firmware upgrade?
> The pins to the heaters and (early on) to the DC motor needed to be > controlled during a firmware update.
> I ran the EC without a bootloader for a while, and that's when I > learned that some of the pins were never setup on the main firmware. I > corrected it and makerbot merged the changes in, but that's been at > least a year ago and many things have changed.
> -Rob
> -- > You received this message because you are subscribed to the Google Groups > "MakerBot Operators" group. > To post to this group, send email to makerbot@googlegroups.com. > To unsubscribe from this group, send email to > makerbot+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/makerbot?hl=en.
On Thu, Mar 8, 2012 at 12:08 PM, Rob Giseburt <giseb...@gmail.com> wrote: > Are you designing a new EC?
> They can float for a small amount of time. Just as long as you set them > low as soon as possible, which is either at the beginning of the bootloader > or the beginning of the firmware (or, better, both, like it should be now.)
> -Rob
> On Mar 8, 2012, at 10:42 AM, "sto...@gmail.com" <sto...@gmail.com> wrote:
> OK. Between your direct handling and jetty pointing me to the EC wiki they > had floating pins. Seems pull down resistors on the board would help. And > if not then use transistors to power the mosfets. This would, obvious, have > the mosfets off till turned up by application.
> ----- Reply message ----- > From: "Rob Giseburt" <giseb...@gmail.com> > Date: Thu, Mar 8, 2012 10:47 am > Subject: [MakerBot] Re: help setting up toolchain > To: "makerbot@googlegroups.com" <makerbot@googlegroups.com> > Cc: "Jetty" <clelland...@gmail.com>
> I customized mine to add an I2C display to the EC.
> > Do you think it was to assure an 'all off' during a firmware upgrade?
> The pins to the heaters and (early on) to the DC motor needed to be > controlled during a firmware update.
> I ran the EC without a bootloader for a while, and that's when I > learned that some of the pins were never setup on the main firmware. I > corrected it and makerbot merged the changes in, but that's been at > least a year ago and many things have changed.
> -Rob
> -- > You received this message because you are subscribed to the Google Groups > "MakerBot Operators" group. > To post to this group, send email to makerbot@googlegroups.com. > To unsubscribe from this group, send email to > makerbot+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/makerbot?hl=en.
On Thu, Mar 8, 2012 at 12:08 PM, Rob Giseburt <giseb...@gmail.com> wrote: > Are you designing a new EC?
> They can float for a small amount of time. Just as long as you set them > low as soon as possible, which is either at the beginning of the bootloader > or the beginning of the firmware (or, better, both, like it should be now.)
> -Rob
> On Mar 8, 2012, at 10:42 AM, "sto...@gmail.com" <sto...@gmail.com> wrote:
> OK. Between your direct handling and jetty pointing me to the EC wiki they > had floating pins. Seems pull down resistors on the board would help. And > if not then use transistors to power the mosfets. This would, obvious, have > the mosfets off till turned up by application.
> ----- Reply message ----- > From: "Rob Giseburt" <giseb...@gmail.com> > Date: Thu, Mar 8, 2012 10:47 am > Subject: [MakerBot] Re: help setting up toolchain > To: "makerbot@googlegroups.com" <makerbot@googlegroups.com> > Cc: "Jetty" <clelland...@gmail.com>
> I customized mine to add an I2C display to the EC.
> > Do you think it was to assure an 'all off' during a firmware upgrade?
> The pins to the heaters and (early on) to the DC motor needed to be > controlled during a firmware update.
> I ran the EC without a bootloader for a while, and that's when I > learned that some of the pins were never setup on the main firmware. I > corrected it and makerbot merged the changes in, but that's been at > least a year ago and many things have changed.
> -Rob
> -- > You received this message because you are subscribed to the Google Groups > "MakerBot Operators" group. > To post to this group, send email to makerbot@googlegroups.com. > To unsubscribe from this group, send email to > makerbot+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/makerbot?hl=en.
When you redesign the extruder, please post your design to
thingiverse. A bigger processor would
be a good idea and robustness against static (serial to MB and
thermocouple) whilst you're in the design phase.
On Thu, Mar 8, 2012 at 1:18 PM, Jetty <clelland...@gmail.com> wrote: >> sounds like you're planning a redesign.
> When you redesign the extruder, please post your design to > thingiverse. A bigger processor would > be a good idea and robustness against static (serial to MB and > thermocouple) whilst you're in the design phase.
> -- > You received this message because you are subscribed to the Google Groups "MakerBot Operators" group. > To post to this group, send email to makerbot@googlegroups.com. > To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
> When you redesign the extruder, please post your design to > thingiverse. A bigger processor would > be a good idea and robustness against static (serial to MB and > thermocouple) whilst you're in the design phase.
And space and processing cycles for the snake game so that it can be taken off of the motherboard freeing up space for more amazing new features. (Or maybe a two player version with networking over the rs485 cable?)
Ok, I'll bite (and probably cause more thread fragmentation) ...
What's wrong with the hot end?
There's a laundry list of problems with extruders (and just as many proposed solutions), and the problems with the existing MBI EC are well documented, but what's wrong with the Mk7/8 hot end? For the moment, let's leave value-system judgements[1] out of it and stick to physics and engineering problems.
- Craig -
[1] We wouldn't be here without the RepRap project, and I'm currently working with the local RepRap group to build 10+ Prusas, but I got my TOM to print things, not to work on the next iteration of the Universal Constructor. I don't mind building a printer out of non-printable parts, as long as they are cheap and plentiful.
On Thu, Mar 8, 2012 at 16:27, sto...@gmail.com <sto...@gmail.com> wrote: > Hmmm. Not immediate. Hot end first. Extruder second. EC, guess if it can > be upgraded. I think it is likely too involved for me.
> ----- Reply message ----- > From: "Rob Giseburt" <giseb...@gmail.com> > Date: Thu, Mar 8, 2012 3:28 pm > Subject: [MakerBot] Re: help setting up toolchain > To: "sto...@gmail.com" <sto...@gmail.com> > Cc: "makerbot@googlegroups.com" <makerbot@googlegroups.com>
> If you are proposing adding resistors to the board, then it sounds like > you're planning a redesign.
> -Rob
> On Mar 8, 2012, at 2:16 PM, "sto...@gmail.com" <sto...@gmail.com> wrote:
> Should I redesign the EC?
> ----- Reply message ----- > From: "Rob Giseburt" <giseb...@gmail.com> > Date: Thu, Mar 8, 2012 1:02 pm > Subject: [MakerBot] Re: help setting up toolchain > To: "B Stott" <sto...@gmail.com> > Cc: "makerbot@googlegroups.com" <makerbot@googlegroups.com>
> Are you redesigning the EC?
> -Rob
> On Mar 8, 2012, at 11:51 AM, B Stott <sto...@gmail.com> wrote:
> Why not pin low on the board?
> On Thu, Mar 8, 2012 at 12:08 PM, Rob Giseburt <giseb...@gmail.com> wrote:
>> Are you designing a new EC?
>> They can float for a small amount of time. Just as long as you set them >> low as soon as possible, which is either at the beginning of the bootloader >> or the beginning of the firmware (or, better, both, like it should be now.)
>> -Rob
>> On Mar 8, 2012, at 10:42 AM, "sto...@gmail.com" <sto...@gmail.com> wrote:
>> OK. Between your direct handling and jetty pointing me to the EC wiki >> they had floating pins. Seems pull down resistors on the board would help. >> And if not then use transistors to power the mosfets. This would, obvious, >> have the mosfets off till turned up by application.
>> ----- Reply message ----- >> From: "Rob Giseburt" <giseb...@gmail.com> >> Date: Thu, Mar 8, 2012 10:47 am >> Subject: [MakerBot] Re: help setting up toolchain >> To: "makerbot@googlegroups.com" <makerbot@googlegroups.com> >> Cc: "Jetty" <clelland...@gmail.com>
>> I customized mine to add an I2C display to the EC.
>> > Do you think it was to assure an 'all off' during a firmware upgrade?
>> The pins to the heaters and (early on) to the DC motor needed to be >> controlled during a firmware update.
>> I ran the EC without a bootloader for a while, and that's when I >> learned that some of the pins were never setup on the main firmware. I >> corrected it and makerbot merged the changes in, but that's been at >> least a year ago and many things have changed.
>> -Rob
>> -- >> You received this message because you are subscribed to the Google Groups >> "MakerBot Operators" group. >> To post to this group, send email to makerbot@googlegroups.com. >> To unsubscribe from this group, send email to >> makerbot+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/makerbot?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "MakerBot Operators" group. > To post to this group, send email to makerbot@googlegroups.com. > To unsubscribe from this group, send email to > makerbot+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/makerbot?hl=en.
>> When you redesign the extruder, please post your design to >> thingiverse. A bigger processor would >> be a good idea and robustness against static (serial to MB and >> thermocouple) whilst you're in the design phase.
> And space and processing cycles for the snake game so that > it can be taken off of the motherboard freeing up space for > more amazing new features. (Or maybe a two player > version with networking over the rs485 cable?)
> Dan
> -- > You received this message because you are subscribed to the Google Groups "MakerBot Operators" group. > To post to this group, send email to makerbot@googlegroups.com. > To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
