Archive | April, 2019

Getting started with STM32F0

04 Jan19

Getting started with STM32F0

I use the Particle Platform a lot and these have been based on STM32F4 up until the new Mesh radios they just delivered. The STM32 series is massive. There's microcontrollers for every need and budget, so I figured it would be a good learning experience to work with one of the cheapest ones available?

After some looking at datasheets, it looked like the STM32F070F6P6 was a good option for my POV-project. For just a few of these, you pay $1.5 per MCU. If you make something in volume (as in 2500), the price drops to $0.70 and below. If you only need a few pins, such an MCU can be a great budget alternative. It's a full 32bit microcontroller with all peripherals you'll typically need and it has the possibility of programming it via USB. It's cheap but has somewhat limited options and not too many pins.

Getting it up and running

Getting it up was super easy. No external components are required to run at 8Mhz, so you just slap the chip on a board and add pins to program and debug it (SWDIO + SWCLK). You can find a STLink v2 programming adapter on Ebay for less than $2, so this really is an affordable development platform. The drawback of running the chip without a crystal is that the internal RC oscillator is not precise enough that you can use USB. On the second iteration of the board, I added the crystal, but then realised that you need to upload a custom USB bootloader as the chip's don't come with one as stadnard. I still have not figured out how to make this work with my IDE, but I'll get there eventually. Speaking of IDE's for STM32 - I've now tried a few and the development experience is far from the 1-click Arduino installer. They're much more IDE's than the Arduino glorified text editor, but the install process is not as smooth.

      After testing some more it turned out that the STM32F070F6 line cannot use USB along with both I2C, Serial debug and Serial data. It simply does not have the required pins to do it? I can remap some pins to get USB working (PA9/PA10 -> PA11/PA12), but that prevents me from using an I2C based IMU. There is also the “minor issue” that the Virtual Com port driver takes up more than the available RAM in this rather constrained device… To work around this I’ll design the third version of the board based on the STM32F070CBT6. This is a 48 pin chip rather than just 20 pins. The price goes up to $2.26 per chip for 10+ and to $1.15 in volume. Its more expensive, but also offers 4 times the memory (128Kb) and that’ll come in handy to get USB working.

It also turns out that the MPU-6050 Accelerometer and Gyro I wanted to use is $8.31 from Digikey or Farnell? That’s for the IC alone. You can buy assembled MPU-6050 modules with all the required extra parts for $0.70 from Aliexpress. I already have 20 of them from another project, so I’ll just add holes to solder these modules in, rather than place them on the board. Reduces the price of each board and swift to solder in.

Setting up clock speeds and the rest of the hardware was really easy using the graphical tools provided in CubeMX. One of the very nice features of the STM32 family is that all pins can be setup as most anything. Want your analog pins on one side? Sure. Just set them up that way. Want two SPI controllers? Sure - just add them to the ports you want. The STM32F0 family is a little more limited than the STM32F4 that I'm used to, but they're still quite flexible. You can also set this up “by hand”, but using CubeMX to generate a set of files to start from is quite smooth. Just select your IDE, and CubeMX will generate suitable project files and a setup for that IDE. The main file will be full of comments indicating where you should put your code. If you follow this, you can then re-run the CubeMX tool to change pin config at any time without it overwriting your code.

What IDE to use?

The first IDE that I tried out was Atollic TrueSTUDIO for STM32 9.1. For an integrated IDE on Windows, this was rather clumsy to set up. I got it working, but it was far from a one click installer? I had expected it to be more plug and play. For my Mac I setup System Workbench for STM32 from OpenSTM32. Having worked with several Eclipse based tools before, this was easy to setup but it's kind of clumsy that the supplied downloads (both from OpenSTM32 and ST) have to be started from command line. ST supplies what looks like OSX installers, but these fail miserably and they've done so for many years. Given how popular Mac's are with developers, it's surprising that they don't even document this but rather just pretend to have a working solution.

It's also surprising that we still don't have proper 1-click installers for stuff like this in 2019. It's not super hard to install System Workbench with all required dependencies, but it's far from simple for a novice. They do however provide great written documentation to follow.

Both TrueSTUDIO and Workbench works well. You get access to full debug capabilities via stlink + openocd and both IDE's are completely free. Workbench is also Open Source. There's also commercial IDE's out there that support the STM32F0 family such as Keil's MDK-ARM and IAR Systems Embedded Workbench. I don't have $2-5k to drop on testing a platform on my spare time, but if you already have this software it's probably a little smoother to get things up and compiling.

Working with it

STM32's do not come with anything resembling an Arduino API, so it may take a little getting used to doing everything "manually" if you come from a more "managed platform". To turn on an output pin, you do something like this:


To turn it off, it's something like this:


Lot's of CAPS and everything is defined as constants, so having an IDE that has some intellisense to open and inspect is required. It's nowhere near as "verbal" as Arduino's digitalWrite, but its just another way to do things? If you play around with several platforms, you'll soon realise that this is how it works in the MCU-business. Neither Microchip, Atmel, Parallax, STM or any other vendor offer APIs that resemble anything you know already. They all want you to go deep down and toggle registers on the chip rather than use convenient and familiar methods that can gloss over how the chip works.

They do however give you a hardware abstraction layer (HAL). It's not anywhere near as complex as just working with registers, but  it's also not exactly smooth? To use GPIO you first have to enable the pheripheral. Then you use the following commands to set a pin as ouput:

GPIO_InitStruct.Pin = GPIO_PIN_3;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

This is equivalent of Arduino's single line pinMode command. No problem, it's just more work. I'm sure this is MUCH faster, but in general I do not care if something is a little slower if it’s easier to remember. If all the code is Open Source so I can learn from it, that will save me in the very few and narrow cases where I need to save a nanosecond or ten? You could of course just write your own pinMode commands if you think this is how it should be.

I know some ppl that prefer to not use any tools and rather go for the 83 page manual for the specific chip, the 91 page programming manual, the 779 page reference for the familiy of chips or the many hundred of documents detailing how features such as DMA, RTC, PWM will work in detail. If you're one of them - then good for you as you won't need to worry about what to do with your spare time?

I on the other hand think good thing they made CubeMX to type all the config out for you and include HAL files :-)
It’s not what I’m used to, but it does the job well and I don’t mind learning multiple ways to skin a cow.


Particle memory limitations and workarounds

18 Sep18

Particle memory limitations and workarounds

When coding in C/C++ it's crucial to do memory management correct. For a device that is expected to "just work" you simply cannot have any memory leaks. The simple way to solve this is to never allocate memory dynamically. By just instantiating all objects statically, you can be guaranteed that you always have enough memory. What do you do when you past this?

With the first Particle hardware platform called Spark Core, you had about 108Kb for your program and 35Kb of runtime memory available. With the Particle Photon, you have 128Kb program and about 60Kb runtime. This extra memory does however come with an undocumented limitation - for the Setup wifi feature (known as Listen Mode) to work, you have to leave at least 21.5Kb of the 60Kb free. You are free to use more, but if you do so the Listen Mode will not work correctly. Saving credentials will seem to work, but eventually fail.

If you've gotten to this, the trick is of course to start allocating memory dynamically instead of statically. That way you can utilise the same memory for multiple things. Jumping through some hoops and rethinking what needed to be in memory at what time, we found a fairly simple solution. We have a lot of debug features that take up valuable memory. Customers will normally not use these, so by making it all dynamic we suddenly had a lot of memory to spare. Here's how the memory usage looked before and after:

Memory use:
   text    data     bss     dec   note
  89884    2148   43360  135392   (before dynamic allocation)
  89868    2148   33128  125144   (after dynamic allocation of a large buffer)
  90012    2148   18468  110628   (Debug screens moved to RAM)

We basically halved the memory usage without sacrificing any features by just rethinking what we needed to load at what times in the program. I'm quite happy with how this turned out and I wanted to share in case others run into the same issue. Big shoutout the the great community and employees at Particle that helped solve this issue!

Level shifting NeoPixels for Particle Photon

14 Sep18

Level shifting NeoPixels for Particle Photon

I just miscounted how many GPIO pins I had for a project, so I had to find a way to save some pins. In this project we have a status LED that is either red, green or both (producing a somewhat orange color). I need 4 of these per Photon, so that's 8 pins. What about using programmable ws2812, sw2812b or SK6812 LED's?

They only need a single pin to drive many LEDs (NeoPixels is just the marketing name that Adafruit apply for all of these), so I can potentially save up to 7 pins, but also make other colors than red/green possible. Surely enough, I had some of these floating around from a former project.

For my Bitmart marquee sign I used maybe 90 of these, but I kept having bugs causing random flashes if I pulled too much power. Back then I used a 74HCT125 for level shifting, but I couldn't find either that or the 74AHCT125 variant in my component shelves. I did however find some 74HCT245 deep down in a drawer and surely enough - these are what is perferred for driving these programmable LED's in the Teensy community. Both will do the job!

I plugged it up and it worked perfectly! No glitches, just perfect timing. From the datasheets, the 74HCT125 and 74HCT245 looks to have very similar characteristics, but the first shifts 4 lines and the other shifts up to eight lines. The one I used in the Bitmart-sign was just one I found in a shelf at Bitraf. Maybe that one was damaged? Hmmm. I'll have to revisit that project to fix the glitches, but for now I've solved my problem.

I had a hard time locating pinouts / connection schematics for these IC's so here they are for use with Particle Photon.

Connecting Particle Photon to NeoPixels using 74HCT125

Connecting Particle Photon to NeoPixels using 74HCT245

Yellow wire is data out from the Photon. Purple is the level shifted data signal. Red is 5V. Black is GND. Do not omit the fat Capacitor that feeds the fast PWM LEDs.


Odd Particle Photon error messages and what they can mean

23 May18

Odd Particle Photon error messages and what they can mean

This post will eventually become a serachable collection of info that I have not found any other place. I usually make my projects based on the P1 module that has an extra 1Mb of Flash built in, but it's the same device as the P0 used in the Photon. If you look inside a P0 and a P1, you'll quickly see the familiarity. It's basically just the extra Flash and the FCC approved PCB antenna that differs.


"Potentially unhandled rejection [3] Serial problems, please reconnect the device" usually means that you have another serial connection open so you can't get access to the port. Just close this and Particle Setup (and other things that require Serial access) This happens ever so often if you're using the super-neat --follow option that keeps a serial connection open even though the device is restarting.

If you read/write beyond the length of an array, you'll easily see the readed red blink. Another way to achive this is using Serial inside a constructor. It's really hard to flash your device when it keeps crashing, so what if there was a way to get the device online but without running your firmware? Of course there is! Hold down RESET and SETUP buttons. Release the RESET button and when you see the device blink purple, release that button also. The device will now blink green, but when it's connected it won't run the firmware. Instead it will fade purple to show that it's online, but not running your program.

Nice to know!

If you need to clear the wifi settings, just hold down the SETUP button for 10 seconds or more. Instead of slow blue blink, you'll then get a very fast blue blink. This means that wifi setup has been fully cleared.

When you're debugging, it's super annoying to have to restart the Serial monitor all the time. You don't have to! Just use this instead:

particle serial monitor --follow

This will try to find the serial port when the device reconnects (for OTA programming and other things)

Embedding myself in devices

19 Nov17

Embedding myself in devices

This blog's been a litte dead the last year as I've been head deep in two big projects in addition to teaching more than before at Westerdals ACT. I'm not dead and I'm having a blast!

I'm doing exactly what I want at the moment and I feel that I'm creating really good stuff.


For the two brothers Simonsen, I'm creating the electronics and software for their Røst coffee roasting machine. It's a beautiful machine that has already won a RedDot Award for the design and "Best New Product" in the technology category at World of Coffee in Budapest. The software and electronics is controlling fans, brushless motors, stepper motors, super high precision temperature sensors, gas burner, spark ignition, capacitive touch screen, encoder, sensors and has a host of safety features. Read more about the machine here or check the video below.


This project I've worked on for almost two years by now. Imagine you're at a festival and need a beer. There's always a beer-line and the guy in front of you will always wait until it's his turn at the bar to start planning. Wouldn't it be nice if the bar had glasses ready and they started tapping the second you hit the BUY button on your phone?

What we've managed with this project is to take the already great BottomsUp system (taps a beer in 4 seconds!) and added an ordering system via an App. The App talks to a controller box under the bar that can remote control the entire tapping system. From you click the Buy-button until you have (up to) 6 beers is just 5 seconds - including payment! This has been a blast to develop and it's now ready for the masses. You can see an older version of the system in action here and this is how the (injection moulded) box now looks after 3 iterations.

Westerdals ACT

Four years ago a friend told me to apply for a job teaching Embedded Systems at Westerdals Oslo School of Arts, Communication and Technology (or Westerdals ACT for short). At that time I felt a little under-qualified, but they really needed someone to do the course. I said yes and over the years I've found that I'm certainly just as qualified as many of the other teachers. I built the course so that it's one of the most complete Arduino courses there is. It's 12 weeks with 4 hour lectures each week that takes the students from complete noobs to someone that could make a simple prototype for a project. I try to cover all the basics whitout going too far into the details, while covering all the things I think will be useful for them. One of the last lessions we have a PiDay where we go through some of the same projects in Embedded Linux, so they get to try it from that side also.  I've now done the course 7 times and the students love it!

Last year the school asked me to build a second course that builds upon the Embedded one. The topic is Machine to Machine communications and briefly said - it takes the prototypes that the students learned to make in the Embedded course and teaches them how to connect them to the cloud. We go though lots of cloud related technologies, play around with radios, communications protocols and build complete M2M networks. I score very well when the students review their teachers each year and I really enjoy the interation with the students. I've always loved presenting and teaching, so I think I might do more of this in the years to come. 


Anyone knowing me will probably know that I don't just have my office at Oslo's biggest Hackerspace, I also help organize it. I'm no longer in the Board, but I maintain our contact with the landlord (Olav Thon) and make sure things "just work" in general. Bitraf is a Do-ocracy and it's amazing how well this works even if there's just a few people doing things. Bitraf has grown from a 20 ppl Hackerspace with coworking (130 sq/m) to a massive combined Hackerspace/Makerspace/Coworking space with 250+ members and several events each week (now with 950 sq/m space). Back when we started, we dreamed about getting a laser. About two years ago I purchased one and last week we just received our second laser cutter. We now have 2 lasers, 4 CNC's, 2 lathes, complete SMD workstation, huge workshop, a sewing room, a chemistry/bio room, seven 3D printers, all the hand tools you'll ever need, lots of workspace for projects…

It's just grown really well organically and only with members funding it. We have done this completely without government grants, so I'll do a writeup on how to run and fund such a space soon.



Basic Blink example for dsPIC30F4013

20 Nov16

Basic Blink example for dsPIC30F4013

With an Arduino, I can teach someone to blink a LED in 15 minutes. It will always work. In the world of PIC microcontrollers, there's nothing "that just works". To help others trying to make a dsPIC30 family microcontroller do just the simplest thing, I'm posting this mini tutorial including what they expect you to know and what you actually need to know.

The Arduino community has always been a place where newcomers could feel welcome. Even the simplest questions are answered politely and nobody looks down on someone just learning the ropes. In general, it's a very welcoming platform. You just download the IDE, plug the Arduino in via USB and you're already moving. I've now tought microcontrollers to students for 4 years and they really love using Arduino as their first hardware tool. So what's different with the microcontrollers from Microchip you may ask? The answer is simple - everything!

What they expect you to know

For a freelance project I'm working on, I have a piece of hardware designed in the US. It's using a dsPIC30f4013 and it has been doing it's job for many years without major problems. Now I've been tasked with adding new features into it and it's been very interesting to see how the culture around the product is extremely different.

In the Arduino world you are expected to be a beginner, but in the PIC-world you are expected to be an expert - even if you're just starting. Let me illustrate this with an example from this thread where a guy starts off by saying he is an absolute beginner and that he just wants to blink a LED.

Here are some of the comments he receives:

Refer to your  micro datasheet. bye!

Do you have access to a logic probe or an oscilloscope to check if your crystal is oscillating?

And anyway I cannot see your CONFIG settings…

you need a pullup on MCLR, and a small bypass capacitor (say 100nF) mounted as close as possible to each pair of power pins

The first of these comments is just terrible? The datasheet for a MCU (like the dsPIC30F4013 that I am using) is no less than 221 pages. The worst is - that is just the parts that are specific for that single MCU. To get the full picture, you also need the datashee for the family of CPUs. For the dsPIC30F family that is no less then 772 pages! To top this off - to use anything remotely advanced, you'll also need to study the dsPIC Language Tools Library. These 400+ pages detail how to use core features like UART, SPI and I2C - all features that an Arduino user will explore within the first few days of use. With a PIC, you should read almost 1400 pages of dense and highly technical documentation BEFORE even blinking a LED?

I can't even imagine how long it would take to read close to 1400 pages? These manuals are not written for a beginner. I would say that datasheets in general are written by engineers that want to impress other engineers. Its not light reading, but requires focus so it's quite tiresome for most to read.

Regarding comment #2 - how on earth can you expect someone that says he is a beginner and cannot blink a LED to have a logic probe or an oscilloscope? Regarding #3 - what CONFIG? Now - I know that config is important when it comes to PIC, but I have yet to find a good tutorial that explains how that is done correctly. I know it's in the datasheet, but the text here really isn't meant for beginners.

Comment #4 is actually quite good, but I'd guess it's somewhat confusing to a beginner? The pullup is essential, but the capacitors are not required to get this working. You would be wise to have them in a PCB design, but they are really just complicating things for beginners trying to blink a LED.

What you REALLY need to know

To get a bare bones dsPIC30F4013 up and running blinking a breadboard, you will need the following:

  • DIP version of the dsPIC30F4013
  • 10K ohm resistor
  • LED
  • 220-510 ohm resistor (for the LED)
  • PICKIT 3 programmer (or similar)
  • breadboard
  • Jumper cables

Locate the datasheet for the dsPIC30F4013 and find the page that explains the PINOUT.

Pin number 1 is marked with a dot on the chip. The text next to the pin shows that this is the pin with the MCLR function. We'll need that later. Place the chip so that pins 1-20 align with the numbering on the breadboard. Connect the 10k resistor from pin 1 (MCLR on the datasheet) to the 5V rail that runs along your breadboard. Connect all the pins marked as Vdd to the 5V rail and all the pins marked as Vss to the minus/ground rail. If you use the power rails on both sides of the breadboard, make sure you connect the minus on one side side with the other and the same for the 5V rail.

Next, connect the shorter PIN on the LED to Vss (minus/ground) and the longer to one end of the 220 ohm resistor. The other end of the resistor should go into the hole connected to Pin 19 (marked as OC4/RD3).

That's all that is needed for the Microcontroller itself. Now we need to connect it to the programmer.

On the PICKIT 3 programmer, there's 6 pins and one is marked with a small arrow. This is Pin 1. Here's how you connect the various pins:

PICKIT 3 dsPIC30F4013
Pin 1 (MCLR) Pin 1 (MCLR)
Pin 2 (Vdd) Vdd (5V power rail)
Pin 3 (Vss) Vss (Ground rail)
Pin 4 (PGD) Pin 9 (PGD)
Pin 5 (PGC) Pin 8 (PGC)

Note that these pin numbers will only be correct for the dsPIC30F4013. Other variants will need to use different pins, but you can locate these by looking at the correct datasheet.

With that connected, it's on to the code.

The code and the config

There are several things that are difficult to know that is required. The main reason for this is the absolute lack of good resources when it comes to tutorials and examples. MicroChip has examples in both the docs and online, but few of these are suited for beginners. The online examples are not publicly available in search engines. They are listed in a cumbersome tool that tries to be smarter than Google that allows you to filter. It's not smarter than Google and Google will never find and index these example files since they are ZIP archived.

Anyway - there's a few things you need to know before starting:

  • What to download
  • How to setup
  • How to set the frequency
  • How to configure
  • What to include

Start by downloading the MPLAB X IDE. This is modern IDE that has the features you'll need, but it's impossible to make it work on anything other than Windows. It comes with most, but not all the features you'll need. If you need to use Legacy libraries, you'll need to do some digging to find these. The normal download is sufficient for the LED example, but there's one confusing thing you must resolve - what compiler should you download? You've got to hand it to the people that named the microcontrollers from Microchip - they really did their best to confuse people! In my case I have a dsPIC30. Should I use XC8, XC16 or XC32?

For obvious reasons you would think that what compiler to use is mentioned in those almost 1000 pages of datasheets, right? Well, it isn't. You need to KNOW that the dsPIC30 is a 16 bit Microcontroller and that for any 16 bit microcontroller from Microchip you should use XC16. It amazes me that nobody thought of distributing all 3 compilers with the IDE and then just automatically select the correct compiler. The IDE will know what compiler to use when it's time to compile the projects since you have to tell what microcontroller it's working with. That brings us to the next part - setting up a new project.

Setting up a new project is fairly simple using the MPLAB X IDE. Select File -> New Project -> Microchip Embedded -> Standalone Project. Select your chip family and device and click through the dialogues. This only does the project setup. It doesn't even set up a single source file, so you'll need to right click the Source Files folder in the Projects window and then choose New -> mainXC16.c. You can rename this to anything you want (like main.c). This newly created file is more or less empty, but it does include the xc.h file that in turn includes the basic files for your microcontroller.

Next you need to know what frequency that your dsPIC30F will be running at. In most examples, this is referred to as FCY and the value of this is confusing. It varies across different microcontrollers, so you can't just use one you found in an example somewhere online. You'll need to search the datasheet for the "Oscillator Operating Modes". This is a long and confusing list of basic clock speeds that your microcontroller can run at. It is however easy to find the one needed for this example. Since we have no external clock signal attached, we need to use the internal oscillator built into the microcontroller. According to the datasheet, this is 7.37Mhz and you can find this set in the example below as SYS_FREQ.

Another important thing is to set the FCY variable. On this specific microcontroller this should be SYS_FREQ/4, but figuring this out is difficult. Reading the datasheet you can see that FCY =1/TCY. So what is TCY then? It's the "Instruction Cycle Time" dummy, don't you know? Well how on earth could I? Digging further I find that TCY = 1/MIPS and that MIPS = (FOSC*PLL)/4. So now you need to know what FOSC and PLL is then? Figuring that part out is difficult if you're not using either an external clock or crystal (if you're experienced enough to know what that is), but lets just leave it at that?

Next up is the CONFIG mentioned in one of the comments. Few beginners include this since ... it just looks insanely complicated I guess? It isn't all that hard, but it does require some former experience to get this right. What looks scary is all those FWPSB and WDT's. Luckily there's a tool built into the MPLAB X IDE that can set this up for you Window > PIC Memory Views > Configuration bits. In this dialogue, you tell the tool what oscillator you are using (hey, didn't you already do that?), prescaling,  watchdog and lots of other things that beginners really should not have to know… I understand that it's there for the advanced users, but to become an advanced user you just need to get a stupid LED blinking first, right?

Behold - now you're ALMOST there! The last thing you need to know (without anyone telling you) is that to just wait a little on a PIC you can't just use the builtin "delay" function. Why? It's not builtin… Include the libpic30.h file that includes the second most required utilities for the dsPIC30F family and your projects should compile. Phew!

// Useful advice!

// FCY must be defined before the includes or things go wrong.
// For some odd reason, the config tool does not set this based
// on the MCU + Oscillator selected
#define SYS_FREQ        7370000L
#define FCY             SYS_FREQ/4

// Device Config; generate using Window > PIC Memory Views > Configuration bits

#pragma config FOSFPR = FRC             // Oscillator (Internal Fast RC (No change to Primary Osc Mode bits))
#pragma config FCKSMEN = CSW_FSCM_OFF   // Clock Switching and Monitor (Sw Disabled, Mon Disabled)

#pragma config FWPSB = WDTPSB_16        // WDT Prescaler B (1:16)
#pragma config FWPSA = WDTPSA_512       // WDT Prescaler A (1:512)
#pragma config WDT = WDT_ON             // Watchdog Timer (Enabled)

#pragma config FPWRT = PWRT_64          // POR Timer Value (64ms)
#pragma config BODENV = BORV20          // Brown Out Voltage (Reserved)
#pragma config BOREN = PBOR_ON          // PBOR Enable (Enabled)
#pragma config MCLRE = MCLR_EN          // Master Clear Enable (Enabled)

// FGS
#pragma config GWRP = GWRP_OFF          // General Code Segment Write Protect (Disabled)
#pragma config GCP = CODE_PROT_OFF      // General Segment Code Protection (Disabled)

#pragma config ICS = ICS_PGD            // Comm Channel Select (Use PGC/EMUC and PGD/EMUD)

// Device Config /end (paste config between these two)

#include <xc.h>
#include <libpic30.h>

