This is library used to control the RGB LED on the board: https://github.com/cpldcpu/light_ws2812/tree/master/light_ws2812_ARM
Got the LPC11U14 MCU, RGB LED and pushbutton soldered onto the board that myelin had soldered the other parts onto.
After eventually remembering I'd changed the demo app to work without the oscillator and that the crystal value is different to the LPCxpresso board got the board to be recognised as a generic USB device. Yay for fine pitch hand soldering that works. :)
Got the RGB LED working with the code myelin provided.
Oh, finally, found a way in LPCxpresso to avoid the debug stop on
main(): http://www.lpcware.com/content/faq/lpcxpresso/changing-initial-breakpoint :)
Wanted to get debug printing to console working and initially it didn't seem to so I thought I had to change the library the project was linked against ("Switching the selected C library") but it turns out the issue was probably that I didn't have a newline character. :/
(Although it seems like it might be unadvisable to use semihosting that enables
printf() use: http://support.code-red-tech.com/CodeRedWiki/UsingPrintf.)
For pin interrupt use, look at section "3.5.34 Pin interrupt select registers" in
So, the examples use LPCOpen APIs rather than the lower level interface described in the User Manual.
Documentation isn't immediately obvious but can be found in downloadable HTML form here (under "Documentation download link" heading): http://www.lpcware.com/content/nxpfile/lpcopen-software-development-platform-lpc11xx-packages-0
While the older v1.0 release documentation appears to be online under http://docs.lpcware.com/ the newer 2.0 release doesn't appear to be online anywhere... sigh
This claims to be some sort of documentation page http://www.lpcware.com/content/project/lpcopen-platform-nxp-lpc-microcontrollers/lpcopen-v2xx-online-documentation-and-he-1 but the 11Uxx section is listed as "To be updated" sigh again.
"The USBD library provides a USB API that is the same as the USB ROM API, but works with a static library instead. This allows examples that would normally only work with devices that have the USB ROM API to work on devices without the USB ROM API with little or no changes."
w00t! (I don't think anyone says that anymore, oh well...) Got the pushbutton on the board being detected and controlling the colour of the LED... (In the roughest way possible with a direct read of the input pin rather than using an interrupt.)
PIO1_25 as an input pin (to ground):
Chip_GPIO_SetPinDIRInput(LPC_GPIO, 1, 25);
(apparently no change from default mux is necessary) then:
Chip_GPIO_GetPinState(LPC_GPIO, 1, 25)
[Update #1: The above was gleaned from http://rancidbacon.com/lpcopen/docs/lpcopen_docs_v2_00a_11xx/mcore48__1125_2board_8c_source.html#l00146.]
In addition, there's some other system setup stuff that needs to be done for the GPIO system to function.
This includes enabling the required clock which is done by the system setup code: http://rancidbacon.com/lpcopen/docs/lpcopen_docs_v2_00a_11xx/mcore48__1125_2board__sysinit_8c_source.html#l00116
/* Enable IOCON clock */
It's likely CHIP: LPC11xx IO Control driver will be needed for further setup.
Some more notes from last night:
One thing I noted was that if I have the LED on single purplish colour it flickers "regularly" like every ~30 seconds or so.
Seems like there's whole chunks of the 11uXX docs missing, e.g. for GPIO such as
Chip_GPIO_SetPinDIRInput(). (There was some reference to this fact on the forums, also, i recall.) In this case, this might be helpful as a starting point. [Update: See "LPC11xx GPIO driver: Link in docs missed" & "Newbie questions, LPCOpen, CMSIS? What to use? what to learn?"]
A catch with using semihosted/
printf() debugging is your device won't work if it's not connected to a debugger. Which seems to be avoided by not having
printf() statements and maybe changing the version of the library you use to link against.
Got tired of not being able to link/search online version of the LPCOpen docs so uploaded them here: http://rancidbacon.com/lpcopen/docs/
As noted above, the LPC11U14 docs seem incomplete but the "Globals > Functions" section has an index which is somewhat useful (although you do have to view each letter of the index separately: http://rancidbacon.com/lpcopen/docs/lpcopen_docs_v2_00a_11xx/globals_func.html
Probably the most useful index is the "C" section (which includes the
Chip_* API functions): http://rancidbacon.com/lpcopen/docs/lpcopen_docs_v2_00a_11xx/globals_func_0x63.html#index_c
However, note that things like the
Chip_GPIO_* functions are missing. A later LPCOpen documentation release for a different chip does appear to include a more complete list (presumably there's some differences but it's a starting point): http://rancidbacon.com/lpcopen/docs/lpcopen_2_17_docs_112x/globals_func_0x63.html#index_c and http://rancidbacon.com/lpcopen/docs/lpcopen_2_17_docs_112x/group___g_p_i_o__1125.html
Also, it appears that in
lpc_chip_11uxx_lib/inc/gpio_11xx_1.h etc you can view the "docs" as they exist in the file itself.
Somewhat useful description of the LPCOpen setup and system start process:
Was contemplating making the board act as a
Here's some documentation on the USBHID protocol used:
For possible future reference:
Probably too old to be useful, but in case I look for it again:
These references were a helpful starting point for the GPIO handling (or might be useful in future for that and other functions) but were lower level (register based) than what they need to be with LPCOpen:
From "LPCxpresso 'Hello, World' and Breadboard Led Blinking"
"NXP’s recommended way of separating an application from library code is to keep the library code in a separate, reusable project."
Also, this might be useful, although not clear how it interacts with LPCOpen: CMSIS Configuration Wizard
Started a new repository (https://github.com/follower/maude-generic-hid-example) with a tidily implemented version of the changes required for it to work with the MAUDE board. (Not yet feature parity with the hacked up version. :) )
Modifying the various Device Descriptor values:
For the moment I've gone with Vendor ID 0x6666 which is supposed to be for "prototypes" (via) and a Product ID of 0x0660 'cos it looked pretty and didn't appear to be used. (Although this post suggests maybe it's only a prototype when used with a Product ID of 0x5555...)
Apparently there is a NXP USB VID PID program which "will allow users to apply for the NXP VID and get up to 3 FREE PIDs" (via "USB VID and PID, the problem and those possible solutions") which might be an option some other time.
I also considered the Vendor ID 0xF055 ("FOSS") but apparently the website that promoted that choice is down with no archive of it anywhere...
For an "actual" product OpenMoko might also be an option: http://wiki.openmoko.org/wiki/USB_Product_IDs