Project: Teacup Firmware

Quote
Triffid_Hunter
what signal did you hook the leds to? step, dir, enable, min, max?

It's hooked up to Step for each motor. I am now assuming that the signal is too fast for my steppers to follow. might try with fiddling around with feedrates a bit more until I get some kind of response. It must be something straightforward "slap on your forehead" kind of thing as the physical setup works with sample code AND it seems that some kind of signal is coming out of my Arduino..
So close... yet so far away..

Quote
Architect
I found that using the MENDEL_TALK command line tool from the func.sh scripts helped out when I started. I don't know if you are running your host on a *nix box or windows, but if you are on a UNIX variant then the func.sh was very helpful in my early testing.

I am using Ubuntu so I'll try MENDEL_TALK later today to see if I can figure out what's going on.
So much for "Plug and Play"..

Triffid_Hunter Wrote:
-------------------------------------------------------

>
> Google "PID without a PhD" for tuning help
>

That helped.

My "heater" now seems to work with the values I posted earlier (I_limit = 384 not .375). I've never been happier to get an arduino to turn an LED on and off.

Thanks for the help.

Well.. Gentlepeople..
It was indeed a "slap on the forehead" moment today.
It seems that your wonderful software is indeed plug-and-play after all..
You just have to pay attention on what you plug and where before you play!!
I took apart the wiring and redid it again and it seems that I got the wiring for the sample code mixed up with the wiring from the actual setup and thus I had STEP and DIR swapped around..
Now it is just purring like a kitten with its belly full of warm milk! Beautiful!
Just have to play with my parameters a bit and we should be away laughing!

Apologies to you who replied with useful info to help me! Most appreciated, but my problems were sourced in my own stupidity!

Oh.. And @Architect.. That MENDEL_TALK in func.sh indeed works like a charm!

Thanks!

out of curiosity, what electronics are those of you who are successfully printing with this firmware using to control and power your heater element? I gather the rudimentary electronics would be Arduino PWM PIN -> MOSFET -> Heater with the temp_sensor and PID software controlling the PWM Pin. I assume this would be about the same for the heated bed as well.

-Arch

@edictor yeah Much prop to whomever wrote the MENDEL_TALK func, it made troubleshooting for me much easier. Let me know how you make out with repsnapper as I've made a few changes to its source code to make it a little more compatible with this firmware as well.

Warez for the Min1284p Controller Board.

Having set off to build and use the awesome FiveD on Arduino firmware for my minimalist DIY micro-controller board.

[aka47.adsl24.co.uk]

I found we were short a boot-loader. Unfortunately the ATMega1284P whilst being a drop in replacement for the Sanguino's 644P doesn't have a boot-loader ready to go and is arguably a little way off the beaten Arduino Path. I modified the Arduino IDE 22 source for the stk500v2 boot-loader and have managed to persuade this to load and work. You can get the modified source and a pre-compiled hex file (20Mhz crystal) here :-

[aka47.adsl24.co.uk]

I guess this is also a do-able upgrade path for owners of through hole Sanguino boards.

Whilst rummaging through the code for the stk500v2 boot-loader I noticed that the Makefile has clauses in it for a range of standard-ish boards.

Couldn't help but wonder if it wasn't worth doing something similar in the Makefile for 5DA if only for the standard off the shelf Arduino boards. A "make all" then could build hex files for them all in batch run. If heading this way i would be happy to contribute a section for my Min1284p board. (yeah I know not really a standard board)

Thoughts for what they are worth.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

edictoor: great to hear you got it working! I am thoroughly experienced with embarrasingly simple errors like the one you describe, I actually tell anyone entering the field to /expect/ errors to be something embarrasingly simple, until they've had someone else check their work- it's amazing how many times you can look at something, only to have someone peek over your shoulder and go 'umm..' because you're too familiar with what's supposed to be there to actually see what really is there

aka47, removing the config.h.dist file and replacing with config.h.gen3, config.h.ramps etc is already on my todo list A batch create for hex files is a great idea- then, so is including hex files with sensible defaults for these boards in the repository.

Now I just need to figure out a way to put the chip type in config.h, then extract it so I can tell gcc the proper target without alienating windows users who don't have stuff like grep, awk, perl etc lying around- any windows developers have a suggestion for this?

---

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

triffid sir.

it is worth having a rummage through the stk500v2 source and makefile.

atmel have #defines for each processor type. you can add multiple -D statments to the gcc invokation. each -D value statement is equivalent to a #define value in the target source.

if you combine the built in processor defines (auto defined by choosing ypur processor type) with a custom #define boardtype created via -D from the make file then you can create the target specific bits in the make file with code compiling from the source automagicaly for processor and custom board spec.

give each target a unique label in the make file and lump invocations together for them all under another so that it will batch build.

dunno if this helps or just muddies the waters......

when i get a mo i could have a first go and forward on some examples.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

jgilmore Wrote:
-------------------------------------------------------
> Have you looked at "correct" homing behavior vs.
> reprap standard behavior? i.e. correct behavior is
> to go to 0,0,0 even if a G92 command has moved
> 0,0,0 to some arbitrary locaiton. The more typical
> reprap behavior which is to interpret "go home" as
> "go mash the endstops and set current location to
> 0,0,0" which is technically all wrong, as it loses
> G92's information. I don't know the right answer
> to that one, but I think it looks like storing the
> real vs. temporary location information, and using
> a special M-code to hit endstops and reset
> position when if a G92 code has been seen (expect
> for a G92 E0)

Hmmm,
Do we have some sort of consensus on the expected behavior of G92 and G28? at work I generally would say "what does the F'ing BRD say cuz that's what I'll code!"
8-D usually in a really pissed off voice cuz the Business says "that's what we wrote in the document but that not what we really want"... I only ask because I am curious as to what the intended use would be. I do not see any use for home other then at the start of a print job and at the end of a print Job. does anyone require something alongthe lines of head cleaner positioning or something bizarre like that? that is the only thing I can think of for needing a reliably repeatable hardware homing position.
for G28 what I have is send X and Y -250mm when you are done you will be Home 0,0 (the endstops will not allow the axis to move beyond itself) then as it was already mostly written this way I do the same for the Z axis.
I still would like to implement the accuracy aspect of once home do it again slowly. but I have more hardware building to do before I get into tuning further.

Architect Wrote:
-------------------------------------------------------
> Hmmm,
> Do we have some sort of consensus on the expected
> behavior of G92 and G28? at work I generally would
> say "what does the F'ing BRD say cuz that's what
> I'll code!"
G92 is currently used (by some) to zero the extruder position after each layer.

More traditionally, it's used to re-use g-code. You slice a part located just off of 0,0,0. Then if you want to print it as a bed of parts you move over, set home, and send the same g-code file. I don't think much of that is actually being done with the reprap, as people want to print all parts on the bed in layers to avoid having to think about the extruder crashing into existing (already printed) parts.

I think it is commonly used as part of the setup for printing a single part - jog the machine to where you want to print, then set home and print.

Part of the problem here is that the behavior of G28 doesn't work if you are using G92 on any axis other that E. The 'official' 5D firmware interperets G28 to always mean "go hit the endstops. If X Y or Z are specified, hit only those endstops but ignore any axis position specifed. Set position to 0 on each axis where we hit the endstops." Thus negating any G92 that was done previously. Absolute machine position is not tracked separately from perceived machine position as set with G92.

Which is WAY different than EMC2 does. It says G28 means "go to (G0) position specified (if any) then go to pre-specified position" i.e. G28 is G30 if you specify an axis. And if you specify G28.1, it sets the "pre-specified position" to whatever you want, though it does start out as 0,0,0. G30 behaves the same, but stores it's "pre-specified position" separately. Also, the machine will go to the position specified by G30 before changing tools, if that behavior is specified in the .ini file. In any case, G92 specified coordinate systems are preserved.

G28 is commonly used either only at the start of a print to avoid having to jog the machine to where you want it, when the g-code is already set up to put the part where you want it. Or after each layer, compensating for the occasional skipped step while building.

I think that the "hit the endstops and re-zero" command should be separate from "go home." I've coded M135 for that, though I haven't coded it for being able to hit the endstops only on the specified axis. That would be very useful for those who want to re-zero between layers, as they don't have to wait for the (much slower) z-axis to hit zero and come back.

I think it's also reasonable to make G28 simply call M135 if G92 hasn't been seen, and behave like "G0 X0 Y0 Z0" otherwise. M135 should reset only the physical machine coordinates, the G92 specified offset from that shouldn't be changed. G30 I think should be an alias for G28.

Actually, just looked at Triffid's branch, and M135 is used for selecting which heater you're talking to. Guess I should code it for M136 instead?

> 8-D usually in a really pissed off voice cuz the
> Business says "that's what we wrote in the
> document but that not what we really want"... I
> only ask because I am curious as to what the
> intended use would be. I do not see any use for
> home other then at the start of a print job and at
> the end of a print Job. does anyone require
> something alongthe lines of head cleaner
> positioning or something bizarre like that? that
> is the only thing I can think of for needing a
> reliably repeatable hardware homing position.
> for G28 what I have is send X and Y -250mm when
> you are done you will be Home 0,0 (the endstops
> will not allow the axis to move beyond itself)
> then as it was already mostly written this way I
> do the same for the Z axis.

I've done business software development. Requirements aren't. And here we have the same thing. Makerbots don't have endstops. Those who do have endstops (mendels) are either using them only for repeatability (avoiding joging the machine to where it needs to be) or are possibly using them to compensate for underpowered steppers or other problems. But we don't really know who is using which for what. Best to program mostly for whatever we think is right and reasonable, after doing due diligence looking and what current firmwares/machines do.

> I still would like to implement the accuracy
> aspect of once home do it again slowly. but I have
> more hardware building to do before I get into
> tuning further.

I hear you there - my laptop died, and I had to go back to my old laptop, only to discover that it doesn't have a working USB port. So no actual testing for me right now. It has a serial port, I may try that. Or I have another that I think just needs its power connector re-soldered. I hate yak shaving, but it seems to be what my life consists of right now.

---

--
I'm building it with Baling Wire

OK

Here's the rules I added to the make file for stk500v2

############################################################

# Jan 9, 2011 Adding 20Mhz 1284P support

# www.kirbyand.co.uk

# avrdude: Device signature = 0x1e9705

# avrdude: safemode: lfuse reads as F7

# avrdude: safemode: hfuse reads as D8

# avrdude: safemode: efuse reads as FD

# avrdude: safemode: lockbits 3F

############################################################

mega1284p: MCU = atmega1284p

mega1284p: F_CPU = 20000000

mega1284p: BOOTLOADER_ADDRESS = 1E000

mega1284p: CFLAGS += -D_MIN1284P_BOARD_

mega1284p: begin gccversion sizebefore build sizeafter end

mv $(TARGET).hex stk500boot_v2_mega1284p.hex


When invoking make I would "make mega1284p" the begin part is specific to the stk500v2 process. MCU is the gcc -m processortype option that will in turn cause the processor specific #define to become defined so we can test for it (ie __AVR_ATmega1284P__ ) this can then be used as a conditional define to add or remove sections of code from the compilation. F_CPU is the speed of the clock for the device, BOOTLOADER where the boot-loader starts in memory (needs to match the fuses, may not be needed for 5DA as the bootloader programming already took care of fuses) The CFLAGS directive adds the -D_MIN1284P_BOARD_ to the gcc invocation so that it is included in the source just as if it had been hard coded as #define _MIN1284P_BOARD_. This is the tag that says what board the device is in and allows further board specific selection of the code using #ifdef directives.


Below is an excerpt from the C file showing an example of conditional compilation


#ifdef _MEGA_BOARD_
#define PROGLED_PORT PORTB
#define PROGLED_DDR DDRB
#define PROGLED_PIN PINB7
#elif defined( _BOARD_AMBER128_ )
//* this is for the amber 128 [www.soc-robotics.com]
//* onbarod led is PORTE4
#define PROGLED_PORT PORTD
#define PROGLED_DDR DDRD
#define PROGLED_PIN PINE7
#elif defined( _CEREBOTPLUS_BOARD_ )
//* this is for the Cerebot 2560 board
//* onbarod leds are on PORTE4-7
#define PROGLED_PORT PORTE
#define PROGLED_DDR DDRE
#define PROGLED_PIN PINE7
#elif defined( _PENGUINO_ )
//* this is for the Penguino
//* onbarod led is PORTE4
#define PROGLED_PORT PORTC
#define PROGLED_DDR DDRC
#define PROGLED_PIN PINC6
#elif defined( _ANDROID_2561_ ) || defined( __AVR_ATmega2561__ )
//* this is for the Boston Android 2561
//* onbarod led is PORTE4
#define PROGLED_PORT PORTA
#define PROGLED_DDR DDRA
#define PROGLED_PIN PINA3
#elif defined( _MIN1284P_BOARD_ )
//* this is for the DIY 20Mhz 1284p min1284p board
//* www.kirbyand.co.uk, a sanguino upgrade
#define PROGLED_PORT PORTB
#define PROGLED_DDR DDRB
#define PROGLED_PIN PINB0
#else
#define PROGLED_PORT PORTG
#define PROGLED_DDR DDRG
#define PROGLED_PIN PING2
#endif

The above example shows conditionally selecting the Debug LED port according to which Board and in one case processor type is selected.

So in summary the combination of Board type, Processor type, Clock speed etc. can be defined in the Makefile and the source written so as to cover all the usual Arduino suspects.

Eg a Duemilanove with either an ATMega328P or an ATMega168P, a Sanguino original with a 644P & 16Mhz Crystal or an upgraded one with a 1284P & 20Mhz Crystal etc etc etc.

Hope this illustrates the method a little better...

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Triffid_Hunter Wrote:
-------------------------------------------------------
> spaztik Wrote:

> > Is this correct? I really don't know what is
> going
> > on here with P I D and I_limit, is there
> something
> > I can read to help me understand?
> >
> > Edit: After thinking about this for a while, I
> am
> > wondering if I_limit should get divided by 1024
> or
> > not, because it is not a factor (like p_factor,
> > I_factor and D_factor). Also because 384 * 0.5
> =
> > 192.
>
> Sounds exactly right to me
>
> Google "PID without a PhD" for tuning help
>

If I haven't said so yet, You All Rock! this saved me much work and figuring out.
I had a thought, while testing and figuring out how PID was implemented and going through this thread.
Perhaps it would be helpful if someone(maybe me) were to catalog this entire thread into a Firmware roadmap.
for example:
PID
-> Overview
-> theories and implementation
-> files
-> settings
-> config
-> gcodes
-> testing FAQs
-> Q&A
-> further readings

I think soon I will be ready to actually use this code for printing. that is once my makergear order gets here, or I learn how to stop breaking my .3mm drill bits.
I owe a few of you a beer (or soda...)
-Trout

Well..
I just binned both Repsnapper and Reprap Host in favour of the latest version of ReplicatorG.
It is such a breath of fresh air in the arena of Host Software. Completely clean and logical to use. Easy to adapt to whatever you're running.
ReplicatorG now has Skeinforge embedded into it so really a one stop shop.
ReplicatorG now sends commands to FiveD on my Arduino 168 Diecimila that runs 3 Easystepper Boards which in turn run my steppers. Couldn't be any more straighforward..
I'd recommend it to anyone here who is looking for Host software to run their 5D machine..

Hi,
I am trying to use Triffids 5D on a 368p
I am using windows with eclipse and avr-gcc toolchain.
Code compiles fine.
I can tallk to the firmware through any number of terminal programs but when trying to connect with repsnapper it just sends M105 to get temp readings and then times out. I have checked the comport and all its settings and as I get no problems with term progs using xon/xoff or not I am really baffled as to why this host program will not connect?

Ideas anyone?

It maybe the Start vrs start issue. Change the capitalization in the firmware and try again.

Using ReplicatorG together with FiveD seems to work in first instance.. But my question now is whether there is some kind of max buffer that I am overrunning while sending from ReplicatorG to FiveD?

The following Gcode works:

G21
G1 X0 Y0 Z0 F2200
G1 X100 Y0 F2200
G1 X100.0 Y0 Z20.0 F2200
G1 X0 Y0 Z20 F2200
G1 X-10.4 Y0 F900.0
G1 X0 Y0 F2200
G1 X10.4 Y-57.4 F900.0
G1 X0 Y0 Z0 F2200
G1 X100 Y0 F2200
G1 X100.0 Y0 Z20.0 F2200

