NMEAparser issue tracker

[dstroy0]

A place for ideas and problem solving.

I'm not planning on supporting AIS messages

match only the last 3 char in the talker/type of message unless the talker sends a $P, then reject it ($P are not standardized)

it needs a char pattern to use as an empty field placeholder to maintain field context, I chose "blank" as a temporary ph, the char pattern shouldn't be any NMEA 0183 reserved char, the problem with this ph is that it uses 6 bytes of memory, so a shorter one would be better.

Other than that I've been knocking up the testing framework, all the commands are open and the arguments that all of the commands accept are currently homogeneous, and they will accept any number of arguments from 0-32. I verified that we can access all of the commands in PROGMEM, and PGM space looks good with the message type Parameters reuse.

I'm going to grab some sentences and put them in PROGMEM so that we can test it.

[dstroy0]

it works, gives the user a token for each field in the sentence

[dstroy0]

The only "talker" that's accepted right now is "GP", there are many talker types, but I only defined this one since it is the most common. I should rename the struct to just "talker" so that it is more obvious what needs changing. I don't know if that's the best solution to this problem? I think probably just wildcard input.

I need to explain to users in the ino comments WHERE they need to go to do things with those fields other than display them. Separately, I need to put the parser files in a folder called "parser" and split the functions.h into .h and .cpp.

[dstroy0]

The sentence structure has changed. With the introduction of wildcards, the talker is wildcard char for any input sentence. Command strings look like: "**ALM", "**BWC" etc. so any talker should work for these messages once I fix bugs I introduced with wcc.

[dstroy0]

This is the output from the modified example, the gsa string is not representative of a real one.

Set up InputHandler...
$GPBWC,081837,blank,blank,blank,blank,blank,T,blank,M,blank,N,blank,*13
NMEA parse BWC fields
0 081837
1 blank
2 blank
3 blank
4 blank
5 blank
6 T
7 blank
8 M
9 blank
10 N
11 blank
12 *13
end NMEA parse BWC fields
$GPGSA,081837,blank,blank,blank,blank,blank,T,blank,M,blank,N,blank,*13
NMEA parse GSA fields
0 081837
1 blank
2 blank
3 blank
4 blank
5 blank
6 T
7 blank
8 M
9 blank
10 N
11 blank
12 *13
end NMEA parse GSA fields
>_test_$$ GPBWC 081837 blank blank blank blank blank T blank M blank N blank *13 
>_test_$$ GPGSA 081837 blank blank blank blank blank T blank M blank N blank *13 

[dstroy0]

The major issues are fixed, I just want to run more sentence types through it.

[dstroy0]

Something is broken... I'll figure out what tomorrow.

[dstroy0]

So it was more than a day, I've been busy. There's something breaking in addCommand, it's one of the memcpy, so I'll figure out what I'm doing wrong with it when I get the chance!

[dstroy0]

Ah, I was copying the memory address by accident instead of the contents.

[dstroy0]

It looks like the ESP does not like pointer math inside of memcpy(), that is currently causing problems.

[dstroy0]

I'm offloading it to a local ptr where applicable.

[dstroy0]

It's working tentatively on ESP again. I need to recheck memory management.

[dstroy0]

On the teensy as well, it had something to do with pointer size.

[dstroy0]

Something is very weird with the ESP and new delete[], malloc, calloc, and free all work fine. I was having problems trying to delete[] allocated memory for splitting the zero-delim command, it was corrupting the heap. switching to calloc and free fixed the problem for ESP and teensy cores.

[2bndy5]

I think free might be more applicable than a simple delete[]

Oh sorry I misread that comment. Looks like you already are using free

[dstroy0]

Yes, I just wanted to share the weirdness. It seems like C functions are more portable than the new and delete[] operators as you suspected.

[dstroy0]

Now I just need to fix whatever regression is happening on avr.

[dstroy0]

I was incorrectly sizing memory allocations with calloc, that was the problem.

[dstroy0]

the latest commit fixes #50

output is back to normal

[dstroy0]

I'm using the example to test for leaks.

[dstroy0]

freeRam has its own issue; I know there's a function builtin to the ESP to get free heap, I need to look for the same for the other platforms. I'm testing on avr and the ram is not decreasing over 1 million iterations so memory management on that platform looks ok.