Hi P,
I wish I could learn ASM, but it's impossible for me. I was actually looking at ASM this morning, to see where something is being stored, but even though I found the answer, I couldn't do anything with it. I just carried on and successfully succeeded in what I was trying to do.
I'm ok at machining and mechanical stuff.
C.

The skills are learned, just like everything else we do, In 1962, at the age of 14, learning assembly language (FAP) was way easier than learning French, and it was the price of admission to a major university computing center. To say I was motivated would be an understatement. You've had your first brush with motivation. I suspect it will not be the last.

https://www.frobenius.com/fap.htm

 

You cannot easily migrate from Oshonsoft BASIC to C, much less migrate to ASM.
You have invested a lot of time and effort in BASIC already.
Your solution at this stage is to learn the intricacies of Oshonsoft BASIC and how each of the independent modules are structured and integrated into your application.

In each module you will find ways to economize on usage of variable space.
Have you looked at where strings are being allocated and used in each module?

 

The skills are learned, just like everything else we do, In 1962, at the age of 14, learning assembly language (FAP) was way easier than learning French, and it was the price of admission to a major university computing center. To say I was motivated would be an understatement. You've had your first brush with motivation. I suspect it will not be the last.

https://www.frobenius.com/fap.htm

Hi P,
True! I have preferred to spread my learning to different subjects, instead of honing up few to a better degree.
Banjo, Morse, French, Art, Electronics/ PCB making, Planning/Building, Navigation. Not much good at any of them, but I'm never bored.
C.

 

You cannot easily migrate from Oshonsoft BASIC to C, much less migrate to ASM.
You have invested a lot of time and effort in BASIC already.
Your solution at this stage is to learn the intricacies of Oshonsoft BASIC and how each of the independent modules are structured and integrated into your application.

In each module you will find ways to economize on usage of variable space.
Have you looked at where strings are being allocated and used in each module?

Hi C,
True, I have spent lots of time and effort with BASIC, and have loads of Libraries of code modules, thanks to others. E,g, COMMA separation as suggested by E, which will take me a week or two maybe less to figure out, but I'm fairly confident I can.
At the moment looking where STRINGS are allocated, would be too much of a stretch, but when I get a clear time, I will have a look.
C.

 

Hi Camerart…. I have told you before... When using strings you only need one or two...
I have recommended you try another basic.... There are far to many problems in Oshonsoft… Even Great Cow Basic will produce tighter code and its free.. However for the tiny expense of Swordfish you could port your code over very easily.. When Iooked at your code, several months since, I could have used two / three strings... But I haven't subscribed to Oshonsoft for years and he has dropped my license... I don't really want to buy the rubbish he's peddling today ( I used to like his compiler ) So I couldn't even re-write it for you..

Download the free version of swordfish and just try it..

 

Hi Camerart…. I have told you before... When using strings you only need one or two...
I have recommended you try another basic.... There are far to many problems in Oshonsoft… Even Great Cow Basic will produce tighter code and its free.. However for the tiny expense of Swordfish you could port your code over very easily.. When Iooked at your code, several months since, I could have used two / three strings... But I haven't subscribed to Oshonsoft for years and he has dropped my license... I don't really want to buy the rubbish he's peddling today ( I used to like his compiler ) So I couldn't even re-write it for you..

Download the free version of swordfish and just try it..

Hi I,
I've lost count of the times, someone has said "I've told you before". I can only work with the memory I've been given, which get's me by, but doesn't shine. Each time I open a program, things are never clear, I have learnt to keep trying different ideas, till either, one works, or in the last resort, I come on a forum for help. I have other skills, that flow like yours do with programming.
I've tried Swordfish, Great Cow, Picax, 'C; Arduino, ASM etc, all suggested in the past, but it's a waste of time, it's Oshonsoft or pack it all in, I'm afraid.
As mentioned, I rely on the Oshonsoft simulator. .
Cheers, C.

 

I have learnt to keep trying different ideas, till either, one works, or in the last resort, I come on a forum for help.
Cheers, C.

I like the term, stochastic. I sometimes feel my coding is that way too. Given enough time and enough tries, you will get the right answer. The term sounds more sophisticated than it is. Not meant critically.

John

 

Re-write your code in .asm...

Or simply make your code more efficient.

 

Or simply make your code more efficient.

Can you help him?

 

I know zip about Oshonsoft or your code but..

