SparkFun Forums

[pelesl]

Hello,

I love the idea of the GPS Logger 2.4 kit. However, along with logging, I would like to be able to have more outputs on this thing, so, for example, I can connect it to a computer to see myself on a map, or a digital camera to record position information on the EXIF data. I figured if I have extra outputs it can go about its business of logging away into the SD card---in other words, during a road trip, I want this thing on 100% of the time so I have a record of where I went, but if I get lost and need to see a map or want to take a picture to document something, I don't want to buy a second GPS unit.

So there are two ways I thought of doing this. One is to buy the programmer, and change the firmware so that as the messages are logged they are also relayed to some unused serial port(s) on the microcontroller. So the question is:

1. Does this board expose any of the serial ports on the microcontroller, or does this solution require me to solder tiny wires to tiny pins?

The other option I thought of is to simply splice off the transmit lines of the GPS module itself, and run those to either another microcontroller or straight to a level converter (for TTL/RS232 depending on what I need that output for). So the question is:

2. If I just splice out from the transmit line, can I have several outputs in parallel as long as the impedances are high enough that the voltage doesn't drop too much on any single line?

[mg]

Yes, to your question 1, the board exposes a serial port, you just need to solder a header on, the output levels are TTL. Check out the Spark Fun LPC Boot Loader, for example.

That's the hardware side done. For the software side, I recommend (naturally!) my own firmware for the 2.4 (see gpslogger.blogspot.com) which supports a serial output mode, to deliver raw, nmea, kml or csv data at a configurable baud rate. I've used this successfully for real-time positioning with Microsoft Autoroute and Google Maps/Earth. It doesn't currently do both serial or file output concurrently, but would be trivial to do so.

[pelesl]

Sounds fantastic, thanks for the reply. I will order one now!

