Since I had some problems gettings USB CDC working I decided to try using NXP's nxpUSBlib instead of the more simple examples that I only got almost working. But I ran into a couple of problems...
The first problem was getting the thing compiling for the LPC1347. The most recent version (0.97) does support the LPC1347 but not quite.
Having downloaded the archive and imported everything into Code Red LPCXpresso IDE as per the readme, I tried to configure the BSP (development board), CDL (CMSIS and device) and nxpUSBlib projects for the LPC1347 MCU. No problems.
But when I tried to select the LPC1347 for the Example_VirtualSerialDevice project it turned out that there was no such build configuration. There is a LPC13Uxx configuration for the Example_MassStorageDevice, however.
Success! More or less, anyway.
Using the nxpUSBlib (having made a few modifications – I'll do a post on that soon) I've managed to get USB CDC working and I got the GSM initialization and SMS receiving working.
At the moment, on receiving an SMS, the system will reply to the sender with the current GPS status regardless of the contents of the SMS.
(The GPS has no fix because it is on my workbench with no satellites in view.)
Power supply considerations
But: I need to do some careful design of the power supply. The GSM module is extremely power hungry. Especially when registering on the network or doing any other network related tasks – like sending or receiving SMSes. And the battery I'm currently using can not supply enough power for both the GSM module and (through a linear 3.3 V voltage regulator) the MCU and GPS module.
So I'll have to get a beefier battery (this 2000 mAh one) or this 6000 mAh one) and also add a low ESR capacitor (as recommended in the GSM module datasheet).
And I'll also add P-channel MOSFETs as high-side switches for the GSM and GPS modules in order to be able to switch power on and off to these modules.
At the moment I run the prototype off two separate power supplies: the 3.7 V LiPo battery directly connected to the GSM module and a 9 V battery supplying the MCU and GPS module through a 3.3 V LDO voltage regulator.
I’ve made quite a bit of headway with the firmware for the GPS Tracker project but there are still some problems – mainly with the command parser and the USB CDC interface.
So I decided I needed some way of debugging the firmware. After looking at several options (they have to run on Mac OS X), I decided to get a LPC1347-based LPCXpresso.
The LPCXpresso consists of two parts:
- An LPC MCU with a minimal amount of support components: crystal, capacitors, an LED and a mini-USB socket with the required resistors and PNP transistor.
- The “LPC-Link” which is a programmer and JTAG debugger which connects to the computer by USB. The LPC Link can actually be severed from the MCU part of the board and will then work as a normal JTAG debugger which can be connected to MCUs (LPCXpresso or otherwise) using a 10-pin connector.
The LPCXpresso also comes with a free version of Code Red’s Eclipse-based IDE with built-in/preconfigured support for the GNU tool chain and standard C libraries and debugging views for inspecting memory and peripherals and whatnot.
I prefer the LPCXpresso to the mbed because the MCU board contains no extra components (compared to what I will use on my own boards) and all code is standard C and CMSIS libraries (so no proprietary firmware environment and libraries) – and still I have the ability to debug code and inspect memory at will.
LPC11U24 + LPC1343 –> LPC1347
The LPCXpresso is available with a number of different LPC MCUs. I chose the LPC1347-based one.
Basically, the LPC1347 is a newer version of the LPC1343 and it has the same GPIO structure as the LPC11Uxx devices and the same USB ROM drivers and it now has EEPROM as well. Read this blog entry on microBuilder.eu for a comparison between the LPC1343 and the LPC1347.
I have decided to focus on only one ARM MCU instead of both the LPC11U24 and the LPC1343 – and that will be the LPC1347 (for now at least). Yes, it has a slightly higher power consumption than the LPC11Uxx but on the other hand it is faster and has a Cortex M3 core instead of a Cortex M0 core.
So the plan is:
- Make the necessary changes to compile the current firmware code for an LPC1347 (which shouldn’t be too much of a hassle since peripherals for the LPC11U24 and the LPC1347 are pretty much the same) in the LPCXpresso IDE (removing the current linker script and CMSIS files).
- Rebuild the breadboard prototype using the LPCXpresso.
- Debug, find the problems and fix them…
For the GPS Tracker project I’ve been working on – struggling with, actually – getting all the communications subsystems working. I need to use UART for communication with the GSM module, soft UART (since the LPC11U24 has only one hardware UART port) for the GPS module and USB CDC for command and debugging.
And apart from the occasional programming blunders (like forgetting to increase a pointer when iterating elements in an array) I’ve had lots and lots of weird problems. But I finally got UART and soft UART working together and then I took a really long, hard look at the example USB CDC code I’ve been working with.
And it turned out that I needed to change a couple of things:
- The linker script (which should be for an LPC11U24 device) specified a RAM size of only 4 KB. This has been fixed to specify an SRAM size of 6 KB.
- The USB interface was initialized with a memory buffer at what was, in effect, an arbitrary place in the SRAM memory. The original code used
usb_param.mem_base = 0x10001000and
usb_param.mem_size = 0x1000.
For an LPC11U24, location 0x10001000 is at two thirds up in the SRAM area (which is from 0x1000000 to 0x10001800).
This has now been changed to use
usb_param.mem_base = 0x20004800and
usb_param.mem_size = 0x0800pointing to the top of the USB RAM area with a size of 2 KB (which is the size of the USB RAM).
USB_CDC_send()function calls the
WriteEPdirectly. This has been changed to copy data into a serial fifo buffer and calling
VCOM_bulk_in_hdlr()function when the USB host requests data. And the max packet size is also observed now.
And with these changes in place I was rewarded with the following session on the USB CDC terminal connection:
sys test OK - Response from SYS TEST sys version OK - b155 on 2012-09-02 13:34:17 +0200, git 31db1bb904695fc5347a136dbf2c819520162099 gps status OK - GPS status: 1, sats: 6/12, time: 121246.854, lat: 5538.7522N, lng: 01233.1385E
Next steps are getting the ADC working for monitoring the battery level and implementing the interface for the GSM module.
To continue my GSM-GPS Tracker project, here is an overview of the system and the components it comprises:
The firmware components can be divided into peripheral drivers and core functionality.
The project is hosted on Github and all the driver code along with linker script, startup code, CMSIS files and Makefile has been moved into a Git submodule (the root of all evil, I know, but in this case it actually made sense) so I can reuse that in my other LPC projects. The submodule is also on Github.
- ADC for battery voltage monitoring
- EEPROM for storing/reading settings (already working)
- UART for GSM module communications (already working)
- Soft UART for GPS module comms since the LPC11U24 only has one hardware UART (already working)
- USB CDC for local programming and debugging (already working)
- Command parser for commands received by SMS or USB CDC
- NMEA parser to extract coordinates and timestamps from GPS module output
- SMS receive/reply GSM module interfacing
- Position logging storing current and the X last known positions with timestamps
It’s about time for a new project and I’ve decided to dust off an old project that I never really got started: a GPS tracker with a GSM/GPRS phone module.
Sure, there are plenty of GSM enabled GPS trackers available – both comercially (like this one) and as hobby projects (this one for example) but that doesn't mean that I can’t 1) learn a lot from making one myself, 2) have fun while doing it and 3) make something better than what is out there…
So the initial high-level requirements (aka “what’s it gonna do”) are:
- Get current position from GPS module.
- Accept commands as SMS messages from a GSM module.
- Send position info back as SMS.
- Continuously send position info to a webserver.
And my initial design considerations (aka “keep this in mind when designing the thing”) are:
Everything must be run off a 3.7 V LiPo battery. So think about power consumption and battery capacity.
The LiPo will be charged with a mini-USB cable.
Think about the size and mounting of GPS and GSM modules as well as antennas for GPS/GSM.
We’ll also need access to a USB socket for charging.
Also, the LiPo battery needs to fit in the enclosure.
The components I have in mind for this project right now is:
- MCU: NXP LPC11U24 ARM processor. I’m thinking that is a good project to start switching from AVR to ARM.
- GPS: SUP500F GPS module since that’s what I already have in my parts box. Otherwise I would probably choose a more modern module.
- GSM: Telit GE865 on breakout board – again the reason is mainly that this is what I already have. But it’s still nice.
- LiPo charging IC: The Microchip MCP73831 looks like it fits my purposes perfectly: it is designed to charge one LiPo cell from a USB port and it has bi-directional status output.
- Status LEDs: a couple of 0805 or 1210 SMD LEDs. The exact model is not critical.
- SIM holder: a generic SMD SIM holder. Something like this.
- Battery: 1000 or 2000 mAh 1s LiPo battery. This one for example.
The next step is, of course, cobbling together a prototype. And in order to do that, I will:
- Get the GSM module working: find a suitable SIM, figure out how to send and receive SMS'es and get HTTP GET and PUT working using GPRS.
- Verify that the GPS module works.
- Create block diagrams for hardware and firmaware (i.e. identifying components and dependencies)