It looks like all of your variables are 'Global' i.e. declared at the top of the program and not inside a subroutine. When you do that, you dedicate memory exclusively to those variables, even if those variables are used infrequently. Eventually you run out of memory. Variables that are 'Local' i.e. declared inside a subroutine are used by the subroutine then released for re-use.

If you can, reserve as many variables in subroutines as possible so that they can be reused by the system. But keep in mind that once you return from the subroutine, that variable is no longer valid (because it will be reused).

I didn't spend enough time with it to see your code structure but keep in mind that you only can do one thing at a time. That usually means that you don't have to save a lot of variables once you are done with them. Rather than a big main loop, break your code into bite-sized functions (subroutines) with clearly defined input, intermediate and output variables. Once you are done with that part, do you really still need to hang on to the input variables or can you re-use them? This is especially important with bigger constructs like strings.

A simple example would be:

• In a subroutine, declare the input string along with the parse code.
  
• Parse the input string. Get enough of the input string to do the job. Use comma counting to count the data that you need.
  
• Get the remaining characters of the string and just discard them without storing.
• 
  
• Convert numeric data from ASCII to something numeric and load into variables.
• Return - the space used by the input string is released for use by the next routine

Oshonsoft supports some structured programming with parameter pass by name and pass by value. Consider using these constructs to break the code into small, self contained (code and data) functions that release their temp memory when done.
http://www.oshonsoftbasiccompilers.com/pic18basiccompilerreferencemanual.php#376

Your PIC has the biggest RAM available in an 18F package. To continue, you'll have to find a way to reduce the number of full-time (Global) variables and let the compiler reuse that space.
You could add a serial RAM for storing bulk data but that's a pain, too.

You don't have to learn another language but at first blush, it looks like you can slick up your OBasic and recover some of that space.

Good Luck!

 

Can you help him?

Well I would have to see the code. But someone already mentioned one tip and that is to reuse strings. I believe the OP is programming in BASIC? That might not be helping depending on the efficiency of the compiler. I assume it is a compiler and not an interpreter like conventional BASIC If so then that is a major source of the problem. I also would look at code you might be able to do without.

 

I agree with pretty much everything John mentioned. The biggest thing I see is no subroutines. That makes you code extremely hard to manage. Frankly all of that code, I don't see how you are doing it without going crazy. And as John mentioned subroutines should give you the advantage of placing variables on the stack. So when the code is called the variables are used but after the function is exited, that memory is freed up for other functions to use.

I mentioned should because that is assuming your BASIC compiler allocates space for variables the way most compilers do.

And I can't stress more the organization it brings. You should be able to place those functions into files that can be included in your project. Put related functions all within one file. The file then should be able to be included in your project.

You are already making use of include files.
Include "fontsml.bas"

Expand on that but with subroutines.

And don't use got and Gosub if you can avoid it.

 

I've tried Swordfish, Great Cow, Picax, 'C; Arduino, ASM etc, all suggested in the past, but it's a waste of time, it's Oshonsoft or pack it all in, I'm afraid.
As mentioned, I rely on the Oshonsoft simulator. .
Cheers, C.

I know... And if there is anyone who is the most deserving of our help its you..The only thing I'm afraid of is oshonsoft support is not as it once was... The last time I opened your program, I couldn't help... I have watched every ounce of this project and if I had a medal I would pin it on Eric Gibbs.. I really really wish I could help more... If I had tons of cash, I would buy you the full proteus suite so you could simulate in real time..

As always, I will watch and if there is anything I can do to help, Ill be there.... On this occasion Look at the strings and which string can be used several times ( overwritten without any problem )… There is another option.. Buy a FRAM and store the strings externally... Works like a eeprom but can be written as fast as SRAM... I use 256k version.

 

Hi all,
Some really helpful stuff there, and I'll give it a closer look later.

Re: Medal giving. There are a handful of medals I would give for the patience and help I've been given, you know who you are, but especially EG.

Some years ago, my maximum program length was 2x A4 pages, and a headache, the program here is 12 pages, and only a mild headache. I'm surprised.

When I tried to learn 'Arduino', I found out about 'includes', and put each of the modules in my program, into it's own include, I soon got lost and had to put it all back in the order you see now. I think I would have the same difficulty with breaking up the variables. Once the program is finished, I may try that experiment, but I know I would be uncomfortable.

I was talking about this to a mate of my who is dyslexic, and we came up with the same answer. We both have an empty cave where we store our words/numbers. It's not really empty, but the information has to be either dug out or waited for. My dyslexia, has improved greatly by working on these programs, which shows one can re-wire our brains if we try. Most days I improve the program, but some days, I break it. I've got program histories going for miles, which may be on a different PIC or almost always needs the PINs changing.

