Proton BASIC Community

John, if you want you can send me the files (descriptor and VB.net source) and I can take a look.

Hi Trastikata,

many thanks for the offer, I'm away too, back late tonight, so it'll probably be Sunday before I get to my machine. Can you PM me your email address please?

John

Well that was odd. I later realised that I had made a typo in my code loading the USB out buffers,  with my string. I had missed out element 31 and for a reason that isn't clear to me that prevented my PC application seeing anything further, maybe it had interpreted the blank element as a nul string termination. Anyway I'm glad to say it's fixed, I can go to the ball now.

John

Quote from: John Lawton on Oct 03, 2021, 06:39 PMAnyway I'm glad to say it's fixed, I can go to the ball now.

Great, John, I am glad you solved it. Because it is a string, an omission to load something in element 31 effectively leaves it with a 0 fille byte which in the case of the string means the end of string.

I'd like some help converting the Flash strings used in the USB Descriptor file into RAM strings so I can modify them in my program code.

The descriptor file currently has a Manufacturer Name descriptor:

Dim Sd001 As Flash = { Byte SizeOf_Table,
                           Byte USB_DESCRIPTOR_STRING,
                           Word "ABC DEF Ltd." }

I can substitute this string to the above and this works:

    SD001:
    Cdata 26,$03,word "ABC DEF Ltd.",0

Note these are unicode (word) strings.

But how can I make this a program code editable RAM string?

Quote from: John Lawton on Oct 22, 2021, 04:38 PMI'd like some help converting the Flash strings used in the USB Descriptor file into RAM strings so I can modify them in my program code.
But how can I make this a program code editable RAM string?

John, sorry for the late response. So if I understand correctly you would like to be able to modify the descriptor strings? Then these should reside in such FLASH memory blocks which could be modified, i.e. can be entirely erased in order to be re-written. Thus the top memory blocks would make a good choice.

Thanks to tumbleweed's excellent solution, we can "force" the descriptor to create some of the data tables in the top memory.

Asm-
save_CData_PC Set $
EndAsm
' place CData at F400
Org 62464   
SD001:
    Cdata 26,$03,word "ABC DEF Ltd.",0
' restore PC (procs will follow...)
Asm-
Org save_CData_PC
EndAsm

In the code above, the descriptor will create the data table at the beginning of one of the upper 1024 FLASH blocks, which at some point you can erase and re-write with the new information for the descriptor to use.

You can either place all string tables in one block or in separate blocks and deal with them accordingly. If all put in one block, you will save memory space, if in separate blocks you won't have to complicate things writing all of them if only one needs modifications.

Another point to mention - don't forget that this is word string, so when you modifying it, place the zero's and if you shorten or extend the string, you will have to modify the first byte to reflect the new string length. For example this is how your original code with "ABC DEF Ltd." will look like in the PIC18F26J50's memory:

ADDRESS F400: 1A034100420043002000440045004600
ADDRESS F410: 20004C00740064002E00FFFFFFFFFFFF

If you want to change it to "ABC DEF Ltd.1" then you will have to modify the string length and add the symbol as word:

ADDRESS F400: 1E034100420043002000440045004600
ADDRESS F410: 20004C00740064002E003100FFFFFFFF


Hope this helps.

Late? You are always very prompt, much appreciated. I'm back on this after a weekend away (working).

I have been using Les's EEPROM address method to create 128 bytes of Flash data memory way above the program code and it works a treat, so I'll probably continue to use that unless Tumbleweed's method is better in some way?

I have mainly been struggling with using the Word string format so thank you for clarifying how that works, I'll dive in again and see if I can get it working.

John

Quote from: John Lawton on Oct 25, 2021, 10:07 AMI have been using Les's EEPROM address method to create 128 bytes of Flash data memory way above the program code and it works a treat, so I'll probably continue to use that unless Tumbleweed's method is better in some way?

With Tumbleweed's method you can force each string (data table) in separate block or addresses whereas with the EEPROM method you are bound to use only one address.

As for any disadvantages or potential problems when using the Assembler addressing, maybe Les can help clarifying it.

Understood, but I can Cwrite to different addresses, as I understand it the EEPROM memory address 'hack' just reserves the flash block(s).

Quote from: John Lawton on Oct 25, 2021, 01:45 PMUnderstood, but I can Cwrite to different addresses, as I understand it the EEPROM memory address 'hack' just reserves the flash block(s).

This however is still FLASH memory and later on if you want to update a given address or string, then you need to erase an entire block. Usually FLASH erase and write blocks are different sizes. For example in 18F26J50 you can write in blocks of say 64 bytes, however FLASH memory is erased in blocks of 1024 bytes. And as you know you can't write in FLASH unless it is cleared beforehand.

So if you place each of your data tables or strings at the boundaries of a new top 1024 byte block (if program size allows it), then you can update each of them separately. This is just for convenience.

My understanding of the EEPROM hack is that it forces the compiler to consider that the device in question has EEPROM at the given address where however you can not create data tables at different addresses but only at the beginning of the previously mentioned FLASH/EEPROM address. Hence you have to create the data tables sequentially (even with empty space in between). So if you need to have two data tables in different FLASH erase blocks, using the EEPROM hack method, you'll have to write a table of more than for example 1024 bytes (the data plus dummy bytes) to get the second table to the new FLASH erase block. 

Got it, thanks.

John

I've just tried the above code:
Asm-
save_CData_PC Set $
EndAsm
' place CData at F400
Org 62464   
SD001:
    Cdata 26,$03,word "ABC DEF Ltd.",0
' restore PC (procs will follow...)
Asm-
Org save_CData_PC
EndAsm
and get the error message: "*** The assembler's Org directive cannot be used in a program that has procedures within it! ***" Sadly it looks like I need to find another way.

The flash string I want to use (BTW, the string needn't be in Flash, it could be in RAM if I knew how to point to that in my USB string descriptor code)

Mystring:
    Cdata 26,$03,Word "ABC DEF Ltd.",0

How can I force the "Mystring" label to be a (high memory) flash data area address in my 128byte high memory area without invoking ORG?

Quote from: John Lawton on Oct 26, 2021, 02:42 PMThe flash string I want to use (BTW, the string needn't be in Flash, it could be in RAM if I knew how to point to that in my USB string descriptor code)

John, what do you mean "could be in RAM" - to load the string in the RAM at power reset, it has to be read from somewhere, hence you need it in the FLASH, thus any permanent modifications should happen in the FLASH string.

Sadly I don't see other option for creating data tables in the FLASH at predetermined addresses but to convert the procedures to subroutines. Maybe Les can suggest a different solution.

The correct code should be so

Asm-
save_CData_PC Equ $
Endasm-
' place CData at F400
Asm-
Org 62464   
Endasm-
SD001:
    CData 26,$03,Word "ABC DEF Ltd.",0
' restore PC (procs will follow...)
Asm-
Org save_CData_PC
Endasm-

Oh thank you, that compiles okay. So does your revised code work because the ORG command is used in assembler rather than Positron?

Everything is well compiled.

Quote from: atomix on Oct 26, 2021, 03:31 PMEverything is well compiled.

But enclosing the ORG command within Asm- and EndAsm- statements means the compiler doesn't complain?

Quote from: John Lawton on Oct 26, 2021, 03:34 PMBut enclosing the ORG command within Asm- and EndAsm- statements means the compiler doesn't complain?

For the compiler this is now Assembler and as far as I know if the Assembler syntax is correct, Positron doesn't complain.

atomix, nice workaround, thank you.

Yes, I've checked and the string is placed at the flash byte address specified.

Curiously, at first the USB code didn't 'see' the string (just ""), but then I moved the string statement around in the code so it seems to depend on where I put it... odd, but not at all due to the asm and ORG statements, so thanks Atomix for your fix.

John

Post removed. PEBKAC