Go Down

Topic: Embedded Tool Kit (Read 3849 times) previous topic - next topic

Camel

Interesting idea.

I wonder if the likelihood of of your code being used would be increased by putting like-minded code into separate Toolkits rather than having a large mixed bag.

...R
I've been wondering that myself, actually. The thing is, there's a fair amount of interdependence through ETK. Breaking it into separate toolkits would introduce dependency headaches. Having it all bundled together makes that a non-issue. Perhaps putting more work into documentation would be the way to go. There'd be sections for container objects, string manipulation, mathematics, control theory, signal processing and so on. What do you think about that?

Camel


Robin2

Perhaps putting more work into documentation would be the way to go. There'd be sections for container objects, string manipulation, mathematics, control theory, signal processing and so on. What do you think about that?
I think I lost a reply I had drafted last Friday and, between one thing and another I had forgotten.

Compartmentalising the documentation could go a long way to making it more accessible to less-experienced users. For example a beginner might find the Bits class useful but scalarLinearKalman scares me :)

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Camel

EvoPid auto-tuning PID controller explanation and example code as promised.

LINK

ETK actually won't compile as-is for AVR chips. It uses C++14 language features and I don't think the AVR compiler supports that yet. The latest g++-4.9 for ARM does so in theory it could compile for the Arduino Due. The Arduino IDE only supports C++11 for the Due so far, though.

It'd be a lot easier to port to C++11 than C++98, so the Due is viable but I'm not going to do that. Arduino should upgrade compilers to and pass -std=c++14  :smiley-razz:

Camel

#19
Dec 28, 2015, 06:52 am Last Edit: Dec 28, 2015, 06:57 am by Camel
So I've been fiddling with path finding algorithms for a robotics project lately and it seems the vast majority of these algorithms require tree-like data structures. You can't easily do that without using dynamic memory and pointers and whatnot. Admittedly, tree structures generally use nodes that are all the same size, so they're not a huge heap fragmentation risk. But for the sake of keeping ETK on the straight and narrow I decided to see how trees could be implemented WITHOUT new/delete.

What I came up with is etk::ObjPool. ObjPool is a memory pool class that can only allocate one type of object. The allocation function, ObjPool::alloc(), calls the constructor for the object and returns a 'pool pointer' which is a reference counting smart pointer. When all pool pointers to an allocated object are destroyed, the objects destructor is called and it's memory is returned to the pool.

It's impossible for an ObjPool to cause memory fragmentation, and it's impossible (at least, very difficult) for an ObjPool to leak memory. So it's a pretty good option if you need to implement trees or linked lists on a micro-controller or embedded device.

The downside of course is that memory pools nearly always use more memory than they need, and if they run out of memory they cannot just grab some more. Choosing the size of the pool could be tricky and any coding using it should be able to recover from allocation failures.

In some circumstances smart pointers might a overkill for a memory pool, especially if it's declared on the stack since the entire pool would get cleaned up anyway. If memory management isn't required and you wish to avoid the overhead of 'pool pointers', ObjPool has a raw_alloc function that allocates and returns a regular C pointer. If you need to, you can free the pointer using ObjPool::free. Note that ObjPool::raw_alloc and ObjPool::free do NOT call constructors or destructors and you would need to use placement new/delete instead.

This is all new code, so if anyone could run their eyes over it I'd be very grateful.

objpool.h
linked list example


Robin2

I've noticed in a few Threads that you have posted links to your StaticString class. Does that mean you have extracted that as a separate item?

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Camel

#21
Dec 28, 2015, 11:15 am Last Edit: Dec 28, 2015, 11:29 am by Camel
I've noticed in a few Threads that you have posted links to your StaticString class. Does that mean you have extracted that as a separate item?

...R
Yeah actually. Hopefully I haven't been spamming about it too much.  :D It just seems nearly every second thread is about string related problems that could easily be solved using the etk string classes.

I have ported and will be maintaining an Arduino port of the string classes from ETK. I've been calling this the StaticString library, but it also includes the string tokeniser and the Rope class.


Robin2

Yeah actually. Hopefully I haven't been spamming about it too much. 
I think it is a good idea.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Go Up