storing large 24 bit unsigned ints in 18F prog memory

[asmboy]

I am contemplating IF it is feasible to store on the order of appx 10,000
24bit unsigned INT values ( up to appx 640,000 largest value) in program memory ( roughly 30,000 bytes of space ) using an 18f4620 - the actual code space for the program itself is under 10k and the part has 64K of total prog flash available .

The data will always be read sequentially from said table using a unique RLL ending 'tag' numeric value of 0xFFFFFF - no issues with managing the offset.

The dual unknowns for me are :

1- I don't know how to define or use a 24 bit, unsigned INT type.

While I assume I can write an efficient pair of conversion functions to go
between 32Bit unsigned & this special space conserving 24 bit type - I don't know how to go about defining a custom type to do the job for me.

2- It is not clear if the compiler is up to the job of doing this sort of custom var type in such a large prog mem table format - and I'm wondering if I have to approach this from a complete custom-on-my-own standpoint using direct access using read_program_memory().

Anybody been over this territory before ?

[Ttelmah]

Unions and structures are your friend.
You can declare a structure of three bytes, then a union between this, and a int32. If your 'space saving', is being done by just dropping the high byte (values are unsigned), then you can still use the normal 32bit operations to work with the values (though possibly worth considering adding 'limit' handling).

Since values are stored LSB first in memory, you can just let the union 'throw away' the high byte.

You can then just assign an array of 3byte structures. To put these into an int32, just copy an entry from the array, into the structure in the union, and then read the int32 in the union. You can do exactly the same in the other direction, _but_, I'd suggest you test if the int32 is > 16777215, and if it is, set it to 16777216 (limit handling).

If you want to handle signs, then you'd need to test the top bit of the 4 bytes, and move this to the 24th bit, and do the opposite, when transferrig the other way.

As an example, of dong this with a signed value, the following may give you some ideas.

[asmboy]

i don't have a CLUE of how to apply that UNION example in practice - really.
meanwhile this is what i had come up with - as all i care to do is lookup ONE data item at a time - convert back to 32 bit format and put the looked up value in a local array for immediate use . this is what I had come up with but is it WRONG ??

or is some other way unworkable? the LST file shows that TBL lookups
are being done. but i cant find where the data i load in the CONST array is placed. this is the critical snippet that i wrote - that compiles ok.

is this OK or what am i missing ??

[FvM]

Defining a struct to handle a 24-bit int does not imply, that the compiler is able to understand 24-bit
constants as you try in your code. The compiler can only work with constants of known types as int8 or int16.

You didn't mention this initializing point before. Basically it should work with a macro, that splits a long integer
value into three int8 values respectively an int16 and an int8.

[Ttelmah]

Yes.
If you look at my example, wat is happening, is that an int32 signed value, is being 'cut down' to a 24 bit signed value, and then returned _in_ an int32. The only 'package' that CCS will understand as containing 3 bytes, is an array of 3 bytes (in a structure say). All the default types contain 1,2, or four bytes. Once the value has been 'cut down', it is no longer useable with the CCS arithmetic. You can assign the cut down value to an array of 3 byte structures, and to come 'back' do the same in the opposite direction, but you have to convert the value _back to an int32 before using any arithmetic, or write your own 24bit arithmetic routines.

It'd help massively if you said whether the values are to be signed or unsigned (the later is simpler).

However unless you want to get involved in writing 24bit arithmetic (one program I posted here some time ago, had a 24bit addition routine in it), you need to extract the numbers from your 'compressed' form, back to the full size _before_ performing any arithmetic.

As an example of the 'structire/union', doing this for you, and how to handle the storage, the following should give some ideas:

[FvM]

You can use a macro for the compile time conversion of initializing constants:

[asmboy]

Sorry for the lack of important detail.

The values are ALWAYS Unsigned and never greater than 2,000,000.

In practice these are a set of stored frequencies that are later input to
a routine that drives an AD9833 DDS /DNO circuit via the SPI sync port.

I had to use a table as the list is quite long ( up to 10,000 items)
and there is no regular/calculable interval between values - no way to algorithmically generate the frequency steps required.

And worse - different variations on the finished instrument will have different tables. The fix for that is to have the table generating code be an include file and to have several different includes depending on the requirements for specific product.

BTW_ thanks for the extra help - it grows clearer as I read.

[asmboy]

BTW- T H A N K Y O U

Ttelmah & FVM 4 your most generous help

i believe i have got this knocked now!!!