Please check if I've made any major logic errors that prevent the concept from working at all. I am stuck.
I got the idea last night that a lot of the Serial.Print messages we use to debug our code don't really need to run if the serial monitor isn't open. DEBUG_PRINT defines need access to the source code to debug. Sometimes I have a different computer without the source when troubleshooting in the field. I started adding a "diagnostic jumper" to my hardware so that I could easily trigger a spew of diagnostic data to a Serial port, but I often don't have a jumper on me. But a USB cable(phone charger) is always around, and teensy can check if(Serial) to know if it is connected.
So, I started writing monitorPrint(attached) till I came to the error 'monitorAvail' was not declared in this scope. I seem to get that error regardless of where I place its declaration.
Q1. Where should monitorAvail be declared in monitorPrint1file, or what else do I need to do to avoid this error?
Stalled, I thought this should really be a library with proper type checking. And I vaguely remembered that all the Serials, SPI, I2C, etc descended from Print or Stream, so it should be possible to make a generic library that could take a message, and send it through any available communications channel, including a null com channel.
So I set about writing that without a complete plan in place. I got quite far, before I actually tried to instantiate various Serial like objects, and store them in a Print* [] for use later. I understand that the transaction based protocols will require drivers to wrap the message in transaction and addressing code, but this is a first proof of concept test that failed. I get no matching function call, because its looking for Print & parameters and it is getting XBee& and EthernetClient&.
Oops. Probably should have tried compiling much sooner, but now I have lots of time in it, I've slept on it, and I don't see the solution.
Q2. Regarding comsManager: Please help me decide if the concept is fundamentally flawed, or if there are other ways to make it work.
Q3. What use cases do you see for this type of software? Hopefully it should go way beyond just saving cycles if the Serial Monitor is closed.(though, shamefully I still haven't tested that basic funcion.)
And let that be a warning about coding stream of consciousness vs making and following an outline. You might end up with nothing.
View attachment 11466 View attachment monitorPrint1file.ino
I got the idea last night that a lot of the Serial.Print messages we use to debug our code don't really need to run if the serial monitor isn't open. DEBUG_PRINT defines need access to the source code to debug. Sometimes I have a different computer without the source when troubleshooting in the field. I started adding a "diagnostic jumper" to my hardware so that I could easily trigger a spew of diagnostic data to a Serial port, but I often don't have a jumper on me. But a USB cable(phone charger) is always around, and teensy can check if(Serial) to know if it is connected.
So, I started writing monitorPrint(attached) till I came to the error 'monitorAvail' was not declared in this scope. I seem to get that error regardless of where I place its declaration.
Q1. Where should monitorAvail be declared in monitorPrint1file, or what else do I need to do to avoid this error?
Stalled, I thought this should really be a library with proper type checking. And I vaguely remembered that all the Serials, SPI, I2C, etc descended from Print or Stream, so it should be possible to make a generic library that could take a message, and send it through any available communications channel, including a null com channel.
So I set about writing that without a complete plan in place. I got quite far, before I actually tried to instantiate various Serial like objects, and store them in a Print* [] for use later. I understand that the transaction based protocols will require drivers to wrap the message in transaction and addressing code, but this is a first proof of concept test that failed. I get no matching function call, because its looking for Print & parameters and it is getting XBee& and EthernetClient&.
Oops. Probably should have tried compiling much sooner, but now I have lots of time in it, I've slept on it, and I don't see the solution.
Q2. Regarding comsManager: Please help me decide if the concept is fundamentally flawed, or if there are other ways to make it work.
Q3. What use cases do you see for this type of software? Hopefully it should go way beyond just saving cycles if the Serial Monitor is closed.(though, shamefully I still haven't tested that basic funcion.)
And let that be a warning about coding stream of consciousness vs making and following an outline. You might end up with nothing.
View attachment 11466 View attachment monitorPrint1file.ino
Attachments
Last edited: