When it comes to electronics, collaboration can generate some truly amazing results. The Micromite Explore-28 is one such example.

Four people, spanning three different countries (Australia, New Zealand, and the United Kingdom), have come together to take a simple PIC prototype into a full functioning, powerful production board. We caught up with Robert Rozée from New Zealand, to take a close look at the Explore-28.

For those of us who aren’t familiar with using PIC micros, for practical purposes, what’s the difference between a PIC and, say, an Arduino?

It mostly comes down to the memory resources and onboard peripherals - almost everything out there running on single-chip micros is written in C, and so details of the chip architecture are generally well hidden from the programmer’s view. Things have come a very long way from the days when you needed to code in assembler, in order to gain sufficient speed and fit your program into available memory space.

The main reasons Geoff Graham selected the Microchip PIC32MX devices for creating the Micromite, were because of three key features that other chip manufacturers could not match in a single device:

1. A 32-bit processor;
2. It was housed in a hobbyist-friendly 28-pin DIP package; and
3. It had an extremely large onboard memory.

The first Micromite used an MX150, containing 128k of flash memory and 32k of RAM. This was just enough space to squeeze a complete floating-point BASIC interpreter and full-screen editor into, leaving around 20k of flash for holding the user’s program and 20k of RAM for variables.

Soon after Geoff created the Micromite, Microchip released the MX170 with double the flash and RAM (256k and 64k respectively), enabling a good deal of “wiggle room”, which was quickly consumed by the addition of 64-bit integers and support to drive small colour touchscreen displays.

The largest flash/RAM combination offered at the time by Atmel, in a DIP package, was 128k of flash and 16k of RAM in the 40-pin ATmega1284. That was it. There was no roadmap leading beyond these constraints, and so any 1284-based Micromite would be pegged at just 4k of user RAM. The 1284 also has a maximum clock speed of 20MHz, while the MX170 goes up to 50MHz.

While other manufacturers offer single-chip devices with more flash and RAM, none of them (that I can think of) currently offer the same quantities of flash and RAM in a pinned package as does the PIC32MX line from Microchip. For the hobbyist those little pins that can plug into a solderless breadboard are pure gold, far more important than any philosophical discussion over chip architecture.

Micromite helps take the pain out of PIC programming. Do you lose anything (such as speed or efficiency) when using MMBasic over Assembler or other compilers?

There are always compromises. Certainly one can write far more compact code in Assembler (or C), and it will run much faster. Remember, BASIC is an interpreted language and so will always be 20 or more times slower than Assembler. But BASIC has some distinct advantages, which can more than make up for the slower speed and larger memory requirements.

For a start, BASIC is much simpler to learn, and this can lead to a considerably shortened development time for your project. For the hobbyist this is especially true where a project that might take six months of learning (in Assembler or C) may never even be started. Compare this to perhaps a few days of development if the same task was coded in BASIC. Sure, the BASIC program might be slower, and use more ‘computing resources’, but does this really matter? From tinkering with Micromite BASIC over the last few years, I can say with some confidence that in the vast majority of hobbyist projects, speed and size of code are of no importance. Indeed, this also holds true for many commercial projects - computers, from the biggest right down to the tiniest, have advanced to the point that computation resources are only ever an issue in quite rare and specialised cases.

In cases where speed is absolutely essential, MMBasic does allow the user to embed within their BASIC code, and call C or MIPS Assembler routines that have been pre-compiled and converted into hexadecimal format. These are called “C-functions”, and the feature has been used to great effect by Peter Mather to add support for various colour LCD displays, additional software serial ports, and to directly manipulate on-chip peripherals. Some of these C-functions are distributed with the language documentation, while the most popular ones have ended up being incorporated directly into the MMBasic interpreter by Geoff. While creating C-functions is not for the faint-hearted, and there are some limitations to what a C-function can do, the facility is there.

Another plus for the Micromite is the ability to very quickly experiment and directly see what happens. In the hobby sphere, Arduino is often considered the benchmark. Now don’t get me wrong, I do believe the Arduino ecosystem is great, but because the code is compiled, there is always the compile-download-run cycle to go through. If your code compiles but doesn’t work correctly it can be extremely difficult to figure out why - the little computer your code is running on is not very “accessible”; you cannot easily look inside the 328P processor on an Arduino board and see what it is doing. So for the beginner, this limitation can be daunting.

