Project: Teacup Firmware

The define is in config.h.dist (as it should be) in my commit.

Does Github allow you to rebase your fork, then? I mean, if you just forked, you get something like this:

triffid:master A - B
                    \
elmom:master         C - D - E

Now I pick you patches C and D, and we get:

triffid:master A - B - C'- D'
                    \
elmom:master         C - D - E

Ideally, you could rebase the fork now, to minimize the number of patches:

triffid:master A - B - C - D 
                            \
elmom:master                 E

The beauty of rebasing becomes obvious if you consider patches in the triffid repo:

triffid:master A - B - C - D - F - G
                            \
elmom:master                 E

A rebase easily gets this into your repo:

triffid:master A - B - C - D - F - G
                                    \
elmom:master                         E

You see how all the duplicates just vanish? This way we can approach the goal from both sides and I can even commit patches, which won't go into triffid:master, to triffid:gen3 to reduce the difference between your work and the gen3 branch. This way we can evaluate at any time wether triffid:gen3 still works on Gen3 electronics and triffid:master still works on single boards. Eventually, the difference will become zero and we're done :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Regarding #defines: all FiveD code I've seen so far uses something like:

#define	power_on()	if (0) {}
#define	power_off()	if (0) {}

while declaring such pseudo-functions just empty, e.g.:

#define	power_on()	/* empty */
#define	power_off()	/* empty */

would do just as fine. Same for

do { ... } while (0)

pseudo-loops, where just

{ ... }

should be equivalent.

Is there a specific reason for this?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I haven't found firmware for an arduino mega that I'm happy with yet.

I have been reading up a bit about this firmware and it sounds promising, but it doesn't have pin definitions for an arduino mega. I'm not entirely sure of what I'm doing, but I think I'd like to try adding these pin definitions and see if I can make it run on my RAMPS kit. I'm familiar with the adruino style of using some function to map a pin number to either an output or input, but what you have here looks vastly different. I'm assuming you directly map the pins instead of calling a function that performs this action behind the scenes? What do I need to know and where am I likely to find this information?

Have a look into arduino.h and config.h(.dist). There are tons of pin definitions and at the top of arduino.h you see the macro definitions used for writing/reading hardware.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Regarding this problem/bug on "FiveD on Arduino" code that I found while porting the code for ARM Cortex-M3:



