This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Characteristic Write followed by inline read (eg write command, read Ack/Nak response)

Hi

I am back on the firmware end of my project after several months doing the PC and Xamarin ends in C#... Trying to remember my C...!

My device has 3 MCU's incl the Nordic as well as a mobile App (via BLE) and a PC (via USB). EG I have BLE, USB and SPI as transports!

Over the top of these transports, I run a protocol which allows any endpoint: PC, App, MCU1, MCU2, Nordic) to send a message to any other endpoint. The Message consists of Header <Ack/Nak> Payload <Ack/Nak>. It all works fine over SPI and USB, but I now need to get the same thing working over BLE.

I have 2 characteristics Send and Receive. The send characteristic sends header/payload from Nordic-->App, the receive characteristic from App-->Nordic. I have these set up as Notify.

Taking the 'Send' characteristic, I want to:

- Send the Header

-Wait for the Ack/Nak (being returned from App-->Nordic via a write on the send characteristic)

- Send the payload

-Wait for the Ack/Nak (being returned from App-->Nordic via a write on the send characteristic)

The send works fine, and I can get the returned Ack/Nak data into my event handler via event BLE_CUS_EVT_RX_DATA     BUT

Is there a way of doing this inline without setting fDataWaiting flags in my event handler for my main application loop on the nordic to pick up eg:

- Send the header

- fall into while loop:  while (!AckNak recieved from app && !TimedOut) {};

- Send payload

- fall into while loop:  while (!AckNak recieved from app && !TimedOut) {};

????

Also, on the APP end, via notify on the Send characteristic

- App gets a call via notify callback, message contains the 'header'

- I validate the header CRC, and work out whether a payload will follow eg if (Header.Payload.Length > 0)

- If a payload will follow then I turn OFF (unsubscribe) from characteristic updates

- Respond with the Ack/Nak for the header

- I Read the payload inline SendCharacteristicRead(payload);

- Respond with the Ack/Nak for the payload

- Turn async updates for characteristic back on....

Feels messy... turning the characteristic updates on/off all the time. Would I perhaps be better having my Send/Receive characteristics without notify, and making a new characteristic with notify on read/write enabled, and using this as a simple single byte datawaiting flag to indicate 'data waiting' to nordic application and to App?

Architectural issues, I know, just unsure of the best route forward?

Nigel

Parents
  • Hello Nigel,

    I am not sure whether I actually understand your question. Is this a matter of latency, or just cleaning up the code?

    Regardless, it seems a bit messy turning on and off notifications all the time. I don't understand the need to do this, but maybe that is the part of the question that I don't understand. What are your ACK/NACK and datawaiting flags used for?

    Is it possible to skip the ACK/NACK in the BLE part of your application, and just send the header and payload in one message? This will reduce the latency. Then check the header and decide whether or not to pass the payload on to one of the other peripherals?

    Best regards,

    Edvin

Reply
  • Hello Nigel,

    I am not sure whether I actually understand your question. Is this a matter of latency, or just cleaning up the code?

    Regardless, it seems a bit messy turning on and off notifications all the time. I don't understand the need to do this, but maybe that is the part of the question that I don't understand. What are your ACK/NACK and datawaiting flags used for?

    Is it possible to skip the ACK/NACK in the BLE part of your application, and just send the header and payload in one message? This will reduce the latency. Then check the header and decide whether or not to pass the payload on to one of the other peripherals?

    Best regards,

    Edvin

Children
No Data
Related