Project: Teacup Firmware

> Frequency can be set by the board definition.

Yup I agree. I can't see why this cannot live in config.h.

> Fuses and bootload position by the mcu definition.

Unfortunately not.

Fuses and boot-load position are board/implementation and boot-loader specific. You can have a range of boards all using the same device (mcu setting) with different clock options and different boot-loaders that need different settings for these options.

For example the stk500v2 boot-loader is bigger than the adaboot boot-loader. Being larger means the Boot-loader section must be larger hence it's start address is different. But I have two otherwise identical boards with identical devices and clock sources but different boot-loaders.

These are best associated with the board definition in the appropriate file/s and an additional board def created with some usefully descriptive name.

With a single file and solely conditional compilation you can add to the "#ifdef (macro1)" statment using" || (macro2)" etc. So that the same statement is used for a number of configurations. very compact and easy to see what is happening. No multiple copies to maintain. very flexible.

With the multi file route you have to add more files for more defs and and then maintain them. As well as using the conditional compilation statements to conditionally include.

If you must go down the multi .h file route then I agree something other than multiple "." is a good move not all OS's can cope well with those sort of file names.

Re supporting other processors, we are not using high level languages here and we are manipulating hardware directly so the same source code is very unlikely to support several architectures simultaneously. A project fork/split together with a very careful factoring out of functions into libraries is about as good as it will get.