Years ago, after getting mixed up with 'threads' I started initialing each reply, so the reply was aimed at a particular person, I also highlighted certain words by CAPITALISING them, e,g, If I read something, or the PIC READs something. This helps me a lot, but I went into the chat room and was being talked about! "How can you work with this idiot, he keeps capitalising words" I haven't been in there since. No problem it's fine out here

I'm sure I can get to the end of this program with the memory tidying help here, especially the shortened STRING stuff.

As always, Cheers, C.

 

So looking further at OBasic’s strings, it looks like you can only declare ONE string length for all strings:

All declared string variables will reserve fixed number of bytes in microcontroller memory. That number is set by the Define directive and STRING_MAX_LENGTH parameter. The allowed range for the parameter is 8-100; the default value is 16. The string variables will take one extra memory byte containing zero value to define the end of string (string termination byte).

It looks like the main reason for your big strings is so you can have one big one for the GPS sentence. Unfortunately, that makes ALL strings that large size.
To fix that consider some other approaches:
As you read the GPS sentence, use the comma counting method described to extract incoming characters into several smaller strings. That way, you can declare the default length of the strings much smaller.
Do you really need strings at all? Could you store them as characters in arrays or bytes? That way you could size the storage accordingly for each ‘string’ variable. In languages like C, strings are stored that way. You would lose the special string functions like substr etc. but it would save a ton of RAM.

Just thinking out loud but the quick solution to your problem may lie along those lines.

Good luck!

 

So looking further at OBasic’s strings, it looks like you can only declare ONE string length for all strings:
It looks like the main reason for your big strings is so you can have one big one for the GPS sentence. Unfortunately, that makes ALL strings that large size.
To fix that consider some other approaches:
As you read the GPS sentence, use the comma counting method described to extract incoming characters into several smaller strings. That way, you can declare the default length of the strings much smaller.
Do you really need strings at all? Could you store them as characters in arrays or bytes? That way you could size the storage accordingly for each ‘string’ variable. In languages like C, strings are stored that way. You would lose the special string functions like substr etc. but it would save a ton of RAM.

Just thinking out loud but the quick solution to your problem may lie along those lines.

Good luck!

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 could write you a store / retrieve function so you could save a string, then retrieve it at another point.. Even with a bit of functionality.. ie save portions, retrieve portions.. Say you have a string called sentence...

call StoreString( sentence, 0 , 50 ) ; stores a 50 character sentence...
Then using the counter part.
call RetrieveString( sentence, 10, 20) ; retrieves that portion..

This way all the data can be "off chip" and all you need worry about is one 50 character string...

 

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.

Just a side note re: strings. I’ve worked with many programming languages. Some of which strings were intrinsic to the language. Others not so much. And I used to believe using strings were much easier.

But...

Currently I’m most familiar with strings in Arduino C. And I no longer use them without having to add code to compensate for their peculiarities. Strings often were the root cause of program instability. Once I minimized the use of strings, the programs were MUCH more stable. Internal to the language, the overhead of string memory management contributed, at the best, to program bloat and crashes.

One of my large programs wouldn’t run over an extended period of time before it crashed. I do not strings since. A program CAN be written using strings, but it will hog memory and likely crash eventually.

The cons are not limited to Arduino C. The same tasks are being performed “under the covers”, IMHO, in any language in which they are a feature.

So knowing the limitations you should carry on. But while you do, familiarize yourself with char arrays as well. In the long run, you’ll benefit.

 

+1 While @camerart 's motivations to stay with what he knows are understandable, I agree with @djsfantasi on this one. Once you recognize that a particular construct can cause problems, and a big RAM footprint is always a problem in any PIC, it's time to look to other ways to do the job and maybe improve your skill-set at the same time. I can sympathize with your predicament here, no one wants to modify a working project to try other things but the realities are that 1) the time you spend fiddling with string sizes to accommodate the current design might be better spent at least looking at some of the alternatives suggested here. When successful, you would have added some useful tools to your bag of tricks. and 2) you may be forced to when you finally run out of RAM and there's no easy fix.

But with that, it's your project and you have to be in your comfort zone, too. See how changing the string sizes works and go from there.
Good luck!

 

+1
I have to side with John here. Once you get comfortable with a certain tool it's time to learn some new tricks.
You cannot go on pushing a square wheel for the rest of your life.