I stumbled across this NXP press release for the LPC134x.

It says "The on-chip USB drivers support both the Mass Storage Class (MSC) and Human Interface Device (HID) class. Furthermore, these drivers are incorporated in ROM, saving customers approximately 5-6 K bytes of user code"

Looking at this presentation, (slide 25), the chip shows up under Windows (and they say Linux) as a Flash drive. It has this capability built in at manufacture! No need for a bootloader, JTAG, or a second chip. Solder it on a board, and it should 'just work'!

An entire USB-based micro-controller board only needs an LPC1342 or LPC1343, a crystal, voltage regulator, a few passives and PCB.

The LPC1342 is available from Farnell for £2.20 and LPC1343 for £2.70 or £3.30.

These micro-controllers are less powerful than an mbed (no ethernet, for example), but comparable to an Arduino's ATmega168 or ATmega328.

HTH, GB-)

The USB bootloader has been available on NXP's site for some time, now they just programmed it into the ROM. Still a nice thing to have.

I agree lots of chips have USB bootloaders.

There are two key points with this LPC134x:

1. The bootloader in manufactured onto the chip, so there is no need for an in-circuit programmer, and
2. It doesn't need a driver to program it.

Having a bootloader on-chip, at manufacture, means that I could make a PCB for school children, or anyone, to make a DIY micro-controller, and they wouldn't need any extra development tools. That isn't true for most micro-controllers. This makes low-volume devices much easier and cheaper to make.

Making the chip look like a flash drive means there is no need to install a driver on the host PC, making it much easier to install the software tools for schools, and individuals. Mbed is one of the few micro-controllers that has that benefit, and it uses a lot of extra technology to get there.

IMHO, LPC134x changes the ground-rules for Arduino-cost micro-controllers, offering an ARM path for low-cost, lowest-complexity boards which school children could make for themselves. (schools in the West Midlands are moving from through-hole to SMD because it is easier and quicker to make, more reliable and uses mass-production technology which both students and teachers prefer).

The LPC13xx series is a cut down LPC17xx with a lower clock and less peripherals, the lack of CAN is what puts me off, but I'm guessing their trying to not stamp all over the STM32F103

The LPC1768 is around a fiver in single unit quantites so the cost savings on small volume are not that significant, the LPC1768 supports the same USB bootloader (mbed uses its own to provide the USB port for other purposes).

There is also a built in Serial bootloader in the LPC17xx, though not usb, it is easily loaded though, there's an article/notebook page on here somewhere showing you how to use the mbed to do it.

From an educational perspective having all the different interfaces on tap that this device provides many more opportunities for learning and development.

For the sake of a couple of quid I personally buy the LPC1768 or mbed as an educational tool.

The configuration would be pretty much the same for LPC1768 you would just need 3 pin header for a USB->TTL Serial interface to program the USB bootloader.

If you want JTAG functionality you still need a JTAG unit.

Andrew, you may be telling me something I didn't discover, so please bear with me.

I would be totally happy if every ARM family (every micro-controller) had devices which had "manufactured in" driver-less bootloaders. Some STM32F's have a USB DFU bootloader. IMHO, the flash-drive approach is better than DFU because it both avoids the need for a host driver, and also dispenses with a host application (not all OS's have DFU support); the file-system browser or 'file finder' does the job for a flash-drive loader.

I looked at the LPC1768 datasheets, including document AN10866 "LPC1700 secondary USB bootloader". It looked like the bootloader is serial (USART) only, and hence requires either a USB to serial converter, or a JTAG interface in order to get a USB botloader installed. Are you saying their is a USB boot loader already installed in a LPC1768 which works like the LPC134x bootloader, and implements a flash drive for program flashing?

For me, the cost and effort comparison between the two devices is 'soup to nuts'; all of the pieces and effort to boostrap from nothing to a working development system. You might be assuming we have some of the parts already, and we don't. My guiding model is to scale to thousands of schools or people starting with nothing, so any extra hardware changes the costs dramatically. I'm trying to strip it to the essentials.

It looks like anyone could make a LPC134x system for about £5-£6 for components + PCB + USB cable. If we can design a single-sided PCB, people could even make that for themselves. The result would be a simple development board which they could bring up without any drivers, and without any other USB interface or SPI hardware. It could use a development environment like the Mbed web-based compiler, or a traditional one - it wouldn't matter.

