Go Down

Topic: Interested in Arduino (Read 4 times) previous topic - next topic


So you have a mega328 8MHz based Lilypad, and something that will do ISP programming (ArduinoISP on a breadboard?)  If I were to provide an AMForth.hex file compiled for an 8MHz 328, you could burn it on your lily pad and give it a go?


Nov 21, 2010, 01:09 am Last Edit: Nov 21, 2010, 01:17 am by Happyman7 Reason: 1
By Earthshine, do you mean this document? It believe it is talking about this kit.

edit: Wow, I need to refresh before posting..


All I want to do is actually use it, not learn to be a computer programmer (or even learn enough to pretend to be one).

Well the problem seems to be with your expectations. The Arduino is based on the Atmel AVR programmable controller. So if you won't/don't learn to program it then it's probably the wrong solution to whatever you are looking for?



Nov 21, 2010, 05:14 am Last Edit: Nov 21, 2010, 06:01 am by John_Smith Reason: 1
Code: [Select]
Do I need to know C or C++, or any other coding to use Arduino?.

Not at all.
I have been learning the Arduino for 2 months now, and am hooked.
Its not the hardware , I also use the STM8S-Discovery kit which is much cheaper and better according to the guy I have had to have program them,  but that's the difference ...

It doesn't have 33,000 people like this community, many of which are obviously way ahead of this simple device, but are there to help us when we miss out a = sign or whatever.

Apart from tinkering a few lines of Basic in the 80s, the only programming I had was a 2 day course on FORTRAN in 1978.
Don't expect to be writing new stuff the first day, mess around with the multitude of examples out there, see what you can do by changing the odd line, and if it stops working, figure out why.
With my mobile phone I can call people and talk to them -  how smart can you get ?


retrolefty, - "Well the problem seems to be with your expectations."

No, the problem is the language. It's too difficult.


No, the problem is the language. It's too difficult.

Ian, the appearances are misleading.

I've deal in the past decades with many programming languages, from the common to the exotic and I've even written my share of special purpose languages. In all those years, the problem with complexity rarely came from the language, but from the task at hand. The advances in programming in the past decades didn't really come from better or other languages, it came from better system libraries and better development environments. It really doesn't matter in what language you program, if the system library is a mess, programming will be a mess, although a good IDE or abstraction layer on to of the libraries can alleviate the problem.

And this is the point where you err. C or C++ isn't too complex or unintuitive or a mess. It's dealing with the microprocessor which is. If you choose any other language including Forth, List or Occam, you will run exactly the same problems. Some languages will pamper you a little longer until you hit that wall, but rest assure, the wall is still there and you will hit it at full speed. The only way around this is to provide a safer environment at the cost of less functions or a big amount of work by someone publishing the library. Lego went this way with their Mindstorm, some of the better graphical robotic kits also.

So for you, it means either take the plunge and master one of the environments or look for an environment better suited to your style of work. If the Arduino seems to have very little redeeming value for you, you might want to investigate the PIC, MSP430 or the STM8 environments. Those differ from the supported languages (PIC often uses Basic) and library support. Whining about how bad one product is won't really solve anything.



Nov 21, 2010, 11:08 pm Last Edit: Nov 21, 2010, 11:16 pm by u0421793 Reason: 1
Fair enough. Nobody is allowed to complain. Let's keep it exactly as it is and always has been.

Look, I don't believe you. Otherwise why aren't we all now programming in 6800 or 8080 assembler or something like that? There is no linearly proportional distance to some "wall" that is inevitable that it will be hit no matter what. Things can be made easier by removing obstructions, and the work is still done and the objective is still achieved.

By the way, what is wrong with people's comprehension lately? A language that is easy is not the same as a language that is simple. I'm not suggesting simplify things at all, but I'm strongly pointing out that it needs to be easy. An easy language to use can be as powerful as a complex and irritating and uncomfortable language. There are a lot of things that were more complex, ornate, flowery and decorative the way they used to be done in history, but have whittled down to a more streamlined, elegant and frankly easier way of operating. I could think of examples, but I'm sure anyone reading this could do so also.

I know from observational experience that some languages are not going to be rewarding or productive for novices in a limited time, whereas some other languages are. Considering that the task of programming is just one of the things that a student has to contend with to get a creative art project designed and constructed, having to spend most of the limited amount of time on just the programming part essentially sabotages the other parts of the production. Yet it is usually in those other areas that they will excel given a chance if it were not for this alien programming phase taking far too long and producing next to useless results every time. It basically puts people off ever having to get this deeply into computers ever again, and they'll typically refuse to risk ever getting involved with technology ever again. It's less risky and more productive to just produce something acceptable that doesn't have a microprocessor sitting there in the middle doing nothing useful except costing a lot, because the bloomin' thing doesn't fulfil the potential it promised due to a far from streamlined approach phase.

There's more to do on a project than spend time guessing the right words and in the right order and spending weeks tracking down problems such as daft syntax errors. A more friendly language would allow them to get to the stage where they're spending weeks tracking down problems such as fundamental action or process design misconceptions instead because computers solve tasks in a way that no human being (well, no fashion designer) would have guessed in a million years. I think that it's better to rush ahead to the stage where you have to be thinking "how would I do this if I were a microprocessor" than be stuck at the early stage of "say the magic word or you'll just get another page of syntax errors" for several months.

In other design domains, with a different set of people, I've seen people produce usefully gratifying results in an afternoon with Ruby* to the point that over the next few times they are in a position to make their own modifications and largely they'll sort of work (although usually not at all in the way they thought they would). I've also seen people spend an entire semester learning to hate Java because all they see are syntax errors, nothing they imagine will work actually ever does, and there's just too much fancy ornamentation to remember to get right each time. I've seen the same people a few months later get introduced to PHP and rush straight ahead actually producing things that sort of work.

The more I look at Lua, lately, thanks to several suggestions, the majority of them (but not restricted to) on this forum, the more I'm convinced that this would be a fairly good launch phase language, where that is the first syntax the novice sees. Although it's alien, it's not 100% martian, and at least some of what they'll try to do themselves beyond (or beside) the given examples in tutorials might stand some chance of producing some evidence of working.

Could (theoretically) a layer of Lua itself drive the C compiler that pushes GCC to make AVR binaries, and still work within an expanded Arduino IDE? Note, I'm not talking about eLua (http://www.eluaproject.net/) which itself seems a good project. (Incidentally, I'm starting to wonder if Forth running on the microcontroller is actually the good idea I'd always assumed it was). I'm now thinking it is better to do it the way it currently is performed -- on an IDE on a MacBook (or whatever else you use) and a toolchain that emits AVR binary and induces it to be on the Atmega chip somehow in a predictable fashion. If there were a Lua option and a C/"Arduino classic" option, neophytes could start off with Lua and progress further. If this wall of yours appears, they've had more productive experience at that point, and are in more of a state of mind to tackle it. I'm not suggesting that Lua is some magic potion that solves all the problems, but it's fairly clear to me that it does go some way to solving a significant problem and that is that frankly C is too difficult.

*Of course, at one point I was strongly wishing that Arduino could be instructed using Ruby, but on second thoughts, Ruby is highly object oriented -- that's one of its strengths -- and physical computing is probably one area where object orientation turns out to be simply an irrelevance.

Ran Talbott

Has it become an arcane language in the past 30 years such that nobody uses it?

Kinda, yeah.  Although I'd say "not many",  rather than "nobody".

Part of it is the availability of cross-development systems I mentioned earlier.

Another part is the growing trend toward CPUs (like the AVR) with separate code and data spaces.  I haven't been active in the FORTH community for quite a long time,  so I don't know how they resolved the problem.  But I know the original implementations would break badly on such architectures.

Another factor is that it's no longer considered acceptable as a professional engineering tool.  While you may dislike C as a matter of taste,  it has huge advantages for serious development.  Most notable is its ability to detect a large percentage of common coding errors.  If you get the parameters for a C subroutine wrong,  or the calling sequence changes,  the odds are good that the compiler will catch the error.  Not so with FORTH:  the most likely outcome is a mysterious failure at run time.

This is not to say there's anything wrong with you for preferring to use FORTH for your own personal projects.  But it really is true that it's a minority view,  and you'll find it difficult to get support among the "mainstream'.


