I am a retired EE, and thinking about buying an Arduino for fun and games. I am much more comfortable programming in Forth (and assembler) than in C++, and I see that FlashForth for the ATmega328P is available from Source Forge. Would that be compatible? Could I load it? Another question: is the source code for the various shields well enough documented so that I can duplicate it with the Forth compiler?
Thanks, Jerry Avins
All of Arduino the source code is available. Documentation is a different story. Open Source software generally has poor or non-existent documentation.
Of course understanding the source code requires a knowledge of C/C++ and if you know it there may be little point in using Forth.
...R
I am a nearly retired EE 8) myself. Welcome to the forum.
If you can get your program down into a .hex file, it can be loaded. I have a standalone programmer (see below) that will allow you to load a hex file from SD card, or you can take a shot at using avrdude commands to do it.
The Atmel data sheets have many example of assembly code.
Not all shields have code associated with them. You'd have to examine the ones that do on a case by basis to determine if their source code would be Forth translatable.
Forth has come up as a programming option before, if you search the forum you should be able to find some topics.
http://www.crossroadsfencing.com/BobuinoRev17/
I would just byte the bullet (hah!) and transition to C/C++. At the level you are going to start at, you knowledge of arduinos and the language can grow together.
Of course understanding the source code requires a knowledge of C/C++ and if you know it there may be little point in using Forth.
I just like telling the machine what to do instead of the compiler telling me what I can and can't. I began programming on bare iron and never really got comfortable with compilers' restrictions. (The first compiler I growled at was FORTRAN.)
Jerry
One thing that I didn't see on the FlashForth web page, etc - was any mention as to how to access and control (or read) any of the hardware GPIO; this may, however, have more to do with my ignorance of Forth, plus not reading the manual, tutorial, etc in more depth.
Once that bit is resolved, then I don't see why you couldn't use it - you'd have to research whether the downsides of using FlashForth are worth the upsides.
For instance, I can see that FlashForth on the ATMega would likely be slower to use (ie - toggling data pins, etc), and you would also have less RAM available (because the Forth environment on the controller would take some). However, in exchange you would have an interactive system, it also looked like you could have multiple processes working at the same time, and as you have noted, you're already familiar and comfortable with Forth (and assembler).
Whether those (and other) tradeoffs are worth it, would be up to you.
What you might look into, though, would be a Forth to AVR/ATMega HEX compiler - I don't know if something like that exists. You might also look into a Forth to AVR C/C++ transpiler/translator - so you could code in Forth, then convert to C/C++ and compile/upload that.
Finally, note that virtually any and all tutorials out there are going to assume you are using C/C++ for the Arduino (or ATMega) - as such, in order to utilize that material, you'd have to do some conversion yourself (and thus, have a working knowledge of C/C++ to do so). Also note that "behind the scenes" that the Arduino library (which encompasses all of the "Arduino commands" - like digitalWrite() and such) does some pretty fancy stuff which you might have to come up with solutions for, in order to emulate the functionality - if needed (you might have to delve into the C/C++ source code of the library, for instance). The Arduino library also abstracts things out from the different microcontrollers that the Arduino system can target (which can and does lead to issues - mainly edge cases related to speed); as such, if you write your code in Forth for the ATMega328 - you will probably have to do more than a bit of refactoring of your code to get it to work properly on other ATMega processors.
If all of that seems worth it, though, for the convenience and familiarity of Forth/Assembler, then by all means, have fun with it!
jyavins:
I just like telling the machine what to do
I undertstand. I dabbled with Forth many year ago. I thought it was a very clever idea. Now I am more impressed by languages that are popular because that makes it easier to share stuff.
...R
Browse the forum some, for example:
http://forum.arduino.cc/index.php?topic=8838.0
I would just byte the bullet ...
I've written more code in C than I care to remember, and some in C++ too. Also FORTRAN, COBOL, and IBM 630 assembler. Not to mention (but I am!) COSMAC, 8080, 6502, and 6809 assembler. I just figured that if a project is for fun, the programming language should be too. Maybe I'll go with the UNIX variant. (I was once a two-bit system administrator.)
Jerry
jyavins:
(I was once a two-bit system administrator.)
Eight bits, surely?
...R
jyavins:
I am a retired EE, and thinking about buying an Arduino for fun and games. I am much more comfortable programming in Forth (and assembler) than in C++, and I see that FlashForth for the ATmega328P is available from Source Forge. Would that be compatible? Could I load it? Another question: is the source code for the various shields well enough documented so that I can duplicate it with the Forth compiler?Thanks, Jerry Avins
I haven't tried any of them (too busy) but there is also AVRForth and eforth328.
So far, the eforth328 looks best to me.
No matter which you get, it works on AVRs so will have some twists if you dig deep enough.
You will need to burn the forth using ICSP as none of them use a bootloader.
Here is a tutorial on making a breadboard 'duino that does show how to load flash using ICSP.
Note that an Arduino can serve as the programmer and that Nick's chip detection and programming software is better than the official site code unless they changed the official to be his code.
Nick has a lot of good stuff on that site and he is helpful on the use of it on this forum.
There is also "amforth" that seems to be pretty active.
westfw:
There is also "amforth" that seems to be pretty active.
I think that's what I meant when I posted AVRForth.
I want to make an eforth variant to run on 1284P chips and 2560's just for the resources.
I have the ebook for eforth328, I have a chance.
BTW the hex file is free.
"One thing that I didn't see on the FlashForth web page, etc - was any mention as to how to access and control (or read) any of the hardware GPIO; this may, however, have more to do with my ignorance of Forth, plus not reading the manual, tutorial, etc in more depth."
I/O is merely a matter of reading and writing the right bits to the right address (in I/O space on some Intel-type machines).
"I can see that FlashForth on the ATMega would likely be slower to use (ie - toggling data pins, etc), and you would also have less RAM available (because the Forth environment on the controller would take some). However, in exchange you would have an interactive system, it also looked like you could have multiple processes working at the same time,"
FlashForth is subroutine threaded, and should be relatively fast. The inner interpreter isn't used at run time, and many call-return sequences are optimized to jumps. Short words ae in-lined. Because there is no need for the inner interpreter or dictionary for turn-key programs, they needn't occupy code space. An interactive environment is marvelous for debugging and great for trying out hare-brained schemes. When I worked at Siemens Research, my Sun terminal was flaky one morning. It's boot ROM was written in Forth, and it was possible to abort to the interactive prompt before it finished. I keyed in a simple walking memory test, and located a bad chip. I called the in-house maintenance people and gave them the address. They dropped their skepticism when changing the chip (they had a map) fixed the problem and asked me how I knew without removing the cover. I explained, and they became adept at using Forth within a week.
"you might look ... a Forth to AVR/ATMega HEX compiler ..."
I'm not fond of source code converters. Their output often needs to be cleaned up manually.
"Finally, note that virtually any and all tutorials out there are going to assume you are using C/C++ for the Arduino (or ATMega) - as such, in order to utilize that material, you'd have to do some conversion yourself (and thus, have a working knowledge of C/C++ to do so). Also note that "behind the scenes" that the Arduino library (which encompasses all of the "Arduino commands" - like digitalWrite() and such) does some pretty fancy stuff which you might have to come up with solutions for, in order to emulate the functionality - if needed (you might have to delve into the C/C++ source code of the library, for instance). The Arduino library also abstracts things out from the different microcontrollers that the Arduino system can target (which can and does lead to issues - mainly edge cases related to speed); as such, if you write your code in Forth for the ATMega328 - you will probably have to do more than a bit of refactoring of your code to get it to work properly on other ATMega processors."
I can read C++, and when I'm in doubt, there are friends I can consult. When speed is an issue, I can drop into assembler. (Forth supports that and many include a built-in assembler.) That lets me use compiled code from other compilers by dealing with calling-convention issues.
I don't like being bound by type declarations. I want to be able to add 4 to 'A' and get 'E' or 0x45, as I choose to interpret the result. My idea of straightforward programming may be odd, but it works for me. For a look into that, see users.rcn.com/jyavins/tantrum. It contains both 8080 and 6811 assembly code.
Thanks for the help and advice.
P.S. When I hit Preview, everything disappeared. I was prepared this time with a copy.
jyavins:
"I don't like being bound by type declarations. I want to be able to add 4 to 'A' and get 'E' or 0x45, as I choose to interpret the result. My idea of straightforward programming may be odd, but it works for me. For a look into that, see users.rcn.com/jyavins/tantrum. It contains both 8080 and 6811 assembly code.
Don't confuse type declarations with type checking. Type declarations are required to tell the compiler how many units of storage to set aside for the object.
Type declarations can really help on the AVR's with such limited RAM. You can use bytes and chars insead of ints to save space if their expected values fit.
Adding 4 to 'A' is perfectly valid in C/C++, and does not even generate a warning. In fact one of the earliest C idioms is using c- '0' to convert an ascii numeral into an integer. Characters are just small integers.
I/O is merely a matter of reading and writing the right bits to the right address
In a modern microcontroller with relatively complex peripherals, losing your symbolic register and bit definitions (that you would have in C or even assembler) to get the HLL features provided by Forth, is NOT a good trade-off, IMO. Forth was swell when the alternative was a slow basic, and compilers or assemblers were unavailable, expensive, and/or terribly slow because they had to be read from cassette tape or floppies. Today, with free cross-compilers/assemblers and fancy IDEs running on hosts with GHz CPUs and TB disks that "everyone has", Forth is more than a bit anachronistic. (I guess it's actually a lot like Arduino. If it's got the built-in functions ("words") that you need, things are a lot easier than if you have to write your own low-level code. Still, "interactive" is nice...)
Yeah but programming in forth is so nice especially when you use objects. It gets to be very natural.
You can write assembler in AMForth? Then you can make custom words to get at the ports and pins. The labels should be the same as in the ATMEL datasheet or close.
westfw:
In a modern microcontroller with relatively complex peripherals, losing your symbolic register and bit definitions (that you would have in C or even assembler) to get the HLL features provided by Forth, is NOT a good trade-off, IMO. Forth was swell when the alternative was a slow basic, and compilers or assemblers were unavailable, expensive, and/or terribly slow because they had to be read from cassette tape or floppies. Today, with free cross-compilers/assemblers and fancy IDEs running on hosts with GHz CPUs and TB disks that "everyone has", Forth is more than a bit anachronistic. (I guess it's actually a lot like Arduino. If it's got the built-in functions ("words") that you need, things are a lot easier than if you have to write your own low-level code. Still, "interactive" is nice...)
FORTH is way anachronistic. That's mostly why those of us who love it, do. 'Cept we prefer the term "retro".
I have however, come to the conclusion that I will try to be happy programming my Arduinos in C.
"Characters are just small integers."
A fellow with a recent master's degree in Computer Science once asked me, as a hardware expert (his words) how hardware knows the difference between Short Int. and ASCII. I told him that it was all the same in hardware, that the difference lay in what the program did with the bits. His experience with compilers suggested otherwise and he had apparently never done any assembly programming. The poor fool declared that I was an ignoramus and he'd get his answers from someone who knew what he was about. Oh, well!
Jerry
Engineering is the art of making what you want from things you can get.
jyavins:
A fellow with a recent master's degree in Computer Science once asked me, as a hardware expert (his words) how hardware knows the difference between Short Int. and ASCII. I told him that it was all the same in hardware, that the difference lay in what the program did with the bits. His experience with compilers suggested otherwise and he had apparently never done any assembly programming. The poor fool declared that I was an ignoramus and he'd get his answers from someone who knew what he was about. Oh, well!
It wasn't this guy, was it?
