Proton BASIC Community

This is probably one for Les, but others may have a work around

Am working on the P16F15376 and pretty much have the whole of the MCU HW blocks running without any major Compiler commands (not a dig at you Les for it now working, I know that the device is mashed up) by accessing the HW functions via procs, long winded but an excellent way to understand the device.

The 367 has 16k which sounds decent however this is development will be packed out with most HW functions running, including floating point and large Flash tables.  I have the NVM flash routines working now where I can write to any 14-bit word in the DFM, without being on a row boundary and can read the DIA strings for the VREF and Temp figures.  Now the DFM  can have up to 14-bits which in most instances is large enough to store 10b-t writes to the ADC and PWM and in terms of math you can do quite a lot in 14-bits..  If I use the LDATA or DIM X as Flashx then I can only store 8/16/32 bits etc and this can eat the flash quite quickly for larger tables as it scales the DFM in a byte per DFM word ratio.   

Q. Is there any way in utilising the full 14-bit word in the compiler commands by adding a FLASH14 to the list for flash tables,(maybe expanding the LDATA and CDATA commands too?  This could open up much more table space and potentially free up the upper 6 bits for flags, status bits  for a single location in the DFM?

J

I used to implement the code memory tables as the "word" size on 14-bit core devices, but it used to confuse some people because a "word" is the standard representation of 16-bits, not 14-bits. So I moved to two 8-bit values held in a single 14-bit flash memory cell for a 16-bit, and larger, value, so that it did not confuse people, and the code to handle larger values held in flash memory was a lot more efficient. :-)

You can perform the task of creating a flash memory table using Asm-EndAsm. For example:

Flash_Table:
Asm-
    dw 100, 200, 300, 400
    dw 16383
EndAsm

Notice the "Asm-", and not just "Asm"? The dash after the directive stops the compiler from adding flash memory banking mnemonics, that would cause an offset to the table's data.

If you look at the .lst file, it will be:

00CF                  01225 Flash_Table
00CF   0064 00C8 012C 01226     dw 100, 200, 300, 400
       0190
00D3   3FFF           01227     dw 16383

See that the "dw" directive is producing the 14-bit flash data as a single element. However, if you use values greater than 16383 (0x3FFF) (14-bit), as shown below:

Flash_Table:
Asm-
    dw 100, 200, 300, 400
    dw 16383, 16384, 32768
EndAsm

The table data will be incorrect because they exceed the flash memory cell limit, as the .lst file will show:

00CF                  01225 Flash_Table
00CF   0064 00C8 012C 01226     dw 100, 200, 300, 400
       0190
00D3   3FFF 0000 0000 01227     dw 16383, 16384, 32768

Notice that it has filled the flash memory cells with 0000 for values greater than 14-bits.

Magic... I thought that there  would be a back door, forgot about the old dw directive.

Understand the limits, its just nice way to maximise some tables at compilation or during test/temperature.

Q. If I wanted to place the tables in a specific memory location within the chip, will ASM- allow the compiler accept ORG?  As adding ORG and optimiser > 0 doesn't allow its use or with Procs.

I want to keep a specific memory map structure for tables and constants that can be updated during Automatic Test and flashed via ICSP or uploaded via a comms channel with compression applied.  Some tables are row aligned to make them efficient and others have a dual compression algorithm to allow for much larger tables and to replace sections of the main program procedures that are inserted depending on the test results/ temperature dependence and device characteristics.

This way I can precompile or adjust procedures, compile  and then insert the code block into a specific memory location depending on the test results.
 

Thanks Les

The assembler directive Org and procedures do not mix Jon. The procedures will be created after the Org address, so it will be incorrect.

That is one of the reasons I added the Dim As Flashx directives, to the compiler has control of where the flash memory resides. Unlike CData and LData.

 

Ah..balls..  I can get round this the old way manipulating the hex and NVM or ICSP flashing and using subs. Unfortunately I  don't have the luxury of more flash on this project, got some other ways but its more work. 