Here we go: an amforth built for an 8MHz ATmega328, runs 19200bps on the serial port (9600 is SO 1980's :-)


This archive contains two hex files and an actual log file of me burning it into an AVR (using ArduinoISP) and using it.  that should be useful if I screw up the instructions below.
  • amforth-328-8Hz.hex
  • amforth-328-8MHz-eep.hex

These need to be programmed into your lilypad with a command like:
avrdude -c stk500v1 -p atmega328p -P /dev/tty.usbserial-FTD61T6Q -C avrdude.conf -b 19200 -e -u  -U lock:w:0x3f:m -U hfuse:w:0xd9:m -U eeprom:w:amforth-328-8MHz-eep.hex  -Uflash:w:amforth-328-8MHz.hex -U lfuse:w:0xE2:m

Breaking that down a bit:
Code: [Select]
# The avrdude program is what interfaces to the hardware device programmer.
# It may not be in your current path.  I believe the example logfile shows it being
# run from the arduino install directory, something like .../hardware/arduino/tools/avr/bin/avrdude

-c stk500v1
# ArduinoISP emulates a stk500v1 programmer.  If you're using some other
# type of programmer, you need to change this

-p atmega328p
# type of device we want to program.

-P /dev/tty.usbserial-FTD61T6Q

# Port where the programmer is connected.  Note that this is NOT the same as the port
# where the lilypad is connected.  Depending on your hardware, you CAN
# have them both connected at the same time.

-b 19200
# Speed of the serial connection to the programmer.

-C avrdude.conf
# Location of the avrdude config file.  This may also be buried inside your arduino install.

-e -u
# magic: chip erase and disable safemode.

-U lock:w:0x3f:m -U hfuse:w:0xd9:m
# Memory protection undone, and hfuse reprogrammed so that there is "no bootloader."
# Note that efuse contains only info that pertains to brownout, and should
# not need to be changed

-U eeprom:w:amforth-328-8MHz-eep.hex
#Program the EEPROM from the file.

-U flash:w:amforth-328-8MHz.hex
#Program the flash from the other file.

-U lfuse:w:0xE2:m
# Set LFUSE to use internal 8MHz Oscillator.  Use 0xFF instead for external 16MHz crystal

According to most of the material I found, 328-based lilypads MOSTLY have external 16MHz crystals, rather than using the internal oscillator.  The above commands will turn off the use of the crystal anyway...  If you notice that you DO have a 16MHz crystal, you can use the "duemilanove.hex" files distributed with amforth in the appl/arduino directory (back to 9600bps, though.)

And ... here it is running forth, defining a new word and everything:
> 1 .
1  ok
> : inc dup 1 + . ;
> 123 inc
124  ok
> inc
124  ok
> .
123  ok


Yay! It works, it works, it works. Thank you thank you thank you. This is excellent. Forthed Lilypads. Two of 'em. And they keep their words through a power-down, which is nice. This is going to be fun.


Code: [Select]
:inc dup 1 + .;

And that is in some way more comprehensible, user-friendly and powerful than C?

occam was (is) a simple, powerful language that allowed to you express concurrency at many levels, yet lacked even the simplest of data structures beyond arrays.

Horses for courses
Per Arduino ad Astra


And that is in some way more comprehensible, user-friendly and powerful than C?

Some times yes, sometimes no, most important is that the people using it are happy with it.



most important is that the people using it are happy with it.

All forth of them?  ;)


Do I need to know C or C++, or any other coding to use Arduino?

The only knowledge of C I had was that it is the third letter of the alphabet.
I still bought an arduino and quickly picked up the language. My first project
was an LED flasher with a time delay that has been changed slightly from
the included examples. Programming seemed daunting at first, but we all start

The best links I found are on this webite:

I also bought a C++ book off amazon. Although it is based entirely on computers,
rather than microcontrollers, it has taught me loads!

My website: http://www.harryrabbit.co.uk/electronics/home.html Up and running now! (Feel free to look round!) :D


Code: [Select]
: inc dup 1 + . ;
And that is in some way more comprehensible, user-friendly and powerful than C?

It depends.  That's interpreted on the AVR itself, with no involvement from the host computer.  An interactive interpreted language like Forth, APL, or LISP (or BASIC, to a rather lesser extent) allows you to build a device that a human can interact with via commands like:
Code: [Select]
led1 off
led2 on

Compare that to the frequent questions along the lines of "how do I get the arduino to read more than one character at a time?"
With Forth, all your keyword parsing is built in. (imagine writing a sketch that needs to respond to those commands on the serial port, for instance; not at all trivial!)
It's sort of like comparing a calculator to C.  If you want to do r^2*pi=, it's a lot easier to use the calculator than to write a C program...

Go Up