Amforth and RepRap

Guys

I have just been having a rummage through the latest release of amforth.

Their latest release 25.4.2010: release 3.8 is now available for download and supports pretty much (with a minor exception) the processors that the arduino and variant run on.

168, Diecimila
644, Sanguino

There is not as yet an explicit 1280 configuration but there is a 640 configuration which is the same as the 1280 but with half the memory. So a copy of the 640 file s and a minor tweak should support the Arduino Mega.

All in all the guys over there have made some outstanding changes and they are part of the core distribution. Most excellent.

The Amforth (Forth for the Atmega) web site can be found here

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Below is an excerpt from a reply from Mathias the Amforth Guru on creating a 1280 hardware definition. As well as feeding back into Amforth so that the base Forth system benefits too.

There looks to be a lot of potential experimental synergy between the two projects.

It is interesting to note that Amforth supports Interrupts, Multitasking and is a 16bit implementation (The forth words are 16bit). Even though it is running on an 8 Bit Micro.

Next step, copy the 640 definitions, tweak then and compile them as a basic 1280 (but with 64k Flash). I will try this out on a spare Arduino Mega I have kicking around.


--- Snip Here For Mathias's reply to my queries ---

> > The one processor that was short for me was the 1280 (Arduino Mega)
> > which is pretty much a 640 but with 128k of memory instead of 64k. I am
> > just about to set too and have a go at compiling for the 1280 and will
> > mod the 640 file (I assume this is still the way to go, although the
> > headers claim that the files are auto generated)

The files are generated with the pd2amforth utility, but edited
afterwards,
there is no complete toolchain to implement the files for a new controller
type. The manual changes are mostly trivial however...

> > Questions.
> >
> > Who do I need to feedback difs changes tweaks etc to to get the final
> > 1280 dev files into the distribution (at some point) ??

Just send them to me directly. There is a patch tracker at the
sourceforge project site as well, it will reach me either way..

> >
> > Which variables do I need to tweak to increase the memory size?? (a
> > quick win hopefully, for my first attempts)

You may use the at90can128 file as a starting point since it already
has all the changes needed for the 128KB flash [1]. Another hint is: use
the usart words with polling access. The interrupt driven IO may
sometimes be very frustrating to get working.

Then there should be only a very few addresses to check:
Usart ports, RAM start/end NRWW start address. Anything else
should be left unchanged. At least for the first try ;=)

Matthias

[1] The 128KB flash are seen as 64KWords to fit into the 16bit address
range, and there are a few other instructions to use. And finally the big
atmegas are slightly slower when accessing the flash since they need
to execute more instructions. But thats all hidden inside a few macros.


------------------------------------------------------------------------------

_______________________________________________
Amforth-devel mailing list
Amforth-devel@lists.sourceforge.net
[lists.sourceforge.net]

---

Necessity hopefully becomes the absentee parent of successfully invented children.

The current developer version of Amforth now has a template for converting an Arduino Mega into a Forthduino.

Note this is not the curent release but changes that have been made to the trunk source since then. So you will need to pull down the current version from Sourceforge using SVN.

[sourceforge.net]

The template builds and loads onto an Arduino Mega.

I have got this far and now need to run some tests. But basicly Forth is now available specificaly for the Arduino Mega.

I returns the usual Forth ok prompt and identifies itself at boot.

Note this overwrites the Arduino Bootloader. If you want to return the Arduino Mega back to service as Under the Arduino IDE and libraries etc you will need to erase the flash and program the bootloader back in.

I have a bit more work to do on the forthduino template but it is good to play with for now and all feedback through the amforth project is welcome.

Note the templates are now part of the trunk and as such should enjoy a degree of support going forward.


Cheers

Andy Kirby (aka47)

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Awesome work Andy.

This seems something I'll want to try out, as soon as I can get my head out of the math for motion optimization.

Question - it sounds easy to change an Arduino Mega bootloader into a Forthduino... does it require a separate bootloader device to return it to Ardunio? That might put a little bit of a damper if you wanted to just try out forth for a little bit without losing the arduino functionality (Unless you happened to have the bootloader device..?)

Actualy you program them both the same way.

Use an ICSP programmer and the binary images.

Options for the ICSP programming are AVRDUDE and one of the following a second arduino with the AVRISP sketch loaded (in the examples section of the arduino IDE), A pony programmer, an Atmel AVR ISP MK2 etc etc etc.

