this bit of code should generate a string of command codes for a YX-5300 sound module. if the uploaded data exceeds 80, the code adds a herd of Fs in front of the required command:
static int8_t Send_buf[8] = {0} ;
void setup()
{
Serial.begin(115200);
{
Send_buf[0] = 0x7E;
Send_buf[1] = 0xCB;
Send_buf[2] = 0x7F;
Send_buf[3] = 0x80;
Send_buf[4] = 0x9F;
Send_buf[5] = 0xA0;
Send_buf[6] = 0x34;
Send_buf[7] = 0xEF;
for(uint8_t i=0; i<8; i++)//
{
//Serial.print(Send_buf[i]);
Serial.print("i= ") ;Serial.print(i); Serial.print(": ");
Serial.print(Send_buf[i] >> 4, HEX);
Serial.print(Send_buf[i] & 15, HEX);
Serial.println();
}
Serial.println();
}
}
void loop()
{
}
compile and see. what Is the source of all those Fs when the command >=80?
Try using unsigned type for this; the high-bit is the sign bit.
unsigned char should be fine.
this is standard code used on every YX-5300 example code everywhere.
results using standard static int8_t Send_buf[8] = {0} ;
i= 0: 7E
results using static unsigned char Send_buf[8] = {0} ;
i= 0: 7E
which makes me believe that nobody ever verifies that the code works, they just cut and paste and pass along the error.
one karma for you, Blackfin
The extra F's are from the Serial.print() routine mistakenly assuming that the result to be printed is 32 bits long, when the high bit is set. They will not be sent to a device if you use Serial.write().
I regard it to be a bug in the Arduino print class.
system
February 17, 2019, 12:48am
5
I regard it to be a bug in the Arduino print class.
It's a bug only because not every possible variable type has a print() overload. So, the compiler uses the best match, which isn't always good enough.
the YX-5300 works with
static unsigned char Send_buf[8] = {0} ;
it initialized immediately, which did not happen with
static int8_t Send_buf[8] = {0} ;
and I'm jumping the next hurdle