+1  A: 

That's an awful lot of work just to fill out an array of bytes. Also, you're trying to tack eight bytes onto playData with each of your -appendBytes:length: messages.

For a situation like this, I'd just declare a struct for your BT command frame. NSData doesn't really offer you much here.

NSResponder
Cool, thanks for the pointer. I'm a newb when it comes to dealing with bytes directly can you show an example?
macinjosh
+1  A: 

If you're going to be working with AV/C frames a lot, rather than creating a struct (which won't really help with the partial-byte packing), you should create an AVCFrame class that makes it easy to set up these frames, sanity checks the values you give it, has a debugging description, and will handle all the grungy details for you.

Your code can then look like this:

AVCFrame *frame = [AVCFrame frameWithCommandType:AVCCommandTypePlay
                                     subunitType:mySubunitType
                                       subunitID:mySubunitID];
// You likely won't actually be writing to the L2CAPChannel. See below.
[l2capChannel writeAsync:[frame mutableBytes] length:[frame length] refcon:nil];

That's not the best interface. You'll want to read through the AV/C Digital Interface Command Set General Specification.

As far as the byte packing goes (and it will have to happen eventually), you'll want to use something like:

// Returns |subunitType| shifted and masked appropriately for bit_oring
// with subunit ID to create an address octet.
inline UInt8
AVRCAddressSubunitType(UInt8 subunitType) {
   const UInt8 kLeastThreeBytes = 0x07;
   UInt8 shiftedType = (subunitType << 3) & ~kLeastThreeBytes;
   return shiftedType;
}

// Returns |subunitID| masked appropriately for bit_oring with subunit type
// to create an address octet.
inline UInt8
AVRCAddressSubunitID(UInt8 subunitID) {
   const UInt8 kLeastThreeBytes = 0x07;
   UInt8 maskedID = subunitID & kLeastThreeBytes;
   if (subunitID & ~kLeastThreeBytes) {
      NSLog(@"*** %s: subunit ID %#hhx > 0x07 cannot be represented "
            "in the 3 bits allotted. Truncating to %#hhx.",
            __PRETTY_FUNCTION__, subunitID, maskedID);
   }
   return maskedID;
}

- (void)l2capChannelOpenComplete:(IOBluetoothL2CAPChannel *)l2capChannel
                          status:(IOReturn)error {
  /* might be worth looking at the error... */
  NSLog(@"%s: open complete - "
        "error: (system: %#x; subsystem: %#x; code: %#x)",
         __PRETTY_FUNCTION__,
         err_get_system(error), err_get_sub(error), err_get_code(error));

  /* to send, first pack your data into byte-sized variables */
  // some variables...
  // address byte layout is [3:7] = 9 = PANEL; [0:2] = 0 = subunit ID
  UInt8 address = (AVRCAddressSubunitType(0x09) | AVRCAddressSubunitID(0x00));
  // some more variables...

  /* create a mutable data and append the bytes in sequence */
  // some appending...
  [playData appendBytes:&address length:sizeof(address)];
  // more appending...

  /* finally, send all the bytes */
  [l2capChannel writeAsync:[playData mutableBytes]
                    length:[playData length]
                    refcon:NULL];
}

For more details on IOWhatever, look to the extensive IOKit documentation. At least in 10.5, the reference docs (as opposed to programming guides) in the docset were kind of screwy, so you'll do well to look at the headers themselves.

You'll need to consult more documentation than you've looked at so far. The AV/C command frame whose diagram you've included is actually the payload (borne in the Command/Response Message Information field) of an AVCTP frame, which is what you actually have to send over the L2CAP transport. The AVCTP spec sketches a rudimentary API in "Appendix A, AVCTP Upper Interface".

You'll need to either locate or write yourself an AVCTP library in order to send the AV/C command frames. You'll want to have the AVCTP library wrap the L2CAP channel, so that you actually send your command frames via it and receive your command frames from it. Good luck! Interfacing with hardware can be a lot of fun, and you'll learn a lot.

Jeremy W. Sherman
wow, thanks alot!
macinjosh