A wish item that would be very handy is a String format Lookup table.
Example (96 Elements)...
Table MainLine2 "1. Display 2. System Setup 3. Config 1 4. Data Log 5. Diagnostic 6. Help "
End Table
. _______ (My Sub menu has 464 chr's (elements))
It's still a byte table in memory, so no change there, just getting the data in would be easier than converting all the characters to ASCII & formatting the line & paste or include ext file.
Reading strings is easy enough with index offset's & convert to string...
(MnuIndx from Menu navigation Sub) Case 1 ' Main Menu LCD_L1.Text = "Main Menu" LCDLen = 16 ' LCD chr's TmpStr = "" StrOffset = (MnuIndx - 1) * LCDLen + 1 For Lp1 = StrOffset To StrOffset + LCDLen - 1 ' no of chrs in each string TmpStr = TmpStr + Str(Table MainLine2(Lp1)) Next LCD_L2_Text = TmpStr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gday Anobium,
There is no Issue, the code snippet at the end is just an example of how I would get each string from a the table of ASCII bytes . (oops, sorry about the errors in it), I have not ported it over to GCB & compiled/test yet, the code is working in my simulation. (I was reading from an array in the sim)
"What is the chip you are using? This will help with the answer."
There was no question asked so an answer is not required! just any relevant discussion on the table data format.
The chip I am using is whatever I decide to use, or any other person using GCB would use.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The chip type, memory size and memory type and memory architecture will help.
Let us assume an old 16f88, let me assume an 18fk42, let me assume a LGT. Each chip family has different capabilities and a string lookup would be implemented in different ways.
But, given I am guessing. I would use a converter to create/manage/access the strings via a lookup function.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok,
You might be misunderstanding my feature wish, sorry if i wasn't clear.
What I suggest would not be relative to any chip type, its just how the compiler decodes the "string" between quotes & puts the bytes in memory.
Should be no different to how the Table command works now with numbers (they are actually strings in the basic code editor anyway)
I didn't suggest a string read from the Table (that's why I dropped the code snippet in my first post)
Example, the following would both result in the same byte list in code memory
~~~
' Existing Table format
Table NoLegs
0x53, 0x74, 0x72, 0x69, 0x6E, 0x67, 0x31
End Table
' Proposed Table format
Table NoLegs
"String1"
End Table
~~~
Result:
53 74 72 69 6E 67 31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like the idea but it may not be possible because of the way GCBASIC handles strings.
I will need some time to look at the way strings are handled and tables are created but I suspect that using the str() function to convert it will be more efficient unless string handling is redefined (which will not happen).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Chris, I have just been looking at the code in 'Sub ReadTableValues' & it looks like a block for convert characters between " " to ASCII values could be implemented.
I haven't used FreeBasic before so it will take me a bit to get accustomed.
If I get a useful result I will post.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I wanted a list of strings ie test, then tables would be best, so why not
put the decimal values for the chars and an end marker code to say end of string.
checking the end marker would be indexing ie check how many times the marker appears and use that as the start of string until next marker.
The marker being a non used char.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As Stan suggests, if wanted you could include a marker between the text entries if required.
I tend to have my entries in individual tables and then check the size of the table in code so that I know how many characters there are in each table, as I print them.
You'd be welcome to the lashed up code if you are interested?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This application will only work on a limited number of PIC devices as most have very limited RAM capability and what RAM they have is paged. AVR devices are better suited for working with string variables.
That said, however, if the memory restrictions are taken into consideration and RAM use is minimised in favour of Flash then it may well be a boon for string handling on RAM restricted devices.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It was a top of the head suggestion.
The extra end/start markers would add up but tables are in program memory and there's usually lots of it.
The idea was all text in one table and various length . if say wanted text 29 then count end
markers until 28 and add chars to empty string until next end marker.
dunno, just a thought
edit, shall I write code to illustrate cos if no one bothered then so am I ?
Last edit: stan cartwright 2021-02-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tech question
what if you define chars as their decimal/0-255 whatever tables allows as values.
define "a" 26
or something similar.
it would make the table easier to write.
like defining ili 9341_red re.
define chars to ascii values start of prog.
using a 328p and allowing for it's boot loader, I've never ran out of memory using 512b table.
is a table dynamic or fixed to certain size? if a pic has 32k prog mem then what is max table size?
Last edit: stan cartwright 2021-02-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to clarify the discussion is for full blown indexable Table strings ("string1", " string2", ...)
Not complaining, just my wish item was for a "hack" to enable easy input of "string" data from the Table code line with the same value index read as is now.
I am all for a string indexed Table as it would add to the already awesome IDE/Compiler that is the great cow!
'first wishTable Test1 "String to index characters from" : End Table 'UltimatewishTableTest1"Strings ","to ","index ","Strings ","from"EndTableTableTest1"Strings ""to ""index ""Strings ""from"EndTable
The Print "String " already does the first wish to some degree into code memory (not considering read)
Just to hi-lite the efficiency of tables...
In a LCD menu that I did recently(simulated in VB) it used 125 lines of code for Case blocks to print constant strings to 1602LCD, then using Indexed characters(ASCII->STR) from a table it is reduced to 41 lines(including table broken into 10 lines for readable). Indexing a whole string would be even less code.
Toni.g
.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
stan
"put the decimal values for the chars and an end marker code to say end of string.
checking the end marker would be indexing ie check how many times the
marker appears and use that as the start of string until next marker.
The marker being a non used char."
That's just what I did in assembler for an 8051 LCD menu back in the day.
It's structured like a "CSV line" in memory except its ASCII byte values & I used Null chr as separator between strings, loop'd the null find until loopcount = index .
Its very memory efficient, longer strings more so.
For GCB it would not be considered a "String" except for the the human coder, the compile pre-process & when the bytes are passed to the string variable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A wish item that would be very handy is a String format Lookup table.
Example (96 Elements)...
Table MainLine2 "1. Display 2. System Setup 3. Config 1 4. Data Log 5. Diagnostic 6. Help "
End Table
. _______ (My Sub menu has 464 chr's (elements))
It's still a byte table in memory, so no change there, just getting the data in would be easier than converting all the characters to ASCII & formatting the line & paste or include ext file.
Reading strings is easy enough with index offset's & convert to string...
@ToniG - does the code (one extra) line of code resolve the issue? ReadTable to the inChar variable.
Anobium
Gday Anobium,
There is no Issue, the code snippet at the end is just an example of how I would get each string from a the table of ASCII bytes . (oops, sorry about the errors in it), I have not ported it over to GCB & compiled/test yet, the code is working in my simulation. (I was reading from an array in the sim)
cheers
A question.
What is the chip you are using? This will help with the answer.
"What is the chip you are using? This will help with the answer."
There was no question asked so an answer is not required! just any relevant discussion on the table data format.
The chip I am using is whatever I decide to use, or any other person using GCB would use.
I humbly disagree.
The chip type, memory size and memory type and memory architecture will help.
Let us assume an old 16f88, let me assume an 18fk42, let me assume a LGT. Each chip family has different capabilities and a string lookup would be implemented in different ways.
But, given I am guessing. I would use a converter to create/manage/access the strings via a lookup function.
ok,
You might be misunderstanding my feature wish, sorry if i wasn't clear.
What I suggest would not be relative to any chip type, its just how the compiler decodes the "string" between quotes & puts the bytes in memory.
Should be no different to how the Table command works now with numbers (they are actually strings in the basic code editor anyway)
I didn't suggest a string read from the Table (that's why I dropped the code snippet in my first post)
Example, the following would both result in the same byte list in code memory
~~~
' Existing Table format
Table NoLegs
0x53, 0x74, 0x72, 0x69, 0x6E, 0x67, 0x31
End Table
' Proposed Table format
Table NoLegs
"String1"
End Table
~~~
Result:
53 74 72 69 6E 67 31
I like the idea but it may not be possible because of the way GCBASIC handles strings.
I will need some time to look at the way strings are handled and tables are created but I suspect that using the str() function to convert it will be more efficient unless string handling is redefined (which will not happen).
Thanks Chris, I have just been looking at the code in 'Sub ReadTableValues' & it looks like a block for convert characters between " " to ASCII values could be implemented.
I haven't used FreeBasic before so it will take me a bit to get accustomed.
If I get a useful result I will post.
If I wanted a list of strings ie test, then tables would be best, so why not
put the decimal values for the chars and an end marker code to say end of string.
checking the end marker would be indexing ie check how many times the marker appears and use that as the start of string until next marker.
The marker being a non used char.
I wrote a simple AppleScript Application that "automagically" creates the table for me.
I enter the required text and then it returns the table:
As Stan suggests, if wanted you could include a marker between the text entries if required.
I tend to have my entries in individual tables and then check the size of the table in code so that I know how many characters there are in each table, as I print them.
You'd be welcome to the lashed up code if you are interested?
There is converter (Windows) that does that same (depends on chip.. can put srrings into EE saving progmem.
That, sadly, doesn't work on macOS. I had thought there was one for Windows but didn't have the inclination to fire up the super laptop to check.
This application will only work on a limited number of PIC devices as most have very limited RAM capability and what RAM they have is paged. AVR devices are better suited for working with string variables.
That said, however, if the memory restrictions are taken into consideration and RAM use is minimised in favour of Flash then it may well be a boon for string handling on RAM restricted devices.
It was a top of the head suggestion.
The extra end/start markers would add up but tables are in program memory and there's usually lots of it.
The idea was all text in one table and various length . if say wanted text 29 then count end
markers until 28 and add chars to empty string until next end marker.
dunno, just a thought
edit, shall I write code to illustrate cos if no one bothered then so am I ?
Last edit: stan cartwright 2021-02-21
Tech question
what if you define chars as their decimal/0-255 whatever tables allows as values.
define "a" 26
or something similar.
it would make the table easier to write.
like defining ili 9341_red re.
define chars to ascii values start of prog.
using a 328p and allowing for it's boot loader, I've never ran out of memory using 512b table.
is a table dynamic or fixed to certain size? if a pic has 32k prog mem then what is max table size?
Last edit: stan cartwright 2021-02-21
Just to clarify the discussion is for full blown indexable Table strings ("string1", " string2", ...)
Not complaining, just my wish item was for a "hack" to enable easy input of "string" data from the Table code line with the same value index read as is now.
I am all for a string indexed Table as it would add to the already awesome IDE/Compiler that is the great cow!
The Print "String " already does the first wish to some degree into code memory (not considering read)
Just to hi-lite the efficiency of tables...
In a LCD menu that I did recently(simulated in VB) it used 125 lines of code for Case blocks to print constant strings to 1602LCD, then using Indexed characters(ASCII->STR) from a table it is reduced to 41 lines(including table broken into 10 lines for readable). Indexing a whole string would be even less code.
Toni.g
.
That's just what I did in assembler for an 8051 LCD menu back in the day.
It's structured like a "CSV line" in memory except its ASCII byte values & I used Null chr as separator between strings, loop'd the null find until loopcount = index .
Its very memory efficient, longer strings more so.
For GCB it would not be considered a "String" except for the the human coder, the compile pre-process & when the bytes are passed to the string variable.