I have a set of fuse settings too that seem to work at the moment. Still early days yet though.

I used to use a spare diecimilla with a strip board sheild and the arduino AVRISP code to burn bootloader images onto blanck atmega168's etc for projects I was working on (includeing a dedicated Arduino AVRISP, so I could have my diecimilla back). At the moment I am using the Atmel AVR ISP MK2 with AVR Studio to develop the tamplates for the amforth project so that we can use amforth with arduino boards.

Next stop when I have finished with the Arduino Mega (still a little bit of work to go, I want interupt comms running before I move on) is to look at the 644 or 644p (Sanguino) which would enable folk to run amforth on makerbot controllers etc if they wanted to.

When you want to play PM me an email address and I will email you a set of thge binary images (to date) to save you needing to toolchain.

The amforth folk are not keen on hosting prebuilt images I think due to the work overhead of maintaining them etc They are of course focused at a wider audience than our arduino oriented selves.

At the point we have stable images I will perhaps put up just the ones we need (168 328 644 and 1280) in the repository (when we get one)

I am not sure which way folk want to work with forth firmware development yet. Certainly git github and a repository would make it available to a wider group of contributors.

At the moment I prefer having images that cover the current release of Amforth only and then keeping the firmware as forth source code to ascii squirt into the imaged devices/boards. I guess it can be tweaked more easily then before load. As well as after load of course.

The guys over at Amforth are currently thinking about the posibilities of implementing a cloning capability to allow a functioning forth system to clone itself onto a blank device/board via ICSP. But only to identical devices due to hardware differences. When and or if this comes off I don;t know yet. It would certainly make the firmware as RepRap as the hardware........

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Update

The Amforth Project has now released version 3.9. (hot on the heels of 3.8)

This includes the forthduino (amforth on the Arduino Mega board) template sources if you want to modify them and roll your own.

It also includes some ready to go demo hex and eeprom files to drop onto your board using the ICSP programmer of your choice. Great for a quick start.

I think this is the core setup only. There are a whole bunch of libraries in the project that are forth code, ready to ascii squirt onto your core/demo setup when you have got it going.

Matthias has also done similar for the AVR Butterfly demo board. Could be useful as a control console maybe ???????

The guys on the amforth developers mailing list are very helpful, approachable and very interested in Forth per ce.

If you write aditional general purpose routines for anything including hardware, memory cards etc etc, be sure to contribute them to the Amforth project as well as here. email them either to the list or to Matthias.

Cheers

Andy Kirby (aka47)

---

Necessity hopefully becomes the absentee parent of successfully invented children.

OK for completeness and comment, heres a cut and paste of a PM conversation I have been having with RBisping.

We had a talk about some stuff and found that there was so much that was worth while we concurred it was worth reposting over here.

---------- Snip Here ----------------


