Interview With [Damien George], Creator Of The Micro Python Project

November 27, 2013 by Mathieu Stephan 55 Comments

[Damien George] just created Micro Python (Kickstarter alert!), a lean and fast implementation of the Python scripting language that is optimized to run on a microcontroller. It includes a complete parser, compiler, virtual machine, runtime system, garbage collector and was written from scratch. Micro Python currently supports 32-bit ARM processors like the STM32F405 (168MHz Cortex-M4, 1MB flash, 192KB ram) shown in the picture above and will be open source once the already successful campaign finishes. Running your python program is as simple as copying your file to the platform (detected as a mass storage device) and rebooting it. The official micro python board includes a micro SD card slot, 4 LEDs, a switch, a real-time clock, an accelerometer and has plenty of I/O pins to interface many peripherals. A nice video can be found on the campaign page and an interview with the project creator is embedded after the break.

Continue reading “Interview With [Damien George], Creator Of The Micro Python Project” →

STM32 F4 Discovery Tutorial Using Open Source Tools

September 27, 2012 by Mike Szczys 19 Comments

[Pulko Mandy] got his hands on the new STM32 F3 Discovery board. He’s a fan of the open source tools just like we are, so he posted a guide covering the use of an open source toolchain with the F3 hardware.

This board was just announced earlier this month but there is already support for it in OpenOCD. It’s not all that different from the F4 board, which we would think made the process a bit easier. [Pulko] is using the Sourcery CodeBench Lite toolchain, which works for pretty much all of the ARM chips out there. It is GCC based and comes with GDB for debugging (along with all the other tools you would expect). He did created his own Linker script and startup code. These are crucial for ARM so it’s nice that he provided them for us. He finishes up the guide by showing how OpenOCD can be used to flash the code to the chip and how it works with the debugger.

[Photo source]

Regarding The Development Files That Accompany TI’s Microcontroller Offerings

September 19, 2012 by Mike Szczys 20 Comments

We received a tip from [Fabien] that Texas Instruments had posted a set of IDEs for the Stellaris Launchpad on their download page. At first we skipped right over the link, but then decided to take a look and see if things had changed any since the MSP430 Launchpad had been released. As we expected, there’s really no help on this page if you’re looking to develop for the hardware without using one of these IDEs.

Why would we want to forego the preconfigured development environments TI supplies? For one thing, they offer only trial licenses. When you go to download one of the packages you have to wade through a eyebrow-raising non-export agreement. When we made it that far, the ~500 MB Sourcery package we downloaded was quite slow. And we don’t see any option for installing any of these on a Linux machine. No matter what OS you choose, we think you should be able to develop for any architecture using the same development environment — be it Eclipse, GNU Emacs, Notepad, or whatever . We don’t want to download a huge package just to try out a new chip.

We know you can develop for Stellaris ARM chips using a vanilla cross compiler like arm-none-eabi (we use Sourcery CodeBench Lite — formerly CodeSourcery G++ lite). We hope that TI is planning on adding a barebones package that supplies a simple Makefile, Linker Script, and base libraries for the hardware. But we won’t hold our breath. After all, it is an industry standard to leave out Linux support.

Parallax Shows Love For Open Source: GCC + Propeller

June 20, 2012 by Mike Szczys 35 Comments

Parallax has done something that is unthinkable for most microcontroller manufacturing companies. They’ve decided to throw their support behind an open source toolchain based on GCC. That’s right, instead of fighting to get your code compiling on a platform whose example code uses crippleware, you can actually download, compile, and start using this toolchain without code size restrictions or other unfavorable limitations.

Why does this matter? One example that comes to mind is ChibiOS and the STM32F0-Discovery board. We’ve been playing around with that board recently and found out that the Atollic 8k code-size limitation prevents you from debugging ChibiOS. So you either pony up the registration fee, or go though at least a little pain (a lot depending on your skill level) to move to an open source solution. Here that’s not going to happen because you start with a GCC option from the word ‘Go’.

So join us in a round of applause for good decisions. Bravo Parallax! This Beta test targets the P8X32A Propeller chip but we hope it’s so popular that the rest of the line gets its own support.

[Thanks Devlin via Adafruit]

HTML Based AVR Compiler Aims To Make Arduino Development On IOS Possible

April 10, 2012 by Mike Szczys 19 Comments

It’s surprising what lengths people will go to in order to bring functionality to their smart phones. In this case, [Tadpol] wanted a way to develop for his Arduino on an iOS device like an iPad or iPhone. He figures it’s possible to rewrite the IDE as HTML5, but since that’s a pretty large mountain to climb, he started by building a browser-based AVR compiler. It’s an interesting concept, and he’s got a working prototype up on Github for you to test. Perhaps you can throw your hat in the ring and help him with development?

The web interface uses boxes to add to the code. What you see above is three sets of commands which will blink an LED. The project, named Avrian Jump, uses a simple ladder language to feed the compiler, with several different options for output. The most interesting in our mind is a WAV file which can be used to program an AVR from the audio out of your device. That would make programming as simple as connecting the specially modified AVR to your headphone jack. There’s also an ASCII output which allows you to save your programs for later alteration, S19 output for AVRdude programming, and an assembler output for debugging purposes. It’s hard to see where this project might go, but we have to admit that the concept is intriguing.

Visualizing A Nanosecond

February 27, 2012 by Mike Szczys 98 Comments

We’re so glad to have run across this video where [Rear Admiral Grace Hopper] explains how to visualize a nanosecond. Now we had never heard of [Grace Hopper] before, but once you watch the clip (also embedded after the break) you’ll want to know who this person is. We work with divisions of seconds all the time when developing with microcontrollers. But those concepts are so abstract we never had a need to think about them as a physical distance. After all they’re a measure of time, right?

You can’t make it out, but she’s holding a length of wire between her hands. It is 11.8 inches long and represents how far electricity can travel in one nanosecond (one billionth of one second). She goes on to explain that this is a calculation of the distance which light can travel in one nanosecond, then really hits the concept home when she uses it to explain latency in satellite communications. For us, the waste of not putting a chip into sleep mode when it’s just stuck in the loop waiting for an interrupt is where we made the connection.

So back to the woman herself. We think you’ll really enjoy reading through her Wikipedia biography page. [Grace] was a computer science pioneer. She is credited with writing the very first computer compiler. She postulated and articulated the concepts that led to the development of COBOL, and popularized the term ‘debugging’. In short, she is one of the giants whose shoulders we all stand upon.

Continue reading “Visualizing A Nanosecond” →

How Canonical Automates Linux Package Compilation

June 12, 2011 by Mike Nathan 25 Comments

pandaboard

What do you do when it’s time to port the most popular Linux distribution to a completely different architecture? Canonical employee [David Mandalla] works on their ARM development team and recently shared the answer to that question with his fellow Dallas Makerspace members.

Canonical needed a way to compile about 20,000+ packages for the ARM platform, however they did not want to cross-compile, which is quite time consuming. Instead, they opted to build a native solution that could handle the load while ensuring that all packages were compiled securely. To tackle this immense task, [David] and his team constructed a 4U server that runs 20 fully-independent ARM development platforms simultaneously.

The server is composed of 21 PandaBoards, small OMAP development boards featuring a dual-core ARM cortex processor with just about all the connectivity options you could possibly ask for. One board operates as the server head, keeping track of the other 20 modules. When someone requests server time to build a package, the main board checks for unused server, triggering a relay to reboot it before the server is automatically reimaged. Once the pristine, secure environment is ready to go, it’s handed off to the customer who requested it.

If you’re interested in learning more about the build process, [David] has put together a blog with additional details.

[Thanks Leland]