has anyone given any thought to porting the mbed enviornment to a lpc1788 platform?

Your best bet is Uvision http://mbed.org/forum/mbed/topic/1932/ does not seem like you can select it in the device menu but the specs are really close for the lpc1768 and lpc1769, or might not be any diffferent, maybe you could just select them and it will work.

I'd like to +1 this please, there's some epic SDKs out now for the LPC1788, including the HY-LPC1788 with a 7" touchscreen TFT and shedloads of connectivity options :)

Hi Jason,

As you may have seen, we've been doing some work to make it easier for us and others to port to other microcontrollers. The LPC1788 is going to be pretty close to the LPC1768, so is this something you'd be willing to have a go at if we gave you some guidance? Or if you can rally some support from someone who can?!

Simon

Hi Simon, thanks for the speedy reply

I've been doing a lot of work with the LPC1768 as of late and loving it, but the problem is it's not really suited to field work. I wanted to use something linked above and hopefully continue to use my mbed code.

Yesterday I bought the above linked product, it should be here within a fortnight, but I am more than happy to not only help you, I'll happily donate money to your foundation and / or buy one and get it delivered to your offices just to get support for this hardware added to the mbed.org compiler.

Lemme know what you think :)

Kind regards, Jason

Hi Simon / Jason,

We already use the LPC1788 (and the older LPC2478) in our products so would also be very interested in the options for mbed support for this micro .

We're even looking at the newer LPC43xx/LPC18xx families (and some of the Freescale Kinetis M4-based micros - the new K20-based Freedom board is now available) for some new developments, so the more general guidance would be most useful.

I'd be glad to help where I can too.

Cheers,

Jez

Hi Jason, Jez,

Would the HY-LPC1788 be a good reference platform for both of you?

It'd be good to have a single platform to work around. I'd be happy to get one in to do any sign-off testing/validation of the port.

Simon

I'm unable to comment for Jez but I've just bought one, so yeah :)

Hoping Jez comes back with the same answer.

Kind regards, Jason

Hi Simon / Jason,

I've not got that board (we went for the Embedded Artists LPC1788 dev kit over a year ago) but don't want to rock the boat, so I would be fine to work on the processor-specific parts & map that onto our hardware & the EA kit.

We're using the LQFP208 package on our hardware (so that's a bonus) - if the schematics for that board are available then porting it for our application would still be a great advantage.

So, I'll help where I can but will have to rely on Jason/the mbed team to do the real testing.

It's still a much better proposition for us than doing it in isolation.

Cheers,

Jez

Hi again,

I won't confess to being an expert when it comes to ARM chips nor C++, mbed was my break into both realms. What I am good at however is learning quickly and putting in research time.

I may be simplifying it here, but if it's a case of digitally wiggling pins and testing them with a logic probe, I can help with that for example. I've got an oscilloscope and logic analyser at my disposal. Anything more involving I can probably help with but may not be the most suited to the task.

I also don't mind buying Jez a HY-LPC1788-CORE module if it helps, they're only 26 quid :)

Kind regards, Jason

Just a quick update regarding rallying.

It's not quite rallying support from another developer, but I've asked a couple of friends at an undisclosed UK electronics enthusiast suppler website if they're interested in backing this too by helping to source and provide UK stock.

Naturally its likely they (or anyone else) will only invest time and money importing these modules if it's likely that support will be added (bit of a catch-22), so I don't mind getting a couple more of these modules to give to reputable devs to get ball rolling quicker.

Kind regards, Jason

Hi Jason,

That's a very kind offer - it would certainly make it easier to have the same core hardware.

It might be worth waiting until we see exactly how much 'tweaking' the existing LPC1768 code will need to support the basic LPC1788 peripherals before going ahead & buying any more though.

I'm a bit rusty with C++ (it's about 15 years since I last used it regularly) so an more comfortable in C but have a fair bit of experience with ARM (mostly ARM 7 & Cortex-M-class). I'm hoping that will still be enough to help with the porting - maybe Simon can bear this in mind when giving us the guidelines?

I'm still really keen to get the LPC177x/178x family into the mbed fold (and then re-use that knowledge to add other processors in the future).

Cheers,

Jez

The device specific code for the mbed is all written in C, the C++ wrappers aren't device specific.

I wouldn't mind helping if it goes ahead, but I don't have LPC1788 hardware myself.

