In the docs for the flash API it says there is a limit of 2000 for the number of flash object IDs. I take it this is a total for all flash handles, not each one. Data loggers seem quite a common application, and 2000 entries is not a lot for a typical data logger, so people must have come across this problem. Is there a way round it?
Do people concatenate data to make larger groups then save them, at the risk of loosing a groups worth of data?
Any thoughts?
Wouldn’t A&D Storage be more appropriate for data logging than Flash Objects…?
I need the logging to be persistent in the case of power out. I guess this is normally done by passing the data on to a server regularly, but not in this case.
Edit
Doh!
OK, I get it now. There are two areas of flash handled by two different APIs. In the A&D API ( 3.22 )it doesn’t actually say its flash or persistent, but looking at the Flash Resources diag 2.3.2 it now becomes clear. When I first looked at the diag the A&D description just looked like a generic term for the available flash, not another API, shame it doesn’t refer to it!
Thanks for the hint.
Hiya,
And the FLASH is quite a lot smaller than the A&D storage area.
However, you can write and rewrite to the same object ID in flash, with the OS taking care of the read/erase/write cycle for you. In the A&D area, once you have finalized a cell, if you want to update or extend it you have to take care of the read/erase/write cycle yourself.
ciao, Dave
Interesting point.
I had thought of using data blocks and the re-write facility in the flash objects, it might be still an option.
The A&D cell has a 16 byte header which is roughly the same size as my data packets, so putting in blocks may be the way to go.
Thanks.
Hiya,
Don’t overlook the fact that the FLASH area appears to be fixed in size (and reasonably small), whereas the A&D area can be resized (using AT+WOPEN) to take advantage of the entire available flash on the unit (less that being used for your application code).
ciao, Dave
A&D storage doesn’t have a read function. Therefore, you can write data too it all day long but good luck getting the data out of A&D.
You can resize the Flash Object area using later versions of DWLWin, loading later releases of firmware (I don’t remember the exact version numbers). My local FAE just gave the maximum size information:
1728KB size and 7939 objects
The adl_adInfo function provides a pointer to the stored data - so you can read the data via that!
You can also do it with AT+WOPEN
I doubt it. All documents provide 128K space for Flash Object area.
i thought that there is only 128K for flash area. Can it be extended via AT+WOPEN???
The Q2687 G* has 1MB of RAM and 5MB of flash available. The H memory part only has the 256K of flash. The 5MB of flash is shared between the A&D storage and Flash Objects.
For some unknown reason the Wavecom engineers decided to only allows up to 1.7MB to be allocated for flash objects. I think they want to force users to save enough room for a DOTA of the entire firmware. But since NO ONE I know of has ever used DOTA to update the firmware, I don’t understand the logic of not allowing the user to decide to use ALL 5MB for flash objects. Also, the limitation on 7000 objects is a pain in the behind too. I have a project where our code logic would have been trivial if we could have had 20,000.
Also, keep in mind that the OpenAT firmware uses some of your flash object area for internal purposes. Therefore, if you use the memory free ADL function to find out how much space is available in the flash object area, you’ll notice some space missing even if you havn’t allocated any flash objects.
I wonder if it was an engineering decision, or a marketing one…? 
More precisely, if markeing decided that the ability to update the entire firmware over the air was a good feature to have on the list - and that then constrained the engineers…
(I know that other manufacturers do advertise the ability to update their entire firmware over the air)
I think marketing can still say they support full firmware update while giving the customer the ability to configure the module in a way that essentially turns the feature off. I personally don’t see any conflict there… 
It is not true.
It is not true too.
Look in ADL user guide for Open AT OS v6.30 section 2.3.2. It clearly shows that for any amount of flash you have only 128k area for Flash Objects. All other space is placed in A&D storage and divided between Applications space (for DOTA) and Data space (for application defined data).