readBytesUntil() - supported in the firmware?

Firmware
1

Hey guys, I’m porting over some code from an Arduino which needs on the serial readBytesUntil() function. Looking at the firmware documentation, it looks like it’s not supported (which would explain why my code using it doesn’t work). Anyone know any work arounds?

Cheers,
Tim

2

I’ve found a replacement for readBytesUntill(), however it only seems to work on the Ardino - not the Sparkcore

–

i = 0;

while(myserial.available() ) // Don’t read unless
{

       inChar = myserial.read(); // Read a character
       inData[i] = inChar; // Store it
       i++; // Increment where to write next
       inData[i] = '\0'; // Null terminate the string

}

Serial.print(inData);
delay(500);

On the Arduino I get values like
5.22
5.22
5.24
…ect

On the Sparkcore (replace “myserial” with “Serial1”) I get values like
43333333333333343333333333333333333333333333333333333333

Anyone got an idea of what is going on?

3

Hmm - for debugging, I might recommend printing out each available character on Serial over USB in order to determine whether the issue is coming from a bad Serial1.read() or elsewhere.

4

Hey Zach, I thought that was what I was doing - what do I need to modify in my code? Below is a full copy of the program I’m running.


byte i = 0;
char inData[20]; // Allocate some space for the string
char inChar; // Where to store the character read


void setup(){
    
    
    
   //  Spark.variable("ph", &ph, INT);
     Spark.variable("i", &i, INT);
    
     Serial.begin(38400);           //USB Serial
     Serial1.begin(38400);         // RX & TX Serial
     
      delay(50); 
     
      Serial1.print("c\r");     //turn the pH Circuit into continues mode. 
          delay(50);                 //on start up sometimes the first command is missed. 
          Serial1.print("c\r");     //so, let’s send it twice.
          delay(50);                 //a short delay after the pH Circuit was taken out of continues mode is used to make sure we don’t over load it with commands.


}
  
 


void loop()
{

   i = 0;
    
   while(Serial1.available() ) // Don't read unless
   {
  
           inChar = Serial1.read(); // Read a character
           inData[i] = inChar; // Store it
           i++; // Increment where to write next
           inData[i] = '\0'; // Null terminate the string
   }
   
   Serial.print(inData);
   delay(500);
   
}
1 Like
5

Hi Tim, I did notice that you declared i as byte (8-bit, unsigned) in the global settings, but used INT (16-bit, signed) in the Spark.variable call. Could that be confusing things? I am thinking that Spark.variable will just read whatever is in the next byte after i and send that two-byte value back to you when you use the cloud to read that variable. I would use int in both places.

I don’t see anything that limits the i value to 19 chars (1 left for the \0 terminating char). You might try making the buffer bigger just to make sure you are not writing off the end of it.

Another likely factor might be the problem that lots of folks are having reading serial data into the core. The current USART code uses polling to check for received bytes and sometimes bytes are lost. I believe that an interrupt-driven USART driver is in the works.

2 Likes
6

I’m going to put this one down to a bug in firmware for now and keep developing my project on the Arduino. Hopefully this will be fixed soon enough :smile:

1 Like
7

Same to me. I’m really about to move to a standard Arduino board for my wireles home automation (FS20) because I can’t get RX/TX to run with my UARTs. Also I’m missing a 2nd TX/RX, because I need them for Receiver and Transmitter. FS20 WUE and FS20 US
Sending out data works perfect, but I experienced some problems getting the hex bytes from the UARTs (the incoming data from the reveiver and the status bytes from the sender), so I switched them to ASCII mode and what I saw was only scrambled, at least every 2nd char was missing, and the serial1 buffer don’t seem to work (if you add delay after reading the first char only the first char will be seen, all the rest is LOST!). I’ll give it another try with the indata[] array in the code above…

8

@zach, have you guys had a chance to look into this over the past sprints at all?

9

In current core-firmware master, USART is now interrupt-driven. We’ll be rolling this out to the web IDE early this week. Definitely give it a try with the new code, and let us know how it goes!

1 Like
10

Awesome - look forward to trying it out! Thanks :smile:

Will this also enable a second port via a “Software Serial” (that the last think I need to get my project up and running on the core)

11

Nope it won’t - that’s on our backlog, but has not yet bubbled up to top priority yet

12

Awesome! All I need to know it’s that it can happen and it’s on your list :smile: