PICAXE basic lacks and Array handling. Alongside this is a lack of Text string handling.
Some time back I converted an AXE133 to recieve and 'parse' sentences received from a GPS receiver chip. The problem with this was that, though I could use SERIN to identify and start receiving the text,I had to use a very large number of @bptrinc one after another in a very very long line (serin RX,baud,("$GPRMC,"),@bptrinc,@bptrinc,@bptrinc,@bptrinc,.,,,,,,,,,,). There was no way I could incorporate something like a FOR loop to be linked to the SERIN. Once all the text bytes were in the scratchpad space, I could the parse it into dedicated areas of the scratchpad. That is having worked out offsets and specific text lengths I could do my own equivalent of string handling by specifying start index and string length for a loop within a subroutine, I could manipulate it.
Looking back at it, the last thing you could call it is 'elegant code'.
But there is one small PIC Basic change the would help. That small change would be an ability to specify repeated @bptrinc something like @bprinc[70] so as to claim and use 70 bytes. e.g.serin RX,baud,("$GPRMC,"),@bptr[70].
Previously I had to extract parameters from within the full GPS sentence, write them back into known space with the first byte being the text length of the parameter.. Basically I wrote a simplistic STRING handler in PICBASIC where I still had to know where each string started or preserve it in a reserved byte variable.
Despite my inelegant code I was able to modify an AXE133 to display GPS position, date and time also to update the time zone. I also manged to get the AXE133 to display range and bearing from that of the AXE133 to a fixed position like Greenwich.
So without true string handling; there are ways, but they would be a lot easier and elegant if we could read and write specific sequences of bytes to and from the scratch pad.
Some time back I converted an AXE133 to recieve and 'parse' sentences received from a GPS receiver chip. The problem with this was that, though I could use SERIN to identify and start receiving the text,I had to use a very large number of @bptrinc one after another in a very very long line (serin RX,baud,("$GPRMC,"),@bptrinc,@bptrinc,@bptrinc,@bptrinc,.,,,,,,,,,,). There was no way I could incorporate something like a FOR loop to be linked to the SERIN. Once all the text bytes were in the scratchpad space, I could the parse it into dedicated areas of the scratchpad. That is having worked out offsets and specific text lengths I could do my own equivalent of string handling by specifying start index and string length for a loop within a subroutine, I could manipulate it.
Looking back at it, the last thing you could call it is 'elegant code'.
But there is one small PIC Basic change the would help. That small change would be an ability to specify repeated @bptrinc something like @bprinc[70] so as to claim and use 70 bytes. e.g.serin RX,baud,("$GPRMC,"),@bptr[70].
Previously I had to extract parameters from within the full GPS sentence, write them back into known space with the first byte being the text length of the parameter.. Basically I wrote a simplistic STRING handler in PICBASIC where I still had to know where each string started or preserve it in a reserved byte variable.
Despite my inelegant code I was able to modify an AXE133 to display GPS position, date and time also to update the time zone. I also manged to get the AXE133 to display range and bearing from that of the AXE133 to a fixed position like Greenwich.
So without true string handling; there are ways, but they would be a lot easier and elegant if we could read and write specific sequences of bytes to and from the scratch pad.
