Project: Teacup Firmware

Hi all,

over the last few days I've been attempting to re-write the FiveD firmware and wrangle pin allocations enough that I can run my entire wooden mendel from an atmega168-based arduino.

At the moment, I've implemented 90% of what I need, it compiles but is otherwise totally untested except for a few personal libraries, and it currently uses 40% of my maximum 16k. I'd prefer it to fit in 14k so I can keep my bootloader.

Some of the design limitations I've taken on to do this:

* NO floating point- the fp libs alone take over 2k (12.5%) of the available space. I have implemented my own crude decimal fp, but use it very sparingly
* NO C++ - the abstractions are lovely on desktops, but it also creates tons of extras that simply aren't suitable for microcontrollers. A data struct and methods as regular functions provide enough of the same features.
* Minimal math in interrupt context - I was horrified to see the FiveD firmware doing significant amounts of floating point math in interrupt context. As a fairly experienced firmware wrangler, I literally cringed. Interrupts should be in and out ASAP, with (relatively) long-running calculations handled in the main loop somewhere.

Some features you may want to "borrow" from my code:
* I/O pin abstraction: pass eg DIO3 to READ(), WRITE(), SET_INPUT(), SET_OUTPUT() and they'll pull the proper ports and bits from arduino.h
* bare beginnings of a similar system for timers
* thoroughly tested ringbuffer and serial libraries
* 2d and 3d integer distance approximation routines (no fp sqrt!)

Notes:
* my temp sensor is a MAX6675 on the SPI bus. you'll have to write me a new temp.c for other types
* extruder stepper controller is hooked into arduino just like the other axes, so only one serial port needed
* I've taken significant chunks of code from the official FiveD firmware, and totally rewritten equally significant sections. I've attempted to mark things I've copied, but won't guarantee that I got them all

Major reorganisations and horrific bugs are to be expected on a regular basis, but if you want to dive in head-first and see how I'm going, download at

[github.com]

[Edit: Changed name to "Teacup Firmware" for the purposes of not confusing folk, after irc discussion. --Sebastien]

Edited 2 time(s). Last edit at 02/24/2011 12:25AM by SebastienBailard.

I will post a release of this when I have my first successful print with it. Until then, github is the only source.

HI Triffid_Hunter ()

I will be very interested to see this code when it is finished.
Good luck and happy debuging.

Stephen

P.s. Glad you are writing it in C without floats. Smart move.

This will have increased benefits with the RepRap as a whole, and could mean that the halts that some people notice would vanish as well.

update:
code is fleshing out nicely, still no testing. up to 8.75k (55%) of my maximum.

every time I go through, I find a way to reduce a few different things to one function while adding new functionality, which is how I'm keeping the size down.

probably won't have the chance to do any useful testing until the weekend, so don't hold your breath on that front.

feel free to post me patches if you try it and fix something, or help me understand git/github enough to cut out the middle man

Interesting stuff, and very worth while.

I must admit whilst being a fan of porting the firmware to other things I haven't actually looked at it yet.

I caught your blog post re floats in ISR's ouch.

Source code does always benefit from a look over by more than one developer though, It's all too easy when down in the trees to loose the shape of the woods. It's always better though to have something to look over than be starting from scratch.

Mostly I have used ISR's to move data out of harms way and into buffering of some sort. Quick in and out, then let the main code get on with processing it.

I am looking forward to having a rummage through the source when the optimizing is finished.

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Hi aka47 ()

You said
"Source code does always benefit from a look over by more than one developer though, It's all too easy when down in the trees to loose the shape of the woods. It's always better though to have something to look over than be starting from scratch."

Grin I love the poetry. Personally I believe that the reason open source code is better than closed code is because the person writing the code knows that someone else might actually read it someday and therefore is less likely to release an embarrassing mess. Well that’s how I feel when I am writing code anyway.

Grin

Stephen

i am looking forward to this release has well, but i will be using the arduino mega my self so i hope that i can modify it my self to work on it,

but this is good, i hope in time that a few more people will join in on cleaning up the code for all of the project

---

[mike-mack.blogspot.com]

looks like the DDA is working.. try it out guys. spits a ton of debug info up the serial port, currently set to 57600 baud so it can keep up. endstops are disabled while I iron bugs out of the algorithms, they were working fine for a bit and confounding my efforts

Dissidence

You should find that the Mega is supported in the Arduino IDE and the Arduino code compiles straight in.

