Associative arrays on a Boron, or other solution?

Tags: #<Tag:0x00007fe22bdbb798>


I think maybe I’ve been staring at the glowing box for too long, overthinking a problem, but maybe someone out there has an idea for me:

In short, I have sensors that send their data over serial in the format of:
abcd, int idNumber, int data1, int data2; abcd is ignore-able.

Easy to parse out the id, data1 and data2, but what I need is to store them as variables that update whenever new data comes in. Catch: idNumber is a 6 digit code from the sensor supplier that I don’t control, and sensors will come and go at random so I can’t declare that somewhere as a variable…maybe.


  • associative array/hashmap myArray[“idNumber”] = {data1, data2}, except I can’t seem to find such a thing for boron? Get all kinds of errors when trying something like std::map<std::string, int, std::less<std::string>> myArray; . Pairs of not-multidimensional arrays instead of one to rule them all.
  • int myArray[999999]; and just have a pantload of null rows. Boron seems to crash even if the compiler says it’s ok, which I don’t think is surprising.***
  • create a variable name on the fly: what a horrible old perl trick that even perl coders cringe at, but if it were possible I might get to go home, even if I wouldn’t sleep too soundly for a night or two…


*** this actually works at some scale, but then I need a version of “retrieve only the populated ones” later on, and sorting/iterating through a giant array sounds like a bad idea


Hey @wileecoyoti since your question poses a learning opportunity I decided to start implementing a data structure that makes it easy to store sensor events with (idNumber, data1, data2) and then retrieve events given the idNumber.

The library works, but I need to provide more test cases and documentation. There’s probably other solutions out there, but for your application I think a data structure like the one I’ve implemented could be useful.


Another idea that I have used is EDB

Its is a simple record based database then can run in EEPROM or SD and using a simple lookup and update function, it should work for this use case. It is only limited by size of the storage space. On an SD with an Argon I can search about 10K records a second with the data record being a simple struct.