A Forth implementation and programming environment for ATmega microcontrollers | Hacker News Reader

A Forth implementation and programming environment for ATmega microcontrollers

mywebspace.wisc.edu

55 pointsColinWright18 comments

Open articleView on HN

There are also chips that have a Forth as their instruction set:

http://www.greenarraychips.com/

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

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

http://flashforth.sourceforge.net/

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.

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.

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.

This brings back some memories. :)

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.

Forth has an academic sister called Joy [0] and under the term "concatenative programming" a niche paradigm has evolved.

[0] http://en.wikipedia.org/wiki/Joy_(programming_language)

I've been playing around with Factor when I have a moment.

I was impressed by reading the excellent 're: factor' blog; he often re-implements small unix utilities in Factor, for instance.

http://re-factor.blogspot.com/

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

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.

oops, catch you!

can you implement that in y86? i didnt learnt x86 asm

Having spent ~30 years "implementing things" (ranging from accounting systems to large-scale control systems to tiny microcontroller projects) I must say that I have found Forth superb for this purpose. It does take a little practice at first, but as I have also had the privilege of teaching a few thousand newbie Forthers I have found that they can become incredibly productive in a matter of days.

You want to check out concatenative programming[1] and particularly #concatenative on Freenode. Factor[2] is the preeminent concatenative language at this time. It is dynamically typed and comes with an excellent interactive environment and a fairly large collection of libraries. It feels very much like “Lisp done right”—which is to say that it’s very practical, and you get much more composability and metaprogramming power without all the parentheses.

Joy[3] was the first language to be described as “concatenative”, invented by the late Manfred von Thun; its operation is defined as a term rewriting system, but it can be implemented using a stack. If you want some theoretical background, Brent Kirby’s Theory of Concatenative Combinators[4] may be enlightening. Cat[5] was the first statically typed concatenative language, and Kitten is my successor to Cat.

If you’re looking at Rust, Kitten[6][7] is designed with similar goals in mind. It’s a language about safe, expressive abstractions with predictable, low runtime costs. It encourages expressing programs as compositions of effects. It is not usable for production but may be fun to play around with; we are currently working on a native backend.

[1]: http://concatenative.org

[2]: http://factorcode.org/

[3]: http://www.kevinalbrecht.com/code/joy-mirror/joy.html

[4]: http://tunes.org/~iepos/joy.html

[5]: http://cat-language.com/

[6]: http://kittenlang.org/

[7]: https://github.com/evincarofautumn/kitten

I mentioned Factor in less detail below, I think it's a lot of fun, but -- from the detail here, might I assume that you're involved with Factor in some way?

If so: does it have a package manager yet?

The last I was plunking around with Factor, 6-8 months ago, uh, "dire" was a good word to describe the package/library management situation. Is that still accurate?

Have you guys considered bootstrapping by using a package manager from another language/ecosystem? For instance, npm is pretty awesome, and they don't really care whether what's being distributed is javascript or not.

I’m not involved with Factor development, just a casual user and concatenative evangelist. Factor still lacks a package manager; the notion, I suppose, is that the standard library is the standard package repository like npmjs.org for Node or Hackage for Haskell.

Hmm. Man, maybe I should see if I can hack something together using npm and a naming convention.

Package managers are ... important.

factor is cool and fasion except it only focus on x86 right now

Reply on news.ycombinator.com