
A Forth implementation and programming environment for ATmega microcontrollers - ColinWright
https://mywebspace.wisc.edu/lnmaurer/web/FloatingAway/FloatingAway.html
======
euccastro
There are also chips that have a Forth as their instruction set:

[http://www.greenarraychips.com/](http://www.greenarraychips.com/)

Gotta love having 144 Forth machines in a $20 chip.

------
Aga
FlasForth is another fun Forth for AVR and PIC microcontrollers. You can even
try it out over telnet... :-)

[http://flashforth.sourceforge.net/](http://flashforth.sourceforge.net/)

------
conductor
I love the AVRs, they are nice and simple Harvard architecture 8-bit
microcontrollers, but I think, for any new project the ARM Cortex series (M0,
M3, M4) are just a better option, they are 32-bit, are faster, have more RAM,
more Flash, you can get DSP and other nice features, and they are cheap.

~~~
HeyLaughingBoy
_Any_ new project? I just made a product for a client that had to fit inside a
shoe and be as physically unobtrusive as possible while stealing power from
another device.

It only needed one bit of input and one bit of output and the code fit into an
8-pin Tiny AVR and was probably just about a kilobyte of compiled C. The chip
cost less than $1 in single units.

ARMs are nice and everything, but orders of magnitude overkill for the
thousands of small devices like this.

~~~
Zuph
The "any new project" generality is getting closer to an absolute truth every
day. Many Cortex chips use _much_ less power than an AtMega or AtTiny in sleep
modes, and use very little power in active modes. All are fast enough that
they can spend the majority of their time in deep sleep modes. NXP is making
significant inroads in producing low pin-count devices, and there are many
chips available for under $2.50 in single quantities.

I mean, at the end of the day, the tool you know is the tool you should use,
but it's more difficult to quibble about the technicalities of it all the
time.

I would argue that the biggest barrier to Cortex M0/M3/M4 adoption in the
hobbyist/maker/startup community is the lack of coherent open tool chains.
Many of the cheap programmers will only program a subset of chips, many pre-
canned compilers don't include various features (Many lack support for the
M0+, or the FPU on the M4F chips), it's almost impossible to get code working
on a chip without delving into a vicious hellscape of linker scripts, and many
manufacturers license their peripheral libraries under onerous non-free/non-
open licenses.

I could program an AVR with one hand tied behind my back using an entirely
open toolchain. Until I can do that with even a single manufacturer's Cortex
Mx offerings, the AtTinys and AtMegas will be sticking around. I want to work
on my project damn it, not debugging my toolchain.

------
pjmlp
This brings back some memories. :)

------
Dewie
Here's an aside on Forth-like languages: how much academic interest/research
has there been in them? I've seen some people say that Forth is like Lisp in
that it is its equal when it comes to high-level abstractions, but at the same
time that it fits like a glow for low-level tasks. Some researchers must have
been curious about this paradigm, at least enough to find out if that claim
might hold some weight.

~~~
rwmj
As the author of jonesforth[1], I found Forth to be a great hack and enormous
fun to write. However as an actual language to implement things, not so good.
It's terribly difficult to write correct code when you've got no bounds
checking, only primitive memory management, no types, and having to manage the
stack. (Modern Forths fix these problems to some extent.)

It's my understanding that most language research is on safety features, type
systems and so on, so I don't know how interesting Forth would be.

[1]
[http://git.annexia.org/?p=jonesforth.git;a=summary](http://git.annexia.org/?p=jonesforth.git;a=summary)

~~~
evincarofautumn
Hi! Thanks for jonesforth; I found it very enlightening when first learning
about stack languages. I typically explain Forth as somewhere between assembly
and C—a Forth implementation is minimal enough that it’s practically a
structuring technique for assembly programs, and (like types in C) more for
convenience than correctness.

