micro-os-plus/micro-os-plus-iii

Cannot create message_queue for types smaller than words

Opened this issue · 3 comments

LnnrtS commented

message_queue_inclusive<uint32_t,50> testBuffer;
works

message_queue_inclusive<uint8_t,50> testBuffer;
fails with

assertion "queue_size_bytes_ >= storage_size" failed

Probably something wrong with the alignment calculation in compute_allocated_size_bytes..?

ilg-ul commented

Negative, there is nothing wrong with the alignment calculation, by design, for efficiency reasons, the queue elements cannot be shorter than a certain limit.

(The technical reason is that, in order for the list of free messages to not consume additional memory, the pointers are stored at the beginning of the messages, thus messages should be large enough to fit a pointer).

LnnrtS commented

I would still consider this a bug because an implicit compile-time requirement is not checked and ends up in a runtime error. Adding a static_assert would make life a bit easier.

Also I found that using queue sizes of more than 128 or 256 failed in a similar manner. Didn't investigate this further. I guess there exists another limitation of (a combination of) queue size and element size. If that was the case, a compile-time check would also be usefui for it.

ilg-ul commented

I would still consider this a bug because an implicit compile-time requirement is not checked and ends up in a runtime error. Adding a static_assert would make life a bit easier.

Ah, right, the missing compile-time check is a bug.

And since this is a separate problem, please enter a separate issue for it. And, given that you obviously have a deep knowledge of modern C++, please suggest a fix, possibly as a PR.

queue sizes of more than 128 or 256 failed in a similar manner

I would appreciate if you could further investigate, and, if necessary, enter new issues, as mentioned before.

Actually I highly appreciate your contributions and I'd be very happy if you would consider further improvements to this project.

I'm committed on returning to it, just that now I'm still busy with preparing some of the tools that I plan to use during development, and this will probably take some more time. I've just released xPack binaries with CMake, meson and ninja, and a few more changes are planned for the xpm tool.

So, if you are interested, welcome aboard!