Using Datalogger- and EepromService together - movesense

I am trying to store some data on the device that I do not want to be overwritten by when the datalogger is full. And have run into some minor issues. I was looking for the "eeprom_logbook_app" but could not find it in firmware version 1.6.2 of the device-lib.
I have defined how much space I want for my persistent data and in App.cpp I have used the LOGBOOK_MEMORY_AREA(offset, size) macro.
where I have used the size of what I want to store as the offset and set the size to be
(2097152 + 1048576) - (size of data I want to store)
as this was what was returned when I asked the sensor for the eeprom size. (The eeprom is devided between 2 ICs one with 1MB capasity and one with 2MB capacity?)
Then I remembered that there was some talk about ExtflashChunkStorage::StorageHeader being stored as the first 256 bytes in this answer.
So my question is where the data will be offset from and what is the max size I can set as size so that I can subtract the correct amount to fit my data? I presume I at least need to take another 256 bytes off from the size to get my correct storage size.

As stated in my comment I got this working the only thing you need to do is using the LOGBOOK_MEMORY_AREA(offset, size) function.
let's say you want to set aside 256 bits for your own config you could then do this:
#define RESERVED_CONFIG 256
#define TOTAL_MEMMORY_SIZE (2097152 + 1048576)
static const uint32_t offset = RESERVED_CONFIG;
static const uint32_t size = TOTAL_MEMMORY_SIZE -offset;
LOGBOK_MEMORY_AREA(offset, size);
This will set aside 256 bytes on the start of the EEPROM memory and offset the logbook to accommodate this. As a result, the logbook header will also be moved to the start of the logbook's memory area.

Related

Calculate the size of FAT table

Given a disk block has the size of 4096M formatted to FAT. The size of each block is 64K. Calculate the size of the FAT table.
My solution:
Number of blocks = disk size / block size = (4096 * 2^20) / (64 * 2^10) = 2^16 blocks.
Assume using FAT16, since we have 2^16 blocks -> have 2^16 entries, each entry needs to store 16 bits.
=> Size of FAT table = 2^16 * 16 = 2^20 bits = 128KB.
I'm preparing for the final exam and the funny thing is that my teacher told me to self-study virtual memory so I'm not sure that my solution and explanation are correct or not. Please help me point out if I'm doing wrong. Thanks for reading.
I've already had the answer to this question and found out I was correct. Thank you and peace out!

EEPROM Page Size Clarification

Does Page size actually mean how many bytes i can read/write per read/write cycle?
for example a page size of 16 bytes means i can read/write in a single read/write?
Thanks.

STM32F746ZG - How to update some part of 256 KB sector in flash

I'm using STM32F103 and moving my code to STM32F746. The F103 was able to update Flash on a per-page basis in 1KB and 2KB.
I have STM32F746ZG Nucleo-board and my code size is big, flash took up to 0x08038000. I want to save other small applications on 0x08040000(sector_5). This applications consist of several 2KB sizes. I need to store multiple applications in Sector_5 and M7 cannot use Flash in 1KB or 2KB increments.
The followings are sector sizes of STM32F746ZG.
#define ADDR_FLASH_SECTOR_0 ((uint32_t)0x08000000) // 32 Kbytes
#define ADDR_FLASH_SECTOR_1 ((uint32_t)0x08008000) // 32 Kbytes
#define ADDR_FLASH_SECTOR_2 ((uint32_t)0x08010000) // 32 Kbytes
#define ADDR_FLASH_SECTOR_3 ((uint32_t)0x08018000) // 32 Kbytes
#define ADDR_FLASH_SECTOR_4 ((uint32_t)0x08020000) // 128 Kbytes
#define ADDR_FLASH_SECTOR_5 ((uint32_t)0x08040000) // 256 Kbytes
#define ADDR_FLASH_SECTOR_6 ((uint32_t)0x08080000) // 256 Kbytes
#define ADDR_FLASH_SECTOR_7 ((uint32_t)0x080C0000) // 256 Kbytes
STM32F746 consists of flash in a sector size of 256 KB each from Sector_5 to Sector7. If I want to use the Sector_5, I have to erase the whole of one sector. What if I want to update only about 2KB in the front of the Sector_5 and keep the area after 2KB intact? It means I only update the content from 0x08040000 to 0x08042000. I have to keep from 0x08042001 to 0x0807FFFF.
I can't even copy 256 KB of Flash to RAM. Because F746 only have 240KB of internal RAM and my many tasks already used RAM, so there is not enough RAM to copy one sector. In this case, please let me know how to update part of 256KB in flash.
On the ST's flash technology, there is no way to update anywhere in the sector without first erasing it. So if there are content in the first 2KB, you cannot update it without erasing the rest of the sector.
One possibility is that you can keep one sector as a temporary buffer and never use it for real storage. Let's say you use sector 7 for that. So when you want to update sector 5, erase sector 7, copy sector 5 into sector 7, and then erase sector 5 and copy relevant content back.
Another possibility is to add an external EEPROM or SRAM for this purpose. SPI flash EEPROM is fairly inexpensive and they have a typical 100,000 write cycles, so also perfect for this use.
That depends. On many STM32 microcontrollers you can zero the bits of the FLASH without erasing it. But you cant set the bits of course - it can only be done by the erase operation. Some chips do not allow it as the flash sector has its own CRC.
If your chip allows the writing to the 0xff filled FLASH you can store the data in another place of this sector. If not You need to copy data to another sector, arase the sector and the write the data back.

