Interactions with Teensy USB Stack

[red-sand-robot]

This isn't an issue per se, but I was curious on if there are any considerations with using AceRoutine and implementing a custom USB HID device. The custom USB device USB code is essentially identical to the Joystick implementation.

I have a few coroutines gathering data, and one coroutine calling the lower-level function to place that data in the USB buffer to be collected during a polling interval (function is almost identical to the Joystick.send() function example provided with Teensyduino).

When those lower-level functions execute, my assumption is that those will run to completion, instead of the switching that happens during running the main loop with the coroutines, and then once those have completed and returned to the main loop the context switching will resume. Is this a correct assumption, or is my example not clear enough for you to answer this question?

[bxparks]

I'm not familiar with Teensy's USB stack. When you say "the Joystick", I assume you mean this: https://www.pjrc.com/teensy/td_joystick.html ? And by Joystick.send(), I think you mean Joystick.send_now()? So I'm not sure I understand what you are trying to do, but I think you are asking the following: If an AceRoutine coroutine calls a low-level function like Joystick.send_now(), does send_now() run to completion, or does it get interrupted? The answer is that AceRoutine is a cooperative multitasking library, not a preemptive multitasking library. Any function called from a coroutine will not be preempted, at least not by anything in the AceRoutine library, because AceRoutine does not use interrupts. You have to explicitly call one of the macros that explicitly yields control (e.g. COROUTINE_YIELD() or COROUTINE_DELAY()). Since the lower-level routines don't know anything about AceRoutine, they will not be preempted. Does that answer your question? If not, you might have to send me some sample code to explain in more details.

[red-sand-robot]

I am working on a custom USB HID device that appears to a PC as a gamepad, and only has a 14byte report size. I have had no problems with that part (custom device descripter/report descriptor, etc). This has been working, both with and without the AceRoutine library. I want to ensure that during operation there is little to no chance calling a function like Joystick.send_now(); inside a coroutine could cause the program to hang, it should just execute and return back to the coroutine.

(and yes, by Joystick I meant https://www.pjrc.com/teensy/td_joystick.html)

I have successfully used AceRoutine to split up gathering data and placing it in an array (like the function Joystick.Y(analogRead(1)); ) and calling a function which initiates the transmitting of USB packets (like Joystick.send_now();).

If I understand your answer correctly, when a function like Joystick.send_now() is called, it is not interrupted, and will run to completion. Once it has returned back to the coroutine, then COROUTINE_YIELD() or COROUTINE_DELAY() are the only ways to explicitly cause the coroutine to switch over to a different coroutine. Is that correct?

I can send some sample code using the Teensy USB Joystick example if you don't mind taking a look at the lower level USB stack. I have made (minimal) changes to some of the USB files so it would be inconvenient for you to use those, but it would be very easy for me to recreate my main code using the Teensy USB Joystick example.

[bxparks]

Yes, Joystick.send_now() will not be interrupted by AceRoutine, because AceRoutine does not use interrupts. I also notice that all the various usb_serial_class::send_now() methods in hardware/teensy/avr/cores/usb_*/usb_api.cpp already disable interrupts.

You can probably just upload your code to a GitHub repo and send me the link. I can take a look at the stuff involving AceRoutine. I don't know much about USB code so probably won't have much to add.