Hi,

A few people have asked about how to take a design based on the mbed Microcontroller to a production prototype.

I have written and few notes on the steps involved, and given some links to resources. I have also put up a set of Eagle schematics of the LPC1768, DP83848 Ethernet Phy, and all their support passive, basically the main parts of the mbed Microcontroller design you might want to use in a product.

It is a first attempt, there is clearly a lot missing. As I figure out what other information is needed/useful I'll update the page.

http://mbed.org/projects/cookbook/wiki/Prototype2Product

Feel free to add/amend/comment/discuss.

Thanks,
Chris

A question that has arisen from the original post:

What is the proposed strategy in moving from quick prototyping to production? What is a reasonable path from moving from the online complier and the mbed firmware to an off-line compiler and rtos or comprehensive system software?

mbed is all about rapid prototyping, and the online compiler is there to help quickly experiment with ideas, prove concepts and gain confidence that your ideas are valid.

At the point when you need to move to an offline compiler, use full debug and an RTOS, you are no longer in the domain of rapid prototyping, but product development. This is a well served market with many vendors of tools, boards, middleware and consultancy services, and they are far better suited to your needs at that time.

As your mbed board is at heart simply an LPC1768 microcontroller you can use any tool chain to generate the binary. This isn't something we actively support at the moment, as our focus for now is with the online compiler.

If the binary you have generated using the online compiler is suitable for your production prototype, you can continue to use it on your own custom PCB.

The Prototype2Production page is meant to outline how to take your binary from the mbed hardware and move it onto your own custom Hardware. The story isn't fully worked out for the software side of things, but we do need a page of guidelines on how to move from an experiment in the online compiler to a full software development environment.

Cheers,

Chris

I'm about to select a processor for prototyping a product.  I tried the mbed in my application and was pleased to find that I got the basics up and running quickly. I When the time comes I'd like to be able to move efficiently from a working prototype to a finished product.

But as I understand it the mbed libraries are not public.

One of the main benefits of prototyping on the mbed is the ability to use the libraries.  It seems that not having the library code available would be an obstacle to moving from the mbed module to a non-mbed LPC1786?

For example, a while ago I posted on this forum about whether the HID mouse code is available to use as a basis for other HID development: http://mbed.org/forum/mbed/topic/146/?page=1#comment-2263  I never received an answer.

What's the plan for making the source code available?

- Chris Graham

I think Simon has covered this here http://mbed.org/forum/mbed/topic/711/?page=1#comment-3560. The upshot is that you can just use the binary file on your custom board freely and as the bin uses no extra magic it will run on a non-mbed LPC1768 (although I have never tried this myself) as demonstrated by Chris's link above.

The "closed" aspect is that you cannot see how the core library functions are implemented but I believe this is more down to the desire to keep the core library stable than anything else and they are well documented so I have never had a problem. I'm not sure what the feeling is about user contributed libraries though...

I saw that  post from Simon.

But I may well want to take the code deveoped on the mbed to another development envrionment for further testing with better tools, or for enhancement with non mbed libraries (that would be less efficient to test and implement in the mbed IDE).  In any event, it would be too risky to go to product stage without assumance of access to source code in case there are bugs in an mbed library, or extended functionality that the mbed group chooses not to address.

Basically I'd rather prototype with some other module than take these risks.

I understand the desire to keep the core library stable but I'm not proposing that anyone be allowed to modify the official code, just that the code be available if I need it.

Until there's a better solution I think mbed won't be as widely used as it could have been.

- Chris Graham

I would also like to add a vote for opening the code base. But I understand it's not always easy, especially in big companies like ARM where a lot is decided by people not directly involved in the project.

That said, you don't have to prototype "with some other module". You can still use mbed, just with some other code base that has source code available. E.g. NXP has a pretty extensive DriverLibrary, which covers most of the LPC1768 peripherals. It might be not as convenient as mbed's classes, but can be a good start.

I've just spent an evening learning to drive the free version of Eagle and using the schematic from http://mbed.org/projects/cookbook/wiki/Prototype2Product. Here are a few observations based on an evening of use:

Deal-breaker issues:

• Support a more easliy (hand) solderable package for the ethernet PHY
• Add named wires to the remaining LPC1768 pins so these can be connected by the user on sheet 1

Nice to haves:

• Add the MagJack alongside the ethernet PHY (incl LEDs!)
• Add a serial ISP header to connect to UART0 to allow programming with FlashMagic. (Ideally with FTDI cable compatible SIL header)
• Add mini 10 pin JTAG header (Allow the user to delete the one they don't want - it appears the free version will allow you to delete from schematic pages > 1)

Bug fixes

• +A3.3v (sheet 2) doesn't seem to go anywhere else - I presume there should be some guidance on what to do with it?
• C18 (sheet 4) comment presumably should refer to OSC 1

Hi,

Very interresting thread.

I start to move my app to mbed and i hope to finally make my own board and use the online mBed compiler.

My fear is about ethernet PHY... DP83848J seem a little bit tricky to sold on a board and seem to be in "end of life", it's available on Digikey, but Farnell say "it is no longer manufactured".

Could someone have another "easy to solder, low cost and available" PHY interface reference to use with LPC1768 ?? ;-)

if i use another phy interface, would it have an impact on the mBed TCP library ???

Like you Dan, i imagine add JTAG header and FTDI on UART0 to have an usb ISP access.

My final need is to have on my own board :

- Uart 0 thru FTDI (ISP and serial debug message).

- Uart 1 to my external device

- Uart 2 to Xbee

- Sdcard (on SPI 0)

- Ethernet

- I2C connector (RJ12)

- I/O -> leds and buttons.

After reading the LPC1768 datasheet and mBed scheme, the "problem" seem to be the PHY interface.

If you have found solutions about PHY...

Thank you.

Chris