> RBisping Wrote:
> --------------------------------------------------
> -----
> > aka47 Wrote:
> >
> --------------------------------------------------
>
> > -----
> > > I think I agree that there is perhaps some
> > mileage
> > > in going with a host/printer protocol that is
> a
> > > little more specific to the task and
> firmware.
> > i agree that having a infix gcode format for
> the
> > forth firmware would be simpler and faster.
> > and It may be better to have a preprocessor
> that
> > just reformats a standard gcode file.
> > it might also be posible to have the firmware
> > capable of reading the stl file directly and
> > creating its own code.
> > It will realy depend on how well we can stuff
> the
> > processor.
> >
> >
> > >
> > > To get there thought I think it is wholly
> > > necessary to embrace the legacy protocols to
> > get
> > > most buy in. and perhaps then offer in
> addition
> > > another protocol for those on the zen path
> > (That
> > > would include me of course).
> > >
> > > Whichever Host/Printer protocol folk actually
> > > eventually go for, the underlying forth
> > > constructs, data, middle layer and hardware
> > > driving primitives will be the same. So is
> > > definitely not a waste of time.
> > >
> > > It is almost perhaps worth considering
> > > implementing something along the lines of a
> > > shunting yard algorithm or wrapper (turns
> Infix
> > to
> > > Postfix) as a protocol front end that then
> more
> > > naturaly presents the standard GCode as a
> forth
> > > ready command protocol (Prefix to Postfix).
> > >
> > > This is I think definitely worth raising as a
> > > discussion piece in the amforth discussion
> > area.
> > > Along with an analysis drive of the current
> > > firmware to draw out the algorithms for re
> > coding
> > > (and maybe how, if at all, we document the
> > > underlying algorithmic structure of the
> > firmware
> > > so more folk can work on it concurrently).
> > untill i get my hands on a running board it is
> > still just theoretical to me, but the odds are
> > converting the current firmware concepts to
> forth
> > should be trivial. and depending on wheither
> the
> > amiforth for the mega has turtle support it may
> be
> > as simple as making a modification of that
> system.
> > though it wasnt made or designed for a
> cartesian
> > system. and while i think this will be a realy
> > good variation on standard reprap firmware im
> not
> > sure how far im going to be able to devote time
> to
> > it with all the other projects that im working
> on
> > right now.
> >
> > >
> > > Would you like to start the ball rolling ??
> > >
> > > I will sort out a wiki page/s to document
> some
> > of
> > > the ideas and direction to make for easier
> > > understanding etc especially to late comers.
> It
> > > would be a good place for diagrams etc to
> > > illustrate concepts.
> > >
> > > There is always a risk with Open Source that
> > you
> > > loose the will to live and die as a result of
> > > answering the same questions over and over
> > again
> > > for each newcomer. They do need the info
> > > though...
> > >
> > > Cheers
> > >
> > > Andy Kirby
> > >
> > >
> > >
> > >
> > >
> > >
> > > RBisping Wrote:
> > >
> >
> --------------------------------------------------
>
> >
> > > -----
> > > > understood. this just means i have to pick
> > > myself
> > > > up another mega soon smiling smiley
> > > > writing firmware for a reprap in forth
> > shouldnt
> > > be
> > > > much of a chore though. The hardest part
> > might
> > > be
> > > > the gcode interpreter portion.
> > > > I understand that sending rpn forth gcode
> > would
> > > be
> > > > simpler and probably what should be done
> > > initialy
> > > > but making the firmware able to take
> standard
> > > > gcode would be better in the long run.
> > > >
> > > >
> > > > aka47 Wrote:
> > > >
> > >
> >
> --------------------------------------------------
>
> >
> > >
> > > > -----
> > > > > There is no bootloader as such with
> amforth
> > > you
> > > > > write all the core in one go.
> > > > >
> > > > > The ballance is ascii squirted as needed.
> > > > >
> > > > > This does over write the arduino
> > bootloader.
> > > > >
> > > > > So do need a programmer to get your
> images
> > on
> > > > and
> > > > > to restore an arduino bootloader if you
> > want
> > > ot
> > > > go
> > > > > back.
> > > > >
> > > > > Note at the moment this is only the forth
> > > > system
> > > > > there is no actual firmware writen in
> forth
> > > yet
> > > > to
> > > > > run a machine. Having a mega that is
> runnin
> > > > forth
> > > > > though is the first step.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > RBisping Wrote:
> > > > >
> > > >
> > >
> >
> --------------------------------------------------
>
> >
> > >
> > > >
> > > > > -----
> > > > > > I had seen your post on this or at
> least
> > > that
> > > > > you
> > > > > > were starting it the other day
> > > > > > now. Will this require burning a new
> > > > bootloader
> > > > > or
> > > > > > will it install like normal firmware
> > > > > > if it completely removes the origional
> > > > arduino
> > > > > > environment I probably won't be able to
> > > test
> > > > it
> > > > > > till I pick up another mega. My only
> > > current
> > > > > one
> > > > > > is in my Mendel right now.
> > > > > >
> > > > > >
> > > > > > aka47 Wrote:
> > > > > >
> > > > >
> > > >
> > >
> >
> --------------------------------------------------
>
> >
> > >
> > > >
> > > > >
> > > > > > -----
> > > > > > > Amforth now supports the Arduino
> Mega.
> > I
> > > > have
> > > > > > just
> > > > > > > completed the first cut of the
> template
> > > > files
> > > > > > and
> > > > > > > they are in the Amforth trunk
> > repository.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Just for clarification, I think people may not quite understand the "ascii squirt" concept.

Feel free to correct me if I am wrong, but, the connection from host to firmware becomes a forth interpreter / compiler. Send the ascii characters "1 3 + ." on the serial line, and you'll see the arduino write "4" as output. Type: ": SQUARE DUP * ;", and you've just asked the arduino to compile a new function that, when executed, squares the previous number. If you then type "3 SQUARE .", it will output "9".

