0:00 What we did in 11.5 4:00 Test Nvs32 6:20 Compile and write some test code 14:05 Compile again 14:40 Fix some errors 20:45 Build and check results 38:30 Another build and test 44:50 Up Next and a heads up Thanks Simon!
Oh wow, good spot. Yeah it's parsed as ASCII text so the filename doesn't matter so far as the IDF caring. I shall fix in the next video though. Thanks for pointing it out
Not sure if my thinking is right but we want to use a custom partition table definition in partition_table.csv but it appears that we are using something else unless this is set up using menuconfig which by default on my system is as follows: # # Partition Table # CONFIG_PARTITION_TABLE_SINGLE_APP=y # CONFIG_PARTITION_TABLE_SINGLE_APP_LARGE is not set # CONFIG_PARTITION_TABLE_TWO_OTA is not set # CONFIG_PARTITION_TABLE_CUSTOM is not set CONFIG_PARTITION_TABLE_CUSTOM_FILENAME="partitions.csv" CONFIG_PARTITION_TABLE_FILENAME="partitions_singleapp.csv" CONFIG_PARTITION_TABLE_OFFSET=0x8000 CONFIG_PARTITION_TABLE_MD5=y # end of Partition Table And partitions_singleapp.csv is this: # Name, Type, SubType, Offset, Size, Flags # Note: if you have increased the bootloader size, make sure to update the offsets to avoid overlap nvs, data, nvs, , 0x6000, phy_init, data, phy, , 0x1000, factory, app, factory, , 1M,
From very first video about nvs I'm thinking if there's some convention about which method's implementation to put into .cpp files and which not. So I tried to implement these private methods in cpp file as it seemed right to me, but that did not work. Templates are doing something weird so that the same code behaves differently in cpp files) Anyways, I wanted to ask if we even need different interface methods for buffers? We could simplify interface by keeping only three methods which behave exactly as buffer methods, but have length defaulted to 1. Do we need to separate those methods for ordinary types just to get rid of explicitly taking variable's address?
This is a hotly debated topic when it comes to the embedded world specifically, mainly because there are two schools of thought. Templates Vs explicit functions. Explicit is probably easier to get your head around and for small code bases fairly easy to maintain. It's also most common and most documented, which is why I chose the other route so that has some love. I also prefer generic programming but it's all about choosing what's best for you. The big problem with templates, which you have stumbled upon, is the instantiation of templates. They are stamped out at the translation unit level; i.e. a *.cpp file. So if you declare a use of the template in one cpp but it is implemented in another cpp, you have a problem. The implementation cpp is a different translation unit and has no idea that your template is wanting to be used. There's better explanations out there, but that's why templates tend to implemented in headers, so the user declaration also gets the definition.
0:00 What we did in 11.5
4:00 Test Nvs32
6:20 Compile and write some test code
14:05 Compile again
14:40 Fix some errors
20:45 Build and check results
38:30 Another build and test
44:50 Up Next and a heads up
Thanks Simon!
Just noticed you have your partition table extension as .cvs as opposed to .csv
Since it works, I guess only the content needs to be in CSV format
Oh wow, good spot. Yeah it's parsed as ASCII text so the filename doesn't matter so far as the IDF caring. I shall fix in the next video though. Thanks for pointing it out
Not sure if my thinking is right but we want to use a custom partition table definition in partition_table.csv but it appears that we are using something else unless this is set up using menuconfig which by default on my system is as follows:
#
# Partition Table
#
CONFIG_PARTITION_TABLE_SINGLE_APP=y
# CONFIG_PARTITION_TABLE_SINGLE_APP_LARGE is not set
# CONFIG_PARTITION_TABLE_TWO_OTA is not set
# CONFIG_PARTITION_TABLE_CUSTOM is not set
CONFIG_PARTITION_TABLE_CUSTOM_FILENAME="partitions.csv"
CONFIG_PARTITION_TABLE_FILENAME="partitions_singleapp.csv"
CONFIG_PARTITION_TABLE_OFFSET=0x8000
CONFIG_PARTITION_TABLE_MD5=y
# end of Partition Table
And partitions_singleapp.csv is this:
# Name, Type, SubType, Offset, Size, Flags
# Note: if you have increased the bootloader size, make sure to update the offsets to avoid overlap
nvs, data, nvs, , 0x6000,
phy_init, data, phy, , 0x1000,
factory, app, factory, , 1M,
From very first video about nvs I'm thinking if there's some convention about which method's implementation to put into .cpp files and which not. So I tried to implement these private methods in cpp file as it seemed right to me, but that did not work. Templates are doing something weird so that the same code behaves differently in cpp files)
Anyways, I wanted to ask if we even need different interface methods for buffers? We could simplify interface by keeping only three methods which behave exactly as buffer methods, but have length defaulted to 1. Do we need to separate those methods for ordinary types just to get rid of explicitly taking variable's address?
This is a hotly debated topic when it comes to the embedded world specifically, mainly because there are two schools of thought. Templates Vs explicit functions.
Explicit is probably easier to get your head around and for small code bases fairly easy to maintain. It's also most common and most documented, which is why I chose the other route so that has some love. I also prefer generic programming but it's all about choosing what's best for you.
The big problem with templates, which you have stumbled upon, is the instantiation of templates. They are stamped out at the translation unit level; i.e. a *.cpp file. So if you declare a use of the template in one cpp but it is implemented in another cpp, you have a problem. The implementation cpp is a different translation unit and has no idea that your template is wanting to be used. There's better explanations out there, but that's why templates tend to implemented in headers, so the user declaration also gets the definition.