What you will have to change are the pin allocations ie what pins are used for what purposes.

Last time I looked at the code the pins were equated to constant names for use in the code. Changing them should be simply a case for finding the definitions and swapping the pin allocations for your own.

Certainly the Mega is the way things are currently going.

I have stumbled upon a cost effective importer of the Japanese Mega clones in the uk. Try this guy :-

[www.yerobot.com]

He currently has them listed for 25UKP and does bulk discounts.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

this code is at the point where I need to sort out my electronics to test with, as the debug output looks great!

checkout latest revision and let me know what you think

been doing lots of work on this recently. Code size seems to have stabilised around 10k- every time I add features and fix bugs, I find neater ways of doing other things.

I've hooked my arduino up to a couple of my motor controllers and an ATX psu PWR_ON line for testing, and they're now moving nicely and turning off after ~30s of inactivity.

I would appreciate some of you testing and/or checking my code and giving me some feedback

has soon has i can i will test what i can for you, but it will not be too soon

---

[mike-mack.blogspot.com]

Would love to test the code but in the process of rebuilding my reprap.

Stephen

Hi Triffid,

Absolutely cool code you've written there.
I just forked the Git repo (hope you don't mind), because I'd like to try adapting your code to work on my own toy, a small CNC machine (here is some info: [letsmakerobots.com])

Until now I've been using a modified version of the RepRap firmware, adapted to use I2C to communicate with my homemade motor drivers.

It works fine so far, sadly my Atmega 168 based Arduino flash is almost exhausted, and I'm not ready to give up on it and replace it with a 368.
I need to implement G02 and G03, which, using the RepRap Arduino code adds another 1000 bytes to the 13700 already used.

I was just pondering on how to port the stuff to straight C, and I found your work.

Thank you!

TinHead,

first off, glad my work has become a useful example for someone

secondly, not sure how accurate you could do an arc with integer math- I suppose we'll find out! The tricky part is you need a *fast* routine to find the next point that can run in dda_step, unless you're willing to chop the arc up into many separate straight-line moves and get the movebuffer to hold them. As it is, the run-time of dda_step limits things to about 4000 steps/second which I'm not entirely happy with.

There's still room for a bit of floating point, remember that the fp library itself takes about 2k, let alone any code using it.

the two optimisation flags -ffunction-sections and -Wl,--gc-sections will remove any functions you don't actually use, so don't be surprised if you add fp and there's little to no increase in code size, but it explodes when you start writing a few routines that use it.

Does forking my repo mean my updates get pushed through to yours? This code is nowhere near stabilised, and there's still the potential for significant architectural changes.

Your project seems a perfect fit for me, I'm planning to go a similar route to yours with the electronics, so I grabbed the code from github.

I cannot seem to find a sketchbook for the arduino ide, what development tools are you using?

anton,
just a basic toolchain:- avr-gcc, avr-libc, gnu make, stty, avrdude and my favourite editor (kate). I find IDEs usually aren't worth the fight I inevitably find myself in, and this gives me absolute control over every aspect- check out my hand-crafted Makefile for example

just cd into directory, type

make

If you alter the Makefile to suit your system (or vice versa), you could even just type

make program

and it will make everything then send it to your arduino.

ps; here's the udev rule I use to get my /dev/arduino symlink:
SUBSYSTEMS=="usb", ATTRS{idProduct}=="6001", ATTRS{idVendor}=="0403", NAME="%k", SYMLINK+="arduino", SYMLINK+="arduino_$attr{serial}", MODE="0660"

Hi,

"first off, glad my work has become a useful example for someone"

Very useful indeed

"secondly, not sure how accurate you could do an arc with integer math- I suppose we'll find out! The tricky part is you need a *fast* routine to find the next point that can run in dda_step, unless you're willing to chop the arc up into many separate straight-line moves and get the movebuffer to hold them."

Considering my math kung-fu is not good, so I'm not sure how I'll do it, but that does not stop me to try. Dividing the arc into small segments might do just fine, the resolution of the machine is only around 0.01 mm.

"As it is, the run-time of dda_step limits things to about 4000 steps/second which I'm not entirely happy with."

Hmmm ... 4000/s converting to my 76steps/mm gives about 52mm/s, that's 3120 mm/min ... I'd like to have a machine able to cut at that speed Mine does 1000mm/min fast moves only when she likes the weather) So no problem here. I thin I2C will add some overhead to that too, so if I get 1500mm/min I'm happy.

