Micromint Bambino 200 brings multi-core performance to mbed applications

08 May 2013

We at Micromint are excited to announce our Bambino 200 SBC based on the dual-core NXP LPC4330. Thanks to your open sourcing of the mbed SDK, we are supporting mbed development by encapsulating gadgeteer sockets into a class library. mbed applications can run on both cores (a cortex-M4 and a cortex-M0) at up to 204 MHz. For more details please visit the product page.

Production units of the base Bambino 200 will be available on May-31 for under $25 in single quantities. For custom configurations please contact our sales staff. Both hardware and software for the Bambino 200 are licensed as open source. Once boards are shipping we'll contribute the lpc43xx and lpc43xx_m0 ports to the mbed repository.

Thanks,

Jesus Alvarez, Micromint USA

08 May 2013

Looks like an impressive board at a good price. But these gadgeteer cables... are not for DIY work. I understand pins are at .05". Very compact but incompatible with the usual .1" pin distance. So for every breadboard experiment I need some adapter. Soldering such a small flatcable is no fun. Would be nice if you come up with a clever solution.

The Bambino 200 E has much more connectors. But is it the same size as Bambino 200?

08 May 2013

Looks really great! But how can you make use of the full dual core power using the mbed platform? Using RTOS library? It would be a waste of computing power if only a single core would be used. Maybe somebody from the mbed team can comment on this as well?

09 May 2013

Thanks for your comments and feedback.

Gadgeteer pins are 0.05" (1,27 mm). One way to interface to 0.1" headers is to use breakout modules (5 for $5 at Mouser). Some third party modules can also help interfacing with breadboards, Arduino shields and other peripherals. Later this year Micromint will also offer other interface module alternatives.

The Bambino 200 and Bambino 200E share the same form factor, 4” x 2.3” (101.6 x 58.4 mm).

Both cores on the LPC4330 can certainly operate simultaneously at 204 MHz. Each core has its own interrupt vector table so ISRs can also be concurrent.

A common way to use asymmetric cores in embedded applications is to partition software tasks between cores. In other words, predetermine which core should do which tasks. In many cases the application requirements are a good starting point to determine the partitioning strategy. For example, on a motor controller the M0 can be designated to handle commands and communications via serial, USB and Ethernet interfaces while the M4 manages real time PWM and analog I/O. The M4 has DSP instructions available so it is a good choice for closed loop control or digital filters. Mailboxes in shared memory can be used when commands and data need to be exchanged between cores.

On the LPC4330 the cores share SRAM and I/O via an internal bus matrix. You can implement logic in your firmware to arbitrate resource access dynamically at runtime, but that requires more overhead so you should do it only when absolutely required. Following the partitioning strategy, it is simpler to designate which core has access to which resources statically (at compile time), e.g. separate memory blocks for each core's program data, set I/O's to be handled by each core, etc. From an mbed application's perspective, one way to think about it is as if you had two microcontrollers each with designated memory and I/O interfaces but with some shared resources like flash, microSD or mailboxes in SRAM.

Good task partitioning and resource arbitration strategies are as important as firmware efficiency in achieving high utilization rates on both cores. Software partitioning in asymmetric cores is much simpler than task scheduling in symmetric cores and does not require an RTOS. Some iteration in task partitioning is usually required during development to optimize core utilization, but most embedded applications do not need to move tasks dynamically from one core to another. In fact, in asymmetric processors this is difficult. In the case of the LPC4330 the M4 and M0 are not 100% binary compatible due to the different ARM architectures (ARMv7-M vs ARMv6-M) and instruction sets, so moving binary code between them would be challenging. If multitasking is required you can still use an RTOS to multiplex tasks within any of the cores.

09 May 2013

Looks like a very nice device for a very nice price. I think it would be benificial if there is an example program of using both cores together. Also how it is it programmed? Will there be mbed drag and drop programming on it? And I assume with the normal deepsleep commands you can disable a core?

Also would be nice if there is a blogpost regarding this board :)

09 May 2013

Thanks for the compliments. We appreciate the opportunity to support mbed applications with the Bambino 200.