Multi Architecture support from one code base is only really doable with a higher level language set and/or a hardware abstraction layer. (This is why OS's and EMC2 have a HAL "Hardware Abstraction Layer") This sort of pain is not really worth the gain.

You can get away with similar architectures and the very heavy use of conditional compilation (look at some linux source for examples, not really suitable for anything but experienced developers)

The atmel ATmega's are very different devices when you look at them, unlike their newer cousins the xmega's. Their is quite a lot of differences between devices. The Analogue sections are a case in point some devices have multiplexing some don't. We are arguably pushing at the boundaries of one code base fits all as it is, we get away with a lot through conditional compilation and rely on the devices processor core being identical.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> Multi Architecture support from one code base is
> only really doable with a higher level language
> set and/or a hardware abstraction layer. (This is
> why OS's and EMC2 have a HAL "Hardware Abstraction
> Layer") This sort of pain is not really worth the
> gain.

I know it goes against the philosophy of 5DA firmware, but we're using FreeRTOS in the ARM-based RepRap electronics project I'm working on. Probably too bulky for a basic Arduino, but I think we'll be able to really easily allow our stuff to run on the Mega platforms as a result.

Yeah I agree,

With FreeRTOS you are effectively adding an abstraction layer and API. All with a code size overhead that would rule out the lower end ATmegas ie 168 etc.

t looks like an exciting project though and definitely worth doing. I am waiting for someone to turn out a linux (RT extended) controller using one of the NXP Processors.

It is potentially do-able to lash up some form of hardware abstraction with a whole sack full of macro's. I would struggle to follow this and am sure it would pretty much bar most potential contributors from understanding quite what is happening.

I fancy an FPGA implementation too, at least for the move controller parts.

Ah well back to conquering the world a nibble at a time.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

So onto how to conditionaly include configs.

In config.h which is included in the source.

----- snip start of of config .h ------

/

* common to all includes*/
#include wibble
#include blah

/* put all the common stuff here */
#define something
#define somethingelse 0x00


/* put conditional includes here last so you can refer to anything you needed pre defined from the common stuf */

#if defined ( _BOARDULIKE_)
    #include "config_boardulike.h"
    #define SIGNATURE_BYTES 0x1E9307 
elif defined (_OTHERBOARDULIKE_) || (_EQUIVALENTBOARD_)
     #include "config_otherboardulike.h"
#define SIGNATURE_BYTES 0x1E9403
#else
	#error "No board definition available, try again with one selected"
#endif

------ Snip end of config.h ---------

Note :-

_BOARDULIKE_ , _OTHERBOARDULIKE_ and _EQUIVALENTBOARD_are instantiated as applicable from the boards defining rules from the Makefile using the -D gcc directive.

The second clause uses the same config file for two different boards that are suficiently similar to be considered the same from a software view.

Hope this helps

Edited 2 time(s). Last edit at 01/25/2011 11:57AM by aka47.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Bum the forum has messed the code by losing the indentation, but I guess you get the method.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

ah so you're suggesting using a staging file for config that pulls specifics in from other places? I thought you were suggesting something that resembles avrdude.conf. I can see a staging file working, to pull in appropriate combinations of config-mendel.h, config-huxley.h, config-ramps.h config-gen3.h, config-mega1280.h, config-mega168.h etc.

So now we need to work out which things go together, and which things need to be separated.. mechanical robot seems to set build volume bounds, and board seems to set steps/mm in enough situations to have those in a board definition file along with cpu and clock options. Bootloader size can probably go in board def, although we can suggest optiboot if space gets too tight.

We still need to make it fairly easy to customise a lot of the options since there are so many machines that simply don't fit in any standard pigeon holes- perhaps an override section in the master staging file or something?


As for working on arm, I think not much needs to change in the core, mostly it's the interrupts and I/O that will need tweaking, and some additions to make use of arm's improved capabilities.

---

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

With ARM the issues (Same with PIC's) are the peripherals. They are quite different on other micro-controlers.

Code that merely does processing can be tweaked for endienness etc and different data representations again through macros.

However the registers, bits, setup and functions of the peripherals are quite different.

This is why folk go for a HAL & API and the bloat it introduces, purely because there is no other way to cope with the complexity of multi architecture particularly where peripherals and IO are concerned.

On the question of config.h. I am suggesting that making it into a suite of files is a lot of work and introduces a maintenance overhead and lack of flexibility that will become apparent in time. Maybe so much so that there will be those that wish they hadn't done it.

Where folk are insistent that this is what they must do the next best (still with the same issues) is to use selective inclusion withing config.h to bring in the config files. Selection being driven by the Board-type macro.

Consider the following hypothetical situation that illustrates the point. (I appreciate it will be unpopular)

The 1284P is a device that I am currently using. Its memory layout is arguably the same as the 1280 but the IO and peripherals are identical to the 644P. (I know this from hacking out configs in separate files for the Amforth project)

If you have config for the 1280 in one file and config for the 644p in another It is not possible to conditionally select the bits needed for each from the code as presented. Selecting one config excludes the other.

OK you say, the solution then is to create a whole new config file dedicated to the board that has the 1280P in it, by copying the other two and hacking out the bits that are not relevant. (Have a count up as to how many board files this will start at and add some for growth, ouch)

A little later on a bug is found in the 1280 specific configuration and fixed for the 1280. Unfortunately we created a new config file and the bug fix which is also relevant to the 1284P has not been made into the 1284P config. (the person working on the 1280 was not interested int he 1284P and anyway did'nt know of the way the device measured up to its siblings, it would be unreasonable to expect that they did)

You have to change all the definitions in all the config files that are relevant and remember which are. If you don't, you will end up with random implementation specific bugs for stuff you already fixed. To do this you have to be a device interchangeability expert as well as knowing every inch of the code and be very picky about the fine detail.

Alternatively keeping it all I one file with the relevant singular section of code shared between several configs through conditional compilation means that you fix it once in one place and all the rest automagicaly benefit. Easy maintenance you don't have to be a device expert to work out the inter-device commonalities and code dependencies. It is implicitly coded in your source. The only developer that needs to know about the commonality etc is that one that is contributing the additional config. They would need to know this whether they crafted a separate file or added compilation conditions. But only really for the device they were working with. Their work though is automaticaly shared with others whose devices share common code.


In short I am happy to go with the flow and will be hacking code for the min 1284P board which ever way. I won't be maintaining the code base so won't have to worry about the rest. From a purely selfish point of view I don't want to see the code base become unmanageable. Ultimately though does a bee care, much less the flower?

---

Necessity hopefully becomes the absentee parent of successfully invented children.

And here I was assuming it would look like:

#define BOARD_CONFIG config##BOARD.h
#include

or

#include

or some such. I know that GCC has facilities for doing that sort of thing, but I probably have the syntax wrong. We're tied to GCC anyway (both ARM & ATMEL, perhaps not PIC?) so there's little (or no?) reason not to use GCC extensions.

I do like the idea of chopping configs up smaller as needed though.

For aka47's example, the guy who wants to create config_1284p.h would chop the relevant sections out of config_644p.h and config_1280.h and put them in separate files called ??? and reference them from config_644p.h and config_1280.h, then include them from config_1284p.h

Sounds reasonable, if a bit complex. Code divers would have fun, tunneling three #includes down to find the actual definitions. Probably better than copying code, and getting the "fixed here but not there" bugs aka47 is pointing out. At least they'd all be named "config???.h" so you could tell you where in the same area.

---

--
I'm building it with Baling Wire

Sorry to interupt the config discussion going on,
But I just got back to working on getting this firm to work with repsnapper,
I was wondering if anyone has had and solved an issue with null lines pausing the print for ~20 sec
The line contains "n1 *69" (that's made up so the checksum is bs) ?

Architect Wrote:
-------------------------------------------------------
> Sorry to interupt the config discussion going on,
>
> But I just got back to working on getting this
> firm to work with repsnapper,
> I was wondering if anyone has had and solved an
> issue with null lines pausing the print for ~20
> sec
> The line contains "n1 *69" (that's made up so the
> checksum is bs) ?

hm, lines that look like valid g-code but don't contain any actual commands.. maybe the firmware doesn't respond in the way the host expects? I suggest removing them before printing

---

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

Quote
aka47
Bum the forum has messed the code by losing the indentation, but I guess you get the method.

That is what the "Formatted Code" tag/button is for!

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

That just hides the issue. either I will address it in the firmware or fix snapper to not output these lines.

I guess thats what happens when I try to have in depth technical discusions at silly o'clock in the morning. lol.

Edit: just been back and edited in the code tags, thanks for that.

On config files.

Remember that the compiler see's all the projects files that are included as one big file because the C preprocessor intelligently (guided by the preprocessor macro commands (#define, #include,#if etc)

Choping config.h down into smaller files should be a driven thing. ie why are we wanting to chop it down. What is the driver for doing this...........

If it is purely an eye candy thing (compilers are blind) or a because we like the idea and we are adding in a lot of work for the maintainer, who we don't care about, because it is not us, and perhaps making the code un-maintainable then it is arguably an extremely poor decision. Don't do it, we will be sorry.

If we are saying that the config.h is too big, it is difficult to understand what is happening, and takes a long time to scroll through and find stuff, then it should be factored out into sub files by function. Where all the .h files are always included.

Sections of the included code are then selected and conditionally compiled. Say put all the pin defs in one pins.h file maybe interupts in a second interupts.h etc etc etc etc. each block of defs enclosed in an "#if defined (processor_tag) my code here #endif".

After that put all the board specific statements one single boards.h file. which is always included. but sections of the code are selected and conditionally compiled by enclosing in each block of defs in an "#if defined (board_tag) my code here #endif".

Easy realy and maintainable.


Guys I think we are struggling to understand conditional compilation and how it is used in larger multi target projects. I am happy to be wrong, but am seeing the urge to chop up and selectively include being driven by a lack of the understanding of this solution to the problem it was cleverly designed to fix.

In a nutshell, my final words on this....

The right solution, factor files that are becoming unweildy by code function (not by target) include them all and conditionally ignore the code that is not applicable for a given target.

The wrong solution, factor files that are becoming unweildy by target and then conditionally include only those code files that are applicable.

Both will work from the compilers perspective neither will compile quicker or give more optimization than the other.

The wrong solution means you will end up with files full of duplicated redundant material that you then have to try and maintain whilst preserving consistency.

The right solution means that you can share blocks of code between different targets, where bug fixing one fixes it for all that share it.


If the code maintainers would like to choose which model they are going to buy into I am happy to make my small contribution along those lines.

Edited 1 time(s). Last edit at 01/25/2011 12:15PM by aka47.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Excellent point aka47, let me see if I can summerize:

There are basically two approaches:

Conditionally compile sections, based on mcu/board/whatever, but keep related stuff together (pin definitions, for instance)

Conditionally include files, based on mcu/board/whatever, and keep things that are included together together. (everything for a particular board in the same general location)

Or, so phrase that differently again:

Group by function

Group by usage (Used together? Goes together.)

Both will "look" the same to the compiler, so we should pick the one that's easiest from the perspective of maintenance, and is therefore least likely to result in stupid hard to track down bugs. Grouping by usage will result in duplicated code, and is therefore bad. We should group by function.

My own comments follow.

Obviously, grouping by usage will give many, many fewer #ifdef statements. Grouping by function will give many more #ifdefs, as selected parts of each function group will be included per board/mcu/whatever.

In no case should code be duplicated, but as a practical matter grouping by usage will probably result in some duplicate code. I don't think it'd be much though. Large code blocks can be shared anyway. OTOH, I think it will make maintaining #ifdefs much easier. Looking through huge #ifdef'd sections trying to figure out which bits are being executed can be really difficult. This is actually what the current scheme fails at - which bit do I need to modify now?

I think the main problem is the pin definitions. By which I mean which pins are the endstops, heaters, axises, and temperature sensors. They're large and unwieldy. And there's so many of them. Perhaps it would make sense to break out the pin definitions and leave the rest grouped by function? That may be the best compromise between "I can find things" and "code is not duplicated". Pin definitions are by definition duplicated code, and it's OK, appropriate, and even necessary to duplicate these sections.

So maybe leave everything else together and break out the pin definitions?

---

--
I'm building it with Baling Wire

Yes I can see the benefits in combining some parts of both aproaches.

The pin defs and to some extent register defs are messy with the ATMegas (but not the XMegas, I mention this only for comparison). The problem wiht the ATMegas is that they have evolved and the registers and pins are in some cases called differnt things on different devices. This was something I had not noticed until Eric the manin Amforth guy pointed it out.

UART's are a particular case in point, on a single UART device the UART register name (pulled in from the avr headers by the mce definition) is different from those devices that have more than one UART. ie the registers are named without a number for single uart devices but named with a number to differentiate which one on the device in multi UART devices etc.

The pin defs and the intrupt vector table defs for example are always mcu specific/unique and may be common to several different board implementations.

So it makes sense to conditionally include pin and interrupt defs conditionally on the mcu type. This way any board having that particular mcu will get the correct defs and they will be shared corectly amongst as many boards as use that mcu.

In effect you are abstracting the avr defintions for some of these because of the naming inconsistencies and bit reordering within the registers.

The rest should stay inline and be conditionaly compiled.

I think we principally agree then on this.

As an addendum.

The easiest way to see how the macro's are being interpreted (conditional compilation is selecting what) is to use the listing options for GCC. These can make GCC produce listing files show what it has read out of the source files including macro expansion. Even where the compilation fails you will get the listings showing what was passed to the compiler after pre processing.

Just in case there are readers who are not sure where the macro's come into this (sorry if you do) the C pre-processing directives

#define macro
#if defined macro #endif
#if evaluate_macro
#include file_of _macrotext

etc. etc .etc

are the macro expressions that are use to create conditional compilation, macro expands to the text that the tag
refers to or the file contains.

I apologize if calling them pre-processor directives, macro's and conditional compilation in different breaths has added to confusion. They are all the same thing it is just how they are used.

Before the compiler attempts to compile anything all the macro's are read, evaluated and removed creating one big temporary text .c file with everything in which is then given to the compiler to compile. The compiler itself never actually gets to see #anything just C code. It is pre-compilation-processed.

Hope this helps.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Actualy just re read your posting, You were talking about pin defs as in what they were doing on the board rather than pin defs on the device.

Those are stricly per board and indirectly related to the mcu used on the board.

Yup it is doable to select those files purely as by board. Given that each board is likely to be wired differently but will have some pins in common with others then I guess the redundancy is unavoidable.

A good example in point then would be the debug LED. Most boards have them (even my minimalist boards) but which pin/port it is on varies acording to the board.

Unfortunately due to the ATMega inconsistencies we already discussed it may be necessary where a single board can have a number of processors to duplicate the file but only if they are really different.

A good example in point for this are the Arduino Dueicimilla or Duemianove boards which can take either a 168 or a 328.

Clearly if both processors pins/ports etc are named the same then the one board def can be used for both instances with something like :-

#if defined (_duemilanove_168_) || (_duemilanove_328_)
   #include "pins_duemilanove.h"
#endif

wow even got the code tags that time. Comes of being awake.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

We should end up then with a config.h something like

/* common to all includes*/
#include wibble
#include blah


/* put all the rest of something that may or may not be shared here */
/* warning may include some conditionals  */
#define something
#define somethingelse 0x00


/* put mcu specific conditional includes here but only if we are really sure. */
/* next to last last so you can refer to anything you needed defined above */
/* from the common stuff   */
#if defined ( _MCUULIKE_)
    #include "intvect_mcuulike.h"
#elif defined (_OTHERMCUULIKE_) || (_EQUIVALENTMCU_)
    #include "intvect_othermcuulike.h"
#else
    #error "No mcu definition available, try again with one selected"
#endif


/* put board specific conditional includes here last so you can refer to */
/* anything you needed defined above */
#if defined ( _BOARDULIKE_)
    #include "pins_boardulike.h"
    #define debug_led b0
#elif defined (_OTHERBOARDULIKE_) || (_EQUIVALENTBOARD_)
    #include "pins_otherboardulike.h"
    #define debug_led a1
#else
	#error "No board definition available, try again with one selected"
#endif

Edited 5 time(s). Last edit at 01/25/2011 12:25PM by aka47.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Triffid_Hunter Wrote:
-------------------------------------------------------
> Architect Wrote:
> --------------------------------------------------
> -----
> > Sorry to interupt the config discussion going
> on,
> >
> > But I just got back to working on getting this
> > firm to work with repsnapper,
> > I was wondering if anyone has had and solved an
> > issue with null lines pausing the print for ~20
> > sec
> > The line contains "n1 *69" (that's made up so
> the
> > checksum is bs) ?
>
> hm, lines that look like valid g-code but don't
> contain any actual commands.. maybe the firmware
> doesn't respond in the way the host expects? I
> suggest removing them before printing


turns out my problem was not the null lines but the ACCELERATION_REPRAP.
I found that the blank lines were immediately after a print layer Zs.s F40 i assumed it was the blank line that caused the delay but it turns out I think it was the acceleration for F40 to F1500 and vise verse.
the gcode looked like this
...
G1 X10 Y10 F1500
G1 Z0.2 F40

G1 X15 Y15 F1500
...
My Printer was paused for ~60 secs between the first G1 command and the next G1 command.

i switched to the ACCELERATION_RAMPING and set the steepness to 175000 (after some experimenting)
and the delay has mostly gone away.

after more thought about it though I am going to alter Repsnapper to not bother sending blank lines nor comments
because there really is no practical reason to do that and being that 5D does not read the whole line it still must process the line number and checksum and I feel that's just wasted cycles in the firmware.

Enjoying the Snow,
[[..Architect..]]

Problems compiling and uploading FiveD on Arduino....

First off sorry if this is the wrong place to ask a question like this, but this is my first post here on the reprap forum. Let me know if i should ask this somewhere else.

Im building my first RepStrap (actually a JunkStrap) and I'm trying to make it out of as many free materials as i can, or things i already own. Mostly for my budget's sake, but also for the challenge. I have been reading the RepRap Wiki for about 6 months now and have learned a LOT. I love that you guys have developed firmware to run on the smaller Arduino's, since that's what i have, so that's why im trying to go the "FiveD on Arduino" route.

The mechanical setup of my Mendel is almost done, but before i get too much farther i have started to assemble and test my electronics.

Here is my setup... (so far)
-Arduino Duemilanove (ATMega 328)
-Pololu A4983 Stepper Drivers
-Some random Stepper motors that should be within spec.

I got the latest "FiveD on Arduino" firmware from Github today and am following all the instructions here [reprap.org], but im running into problems already....

#1. Did i do step 3 of the simple installation right when it says "3. Copy config.h.dist to config.h"
I basically just created a new file called config.h and copied and pasted everything that was inside config.h.dist into the new file.
Is that right? After that I started editing the config.h file and ran into problems #2-#4 below.....

#2. The pin definitions..... There seems to be two sets of definitions, the "User Defined Pins" and the "Official gen3 Pinout".... am i supposed to choose one set and comment out all the other ones, or just edit my pin assignments in both? Any detailed help there would be great. I am using the wiring schematic for the Pololu electronics here [reprap.org] (but obviously trying to use an Arduino with an ATMega 328 and not the Mega)

#3. Also, at the top of config.h is the question....
/*
Are you using the official GEN3 motherboard with separate extruder controller?
*/
#define GEN3

Am i supposed to comment this out if "No".... my answer IS no, but i don't know what to do about it, haha.

#4. After editing config.h a bit to match my setup and trying to upload it to my Arduino, i get the following error....
In function 'dda_create':
error: 'DIO19_WPORT' undeclared (first use in this function) In function 'dda_start':
In function 'dda_step':

What am i doing wrong?

Im really trying to basically just make exactly the motherboard/electronics that Triffid Hunter has done here.... [wooden-mendel.blogspot.com]
Does anyone have a schematic for that, im assuming it's almost identical to the Pololu Electronics with a Arduino Mega, just different pin assignments?

Thanks so much for the help guys, I am so excited about the RepRap project and can't wait to get my JunkStrap Mendel up and running!

Edited 4 time(s). Last edit at 01/29/2011 02:26AM by daufhammer.

#1 yep that should work fine
#2 ignore the gen3 ones, they only activate when you define gen3 (see #3). In fact you can remove the whole gen3 block if you're not going to use it
#3 yep comment it out
#4 gen3 uses pins that don't exist on the '328, it'll be complaining about that. this should disappear when you fix #3

---

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

Thanks for the quick answer Triffid_Hunter! Do you have a schematic and config.h of your setup i can look at....

I made the changes you mentioned and commented out the "#define GEN3" at the top of config.h, but that generated a few more problems/questions.

I commented out all of the Gen3 pins after the #else, but got the following error...
o: In function `temp_sensor_tick':
C:\DOCUME~1\Drew\LOCALS~1\Temp\build6494708951170241246.tmp/temp.c:219: undefined reference to `get_read_cmd'
C:\DOCUME~1\Drew\LOCALS~1\Temp\build6494708951170241246.tmp/temp.c:221: undefined reference to `start_send'

Then i tried commenting out the #else also, but got this error...
C:\DOCUME~1\Drew\LOCALS~1\Temp\build6494708951170241246.tmp\/config.h:200: error: expected identifier or '(' before '/' token

Also, what is this pin for? #define PS_ON_PIN DIO9

What should i do with the Enable pin on the Pololu stepper driver? In the standard Pololu electronics the schematic shows each of the Pololu driver Enable pins going to an Arduino pin, but i don't see any Enable pin listed in the "User Defined Pins" section of config.h. Should i just pull each of those pins LOW according to the Alegro A4983 Datasheet so that they are always Enabled?

Here is what my Pinouts section looks like now. Any ideas what i might be missing? Thanks!!!

/***************************************************************************\
* *
* 3. PINOUTS *
* *
\***************************************************************************/

/*
Machine Pin Definitions
- make sure to avoid duplicate usage of a pin
- comment out pins not in use, as this drops the corresponding code and makes operations faster
*/

#include "arduino.h"

#ifndef GEN3
/*
user defined pins
adjust to suit your electronics,
or adjust your electronics to suit this
*/

#define X_STEP_PIN AIO0
#define X_DIR_PIN AIO1
#define X_MIN_PIN AIO2

#define Y_STEP_PIN AIO3
#define Y_DIR_PIN AIO4
#define Y_MIN_PIN AIO5

#define Z_STEP_PIN DIO2
#define Z_DIR_PIN DIO3
#define Z_MIN_PIN DIO4

#define E_STEP_PIN DIO7
#define E_DIR_PIN DIO8

#define PS_ON_PIN DIO9
/* #else
/*
this is the official gen3 reprap motherboard pinout
*/
#define TX_ENABLE_PIN DIO12
#define RX_ENABLE_PIN DIO13

#define X_STEP_PIN DIO15
#define X_DIR_PIN DIO18
#define X_MIN_PIN DIO20
#define X_MAX_PIN DIO21
#define X_ENABLE_PIN DIO19

#define Y_STEP_PIN DIO23
#define Y_DIR_PIN DIO22
#define Y_MIN_PIN AIO6
#define Y_MAX_PIN AIO5
#define Y_ENABLE_PIN DIO7

#define Z_STEP_PIN AIO4
#define Z_DIR_PIN AIO3
#define Z_MIN_PIN AIO1
#define Z_MAX_PIN AIO0
#define Z_ENABLE_PIN AIO2

#define E_STEP_PIN DIO16
#define E_DIR_PIN DIO17

#define SD_CARD_DETECT DIO2
#define SD_WRITE_PROTECT DIO3
*/
#endif

daufhammer Wrote:
-------------------------------------------------------
> Do you have a schematic and config.h of your setup i can look at....

no, but it's pretty simple.. OCR0A/OCR0B pins (see appendix in config.h) are connected to a couple of IRL3803s, SPI port goes to MAX6675, arduino power comes from 5VSB, everything else is powered from a 7805 on the 12v rail.. rest of the pinouts are basically random, whichever pin was closest when I routed the wires. I'm gonna have to rewire it soon because my X and Y axis signals are on the analog port and I want to swap out my MAX6675 for a couple of thermistors.

> I commented out all of the Gen3 pins after the
> #else, but got the following error...
> o: In function `temp_sensor_tick':
> C:\DOCUME~1\Drew\LOCALS~1\Temp\build64947089511702
> 41246.tmp/temp.c:219: undefined reference to
> `get_read_cmd'
> C:\DOCUME~1\Drew\LOCALS~1\Temp\build64947089511702
> 41246.tmp/temp.c:221: undefined reference to
> `start_send'

you still have TT_INTERCOM defined. you probably want TT_THERMISTOR instead

> Also, what is this pin for? #define PS_ON_PIN
> DIO9

That's the pin I connect to my ATX psu PWR_ON pin so my arduino can turn the power on and off by itself. Since my '328 doesn't have enough pins for each axis to have its own enable, I use that pin to enable and disable all the steppers and the heater at once.

> What should i do with the Enable pin on the Pololu
> stepper driver? In the standard Pololu electronics
> the schematic shows each of the Pololu driver
> Enable pins going to an Arduino pin, but i don't
> see any Enable pin listed in the "User Defined
> Pins" section of config.h. Should i just pull each
> of those pins LOW according to the Alegro A4983
> Datasheet so that they are always Enabled?

The gen3 pinout section shows you defines for individual enable pins, eg X_ENABLE_PIN etc, but you probably won't have enough spare pins for them all

---

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

Awesome, thanks!

I made those changes and it compiled properly, but when i tried to upload the firmware i got the following error...

avrdude: ERROR: address 0x820003 out of range at line 822 of C:\DOCUME~1\Drew\LOCALS~1\Temp\build3774636178461720984.tmp\FiveD_on_Arduino.cpp.hex
avrdude: write to file 'C:\DOCUME~1\Drew\LOCALS~1\Temp\build3774636178461720984.tmp\FiveD_on_Arduino.cpp.hex' failed

Any idea what that could be?

Also, just to clarify... so you basically hook together all the Enable pins of the stepper drivers, the Heater, and the ATX psu, and tie those all to PS_ON_PIN? i.e. instead of using up a bunch of Arduino pins to turn on and off all those things, you just use one pin to turn them ALL on and off. Im pretty sure that's what you were saying, but just wanted to double check....

Thanks Triffid_Hunter, I really appreciate all the help from such an expert!
(I have been doing a lot of random projects with my Arduino over the past year and a have a bit of programing experience, but the RepRap firmware is pretty complex for me, so i still consider myself a noob.)

daufhammer Wrote:
-------------------------------------------------------
> avrdude: ERROR: address 0x820003 out of range at
> line 822 of
> C:\DOCUME~1\Drew\LOCALS~1\Temp\build37746361784617
> 20984.tmp\FiveD_on_Arduino.cpp.hex
> avrdude: write to file
> 'C:\DOCUME~1\Drew\LOCALS~1\Temp\build3774636178461
> 720984.tmp\FiveD_on_Arduino.cpp.hex' failed
>
> Any idea what that could be?

You need to comment out fuse.h, the whole file... I was trying to provide fuse settings but apparently ld and avrdude disagree on how they are represented

> Also, just to clarify... so you basically hook
> together all the Enable pins of the stepper
> drivers, the Heater, and the ATX psu, and tie
> those all to PS_ON_PIN? i.e. instead of using up a
> bunch of Arduino pins to turn on and off all those
> things, you just use one pin to turn them ALL on
> and off. Im pretty sure that's what you were
> saying, but just wanted to double check....

No, I set everything to always be enabled and hook that pin to the psu's pwr_on pin, usually a green wire. Can't do much with an enable signal but no power!

> Thanks Triffid_Hunter, I really appreciate all the
> help from such an expert!
> (I have been doing a lot of random projects with
> my Arduino over the past year and a have a bit of
> programing experience, but the RepRap firmware is
> pretty complex for me, so i still consider myself
> a noob.)

heh, tackling things a little bit beyond you is the best way to learn

---

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

Nice! I commented out the whole Fuses.h file and it compiled and uploaded!

Im a bit more confused about the psu and enable pins now though....

when you said "I set everything to always be enabled..." How did you do that?... Did you just connect all the Enable pins on the Pololu Drivers to ground to pull them Low? (The data sheet says they need to be pulled low to be enabled)... then you also connected the green "power on" wire from the psu to the PS_ON_PIN on the Arduino..... That way when you give the Arduino power, the PSU turns on automatically, and the Pololu drivers are enabled also.

Let me know if i have things straight this time!
(Disregard all that above....See Edit 1)

Also, do you know any good way to test if the firmware on the motherboard is working properly before i plug in my Pololu drivers. I just don't want to accidentally burn one of those things out from a pin being high when it should have been low, or vice versa. I thought about just using an LED between ground and then touching it to the different pins to make sure i get a signal where i expected.

Again, thanks for the input!

Edit 1: After studying the Pololu A4983 Driver schematic on the Pololu website [www.pololu.com] it sees like the enable pin is already pulled low in the circuit, so technically we could just ignore these pins and leave them unconnected right?

Edit 2: So i have continued trying to get things all setup right and I am now 99% sure my basic electronics are setup right.... for now just an Arduino '328, 1 Pololu A4983 Driver, and 1 Stepper & 12v PSU..... I ran a basic sketch on my Arduino to get my motor turning back and forth and it worked, so that's all good....

I'm basically trying to test just one Axis before i put everything else together, but for some reason when i start up the RepRap Host software and try to Jog the Axis the software freezes.... When the Arduino is NOT plugged into the USB port, the software functions fine, but everytime i plug it in, it freezes.... i would guess this is some sort of communication error between the Host software and the Arduino, but i don't know what it is.... I did already change the COM port in the preferences to COM 3 (my Arduino's COM port). I had done this earlier when i was trying out some older firmware for the Arduino '328 and it wasn't freezing and the Tx Rx led's would light up when i pressed the axis jog button. But now with your firmware the Host software freezes. Any thoughts on what I could do to fix that? Thanks!

Edited 4 time(s). Last edit at 01/31/2011 03:47AM by daufhammer.

yeah we have lots of issues with host software all having different but very particular expectations of what firmware should say.. For the moment I suggest you use your favourite serial terminal

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> yeah we have lots of issues with host software all
> having different but very particular expectations
> of what firmware should say..

I hope Libreprap will help on this question.

When porting this firmware to my ARM board, I found that I couldn't put my firmware working with RepRap software and RepSnapper and so I am just using now RepRap software although I like a lot RepSnapper and I used it before with RepRap electronics.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Ok, thanks Triffid_Hunter.... I was thinking that the FiveD on Arduino firmware was pretty stable now and would be usable by someone like me who has a lot of experience on the electronics side, but just a little on the programming side.

Would you recommend i go a different firmware/motherboard route? I would really love to use my Arduino Duemilinove '328, but maybe it's not the best solution for me right now.

To use a serial terminal, Im guessing that i could use the RepRap host software to arrange my parts, then generate the gcode file from there. Once i have the gcode file, how would i send it to the Arduino from the serial terminal (i have very little experience here)

Also, would there be a way to just "jog" the axis' from a serial terminal... that would be really helpful to just start testing my electronics.

And, casainho, is Libreprap just an alternate type of Host software to interface with my RepStrap Mendel?

Thanks

Edit: Oh yea, i forgot to mention that even without the RepRap host software running, when i plug in my Arduino and turn on the 12v power to the stepper driver, my motor just makes a squealing sound, but isn't turning.... I know its all wired right because of my tests with just a basic sketch to turn the motor back and forth... but with the FiveD firmware it just squeals.... could this be because i am only wiring up one stepper (axis) and don't have and end stop? Is it possible to just test one axis without anything else connected, or will the firmware not like that?

Edited 1 time(s). Last edit at 01/31/2011 02:33PM by daufhammer.

daufhammer Wrote:
-------------------------------------------------------
> Ok, thanks Triffid_Hunter.... I was thinking that
> the FiveD on Arduino firmware was pretty stable
> now and would be usable by someone like me who has
> a lot of experience on the electronics side, but
> just a little on the programming side.

heh not yet, still needs lots of wrangling.. it's mostly polish that's happening now, rather than massive mathematical or procedural changes

> Would you recommend i go a different
> firmware/motherboard route? I would really love to
> use my Arduino Duemilinove '328, but maybe it's
> not the best solution for me right now.

I only have a '328 to test this on myself.. Its only limitation is that it doesn't have quite enough pins for everything we could use a pin for. Perhaps a 74hc575 on the SPI port could help with that?

> To use a serial terminal, Im guessing that i could
> use the RepRap host software to arrange my parts,
> then generate the gcode file from there. Once i
> have the gcode file, how would i send it to the
> Arduino from the serial terminal (i have very
> little experience here)

you'll want xon/xoff support for that, then just copy+paste

> Also, would there be a way to just "jog" the axis'
> from a serial terminal... that would be really
> helpful to just start testing my electronics.

sure,
G91 (relative)
G1X1 (move 1mm)
G1X-1 (move back 1mm)

> And, casainho, is Libreprap just an alternate type
> of Host software to interface with my RepStrap
> Mendel?

libreprap is a new project started by ralith and a few others in an attempt to create a universal serial interconnect library, which will hopefully stabilise the API. I don't think there's anything released just yet, but we're desperately in need of it

> Edit: Oh yea, i forgot to mention that even
> without the RepRap host software running, when i
> plug in my Arduino and turn on the 12v power to
> the stepper driver, my motor just makes a
> squealing sound, but isn't turning.... I know its
> all wired right because of my tests with just a
> basic sketch to turn the motor back and forth...
> but with the FiveD firmware it just squeals....
> could this be because i am only wiring up one
> stepper (axis) and don't have and end stop? Is it
> possible to just test one axis without anything
> else connected, or will the firmware not like
> that?

it should be fine with that, just don't ask it to wait for temperature to reach some value
it won't move until it receives a command that tells it to move

---

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

I've been building release-candidate, and the thermistor table lookup code is way out of kilter (unless I've hugely misunderstood it). I've found that the following produces the correct results (based on the old 1.3 firmware):

for (j = 1; j < NUMTEMPS; j++) {
if (pgm_read_word(&(temptable[j][0])) > temp) {
// multiply by 4 because internal temp is stored as 14.2 fixed point
temp = pgm_read_word(&(temptable[j][1])) * 4 +
(temp - pgm_read_word(&(temptable[j-1][0]))) * 4
* (pgm_read_word(&(temptable[j][1])) - pgm_read_word(&(temptable[j-1][1])))
/ (pgm_read_word(&(temptable[j][0])) - pgm_read_word(&(temptable[j-1][0])));
break;
}
}

That cost me a thermistor

Vik :v)