What is the maximum size of TIFF metadata?

Is there a maximum limit to the amount of metadata that can be incorporated in an individual field of TIFF file metadata? I'd like to store a large text (up to a few MB) in the ImageDescription field.
There's no specific maximum limit to the ImageDescription field, however, there's a maximum file size for the entire TIFF file. This maximum size is 4 GB. From the TIFF 6.0 spec:
The largest possible TIFF file is 2**32 bytes in length.
This is due to the offsets in the file structure, stored as unsigned 32 bit integers.
Thus, the theoretical maximum size is that which #cgohlke points out in the comments ("2^32 minus the offset"), but most likely you want to keep it smaller, if you also intend to include pixel data...
Storing "a few MB" should not be a problem.

Main memory bandwidth measurement

I want to measure the main memory bandwidth and while looking for the methodology, I found that,
many used 'bcopy' function to copy bytes from a source to destination and then measure the time which they report as the bandwidth.
Others ways of doing it is to allocate and array and walk through the array (with some stride) - this basically gives the time to read the entire array.
I tried doing (1) for data size of 1GB and the bandwidth I got is '700MB/sec' (I used rdtsc to count the number of cycles elapsed for the copy). But I suspect that this is not correct because my RAM config is as follows:
Speed: 1333 MHz
Bus width: 32bit
As per wikipedia, the theoretical bandwidth is calculated as follows:
clock speed * bus width * # bits per clock cycle per line (2 for ddr 3
ram) 1333 MHz * 32 * 2 ~= 8GB/sec.
So mine is completely different from the estimated bandwidth. Any idea of what am I doing wrong?
=========
Other question is, bcopy involves both read and write. So does it mean that I should divide the calculated bandwidth by two to get only the read or only the write bandwidth? I would like to confirm whether the bandwidth is just the inverse of latency? Please suggest any other ways of measuring the bandwidth.
I can't comment on the effectiveness of bcopy, but the most straightforward approach is the second method you stated (with a stride of 1). Additionally, you are confusing bits with bytes in your memory bandwidth equation. 32 bits = 4bytes. Modern computers use 64 bit wide memory buses. So your effective transfer rate (assuming DDR3 tech)
1333Mhz * 64bit/(8bits/byte) = 10666MB/s (also classified as PC3-10666)
The 1333Mhz already has the 2 transfer/clock factored in.
Check out the wiki page for more info: http://en.wikipedia.org/wiki/DDR3_SDRAM
Regarding your results, try again with the array access. Malloc 1GB and traverse the entire thing. You can sum each element of the array and print it out so your compiler doesn't think it's dead code.
Something like this:
double time;
int size = 1024*1024*1024;
int sum;
*char *array = (char*)malloc(size);
//start timer here
for(int i=0; i < size; i++)
sum += array[i];
//end timer
printf("time taken: %f \tsum is %d\n", time, sum);