help setting up toolchain

[John D'Ausilio]

I've been fighting with getting a toolchain running that will compile
G3Firmware ..

Initially tried outdated MBI instructions, fail (lots of problems)
Next built toolchain manually using latest (4.6.3), fail prog_uchar
again using 4.6.2, fail prog_uchar
Next built toolchain using Jorg's scripts (4.5.1), fail stdint.h ..
added -D__STDC_HOSTED__=0 now fails atomic.h

Can anyone offer suggestions on how to get a working toolchain on
32-bit linux that will compile G3Firmware?

john d

[Robert Hunt]

I followed the MBI instructions and didn't have any issues under Ubuntu:

apt-get install gcc-avr avr-libc avrdude scons git-core

git clone git://github.com/makerbot/G3Firmware.git

cd G3Firmware/firmware

scons

[JohnA.]

Last time I did it was probably 6 months ago, but at that time I just followed the same directions.....

JohnA.

[Cliff L. Biffle]

On Tue, Mar 6, 2012 at 7:31 AM, John D'Ausilio <jdau...@gmail.com> wrote:

Next built toolchain manually using latest (4.6.3), fail prog_uchar
again using 4.6.2, fail prog_uchar

Don't feel bad!  This isn't your problem -- it's the firmware's.

prog_uchar has been deprecated in avr-gcc forever.  They shouldn't have used it.  Once you fix that you'll get some errors about const correctness.

Here's what I had to change to get the firmware compiling under 4.6.2: https://github.com/cbiffle/G3Firmware/commit/539c48d7cb1b569031f2189569896506d9824a7e

 

As for installing GCC:

On Wed, Mar 7, 2012 at 5:35 AM, Robert Hunt <robert...@gmail.com> wrote:

I followed the MBI instructions and didn't have any issues under Ubuntu:

apt-get install gcc-avr avr-libc avrdude scons git-core

Note that this will install a rather old version of avr-gcc -- older than what Jetty et al. are recommending for firmware builds.  Even under Pedantic Polygon.

I did a review of avr-gcc package versions in Debian-derived distros last night (trying to choose my next VM) and didn't find any that packaged anything more recent than 4.5.

Fedora ships 4.6.2.  Good for them.  Might try that if you don't want to build your own.

I ended up using my toolchain under OS X with larsimmisch's Homebrew recipe for avr-gcc and avr-libc.

-Cliff L. Biffle

[Jetty]

>Note that this will install a rather old version of avr-gcc -- older than
>what Jetty et al. are recommending for firmware builds. Even under
>Pedantic Polygon.

It's worth mentioning that the stock MBI Extruder firmware will not
fit on the extruder
if you compile with some older avr-gcc's (maybe all), the binary is
too large.

I'm using gcc V4.6.2, but my environment is mac not linux. I had to
compile the toolchain
from scratch and fix a couple of compiler issues to be able to build.

[Ethan Dicks]

On Wed, Mar 7, 2012 at 11:22 AM, Jetty <clell...@gmail.com> wrote:
> It's worth mentioning that the stock MBI Extruder firmware will not
> fit on the extruder
> if you compile with some older avr-gcc's (maybe all), the binary is
> too large.

Interesting to learn. I have a spare Gen3 extruder I bought as a bare
board when such things were still possible to buy. Since I still run
CupCakes, this news makes me want to consider stuffing that board with
a 328P for some headroom.

I'm surprised to hear there's a substantial difference in compiled
code size from one version of avr-gcc to another. A few bytes? Sure.
Doesn't fit? That's different.

Since I haven't compiled firmware from source in a couple of years, I
have to ask - how close to the limit _is_ the Gen3 firmware? What
about using a different bootloader to release some space? (ISTR
there's a newer bootloader that's 500ish bytes vs 2K for the
traditional one). What about abandoning the bootloader entirely and
requiring an ISP programmer? I know all Gen3 owners have a USB-TTL
cable and can reprogram their firmware via serial if there's a viable
bootloader, but a $20 USBtinyISP is a lot cheaper than replacing the
board.

> I'm using gcc V4.6.2, but my environment is mac not linux.  I had to
> compile the toolchain
> from scratch and fix a couple of compiler issues to be able to build.

I had to do that when I was developing on and running the CupCake from
a CentOS laptop last year - it took me quite a bit of time to get
avr-gcc working from source - far longer than I would have predicted.

-ethan

[sto...@gmail.com]

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 make...@googlegroups.com.
To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.

[Rob Giseburt]

The bootloader is not completely needed, however, I have found that the bootloader does do a little setup that the firmware (erroneously) relies on.

This is a work-in-progress that I have had to put on the back burner, but it’s working for me (most of the time, at least):

https://github.com/giseburt/Optiboot-for-Makerbot

I have only really tested it on the Gen3 and Gen4 EC, as far as I recall.

Now, to get it to work, you have to kinda trick scons a little:

scons platform=ecv22 baud="115200 -F" port=/dev/tty.usbserial-* upload

You’ll need to change the port for your OS, but note that there is a space in quotes … that’s required. Optiboot looses the ability to verify the chip type, so you need avrdude to have a -F on the command, and I’ve found that above is the easiest way.

  -Rob

—

MakerBot Operator

Member of CCCKC Hackerspace

Member of KC Fabricators Google Group

[Ethan Dicks]

On Wed, Mar 7, 2012 at 12:44 PM, sto...@gmail.com <sto...@gmail.com> wrote:
> Say, to you hard core coders and compiling types. Do you know if the
> bootloader is actually required to run YOUR bots?

No. Not required, but given the hassles I remember from a few years
back, when CupCake firmware changed every few weeks, users had a wad
of problems updating their firmware.

No bootloader means that you can not use the USB-TTL cable to update
your firmware over the serial interface. That's it. It has no
bearing on the payload code itself.

> Could you disregard the bootloader and burn firmware directly...

Yes.

> with a $5.00 mcu programmer then just run?

$5? What programmer are you recommending? I can build an uber-cheap
parallel port programmer that avrdude can drive, but then I have
nowhere to plug that into a modern laptop.

If you have a suggestion better than this...

http://www.ladyada.net/make/usbtinyisp/

... I would love to learn about it (I already own a USBtinyISP and
have recommended to several friends who do Arduino work that they get
one as well).

I detest the fact that hardware vendors dropped "legacy ports" years
ago, but nobody asked me what I thought.

-ethan

[Jetty]

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.

[Rob Giseburt]

And a word of warning: When using a full programmer, by default avrdude wipes out your EEPROM when programming.

  -Rob

—

MakerBot Operator

Member of CCCKC Hackerspace

Member of KC Fabricators Google Group

[Ethan Dicks]

On Wed, Mar 7, 2012 at 12:57 PM, Rob Giseburt <gise...@gmail.com> wrote:
> The bootloader is not completely needed, however, I have found that the
> bootloader does do a little setup that the firmware (erroneously) relies on.

Really? I'm surprised to hear that. I thought some of us were
experimenting with ISP-loaded (no bootloader) firmware in 2009 or
2010. Perhaps I've misremembered what we were fiddling with, but I
was definitely using my USBtinyISP to inject code. I've even recycled
spare extruder controllers as RGB LED controllers (because they have 3
built-in 12V MOSFET channels and screw terminals). I used no unusual
compile-time flags, no unusual init code, and I dropped the code right
on the Extruder controller with a USBtinyISP and avrdude - no
bootloader.

> This is a work-in-progress that I have had to put on the back burner, but
> it’s working for me (most of the time, at least):
>
> https://github.com/giseburt/Optiboot-for-Makerbot

Interesting.

> I have only really tested it on the Gen3 and Gen4 EC, as far as I recall.

I will have to have a deep look at that.

> Now, to get it to work, you have to kinda trick scons a little:
>
> scons platform=ecv22 baud="115200 -F" port=/dev/tty.usbserial-* upload
>
> You’ll need to change the port for your OS, but note that there is a space
> in quotes … that’s required. Optiboot looses the ability to verify the chip
> type, so you need avrdude to have a -F on the command, and I’ve found that
> above is the easiest way.

Easy hack as long as it's mentioned some place what it's for, in case
people forget or to help new people figure out why it's there.

Thanks for sharing the Optiboot stuff.

-ethan

[Jetty]

No, you can't do that.

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.

See this: http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader

However in reality, bootloaders make life easier, and they'd be the
last thing to dump, only if code optimizations didn't surfice.

[John D'Ausilio]

getting rid of the snake game would probably free a few bytes ...

[Jetty]

>getting rid of the snake game would probably free a few bytes ...

Yes it would. I've been avoiding removing it until I absolutely need
the space for the next new feature.
Mainly because somebody thought it was a killer feature to add in
addition to the 3 features "Monitor / Jog / Build",
so I didn't want to upset anyone, by removing it. :-)

Does anyone out there play it?

Interestingly, snake is also in the upcoming Replicator firmware.

[Dan Newman]

On 7 Mar 2012 , at 10:31 AM, John D'Ausilio wrote:

> getting rid of the snake game would probably free a few bytes …

Well, if I could play it WHILE printing, then maybe it would have
some value. Or, if it actually played out in real life on my
printer. (Maybe with some real obstacles to the extruder nozzle
like hitting the wiring harness connector.)

Dan

[John D'Ausilio]

success! Thanks, Cliff .. you gave me the necessary clues.

[sto...@gmail.com]

Ooops... Sorry, I was wrong! Not $5.00.....



Is $3.99 ---- Free Shipping.

Search eBay: USBASP USBISP AVR Programmer.

Before you start the motor boat - buts. Yes, it does work. I have one and have, granted only, programmed 11 bare chips and hand built Atmega boards it worked perfectly. Even re-programming too. I used someone's instructions. I think it was the original USBISP.

As for mine, I apparently paid a premium at Christmas of ~$5.49.

Hope it helps.

Oh, legitimately sorry for not posting a link. I am phone thumbling. But, I did check online before I replied here.

----- Reply message -----
From: "Ethan Dicks" <ethan...@gmail.com>
Date: Wed, Mar 7, 2012 12:57 pm
Subject: [MakerBot] Re: help setting up toolchain

To: "sto...@gmail.com" <sto...@gmail.com>
Cc: "make...@googlegroups.com" <make...@googlegroups.com>


On Wed, Mar 7, 2012 at 12:44 PM, sto...@gmail.com <sto...@gmail.com> wrote:
> Say, to you hard core coders and compiling types. Do you know if the
> bootloader is actually required to run YOUR bots?

No.  Not required, but given the hassles I remember from a few years
back, when CupCake firmware changed every few weeks, users had a wad
of problems updating their firmware.

No bootloader means that you can not use the USB-TTL cable to update
your firmware over the serial interface.  That's it.  It has no
bearing on the payload code itself.

> Could you disregard the bootloader and burn firmware directly...

Yes.

> with a $5.00 mcu programmer then just run?

[sto...@gmail.com]

@  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?

----- Reply message -----
From: "Jetty" <clell...@gmail.com>
Date: Wed, Mar 7, 2012 12:58 pm
Subject: [MakerBot] Re: help setting up toolchain

To: "MakerBot Operators" <make...@googlegroups.com>

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?

[Whosawhatsis]

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. 

[sto...@gmail.com]

@ jetty

Re: bootloader

Disclaimer: noob hackin

Hmmm. For several months I'd read that the bootloader is for IDE access not programs. I'd also understood that historically the bootloader causes a delay in running aps which the Optiboot sped through. I'd also read if no bootloader your application just runs. This is how commercial/consumer embedded applications are used in manufactured goods. No?

Many online instructions allude to - if you have the tools you just program the mcu chip. I think I burned a combined fade LED, blink LED, and waive servo sketch w/o boatloader. It was a few months ago and I was playing with my new expensive ($5.49) USBISP programmer on bread board aurduinos (ATmega328P). Instructions on the web state bootloader isn't needed if you do not need to use the IDE.

Disclaimer 2: The above was noob hackin recollections from a blur of lots of new mind numbing cool things and technologies. Maybe, I need to experience it all again? Meaning - I forget and might remember wrong. ;-)

----- Reply message -----
From: "Jetty" <clell...@gmail.com>
Date: Wed, Mar 7, 2012 1:28 pm
Subject: [MakerBot] Re: help setting up toolchain
To: "MakerBot Operators" <make...@googlegroups.com>

No, you can't do that.

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.

See this:  http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader

However in reality, bootloaders make life easier, and they'd be the
last thing to dump, only if code optimizations didn't surfice.

>I used no unusual
>compile-time flags, no unusual init code, and I dropped the code right
>on the Extruder controller with a USBtinyISP and avrdude - no
>bootloader.

[sto...@gmail.com]

Re: Snake

My son snuck past me while I was setting up a build and flicked snake on. My impressions: 1st ten second game - cute. The next few games with a kid under my arm pit fighting for arrow keys - annoying.

Suggestion: Drop Snake. Add bot features. Give link to game sketch online to load on a spare aurduino.

----- Reply message -----
From: "Jetty" <clell...@gmail.com>
Date: Wed, Mar 7, 2012 1:54 pm
Subject: [MakerBot] Re: help setting up toolchain
To: "MakerBot Operators" <make...@googlegroups.com>

[Whosawhatsis]

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.

[sto...@gmail.com]

@ 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.

Thanks.

----- Reply message -----
From: "Whosawhatsis" <whosaw...@gmail.com>
Date: Wed, Mar 7, 2012 3:22 pm
Subject: [MakerBot] Re: help setting up toolchain

To: <make...@googlegroups.com>
Cc: "Jetty" <clell...@gmail.com>

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 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?

----- Reply message -----
From: "Jetty" <clell...@gmail.com>
Date: Wed, Mar 7, 2012 12:58 pm
Subject: [MakerBot] Re: help setting up toolchain
To: "MakerBot Operators" <make...@googlegroups.com>

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 make...@googlegroups.com.
To unsubscribe from this group, send email to makerbot+u...@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 make...@googlegroups.com.
To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.

[Whosawhatsis]

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.

[sto...@gmail.com]

@ whosa and others.

OK, my sluggish memory recalls.

Per Arduino.cc and other's directions:

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" <whosaw...@gmail.com>
Date: Wed, Mar 7, 2012 3:50 pm
Subject: [MakerBot] Re: help setting up toolchain
To: <make...@googlegroups.com>
Cc: "Jetty" <clell...@gmail.com>

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.

On Wednesday, March 7, 2012 at 12:43 PM, sto...@gmail.com wrote:

@ jetty

Re: bootloader

Disclaimer: noob hackin

Hmmm. For several months I'd read that the bootloader is for IDE access not programs. I'd also understood that historically the bootloader causes a delay in running aps which the Optiboot sped through. I'd also read if no bootloader your application just runs. This is how commercial/consumer embedded applications are used in manufactured goods. No?

Many online instructions allude to - if you have the tools you just program the mcu chip. I think I burned a combined fade LED, blink LED, and waive servo sketch w/o boatloader. It was a few months ago and I was playing with my new expensive ($5.49) USBISP programmer on bread board aurduinos (ATmega328P). Instructions on the web state bootloader isn't needed if you do not need to use the IDE.

Disclaimer 2: The above was noob hackin recollections from a blur of lots of new mind numbing cool things and technologies. Maybe, I need to experience it all again? Meaning - I forget and might remember wrong. ;-)

----- Reply message -----
From: "Jetty" <clell...@gmail.com>
Date: Wed, Mar 7, 2012 1:28 pm
Subject: [MakerBot] Re: help setting up toolchain
To: "MakerBot Operators" <make...@googlegroups.com>

No, you can't do that.

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.

See this:  http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader

However in reality, bootloaders make life easier, and they'd be the
last thing to dump, only if code optimizations didn't surfice.

>I used no unusual
>compile-time flags, no unusual init code, and I dropped the code right
>on the Extruder controller with a USBtinyISP and avrdude - no
>bootloader.

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To post to this group, send email to make...@googlegroups.com.
To unsubscribe from this group, send email to makerbot+u...@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 make...@googlegroups.com.
To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.

[sto...@gmail.com]

@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" <whosaw...@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: "make...@googlegroups.com" <make...@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 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.

Thanks.

----- Reply message -----
From: "Whosawhatsis" <whosaw...@gmail.com>
Date: Wed, Mar 7, 2012 3:22 pm
Subject: [MakerBot] Re: help setting up toolchain
To: <make...@googlegroups.com>
Cc: "Jetty" <clell...@gmail.com>

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 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?

----- Reply message -----
From: "Jetty" <clell...@gmail.com>
Date: Wed, Mar 7, 2012 12:58 pm
Subject: [MakerBot] Re: help setting up toolchain
To: "MakerBot Operators" <make...@googlegroups.com>

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 make...@googlegroups.com.
To unsubscribe from this group, send email to makerbot+u...@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 make...@googlegroups.com.
To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.

[Whosawhatsis]

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.

[Joey]

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)