I found reading the RepRap software this piece of code:

  if(eTemp == Double.NEGATIVE_INFINITY)
  {
    Debug.e("GCodeReaderAndWriter.getETemp() - no value stored!");
    return 0;

And this, where eTemp variable get filled:

  eTemp = parseReturnedValue(resp, " T:");

So, the problem is that firmware "FiveD on Arduino" is printing:

#ifdef REPRAP_HOST_COMPATIBILITY
  sersendf("T: %u.0\n", current_temp);

While it should put a space before "T":

#ifdef REPRAP_HOST_COMPATIBILITY
  sersendf(" T: %u.0\n", current_temp);

I didn't tested yet, but after reading RepRap software and firmware, I am sure the problem is that one.

Edited 1 time(s). Last edit at 10/07/2010 02:27PM by casainho.

---

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

[www.3dprinting-r2c2.com]

I have looked in arduino.h and all I see (regarding the arduino mega anyhow) is this:

#if defined (__AVR_ATmega1280__)
#endif	/* __AVR_ATmega1280__) */

#ifndef	DIO0_PIN
#error pins for this chip not defined in arduino.h! If you write an appropriate pin definition and have this firmware work on your chip, please tell us via the forum thread
#endif

While I see a bunch of stuff like this:

	#define AIO7_PIN		PINA5
	#define AIO5_RPORT	PINA
	#define AIO5_WPORT	PORTA
	#define AIO5_DDR		DDRA

for other ardunio boards, I don't understand the magic that makes it work. Thus, I'm not sure how to reconfigure this to make a set of pin definitions for the ATmega 1280.

I'm also wondering if I inadvertently discovered a copy/paste editing mistake. Keeping in mind that I really don't understand what I'm looking at, I'm guessing that you are trying to define analog input 7 in the above example? Everything else looks like it is set to pin 5 here though. In nearly all of the other #define statements, the pin numbers are the same throughout each group. For example:

	#define AIO0_PIN		PINA0
	#define AIO0_RPORT	PINA
	#define AIO0_WPORT	PORTA
	#define AIO0_DDR		DDRA
//all 0

	#define AIO1_PIN		PINA1
	#define AIO1_RPORT	PINA
	#define AIO1_WPORT	PORTA
	#define AIO1_DDR		DDRA
//all 1

**Edit:
I followed through some of the #include's and found a few header files in the arduino libraries that may help me figure out pin definitions. Namely, io.h, iom1280.h, and portpins.h. I'm still pretty confused, but its a step in the right direction I think.

Edited 1 time(s). Last edit at 10/07/2010 09:31PM by dazed.dnc.

dazed.dnc; the macros at the top of arduino.h are the magic behind the pin systems.

When you eg WRITE(DIO3, 1), the preprocessor passes "DIO3" to the WRITE macro, which substitutes DIO3 into the _WRITE macro, like this:

do { if (1) { DIO3_WPORT |= MASK( DIO3_PIN); } else { DIO3_WPORT &= ~MASK(DIO3_PIN); }; } while (0)

in preprocessor parlance, ## is the string concatenation operator which we use to construct these new names from the specified pin.


this then gets preprocessed again as the preprocessor returns from _WRITE macro to WRITE macro, using relevant defines from arduino.h and we end up with this:

do { if (1) { PORTD |= MASK( PIND3); } else { PORTD &= ~MASK(PIND3); }; } while (0)

this gets preprocessed /again/ and we end up with something the compiler understands which I won't reproduce here for clarity because frankly it's eyeball-twisting.


so in order to use "DIO3" as a pin specification, DIO3_WPORT and DIO3_PIN must be defined. reading requires DIO3_RPORT, and setting input/output requires DIO3_DDR, so for every usable pin you will find 4 defines.

When you create a set of maps for your mega, you must simply work out the appropriate port names/values for each pin, choose suitable pin names and write defines as necessary

---

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

casainho, your patch is in the repo, let us know how it goes. Looks like you've done some serious digging there- well done even if that's not the fix

dazed.dnc, that is indeed a typo- actually more like incomplete changes after a copy+paste. patch is in the repo. There may be some register changes, eg PRR -> PRR0 between the smaller atmegas and your 1280. see temp.c:89 and serial.c:79 for how we've handled this for the differences between 168/328 and the 644.

---

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

Got an answer for this one:

Quote

Same for

do { ... } while (0)

pseudo-loops, where just

{ ... }

should be equivalent.

[kernelnewbies.org] You always learn new things ...

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

> [kernelnewbies.org] You always
> learn new things ...

Good, I also were asking myself about that. It's a pleasure to learn from other experienced developers and that's why I love Open Source, where I can analyse and learn with the others humans works :-)

---

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

[www.3dprinting-r2c2.com]

Triffid_Hunter (): Thanks for the detailed explanation. I saw the link about "stringification" but it didn't quite sink in until I saw your example and learned what "##" does.

I have a datasheet for my chip and I see where it lists the "ports". I think I have all the information so it is just a matter of translating it all into a usable set of pin definitions. That might take a while considering my lack of experience and understanding.

I'm going to start recommending to people outside of rep-rap community with the at-mega 328 chip give this code a try as a beta alternative. This code for the at-mega works fast! the only other alternative is to move more processing tasks to the computer host CPU using firmeta standard.

It is ridiculous for people to spend over 300$ for hardware, when this code works better than the more expensive hardware, when it is setup correctly. the key is getting it setup correctly.

This code seems this code works well with alternative driver circuits as well that are cnc board based, or you can use Pololu Electronics, or any driver. Also it has the needed speed for those that start out with threaded rod systems, as it can run ok at least at 1/4 micro stepping speed.


Again, I'm recommending people that can tinker, to give it a try.. the documentation is scarce.

james villeneuve:
great to hear that you think this project is ready for a wider audience!

