midi sysex head scratching - arduino project

[alistermorton]

My code returned 100 and -905 as a 16 bit short int and I can't immediately see the problem in your code. When I get back to the office tomorrow I'll do a cut and paste of my code. It used an inline function but that won't change the logic. 

[cedd]

Thank you so much Alister. I'm going to try it tomorrow with the 2 bytes as constants rather than being read from the midi input - I'm wondering if there's something quirky going on that's different between live values like I have, and simulated ones like you have. I've got Bome's Send SX software running on my laptop and am sending the value to the teensy that way.

[DrV]

I've now had time to do some experimenting.

First, -905 is hex 78 77 not hex 78 7f but that's a minor detail. It's still a negative number (-897) actually.

Second, it looks as though the Teensy is treating the int as a 32 bit value which is why the code works on a real Arduino, which treats it as a 16bit value.

Third, although Alister was nearly right about sign extending the 32 bit number he should have put ffffc000 instead of 8888c000

I'm posting this on the mobile so can't see the code tags but I'll try and edit on the computer so that I can show you the code correctly.

Dave

void setup() {
Serial.begin(9600);
}

void loop() {
byte rxhigh_part = 0x78;
byte rxlow_part = 0x77;
long val = ((rxhigh_part&0x7f)<<7) | (rxlow_part & 0x7f);
if(val & 0x2000) val|=0xffffC000;
Serial.print (rxhigh_part, HEX);
Serial.print (rxlow_part, HEX);
Serial.print (" : ");
Serial.println(val);
while(1);
}

Resulting output is

7877 : -905

Of course I've had to declare val as a long to force the Arduino to use 32 bits. If I do that and use C000 instead of ffffc000 for the sign extension I get the same result that you did. And if I use 8888C000 I also get the other wrong value that you got!

Hope that helps

Dave

Edited December 3, 2021 by DrV
Added the CODE section

[alistermorton]

Well spotted, Dave, absolutely if should have been FFFFC000 - D'oh! It had been a long day.

My test was as follows:

inline short combine7bit(unsigned char high, unsigned char low)
{
	unsigned short u = ((high & 0x7f) << 7) | (low & 0x7f);
	if (u & 0x2000) { u |= 0xC000; }
	return (short)u;
}

int main()
{
	short s = combine7bit(0x78, 0x77);
	printf("%hd\n", s);
	s = combine7bit(0, 0x64);
	printf("%hd\n", s);
	return 0;
}

This outputs -905 and 100 for the given inputs.

[cedd]

You absolute beauties! That's it! 

You might also chuckle to note that after my last post yesterday I decided to try something else and get the name transfer working instead. Roland have a table of values 0-127 that correspond with characters. I set about building up an array of all the different characters. Took me ages. Then, and only then, did I realise that Roland had used values that corresponded to the ASCII codes for the relevant characters - all I had to do was write the received value to the display and it worked. 

Thanks again. Will share the final item with you once I've finished it. 

Chris 

[DrV]

Glad it worked. When I've got a minute I'll have a look at the Teensy again. Got a couple in a box  somewhere...

[alistermorton]

Apologies for sending you up a blind alley with those 8's ... I can only say if had been a long day and I'd done my code on shorts, not ints. Anyway, glad to hear it's working.

 

[boatman]

Sorry, coming late to the party. It's always a good idea to cast 8-bit byte values to 16-bit int before doing integer operations.

So:

int val = ((rxhigh_part&0x7F)<<7)|(rxlow_part&0x7F);

should be:

int val = (((int)rxhigh_part&0x7F)<<7)|((int)rxlow_part&0x7F);

 

[timsabre]

C always casts byte to signed int when you do a calculation, you don't need to do it separately. The trouble comes when int is 16bits (mega arduinos) as 32767 isn't all that big and quite easy to overflow. On ARM arduino it's 32 bit so doesn't overflow. 

I've started defining things as uint_32t or uint_16t rather than relying on the compiler to set the variable size, can save a lot of head scratching.