Hi Eric,

Thanks for that info - makes me feel a bit less nervous about the task.

We're already using some of the NXP-sourced CMSIS routines for the LPC1788 so much of it should (hopefully) be pretty simple to port the existing supported peripherals over from the LPC1768.

I'd be glad of the help - to me it's a matter of when it gets done (rather than if) but it would be great to be able to feed it back into the wider mbed community.

Jez

Very minor update, just waiting for a couple of these boards to ship from China.

Great - all we need now is some hints from the mbed guys on how best to tackle this (so that we can make it as re-usable as we can). I'm hoping that either the release of the HDK or some form of porting guide will be available to get us moving in the right direction.

Hopefully Simon can give us some kind of timescale for this?

Jez

A good starting point for the device specific C-code that is required is probably that of the other mbed devices: http://mbed.org/handbook/mbed-SDK. Although besides that some information from mbed guys would indeed also be required.

Devices have arrived :)

Simon / Jez, send me a private message with where to post these CORE modules.

Simon, if you don't need one as you guys can get one through the business, that'd be cool, in which case I'll post it to Erik instead :)

Hi Jason,

That was a pretty quick delivery.

PM sent.

Simon - do you have any idea when you might be able to give us some guidance for starting the port?

Cheers,

Jez

I have just finished writing a first document about how to port the mbed SDK.

Let me know if you need additional information.

Cheers, Emilio

Hi Jez,

"88" core module is now on its way to you, should be there tomorrow before 1pm so you've got something to tinker with over the weekend ;)

Emilio / Simon, please confirm if you want me to send you guys one as well.

Kind regards, Jason

Hi Jason

Great - I will let you know when I've got it.

I'm in the process of going through the porting info from Emilio so hope it all goes smoothly.

Cheers

Jez

Hi Jason,

It's arrived - quite surprised how compact it is (given the size of the 208 pin LQFP package for the processor itself).

I'll see how far I can get following the porting guide (probably comes down to how easy it is to directly use the NXP CMSIS code for the LPC177x_8x from the lpcware.com website...)

Cheers,

Jez

Hi Jez,

Glad it got there safe, the main SDK came with a DVD which I've dumped on Dropbox, the RAR file does indeed have the CMSIS implementation ;)

Documentation, schematics etc (browsable folder)

Example code with CMSIS (163MB RAR file)

Hopefully this'll help :)

Hi Jez, any luck? :)

Erik, happy to post you out one of these modules if it'll help speed up the process. Drop me a PM with your address.

(Secretly, I'm struggling to port my C++ libs to C, hehe)

Hi Jason,

I'm making some (slow) progress with it - it took me ages to get the LPC1768 example rebuilding (with IAR in my case) as I didn't clone the mbed code from GitHub - d'oh!

I've got most of the core files for the LPC1788 in place & am just trying to finish off the last few changes to this before I try to get the simple test cases running.

I'll post an update as soon as I have some simple GPIO code for testing if that would be useful?

Cheers,

Jez

Hi Jez,

Sure, will assist how (when) I can, I've got my "88" hooked up at home with uVision and remote desktop access, so I can occasionally (i.e. lunchbreaks) run tests if needs be.

Kind regards, Jason

PM send to Jason :)

Btw slightly related question, I haven't used an offline compiler yet for ARM's, which one is the best choice if I don't want to pay a small fortune for licenses? Some googling showed me that Code Red LPCXpresso edition has highest code limit for a free version, but I don't know if it is really handy to use the compiler you both aren't using.

Hi Jason / Erik,

I've got a full seat of IAR (unlimited binary size) & the LPCXpresso Code Red suite (which has now been bought out by NXP) which I think gives up to 128k code size.

I've also got the ARM GCC build down to try...

I'm most familiar with the IAR tool-chain but could try & use some of the others if that will be better overall?

Maybe we'd do best to each add in the support for a different offline tool-chain in the longer-term but we might be best to focus on just one until we're got the basics working in that one.

So, what's the consensus? Does Simon have a preference too?

Cheers,

Jez

Hi all, just a small note: the only toolchain dependent code is the "startup" code and the "linker script", that are usually provided by the silicon, or tool vendor.

All the actual peripheral drivers are toolchain independent. You should be able to collaborate on the same code using different toolchains.

Cheers, Emilio