The base boards will be shipping by the end of May and the enhanced boards by mid June. At those times we'll provide documentation and examples on our wiki as we do with our other off-the-shelf ARM board designs.

Using the Keil MDK to build mbed applications is supported in the initial production builds. Within two months of release, using the gcc distribution by CodeRed will also be supported. At the moment we don't have plans to support mbed drag and drop programming or the online compiler.

There are APIs for the M4 to turn the M0 off and on. Controlling sleep modes will not be in the initial builds, but should be available by the time gcc builds are supported. Source code is provided so you have the freedom to use other master/slave arrangements or implement other features. Both hardware and software are open source.

09 May 2013

OK... for me only supporting KEIL or CodeRed would be the deal breaker.

I am pretty shure that I am not alone with the following reasons to choose mbed over other MCU boards:

- mbed gives you full control over the MCU - You don't have to invest in an IDE, since it is available for free - as a browser app - on all platforms - Without loosing much time in learning IDE specifics, you can start writing convinient C++ code.

So, as long as you don't support a free and convinient IDE like the online toolchain from mbed, your board is not an option for me (although I would love to use such a performant MCU). But again, I am only a hobbyist. A professional who already has a license for KEIL or something similar might benefit from your approach. However, these professionals most likely already have everything in place and don't depend on mbed.

Just my opinion, but I definitely think that your product is interesting.

Regards

Tobias

09 May 2013

Thanks for your comments.

We understand the mbed online compiler is a good alternative for some projects. Unfortunately, there are no procedures to add project options so our boards are listed in its "Add a device" option. Possibly this will be more flexible in the future. In the meantime, using the mbed online compiler restricts you to hardware similar to the supported boards (currently mbed LPC1768, mbed LPC11U24 and Freedom KL25Z). Using boards with a different ARM MCU (such as the NXP LPC4330 in the Bambino 200) is not really viable with the online compiler at this time. With the fast evolution of cloud IDEs (Cloud 9 and others), it is just a matter of time before there are online options for building ARM binaries without restrictions on target hardware.

Using an offline compiler does give you more control over the debugging and build, as well as the freedom to use any MCUs you so desire. Setup and configuration are more complex, but Keil and CodeRed have improved significantly over time. Cost is also a factor, although NXP's acquisition of CodeRed should make it more attractive (for projects using NXP MCUs).

09 May 2013

I understand your reasoning, and for more professional users it also won't matter. But I do have to agree with Tobias that just for hobbyist the online compiler of mbed is ideal, both for the libraries of other users and that it simply works. No screwing around with setting correct paths in 20 different locations inside the compiler just to include a piece of code.

I would guess that adding it to the device list should be possible when talking with mbed guys (then again, maybe I am wrong), but you would need drag and drop programming also then.

09 May 2013

I also would like to see a detailed hardware manual.

09 May 2013

Don't think it should be too hard to add support to the online IDE. Infact, we've been working on ways to make it easy :)

Perhaps with your guys help we can add and test it in betamode, and look to add it fully in one of the next releases?

Simon

09 May 2013

Simon, those are great news! Thanks for the update. I was not aware there were plans for supporting third party hardware in the mbed online compiler.

Once the boards are shipping and the the lpc43xx and lpc43xx_m0 ports are in the mbed repository, we can focus on working with the mbed staff on the options for supporting LPC43xx builds with the online compiler.

Jesus Alvarez

19 May 2013

Wow !! to be able to combine NETMF and MBED in the same chip is brilliant.

At the beginning my project was split between 2 MCUs: STM32F4 NETMF for the core and MBED for image analysis and display. Then I replaced MBED with LPCxpresso because at that time source level debugging was not possible with MBED. Finally when NETMF for the STM32F4 could be compiled with GCC, I wrote NETMF native interop extensions and moved everything to the STM.

Still I like it better when split in two and your offering seems to be the perfect answer.

still WIP: http://www.youtube.com/watch?v=4MkRRm61LAY

04 Aug 2013

I know this thread is old but is there any news on how things are progressing? I know there were delays with the NETMF side of things, but have not heard anything about how MBED support is going.