bt_send_rfcomm ignores len parameter, and truncates at first 0x00

[GoogleCodeExporter]

What steps will reproduce the problem?
1. packet_handler from rfcomm-cat, global uint16_t rfcomm_channel_id/mtu set in 
RFCOMM_EVENT_OPEN_CHANNEL_COMPLETE.
2a. C++ application thread using:
bt_send_rfcomm(rfcomm_channel_id, , "Hello world", 11);
2b. C++ application thread using:
bt_send_rfcomm(rfcomm_channel_id, , lpd8806Buffer.data(), 
lpd8806Buffer.size());,
where lpd8806Buffer.data() is a uint8_t* encoding RGB data in the LPD8806 
LED-strip protocol roughly:
0x00(32bits),
Green | 0x80(8),
Blue | 0x80(8),
Red | 0x80(8),
...
0x00(32)

What is the expected output? What do you see instead?
From (2a), result on the serial interface is as expected (eg ASCII "Hello 
world")
From (2b), a packet is sent with 0 payload, likely because the first byte is 
0x00. If I prepend some ASCII to the message in (2b), I receive everything up 
to the 1st 0x00 (eg the 1st byte of my transmission).

What version of the product are you using? On what operating system?
iPhone 4, iOS 5.0, BTstack/BTdaemon SVN r1640, establishing an RFCOMM 
connection to an SPP bluetooth module (specifically EGBT-046S). 

Original issue reported on code.google.com by p...@p-rimes.net on 26 Mar 2012 at 12:32

[GoogleCodeExporter]

This turned out to be a bug in my application code (which BTstack's use of 
PacketLogger made *much* easier to debug). My RGB data was not updated 
correctly on ARM devices, and hexdump inspection of the payload data identified 
this as my error.

BTstack RFcomm works splendidly now.

Original comment by p...@p-rimes.net on 29 Mar 2012 at 2:53

[GoogleCodeExporter]

hi. thanks for double checking. bt_send_rfcomm is used by Celeste and I've 
transferred several hundreds of megabytes with it, so it should really work. :)

Original comment by matthias.ringwald@gmail.com on 29 Mar 2012 at 3:25

• Changed state: Invalid