Language Parsing With ANTLR

September 7, 2017 by Al Williams 31 Comments

There are many projects that call out for a custom language parser. If you need something standard, you can probably lift the code from someplace on the Internet. If you need something custom, you might consider reading [Federico Tomassetti’s] tutorial on using ANTLR to build a complete parser-based system. [Frederico] also expanded on this material for his book, but there’s still plenty to pick up from the eight blog posts.

His language, Sandy, is complex enough to be a good example, but not too complex to understand. In addition to the posts, you can find the code on GitHub.

Continue reading “Language Parsing With ANTLR” →

Friday Hack Chat: JavaScript On Microcontrollers

August 23, 2017 by Brian Benchoff 15 Comments

Microcontrollers today are much more powerful and much more capable than the 8051s from back in the day. Now, they have awesome peripherals and USB device interfaces. It’s about time a slightly more modern language was used to program these little chips.

During this Friday’s Hack Chat, we’re going to be talking about JavaScript on microcontrollers. [Gordon Williams] will be joining us to talk about Espruino. This is a tiny JavaScript interpreter that runs on the little embedded chips, has a debug interface, and allows you to program your board on any platform without any external programming hardware.

[Gordon] is the key developer of Espruino, and so far he’s launched a full-sized Espruino, and a pico Espruino on Kickstarter, both with amazing success. The software stack has been extremely popular as well — it’s been ported to the ESP8266 and dozens of other microcontrollers that will soon be in the Internet of Things.

During the Hack Chat, we’ll be discussing interpreted languages on microcontrollers, interpreter design and optimization, with a special emphasis on creating devices with Espruino and putting Espruino boards on the Internet with WiFi, Bluetooth, and other crazy radios. As always, we have a spreadsheet open to everyone if you’d like to ask a question.

Here’s How To Take Part:

Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. Hack Chats are mostly, usually, and this week noon, Pacific time on Friday. Here’s a time and date converter!

Log into Hackaday.io, visit that page, and look for the ‘Join this Project’ Button. Once you’re part of the project, the button will change to ‘Team Messaging’, which takes you directly to the Hack Chat.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.

Interpreting Brainf*#k On An AVR

February 27, 2013 by Brian Benchoff 12 Comments

We won’t call it useless, but we will ask why [Dan] wrote a brainfuck interpreter for the AVR

It’s not generating code for the AVR; think of it more as a bootloader. To run a brainfuck program, [Dan] uploads it to the EEPROM inside his ATMega32, after which the microcontroller takes over and starts performing whatever instruction the brainfuck program tells it to do. Because the whole thing runs off the EEPROM, the code size is limited to 1022 bytes. Enough for any brainfuck program written by a human, we think.

As for why [Dan] would want an AVR to build an interpreter for a language that is nearly unreadable by humans, we honestly have no idea other than the common, ‘because it’s there’ sentiment. There are some pretty cool projects out there that use brainfuck, including this genetic algorithm software developer. Right now, though, blinkey LEDs are enough to keep us happy, so you can see a video of brainfuck doing its thing on a LED bar display after the break.

Continue reading “Interpreting Brainf*#k On An AVR” →

A JavaScript Interpreter For ARM ‘micros

October 5, 2012 by Brian Benchoff 42 Comments

When programming a microcontroller to do your bidding, you only have two choices. You could write your code in a proper language such as C and cross-compile your source into a piece of firmware easily understood by a micro. Alternatively, your could load an interpreter on your microcontroller and write code via a serial connection. Interpreters are a really fast and easy method to dig in to the hardware but unfortunately most microcontroller interpreters available are based on BASIC or Forth.

[Gordon] figured it’s not 1980 anymore, and interpreters for these relatively low-level languages aren’t a good fit with the microcontrollers of today. To solve this problem, he created Espruino, a JavaScript interpreter for the new batch of ARM development boards that have been cropping up.

Espruino is designed for the STM32VL Discovery board, although [Gordon] plans on porting his interpreter to the Arduino Due when he can get his hands on one. Installation is as easy as uploading any other piece of firmware, and even though [Gordon]’s STM32VL doesn’t have a USB port for a serial terminal, it’s a snap to connect a USB to TTL converter and get this interpreter working.

Espruino isn’t open source yet, only because [Gordon] would like to clean up his code and write a bit of documentation. He’d also like to make Espruino profitable so he can work on it full-time, so if anyone has an idea on how [Gordon] can do that, leave a note in the comments.

BASIC For Some Beefy AVR chips

May 3, 2012 by Mike Szczys 10 Comments

klBASIC is a BASIC interpreter written in C for AVR microcontrollers. [Karl Lunt] developed the project based on an assembly language BASIC interpreter for 68HC11 chips written by [Gordon Doughman]. The transition from assembly to C bulked up the code, so you’ll need a beefy AVR chip in order to store all of it.

The idea is that one AVR chip can run BASIC with just a serial monitor. But like this Arduino BASIC interpreter build, it would be a snap to run this with a keyboard and small LCD screen. We see binaries available for several different AVR devices including ATmega128, ATmega1284, and Xmega128. They range from 1.5k to 16k of program memory. We didn’t find a link to the source code (just these precompiled files) so we inquired with [Karl] to see if that is available. He’s reluctant to release the code because it’s “pretty much a mess” and doesn’t live up to his normal standards. If he codes for a living we can see how that may be embarrassing. If you’d like to lend a hand cleaning up the code, let him know by leaving a comment here and maybe he’ll release it for that purpose.

We find this interesting, but it’s tough to get excited about building one of our own. If this has inspired you, we’d love to hear some of your plans in the comments after the break. Perhaps we’d be prodded into another programming adventure based on your enthusiasm.