On that note I decided to go for the Code Red suit first, since it supports a decent code size. Exporting hello-world to Code Red went fine, and immediatly worked. Dragging created bin file to my LPC1768 worked perfectly, so couldnt be much easier than that :)

However then I tried geting the Github mbed library, and compiling the hello world program with that one. Apparantly then you need to do something else, since it mainly gives me many compilation errors. I deleted all unrelated directories (other compilers and targets), and then it complains it can't find LPC17xx.h, even though it is there and in its search path. Thats why I liked mbed so much, no crap with stupid compilers :P

So guess that is a bit more work to get going on. Maybe anyone happened to have done that before?

Edit: Well got it a bit further with manual includes, but it looks mainly like I am burrying myself deeper :P

Be sure to correctly configure the code_red path in your "private_settings.py", ie:

GCC_CR_PATH = "C:/code_red/RedSuite_4.2.0_349/redsuite/Tools/bin"

To build the mbed library for the LPC7168 with the code_red toolchain:

python workspace_tools/build.py -m LPC1768 -t GCC_CR

To build a test project linking to the mbed library:

python workspace_tools/make.py -m LPC1768 -t GCC_CR -p 0

Could you report to us the compilation errors you are getting from the above build commands?

Cheers, Emilio

That python command already fails for me:

>>> BUILD LIBRARY CMSIS (LPC1768, GCC_CR)
Copy: cmsis.h
Copy: cmsis_nvic.h
Copy: core_cm3.h
Copy: core_cmFunc.h
Copy: core_cmInstr.h
Copy: LPC17xx.h
Copy: system_LPC17xx.h
Copy: LPC1768.ld
Compile: cmsis_nvic.c
[Error 2] The system cannot find the file specified


Completed in: (0.03)s


Build failures:
  * GCC_CR::LPC1768

Edit: And make command:

Traceback (most recent call last):
  File "workspace_tools/make.py", line 9, in <module>
    from serial import Serial
ImportError: No module named serial

When I disable serial import (guess some kind of package I am missing), I get the same error as the build.py has, only now with main.cpp

This is regardless of what I put in private_settings.py, I use there:

GCC_CR_PATH = "D:\ProgramFiles\LPCXpresso_5.2.4_2122\lpcxpresso\tools\bin"

Or won't it work with lpcxpresso red suite? At which point I am back at looking for compiler :(

The file that the build system cannot find is very likely your GCC executable.

Run the command with the "-v" option:

> python workspace_tools\build.py -t GCC_CR -m LPC1768 -v

>>> BUILD LIBRARY CMSIS (LPC1768, GCC_CR)
Copy: cmsis.h
Copy: cmsis_nvic.h
Copy: core_cm3.h
Copy: core_cmFunc.h
Copy: core_cmInstr.h
Copy: LPC17xx.h
Copy: system_LPC17xx.h
Copy: LPC1768.ld
Compile: cmsis_nvic.c
C:/code_red/RedSuite_4.2.0_349/redsuite/Tools/bin\arm-none-eabi-gcc -std=gnu99 -c -O2 -Wall -fmessage-length=0 -fno-exce
ptions -fno-builtin -ffunction-sections -fdata-sections -MMD -save-temps -mcpu=cortex-m3 -mthumb -D__NEWLIB__ -D__CODE_R
ED -D__USE_CMSIS -DCPP_USE_HEAP -DTARGET_LPC1768 -DTOOLCHAIN_GCC_CR -D__CORTEX_M3 -DARM_MATH_CM3 -IC:\Users\emimon01\mbe
d\libraries\mbed\vendor\NXP\cmsis -IC:\Users\emimon01\mbed\libraries\mbed\vendor\NXP\cmsis\LPC1768 -IC:\Users\emimon01\m
bed\libraries\mbed\vendor\NXP\cmsis\LPC1768\GCC_CR -o C:/Users/emimon01/mbed/build\mbed\.temp\LPC1768\GCC_CR\cmsis_nvic.
o C:\Users\emimon01\mbed\libraries\mbed\vendor\NXP\cmsis\LPC1768\cmsis_nvic.c

and verify that the path to your GCC is correct, in my example:

> C:/code_red/RedSuite_4.2.0_349/redsuite/Tools/bin\arm-none-eabi-gcc --version
arm-none-eabi-gcc (Red Suite 2010Q4 by Code Red) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If the path is not correct, modify your "private_settings.py" accordingly:

GCC_CR_PATH = "C:/code_red/RedSuite_4.2.0_349/redsuite/Tools/bin"

HTH, Emilio

Okay I found my issue, thanks to your debug option:

In the path in private_settings.py you have to use forward slashes. I was doing the lazy option, navigate to that folder, copy it, and paste it. However windows uses backslashes then, and apparantly \t and \b were parsed as something else!

Edit: Issues gone, there was a .temp directory in the generated mbed library (might have been leftover of previous attempts at generating it), which had apparently some stuff that shouldnt be there. After deleting .temp that was gone.

But while this does now work, isn't it possible to just import the non-compiled source code and use that? Since that is what you want to modify the code easily. With a bit looking around I guess not?

I decided to bite the bullet last night too. I've gotten toolchain definitions with memory assignments tentatively fleshed out along with CMSIS and CAPI mostly complete. Just doing the pin assignments now for the HY-LPC1788-CORE board now.

When I've done this and tested it, I'll whack it onto GitHub under a new repo (unless the mbed guys want me to try pushing back up to the main mbedmicro repo or something, I'll let you guys confirm).

Regardless, there's been a couple of migraines and lots of pouring over PDFs and source code at this point, hoping it all works out :)

Do I understand correctly then that you effectively finished the port already then? (Minus testing). If so, nice job. And then I guess you won't be needing more help?

I think I'm about 50% of the way through the prepwork, no idea what work is required beyond this point. Here's a quick taster though;

Okay, so today is the day (well, lunchtime and evening), I've just tried it quickly before I start work however and I had a missing serial module warning (which I installed from the pyserial 2.6 package page).

I then tried running it again and it complains about a missing main.cpp, neither the mbed SDK porting page nor the mbed tools page clearly state how this file is supposed to come into existence (and I've re-read both pages thrice), it certainly doesn't appear to be there from git nor does it get generated when I run the following command;

python workspace_tools\make.py -m LPC1788 -t ARM -s COM3 -d E:\ -p 0

(Please note, the LPC1788, at least in the HY-LPC1788-CORE form, does NOT provide UMS like the mbed LPC1768, but I do have the latter hooked up, I was going to let it output the BIN file to there, and then flash it to my "88" manually with Segger J-Flash ARM).

The error I get is as follows;

>>> BUILD PROJECT: BASIC (LPC1788, ARM)
Compile: main.cpp
[ERROR] [Error 2] The system cannot find the file specified

This relates to not being able to find the armcc compiler. I installed the GNU Tools for ARM Embedded Processors as per the mbed-tools page, however these don't seem to provide "armcc.exe".

First I thought it might be the spaces, so I created a symlink to the gcc folder, then I tried symlinking arm-eabi-none-gcc.exe to armcc.exe and started getting different errors such as;

armcc: error: unrecognized command line option '--cpu=Cortex-M3'
armcc: error: unrecognized command line option '--split_sections'
etc

I also tried another path / gcc binary to the same problems. I'm starting to think I don't have the right toolchain installed and rapidly being out of my league here. I could do with a little insight :)

To specify that you want to use the GCC toolchain provided by ARM you have to use the -t GCC_ARM option, instead of the -t ARM option that uses ARMCC.

# build the mbed library
> python workspace_tools\build.py -m LPC1768 -t GCC_ARM

# build test 0, linking to the mbed library
> python workspace_tools\make.py -m LPC1768 -t GCC_ARM -p 0

HTH, Emilio

The best thing you can do is Fork our repository and send us a Pull Request:

1. Login to github, press the "Fork" button in the mbed repository.
2. Clone your fork to your local machine and apply the changes for adding the LPC1788 target.
3. Commit and push your changes to your forked mbed repository.
4. Press the "Pull Request" button in your forked mbed repository.

Let me know if you have additional questions.

Emilio

Hi Emilio / Jason,

I've not given up on this (I'll do it anyway - if only as a learning exercise) but am still struggling to find out exactly what needs to go in some of the files...

I think I've got the CMSIS core & NXP-supplied files sorted but am still a little unsure with some of the SDK-specific files.

cmsis.h is pretty trivial

cmsis_nvic.h similarly easy

cmsis_nvic.c - how do I get the number of vectors? For the LPC1768, the NXP user manual says that the NVIC has 35 vectored interrupts but the SDK file uses 16 + 33 for NVIC_NUM_VECTORS...how do you derive these numbers?

The LPC1788 UM says it supports 40 vectored interrupts, so what should I put in for these?

The .sct file seems reasonably easy to follow but is there a naming convention we should aim to follow (especially when including the external memories)?

I think I'm nearly there but missing something obvious...

Cheers,

Jez

You just want to copy the __Vectors section of your startup_DEVICE.s at the beginning of RAM. Each DCD directive allocates one word: you can simply count them.

The startup_DEVICE.s is usually provided by the silicon vendor.

HTH, Emilio

Marvelous - that would give 16 + 41 (8 more interrupt sources on top of the 1768).

I was looking at the user manuals (1788 makes sense but the 1768 talks about 35 NVIC sources but only has vectors for the first 33 - missing out USB & CAN activity interrupts it seems).

Thanks

Jez

Yes, I think you are right. Of course, we are not enabling these interrupts, but next time we update the LPC1768 CMSIS module, we will fix "startup_LPC17xx.s".

Cheers, Emilio

Another day, another couple of baby steps taken.

I successfully compiled a binary with Emilios help (thanks mate), successfully flashed it with Segger J-Flash, but then nothing happened. I fired up a debugger thinking it may help me, but total deer in headlights moment;

I'm stretching my limits of understanding here, but it looks like its stuck in a loop very early on, so some core init is inherently borked.

At this point I thought I'd try and get it working in Keil uVision, better the devil you know, that proved even more of a hassle though. Keils binaries refused to compile the code, so I switched to the ARM-EABI-NONE- toolchain (which annoyingly reset all my programs includes) and now I'm struggling to compile / link things properly;

compiling parse_pins.cpp...
cc1plus.exe: warning: command line option '-std=gnu99' is valid for C/ObjC but not for C++ [enabled by default]
../mbed/libraries/mbed/rpc/parse_pins.cpp(62): error: expected unqualified-id before 'else'
../mbed/libraries/mbed/rpc/parse_pins.cpp(80): error: expected '}' at end of input

(the warning is safe to ignore as I specified -std=gnu99 -std=gnu++98 in the compiler parameters)

Looks like I've gotta edit these files too. Will review on my lunchbreak. Back to the grindstone for now :)

Yes, I agree. Although, we have not a chance to help you if you do not share your code.

What I would suggest you to do is:

1. Login to github, press the "Fork" button in the mbed repository.
2. Clone your fork to your local machine and apply the changes for adding the LPC1788 target.
3. Commit and push your changes to your forked mbed repository.

Cheers, Emilio

Hi Emilio,

I'm still getting a few problems...I can successfully rebuild the LPC1768 for IAR, GCC_ARM & GCC_CR tool-chains (not fought with the others much yet)...

But when I try and build my LPC177x_8x code, the IAR one is failing...the -v shows that it appears to be trying to use the IAR assembler on the GCC startup assembly file

>>> BUILD LIBRARY CMSIS (LPC177x_8x, IAR)
Copy: LPC177x_8x.icf
Assemble: startup_LPC177x_8x.s
C:/Program Files (x86)/IAR Systems/Embedded Workbench 6.50-5/arm\bin\iasmarm --cpu Cortex-M3 -o C:\Users\jeremy.cawley\Documents\Git
Hub\build\mbed\.temp\LPC177x_8x\IAR\startup_LPC177x_8x.o C:\Users\jeremy.cawley\Documents\GitHub\mbed\libraries\mbed\vendor\NXP\cmsi
s\LPC177x_8x\GCC\startup_LPC177x_8x.s

    IAR Assembler V6.50.5.4819/W32 for ARM
    Copyright 1999-2013 IAR Systems AB.

    .equ    Stack_Size, 0x00000100
-------^
"C:\Users\jeremy.cawley\Documents\GitHub\mbed\libraries\mbed\vendor\NXP\cmsis\LPC177x_8x\GCC\startup_LPC177x_8x.s",19  Error[40]: Ba
d instruction

So, why is the IAR trying to assemble the GCC assembly file? Or should I ask why the build command for the IAR tool-chain is picking up an assembly file form the GCC folder?

Bear in mind it build the LPC1768 code ok (and looks in the IAR folder for the startup assembler file in this case...)

Where have I mucked this up?

Any help is most welcome!

Jez

Hi Emilio,

I've sent the pull request, DO NOT for the love of God merge it, it's well foobared :)

Status update;

• Compiles in Keil uVision but hard faults when attempting to use wait_usec (suspect issue with timer 3)
• Compiles in mbed tools but doesn't reach main() - gets stuck in a loop after only a few instructions

Jez, if you feel brave, you can start stealing stuff from my tentative commit but there be MANY dragons mate, I've fudged 49% of it and winged 51% more ;)

Kind regards, Jason

Learning every day!

Managed to trace down what the fault is, it appears to be a "imprecise data bus error" within gpio_dir()..

This appears to be BEFORE the LPC_TIM3 (Timer3) invokation within wait_usec(), it's just this didn't manifest itself until around the time the wait was called due to buffering (although I suspect there is still an issue, at least on my end, with timer 3).

Again, I'll keep plodding / bumbling on but any advice is welcome ;)

Well, I've managed to get the CMSIS library to build under IAR now...but it's failing to build the mbed library.

Looks like I'll need to add in lts of defines for the LPC1788 in many mbed files next.

I'll try and look at some of Jason's edits next.

Hopefully between us we'll get there soon!

Jez

Jez, go for it, but keep in mind there's some serious issues with it, I've got a feeling I've somehow seriously fouled access to the pins by making too many assumptions.

Emilio and ARM team, I'm hoping you can look at this today, I've given myself until Sunday before I have to take a break from this and work on something else (porting my C++ libs to ANSI C, joy) all of next week. I'd be back on it the following week but I've got this weekend to have a play if someone can help me :)

Kind regards, Jason

Hi Jason, the past 3 days I have been out of office to attend a conference, I will have quite a backlog when I am back to the office on Monday, I should be able to provide you a bit of feedback about your changes to add support for the LPC1788 board on Tuesday.

Cheers, Emilio

Hi Jason,

I tried to get your code to rebuild on my PC (using 32k limited version of Keil v4.54) but it doesn't work for me...which I'm sure is down to some setting I have got wrong.

I've tried to specify using Keil for the offline ARM option (in my private_settings.py file) but it seems to keep trying to use a binary from c:/Program Files/ARM/armcc_4.1_791 instead...

Can you confirm what you've set in your private_settings.py & what command line you're using to rebuild please? Also, are you using a full seat of Keil or the limited size demo version?

I've got the LPC1768 to rebuild ok on my PC with IAR, GCC_ARM & GCC_CR but wanted to try and match at least some of Jason's work & get the IAR side running under that too...

For Jason's LPC1788 code I get an error (cannot open source file <rt_misc.h> when compiling sys.cpp) when compiling under IAR. Both GCC_ARM & GCC_CR give 'non-constant expression in ".if" statement'.

My own port is stuck as I can't find out why the IAR won't pick up the definition for 'SystemCoreClock' (which is in my system_LPC177x_8x.h file as

extern uint32_t SystemCoreClock;

Hmm.

I'm sure that once someone points out my silly muck-up all will progress quicker...but at present I seem to be finding lots of brick walls.

Cheers,

Jez

Ok, a bit of sleep & a few cups of coffee later...

I've now edited the settings.py file so that I can get the Keil stuff to build (for some reason the private_settings.py wasn't letting me change it to build for Keil rather than standalone & the Keil path changes weren't working either).

So I can now build Jason's LPC1788 in Keil :-)

I've removed the sys.cpp from the IAR folder & LPC1788 now builds with IAR too 8-)

I'll try & get GCC_ARM & GCC_CR building with it next.

Sadly no further on with my code though...I'm hoping to see why Jason's code locates the SystemCoreClock & mine doesn't.

Hopefully some more progress tomorrow.

Jez

We just accepted a "pull request" that adds support for the NXP LPC4088 from Embedded Artists, you can take it as an additional example: https://github.com/mbedmicro/mbed/commit/2662e105c43c93986d52713234375b7910acf297

We have now ordered a couple of "HY-LPC1788-CORE" boards, we should soon be able to try your new target support.

Cheers, Emilio

Hi Emilio / Jason

I've managed to get most of the LPC1788 port in there on the back of the LPC4088 example...though it's currently for the Embedded Artists kit (as it's easier for me to test on that at the moment).

As soon as I've done a little bit more testing I'll put an update in here - then hopefully it won't take much more work to get the port to the CORE board done...I hope!

Cheers,

Jez

Hi Jez, Jason, after the initial feedback we received from people porting the mbed SDK to new targets, we have decided to keep the code for each new target in its own completely separate directory, eliminating the shared code in the HAL implementations. In this way, we can accept more easily "pull requests" for new "experimental" targets.

Cheers, Emilio

Hi guys, just curious, it's been awhile now since Emilio's last post, has there been any other updates with the LPC1788?

Jason

Hi guys, we are also using LPC1788 when we want to use mbed we chose 4088 and compile digital out codes are work properly but when we want to use wait or serial comments system will stop working. can any one help us.