Reset FTDI Buf

So I'm using the Usb Host Sheild 2.0 Libary and USBFTDILoopback. My sensor has the USB FTDI chip and it is running on my Arduino Mega with Arduino Host Sheild. The sensor reads at 8bit 1bit stop. Sence the FTDI chip runs at 64 bit it fills the first set of data that I need whole and starts on the next line when down at a high delay. I have tried to merge the Buf to a new Buf to keep the same character in line where I can call them in individually for other functions. Is there a better way to merge Buf arrays or can I reset the sensor to give me a fresh line of information? It gives me every second and only need every 1-5 minutes or so. It's for a rain sampler and the sensor indicates when it rain date/time plus volume/intensity. Not very well at these things as well.

#include <cdcftdi.h>
#include <usbhub.h>

#include "pgmstrings.h"

// Satisfy the IDE, which needs to see the include statment in the ino too.
#ifdef dobogusinclude
#include <spi4teensy3.h>
#include <SPI.h>
#endif

class FTDIAsync : public FTDIAsyncOper
{
public:
    uint8_t OnInit(FTDI *pftdi);
};

uint8_t FTDIAsync::OnInit(FTDI *pftdi)
{
    uint8_t rcode = 0;

    rcode = pftdi->SetBaudRate(115200);

    if (rcode)
    {
        ErrorMessage<uint8_t>(PSTR("SetBaudRate"), rcode);
        return rcode;
    }
    rcode = pftdi->SetFlowControl(FTDI_SIO_DISABLE_FLOW_CTRL);

    if (rcode)
        ErrorMessage<uint8_t>(PSTR("SetFlowControl"), rcode);

    return rcode;
}

USB              Usb;
//USBHub         Hub(&Usb);
FTDIAsync        FtdiAsync;
FTDI             Ftdi(&Usb, &FtdiAsync);

uint32_t next_time;

void setup()
{
  Serial.begin( 115200 );
#if !defined(__MIPSEL__)
  while (!Serial); // Wait for serial port to connect - used on Leonardo, Teensy and other boards with built-in USB CDC serial connection
#endif
  Serial.println("Start");

  if (Usb.Init() == -1)
      Serial.println("OSC did not start.");

  delay( 200 );

  next_time = millis() + 5000;
}

void loop()
{
    Usb.Task();

    if( Usb.getUsbTaskState() == USB_STATE_RUNNING )
    {
        uint8_t  rcode;
        char strbuf[] = "DEADBEEF";
        //char strbuf[] = "The quick brown fox jumps over the lazy dog";
        //char strbuf[] = "This string contains 61 character to demonstrate FTDI buffers"; //add one symbol to it to see some garbage
        //Serial.print(".");

        rcode = Ftdi.SndData(strlen(strbuf), (uint8_t*)strbuf);

	if (rcode)
            ErrorMessage<uint8_t>(PSTR("SndData"), rcode);

        delay(50);

        uint8_t  buf[52];//all 52 was 64 to limit first row charachter to needed information

        for (uint8_t i=0; i<52; i++)
            buf[i] = 0;

        uint16_t rcvd = 52;
        rcode = Ftdi.RcvData(&rcvd, buf);

        if (rcode && rcode != hrNAK)
            ErrorMessage<uint8_t>(PSTR("Ret"), rcode);

        // The device reserves the first two bytes of data
        //   to contain the current values of the modem and line status registers.
        if (rcvd > 2)
            Serial.print((char*)(buf+2));

        delay(10);
    }
}

Hopefully I have interpreted your question correctly:

    for (uint8_t i = 0; i < 52; i++)
      buf[i] = 0;

I know it feels good to do housekeeping like this, but it serves no purpose. When the buffer is filled, it will be overwritten with the valid data and you know the length of the valid data. Invalid data consisting of zero is no more valid than any other value.
Anyway, if you really want to zero out memory, then look at the memset() function, which is usually optimised to do the job well.

can I reset the sensor to give me a fresh line of information? It gives me every second and only need every 1-5 minutes or so.

I don't know the answer to this, but you should definitely try to just get the sensor to deliver on demand rather than constantly spam your controller.

I have tried to merge the Buf to a new Buf to keep the same character in line where I can call them in individually for other functions. Is there a better way to merge Buf arrays or can I reset the sensor to give me a fresh line of information?

There are loads of ways to do what you are trying to do. In your case, where you have loads of incoming data but only occasionally want to use it, I might suggest the following:

  • The incoming data is record separated by new lines, so either \r\n or just \n .
  • When you want to extract a record from the incoming stream fill the buffer as you do already,
  • then search the buffer for the record separator (strstr() maybe),
  • use memmove() to shift the portion of the data after the record separator to the beginning of the buffer,
  • perform the next data read into the unused tail part of the buffer to complete the record.

Thank you for a reply. I will certainly will try it once I get the sensor back. I’ve tried to set the buf to zero again at the end but the old string of data still overlapped it. Are you saying there is no need to declare buff*=0 at the beginning? Yes on demand would be great, but my ability seems to be lacking! I’ve had to other professor engineers that don’t know the answer as well. The first string of data fill one complete second time slot and a partial of the next second. So it continues to be off. I’ll research the the two functions you’ve listed below. Once again thank you for feedback. I have 57 days left to finish, and I’m just a mechanical major. Lol*

Klyles3:
Are you saying there is no need to declare buff*=0 at the beginning?*
[/quote]
I'm saying there is rarely a need to zero out RAM before you put your data in it.
> Klyles3:
> Yes on demand would be great, but my ability seems to be lacking! I’ve had to other professor engineers that don’t know the answer as well.
You seem to be writing the string "DEADBEEF" to the device, is that necessary or does the data keep coming anyway?
Try posting the details of the sensor hardware (with a link if available) to see if someone here has experience with it and/or can offer help.
> Klyles3:
> The first string of data fill one complete second time slot and a partial of the next second. So it continues to be off.
As an addition to my previous suggestion, if RAM wastage is no problem, or if you just want to get it working quickly before refining it, you could just allocate a buffer that is twice the size of the maximum record length (including termination) and then you are always guaranteed to have a whole record somewhere in it.