With the Micromite you, the programmer, are much more intimately connected with what is going on inside the chip. You can type in code and instantly see what the results are, and if your code does crash then the MMBasic interpreter ensures that it does so fairly gracefully, and gives you a good measure of feedback as to where things came unstuck. This has always been one of the big pluses for interpreted languages such as BASIC or Python.

Instant feedback is definitely useful, especially when learning. In terms of application speed and functionality, what’s the benefit of a MX170 over an ATmega328 (Arduino Nano)?

If we are talking about an MX170 running an MMBasic program that could also be rewritten in C for the 328P (the 328P has 32kB of flash and only 2kB of RAM available, compared to 59k of flash and 52k of RAM for MMBasic programs and variables respectively.), the C code will almost always be faster than the BASIC code. But as I have said earlier, speed is not nearly as critical today as it was, say, 10 or 20 years ago. MMBasic provides many non-speed related advantages, such as ease of learning and speed of development, as well as inbuilt support for a number of different peripherals that the beginner may want to start out experimenting with. For instance, a single statement can read a DS18B20 temperature sensor, another can write to a two-line LCD display module.

If we are talking about an MX170 running C code, then the MX170 will easily outperform the 328P. The 328P is an 8-bit core running at 20MHz tops, while the MX170 is a 32-bit core running at up to 50MHz. The MX170 has 256kB flash and 64k RAM, while the 328P has 32kB flash and only 2kB of RAM. The MX170 is a far larger and more sophisticated bit of silicon, while costing only twice the price of a 328P (US$4 versus US$2 from Microchip direct).

The reason for the two answers is that the Explore-28 board does not have to run MMBasic. There are projects such as Pinguino and chipKIT (with a PIC32 core extension) providing an Arduino-like experience. It is quite conceivable that either of these could be adapted to work with the Explore-28 with little effort.

THE EXPLORE-28

Running on MMBasic, with the form-factor of an Arduino Nano, the Explore-28 provides the speed and efficiency of a PIC microcontroller, but can be programmed directly from your USB port. We continued the conversation with Rob Rozée to talk more about the E-28 and how it came together.

Anyone with a keen eye looking at the pictures of the board will notice, the E-28 uses two PIC micros on the one board. Can you detail the role of the 16F1455 in the board?

The 1455 provides two specific functions that the MX170 cannot perform itself:

1. It works as a USB to serial bridge using the open-source M-Stack USB stack. The MX170 does not have onboard USB itself, so in most cases when working with a bare DIP MX170, you would need to use something like an external CP2102 bridge module to connect to a PC.
2. The 1455 also contains an implementation of ‘ASCII ICSP’. This is a protocol that allows the 1455 to be used to upgrade the MX170’s firmware using a programme called pic32prog. I developed ‘ASCII ICSP’ specifically to allow easy uploading of the Micromite firmware to the MX170 after seeing the complexity of using the official Microchip solution - the MPLAB X IDE (a 400MB download) and a PICkit 3 that costs around $50 from Microchip. Micromite BASIC is always evolving with new enhancements and bug fixes, and from very early on users were having to deal with this expensive and complicated firmware update process.

As it happens, originally “ASCII ICSP” ran on an Arduino Nano. My code for the Nano was converted by Peter Mather to run on the 1455, and then integrated with M-Stack by Peter, through a long chain of emails between us running back and forth around the globe.

Thank goodness for the internet - imagine going through that process via post! What is the biggest benefit of this setup, over using the MX170 on its own?

The biggest benefit is having one simple-to-use package that contains everything, much as an Arduino board “contains everything”. The MX170 runs Geoff’s Micromite BASIC; the 16F1455 provides the USB to serial bridge as well as a very simple means to perform firmware upgrades; and an onboard regulator provides a regulated 3V3 supply (MMBasic assumes a 3V3 supply for the onboard A/D converters to read right).

The MX170 in a DIP package is a marvellous solution for many applications, and those pins are what I feel make the Micromite magic. The Explore-28 simply expands upon this, and helps open up MMBasic to those who perhaps aren’t so confident plugging the necessary parts together, or whose application fits with the all-in-one solution.

So you’re using two chips to still gain that simple connectivity. That’s great! When did you realise this was a winning combination and wanted to move from prototype to hardware?

To be honest, it’s something I had in mind right from the very start and so it was a process of continual and slow evolution. If I were asked to provide an exact moment I’d have to say 20 April 2014 at 5:43pm, which was when I started a thread on The Backshed Forum, titled Simplest 32MX150 ICSP. This forum is talk-central for all things Micromite.