int main(void) {
    _TRISD3 = 0;
        _LATD3 = 1;
        _LATD3 = 0;
    return 0;

Oh? you don't know what those TRISD and LATD's are? Let me repeat that with comments so you have a remote idea:

int main(void) {
    _TRISD3 = 0; // set D3 to output
        _LATD3 = 1;       // turn D3 on
        __delay_ms(1000); // wait a second
        _LATD3 = 0;       // turn D3 off
        __delay_ms(1000); // wait a second
    return 0;

Yup. _TRISD is what Arduino calls pinMode, you know the method you use to set the mode of a pin? And yes - setting _LATD3 to 1 is similar (but not too similar or explanatory) as the Arduino digitalWrite method. Obvious once you know it, right?

You must be kidding, right?

No I'm not. It does sound like a joke, but it really is this convoluted to get a simple LED blinking. This is the exact reason that Arduino was founded - to be a counterweight to this elitist, top down world. I should note that I have seen similar things on the AVR Freaks forum also, but not this bad. I should also point out that the hardware itself works great, it's just incredibly hard for beginners to learn how to use it. One might argue that you can’t compare a chip manufacturer to a platform like Arduino that use many different chip’s in their designs. I’m not really comparing hardware here - I’m comparing the developer experience for beginners. As a teacher, that is a concern for me. If you start with an Arduino (like most do these days) you expect solutions to be that easy to work with in the future. If you come from Arduino, then you’ll instantly dismiss PIC as being unnecessary difficult. This is hardware, so you’ll loose slowly but you will eventually loose completely.

The forum thread mentioned above is not unique. After working with PIC the last months, I can tell that this top down view persists across the entire forum and unless you prove worthy you won’t get an answer. Developers from across the world are fleeing solutions based on PIC controllers. There is no reason you should have to pay the massive extra cost of poor documentation and a lack of examples. Even Chinese chip manufacturers such as Espressif (the makers of the popular ESP8266) managed to make better tooling and API within a year. Microchip should really look to companies like Particle and Electric Imp that sell advanced microcontrollers with builtin wifi and hardware encryption/decryption. Their APIs are super solid across multiple devices and they just work. If they want to be really impressed, they should study Paul Stoffregen's work on the Teensy. It's so much cool stuff happening in the microcontroller world, but Microchip isn't part of it.

PS: I know that Microchip makes lots of other things apart from Microcontrollers. It's just that this blog post is about just that and not the other things they do like sensors.

PPS: If you go to the Microchip website after reading this - they have an error in the website JS so no links will open normally in Chrome. Just right click and select "Open in new window" to view the pages. If you open the console, you can see that the error thrown is "Uncaught ReferenceError: ga is not defined" referring to the Google Analytics implementation that is broken.


Call me! (with Adafruit FONA)

09 Sep15

Call me! (with Adafruit FONA)

About a year ago, Adafruit launched the FONA. It's a neat little breakout board that packs all the features you'd want in a phone such as Calling, SMS, Data and Lipo battery operation and charging. Add to that a good API that is easy to extend and we have a winner.

By itself, the module can't do much, so you'll need a microcontroller of some sort. My preference is using a Teensy 3.1 since these are just incredibly flexible, fast & cheap. They're also small and placement friendly. By now I've used the FONA for two commercial projects and I thought it'd be nice to collect my experiences in this post.

Call for pizza using the ad on a bus station

The first project had me build the FONA into an advertising board. Check this video to see it in action. The large timer was connected to a motor that pulled it slowly back to zero. At each end position of the timer, there was a manual switch that triggered the FONA in different ways. When the timer was set to 15 minutes, the Teensy set the FONA to call up the pizza delivery. If the person turning the timer wanted, they could get a free pizza within 15 minutes. When the timer was set back to Zero, the Teensy prepared the FONA for the next customer.

As can be seen in the video, it was a snowy morning and I got to do some extra troubleshooting in the bus shed since the timer motor accidentally burned out the evening before and the replacement motor made so much electrical noise that it messed up the sensing on the button pins. I solved this by moving the button pins to analog pins and using a different threshold than the normal digital I/O used.

The FONA used a normal headset-mic to pick up the sound. To play it back I used some more Adafruit components - a 3.7W amplifier and these neat transducers. Despite being only 5W, it was not a problem to hear the sound on a busy Bus-stop when attaching the transducer firmly to the board itself. While the person waited for their pizza, we also played them some cheezy elevator-music. This came from the Teensy using the Audio Adaptor board. I really dig this board. So many cool audio things you can do. Really powerful!

The installation stood there for a whole day and worked without any issues despite the moist weather.

Call anywhere in the world for free!

The second project had us set up a telephone booth that looked kind of like a 1.2 meter tall iPhone. It was to promote the mobile provider MyCall and the idea was to make a phone booth where you can call for free (3 minutes at a time). JCDecaux also made a nice video for this one that highlights that the campaign gave 30% boost in sales.

The interface to the user was a 47" touchscreen showing a multi-screen AIR app that communicated with a Teensy 3.1 via Serial. Before calling, the user was asked to input their existing phone number. After their free call was finished, we used their phone number to send them a polite SMS telling that MyCall offered great prices on calls abroad (their specialty). The project stood outside in a very public space (outside the Oslo central station) for 10 days and worked without a single error. I'm really happy with the stability of the FONA/Teensy combination!

Both projects were done for JCDecaux with MesseTjeneste making the enclosures and me doing the software + electronics.

Fona tips and tricks learned

Here's some things that are nice to know about FONA that you won't find on the (as always) solid tutorial pages on

A lipo battery is indeed Required
The FONA needs a battery to be able to source the required power upon connecting to the network. A 2.2A / 5V dedicated power supply was not enough, but a half-charged 150mA lipo in addition to the USB connection did the trick. The lipo battery is now added as a requirement on the FONA product page.

GSM calling produces serious EMP
Once a call was placed or the FONA connected to the network, the audio chip in the Teensy Audio board was completely messed up. It produced random and unpleasant audible noise. I solved by moving the FONA away from the Teensy, putting them in two separate boxes. I also tried shielding them from each other, but I got very varying results. Much easier to just move them away from each other.

Not all SIM cards will work
I initially picked up a dirt cheap SIM card at a kiosk and it worked right away. This was from MyCall, the company I later made the kiosk for. I then needed to make a copy of the installation, but when I tried to use a SIM card from Norway's largest telco Telenor, it didn't work.

The SIM worked like a charm when inserted into a phone, but on the FONA I was unable to connect to the network. The SIM unlocked successfully, but I was denied access to the network. I later learned that holding down the KEY button for 20 seconds can solve this.

Library only covers some
I needed to blink some lights while a call was in progress and play some audio when the call ended. There currently isn't a method in the default library to check this, but all I had to do was to look up the SIM800L datasheet to find the required AT command.  I then looked through the Adafruit code to see how they had implemented similar features and added this (gist). It's all just serial AT-commands that are wrapped nicely. Super simple!

Using Teensy
Since the Teensy has several Serial ports, you may need to make some minor changes to the default FONA sketches and lib. I've detailed these in this gist.

Ideas aplenty

My initial thought seeing the FONA was to build a phone, but I still haven't done that. Instead, I've used it for installations. Using a phone rather than wifi or bluetooth has advantages and drawbacks, but there are some pretty cool things you can do with this. As an example of something I'd love to do:

  • Imagine an interactive window display controlled via SMS?
  • Using it as a transparent network access point?
  • Click-this-big-button-to-talk-to-support/sales?
  • Circuits that allow you to check status or remote control vending machines or controls? It would be really simple to make a machine send an SMS if it fails to do it's task, so it can alert you that it needs service.
  • It could also be perfect for simple surveilance of hunting spots or beehives in rural areas where there's no phone coverage
  • Turning on the heat at the family cottage via SMS

It's so many cool things you can do with this when you don't need to think about having wifi available!

I really dig how easy it is to build connected installations with the FONA board and it looks like others also think so since Adafruit has now expanded the range to also include a board with a GPS and some convenient starter packs. I'm looking forward to play much more with FONA in the future!


ESP8266 and stability

24 Mar15

ESP8266 and stability

Please note: this article is 3 years old. Since then a lot has happened to the ESP's. They're more stable since version 1.1x and they are now super easy to integrate with the Arduino IDE.

Like many others in the Maker Community I've spent a lot of time playing with the dirt cheap ESP8266 wifi chip. It is the cheapest way to add wifi to your project and it's easy to get hold of. My hope was that it would be solid enough that I could build permanent installations and fun Internet Of Things (IoT) devices with it, but the darn thing keeps crashing. I've been testing it since the 0.91 firmware and all the way up to the current 1.0 version and it's not possible to keep the device running for a prolonged period of time.

I've spent more than a weeks worth of time getting it to not crash at random intervals, so I thought I'd share what I've learned in case others find it useful.

Setting up for development

The best way to hook up these dev boards is to use the ESPlorer software (java) and getting a USB to Serial converter. If you have a version that offers 3.3V on both data and power lines (such as this one), it is the most convenient. If you can't find a 5V USB to Serial, you should know that the Serial pins (RX/TX) are supposedly 5V tolerant, but the power must be 3.3V or you will fry the chip. The ESP modules will pull a couple hundred mA, so powering it from a good 3.3V power source such as a LM1117 / LD33 can be a good idea.

There's many guides to hooking up the various development boards, so I won't detail that part, but lets look at the software side of things! When you buy the ESP-01 breakout boards from ebay, you never know what version of the firmware it comes with. Most likely it will be an old one so you'll probably want to update it. But - what firmware should you use?


NodeMCU is a firmware that adds a LUA layer on top of the (somewhat stable) official 0.95 Espressif SDK. This seems to be the most stable firmware you can currently use and it is also the one that is the easiest to get started with. It is well documented and offers good tools. Rui Santos has a great guide for hooking up an ESP-01, burn the NodeMCU firmware and setting it up as a webserver.

Briefly said, you hook up the ESP directly to a USB to Serial converter (3.3V!), download the NodeMCU Flasher tool, select the COM port and hit the Flash Button.

When that is done, download the ESPlorer software to talk to it. LUA is a very straightforward language to learn and if you're used to closures like in Javascript, you'll feel right at home. NodeMCU has a nice, documented API and several libraries that you can add for special hardware like LCD's, WS2812/2811 LEDs, sensors and more.

The NodeMCU firmware is based on the original Espressif SDK and thus inherits all the bugs it comes with. This means that the hardware will crash just as often, but since it always restarts after a crash, it will re-run your LUA script on startup. This makes NodeMCU good enough for devices that will just send some sensor data to a webservice such as Thingspeak. It will not work as an access point doubling as a webserver though. It'll crash and hang just as often as with the original firmware, so for me this is a showstopper. I want to make IoT gadgets that serve up a web interface as well as an open API.

Stock firmwares

Updating the firmware is quite easy if you use the NodeMCU Flasher. This has a nice, minimal GUI and everything is point and click. It's Windows only though, so if you like Python, check out the esptool. All the officially Espressif SDK's contain a "bin"-folder that has the precompiled files and a text description of what memory addresses to copy each .bin file into.

My initial idea was to use the UART in the ESP boards with a Microcontroller. Most my projects are based around the Teensy 3.1 and since it has 3 serial ports, so it's a breeze to do UART communications with. However, no matter how hard I tried, I couldn't make it 100% stable. After a few hours, it just crashed and restarted. It could run fine over night, but it would always crash after some usage. If there was a lot of traffic, it would crash more often and my intent was to basically bombard it with data continuously. I tried all the different versions of the firmware and even the official 1.0 version that was released this week is buggy beyond repair. It is actually so buggy that Espressif recently started an official bug-hunt...

That pretty much rules out using the official firmwares. How about making your own then? Espressif provides an SDK and the required code to compile your own version. Building it yourself is quite easy if you have a Ubuntu VM. Just follow the instructions outlined here. This will however not solve all your problems. Some of the codebase is Open Source, but other parts are provided as "binary blobs" so you can't really know what bugs are hiding inside. You can however exclude those parts of the Espressif SDK that you suspect to be causing the problems, so if want to program the ESP8266 directly check this neat guide on Hackaday.


This "Transparent Bridge" is the solution I'm currently experimenting with. It's a completely dumbed down firmware that can take a TCP connection on any port and relay it to the Serial port (RX/TX). Just apply power, connect to the WiFi access point that it sets up, Telnet to the default address and you can set it up to join your local network / access point. You can then up the BAUD rate to whatever you want/need and change the Port to for example 80 to make it work easily with browsers.

Anything sent to the ESP will then show up on the Serial connection. When you write back to a connection, you can serve data (like a webpage). Currently, this seems to be the most promising solution, but it requires some more testing. The basic idea is to use as little as possible of the buggy Espressif SDK as possible. To get the ESP Transparent Bridge firmware onto the device, just load the premade .bin files using the NodeMCU Flasher tool like this:

I'll post back here when I have more details & results on this setup.

But why care if it's buggy?

You might ask yourself - why on earth should one care about this chip if it is so buggy the creator has to host a competition to find all the bugs? The thing is - at $2 you can put wifi into ANYTHING! A typical wifi-shield for an Arduino will cost you from $30 and up to $90. Just a plain breakout board from Adafruit will cost you $35 and the CC3000 that it's based on isn't exactly stable either. A $2 chip that works would open up so many possibilities, so that's why I still care after fiddling this much with it.

A little about the hardware

I presume that you already know a bit about the hardware if you're reading this. If not, here's some details. The ESP8266 is a small powerhouse and this is a small 101 on the hardware. It's an ARM processor that runs at 80Mhz and can be overclocked to the double. It has up to 16 GPIO pins available and it does SPI, I2C, UART & more in hardware (fast!). It offers great range and you can get one for as low as $2 on ebay. Physically, it is a tiny 5 x 5 mm Integrated Circuit that needs a little supportive components around it to be useful. There is a series of dev-boards that offers this: ESP-1, ESP-2, ESP-3, ESP-4, ESP-5, ESP-6, ESP-7 and so on, all the way up to ESP-12. They differ with regards to pin spacing, internal/external antenna and the number of GPIO pins broken out. It was hard to locate all the pinout diagrams, so I've gathered them all in a github repository that I'll fill with useful code and resources. The original datasheets has some decent info, but check the ESP8266 wiki for more details.

The ESP-1 is typically the cheapest and most available. It only has 2 I/O pins broken out and uses 2.54mm headers. They are however clumsily combined into a 2x4 arrangement making them impossible to breadboard. It's not hard to make an adapter, but the ESP-2 is more practical for breadboard use. This also has a third I/O pin broken out, but requires an external antenna. The different versions all offer useful features, but the ones to avoid are ESP-5 and ESP-10. These do not have the pins required for updating the firmware exposed.

The version that seems to attract the community is ESP-12. It has FCC certification, RF-shielding, ADC and 9 GPIO's. It is included in the NodeMCU devkit that you can now get from TronixLabs and several other Open Hardware vendors. I'm looking forward to getting a couple of these to play around with. Other devboards that look interesting are the new one's from Olimex.



Project: wifi-enabled RGB LED displays

08 Jul14

Project: wifi-enabled RGB LED displays

Every now and then there's a project you can't say no to and this was one of them. is sort of Norway's version of Craigslist, a big online market where you can sell just about anything. As a marketing stunt, they opened a physical store downtown Oslo. I was called in via some friends in the agency that handled the project and they needed lots of things quickly. Since I was fully booked, I couldn't say yes to all the projects suggested so I passed some of them to my friend Thomas Winther who did a great job making an in-store Selfie-app using Unity & LeapMotion.

In the store they needed a way to show information from the website and this was the job I couldn't say no to. Apparently it isn't very easy to get hold of a wifi-enabled LED display that can pull data from the web? Also - most commercially available displays are small, monochrome and use tiny LEDs so they're not that visible when mounted high up on a wall. The agency wanted 5 large displays, perferably with more than one color display. Having recently read about Teensy 3.1 and the OctoWS library I promptly said I'd do it!

The Teensy microcontroller is a great alternative to using Arduino's in installations. It has a really fast ARM processor and lots of RAM, but it is still 99% Arduino compatible. This means that pretty much all Arduino code will run on it, but at blazing speeds. After installing a little extra software, you can use the normal Arduino IDE to program it, so it's really an "Arduino compatible". It's so compatible (and affordable @ $20!) that I feel that this is really the path that the Arduino Team should have taken instead of making bigger and more complex boards. Here's how the Teensy 3.1 looks next to an Arduino Nano. It's soo tiny that the Nano looks big!

For the parts, I could have saved some money by picking it up from different places, but I didn't have much time. I picked up tons of Neopixels & Teensy's from Adafruit since they'd ship the parts so I had them within a week. Buying parts from Adafruit really makes a difference since the whole process is completely trouble free. It's a little more expensive, but worth every dollar.

This is how the test-display looked when running the rainbow sketch:

Lovely, isn't it? You can see the neopixel strips lying in front. I stuck these to the back plate using the same clear silicone that I used to fix the panel to the front. The first test showed that we'd have to compensate a little for every 50cm as the neopixels are put together of 50cm segments and loose a few mm in the overlap between these.

Thanks to Jens Dyvik at Bitraf, making the wooden parts was short. Jens is really good at Rhino and CAM software, so the process from sketch to finished product was really swift. His huge Shopbot CNC'd all the lattices and backplates in one go! Nice to have good tools, right? Two things to note about the CNC'd parts:

  • When using MDF as material, make sure each protuding part has a certain minimum size or they'll break off easily.
  • Research carefully what kinds of silicone that will remain fully transparent over time. Most clear silicones will get a yellowish tone over time. The ones that are made for aquariums appear to be the most suited ones.
  • When exposed to heat for a long time, MDF will want to "bend". Make sure you stick it down properly to avoid too much maintenance.

Soldering and gluing together the displays took quite some time, but it was made a lot easier by Paul Stoffergren releasing these neat adapter boards. I added a 2.4Ghz radio to each of these and tucked it away on the back of each display. Here's a photo showing 1920 pixels running at once. Note that the Mac to the left is on full brightness! The displays are so bright that they're visible in daylight as well.

Each sign requires quite a bit of cable and with the amount of current going through them, this was the first electronics project I've made where I've had to calculate the correct diameter of each cable. A good learning experience!

I could have built a Wifi adapter inside each of the displays and in hindsight, that would have been an easier choice if it wasn't for wifi issues. What I went for instead was a server-client solution where a single box would connect to the internet as well as serve up a webserver that could be used to control all the 5 signs. It has a Teensy 3.1 that holds a custom webserver, uses cable for internet access, has a display that shows status and the IP address of the webserver as well as a nrf24l01 radio (2.4Ghz) that sends data to the signs. This is put together in a nice 3D printed box that is wall mounted.

It's a pretty versatile solution and it works rather well. There's two drawbacks to this solution:

  • The NRF24L01 radio's are dirt cheap, but they have a limited range and are affected by other 2.4Ghz radios (bluetooth, wifi & more)
  • The Ethernet library for Arduino is a synchronous API. When the device fetches data from the internet, it'll freeze a short while until the data is received.

None of those issues are big problems, but they're worth noting if you are building something similar. Initially I planned to use a Raspberry Pi to be the webserver, but it turned out to be really hard to make the NRF24 radios work reliably with GPIO on the Pi. I've since noticed that the NRF24 dislikes fast CPUs, so if you're trying to make this readio work on the Pi, make sure to add a delay to your main loop. The Teensy 3.1 is also too fast for this radio.

The final result is that you can use any device such as your phone to control what is displayed on each of the signs. I've also built some remote admin to it as well. Every time the displays power up they'll await instructions from the server. The server fetches API data such as how many tractors are for sale or what are the latest boats available, and sends this to the displays. It's super flexible and a true IOT solution.

Disregarding some (serious) mounting issues beyond my control, I really loved solving this project and you can check it out if you're in Oslo. 


After making this, my wife said that I should start making and selling these commercially. It's probably a good idea, but I really can't see myself selling LED signage. However - if you have some weird project in the Internet of Things domain - feel free to contact me. I love a good challenge!




X/Y robot with MakeBlock (Part 4)

17 Feb14

X/Y robot with MakeBlock (Part 4)

Have spent a couple evenings on getting GRBL up and running now. Here's my notes from setting it up.

Compiling GRBL on OSX

At Oslo Maker Faire, I finally met Simen Svale Skogsrud from the Oslo firm Bengler. One of their/his many cool side-projects is GRBL - a machine control software used for CNC, laser and 3D printers. As soon as I saw the Makeblock X/Y gantry, I knew that I had to make it run GRBL. Since most of the guides available seem to think that getting GRBL onto an Arduino is difficult, I thought that I'd write a small guide/tutorial for how I did this.

Start by copying / clone the source files from the Github repository to your machine. The precompiled versions could work, but I'll need access to the source later.

Download what we'll need

If you don't have the Arduino IDE installed, go get it from This contains all the command line tools we'll need, including avrdude (used for uploading code to the Arduino) and the avr-gcc compiler (converts source code to something the Arduino can use). The Terminal application is in the Utilities subfolder on your Mac /Applications/Utilities/Terminal. Open the app and type avrdude. If you get an error message along the lines of "command not found", we will need to setup the Mac to know where the AVR software are.

Adding the AVR tools to PATH

My original intent was to use LadyAda's tutorial ( for setting up AVR, but it's unfortunately quite outdated. Some of the external links are dead and I think it's possible to do this a little easier given that all the required tools are in the Arduino download.

Add your AVR-dude to the OSX path according to this tutorial. The AVR tool location on your machine will vary, but it will probably be somewhere inside your Arduino app folder like this:


After adding to the path, you'll need to close that terminal window and open a new one for the PATH to refresh. Typing "avrdude" in this new terminal window should now list all the options instead of "command not found". If not, go back to the tutorial above and try again.

Compiling the source

Now that we have the AVR tools in our path, we can go to the GRBL folder. I placed mine along with other Arduino code at /Users/jensa/Documents/Arduino/grbl/. Open open a terminal window and go to that folder:

cd /Users/jensa/Documents/Arduino/grbl/

To generate a .HEX file from the source code, simply type "make" and hit Enter.

If all goes well, you will now get a compiled program that you can upload to your Arduino. If something goes wrong, type "make clean" to remove the generated files. To see what other options are available, have a look at the "makefile" in the grbl folder. this is also where you'll adjust the compilation options if you're compiling for something other than an Arduino UNO (or other Atmega 328p-based devices).

AVR adjustments

To upload the hex file to the Arduino, you'll use "make flash". As long as the path has been set properly, that will compile just fine, but uploading it didn't go as planned. After figuring this one out, I found this official guide that could have helped me. To help others in the same situation, I'll leave how I got it working without this guide and the errors I got:

avrdude -c avrisp2 -P usb -p atmega328p -B 10 -F -U flash:w:grbl.hex:i
avrdude: can't open config file "/usr/local/etc/avrdude.conf": No such file or directory
avrdude: error reading system wide configuration file "/usr/local/etc/avrdude.conf"
make: *** [flash] Error 1

Looks like avrdude needs some custom configuration. Let's have a look at what's required. By typing "avrdude" on the command line, you'll get an overview of what's possible. From this, we can see that the "-C" flag allows us to set a custom configuration file. Since we are using the Arduino supplied version of AVR, we should probably use that config file as well. I found this file by using the find command in the terminal window:

sudo find / -name "avrdude.conf"

In my case, the path was:


so you're will probably be something similar. I added this to "makefile" after the other parameters for "PROGRAMMER" so that the line was now:

PROGRAMMER ?= -c avrisp2 -P usb -C /Applications/

Running "make flash" now returned a different error message:

avrdude: usbdev_open(): did not find any USB device "usb"

Right… That makes sense. In the Arduino IDE you're always specifying paths that start with /dev/ and such. You can find the correct port using the command

ls -l /dev/cu.*

This returns a list of possible devices and it's the same you'll find in the Arduino IDE. In my case it was /dev/cu.usbmodem411. Note: do not have the Arduino IDE open while doing this as it can cause trouble.

My "PROGRAMMER"-line in the makefile was now like this:

PROGRAMMER ?= -c avrisp2 -P /dev/cu.usbmodem411 -C /Applications/

I still got errors though:

avrdude: stk500v2_ReceiveMessage(): timeout

Ok. I've seen this one before. It basically means that your config is correct, but something is incorrect with the programmer. The programmer is set with the "-c" flag and here it's set to "avrisp2". That's the same as using "AVRISP mkII" in the Arduino IDE and that won't work with an Arduino UNO board. How about removing the number 2 so we get this:

PROGRAMMER ?= -c avrisp -P /dev/cu.usbmodem411 -C /Applications/ -carduino

Note the addition of -carduino at the end there? It helps with defining the right board. Ohhh! It's uploading! Now let's see if this works. We should be able to log onto the GRBL installation using the Arduino serial monitor. Bingo.

For figuring out the rest, I looked a lot at this tutorial that details how to use GRBL for a laser engraver. It's a little outdated, but has tons of good info!

For some defaults, I tried what is found on the GRBL wiki. That didn't work too well with the MakeBlock setup I have. Instead I ended up on using something like this:

$0=12.650 (x, step/mm)
$1=9.000 (y, step/mm)
$2=25.000 (z, step/mm)
$3=5000.000 (x v_max, mm/min)
$4=5000.000 (y v_max, mm/min)
$5=500.000 (z v_max, mm/min)
$6=500.000 (x accel, mm/sec^2)
$7=500.000 (y accel, mm/sec^2)
$8=10.000 (z accel, mm/sec^2)
$9=200.000 (x max travel, mm)
$10=200.000 (y max travel, mm)
$11=200.000 (z max travel, mm)
$12=10 (step pulse, usec)
$13=2500.000 (default feed, mm/min)
$14=192 (step port invert mask, int:11000000)
$15=25 (step idle delay, msec)
$16=0.050 (junction deviation, mm)
$17=0.005 (arc tolerance, mm)
$18=3 (n-decimals, int)
$19=0 (report inches, bool)
$20=1 (auto start, bool)
$21=1 (invert step enable, bool)
$22=1 (soft limits, bool)
$23=0 (hard limits, bool)
$24=1 (homing cycle, bool)
$25=224 (homing dir invert mask, int:11100000)
$26=100.000 (homing feed, mm/min)
$27=500.000 (homing seek, mm/min)
$28=100 (homing debounce, msec)
$29=2.000 (homing pull-off, mm)

An error that had me stumped for a long time was that the limit switches would be hit all the time causing the GRBL error:

ALARM: Hard/soft limit. MPos?

I searched and searched until I found this post regarding testing of homing in 0.9. Oh my… GRBL wan't to work with a 3 axis setup? How on earth could I know that… Well. I guess I could change the Z-axis a bit. That way I could even fit a Dremel on there? Hmmm! That sounds interesting…