TM4C1294NCPDT: Manage device configurations

Norbert,

I particularly despise "dynamic" structured protocols like JSON, I believe they are a waste of space and bandwidth and should be banished - at least by GreenPeace supporters, for the hack of saving the planet from unnecessary energy consumption!

EEPROM is even more delicate for these, because it is very difficult to control the actual length of all your stored content - EEPROM inside the TM4C is relatively small, and also "not eternal", so if you need frequent writing on EEPROM, you should have some kind of rotation so not to write always on the same location - even harder with unpredictable dynamic content.

Of course, I assume that you are looking for some sort of generic storage. But my suggestion is: can't you pre-define what you are going to store, and simply use a fixed structure to save these values?

After some years, we eventually came down to two different sets:

- One is common to any project in the company, and contains information such as serial number, total amount of seconds used, total number of sessions, etc... All products consume a fixed memory size for these basic info.

- The other set is "product-specific", and have a well documented storage sequence, using a struct something like:
{
FLOAT PID1_CALIBRATION;
FLOAT PID2_CALIBRATION;
INT32 TEMP1_ALARM;
}

If you create a neat framework, is very easy and fast to create new products, read/write/transport these settings between devices. When a new item is required for an existing product, the new entry is added after the existing ones, so that current eeprom values are still valid on their existing locations.

Anyway, just a few thoughts. JSON based, to me, is for unlimited storage and bandwidth situations...

Cheers

Bruno

Hi Bruno,
We are grateful to have people like you and others (can't name them all here...) with extensive experiences in the industry in the fourm who can answer questions sometimes TIers don't have experience with. I was just Googling what BSON and JSON are. :-)

Hi Nobert,
Sorry for my lack of experience in in these two different formats. I found the below link that compares between BSON and JSON formats. As indicated by Bruno the JSON takes up much more space than BSON format. Considering the limited size of the EEPROM it is wise to go with smaller format but how that will impact the efficiency of retrieving the data and manipulation of the data I can't really comment.

stackoverflow.com/.../compare-json-and-bson

Hi All,

I don't want to use JSON on the controller itself: it is indented to be an input format (and it was only an example) that can be edited manually, or can be produced a web-service or even a desktop application, and this can be used to generate binary data stored in the EEPROM on the MCU site.

My issue is that these properties could change from product to product and we want to avoid an own developed binary protocol. That s the reason while I am looking for possible solution. We already have an application that can read such files, like XML or JSON, serialize them into binary stream, which is ready to download to the EEPROM and beside of this, generate C++ classes, that can be instantiated and access properties described above. Just an example (they may be much more pseudo codes than valid sources):

The input JSON describes, a property with value

{MaxSpeed: 2000}

The generated binary locates in the EEPROM with offset X

And the serializer generate C++ class beside of the binary, like this:

class Controller {
public:
unsigned int MaxSpeed() const {
return ReadIntEEPROM(X);
}
private: 
int startAddress;
}

Please note that the offset is generated into the code. Than this classes are added to our project...  So my intention is to reduce this huge amount of work that need to maintain such a development even if we lost some performance, because these operations are used during startup.

And once again, mention of BSON and JSON was only example

Regards,

Norbert

Norbert,

Let me see if I got this right now: you are just discussing a method to transport structured data between an external device (such as a PC), and your TM4C, is that it? And the EEPROM storage part is something that you will handle separately inside the controller, is it?

Well, we do use our own binary protocol - time and pain convinced us it was needed.

For that transfer, you can probably use some sort of JSON code available in C. I don't have a lot of experience in porting generic C code into the MCU's world, particularly things like this, which will certainly require managing buffers... But it may be easier than implementing your own serial protocol on the PC/other-device end...

When we "created our own", we looked for probably what you are seeking now - and the solutions all seemed similar and non-standard... I honestly don't know if there is one. For example, TI uses one protocol for controlling the bootloader transfers, and that one also does not seem to respect any form of "universal rule".

Either way, consider that, even with guys like JSON, you may want to include some sort of checksum on the binary transmission itself, otherwise you are never sure that the full 1762 bytes arrived properly into the MCU.

Bruno