Sometimes it seems like Arduino is everywhere. However, with a new glut of IoT processors, it must be quite a task to keep the Arduino core on all of them. Writing on the Arduino blog, [Martino Facchin], Arduino’s chief of firmware development, talks about the problem they faced supporting two new boards from Nordic.

The boards, the Nano 33 BLE and Nano 33 BLE Sense are based on an ARM Cortex M4 CPU from Nordic. The obvious answer, of course, is to port the Arduino core over from scratch. However, the team didn’t want to spend the time for just a couple of boards. They considered using the Nordic libraries to interact with the hardware, but since that is closed source, it didn’t really fit with Arduino’s sensitivities. However, in the end, they took a third approach which could be a very interesting development: they ported the Arduino core to the Mbed OS. There’s even an example of loading a sketch on top of Mbed available from [Jan Jongboom].

On the one hand, this has two big advantages: in theory, Arduino can now run on anything that supports Mbed, which is quite a lot. Second, even though the system retains the simplicity of Arduino, the entire Mbed system is available to Arduino developers and vice versa.

On the other hand, you could argue that if you have Mbed, you don’t really need Arduino. While much is made about Arduino’s simplicity, it is really a C++ program with two predefined functions and an IDE that builds your code without as much explicit help as you’d expect. However, the wide variety of code that supports Arduino should be of interest since you could just use it from either an Arduino or Mbed program without much effort.

This might make some of our favorite Mbed labs projects more popular. If you want to see our take on an Mbed project, you can turn it into a signal generator.

Thanks [halherta] for the tip.

Even a cursory glance through a site such as this one will show you how many microcontroller boards there are on the market these days. It seems that every possible market segment has been covered, and then some, so why on earth would anyone want to bring another product into this crowded environment?

This is a question you might wish to ask of the team behind Explore M3, a new ARM Cortex M3 development board. It’s based around an LPC1768 ARM Cortex M3 with 64Mb of memory and 512k of Flash running at 100MHz, and with the usual huge array of GPIOs and built-in peripherals.

The board’s designers originally aimed for it to be able to be used either as a bare-metal ARM or with the Arduino and Mbed tools. In the event the response to their enquiries with Mbed led them to abandon that support. They point to their comprehensive set of tutorials as what sets their board apart from its competition, and in turn they deny trying to produce merely another Arduino or Mbed. Their chosen physical format is a compact dual-in-line board for easy breadboarding, not unlike the Arduino Micro or the Teensy.

If you read the logs for the project, you’ll find a couple of videos explaining the project and taking you through a tutorial. They are however a little long to embed in a Hackaday piece, so we’ll leave you to head on over if you are interested.

We’ve covered a lot of microcontroller dev boards here in our time. If you want to see how far we’ve come over the years, take a look at our round up, and its second part, from back in 2011.

In Still better I-V plot for Schottky diodes, I had some lessons learned at the end of the post:

1. Higher-resolution ADCs do give smoother curves, with less digitization noise, but they aren’t a panacea for measurement problems. To get most of the resolution, I had to set the ADC to use long sample times and do a lot of averaging. I understand that Freescale Kinetis M series include 24-bit sigma-delta converters for higher precision at much lower speed (24 bits is 7 decimal digits), as well as the high-speed 16-bit successive-approximation converters. Unfortunately, they don’t have a low-cost development board for this series.
2. Stay away from the bottom end of the ADC range on the KL25Z.  Scale single-ended inputs to have values at least 50, and differential inputs to have values at least 20.  There may be similar problems at the top end of the range, but I did not test for them.
   I wondered if the problem may be switching from the large value for the voltage across the diode to the small voltage across the shunt resistor that was the problem. I tried putting in a dummy read between the voltage and the current reads, but that didn’t help at all. At first I thought that the low-count readings were good with the large shunt resistors, but this is probably an illusion: errors in the current measurement for small currents aren’t visible on the plot, because the voltage across the diode is not changing, and so large horizontal errors in the plot are not visible there.