In this sense, the 'protocol' is not GCode, byte code, or any other code. It is a forth programming environment. Send it the forth code to execute GCODE, and you can then send the GCODE, and it would work about as well as a C compiled firmware (perhaps a little slower). Send it the forth code to execute SPLINE MOTION, and then send it SPLINE motions, and you've just changed the function of the device.

In essense, the forth language itself becomes the "bootloader".

Yeah that's pretty much it.

With forth the compilation of your source code is done on the controler board, not on your PC.

As you point out the native session is interactive (unless you have set a turnkey word up in which case it boot s straight into the app you told it to run).

The interactive session is designed to communicate with people and has no apparent flow control (it does, but it is a people one).

Before the days of the Internet (and still for embeded systems, particularly ones that are self contained) people used terminals or terminal emulation software to talk to other computers, modems and devices. (Any one who has spent time with data comms kit will be familiar with this).

We use the same terminal software to talk to an embeded forth systems and do the interactive thing.

When you have a lot of source code to initially load onto a forth system rather than typing it all in a line at a time using people/terminal protocol it is a clever dodge to use the ASCII file transfer options in your terminal software to literally squirt the text at your board. In theory you could cat a source file at the serial port on your linux box and get a similar effect.

The transfer completely ignores the boards responses and just send it all at the board, Hence "squirt".

Note with Amforth being a flash device once loaded it is there for ever after until you interactively erase it and reload your source. Even when you turn it off then back on. Hence your sugestion it in this limited way is like a boot loader, but much more versatile.

There is a caveat the ASCII squirting does not recognise people oriented flow control. It literally squirts the text at the board and ignores responses. Hence no flow control.

To get around this we can use character pacing or a script/program to do people protocol.

Character pacing, Set a low baud rate or put a delay between each character sent such that the stream of information arvies at the board just slower than the board can handle it. (Still squirted though)