If we could get a more powerful micro-controller for a few £'s more, that would be brilliant.

But if we need a JTAG programmer, or USB to serial adapter too, the cost comparison is different, and the complexity much higher using LPC1768.  While I'd like the extra resources, the cost to get started is approximately 3-4x more, and not just a few £'s.

Does the LPC1768, or any member of the LPC1700 family, have a driver-less USB bootloader "manufactured in"? Would you please point me at it?

TIA - GB-)

Yes USB->TTL Serial is required to load the USB bootloader from NXP this is what I said, but it does make the processor flash behave like a USB drive, read section 4 of AN10866. (You can write your own to work from any interface e.g. Ethernet, CAN, RS485 etc)

You can hack a Nokia DKU-5 cable to do the job (~£2-3)

No they don't come manufactured in with USB Bootloader.

The issue you would face is the extra cost of adding those capabilities to the LPC13xx series devices adding a MAC + PHY for Ethernet, CAN Tranceiver through 'shield' boards with their own PCBs etc would easily outweigh the cost of the DKU-5 cable or even a conventional USB to TTL cable.

Thank you for the clarification.

Okay, so comparing the cost of complexity of an LPC134x board is not an "apples for apples" comparison with LPC1768. To bring a LPC1768 board up, either people hack a Nokia DKU-5 cable to make their own USB to Serial adapter, or get a 'proper' USB to serial adapter, or a JTAG programmer.

All of these solutions are more expensive than an Arduino/Freeduino. As I wrote, Arduino is my benchmark cost and capability. I'm aiming for half-price, i.e. £7/$10 micro-controller with comparable capabilities, and not more expensive even if it gives more capabilities.

The important point about the LPC134x for me is it removes cost and complexity. I was attracted to Arduino because of its low cost of entry and ease of use, and I find both children and adults respond the same way.

I am probably out of step with most Mbed users, but I prefer a lowest-cost, least complexity solution over richer peripheral sets. IMHO, an Arduino is enough to learn an amazing range of things. I think most Arduino users get a lot of value from it, and many never exhaust its capabilities. An LPC134x is better, and would cost less. I'd love Ethernet, but I'd like to attract 2x more users even more :-)

Of course, if someone released an ARM with a USB-flash-drive bootloader, and Ethernet, for a sub-Arduino price, I'd be very happy (no driver, no weird loader application, supported on most platforms, i.e. Windows, Mac, Linux, ...). I'd happily spend time making boards, and porting software to it. Frustratingly, all the pieces exist, just not in an off-the-shelf device, and all it needs is a pre-programmed part, no new electronics (are you reading this NXP, ST, Atmel, TI, ...?). STM32F105 is a near solution, but DFU doesn't seem to be properly supported on all major platforms. STM32F105, LPC17xx, SAM3U or LM3S with the right USB bootloader would all be good for me.

Thank you very much for taking the time to write, you've helped me clarify my thinking.

GB-)

Nice to see this conversation unfolding! We're obviously concentrating on making mbed successful with the first hardware platform at the moment, but I wouldn't like you to think we haven't got others planned out with alternate cost/feature trade-offs :D

Keep the comments coming!

Simon

Simon Ford wrote:

Nice to see this conversation unfolding! We're obviously concentrating on making mbed successful with the first hardware platform at the moment, but I wouldn't like you to think we haven't got others planned out with alternate cost/feature trade-offs :D

Keep the comments coming!

Simon

Well, if you can pursuade ARM manufacturers, especially all Cortex-M3 producers, to produce low-cost parts which have a USB flash-drive bootloader built-in, then IMHO the hardware will solve itself; you will have less need to develop more hardware because others will do it because it'll be so cheap and easy. (IMHO, if USB DFU was nicely supported on most OS's, i.e. so devices looked like flash drives or files, then it would already have been sorted).

GB-)

It's good for us users in a position where we cannot justify a £100/200 for some form of programming interface

However for the manufacturers the incentive is not as strong, development and education count for less than 1% of sales.

In manufacturing paying £10,000 for a programming station is feasible when you're making thousands of units.

Also preventing the user from directly modifying the system is sometimes in the device manufacturers interest, having a system that is too easily accessible may be detrimental to sales.

Now I respect there are protection systems, but these are not infallible

The path that may gain more interest from manufacturers is technology advancement, i.e. the childish 'Mine's better than yours!'