The arrays are for pulse counts + asscoiated ppm levels and would be low usage.. I was hoping the compiler had the facility to set up the table and then PICKIT3 would flash directly, but the main reason for GBC was because it supports the 16F18326 256 eprom, 2048-ram, 28k flash and PICKIT3 with
mplab 3.3 would program it, but with that much mem, it probably won't be an issue.
The 16F18326 was $ 0.71 microchip direct.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Then the third option above. "Lookup_Tables" is what you are after
quoting from the help file:
* Advanced use of Lookup Tables
You can use the Table statement to store the data table in EEPROM. If the compiler is told to store a data table in "Data" memory, it will store it in the EEPROM.
NOTE The limitation of of using EPPROM tables is that you can only store BYTEs. You cannot store WORD values in the EEPROM tables.
*
and this:
*Data tables can now be loaded directly from a file. The source file will be read as a hexidecimal raw file. Table TestDataSource from "sourcefile.raw"
*
if you want to calculate your tables with a spreadsheet etc, and have the PICKit upload iit or:
Data tables can be define by
1. a single value on each line
2. multiple elements on a single line separated by commas
3. constants and calculations within the single line data table entries are permitted
4. an external data source file
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is the proper way to store this table in EEPROM ,, the program compiles without errors,,,but I can find nothing related to prom in the ASM file....
TAB:
TABLE prom as string
16 '0
"This is a test"
15
end table
Last edit: xtal10 2016-08-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seen the Help file? You seem to making up you own syntax. See 'Advanced use of Lookup Tables'
You will have to define your string as values. (I thought we could process strings in tables - I will check later).
So, for now. I would use the import the external data file method for your strings. This will create a table in EEPROM of strings.
' ----- Configuration'Chip Settings. #chip 16f877a; ----- Main body of program commences here. Table TestDataSource from "table.txt" Store Data'You MUST do this read!! TableLoc = 1 ReadTable TestDataSource, TableLoc, SomeVarend
Your chip has huge memory. Why are you chasing 255 bytes of EEPROM?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I prefer to store Constants, MSGs ETC in EEPROM and use valuable pgm memory for pgm instructions,,,,,and wonder why eprom is so ignored , that the COMPILER cannot easily store constants in it? , I can't even use ALL 256 bytes , have to let byte 0 = the length, Sigh....and thats If I can figure out how to do it..
I saw the help file, I guess I need an interpreter, it caused me more confusion than help, Thats why I asked what the proper way was to store constants in EEPROM,
In other words show me a working example of how to store "THIS IS A TEST" in EEPROM using the COMPILER , not the program using eewrite etc....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just because you may prefer to store Constants in EEPROM does not mean there is anything wrong with the compiler.
Constants have been stored in Program memory for as long as Microprocessors have been around.
Any C compiler, try XC8, will automatically store Constants in program memory.
That is why every Hex File Viewer, ever written, displays Hex on the left and ASCII on the right. It is so that you can clearly see your Constant / string data, in the program memory.
EEPROM is for long term data storage of nonvolatile information that may need to change infrequently.
Constants should never change by their very nature and are therefore stored in program memory which is more abundant.
As with anything you may be able to find examples that deviate from this logic but the basic principle holds true for all compilers, and has been the accepted practice since the 1960’s.
Cheers
Chris
Last edit: Chris Roper 2016-08-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
EEPROM is for long term data storage of nonvolatile information that may need to change infrequently.
Now letting EEPROM layout word,word ~~~~~~~~word,word
where 1st word = 0-9999 ppm 2nd word=0-65534 pulses etc-etc-etc where ppm is associated with #pulses, these values will change with calibration changes...
This is easy to implement in EEPROM[8 bit] ....perhaps not so easy in FLASH[14 bit]
Anobium ..... I will try
Table TestDataSource from "table.txt" Store Data
to verify that data will be stored in EEPROM at compile time.....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
EEPROM is a Byte oriented Resource and therefore the Compiler writes Byte Oriented Data.
Again, you can not realistically expect the compiler to use Word Data on a byte resource.
It is up to you, to use the tools provided by the language, to adapt it to your needs.
Are you aware of Aliasing?
It is in the Help System and if you read up about variables you can't miss it.
If you need to store a word as two bytes do this:
Dim MyWord as Word Alias MyWordH, MyWordL
Now you have a Word Variable that can be treated as 2 bytes when working with the Byte Oriented resources of an 8 Bit controller.
That should point you in the right direction, just remember that it is an 8 Bit Processor, nothing, not even the Flash memory, can store or use Word size data.
Cheers
Chris
Last edit: Chris Roper 2016-08-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
EPRead and EPWrite are probably what you are looking for.
If you are working with one of the Newer PIC devices with HEFM (high endurance flash memory) then HFEreadBlock and HFEwriteBlock will be of use.
Both are covered in the GCBasic Help under command reference or in the online help here:
http://gcbasic.sourceforge.net/help/_eeprom.html
and here:
http://gcbasic.sourceforge.net/help/_hefm.html
Depending on your reason for storing the arrays in EEProm the following may be a better alternative:
http://gcbasic.sourceforge.net/help/_lookup_tables.html
Cheers
Chris
Last edit: Chris Roper 2016-07-14
The arrays are for pulse counts + asscoiated ppm levels and would be low usage.. I was hoping the compiler had the facility to set up the table and then PICKIT3 would flash directly, but the main reason for GBC was because it supports the 16F18326 256 eprom, 2048-ram, 28k flash and PICKIT3 with
mplab 3.3 would program it, but with that much mem, it probably won't be an issue.
The 16F18326 was $ 0.71 microchip direct.
Then the third option above. "Lookup_Tables" is what you are after
quoting from the help file:
*
Advanced use of Lookup Tables
You can use the Table statement to store the data table in EEPROM. If the compiler is told to store a data table in "Data" memory, it will store it in the EEPROM.
NOTE The limitation of of using EPPROM tables is that you can only store BYTEs. You cannot store WORD values in the EEPROM tables.
*
and this:
*Data tables can now be loaded directly from a file. The source file will be read as a hexidecimal raw file. Table TestDataSource from "sourcefile.raw"
*
if you want to calculate your tables with a spreadsheet etc, and have the PICKit upload iit or:
Data tables can be define by
1. a single value on each line
2. multiple elements on a single line separated by commas
3. constants and calculations within the single line data table entries are permitted
4. an external data source file
Cheers
Chris
thx for the info ,,, I just now have to convert the program to GBC
It looks like GBC doesn't do floating point, is that correct? thx again
Welcome. Currently no floating point. I am sure you are know the methods to get around this using factorisation etc.
I have no experience with the version of Basic but do ask and we can help.
What is the proper way to store this table in EEPROM ,, the program compiles without errors,,,but I can find nothing related to prom in the ASM file....
TAB:
TABLE prom as string
16 '0
"This is a test"
15
end table
Last edit: xtal10 2016-08-21
Seen the Help file? You seem to making up you own syntax. See 'Advanced use of Lookup Tables'
You will have to define your string as values. (I thought we could process strings in tables - I will check later).
So, for now. I would use the import the external data file method for your strings. This will create a table in EEPROM of strings.
Your chip has huge memory. Why are you chasing 255 bytes of EEPROM?
I prefer to store Constants, MSGs ETC in EEPROM and use valuable pgm memory for pgm instructions,,,,,and wonder why eprom is so ignored , that the COMPILER cannot easily store constants in it? , I can't even use ALL 256 bytes , have to let byte 0 = the length, Sigh....and thats If I can figure out how to do it..
I saw the help file, I guess I need an interpreter, it caused me more confusion than help, Thats why I asked what the proper way was to store constants in EEPROM,
In other words show me a working example of how to store "THIS IS A TEST" in EEPROM using the COMPILER , not the program using eewrite etc....
Try the code in the listing I posted!
Create a file called 'table.txt' put "THIS IS A TEST" in that file. Make sure this file is in the same folder as your source program.
Could not be easier.
Just because you may prefer to store Constants in EEPROM does not mean there is anything wrong with the compiler.
Constants have been stored in Program memory for as long as Microprocessors have been around.
Any C compiler, try XC8, will automatically store Constants in program memory.
That is why every Hex File Viewer, ever written, displays Hex on the left and ASCII on the right. It is so that you can clearly see your Constant / string data, in the program memory.
EEPROM is for long term data storage of nonvolatile information that may need to change infrequently.
Constants should never change by their very nature and are therefore stored in program memory which is more abundant.
As with anything you may be able to find examples that deviate from this logic but the basic principle holds true for all compilers, and has been the accepted practice since the 1960’s.
Cheers
Chris
Last edit: Chris Roper 2016-08-22
Chris the key here is
EEPROM is for long term data storage of nonvolatile information that may need to change infrequently.
Now letting EEPROM layout word,word ~~~~~~~~word,word
where 1st word = 0-9999 ppm 2nd word=0-65534 pulses etc-etc-etc where ppm is associated with #pulses, these values will change with calibration changes...
This is easy to implement in EEPROM[8 bit] ....perhaps not so easy in FLASH[14 bit]
Anobium ..... I will try
Table TestDataSource from "table.txt" Store Data
to verify that data will be stored in EEPROM at compile time.....
Oh. You need to think this solution through very carefully - you will be writing additional code when the standard methods will work.
EEPROM is a Byte oriented Resource and therefore the Compiler writes Byte Oriented Data.
Again, you can not realistically expect the compiler to use Word Data on a byte resource.
It is up to you, to use the tools provided by the language, to adapt it to your needs.
Are you aware of Aliasing?
It is in the Help System and if you read up about variables you can't miss it.
If you need to store a word as two bytes do this:
Now you have a Word Variable that can be treated as 2 bytes when working with the Byte Oriented resources of an 8 Bit controller.
To write your word:
That should point you in the right direction, just remember that it is an 8 Bit Processor, nothing, not even the Flash memory, can store or use Word size data.
Cheers
Chris
Last edit: Chris Roper 2016-08-23