Can you suggest anything specific that would make it easier for this wider audience to access? I'm not good at even knowing what needs to be documented :/

---

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

Given that Pin 47 uses port L and is number 2 on that port, have I got this correct?

#define DIO47_PIN		PINL2
	#define DIO47_RPORT	PINL
	#define DIO47_WPORT	PORTL
	#define DIO47_DDR		DDRL

Attached is a list of pins and associated ports/functions for an arduino mega. I intend to put them in the firmware myself eventually, but I thought I should post the list here for anyone interested in the mean time. If anyone finds something that is missing or incorrect, please let me know so I can fix the list.

I don't know if I just overlooked them or if they don't exist, but I'm not able to find a few of the alternate pin functions. IE: Timer 2 (T2) and Output Compare 2C (OC2C)

I think all the (useful) breakout pins are accounted for though. There are also apparently some pins with no breakout connection. However, they have alternate functions which might be useful in the firmware so I went ahead and listed them.

Traumflug Wrote:
-------------------------------------------------------
> Does Github allow you to rebase your fork, then? I
> mean, if you just forked, you get something like
> this:
>

Rebasing commits that are pushed to a public repo is discouraged, and I don't think github allows anything besides adding and deleting branches.

Do the duplicates really matter? Is occasional birectional merging too messy?

Triffid seems to be doing the merging now in the new gen3-merge branch?

I'm happy if/when master magically starts to work on gen3

Quote

Do the duplicates really matter?

Yes, because this prevents you from slimming out your stack of patches. You end up with a huge stack and have a hard time to distinguish those already in the main repo from those only on your branch. Rebasing works even in both directions, so finding an answer to "my set of patches worked with last week's master, but doesn't today" can be done by rebasing a few commits back, then rebasing forth until you catch the culprit.

So, while rebasing and cherry-picking is a great idea for working locally and even recommended by GitHub, it doesn't work with repos which are somehow made public. Disappointing :-/

That said, FiveD on Arduino seems to do better than ever. People start recognizing this firmware :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

dazed.dnc

nice work on the arudino mega pin list but before you get to carried away...

After chatting on IRC, I was able to knock out the ATmega1280/ArduinoMega pin map and the other firmware changes on sunday, and Triffid has all ready pulled the patch into the master branch of the git repo.

I have check that it compiles but i haven't had time to actual upload the firmware to my arduino mega yet and check it all works.
So please feel free to try it and report back

Matt

Thanks for doing the grunt work and pointing that out. You just saved me a lot of time and guesswork. I'll grab the new files and give it a shot.

Edit:
Does the following also apply to this firmware?

Quote
http://reprap.org/wiki/Arduino_Mega_Pololu_Shield
The FiveD Firmware uses Timer1, which is also used for PWM on pins 11 and 12, so we can not use those pins for the heater in FiveD Firmware. This first set of pin definitions is tested on the FiveD firmware.

Edit again:
I just saw in the code comments that you should not use pins 11 and 12. The above issue must be why. Since my heater uses pin 12, how difficult would it be to use another timer instead? If it is a relatively simple firmware change, I would like to try that before I go modifying my PCB to use some other pin.

Edited 2 time(s). Last edit at 10/12/2010 08:25PM by dazed.dnc.

Could someone (Triffid?) make the gen3_merge branch code compilable fot gen3 (with correct defines in config) with the arduino env? I would love to use the makefile, but can't seem to be able to upload the code. Get the usual error of board not responding and syncing error. If you could give any pointers on how upload the .hex, it would rock my world Are you able to upload with "make program" ? What boards are you using? Maybe you could see how the latest Arduino release does it, since it works flawlessly (had problems with earlier versions).

Btw. the compiling in the Arduino env complains about the copier.* code, which should not be included. Removing them fixes that particular issue, but what would be the real fix? I tried in my fork (the temp branch currently) making the makefile copy the appropriate files into a build dir. That replaces the need to have symlinked files (what about windows?) for the extruder board also.

For the other issues:
Maybe a simple config file for global definitions (could be generated by the makefile) could be included in all the files which could include the defs given now in the makefile?

Quote