People protocol. You don't recognize it but you use a transfer protocol when you are typing information in. It is a method to down load information from your head into the computer. Each character you type is echo'ed to the screen so you can see what key you pressed (if necessary correct it) and that the system has accepted it (it does'nt echo it until it has got it). When you have typed a line or command and want the system to do something with it you hit the "enter" key. The system knows you want it to do something with the information you have given it and will respond with an error message or the command prompt when it is ready to do some more. This is people oriented protocol with flow control.

OK - you say, thats all well and good, why not write up a simple script or program to do the source file transfer and emulate people protocol including flow control.

The simple answer is that the Amforth guys have done this, there is a script provided in the download.

Personally I usually just set the baud rate slow and ascii squirt. But will be using the provided tool/script for larger initial transfers.


Hope this clarifies.

Cheers

Andy Kirby (aka47)

---

Necessity hopefully becomes the absentee parent of successfully invented children.

An addendum to the above.

You squirt/load your source straight into the forthduino.

The forthduino compiles and stores it all, then you run your code.

When running the protocol on the serial link is what ever you coded it to be in your source.

So if you want 100% Makerbot compatible GCode protocol that is what your code should have been writen for and what you will get.

Once the initial firmware load has been done (unless your developing from scratch that is) you can interactively tweak, test, modify and extend your firmware without reloading again. Using forths interactive capabilities. ie It is it's own development system. You can also modify and tweak all those machine specific parameters without reloading and recompiling the whole lot again.

That is one of the great advantages of using forth in a R&D or hobby environment.


Hope this helps

Cheers

Andy Kirby (aka47)

---

Necessity hopefully becomes the absentee parent of successfully invented children.

something i was thinking about with the mega. I intend to install a sd card on mine or at least the forth one once i get it purchased. Having a forth routine that can be called that then takes a gcode file input and stores it on the sd card in forth formated gcode that can then be printed directly off the sd card would be rather optimal and not too dificult to impliment either.

Must think more....

It should be doable.

Forths block routines etc are already done to death and readily available. Interfacing should be dead easy too. Take a look at adafruits latest datalogging card for some ideas.

The SD SDHC and Micro SD/SDHC cards all look to use SPI as well as the SD interface. Most embeded implementations I have seen take advantage of this to use a minimalist SPI interface.

I have a couple of 2G micro SD cards kicking around here waiting time to do something with.

Buffering and replaying prints is definitely a killer app. Machinery should idealy have the files on board to build them selves as well as have space to add more. You could build one machine from another then without ever needing a host.

Being able to print several copies of an object at a time using ofsets could be do-able as well. Saving having to create huge build files that have copies in them.

Just on with expanding the forthduino additions to the Amforth project to take in the Sanguino, Diecimilla and Duemillanova. ATMega's 644, 168 and 328. A Duemillanova with 328 has just arrived for testing.

These then should cover just about all of the ATMega based boards that are in play at the moment, enabling experimentation with alternative firmware. Including all the Makerbot and extruder boards too.....

Exciting things.

Cheers

Andy Kirby

---

Necessity hopefully becomes the absentee parent of successfully invented children.

well, i picked up a second mega and have (i believe) installed the forth kernel into it. but I havent been able to find any real documentation on how to talk to it. Im not sure if i just have my speed, parity etc wrong or if the programs im trying to use to access it are inappropriate.

Any info would help
though i will keep working on it regardless

hmm, ok never mind the first question. apparently it didnt install the hex properly. so, am i going to have to compile this myself or is the hex file in the directory supposed to be complete

I can not vouch for the binary file from the Amforth repository as I didn't generate it. The project folk are usually pretty good though. You need two files the eeprom file and the hex file. In the readme.txt file there is a note of the fuse settings to burn.

Default speed etc for the serial is 9600 8N1.

On linux the MEGA's usb serial port usually comes up as ttyUSB0. It only come up after the board is plugged in though.

As I use linux I tend to use minicom as a terminal to talk to the board. (It does ascii file transfer too to squirt pre-writen forth code into the board).

So in order you will need to ....

1. Plug in Mega Board
2. Open up minicom
3. Make sure settings are for 9600 8N1 and correct ttyUSB is set to match what linux thinks your board is at. (usually ttyUSB0, but could be different on someone else).
4. press reset on your board.

You should now get a short line telling you Amforth and the version followed by a > prompt.

Forth away....... (Go forth and multiply?? lol)

Typing: "words" followed by return (no quote marks) should give you a list of the words that are loaded. as you add more words you should see them added to the list.

A simple first forth program is usually something like

: hello , ." hello world " ;

which can be run by typing "hello" followed by return.

This should printout hello world to your terminal.

If you then type "words" you should see the same list of words earlier but there will now be an extra word defined as hello. You can run this any time now as it is compiled and stored in the controllers flash.

Interactive in situ coding, Easy peasy huh.

Any info needed ask here, it is worth putting up publicly for anyone else that wants to follow a similar route.

Any one wanting to shortcut the build process pm me an email address and I will email you the hex and matching eeprom files, that I have successfully programmed in..

I apologies if I have told anyone something here that they already know, whilst answering questions I have tried to explain enough to help a newbie.


Hope this helps


Cheers

Andy Kirby (aka47)

Edited 2 time(s). Last edit at 06/19/2010 08:57AM by aka47.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

There shouldn't be a comma after hello. I.e.

: hello ." hello world" ;

---

[www.hydraraptor.blogspot.com]

haha, thanx for the info. and most of that i know pretty well but its the specific of loading it on the mega that is being a issue. ive already changed the fuse settings to yours (though ff turns into f7 for efuse) but it should still be fine there.
when i do the upload and then verify it says

first mismatched byte 0x10000
0xff!=0x0c

ive been using hyperterminal in windows so far and it just seems to be not respoding. no echo no ok.

so far all ive been trying to load is the hex file. what do i do with the eprom file and how do i install both simultaneously without one erasing the other?

I probably just havent read the instructions thouroughly enough or close enough but i dont see it when i go through it

ok, i think i found where i need to put the eep

OK Guys

Finally got some time to string together a few minutes and work on the amforth images.

I now have images (hex and eep files) for:-

Diecimila (ATMega168)
Duemilanove (ATMega328, use Diecimila for ATMega168 Duemilanove)
Mega (ATMega1280)
Sanguino (ATMega644p)

Only the Sanguino image isn't tested because I don;t currently have a board that isn't a part of something I don;t want to take apart.

Anybody who wants a copy of these Private Message me your email address and I will email you the zip by return.

There is a brief readme.txt in the zip file that has the fuse settings that worked for me.

Cheers

Andy Kirby (aka47)

---

Necessity hopefully becomes the absentee parent of successfully invented children.

thanx for the hex files mate. I now get all the way to version on reset but no prompt so seems something is still missing. not sure what though.

when i do a upload i still get the error message when it compares the written to the origional. though not sure what keeps getting lost or if its just that it keeps comparing past the written part.

Is there a order that the hex files should be installed in? i.e. does one get erased if you load them in the wrong order or something.

i think i need a little more info to be helpfull.

can you describe your programmer. programing tools and paste your invocations in her so i can look over them ?

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

OK

I have run up my development system and made a note of the programming sequence that AVR Studio programs my Duemilanove board.

**** Snip Here *****

Getting isp parameter.. SD=0x06 .. OKOKOK
Reading FLASH input file.. OK
Reading EEPROM input file.. OK
Setting mode and device parameters.. OK!
Entering programming mode.. OK!
Reading signature .. 0x1E, 0x95, 0x0F .. OK!
Signature matches selected device .. OK
Erasing device.. OK!
Programming FLASH .. OK!
Reading FLASH .. OK!
FLASH contents is equal to file.. OK
Programming EEPROM .. OK!
Reading EEPROM .. OK!
EEPROM contents is equal to file.. OK
Writing fuses address 0 to 2.. 0xFF, 0xDB, 0xFD .. OK!
Reading fuses address 0 to 2.. 0xFF, 0xDB, 0xFD .. OK!
Fuse bits verification.. OK
Leaving programming mode.. OK!

Fuses:

Extended 0xFD
High 0xDB
Low 0xFF

***** Snip Here *****

This should give some indication of the order AVR studio thinks it is best to do stuff. Which seems to work for me.

Something I did notice is that the fuse bytes are programmed the other way around to how I noted them in the readme.txt file. I recorded them as per the fuses statment above but the ordering of the fuse bytes for programming acording to the capture above is reversed.

Check out the ordering of your fuse bytes............

If they are the wrong way around something will be screwed up.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

well, i did try redoin the fuses as per your email and still no boot. i get a deviation in the writing and reading of the hex file at 0x10000 and the eep file at 0x02
i will have to retry it again and see if i can cut and paste it into a window.
but im in the middle of moving so it might be a few days.
oh im using the programer from makerbot a usbtiny.

Nophead.

Well spoted, thanyou sir. Indeed no comma.

RBisping.

Fine whenever you get to it. Good luck with the moving. Not seen the makerbot programmer. I use/d the megaisp stuff from source-forge originally followed by the isp from the arduino 18 ide. designed and built my own using the same stuff but disabled the auto reset as this tends to screw things up and eventually when I git a new job bought an atmel avrisp II.

All have worked great for me with the exception of the auto reset issues and the arduino boards.

I will take a look at the makerbot one. Your problems looks to be more likely programmer/programing related rather than image related as I have helped some other folk along with the same images and they are working fine.

Cheers

Andy Kirby (aka47)

---

Necessity hopefully becomes the absentee parent of successfully invented children.

i also believe it is a issue with my programmer but so far havent found a answer, also havent had time lately to work on it more either.

Thanxs for the help and future help

Make a minimalist Atmega 644p/1284p Based Micro-Controller

If you want a fun way to start with Amforth, a DIY Sanguino, a DIY RepRap Controller or just an Arduino compatible with more welly this one is for you.

This project was inspired by the Arduino and the Sanguino but was primarily for use as a RepRap Controller and general purpose Amforth development board.

[aka47.adsl24.co.uk]

The board also features an as yet untried first atempt at built in cloneing capability. If the Master board SPI peripheral won't perform as planned there is always the fall back of bit banging.

Cheers

Andy Kirby

---

Necessity hopefully becomes the absentee parent of successfully invented children.

On programming in the images, the devices seem to be picky about the fuse settings someone else was having similar-ish issues over on the Amforth mailing list and Erich Walde came up with some different fuse settings that fixed it.

So trying different fuse settings or having a rummage through the Amforth mail list archive might be useful.

Cheers

Andy kirby

---

Necessity hopefully becomes the absentee parent of successfully invented children.

ok, ill check that out. i got a couple more mega's the other day and tried dl again and got the same results, i was able to reinstall the origional images though.

i have got a few more tasks to tidy up then i will build images from the latest amforth release and put them on my blog/docs site along with the diy 1284p board design that is already there.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I would like whatever files you have that you were able to compile on the atmel compiler. I have had 0 luck in getting the files in the zip file in the right order or edited or whatever it is that I am supposed to get them to compile. I am trying to target the 1280. If there is anyone that can send me a zip file that actually compiles to the target I would be eternally grateful. Thank you in advance ~ keith