NOTE: C51
Keil uses 16 bit pointers and I have a file which is larger than 64k.
the file is a bunch of structures (all pointed to) that I acces as structures
This creates pure havoc when a structure crosses a 4k boundary.
example: at 0fffe U16 shortvalue U8 charvalue if you access charvalue as str_pointer->charvalue, you get the contents of location 0, not 10000.
these values are NOT accessed by 'regular' code, but by U8 ReadFlash(U32 address)
any suggestions. The only one I have come up with is rather 'unpleasnt' i is to use #defines instead of structures as in above example #define shortvalue 0 #define charvalue 2
this makes [str_pointer->charvalue] into [str_pointer + charvalue] which the compiler treats 'correctly' as a 32 bit addition.
Erik
PS I have begged and begged the creator of these files to 'gap the files' where a 64k cross happens but get a "no way Jose"
Anyhow as to "obviously a misrepresentation of the facts" Keil DOES support "data banking" which, in it's way, makes the data address reange 24 bits.
Yes, but that would be called HDATA, not XDATA. And the way you pointed out that "of course" you accessed that data via an accessor function pretty much proved that you're not using that, so it's beside the point.
There's structurally no difference between an accessor function like that, and generic file I/O via fsetpos()/fread(). For all practical intents and purposes, that data is on mass storage.
just trying to find the 'safest' or, if you will, 'best' solution.
There is not really any "safe" way, because you have to leave the region where the safety features of the language can offer any help. There's not much to be improved over the obvious #define'd offsets. As a bonus, that method allows you to break the strict relation between the data layout in the file, and that of the C structures. E.g. even if the other side of the storage model needs padding, you don't have to bother the C51 with it.