1. FatFS uses wear-leveling which means it will alternate between different parts of the flash to reduce the wear of the flash so you can't manually pre-erase the sectors afaik. This is something you have to consider if you opt not to use FatFS.
2. Like I wrote in my previous post - use a queue to store the values from the interrupt, then store them to flash in another task on another core.
Fatfs delay at write at new sector
Re: Fatfs delay at write at new sector
OK. My interrupt continues during flash operations with ESP_INTR_FLAG_IRAM and issues an xSemaphoreGiveFromISR, but the interrupt handler task with xSemaphoreTake does not work (does not handle events) during the preparation of a new flash page.
1. How do I assign the first kernel to handle a task with xSemaphoreTake?
2. How to assign the second core to execute the task write the flash?
Will this work?
1. How do I assign the first kernel to handle a task with xSemaphoreTake?
2. How to assign the second core to execute the task write the flash?
Will this work?
Re: Fatfs delay at write at new sector
I have to allocate write operation in a flash in a separate task on a separate kernel. All other calculations, semaphore processing from the interrupt, and Queuing can be left to work on two cores?permal wrote: ↑Sat Dec 15, 2018 11:17 am1. FatFS uses wear-leveling which means it will alternate between different parts of the flash to reduce the wear of the flash so you can't manually pre-erase the sectors afaik. This is something you have to consider if you opt not to use FatFS.
2. Like I wrote in my previous post - use a queue to store the values from the interrupt, then store them to flash in another task on another core.
OK. My interrupt continues during flash operations and issues an xSemaphoreGiveFromISR, but the interrupt handler task with xSemaphoreTake does not work (does not handle events) during the preparation of a new flash page. Although I have allocated a separate kernel to write to the flash.
What did I do wrong?
Re: Fatfs delay at write at new sector
I hope I will communicate the decision and it will be useful to someone 
No division of tasks on different CPU cores did not help. Interrupts continued to occur, but the interrupt handler did not handle events of about 50 MS
My decision hangs the entire system when the page is created fatfs was the removal of fatfs from my project. I organized 10 storage partitions of 2 MB each (my chip have 32 mb). Consistently write log file in these sections, when all are busy starting from the first. Thus minimizing the wear on the flash. In fact, I plan that the log will be recorded less than 1000 times, that is, 100 overwrites in each partition.
I act so:
1. Erase the entire partition with the command
esp_partition_erase_range()
2. I write blocks on 64 bytes (such at me the size of a line of a log)
esp_partition_write()
There are no problems with the hang-up anymore.
I also had to make some semblance of the file system to output the logged information from the flash to the user via http request
No division of tasks on different CPU cores did not help. Interrupts continued to occur, but the interrupt handler did not handle events of about 50 MS
My decision hangs the entire system when the page is created fatfs was the removal of fatfs from my project. I organized 10 storage partitions of 2 MB each (my chip have 32 mb). Consistently write log file in these sections, when all are busy starting from the first. Thus minimizing the wear on the flash. In fact, I plan that the log will be recorded less than 1000 times, that is, 100 overwrites in each partition.
I act so:
1. Erase the entire partition with the command
esp_partition_erase_range()
2. I write blocks on 64 bytes (such at me the size of a line of a log)
esp_partition_write()
There are no problems with the hang-up anymore.
I also had to make some semblance of the file system to output the logged information from the flash to the user via http request
Who is online
Users browsing this forum: Majestic-12 [Bot] and 148 guests