I am going to order the programmer from Sparkfun, too---this plugs directly into the board (I don't need to get the programmer connector header myself), right?

I've used AVR studio and AVR-GCC to program using the JTAG ICE MKII (this was before I found Sparkfun). From looking briefly at your docs, it seems your firmware is also in C (though it looks as though you are a Linux guy). Can you recommend a compiler/dev env that I could use with this microcontroller?

[pelesl]

Is it true that the GPS module is glued to the components? That sounds like a terrible idea. Has anyone tried to yank it off?

[pelesl]

...I am going to order the programmer from Sparkfun, too---this plugs directly into the board (I don't need to get the programmer connector header myself), right?...

Okay, I don't now what I'm doing. I see Sparkfun recommends the LPC Serial Port Boot Loader Interface. Am I to understand all I need is this and a cable to connect to my computer?

[mg]

There are a couple of steps.

Firstly, you need to mount a 6-pin female breakaway header onto the board (as by default, it isn't provided) to access the serial port. Either buy this from Spark Fun or your local electronics store (as I did).

Secondly, you need a serial interface: just buy the Spark Fun LPC Boot Loader interface. As you can see in the pictures, it has male breakaway header on it, and RS232c on the other side.

Thirdly, if you just want to download new firmware, all you need is the Philips Flash Utility to run from Windows PC.

Fourthly, if you do want to develop, then yes, you need a development environment: I'm not qualified to give a comprehensive answer, but CrossWorks CrossStudio works for me (it helps that I used several years ago for commercial work), but I use it superficially and do all of my development work under FreeBSD - so yes, I'm a UNIX guy :-).

(Aside: for embedded development (which I spent many years of doing commercially) I found the most effective approach is to do the hard work of making a hardware abstraction layer work on the microcontroller, then build an emulator for that HAL on your development host (Windows, UNIX), and from thence onwards, you can do 99% of your work on the development host [faster code/compile/test cycle times], the last 1% consists of loading your image into the microcontroller and running the self-tests.)

Finally, yes the EM-406 is double-sided-taped to the LPC, but you could probably pry it apart easily (I haven't tried). I don't think that's a big issue.

[pelesl]

Thanks for the tips. I see the holes for the headers now in the pictures.

Double-sided tape doesn't sound bad at all; I just saw in the reviews of the logger that someone said it was glued on.

I ordered everything (except the header) because I noticed the LPC Interface was the last one in stock!

[pelesl]

...
Fourthly, if you do want to develop, then yes, you need a development environment: I'm not qualified to give a comprehensive answer, but CrossWorks CrossStudio works for me (it helps that I used several years ago for commercial work), but I use it superficially and do all of my development work under FreeBSD - so yes, I'm a UNIX guy .

I got my hopes up thinking Crossworks was free, but it's not. My first exposure to microcontrollers was the Atmel AVR and I guess I got too used to having AVR studio for free. I guess it's about time I relearn about makefiles and such---can you tell me which tools you use in UNIX?

(Aside: for embedded development (which I spent many years of doing commercially) I found the most effective approach is to do the hard work of making a hardware abstraction layer work on the microcontroller, then build an emulator for that HAL on your development host (Windows, UNIX), and from thence onwards, you can do 99% of your work on the development host [faster code/compile/test cycle times], the last 1% consists of loading your image into the microcontroller and running the self-tests.)...

Here's where the truth comes out: what's a hardware abstraction layer? What kind of tools are there for doing the emulation? The simple examples in AVR studio show things like code which changes a pin value and then you can go in some window and look to make sure the pin value is in fact changed, but if you're working with something like the GPS Logger, which has a component sending data serially to the controller---do these emulation tools allow you to generate fake streams to send into the emulated ports?

[mg]

Yep, you need to buy a license for Crossworks (although you can trial it for 30 days if you just want to do a quick once off change). The personal license, which I use, is affordable (IMHO), but restrict your end-use of the binaries. I'll probably migrate everything to UNIX at some stage, just haven't needed to for now. Under UNIX, I use standard make/gcc43/splint plus all your usual build glue - perl, sh, sed, etc :-).

Getting off topic ... you can emulate in all sorts of ways (e.g. since access to the micro is with mem read/writes, you could run another thread/process and monitor those mem locations and respond with the desired values). In my case with a HAL, different source code links in for real or emulated cases, e.g.

Real hardware:

Code: Select all

void lpc21XX_rtc_enable (void)
{
        PCONP |= PCONP_PCRTC;

        CCR &= (unsigned long) ~CCR_CLKEN;
        YEAR = (unsigned long) 1980;
        MONTH = (unsigned long) 1;
        DOM = (unsigned long) 1;
        HOUR = (unsigned long) 0;
        MIN = (unsigned long) 0;
        SEC = (unsigned long) 0;
        CCR = (unsigned long) (0x10|CCR_CLKEN); /* CLKSRC=1 (use the pre-scalar) */
}

void lpc21XX_rtc_disable (void)
{
        CCR &= (unsigned long) ~CCR_CLKEN;
        PCONP &= ~PCONP_PCRTC;
}

Emulated hardware:

Code: Select all

/*@null@*/ /*@shared@*/ static emu_timer_t* emu_timer_create (emu_callback_t callback, long secs, boolean re
peat)
{
        /*@only@*/ emu_timer_t * ctx = (emu_timer_t *) malloc (sizeof (*ctx));
        assert (ctx != NULL);
        assert (callback != NULL);
        ctx->callback = callback;
        ctx->secs = secs;
        ctx->repeat = repeat;
        ctx->x_rsecs = 0;
        ctx->x_next = NULL;
        emu_timer_enqueue (ctx, FALSE);
        return ctx;
}

...

void lpc21XX_rtc_enable (void)
{
        assert (!lpc21XX_rtc_enabled_flag);
        lpc21XX_rtc_enabled_flag = TRUE;

/*@-evalorderuncon@*/
        lpc21XX_rtc_timectx = emu_timer_create (emu_lpc21XX_rtc_tick, (signed long) 1, TRUE);
/*@=evalorderuncon@*/
        assert (lpc21XX_rtc_timectx != NULL);
}

void lpc21XX_rtc_disable (void)
{
        assert (lpc21XX_rtc_enabled_flag);
        lpc21XX_rtc_enabled_flag = FALSE;

        assert (lpc21XX_rtc_timectx != NULL);
        emu_timer_destroy (lpc21XX_rtc_timectx);
}