✨ FreeRtos queue wrapper class

[Rocky14683]

Summary:

A wrapper class for freertos queue

Motivation:

Idk whether this should be in kernel, but this is very useful. For example, odometry and controller system.

Test Plan:

• test 1->

• multiple queues
• multiple tasks and queues interaction

[djava]

Motivation? What usecase does std::queue not cover? I think the built-in vendor-provided queues are probably more designed to be used in cases where you don't have dynamic allocation, which does not apply for the V5.

[Rocky14683]

Freertos queue receive will block current task until data got send into the queue.

[Rocky14683]

It is mainly for the data sharing between 2(or multiple? Im not sure abot this) tasks.

[ion098]

Freertos queue receive will block current task until data got send into the queue.

A thread safe queue class based on std::queue with this feature should also be possible, and would allow users to not worry about max queue size.

Also, it looks like the changes from your other PR #690 accidentally got added in this PR as well, you should probably fix that.

[ion098]

Also this class won't work properly for types that have non trivial copy constructors (and I don't think there's any easy way of fixing that because of how the C API works).

[Rocky14683]

I think that is not an issue because it's for passing data. It's not for passing complex objects. Also, the thread safe queue will work, but that shouldn't be in kernel.

[Rocky14683]

I'm not going to use static assert, it does not work well with intellisense. I'll use concept.

[ion098]

Suggested change

	pros::c::queue_delete(queue);
	if (!deleted) {
	pros::c::queue_delete(queue);
	deleted = true;
	}

[djava]

I think that is not an issue because it's for passing data. It's not for passing complex objects.

Strongly disagree, if we have a type template in C++ then it should work with C++ types. We can add a type constraint for trivially_constructible but at that point, wouldn't you rather just have something that actually works with everything? I don't see the point when it's strictly worse than another option.

Also, the thread safe queue will work, but that shouldn't be in kernel.

Then why is this? This is just a worse version of that.

[Rocky14683]

Bcuz freertos queue is already in kernal(apix.h), I just wrap it with a class, it's easier to use.

[djava]

I just don't really think we should be encouraging using something that's not really worth using by making it easier? Who is this for? There's a reason its in apix.