Geoff’s first release of Micromite BASIC for the (then) MX150 had amazed everyone. Previously there was his Maximite BASIC (running on an MX695, VGA output, PS/2 keyboard and programs stored on an SD card), but the Micromite stripped back the hardware even further, to the bare minimum - one chip and one capacitor. However, some folks were struggling to get the firmware into the chip, and I could see that the existing solutions were beyond the abilities of many MMBasic enthusiasts. So, I started the aforementioned thread.

I’d worked with Arduino before, and had been impressed by the all-in-one nature of the whole Arduino system. It significantly reduced the barriers to tinkering with tiny computers, but there were still some hurdles (and nasty hidden potholes). Some people managed to brick their Arduinos due to a small design flaw that was finally rectified in the UNO rev3 but never publicly admitted to by the designers; and while the Arduino IDE does a great job at taking care of much of the drudgery of programming in C, there are still barriers. For example, C is simply not that easy to understand for the non-programmer, and an Arduino sketch that fails is not very pleasant to try and debug. While lots of people do great things with Arduino, lots of people also walk away due to frustration.

So, I set about trying to bring together the advantages of the two. This required following several threads, or “lines of enquiry”:

• Software to upload PIC32 firmware
• Firmware to interface to the ICSP port on the MX170
• Hardware components to sit between the USB port and MX170.

The forum thread kicked off several solutions, and proved that some quite hopeful approaches were simply not viable. The task of talking to an ICSP port was (just) beyond the ability of simple bit-banging solutions - alas, a USB to serial bridge on its own was not sufficient.

The process followed through several stages, along with a few breaks of several months at a time. Getting in touch with Serge Vakulenko was a major turning point, as he helped me get set up to add ‘ASCII ICSP’ support to pic32prog. At the same time I used a spare Micromite to act as a crude programming head - this enabled me to get the software sorted without the final firmware and hardware. Once pic32prog was sorted I took a break of a few months, then moved onto the firmware and hardware, in the form of an Arduino Nano, five resistors, and a zener diode. The firmware was an Arduino sketch (C code) to translate a stream of ASCII symbols (essentially eight letters: d,e,f,g,D,E,F,G) into clock and data pulses. This was then published as a Silicon Chip Magazine article, and after that I stopped again for a few months.

As I said before, I’d always had in mind the “final product” being all the bits on a single PCB, much like an Arduino board. This was already sort-of-there in that if the reset pin of the Nano was jumpered to ground, the RxD and TxD pins from the Nano’s onboard USB bridge could be used to communicate with an attached Micromite, while the Nano’s 328P processor was held in reset.

The use of a 1455 was kicked around a bit on the forum, and someone did come up with a solution based upon my Arduino sketch and Microchip’s own USB stack. Unfortunately, however, the licensing of Microchip’s code precluded the source code being released, and the binary image that was created was tied to a VID/PID pair owned by that one person.

After some discussions with Peter Mather, I did a little research and came upon the M-Stack USB stack. This was open source, and so Peter set about combining it with a reimplementation of ‘ASCII ICSP’. We used a public VID/PID pair and were able to “release it into the wild” after a short development period of just a few weeks. This was the last thread needed to bring together the final design for the Explore-28.

That’s quite a process. Did it take you long to get a working final board?

While Peter and I got the 1455 code working, I built the prototype. I posted photos of this on the forum, and not long afterwards Graeme and I had an email discussion about converting it to something the size of a Nano.

I believe it took a couple of months as we worked back and forth over the board layout. We started out with the QFN-packaged MX170 because we both believed that neither of the other two SMD options (SOIC and SSOP) would fit onto the board. Right from the start we used four layers; the two internal ones being ground and 3v3, with signals on the two outer layers. It was only when it came to assembling the QFN packages onto completed PCBs that I realised how much of a pain they were to solder by hand (not impossible, but really hard), so after the initial run we quickly decided to revisit the other packaged options. Of the QFN boards that went out, I am only aware of one single bad QFN solder joint, which is an absolute miracle, looking back on it now!

As it turned out, the largest SMD package - SOIC - could be fitted. When it came to assembly, the SOIC boards were an absolute pleasure to populate - not only in the soldering of the MX170, but also because this time around we’d gone to the trouble of lining up all the resistors and capacitors in the same orientation, making it much quicker to place and solder them.

Apart from some boards that were accidentally ordered without the internal layers filled in, all others were fully functional and could be shipped to customers. I guess it does help that, electrically-speaking, the design is very simple, so there was not too much opportunity for things to go wrong.