Joey

[Jetty]

>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:

G3Firmware/bootloader/hardware/arduino/bootloaders/atmega:

-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.

[sto...@gmail.com]

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" <clell...@gmail.com>
Date: Thu, Mar 8, 2012 12:29 am
Subject: [MakerBot] Re: help setting up toolchain
To: "MakerBot Operators" <make...@googlegroups.com>

[Jetty]

>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?

See this: http://wiki.makerbot.com/ec22

[Rob Giseburt]

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

>

[sto...@gmail.com]

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" <gise...@gmail.com>
Date: Thu, Mar 8, 2012 10:47 am
Subject: [MakerBot] Re: help setting up toolchain

[Rob Giseburt]

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

[B Stott]

Why not pin low on the board?

[Rob Giseburt]

Are you redesigning the EC?

  -Rob

[sto...@gmail.com]

Should I redesign the EC?

[Rob Giseburt]

If you are proposing adding resistors to the board, then it sounds like you're planning a redesign. 

  -Rob

[Jetty]

> 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.

[Joseph Chiu]

And please add MOVs or some other transient suppressors to protect the
inputs and the FET's!

[sto...@gmail.com]

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" <gise...@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: "make...@googlegroups.com" <make...@googlegroups.com>

[Dan Newman]

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

[W. Craig Trader]

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.

- C -

[Aaron Double]

Now why would the extruder need to compete with the motherboard playing the snake game?