Hi John and Brad, > This cross-pollination > should benefit both communities: MSP430/CamelForth and AVR/Amforth.
I hope so. Exchanging forth code would be great. Flashforth recently imported the I2C routines from amforth. I haven't looked at the details, but my impression is, that it was not a 1:1 import. If either side now makes a change, the code base diverges and that is bad. My dream is, that different forth's and different forth vendors come together and create a common code base for basic routines: I2C, LC displays, PWM, TCP/IP, 1-wire, you name it. A system like camelforth that is available for many platforms has/may have less trouble here. Amforth has got some features that are not very common among microcontroller forth's: exceptions, wordlists, recognizers. I see no reason why they can't be common code that is used verbatim in different systems. Exceptions as written by Mitch some 20 years ago are a good example. Small, clean and almost portable (some stack pointer voodoo, the basic words are needed anyway) My combined source tree has them that way for both systems. Stack pointer handling in avr8/msp430, throw/catch in common. Wordlists and recognizers depend on a persistent configuration stack, the interface are system specific map-stack/get-stack/ set-stack words. Everything else is common code. With the camelforth merge I can see which words are really specific and which are common. Having a single file for each word definition is a good thing (tm). Another thing are tastes like ACCEPT. Some behaviours could be seen as bugs: My version of it does no longer underruns the terminal line with backspaces, it stops at index 0 at the terminal output echo as well. Nothing to worry about. Another is that I love the unix shell look'n'feel: the enter key starts a new line where the program output is placed. The usual forth command prompt > 1 2 + . 3 ok > is confusing to me. Where did the user input stop and the program output starts? I work with shell prompts all day, so I'm used to > 1 2 + 3 ok > Here we will never reach consensus, we should not try to pretend achieving it. ACCEPT *may* be common code, system specific can override it however. A remark to naken_asm It is a great tool. I love it. Amforth started with another opensource assembler (avra) that unfortunately died shortly thereafter so I had to use the Atmel assembler. naken_asm would be the number one tool if it could handle the amforth sources without (much) changes. I'd love to keep the Atmel assembler working, for two reasons: many amforth users use windows and like it and the other is the bad experience with avra. Atmel has an interest in selling chips... the avra people lost interest. > A minor correction: TI did sell a Stellaris Launchpad that used an > ARM-based micro, but I believe that you're referring to the MSP430 > Launchpad here. Oops, the box I unpacked is labelled MSP430 Value Line / Launchpad Development Tool. Another, very similar looking box is labelled Stellaris Launchpad LM4F120, an ARM system it seems. Good that I picked the right one. I should ask my friends from forth-ev what they sent me. Looks like a trojan horse. Mike? ;) Matthias ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
