I have recently started learning and implementing freeRTOS on a DSPIC33FJ64MC802. One of the reuirements of my project involves saving a few variables on the dsPIC itself so even after a power cycle the values of those variables are still there on the controller. In XC16 compiler in MPLAB X IDE there is a library to which uses the flash memory on the controller and saves the variable value in it. I would like to know if there is any way to do a similar functionality using the dsPIC on the same controller. Currently I donot have an external SPI EEPROM connected to the controller. If using an external storage is the only way could anyone guide me how to use it from a software perspective.
This question seems to relate to the specifics of your microcontroller and board design, rather than FreeRTOS.
I’m confused by this as would imagine you were using the XC16 on your dsPIC, so if X16 provides a library for writing to flash then that would seem to be what you want. Otherwise you are going to have to write your own functions for writing to the flash, which would need some understanding of the part’s datasheet - unless you have external storage, battery backed RAM, etc.
Thank you so much for replying back. I apologize for the confusion here. The idea here was to use the freeRTOS on the dsPIC instead of the default. So i was trying to see if there was a way to save the serial number of the dsPIC itself. That way even when the power is removed after powering on the serial number will be available. Based on the datasheet of the controller it looks like there is not a EEPROM on the controller itself but it can be emulated by saving the variable to the flash memory. Is there any function built in to FreeRTOS that can write and read from the flash memory on the controller itself?
FreeRTOS itself is very device independent, and has just a small bit of code in the portable files that contain the needed device specific code. Int basically contains NO I/O code, like serial ports or flash controllers.
It may be possible to use the vender library directly, or it might need some small modifications (maybe just a mutex wrapper to avoid trying to program two different locations at the same time), maybe if it has some longer delays, those might work as calls to vTaskDelay (but most flash delays are shorter than that).