I suppose in those days nobody was brave enough to point out that it's needlessly tedious and difficult to comprehend, because everything was difficult in those days. Not like today, with nice easy to use languages.
Where did it all go wrong and C became popular instead?
Well, you know, you haven't gotten AMForth working on your lilypad yet, despite the fact that you have existing Forth background, and AMForth theoretically runs on the chip that's involved. Meanwhile lots of people have bought Arduinos and managed to get C programs to work...
If you hear "Well, it's a lousy language, but it was easy to get running, and it was easy to get it to do things I wanted to do" often enough, you might eventually start thinking that the language wasn't so awful after all...
and AMForth theoretically runs on the chip that's involved.
Not theoretically, there's a finished hex file to upload for the Atmega168 in the distribution archive, but unfortunately only for the 16MHz version, not the 8MHz version. If it were my problem, I would contact the maintainer of that .hex file and ask if he could create one for the 8MHz version too. But then there still remains the question how to get it on the Lilypad. The documentation advises to use an ISP to rewrite the boot-loader for this, which might pose a problem if one didn't have one.
Korman
westfw, - Why? Is it about to undergo a fundamental change for the better?
Korman, - before I put it on the Lilypad I'm experimenting with a pair of Duel Mini Love boards, and that procedure simply doesn't work thus far. The board apparently now successfully flashes the other board in the 'avrdude' software (after several weeks of permutations), but then when I hook the second board up to a terminal, it is still the Arduino it always was. I seem to be doing everything right, except for getting the results.
In fact, here is my avrdude command line (I'm inside the amforth folder at this point):
ian-macbook:~ ian$ /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -b 57600 -p m328p -c avrisp -P /dev/tty.usbserial-A9007UP5 -v -F -U flash:w:appl/arduino/duemilanove.eep.hex
and
ian-macbook:~ ian$ /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -b 57600 -p m328p -c avrisp -P /dev/tty.usbserial-A9007UP5 -v -F -U flash:w:appl/arduino/duemilanove.hex
(not sure what the difference between the .eep.hex and the .hex is - presumably the first one had just seen a mouse).
Is it about to undergo a fundamental change for the better?
If it's seen by many as a fundamental change for the better, it happens. If such a fundamental change for the better was available for the past 20 years (that's how long I know about Forth) and didn't happen, your fundamental change either isn't as fundamental as you see it or isn't as good. Most likely it fails to address the real problems people need solved and address just irrelevant cosmetic ones. After 20 or 25 years you can rest assured that Forth has the place it deserves as a development tool.
Korman
It's all down to whether a language is approachable or not. If it is hostile, people (other than technicians and engineers) will be repelled by the bad taste it leaves. There needs to be a soft, comfortable, forgiving and above all, easy to understand language for the Arduino. This C stuff is for experts. I'm not saying take C away, I'm saying put something else in there as well, for the beginner to transition into Arduino programming with.
Bitlash is currently on one of the Lilypads, and it's excellent, except there's no examples or existing code to try, so it has a limit to how much I can learn.
Forth is what I've already been exposed to in the past, and found it immediately understandable, and simple, but I never got very far in it because it can get a bit technical at times. However, I did manage to complete a few simple programs when I was using it (on my old Dragon 64, decades ago) (which I seemed to have spent more time hardware modifying than using — it ended up with an internal SMPSU, piggyback CoCo forth rom with a chip select switch on the case, and some other mod with the RS232 interface that I forget the details of now). I thought Forth was the ideal language for hardware-level microcontrollers.
Well, I looked at AMForth. What horrible installation instuctions! What awful build environment assumptions! What kludges!
ATmega8 doesn't seem to build at all, probably never has (differences in the way UART register and bit names are defined.)
ATmega168 compiled! ATmega328 compiled!
Unfortunately, I don't have spares of those around, only spare mega8s. Or maybe I just need to hunt harder...
My "maybe C isn't so bad" comment was meant to mean that people aren't always the best judge of what makes a language "good"; APL was written by real computer scientists who thought they were doing a good thing, and C was hacked together my some hippies that wanted to get work done. But evolutionary forces have resulted in what we have now, where C has evolved to become very common, and APL has all but disappeared...
Bitlash is currently on one of the Lilypads, and it's excellent, except there's no examples or existing code to try, so it has a limit to how much I can learn.
Ah, it's excellent but doesn't work for what you need. I prefer something a little raw that works instead. And many other people too.
There needs to be a soft, comfortable, forgiving and above all, easy to understand language for the Arduino.
To stay with your terminology, the raw electronics and bit-twiddling you're exposed to with the Arduino are harsh and unforgiving. Forget a pull-up resistor - get garbage data. Connect a motor without driver - fry your processor output. Have noise on the power pin and no decoupling - system fails in strange ways. Same with software: Recurse too deeply - put random garbage into your variables stored in memory. Use too many pass-by-value string calls in a call stack - run out of memory. Write to EEPROM everytime loop() is executed - kill your EEPROM in a minute or less. Set pinmode() in the wrong order if pins are connected - fry your pins. Spend too much time in ISR - read garbage data from you pins or get Servo-jitter. And so on and so forth, the Arduino simply isn't a cosy and forgiving system system you dream of. If you try to make it safe, you lose a lot of its functionality. Lego went this way in a similar situation, National Instruments went the other way and put a lot more processing power into their boxes so they work with LabView properly.
If you really feel the need to have an easy and safe software development environment language for the Arduino, create on. All the people in a similar situation as yours will thank you.
Oh, you can't because you don't want to spend the time to do it or learn how to do it? Well then buy one of the available easy ans safe solutions.
Oh, you don't want to spend money either? Well then you really just can sit in the corner and feel sorry for you.
As to your Forth, why don't you use it on your Lilypad? Why didn't you contact the maintainer and ask for help? Did you bother to spend $20 on an ISC to put a Forth image on Lilypads? If not, have you considered offering a small contribution for a Lilypad with the Forth loader installed?
Korman
Learn C. Then take Lua for a whirl.
You need a C ref, Practical C Programming (oreilly), and the 2 Lua books(amazon or lua website). Thats all.
In addition you should learn how to install and drive a gcc toolchain like winAVR using a editor like Scite, or Vim or Emacs.
These are the foundations that you can build on. After that you can learn most other languages and tools easily.
I would vote for C/C++ as well. In the end it helps a lot to understand what the hardware does. Java is just one step to far away. That is C/C++ skills translate to Java. The other way round is questionable.
Anyway: once you know one language you have to understand that there are other languages that may be much better suited for what you are doing. It always depends on what you want to do.
Although somewhat unpopular Forth is pretty cool if you need to be close to the hardware.
Udo
I suppose in those days nobody was brave enough to point out that it's needlessly tedious and difficult to comprehend
orbitalair, - where does Lua fit in?
Although somewhat unpopular Forth is pretty cool if you need to be close to the hardware
Being close to the hardware is precisely the reason C was developed.
Think of it as a high-level, platform-independent assembly language, and you won't go far wrong.
AWOL -- that unix article / link is so funny and enjoyable -- thanks!
I've been reading a bit about Lua and it really looks quite interesting.
eLua, though, seems to fit larger AVR processors than the Arduino typically has. Otherwise, eLua might actually be very interesting as a starting point.
AWOL: I thought the same about Forth. Until I did some project that applied some really nifty tricks to push the hardware to its limits. Then somebody pointed out to me that what I was doing was reinventing Forth. Now I have a completely different opinion on Forth. Of course 99% of the time I will not implement anything in Forth. But sometimes Forth even beats assembler. Especially on the AVR.
I can and will code in a lot of languages. My conclusion is that almost any language has some benefits in at least one domain. If you always happen to code outside the domain you might not appreciate them. Prior to this project I would have never imagined that Forth could be useful for me.
Actually I did not really use a standard Forth but a dedicatet Kernel for my own purposes. In addition I know some hardware expert who implemented a Forth kernel in order to have a portable test suite for micro controllers. So my conclusion is that Forth is worth to investigate.
Udo
So Ian: what DO you have in the way of equipment for reprogramming your lilypad? What OS do you have? I succeeded in building an AMforth for mega168 and mega328 at 16Mhz (maybe, anyway) (using Windows) but am wondering how I should proceed with trying to actually load it into a Arduino...
But sometimes Forth even beats assembler
That's...difficult to believe.
Of course this is hard to believe. But think about it: with the AVR you can not execute machine code from RAM, Forth programs will be "interpreted". Hence you can write a very tiny compiler to generate forth programs inside the AVR. The actual call overhead penalty of the tokens is outweigthed by the speedup due to the self modifying code. That is I wrote a program in C that will generate a Forth program in a tiny subset of Forth that consists of dedicated Forth statements hand coded in Assembler. Hence I can reconfigure the really performance critical stuff at runtime. In order to beat this I would have to reflash the controller at runtime. Then machine language would be faster again. However this would make my compiler much larger and might wear out the flash since I reconfigure quite often.
Although I have >10 years assembler experience and >25 years of programming experience in various languages I would not even try to do something like this in machine language in such a tight space.
Udo