• State Verified Answer
  • Date
    KCrayn
  • Date
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 86 subscribers
  • Views 6144 views
  • Users 0 members are here

Arduino Lighthack for Softkeys

Hi all, I'm trying to modify the Lighthack code on the ETCLabs Github page to make some physical softkeys, and use the display to label them. I'm pretty new to arduino but have some programming knowledge from doing engineering at uni (mainly Matlab). I'm getting hung up on parsing the OSC messages from the console. The original code is:

 

void parsePanUpdate(OSCMessage& msg, int addressOffset)
{
panWheel.pos = msg.getOSCData(0)->getFloat();
updateDisplay = true;
}

 

The softkey labels are strings not floats, and I'm not sure how to go about adapting this code, to put the softkey label into a string. I'm not using the encoder structs, just simply strings, which are global vars, to store the labels, which get printed to the LCD display.

There is a getString method, but I'm not sure how to go about using it.

 

Any help would be greatly appreciated.

Cheers

Parents
  • +1

    Here a small code snippet for parsing string data, instead of the Pan/Tilt Update:

    String data;

    void parseData(OSCMessage& msg, int addressOffset) {
      char txt[128];
      int length = msg.getDataLength(0);
      msg.getString(0, txt, length);
      data = String(txt);
      displayStatus = true;
      }

  • 0 in reply to sstaub
    The above will crash out if the string is longer than 128 characters (including terminating null)
    Better:
    void parseData(OSCMessage& msg, int addressOffset) {
    char txt[128];
    int length = msg.getDataLength(0);
    if (length > 128) length = 128;
    msg.getString(0, txt, length);
    data = String(txt);
    displayStatus = true;
    }

    (The limit might be 127 instead of 128, I forget whether msg.getString() adds a terminating null or not)
  • 0 in reply to Richard
    Yes, there are many unexpected buffer overflows in conjunction with receiving long strings and also with other interrupt based I2C and SPI interfaces. Maybe that is a problem of the ring buffer for usb on Arduino UNO. I have no problems with using Arduino Micro board which have an native usb port (ATMega32u4) with it's own buffer. General, using dynamic storage allocation (used by OSC and Arduino String libraries) is not the right way on this small micro controller, which causes many unexpected buffer overflows and crashes.
  • 0 in reply to sstaub

    The above code allocates a fixed-size buffer of exactly 128 bytes, and will therefore crash if trying to put more than 128 bytes into the buffer.
    It doesn't matter what else is going on unless you can already guarantee that getString can never return more than 128 bytes.

    Alternatively, you can find out the required size first and then allocate an appropriate buffer.

    However, it's unlikely you'd ever want more than 33 bytes anyway, as the display can only show 32 characters (at once).
    - Arduino doesn't have much RAM so there isn't much point in keeping more than you need :)

  • 0 in reply to Richard
    You are right when talking about that short code snippet. But when you look in the main loop there is an object creation static String curMsg; which is a dynamic allocated object. I think this is one of the problems for a crash.
  • 0 in reply to Richard

    Another problem for the classic Arduino's like UNO is that the UART Ringbuffer (which is used for USB Connection with FTDI Chip) have only 64 bytes. Other boards like Leonardo have its own RAM (832 bytes) for USB.

Reply Children
No Data
Related

www.etcconnect.com