Just love the compiler for its code efficiency and speed.  Why do it in 20k when you can do it in 3.  Its like art, when you see it you just know its different

QuoteI used to implement the code memory tables as the "word" size on 14-bit core devices, but it used to confuse some people because a "word" is the standard representation of 16-bits, not 14-bits

Just squeeze it in  ..    I know you have a load of unpublished commands and features, its efficient hence why you put it in  at the start. You know it makes sense and is useful.  As we are now on individual compilations of the compiler you can add that into mine and add it to my yearly renewal.
I don't mind paying for the feature at all, it keeps the code concise so I can pick it up quick. Can PM me if this on the cards.  Also very interested in an efficient Edata substitution for any DFM writes on these devices.  Currently have the full Flash manipulation  into 300 bytes for any write plus erase but again if i spend a day working out the structure or documenting its more efficient to have a custom command and having it concise. 

One thing I did not realise before was the power of the  proc within a proc.  ex  MyVar = Proc1(Proc2(),(Proc3 ()- Proc4()).   


J x

I tried the ORG within the ASM- and it does place tables at the correct location in memory

asm-                               '    USED TO STOP THE COMPILER PRODUCING BANKING
org 10000
dw 232,1023,3245,5372,9876,1,123
endasm



Quote from: JONW on Jan 22, 2023, 10:19 AMI tried the ORG within the ASM- and it does place tables at the correct location in memory

Jonw,

the ORG directive within Assembler code used to work for me in the past to combine HEF tables and procedures, but not anymore. How did you go around that? For example this used to work.

Device = 18F26J50
Declare Xtal = 20

Main:
    Clear
    MyProc(123)
End
   
Proc MyProc (Temp As SDword), Float
    Result = Temp
EndProc

Asm-
    save_Data_PC Set $
EndAsm

Org 63488
CData $CD

Asm-
    Org save_Data_PC
EndAsm


Not sure now  .  Just added it in to the code and it compiled and I could then access the bytes ok but looking at the hex files with and without the asm- and dw they are totally different and not what i expected. 
I now think this can only be done by either directly adding the tables to the hex file after compilation or loading the tables in via comm port and using flash Read/Write commands.  O just exchange procs for subs.


 

Device = 18F26J50
Declare Xtal = 20

Main:
    Clear
    MyProc(123)
End

Proc MyProc (Temp As SDword), Float
    Result = Temp
EndProc

 asm-                               '    USED TO STOP THE COMPILER PRODUCING BANKING
org 10000
dw 1111,2222,3333,4444,5555,6666,7777
endasm


The above compiles ok but look at the hex with and without the asm-, not sure if its moving the procedures to that offset, therefore if you increase the table size you will corrupt the code.

Think I will opt for merging hex files

Quote from: JONW on Jan 22, 2023, 11:25 AMNot sure now  .  Just added it in to the code and it compiled and I could then access the bytes ok but looking at the hex files with and without the asm- and dw they are totally different and not what i expected. 
Think I will opt for merging hex files

Oops, my bad I missed to wrap the data table, this I think should work combining flash tables and procedures:

Device = 18F26J50
Declare Xtal = 20

Main:
    Clear
    MyProc(123)
End
   
Proc MyProc (Temp As SDword), Float
    Result = Temp
EndProc

Asm-
    save_Data_PC Set $
EndAsm

Asm-
    Org 63488
    dw 1111,2222,3333,4444,5555,6666,7777
EndAsm

Asm-
    Org save_Data_PC
EndAsm


Yes it does!  Very Nice, thanks dude

Out of curiosity, how does that work Trastikata?  Never used Set in any ASM

Quote from: JONW on Jan 22, 2023, 04:55 PMOut of curiosity, how does that work Trastikata?  Never used Set in any ASM

Set is the same as Equ but can be modified later. The dollar sign gets the current assembler address.