EEprom management

[keytapper]

Hi forum,
I was trying some way to be less prone to flaws as I wanted to configure the writing on the EEPROM in a manner that I should not worry if something will change on the other part, such as changing the variable cast. In fact the compiler should take care of these changes.
So I wrote a little snippet:

Code Select Expand

Sub EEreadRamdata()
  var1 = numblock * RAMDATASPACE
ReadEEdata:
  RAMdataWr = ERead var1
  tmpl = SizeOf RAMdataWr
'  Inc var1, SizeOf RAMdataWr              ' it doesn't compile
  Inc var1, tmpl
  RAMdataSize = ERead var1
  tmpl = SizeOf RAMdataSize                 ' it doesn't compile
'  Inc var1, SizeOf RAMdataSize
  Inc var1, tmpl
  RAMdataTotLen = ERead var1
  tmpl = SizeOf RAMdataTotLen
'  Inc var1, SizeOf RAMdataTotLen           ' it doesn't compile
  Inc var1, tmpl
  RAMdataRep = ERead var1
EndSubSo the initial attempt was to use the way which is commented out now. But there's something I don't get because the compiler knows which value to assign to the variable, thus should be same for the Inc formula.
One more study it was to create an array, but there's no such option to do

Code Select Expand

Dim RamData[12], address as Byte
Ewrite address, RamData              ' that should write the whole array


[top204]

SizeOf is a compiler inline command and is not supported in that position within the compiler. Inline commands and macros and procedures are also blocked in other areas of the compiler because an inline command or procedure could actually alter the variable that is being incremented. Than what?

In most commands, the compiler will give an error message stating that an inline command is not suitable at a positiopn, and in the case of the Inc and Dec commands, it will give an error message that it does not recognise the variable after the SizeOf function. For example:

Inc MyDword, SizeOf MyWord

Will give the error message:

*** Unrecognised, Illegal or Unresolvable characters found ' MYWORD '! ***

I will go in and change the error message for Inc and Dec to the more recognisable one for "inline commands not supported at this position".

The ERead and EWrite commands use the assignment or parameter variable sizes to dictate what to read or write to EEPROM. A better method for dictating their size would be to create a few procedures that will only read/write various sizes. For example:

EEPROM_Read8 or EEPROM_Write8 or EEPROM_Read16 or EEPROM_Write16, where the size of the parameter variable and the size of the Result variable dictate what size will be written and read.

[keytapper]

SizeOf is a compiler inline command and is not supported in that position within the compiler.

I will take it in account, as long as my memory won't leak . Good explanation

Inc MyDword, SizeOf MyWord

Wouldn't include the sum or subtraction, which are the aliases for these command?

EEPROM_Read8 or EEPROM_Write8 or EEPROM_Read16 or EEPROM_Write16

I'll try it with newer MCU, I'm working on a 14 core one, as a retrograde as I am, I wish to get rid of those mummy . So I've a bit of fights to limit the 8 jumps on subroutines.
I'm pleased that the compiler is very parsimonious and the result is great.

[top204]

I know it seems like a big step to move away from the 14-bit core devices, but they are now 20 years out of date!

The compiler makes it so simple to move to an 18F device, and after a few days you will not actually notice that you are writing for a more flexible and powerful device, until the program compiles and operates, then you will see the "good" difference in size and speed and flexability. Then after a few weeks, you will think to yourself "why did I stay with such a clumsy and slow device for so long?" :-)

I know this because I did the same about 19 years ago when the 18F series devices first came out. i.e. The good old PIC18F452. It was like magic back then, with all that flash memory and RAM, and all those clever mnemonics, and it could operate at a whopping 40MHz! :-) They haven't advanced enough with the speed of them, but the newer 18F devices do have more inside them, and are just as easy to work with.

Also, the 18F devices are less expensive than the very old PIC devices, and you get a lot, lot more in them. Also, they will be around for a lot longer than Pi nonesense and ESPs that go out of fashion, so are dropped, or the new one comes out and nothing works on the old ones and they are no longer available. This type of thing has happened many times over the past 20 years, but you can still buy the Microchip devices from way back when.

[top204]

Keytapper.... With your spotting the SizeOf function not being supported as the second parameter within the Inc and Dec commands, I have allowed it through with them in version 4.0.2.3 of the Positron8 compiler, and will add them to the Positron16 compiler ASAP.

The SizeOf function is different to standard functions, in that it returns a constant value to the parser, and is more like a directive, so it will not interfere with any variables that are being altered by the command, so I made a special trap for that function alone. Other inline commands (compiler functions) and procedure calls as the second parameter will also give the appropriate error message that they are not supported at that position.

The version 4.0.2.3 update is available from here:

Positron Corrections Update 4.0.2.3-1.1.0.9

[keytapper]

Thank you for your great attention, Mr. Les.
In facts the statement like SizeOf, AddressOf and Bound should have a constant as result, no user will do much about them.

I vote for the chance to write an array, just by mention its name.

Code Select Expand

Ewrite address, myarrayThat should go smoothly, because the compiler knows the length of the array. There should be only necessary a precaution from the user to know the boundary of the data written. Hardly I suspect that EEPROM access has some kind of bank 

Anyway, please don't cross your line of comfort