3. Watch out for AC noise when trying to measure DC parameters.  If there are semiconductor junctions around, the noise may be rectified to produce an unwanted DC signal.
4. The differential ADC settings have a range of ±VDDA, not ±VDDA/2. This means that the least-significant bit step size is twice as big for differential inputs as for single-ended inputs. For some reason the Freescale documentation never bothers to express what the differential range is.
5. Serial USB connections are a bit flakey—the Arduino serial monitor missed a byte about every 200–300 lines.  I looked for anomalous points on the plot, then commented out the lines that produced them—they were almost all explainable by one character having been missed by the serial monitor; e.g., I commented out “662401069     86      19″ right after “660001069       865     17″,  because the last digit of the voltage (the second field) was missing.  The fields were a timestamp (in 24MHz ticks), voltage across the diode (in ADC units), and voltage across the shunt resistance (in ADC units).  [Actually, this was not a new lesson for me—I've had to do the same on almost all files collected from the Arduino serial monitor.  My son's data logger code is better at not losing data, but it is still worthwhile to check for anomalies.]
6. The 3.3v supply from the Freedom board is much cleaner than the 5v USB supply that I get from the Arduino (unless I use an external power supply with the Arduino), but I can only take about 10mA from the 3.3v supply before it begins to droop.  If I want  more than that, I’d better provide my own power supply (or at least my own LDO regulator from the USB 5v supply).

I’d like to correct a few of those lessons in this post.

1. A 24-bit sigma-delta converter is really only about 7 bits of accuracy—you are relying on oversampling with a single-bit comparator, then low-pass filtering.  Your resolution is a function of frequency, but the “24-bit” number is misleading—that’s how much precision they carry in the low-pass filter computations, and has little to do with the amount of information you can actually extract from the ADC. I think I was confusing sigma-delta converters (which are fast, cheap, and not very accurate) with dual-slope converters (which are slow and more accurate).
2. no update.
3. no update.
4. no update.
5. The UART communication from the Freescale KL25Z boards, using MBED’s code on OpenSDA chip to do the UART to USB conversion is much less reliable than the Arduino serial connections.  My son has been doing testing and has found that he can run the Arduino boards up to about 500k baud without losing characters (aside from a small number right after a reset), but the MBED-implemented UART communication on the KL25Z lost tens of character per second even at fairly low speeds (tested own to 62.5kbaud). We suspect a bug in their code in which they ignore the UART port for too long while dealing with the USB side.  (He’s not the first to notice that the MBED serial communication is broken on the KL25Z boards.) Using the MBED USB stack natively on the KL25 chip (not the SDA port), he had no noticeable character losses, so the problem is not on the host computer or the software he was testing with, but on the MBED implementation of the USB serial connection on the OpenSDA chip.
   This bug in MBED’s serial implementation has raised the complexity of the port of the data acquisition system to the KL25Z enormously, as he’ll have to implement a USB stack (or enough of one to do USB serial) on the KL25, rather than using the buggy one on the OpenSDA chip.  The MBED USB stack (written in C++) is not compatible with the bare metal ARM platform he’s been using for the port (which only seems to support C).  He’s gotten the USB code to compile and link, but is having trouble getting it to run—we suspect that some part of the C++ memory management has not been initialized properly.
   We have not checked whether the PEMicro OpenSDA software works for serial communication—since it doesn’t work for downloading software from the Mac, we can’t use it anyway.
6. As I reported in Diode-connected nFET characterisitics, the 3.3V LDO on the KL25Z boards is actually pretty good: it can be modeled as 3.32V source with a 55mΩ series resistor. I got a steeper voltage drop above 500mA, but that was from overloading the USB 5v supply that was powering the board, not from problems with the LDO.
   I’ve not yet tried powering the board with a beefier power supply on the P5-9V_VIN pin. I suspect that it will be able to handle up to 1.5A without problems (maintaining the 55mΩ impedance).

In Still better I-V plot for Schottky diodes, I had some lessons learned at the end of the post:

1. Higher-resolution ADCs do give smoother curves, with less digitization noise, but they aren’t a panacea for measurement problems. To get most of the resolution, I had to set the ADC to use long sample times and do a lot of averaging. I understand that Freescale Kinetis M series include 24-bit sigma-delta converters for higher precision at much lower speed (24 bits is 7 decimal digits), as well as the high-speed 16-bit successive-approximation converters. Unfortunately, they don’t have a low-cost development board for this series.
2. Stay away from the bottom end of the ADC range on the KL25Z.  Scale single-ended inputs to have values at least 50, and differential inputs to have values at least 20.  There may be similar problems at the top end of the range, but I did not test for them.
   I wondered if the problem may be switching from the large value for the voltage across the diode to the small voltage across the shunt resistor that was the problem. I tried putting in a dummy read between the voltage and the current reads, but that didn’t help at all. At first I thought that the low-count readings were good with the large shunt resistors, but this is probably an illusion: errors in the current measurement for small currents aren’t visible on the plot, because the voltage across the diode is not changing, and so large horizontal errors in the plot are not visible there.
