Hi J,
As I'm more used to using STRINGs than your other suggestion, I'll carry on that way.

Once I follow the earlier suggestion in #8 9 to end the sentence at 'E' then as you suggest lower all of the STRINGS to the longest necessary, I'm sure this will work.
Thanks, C.

I looked at the program in msg #1 and it has about 40 string variables.
I think you can shorten the max length of the string to 30 from the original 70 and free about 1600 bytes of RAM.

 

Instead of using strings, consider using byte arrays. That allows you to make each one a specific length (ie shorter). Byte arrays can still store ascii character or string variables, it is just they are written slightly differently, and you have to keep track of position/count. The data in the byte array is identical to the data in a string....
For all my serial I/O and interpretation in Oshonsoft, I use byte arrays, never strings...

 

Instead of using strings, consider using byte arrays. That allows you to make each one a specific length (ie shorter). Byte arrays can still store ascii character or string variables, it is just they are written slightly differently, and you have to keep track of position/count. The data in the byte array is identical to the data in a string....
For all my serial I/O and interpretation in Oshonsoft, I use byte arrays, never strings...

Considering that C has already mentioned that he can't get his head around array's, this will be difficult.
What's needed is a invisible interface to store the strings so it doesn't disrupt his thinking... I use an external EEPROM to store all my text and each line is 16 chars ( size of screen ).. Because they are NOT in memory, I use one buffer and refill as necessary ( as most programmers do ) This is why I propose that a simple interface to store and refill the string, would be easier for C to get his head around..

 

Hi,
'I' is correct regarding me learning new programming skills such as ARRAYs. It would most likely lead to lots of time and your efforts, while I loose track of how the existing program works. Having said that here is a program in my files from 2008, most likely written by EG: attached

For now I'll plod on pushing my square wheel, which, by the way, is getting rounder.

I changed the suggested 'Stop at 'E' to 'W' as I'm west of the Greanwhich date line. (I can see that this is unsatisfactory, and will re visit it later)

The program seems to be working and the STRINGS are being cleared but not in the box shown here:attached

This doesn't allow further sentences to be entered?
C.

 

What is the purpose for clearing the strings?

 

What is the purpose for clearing the strings?

Hi J,
https://forum.allaboutcircuits.com/threads/2x-strings-in-oshonsoft.157874/#post-1369872 #2

C.

 

Hi J,
https://forum.allaboutcircuits.com/threads/2x-strings-in-oshonsoft.157874/#post-1369872 #2

C.

Can't you just overwrite the strings and put a LF to mark the end of string?

 

Can't you just overwrite the strings and put a LF to mark the end of string?

Hi J,
I think it is because, when a short STRING overwrites a long one, some of the end of the old one is left, which I think may cause problems. Not sure.

When the STRINGS are PARSED using the LF ending, sometimes they are 70 long, doesn't this mean the STRING_MAX_LENGTH needs to be 70?
C

 

Hi,
I changed STRING_MAX_LENGTH to 50

I added ,W to the end of the REMOTE test MACRO.

It appears to be working, so now GPS, BMP280, AK8930C and HC-12 working. Perhaps the uncleared Simulator box, may be a problem with the simulator only?

I had the 5110 LCD working, but at the moment, it isn't, so I'll look at this again next.
C.

 

Hi J,
I think it is because, when a short STRING overwrites a long one, some of the end of the old one is left, which I think may cause problems. Not sure.

When the STRINGS are PARSED using the LF ending, sometimes they are 70 long, doesn't this mean the STRING_MAX_LENGTH needs to be 70?
C

It was said earlier, that parsing can be stopped at "W" character.

 

hi C,
You may recall that you were using the str1 for many different messages of varying lengths also you were testing particular characters in the string in order to determine the message source, you had persistent problems.!!

What is so difficult about a code line of Str1=""

Much Ado about Nothing, as Shakespeare would say.

E

 

It was said earlier, that parsing can be stopped at "W" character.

Hi J,
True, and and as already mentioned, this is what I'm doing.

When using the Oshonsoft simulator I have to put in a full sentence as #44, and I commented that the unclearing box, could be a simulator problem only.
C.

 

hi C,
You may recall that you were using the str1 for many different messages of varying lengths also you were testing particular characters in the string in order to determine the message source, you had persistent problems.!!

What is so difficult about a code line of Str1=""

Much Ado about Nothing, as Shakespeare would say.

E

Hi C,
Yes, I recall Str1 for many different messages then we added Str2, which works.

What is so difficult about a code line of Str1="" Here I am

Str1="" Gives 'not not a valid Byte constant error'
Here is the DIM: 'Dim str1(50) As Byte'

I used this to clear the STRINGs::
'For x = 0 To 79 'Clear STRING1
'str1(x) = 0
'Next x

C.

 

hi C,
Can you confirm that all the incoming data messages are in ASCII text, on this latest hardware build.?
E

 

Hi C,
Yes, I recall Str1 for many different messages then we added Str2, which works.

What is so difficult about a code line of Str1="" Here I am

Str1="" Gives 'not not a valid Byte constant error'
Here is the DIM: 'Dim str1(50) As Byte'

I used this to clear the STRINGs::
'For x = 0 To 79 'Clear STRING1
'str1(x) = 0
'Next x

C.

This may be too obvious, but you say that now your strings are 50 bytes long (and were 70 bytes long previously). THEN WHY ARE YOU WRITING TO EIGHTY MEMORY LOCATIONS? Take a look st the code you posted to clear the STRINGs.

 

This may be too obvious, but you say that now your strings are 50 bytes long (and were 70 bytes long previously). THEN WHY ARE YOU WRITING TO EIGHTY MEMORY LOCATIONS? Take a look st the code you posted to clear the STRINGs.

Hi D,
For me nothing's obvious.
How I program, is to change one line or connected lines, then test it, then change other 'obvious' lines, moving hopefully forward. I've seen the 80 locations, you mention, and will change them soon.
Thanks, C.

 

hi C,
Can you confirm that all the incoming data messages are in ASCII text, on this latest hardware build.?
E

Hi E,
I'm pretty sure you mean this: attached.
C.

 

While your at it, instead of changing one line, I’d look through the entire program to see if there’s any other place where you assume a particular size. That is, you might find “80” in other lines of code that needs changing.

 

hi C,
I understood we are only using the $GPGGA msg.??
$GPGGA,162254.00,3723.02837,N,12159.39853,W,1,03,2.36,525.6,M,-25.6,M,,*65

E

 

While your at it, instead of changing one line, I’d look through the entire program to see if there’s any other place where you assume a particular size. That is, you might find “80” in other lines of code that needs changing.

Hi D,
Will do.
C