Embedded Tool Kit is a header-only C++ library for doing fundamental 'stuff' on microcontrollers. It covers things like strings, maths, container objects, memory pools, functions for unit conversions and so on. Originally it was written specifically for STM32 chips using the c++14 standard. I've now ported it to Arduino (and c++11) and I can compile various examples but I don't have any AVR boards to test it. So if anyone is interested in trying it, that would be awesome.
Several years ago I wrote a maths library specifically for doing IMU related work and I called it IMUMaths. Adafruit picked up an old copy and bundled it with their BNO055 library, but I actually merged IMUMaths into ETK a while ago.
void setup() {
Serial.begin(57600);
}
void loop() {
etk::List<int, 10> list;
for(auto i : etk::range(15, 20))
list.append(i);
auto len = list.size(); //five items have been added, size is 5
list.insert(11, 2); //inserts 11 at position 2
etk::StaticString<128> ss;
for(auto& i : list) {
ss += i;
ss += " ";
}
Serial.print(ss.c_str());
delay(100);
}
From a brief look at your documentation link your toolkit seems to be a mix of things that could be useful for many (such as Rope and LinkedList and RingBuffer and other stuff that is very esoteric (i.e. means nothing to me ) such as BrownLinearExpo.
I wonder would there be value in dividing your library into two parts one aimed at "regular" Arduino users and the other with the more specialized functions.
From a brief look at your documentation link your toolkit seems to be a mix of things that could be useful for many (such as Rope and LinkedList and RingBuffer and other stuff that is very esoteric (i.e. means nothing to me ) such as BrownLinearExpo.
I wonder would there be value in dividing your library into two parts one aimed at "regular" Arduino users and the other with the more specialized functions.
...R
Hi Robin2, thanks for having a look. I have thought about reducing the scope of ETK because it is a bit poorly defined at the moment. It could be reduced down to strings, maths, containers and memory. The problem is, there's several downstream projects that would be severely broken if I change too much now.
At the end of the day, there's absolutely no harm in using only the parts that you need.
Camel:
At the end of the day, there's absolutely no harm in using only the parts that you need.
I am aware of that.
I was thinking more about how you would "market" it to a wider audience. My instinct is that it now appears too complex for newbies even though parts could be useful for them.
Maybe you could have an "expert" version and a "newbie" version - obviously with a different library name to avoid confusion.
I was thinking more about how you would "market" it to a wider audience. My instinct is that it now appears too complex for newbies even though parts could be useful for them.
Maybe you could have an "expert" version and a "newbie" version - obviously with a different library name to avoid confusion.
...R
I hear what you are saying. But I think experience level is irrelevant. People who may consider using this library are those who are interesting in getting things right the first time, as opposed to those who have set out to tinker and roll their own bug riddled libraries. I don't mean to be condecending but doing low-level memory allocators and container objects is hard. It's taken a lot of work to get everything in ETK to its current state and it still could be more efficient, more useable, etc. I would suggest "newbies" who are mainly interested in making something work reliably, could benefit from using ETK. They face a learning curve regardless.
Experienced coders may consider using ETK or parts of it because they understand how it makes writing high integrity code easy, how it saves time and that it is MIT licensed. Experienced coders might also find bugs, make improvements or submit new code . . .
Camel:
I hear what you are saying. But I think experience level is irrelevant. People who may consider using this library are those who are interesting in getting things right the first time, as opposed to those who have set out to tinker and roll their own bug riddled libraries.
I guess I have not been explaining myself clearly.
IMHO many newbies who could benefit from the library will be frightened away from it by the various very specialized functions it contains. Newbies don't know enough to know what they need to "get things right the first time".
As it stands I would not recommend it to a newbie because it would almost certainly give rise to more questions than answers. But if there is was a cut-down version that just contained the functions that regular users would benefit from I can see myself recommending that.
Anyway - I have said my piece. There is absolutely nothing wrong with writing a specialized library for use by a minority of Arduino users.
Robin2:
I guess I have not been explaining myself clearly.
IMHO many newbies who could benefit from the library will be frightened away from it by the various very specialized functions it contains. Newbies don't know enough to know what they need to "get things right the first time".
As it stands I would not recommend it to a newbie because it would almost certainly give rise to more questions than answers. But if there is was a cut-down version that just contained the functions that regular users would benefit from I can see myself recommending that.
Anyway - I have said my piece. There is absolutely nothing wrong with writing a specialized library for use by a minority of Arduino users.
...R
If I were to scope ETK as 'a collection of libraries are intended to be widely useful, and usable across a broad spectrum of embedded applications', what parts would you cut out? You already mentioned a filter class, maybe all signal processing related classes should go?
Camel:
If I were to scope ETK as 'a collection of libraries are intended to be widely useful, and usable across a broad spectrum of embedded applications', what parts would you cut out? You already mentioned a filter class, maybe all signal processing related classes should go?
I think I would start from the other end. What are the things that newbies have a problem with? Those are the things to include. The ones that jumped out at me are Rope and LinkedList and RingBuffer. And I would put RingBuffer before LinkedList.
Another idea is that those functions have to do with manipulating data in memory, whereas some of your other functions have to do with what I will loosely call "statistics". For all I know your functions may fall naturally into 3 or 4 groups and could therefor make 3 or 4 libraries with names that indicate their purpose.
For example a library with Rope, RingBuffer and LinkedList (plus other closely related functions) might be called DataManagementTools or DMT. This is only a suggestion to illustrate what is in my mind - you may think of a much more sensible and meaningful name - meaningful to newbies, of course.
And there would be nothing wrong with some of the libraries depending on any of the others - except the "beginner" library.
) such as BrownLinearExpo.