What hurdles did you experience going from prototype to production board, in terms of circuit design, differences between DIP to SMD, or anything else?

Well, the circuit was very simple, and had been worked out well in advance. There is a little bit of non-standard wiring around the 1455’s power pins, but it was determined that this was okay, through a few emails to Microchip’s engineers.

The board layout was conducted via email between myself and Graeme. We both have backgrounds working with SMD parts - in my case, going back to several years at Trimble Navigation where I had to deal with 14-layer designs; by comparison, the Explore-28 is a walk in the park! Graeme handled the CAD layout. He’d send me proofs and I would mark them up with required changes using Photoshop, before emailing them back. It worked really well and meant that we got to review each other’s work. One cannot underestimate the importance of peer review during the design process.

The PCBs were fabricated by PCBGOGO in China. Ten boards that are 100mm x 100mm cost something like US$50 for four layers, while the same in two layers are a little over US$10; the prices are ridiculously cheap.

Those prices are definitely very accessible. Why would someone choose an E-28 over something such as an Arduino Nano?

There will be some cases where an Arduino Nano is the best choice, there will be other situations when an Explore-28 is the better option, and there will be scenarios where a bare MX170 is ideal. There is no one solution for every situation.

My first piece of advice would be that if you find the Arduino a little intimidating, or have tried using the Arduino system in the past and struggled, then give the Explore-28 a go. The board is quite cheap, and the learning curve for Micromite BASIC is extremely shallow.

Micromite BASIC also has some very nice built-in features that may require a bit more work to get going with an Arduino. There are 64-bit integers, a full set of floating-point maths routines, support for a number of neat devices available as single commands and, of course, an intimacy that only comes with an interpreted language. All you need to talk to any Micromite is a terminal emulator such as Tera Term, so it is a very lightweight development environment.

That said, even if you are a seasoned engineer working in a commercial environment, you may still favour an Explore-28 (or DIP MX170) for certain things. For example, if you want to quickly whip up something in half an hour, then a Micromite solution may be ideal. Often speed of running code is not a big issue, whereas speed of development is. Even if you plan on moving to different hardware later on, a Micromite is a good test platform on which to experiment with ideas and create mock-ups. Bear in mind, I used a Micromite to create the first ‘ASCII ICSP’ programmer before migrating it to an Arduino Nano and then (coded by Peter Mather) to a 1455.

That’s a great point. So often as a hobbyist we’ll look at tech specs without giving too much thought for development time itself. What are some practical uses for the E-28, out in the wild?

Like the Arduino Nano, the Explore-28 is tailored to applications where the device is going to be tethered to a USB port. This may be collecting data from peripherals, that is then processed and passed on to an attached PC. Or it may be controlling attached devices - Micromite BASIC supports controlling RC servos, has a couple of spare serial ports, along with I2C and SPI busses accessible from BASIC. Whereas a PC running Windows, Linux, or OS X can not sensibly run applications in real-time, a Micromite is simple enough that it can. Millisecond timing is possible, which is often perfectly adequate for interacting with the physical environment. Frequencies up to 300kHz can be measured, as can the time between pulses.

Another practical use is in a teaching environment. While it is all the rage to talk about teaching kids object-orientated programming, I see great value in taking a step back and concentrating on algorithms and interactions with the physical world. Initially, BASIC was developed as a teaching tool to open up computers to non-technical users, to enable them to process data; and this is a task that the Micromite is well suited to, extending to include the collection of data from sensors and controlling devices. The Explore-28 provides this in a cheap and relatively robust package.

Sounds very robust to us. Are there any improvements still to come?

We are all still waiting for Microchip to release an MX190 with double the flash and double the RAM. Geoff Graham is actively developing Micromite BASIC, and with the ability to easily upgrade firmware, the Explore-28 is in a position to take advantage of this. Apart from a few minor tweaks to the PCB layout, I am hoping that the Explore-28 will be able to remain stable and unchanged in design for quite a while. Really, it is a very simple device that would be difficult to improve upon.

The one thing I would like to see happen, is for someone in China to pick up on the design and make clones. The compiled Micromite BASIC firmware is free to distribute, and everything else in the Explore-28 design is open source. If clones flooded the market at US$5 each I’d be absolutely chuffed - the more the merrier!

Robert, we thoroughly enjoy (and appreciate) your open-source approach with the Expore-28. We’re excited to see where it goes in the future!