Could someone (Triffid?) make the gen3_merge branch code compilable fot gen3 (with correct defines in config) with the arduino env?

That's obviously currently in the works on the branches with "gen3" in the name. Regarting a config, putting this into a config.h.gen3-mendel.dist would probably be the best idea. Thre are so many combinations of hardware and electronics out ther, making a preference for any of the combinations doesn't make sense.

Quote

I would love to use the makefile, but can't seem to be able to upload the code. Get the usual error of board not responding and syncing error. If you could give any pointers on how upload the .hex, it would rock my world smiling smiley Are you able to upload with "make program" ?

Yes, that works for an Arduino Diecimila here. If it doesn't for you, using the Arduino IDE should be just as fine. If the later doesn't work, this should be fixed.

Quote

Btw. the compiling in the Arduino env complains about the copier.* code, which should not be included. Removing them fixes that particular issue, but what would be the real fix?

Removing the file IS the real fix, because Arduino IDE picks up any file available. If this code is used elsewhere, the contents should be wrapped in #ifdefs, like for example in heater.h/.c with the HEATER_PIN config.

Quote

Maybe a simple config file for global definitions (could be generated by the makefile) could be included in all the files which could include the defs given now in the makefile?

This should work already. All configurations set in the Makefile and not set by the Arduino IDE can be set in config.h as well. Unless we overlooked something, of course.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Could someone (Triffid?) make the gen3_merge
> branch code compilable fot gen3 (with correct
> defines in config) with the arduino env?
>
> That's obviously currently in the works on the
> branches with "gen3" in the name. Regarting a
> config, putting this into a
> config.h.gen3-mendel.dist would probably be the
> best idea. Thre are so many combinations of
> hardware and electronics out ther, making a
> preference for any of the combinations doesn't
> make sense.
>

Yes, but the actual compilation didn't seem to work. I tried adding #define's for all the stuff, but still had problems. Tested example config.h files for both boards would be great.

> I would love to use the makefile, but can't seem
> to be able to upload the code. Get the usual error
> of board not responding and syncing error. If you
> could give any pointers on how upload the .hex, it
> would rock my world smiling smiley Are you able
> to upload with "make program" ?
>
> Yes, that works for an Arduino Diecimila here. If
> it doesn't for you, using the Arduino IDE should
> be just as fine. If the later doesn't work, this
> should be fixed.

I just wonder what the arduino IDE does so differently.

>
> Btw. the compiling in the Arduino env complains
> about the copier.* code, which should not be
> included. Removing them fixes that particular
> issue, but what would be the real fix?
>
> Removing the file IS the real fix, because Arduino
> IDE picks up any file available. If this code is
> used elsewhere, the contents should be wrapped in
> #ifdefs, like for example in heater.h/.c with the
> HEATER_PIN config.
>
> Maybe a simple config file for global definitions
> (could be generated by the makefile) could be
> included in all the files which could include the
> defs given now in the makefile?
>
> This should work already. All configurations set
> in the Makefile and not set by the Arduino IDE can
> be set in config.h as well. Unless we overlooked
> something, of course.

At least the gen3_merge branch code doesn't get all of the needed global defines from the config.h. Should be a quick fix for the more experienced developers. I'm not sure how to fix it right. Couldn't get the extruder code compile, and the motherboard code seemed to be missing something even if I got compiling.

I think this code is good enough to be used as an alternative for people that want better performance from hardware. It would be good if it was documented on how to get it on the avr controller step by step.

Explain briefly what a makefile is to people, and the steps and programs and processes you use. also perhaps explain that there are several types of drivers out there that work with your setup.

Upload the instructions in the gen3 section with a link to your downloads. don't overshadow the makerbot section, or the gen3 sections, just add a few comments at the end called alternative firmware, or something like that. also add a disclaimer. such as a work in progress, use caution, or what have you. also mention the 115,000 baud settings change from 19200baud in reprap host software if used.

This firmware may also be added upon too. many features related to 3d printing are coming, including 3d probe scanners. that is something for another discussion though. this firmware is promising, because it has a small footprint, excellent performance, and is starting to sort of work on the 1280 controllers. I personally think that compatibility with reprap host software is a minimum requirement, as long as it works with the reprap host at some level.