3. Watch out for AC noise when trying to measure DC parameters.  If there are semiconductor junctions around, the noise may be rectified to produce an unwanted DC signal.
4. The differential ADC settings have a range of ±VDDA, not ±VDDA/2. This means that the least-significant bit step size is twice as big for differential inputs as for single-ended inputs. For some reason the Freescale documentation never bothers to express what the differential range is.
5. Serial USB connections are a bit flakey—the Arduino serial monitor missed a byte about every 200–300 lines.  I looked for anomalous points on the plot, then commented out the lines that produced them—they were almost all explainable by one character having been missed by the serial monitor; e.g., I commented out “662401069     86      19″ right after “660001069       865     17″,  because the last digit of the voltage (the second field) was missing.  The fields were a timestamp (in 24MHz ticks), voltage across the diode (in ADC units), and voltage across the shunt resistance (in ADC units).  [Actually, this was not a new lesson for me—I've had to do the same on almost all files collected from the Arduino serial monitor.  My son's data logger code is better at not losing data, but it is still worthwhile to check for anomalies.]
6. The 3.3v supply from the Freedom board is much cleaner than the 5v USB supply that I get from the Arduino (unless I use an external power supply with the Arduino), but I can only take about 10mA from the 3.3v supply before it begins to droop.  If I want  more than that, I’d better provide my own power supply (or at least my own LDO regulator from the USB 5v supply).

I’d like to correct a few of those lessons in this post.

1. A 24-bit sigma-delta converter is really only about 7 bits of accuracy—you are relying on oversampling with a single-bit comparator, then low-pass filtering.  Your resolution is a function of frequency, but the “24-bit” number is misleading—that’s how much precision they carry in the low-pass filter computations, and has little to do with the amount of information you can actually extract from the ADC. I think I was confusing sigma-delta converters (which are fast, cheap, and not very accurate) with dual-slope converters (which are slow and more accurate).
2. no update.
3. no update.
4. no update.
5. The UART communication from the Freescale KL25Z boards, using MBED’s code on OpenSDA chip to do the UART to USB conversion is much less reliable than the Arduino serial connections.  My son has been doing testing and has found that he can run the Arduino boards up to about 500k baud without losing characters (aside from a small number right after a reset), but the MBED-implemented UART communication on the KL25Z lost tens of character per second even at fairly low speeds (tested own to 62.5kbaud). We suspect a bug in their code in which they ignore the UART port for too long while dealing with the USB side.  (He’s not the first to notice that the MBED serial communication is broken on the KL25Z boards.) Using the MBED USB stack natively on the KL25 chip (not the SDA port), he had no noticeable character losses, so the problem is not on the host computer or the software he was testing with, but on the MBED implementation of the USB serial connection on the OpenSDA chip.
   This bug in MBED’s serial implementation has raised the complexity of the port of the data acquisition system to the KL25Z enormously, as he’ll have to implement a USB stack (or enough of one to do USB serial) on the KL25, rather than using the buggy one on the OpenSDA chip.  The MBED USB stack (written in C++) is not compatible with the bare metal ARM platform he’s been using for the port (which only seems to support C).  He’s gotten the USB code to compile and link, but is having trouble getting it to run—we suspect that some part of the C++ memory management has not been initialized properly.
   We have not checked whether the PEMicro OpenSDA software works for serial communication—since it doesn’t work for downloading software from the Mac, we can’t use it anyway.
6. As I reported in Diode-connected nFET characterisitics, the 3.3V LDO on the KL25Z boards is actually pretty good: it can be modeled as 3.32V source with a 55mΩ series resistor. I got a steeper voltage drop above 500mA, but that was from overloading the USB 5v supply that was powering the board, not from problems with the LDO.
   I’ve not yet tried powering the board with a beefier power supply on the P5-9V_VIN pin. I suspect that it will be able to handle up to 1.5A without problems (maintaining the 55mΩ impedance).

Introduction

Now and again we examine various development boards designed for use with the mbed development platform for ARM microcontrollers, such as the the original mbed unit and the Freescale Freedom FRDM-KL25Z – and now we have another one from NXP … their new LPC800-MAX development board:

Although the LPC800-MAX works with the mbed online compiler, you’re not limited to that. NXP have also supplied free offline development tools based on the Eclipse IDE.

Hardware specification

The board is based on the NXP LPC812 with an ARM Cortex-M0+ Core running at 30 MHz. The LPC812 has 16KB flash memory, and 4KB RAM. For I/O you have 3 x USARTs, 2 x SPI ports,  one comparator, and one I2C port. The serial lines are brought out to a separate serial expansion connector to allow easy connection to a range of expansion boards from the manufacturer. An RGB LED is fitted to the board for all the “hello, world” fun you could want, and for extra I/O (and I2C practice) there’s a four-channel NXP PCF8591 ADC (and also gives you one DAC as well – convenient) along with a PCA9672 I/O expander IC for more GPIO. 

