Loading fonts from raw format (non-FAT16) SD cards

[Goran]

Hello,

i have a question regarding the usage of 3rd party fonts loaded from the Display's SD card.

Before i worked with Goldelox Displays, where fonts could be placed in raw format on the SD card, and could be loaded by first setting the sector address and then by setting the specific media font ID 7. A similar procedure also works for loading images and videos stored in raw format.

Now i am working with Picaso Displays. I checked the documentation, and i see that it is still possible to load images and videos in raw format same as for Goldelox Displays, but it seems fonts can't be loaded anymore in raw format, instead fonts have to be referenced using a file handle, which you get by using a FAT16 file open() operation. Why is the possibility to load raw fonts missing, isn't that somehow inconsistent?

I am using my own optimized SD card layout to describe which raw format content resides where on the SD card, so i know all sector addresses. FAT16 would just be another way to describe the layout, but for my application it would be oversized and have no gain at all, only serious drawbacks, so i would like to prevent using it and investigate other options.

I see that it is possible to define custom fonts in 4DGL #DATA segments and loading them by passing a pointer to txt_FontID(), so there are already several ways to address fonts: by passing a system font ID, by passing pointers to custom firmware fonts and by passing file handles.

And now to my actual questions:

1. Is it possible in 4DGL code to get a pointer to a raw format font in SD card memory (i would know the address) and to use this pointer with txt_FontID() to load the font similary to using a pointer to a #DATA segment?

2. If not, would it be possible to extend the Picaso PmmC code about an internal function to load raw format fonts like with Goldelox Displays, by setting the sector address first and then by passing a specific media ID to txt_FontID()?

Any help would be appreciated,
Goran

[ESPsupport]

I think what you want to do is covered in this thread http://forum.4dsystems.com.au/forum/...6-custom-fonts

[Goran]

Hello Mark,

thank you for the quick response. I checked the thread you supposed and i think it does not cover what i need.I have no FAT16 partition or any file system at all on my SD card, as its actually not necessary at least for Goldelox. As i understand this thread post assumes that you have a FAT and a raw partition, where you call the load image control file routine on the DAT file on the FAT partition to load the font from the raw partition. And i can't call file operation routines as i have no FAT, which i honestly like to prevent as it would cause some drawbacks for me. Could you please answer the two specific questions i asked before?

Goran

[ESPsupport]

Gee the reason Goldelox is RAW is because it is too small to support FAT.

All you need is a small FAT partition at the start of your card and put the .DAT files in there, you can still use RAW for everything else. Just what are your perceived drawbacks?

The Data statement is for fonts in flash only.

No it is not possible to extend the PmmC code.

[Goran]

There are good reasons not to use a FAT partition, at least for me. In my application the Displays are part of devices, which have to be updated at the customers side. Its not possible to ask the customer to take out the SD card, connect it to a PC and do a file copy or use any of your tools, instead its a task of the device firmware updater, specifically the Display updater part, which does it over a serial line for the Display SD cards using the SPE protocol. The drawbacks would be:

- writing the SD card over SPE is very slow, which extends update time.
- even a small FAT partition would be by far oversized compared to an optimized layout, regarding the slow write speed and what you would need to describe the layout with FAT (MBR, Bootsector, FAT and FAT copies, Directory entries with file modification times and attributes which i would actually need for nothing will make a lot of kilobytes which will make the update run minutes longer).
- i will have to implement FAT16 support in my updater.

For me these problems are 'serious', most probably not for most others. Independent from that Goldelox is too small, what i don't understand is that images and videos still can be addressed in raw format using the set sector method, but not fonts. Thats really strange and to me it looks at least like an inconsistency, if i were mean i could also call it a design flaw, sorry.
But after said that, thanks for your answers, i can now better estimate the effort i will have to put into the Picaso Display support.

Goran

[ESPsupport]

The FAT file simply contains the RAW address of the GCI file. So in reality, unless that file moves in the RAW partition, the FAT partition will never need updating.

Your 'Updater' just needs to only update the RAW area, it can completely ignore the FAT partition.