"There's still room for a bit of floating point, remember that the fp library itself takes about 2k, let alone any code using it."

It would be easier for me to just take the RepRap routine and have it work with your code. Even with floating point it would still leave enough place for my needs, since I will disable the extruder part for now.

"Does forking my repo mean my updates get pushed through to yours? This code is nowhere near stabilised, and there's still the potential for significant architectural changes."

Not sure how GitHub does this, must check...


10x

Nope forks are not updated ... I guess that's why they call em forks

TinHead Wrote:
-------------------------------------------------------
> Nope forks are not updated ... I guess that's why
> they call em forks

But, since it is GIT, you can do all sorts of fancy stuff, like have git rebase the fork :-)

TinHead, I keep pushing lots of new stuff almost every day.. just last night I found a bug where a math operation related to move speed overflows its register if you move any axis beyond +/-71mm.

After finding that, I think my top move speed is higher than earlier stated since it was significantly affecting my estimates.

git has a rebase feature which may help keep you up to date if that's what you want

---

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

What is it about the reprapers where they all have to have their own special
version of the firmware?

Do we really think our needs are so special that we need a unique version?

Disclaimer: I am no better, I have my own custom one based on the original firmware for the arduino.

However

Could we work together and come up with a singe Gcode / 5d Gcode interpreter BIOS based on this arduino rewrite?

If Triffid_Hunter() is prepared to be the guardian of this code base maybe we should all put forward changes (bug fixes, ideas, and features) to him for approval?

Anyone have any thoughts?

regards

Stephen

stephen george Wrote:
-------------------------------------------------------
> What is it about the reprapers where they all have
> to have their own special
> version of the firmware?
>
> Do we really think our needs are so special that
> we need a unique version?

Of course! otherwise we'd buy our plastic whatevers from the shop instead of wanting to print our own designs!

> Could we work together and come up with a singe
> Gcode / 5d Gcode interpreter BIOS based on this
> arduino rewrite?

that would be interesting, especially considering the vastly differing needs of the reprap community.. Some want very intelligent firmware, others just want it to send step signals and have all the data-wrangling done host-side, and trying to force everyone into one or the other just leads to lots of different firmwares

> If Triffid_Hunter() is prepared to be the guardian
> of this code base maybe we should all put forward
> changes (bug fixes, ideas, and features) to him
> for approval?

I don't think I would make a good maintainer- I prefer to do all the fun stuff during the initial run-up to version 1 then hand it over to others who are good maintainers. I will endeavour to make it fairly easy to read though- as easy as possible without sacrificing code size or functionality anyway.

---

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

You couldn't shoe horn in a routine to clone the firmware to an identical AVR via ISP could you.... while you have got the bonnet up. (Including the bootloader)

I was thinking as you are using a makefile IDE (I do the same, it's so easy and fast) and some other folk might struggle to replicate what you have onto virgin hardware.

It might be worth considering keeping binaries for 168, 644 and 1280 in the repo, that folk could avrdude on for similar reasons.

Plus it's a backdoor way to get some functionality into the firmware I fancy.

No or you haven't got time is a perfectly good enough answer.

<|

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I posted a link to a project where someone has already written that routine. I may toss that feature in further down the track. feel free to do some research and post me an example so it's really easy for me to toss it in

---

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

[hackaday.com]

---

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

I have been using this for a year or two (posted the refs to it in the RepRap blog way back) bit now :-

[code.google.com]

Until I started working again and then bought the AVR ISP, because I wanted the Arduino back.

If you don't get chance, don't worry.

I will have a look at it after I have sorted:-

Amforth and Micro SD on the Mega on my desk.

and

[dev.forums.reprap.org]

and of course earned some more Beer & RepRap tokens....

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

ok, none of the projects I found seemed to do what we wanted, so I started writing one. It's in my git repository as copier.[ch]. It's 100% untested and almost certainly riddled with bugs. I only have one atmega, so I can't test it- it's up to you.

In other news, the rest of the firmware has reached the point where I need to do more electrical and mechanical construction for further testing and polishing.

---

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

Thanks your a star.

Just working on porting amforth to the arduino mega, it looks fairly trivial, apart from there are'nt any definition files yet for the atmega1280. So just working on those.

Joined the amforth mailing list and they are fairly helpful.

The code does compile in the AVR IDE with no errors and the wrong processor so it should go OK once I get these done.

Got the projects created for the experimental electronic stuff too, just creating the necessary parts for that.

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.