The printer makes all the correct movements and the Host software responds at the end with saying that it has finished building. All good.

But as soon as my Gcode becomes 1 or 2 lines longer:

G21
G1 X0 Y0 Z0 F2200
G1 X100 Y0 F2200
G1 X100.0 Y0 Z20.0 F2200
G1 X0 Y0 Z20 F2200
G1 X-10.4 Y0 F900.0
G1 X0 Y0 F2200
G1 X10.4 Y-57.4 F900.0
G1 X0 Y0 Z0 F2200
G1 X100 Y0 F2200
G1 X100.0 Y0 Z20.0 F2200
G1 X0 Y0 Z20 F2200

Then the printer only runs up to the line before the last one and then stops. The ReplicatorG software is just frozen and I have to force close it.

Is there a maximum buffer size that I can alter somewhere for FiveD?
And if there is anyone here with ReplicatorG experience, is there a way to control the sent buffer size?

I have a one char fix against the master branch.

Line 57 (or so) of analog.c reads

     AIO0_DDR &= ANALOG_MASK;

It should read:

     AIO0_DDR &= ~ANALOG_MASK;

I've been chasing crazy behavior that was caused by this - things like an axis starting out in the wrong direction and then turning around and going in the correct direction, all in a single simple g0 motion. Attach a scope probe and the problem goes away, etc.

Architect Wrote:
-------------------------------------------------------
> It maybe the Start vrs start issue. Change the
> capitalization in the firmware and try again.

I gave this a go ( did not work) and then worked out the following.

Any new connection to the 328 forces a reset on this setup. It seems to take ~4-5 secs to get past the bootloader, initialise and send the [sS]tart\nOk.

Repsnapper times out in about 5 secs. Wondering if it never notices the start before it gives up.

petedee Wrote:
-------------------------------------------------------
> Architect Wrote:
> --------------------------------------------------
> -----
> > It maybe the Start vrs start issue. Change the
> > capitalization in the firmware and try again.
>
> I gave this a go ( did not work) and then worked
> out the following.
>
> Any new connection to the 328 forces a reset on
> this setup. It seems to take ~4-5 secs to get past
> the bootloader, initialise and send the tart\nOk.
>
> Repsnapper times out in about 5 secs. Wondering if
> it never notices the start before it gives up.


Finally got it to connect if I turned validation off. I was wondering why it was sending M105 before a connection had been established, this is obvious now that is how it validates the connection.
Although there is no outward appearance that you have connected (apart from the green light remains on) my motor enabled lines went active when I sent G1 X10.0 manually.

Hello,

I am currently porting the FiveD on Adruino firmware to the Gen7 hardware and I am having a lot of problems.
I started with the RC2 because Traumflug advised me to use them. But I had to notice that there are MANY bugs, untested code and missing features.
So my question is: What features are supported by the current version and which one is the current version? There are so many branches that I don't know which one to choose. And I think for a newbe this would be a unsolveable problem
Is there any documentation of the different branches?
The features I am missing most are support for a heated bead and support for RepRaps with VERY high STEPS_PER_MM_* values like our RepStrap with 3600 steps per mm.
And Traumflug told me that there is no support for Adruino IDE in the current master branch. Why not? This is a very bad fact for a newbe because not everyone has a ISP programmer like me.

OK
some simple facts.

Fact 1.

If you have an Arduino compatible board with an Arduino compatible boot-loader (I count Sanguino in this category) then you don't need a hardware programmer. Simply because the boot-loader emulates one and the device fuses were set at the point this boot-loader was programmed into the device using a hardware boot-loader.

If you have an at-mega based micro-controller board without an Ardunino compatible boot loader then you either need a compatible boot-loader or a hardware device programmer.

Fact 2

If you have an Arduino compatible board with an Arduino compatible boot-loader (I count Sanguino in this category) then you don't need to concern yourself about the at-mega devices fuse settings because they have already been set.

If you have an at-mega based micro-controler board without an Ardunino compatible boot loader then you you have to set the devices fuse settings at the point you program it with a hardware device programmer either with firmware or a boot-loader.



Guys, simple facts that cannot be dodged, avoided or skirted around. If you have not taken into account the above no amount of messing with the A5D code or compilation will help you. Sort these first.

Just in case the last statement was missed, Sort these first.

To burn A5D code you need either a hardware programmer and the correct fuses for your device or a device pre programmed with a boot-loader (arduino, stk500v2, adaboot, atmel etc) that emulates a hardware programmer, programmed into the device along with the fuse settings.

The build and make files although they don't state as much need this. This is the law according to atmel.


Hope this helps

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

madscifi Wrote:
-------------------------------------------------------
> I have a one char fix against the master branch.
>
> Line 57 (or so) of analog.c reads
> AIO0_DDR &= ANALOG_MASK;
> It should read:
> AIO0_DDR &= ~ANALOG_MASK;
> I've been chasing crazy behavior that was caused
> by this - things like an axis starting out in the
> wrong direction and then turning around and going
> in the correct direction, all in a single simple
> g0 motion. Attach a scope probe and the problem
> goes away, etc.

wow, I've been looking for that for ages, thanks! I think that may have been causing quite a number of the strange bugs that people have been seeing. I swear I've looked at that file a hundred times and gone straight past that! Never encountered it directly myself because my electronics use the max6675 digital sensor and totally bypass the whole analog subsystem. commit pushed to master


Jacky2K Wrote:
-------------------------------------------------------
> So my question is: What features are supported by
> the current version and which one is the current
> version? There are so many branches that I don't
> know which one to choose. And I think for a newbe
> this would be a unsolveable problem. Is there any
> documentation of the different branches?

for a while, release-candidate-triffid is where most of the development was having, but that was too confusing so I merged that, release-candidate and master together. now master is the primary branch. Ignore the rest unless your curiosity gets the better of you.

fived_v2 is me starting a rewrite based on everything I've learned from the current version. I will continue developing the current version until v2 is ready to print.

As for features, all the new fancy stuff (eg arbitrary temp sensors/heaters for your heated bed/heated chamber/2nd extruder) came in when I merged everything into master.

Why do you have such high STEPS_PER_MM? 3600 is outrageous, are you microstepping on Z for some reason? you will never get anywhere near <0.3um precision from the mechanics unless you've bolted an extruder to a rather elaborate mill. I don't think the current version can support that simply due to the numeric precision involved, maybe v2 will be better since I've decided that using a little floating point in the input stage is a good idea.

---

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

Triffid sir,

Been thinking about the config files and perhaps having a config.h per board is'nt necessary.

If the -D value directive from the make file specifies a board. then the source can pick up the board tag in config.h using #ifdef's.

This keeps the make file simpler and moves all the board specifics to config.h

Where one config.h fits all with compilation being conditional on the board tag named in the make file.

You end up with a compile for board u like setup with no editing necessary, just invoke "make boardulike"

or maybe "make everything" to make the binaries for every supported board type.

I don't mind contributing some effort towards this is this is a direction you guys wanna go in.

I guess going this route makes it easier to extend existing board defs to take in new board defs for those that want to contribute this.

I don't have your current email (lost during upgrades etc) if you are interested in going this route PM me your email and I will email the diffs as I work.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> Triffid sir,
>
> Been thinking about the config files and perhaps
> having a config.h per board is'nt necessary.
>
> If the -D value directive from the make file
> specifies a board. then the source can pick up the
> board tag in config.h using #ifdef's.
>
> This keeps the make file simpler and moves all the
> board specifics to config.h
>
> Where one config.h fits all with compilation being
> conditional on the board tag named in the make
> file.
>
> You end up with a compile for board u like setup
> with no editing necessary, just invoke "make
> boardulike"
>
> or maybe "make everything" to make the binaries
> for every supported board type.
>
> I don't mind contributing some effort towards this
> is this is a direction you guys wanna go in.
>
> I guess going this route makes it easier to extend
> existing board defs to take in new board defs for
> those that want to contribute this.

sounds great, but I think it will be easier to manage with lots of config.h.boardulike- may make the Makefile a shade more complex but making slight alterations and creating new boards will be simpler.

Can we get make to automagically look for config.h.blah when we make blah instead of needing a rule for each one? that way, copy, rename, edit, make is all that's necessary to support a new board, or create a custom config

The only part I'm not sure about is how to extract the correct target cpu for gcc from the config in a way that works on windows. It's not enough to provide the relevant defines, gcc needs to have the target cpu passed on its commandline so it can pass that on to binutils. It's trivial in linux, egrep -o would probably be sufficient (awk, sed, perl can do it too) but I don't want to totally alienate windows users. perhaps we can just do it with grep, and then try to wrangle the files into some shape that will compile in the various windows IDEs.

> I don't have your current email (lost during
> upgrades etc) if you are interested in going this
> route PM me your email and I will email the diffs
> as I work.

fork, edit, commit, pull request

---

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

Quote
Triffid_Hunter
sounds great, but I think it will be easier to manage with lots of config.h.boardulike- may make the Makefile a shade more complex but making slight alterations and creating new boards will be simpler.

I am not a software developer, but I can put my two cents in as a User..
I like the idea of being able to just make a new config file for a new board rather than having to set settings in the program files. That way, some more comments about what does what can be added all centrally..
ReplicatorG works on the same principle. Each Machine has it's own config file. Of course, there the file to be used gets selected in the GUI by the User in a drop down list.

Again.. just my 2 cents..

Just a heads-up, I submitted a bunch of patches tonight:

- Fixed a bug where the intercom functions aren't present if GEN3 isn't defined.
- Added a config.h.ramps file
- Added heated bed support (M105 reports B: temperature, M140 sets bed temp according to RepRap M-codes)

For the heated bed, I added a #define in config.h that lets you specify which heater is your bed heater.

As for the configuration route, I really prefer config.h.ramps, config.h.gen3, and so on. I tried hacking a #RAMPS define into the config.h.dist file but all the conditionals got crazy. Also, my personal preference is to keep as much outside of the Makefile as possible for Arduino n00bs.

plasmator Wrote:
-------------------------------------------------------
> Just a heads-up, I submitted a bunch of patches
> tonight:
>
> - Fixed a bug where the intercom functions aren't
> present if GEN3 isn't defined.

I thought that was the point - GEN3 is the only electronics set that has a seperate extruder controller with RS485 coms to it. I think. You don't need those functions unless you have GEN3, and you don't want them. Part of the point of GEN3 was the original reprap firmware is so inefficient that it was getting overloaded handling temperature control as well as four steppers. Part of the point of this firmware is that it fixes the original firmware's bloat and inefficiencies to the point that it can easily handle all of it, and handle MUCH higher step frequencies, and serial coms, at the same time. Number of pins becomes the limitation as to what you can handle with your microcontroller, rather than speed and code space. OK, code space is still something of a concern. The GEN3 define is a way of making this firmware work on that hardware configuration, but it's the only situation in which coms are needed.

Or do you need the intercom functions for some reason in a different configuration?? Do share.

---

--
I'm building it with Baling Wire

Well actually I probably didn't explain thoroughly. The intercom functions are called from temp.c. If GEN3 isn't #defined, the functions in intercom.c aren't included and I get a compile-time error. So I applied the following patch to temp.c:

commit c69cfb3551c5f4cca099897a11564da8f1fe9609
Author: - 
Date:   Sun Jan 23 20:34:40 2011 -0600

    Fixed for when GEN3 isn't defined.

diff --git a/temp.c b/temp.c
index c177038..83d636c 100644
--- a/temp.c
+++ b/temp.c
@@ -214,6 +214,7 @@ void temp_sensor_tick() {
 					break
 				#endif	/* TEMP_PT100 */
 
+				#ifdef GEN3 //If GEN3 isn't defined, these functions are undefined.
 				#ifdef	TEMP_INTERCOM
 				case TT_INTERCOM:
 					temp = get_read_cmd() << 2;
@@ -224,7 +225,8 @@ void temp_sensor_tick() {
 
 					break;
 				#endif	/* TEMP_INTERCOM */
-				
+				#endif
+
 				#ifdef	TEMP_DUMMY
 				case TT_DUMMY:
 					temp = temp_sensors_runtime.last_read_temp;

Maybe I did something stupid, but it fixed it for me?

plasmator Wrote:
-------------------------------------------------------
> Well actually I probably didn't explain
> thoroughly. The intercom functions are called
> from temp.c. If GEN3 isn't #defined, the
> functions in intercom.c aren't included and I get
> a compile-time error. So I applied the following
> patch to temp.c:

Point taken, although the theory is that if you're not using the GEN3 intercom, you don't have TT_INTERCOM defined which also fixes this

---

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

Guys

----snip----
The only part I'm not sure about is how to extract the correct target cpu for gcc from the config in a way that works on windows. It's not enough to provide the relevant defines, gcc needs to have the target cpu passed on its commandline so it can pass that on to binutils. It's trivial in linux, egrep -o would probably be sufficient (awk, sed, perl can do it too) but I don't want to totally alienate windows users. perhaps we can just do it with grep, and then try to wrangle the files into some shape that will compile in the various windows IDEs.
----snip----

The short answer is you don't. This is why the cpu definition lives in the makefile or is set from the build environment rather than the source. It works cross platform. What-ever the platform. (Mac too). I guess this is exactly why arduino and the AVR IDE do it this way. The minimum you can get away with in the make file as I understand it is the mcu definition, frequency, fuses and a board definition. If you are writing a boot-loader section you need the load address too and your fuses select whether to boot from the boot-loader or the start of program memory.

Re multiple .h files.

Sure you can go this route you are still going to need conditional includes/compiles in your C file though.

Consider looking forwards in time. There will come a point where folk using larger chips memory wise will be adding features that then make the compiled set too large for the smaller devices. Conditional excludes in the main .C file will be necessary to chop out those features for use of the rest on smaller boards. Either that or fork the project into a small device firmware and a large device firmware. Once you have two projects to maintain the work has doubled and there is greater chance of getting out of step. (Inconsistencies)

If you want to factor out all the differences into separate per build files. You are going to need to look at what you do with the .c files as well for consistency.

Having multiple .h files can also mean a greater maintenance overhead. (as does multiple files where ever.)

If you want to keep the .c file all in one and rely on conditional compile than you may as well have just one conf.h. Consistency is good.

ReplicatorG can have files per machine purely because it uses a driver model and each file is the driver. The rest of the code is common only each driver is machine specific.

For a user that would just use a pre-compiled binary or make the source as is number of files is irrelevant. They just want it to work.

For the maintainer though, changes that are relevant to a number of boards need the maintainer to modify an equal number of .h files. More work and greater probability of introducing inconsistencies.

My advice with config.h is keep it in one.

or, if maintainer masochism is your thing

Keep everything common in config.h and conditionally include board specific headers using the board tag -D set from the make file.


Keeping the project together unfortunately means adding complexity somewhere, one way or another. Some routes make more work than others. Some routes are a blind alley.


Thoughts for what they are worth.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Frequency can be set by the board definition. Fuses and bootload position by the mcu definition.

Probably what we'll end up with is that the board definition files will define pins and the features that board needs, and does some sanity checks (is the mcu right for that board?) There would be a seperate file that looks more like our current config.h.dist with each feature and pin defined with a comment, probably call it config.h.custom. Those like me who have a non-standard setup will define the MCU appropriately, define the board type as "custom", and edit the custom config file. If/when that setup becomes standard, it'd just get its name changed and be automatically included by config.h.

And then the central config.h tests the board definition and #includes the correct config file.

I like that setup, I think it'd be fairly simple to keep straight.

I think config.gen3.h would help those whose operating systems or IDEs rely on the extension to determine file type. config-gen3.h or the like may be even better, with no extra period to confuse things for those poor sods whose operating system likes to hide the file extension. Obviously, we'll need atmel168.h atmel328p.h etc as well. Probably make it exactly like the mcu define to make the include easier.

One concern I do have is multiple architectures. Right now we support only atmel cpus, but that will change fairly quickly. Either Casinho will publish his ARM modifications and we'll merge them, or I'll give up on him and do it myself. Either way, some of the initialization routines will have to change drastically. Somebody will eventually want PIC as well, more than likely.

I don't know if it'd be better to have the initialization routines horribly chopped up with #ifdefs, or completely different routines included one after the other with #ifdefs, or the makefile compile completely different C files. Cross that bridge when we come to it I guess.

---

--
I'm building it with Baling Wire