nRF8001 Data Credit System Details

[Garth Snyder]

I wrote my own ACI interfacing code, so I have questions about some details of the data credit system that most devs may be insulated from by the Nordic SDK.

Section 25 of the nRF8001 Product Specification (page 133, Revision 1.2) lists 5 "data commands": SetLocalData, SendData, SendDataAck, RequestData, and SendDataNack. But of these, only SendData and SendDataNack list a DataCreditEvent as a possible return packet in their "Returned events" sections. Presumably, the remaining 3 "data commands" that cannot return data credits should NOT have credits charged against them on transmission. Is that correct?

I'm a bit suspicious of the accuracy of the documentation. In particular, it seems strange that SendDataNack would consume a credit while SendDataAck does not. And RequestData presumably involves a radio transmission as well; does it not consume a data credit?

Alone among the data commands, SetLocalData returns a regular CommandResponseEvent. And if I understand its function correctly, it cannot trigger any radio communication. Is it fair to say that SetLocalData is really just a regular command and should in no way be treated as a "data command"? That is, not only should it not be charged a data credit, but it should also block all other non-data commands until the CommandResponseEvent is received?

[Garth Snyder]

Thank you for this detailed and thoughtful response, and best wishes for a happy new year. This is very helpful.

I think this points me toward all the information I needed, but just for the sake of providing feedback on the documentation, it's surprising to me that you mention that "most...commands do not block other commands". I had been under the impression that there could only ever be one non-data command outstanding, for the reasons outlined below. (Mind you, I'm not arguing or nitpicking -- I'm just pointing out an additional area where the documentation might be potentially misleading.)

The text of Section 19.x divides ACI packets into three groups: system commands, data commands, and events. And then in Section 21.1, "System command buffering", the product spec states explicitly that "Only one System Command can be outstanding at any moment in time before the application controller is allowed to send another one...The application controller must receive an event confirming the execution of the command before sending the next system command."

It does make intuitive sense that some packets classified as system commands might be more lenient in their behavior, but the overall impression I had had from reading these sections was that any outgoing (controller-to-nRF8001) command that was not a data command should be sent only when no other commands were pending.