If you’re using the offline development IDE you can also make use of the NXP hardware debugging interface as well. Users of the physically-narrow range of NXP LPC development boards will also recognise the two parallel rows of pinouts down the length of the PCB, and Arduino users will recognise the header sockets (more on those later). When you receive the board – you just receive the board, so you’ll need a typical microUSB cable. Finally, you can download the LPC800 MAX schematic for further examination.

What is mbed anyway?

mbed is a completely online development environment. That is, in a manner very similar to cloud computing services such as Google Docs. However there are some pros and cons of this method. The pros include not having to install any software on the PC – as long as you have a web browser and a USB port you should be fine; any new libraries or IDE updates are handled on the server leaving you to not worry about staying up to date; and the online environment can monitor and update your MCU firmware if necessary.

However the cons are that you cannot work with your code off-line (no working in-flight) and there may be some possible privacy issues. Here’s an example of the environment:

As you can see the IDE is quite straight-forward. All your projects can be found on the left column, the editor in the main window and compiler and other messages in the bottom window. There’s also an online support forum, an official mbed library and user-submitted library database, help files and so on – so there’s plenty of support.

Code is written in C/C++ style and doesn’t present any major hurdles. When it comes time to run the code, the online compiler creates a downloadable binary file which is copied over to the hardware via USB, from which point you reset the board and off it goes.

If you’re using the LPC800-MAX with mbed, be sure to follow the “Getting Started” guide and also check for the latest firmware from the mbed handbook. And although the mbed board appears as a USB storage device, you can still have serial communication with a PC using a virtual serial port via the USB cable connected between the PC and the LPC800-MAX.

Arduino form-factor compatibility

You will notice the header sockets physically match the Arduino Uno R3 specification, so you can drop in an Arduino shield. However the board runs on 3.3V and is 5V-tolerant, so it’s preferable your shields or new designs are good for 3.3V operation. Furthermore, as the onboard LPC812 doesn’t have as much analogue and digital I/O as an ATmega328P found on the Arduino Uno, the extra I/O are provided by two external ICs via I2C. Four analogue inputs are provided by the onboard NXP PCF8591 ADC (and also gives you one DAC as well – convenient) – and the equivalent A4 and A5 pins are not ADC, instead they’re just I2C SDA and SCL respectively.

The extra digital I/O pins are provided via I2C by the aforementioned PCA9672 I/O expander IC. Upon reflection you’d have to be very keen to use a specific Arduino shield as some extra coding would be required to deal with the required I/O – however on the other hand you can easily add external circuitry with blank Arduino protoshields for new projects. Finally, here’s a pin map of the shield connectors.

Not a fan of mbed? Offline tools

NXP have also made their LPCXpressoIDE based on Eclipse available for free download for all platforms – http://lpcware.com/lpcxpresso/download. The free version is good for up to 256 KB code size (provided you register the software) which more than covers the requirements for this and other LPC800 products:

For more information and support, there is a huge repository of information on the NXP website.

Where to get an LPC800-MAX

The board is manufactured and sold by Embedded Artists. At the time of writing the board retails for €15, which is around US$21. NXP also have a range of LPC800 microcontrollers, including very inexpensive through-hole 8-pin versions which are available from the usual retailers. And adafruit of all places have a US$13 starter pack based around the DIP LPC810, which is an interesting 32-bit alternative to the ATtinys out there.

Conclusion

If you’re interested in working with the NXP LPC800-series of microcontrollers, the LPC800-MAX board is a very convenient development board considering the included debugger, Arduino protoshield capability, external GPIO expander and ADC/DAC and onboard LED – as well as the free IDE.

If you enjoy the mbed development environment, the board gives you another hardware option. However if you’re an Arduino user looking for a cheap way of getting a faster board whilst using your existing environment – this is not for you. The product under review was purchased without the knowledge of the supplier.

Full-sized images can be found on flickr. And while you’re here – are you interested in Arduino? Check out my new book “Arduino Workshop” from No Starch Press.

In the meanwhile have fun and keep checking into tronixstuff.com. Why not follow things on twitter, Google+, subscribe  for email updates or RSS using the links on the right-hand column? And join our friendly Google Group – dedicated to the projects and related items on this website. Sign up – it’s free, helpful to each other –  and we can all learn something.

The post Review – NXP LPC800-MAX Development Board appeared first on tronixstuff.