excellent work!

Quote

Tested example config.h files for both boards would be great.

How would I test a config with neither having a standard Gen3 electronics nor a standard (if that even exists) Mendel?

Quote

It would be good if it was documented on how to get it on the avr controller step by step.

It's the exact same procedure as with the official firmware and it's well well documented. It seems to be a bit difficult to swallow the existence of a Makefile doesn't require to actually use that.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Guys

I am quickly getting to the point where I need to start with putting some working firmware onto a huxley I am building and fancy trying your code for size.

A quick couple of questions.

How are you doing for pin numbers on devices when doing full 5d ?? (I know some of you are keen to stay with the 328)

Has anyone implemented your firmware on a 644 or 1284 40 pin DIL ??

Where is your current repository so I can rummage through some code and muse a little ??

Cheers

aka47

PS I am just working on a programmable stepper driver (spi + step dir) that may allow you to do some clever things like get more speed by changing micro-stepping settings on the fly. Just need to make sure that transitions are on compatible boundaries. I hope to have a schematic done in the next couple of weeks.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

Where is your current repository so I can rummage through some code and muse a little ??

[github.com]

Pin configurations are done in config.h and the 644 should work already.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Tested example config.h files for both boards
> would be great.
>
> How would I test a config with neither having a
> standard Gen3 electronics nor a standard (if that
> even exists) Mendel?
>

Well, putting the proper #define's and having it compile would be great.

Now I'm actually successfully using the Makerbot firmware. I was considering using ReplicatorG to upload this firmware after compiling it with the Makefile, but since I got the bot printing, I'll won't be messing with the firmware in while. The default settings of repG gave me a nice ring

I'll be following the progress of this promising project though.

Hi. I just wrote a really long post about the work we are doing at Labitat, the hackerspace in Copenhagen, but then disgusting web technology ate my complete post. I absolutely detest web forums. Is there a mailing list please?

We have an FPGA lab group and we are doing some new electronics for the Mendel, also with the NXP LPC1768 Cortex-M3. I'll also be looking at LPC1343, a smaller sibling. We plan to add closed loop control of steppers and have the FPGA handle that, along with other tasks as makes sense. A cheap and easy to access FPGA platform is the Open Logic Sniffer at $45 shipped worldwide, with a smallish but still useful Xilinx Spartan-3E FPGA. There are also other boards. We want to optimize both software and hardware for performance, cost, size and hassle. We think that there is quite a lot to gain by stepping up from the AVR limitations.

LPC1769 is a 32-bit core at 120MHz and should allow both very well structured code (don't worry no C++) and also new math. FPGA can also do some math of course, but it's generally expensive. (Needs much FPGA real-estate.) In the end we may target the Actel SmartFusion FPGA which include Cortex-M3, FPGA and analog in a single package. A SmartFusion eval board sells at $99 and would probably connect directly to driver boards, maybe we'll make a suitable driver board too. That's all in the future, we are starting making only small changes, one step at a time. First step get some code running on Cortex-M3. This rewrite looks like exactly what we want to start with!

Our FPGA group page and the RepRapper project page.

I'm also a libusb maintainer, and I am quite allergic to using USB only as a dumb serial port. USB is a packet bus, and applications can usually benefit tremendously from exploiting that. I'll look at how the RepRap can make good use of USB. Next release of libusb-1.0 also supports Windows. Release coming Real Soon Now, heh. We're of course happy to help out with the USB host software too. LPC1768 has Ethernet, and we've discussed that briefly, but will focus on USB first.

In any case the Mendel should also be able to standalone. LPC1768 has USB host functionality, a memory stick could plug into that, user chooses a gcode file which is copied from the stick quickly, then user unplugs stick and goes to next machine while Mendel goes about printing.

This is open source and of course we're happy to collaborate with others who are also interested in this. We have a mailing list for the FPGA group, where I expect that this project will be discussed when we are not meeting (every 2nd Thursday, next meet in two days) up in person at Labitat.

Cheers.