Is your feature request related to a problem? Please describe.
When testing and debugging sketches, there have been cases when certain devices fail to reinitialize or stop working during runtime. When running sketches that utilize Loom sleep, diagnosing and exploring the factors which contribute to problems become much more opaque. We can only rely on the LED to ensure the code is running or look into SD logged data (if SD is being used and isn't the component which is misbehaving). Otherwise, we cannot properly debug issues without some extensive efforts.
Describe the solution you'd like
The solution to this would be to ensure that serial communication gets reattached and reinitialized upon waking up from sleep. The exact reason this doesn't happen already isn't exactly clear.
Describe alternatives you've considered
There aren't really any alternatives to seeing this sort of output, other than the aforementioned use of SD logging to determine how well the device is functioning. Once again, this is not an effective alternative in the case that SD logging in particular isn't working well with sleep, which has occurred before when running code on Loom.
Additional context
I have heard that Loom used to have this functionality, but no longer does. Upon exploring past Loom versions, I have discovered that Sleepmanager::post_sleep() used to include a function call to USBDevice.detach() that was removed by Noah Koontz. Adding the line back now causes a hard fault. According to Noah, he does not remember why he removed this line, and doesn't know why it would cause a hard fault. I have also attempted to add other function calls like USBDevice.begin() and Seria.begin() along with a delay() to wait for reopening Serial. Further investigation will probably be required to identify why these USBDevice methods don't work.
Is your feature request related to a problem? Please describe. When testing and debugging sketches, there have been cases when certain devices fail to reinitialize or stop working during runtime. When running sketches that utilize Loom sleep, diagnosing and exploring the factors which contribute to problems become much more opaque. We can only rely on the LED to ensure the code is running or look into SD logged data (if SD is being used and isn't the component which is misbehaving). Otherwise, we cannot properly debug issues without some extensive efforts.
Describe the solution you'd like The solution to this would be to ensure that serial communication gets reattached and reinitialized upon waking up from sleep. The exact reason this doesn't happen already isn't exactly clear.
Describe alternatives you've considered There aren't really any alternatives to seeing this sort of output, other than the aforementioned use of SD logging to determine how well the device is functioning. Once again, this is not an effective alternative in the case that SD logging in particular isn't working well with sleep, which has occurred before when running code on Loom.
Additional context I have heard that Loom used to have this functionality, but no longer does. Upon exploring past Loom versions, I have discovered that Sleepmanager::post_sleep() used to include a function call to USBDevice.detach() that was removed by Noah Koontz. Adding the line back now causes a hard fault. According to Noah, he does not remember why he removed this line, and doesn't know why it would cause a hard fault. I have also attempted to add other function calls like USBDevice.begin() and Seria.begin() along with a delay() to wait for reopening Serial. Further investigation will probably be required to identify why these USBDevice methods don't work.