Understanding the ADB Service Request Signal
In the comments section of yesterday’s post, I mentioned a concern about ADB’s service request (SRQ) mechanism. A device requesting service can pull the ADB bus low at a certain point midway through another ADB transaction, which is called an SRQ signal. It appeared that the SRQ would interrupt the transaction in progress, and cause the host to poll other ADB devices to find the one asserting SRQ. The traffic logs collected by my ADB packet sniffer matched this theory. That would create the potential for bus deadlock if two devices both requested service, each one forever interrupting the other.
To answer this question, I got out my Saleae logic analyzer, so I could directly inspect traffic on the ADB bus. Here’s what I saw for a typical ADB transaction without an SRQ signal:
Everything up to the first stop bit is generated by the host. Everything after that is the reply from the device. Tlt is the “stop bit to start bit time” described in the ADB spec, a period of about 200 microseconds between the command and data sections during which the bus remains high.
A device asserts the SRQ signal by pulling the bus low during the first stop bit, after the command section of the transaction. I had thought this cancelled the rest of the transaction. Or maybe the SRQ signal (nominally 300 microseconds) ate into the Tlt time following it, but the rest of the transaction still finished, as shown by the dotted red line here:
My ADB traffic sniffer showed no traffic after the SRQ, so I assumed it cancelled the rest of the transaction. But when the logic analyzer captured a transaction including an SRQ, it showed this:
SRQ doesn’t cancel the transaction, nor does it eat into the Tlt time. It’s basically a stop bit with an extra-long low time, and it simply delays everything that follows. So there’s no fear of ADB bus deadlock.
Why wasn’t my ADB traffic sniffer showing the data that follows the SRQ? It turned out this was wholly unrelated to my misunderstanding of the SRQ mechanism, but was just a bug in my code. I got too fancy trying to maintain a byte count and a separate SRQ flag in a single status byte, using bit masking operations, and my code didn’t work. With the bug fixed, I now see the true ADB traffic. Address 2 is the keyboard, 3 is the mouse. The keyboard keeps asserting SRQ, but that doesn’t prevent communication with the mouse.
ADB Reset Addr: 0, Talk 3 Addr: 1, Talk 3 Addr: 2, Talk 3 62 02 Addr: 3, Talk 3 SRQ 69 01 Addr: 4, Talk 3 SRQ Addr: 5, Talk 3 SRQ Addr: 6, Talk 3 SRQ Addr: 7, Talk 3 SRQ Addr: 8, Talk 3 SRQ Addr: 9, Talk 3 SRQ Addr: A, Talk 3 SRQ Addr: B, Talk 3 SRQ Addr: C, Talk 3 SRQ Addr: D, Talk 3 SRQ Addr: E, Talk 3 SRQ Addr: F, Talk 3 SRQ Addr: 2, Listen 3 0F FE Addr: 2, Talk 3 SRQ Addr: F, Listen 3 02 FE Addr: F, Talk 3 SRQ Addr: 3, Listen 3 SRQ 0F FE Addr: 3, Talk 3 SRQ Addr: F, Listen 3 SRQ 03 FE Addr: F, Talk 3 SRQ Addr: 2, Listen 3 0F FE Addr: 2, Talk 3 SRQ Addr: F, Listen 3 02 FE Addr: F, Talk 3 SRQ Addr: 3, Listen 3 SRQ 0F FE Addr: 3, Talk 3 SRQ
4 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
As a side note, the Saleae logic analyzer was the perfect tool for this, and made debugging the ADB traffic a breeze. I had mixed feelings about the Saleae when I reviewed it last year, citing some missing features like external clocking and advanced triggers. But I’ve used it many times since then, and I have to admit the lack of those features has never been an issue, not even once. So maybe Saleae got the feature set right after all. My only gripe now is that I wish it had more than 8 channels, especially since I somehow killed one of them. 🙂
If you’re after more channels at a decent price, check out the Digilent Analog Discovery 2. http://store.digilentinc.com/analog-discovery-2-100msps-usb-oscilloscope-logic-analyzer-and-variable-power-supply/ – EEVBlog review of the first gen here https://www.youtube.com/watch?v=Aymumu3mYl8
timestamping would make debugging a lot easier, you would spot “SRQ interrupted” packets actually taking longer than non interrupted = not interrupted at all
anyway, in the comment your spam filter ate I suggested implementing both USB host ports in software (reverse VUSB), host does all the pooling and its only 1.5Mbit.
https://courses.cit.cornell.edu/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html
$2 72MHz arm is fast enough.
Interestingly, your finding seems to contradict Microchip AN591 (http://ww1.microchip.com/downloads/en/AppNotes/00591b.pdf): “The Tlt signal and Data Packet transfer, which are part of every Command packet signal sequence, are overridden if an Srq is issued by any device.”