Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 5 of 5

Thread: Print descendents, scope issue, comsManager

  1. #1

    Print descendents, scope issue, comsManager

    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.
    Attachment 11466 monitorPrint1file.ino
    Attached Files Attached Files
    Last edited by slomobile; 09-04-2017 at 11:51 PM.

  2. #2
    I just realized much of the functionality of monitorPrint1file.ino can be summed up as
    if(Serial)Serial.print("Something, something... Dark Siiide");
    It is now stalled at :
    monitorPrint1file:33: error: no matching function for call to 'ILI9341_t3::write(char [64], int&)'
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\ILI934 1_t3/ILI9341_t3.h:264:17: note: candidate expects 1 argument, 2 provided
    no matching function for call to 'ILI9341_t3::write(char [64], int&)'

    I found silly mistakes in comsManagerExample.zip Forgot to #include <Arduino.h> in emptyCom.h, so added that, commented out the line that was triggering the error just to get past it, and declared emptyCom extern and it compiles now.

    So, back to work I go. Questions of usefulness remain.
    Last edited by slomobile; 09-04-2017 at 11:47 PM.

  3. #3

    Angry Xbee as Print *

    So far, every com type(my term for Serial, Ethernet, SD, i2c, SPI, SD, various displays, etc.) which I tried, can be stored in a Print* except SerialFlash and Xbee. The Xbee library is different from the others because instead of inheriting from Print like the other libraries, including my EmptyCom
    Code:
    class EmptyCom : public Print
    {      ...                    };
    it stands alone, but gains access to a serial object through parameters, just like ComsManager does. That makes it an example I can follow, but does throw a wrench into the works. BTW Stream inherits from Print, so any Stream object is also a Print object.
    Code:
    class XBee {
    void begin(Stream &serial);
    void setSerial(Stream &serial);
    private:
    	bool available();
    	uint8_t read();
    	void flush();
    	void write(uint8_t val);
    	void sendByte(uint8_t b, bool escape);	
    	// buffer for incoming RX packets.  holds only the api specific frame data, starting after the api id byte and prior to checksum
    	uint8_t _responseFrameData[MAX_FRAME_DATA_SIZE];
    	Stream* _serial;
     ...  }
    But then it implements the same functions as Print's and Stream's virtual functions, so it should be possible to rework the Xbee library so the Xbee object inherits from Stream. It remains to be seen if that can be done without breaking existing Xbee code that uses the library. Is there a way to promote the Serial object passed in Xbee.begin or Xbee.setserial, to the self same Xbee object?
    or
    Is there a different way to bring Xbee and SerialFlash into the fold?

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,711
    Quote Originally Posted by slomobile View Post
    Is there a different way to bring Xbee and SerialFlash into the fold?
    You'll probably need to ask Andrew Rapp, the author of XBee. But I wouldn't expect much. He wrote it a long time ago and it's been stable (or "frozen") for quite a long time.

    SerialFlash is my fault. This is one of several things on my to-do list for SerialFlash. I actually have a small pile of newer chips to test and support too. But it's been a lower priority than many other things, and probably will continue to be for months. Sorry, there's just so many important things to do on other libs and documentation.

  5. #5
    Thanks Paul. Don't feel rushed to update SerialFlash on my account, I'm not in any hurry. When I asked if there was a way to "bring Xbee and SerialFlash into the fold" I was unclear. I was looking for a code technique to store(in the same array), and use the instances in a similar way to the Serial objects. I've just heard of "conversion constructors", but am still a bit fuzzy on how they work, or how to implement them in this case. Since I already have EmptyCom included, it would make a handy wrapper class.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •