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

Read Single Value from an array

I'm using SD110, and in my application I have an array of 64, 32-bit integers.

Typically, the client will only need to read 1 of the 64 values, or write to one of the 64 values. Rather than passing the entire large block of data, when only 4 bytes are needed at any time, I've created a characteristic that has 5 bytes - the first byte is for the index in the array, the remaining 4 bytes are the value. This works well for writing - I write the index and value. The thing I can't figure out is how to read a value out of the array at a given index.

Is there a way to do this?

Parents
  • So if I understand correctly, you have a single characteristic you intend to read data from and write data to (from the perspective of the central/client). Writing is easy because the nRF51822 is immediately notified of a write and can process the data, which in your case is parsing a packet and modifying memory.

    A simple read by your client is easy, but that's not enough for you application, your client needs to access a specific piece of data. It needs a way of telling the application on the nRF51822 what data it wants and the nRF51822 needs to then give it that data. So the way you tell the application on the nRF51822 what data you want is by doing a write (and then a read, perhaps...)

    There's a simple concept explained in this book called a control point. It's a characteristic you send a "control" message to, and then your system does something. That message can be as simple as just a number, or a more complex payload. The something the system does depends on your design. A "pure" control point is write-only, but in real life you can make it read/write, if you want.

    So there are a couple of things you need to decide. First, you need to decide on a protocol of control messages that both your control point and your client understand. You've already gotten somewhere, designing a way to do reads. A good protocol will fit your system (not be too complex) while allow for some extendability (you can add more stuff it it later, easily).

    Right now, you need a control message the means "read" and another that means "write". One simple way to achieve this is to place a byte at the beginning of your packet that indicates the message type. For example, a 0 means read and a 1 means write. Then when your control point receives one of these packets, it decides what to do based on that byte.

    So great, you can write data (control messages) in, but how do you get the data you wanted to read back out?

    One way is to create another characteristic that contains the result of any operation commanded by the control point. This type of behavior is called a data point. After sending a command to the control point you can read the result from this data point characteristic. Alternatively, you can notify the result from the nRF51822 so the client doesn't have to go read it itself.

    A "dirtier", but probably workable, way is to have a single combined data/control point characteristic. Take the concepts above, but rather than using different characteristics for control and returned data, use the same characteristic. The benefit is some small power savings and a little less code.

    Good luck.

Reply
  • So if I understand correctly, you have a single characteristic you intend to read data from and write data to (from the perspective of the central/client). Writing is easy because the nRF51822 is immediately notified of a write and can process the data, which in your case is parsing a packet and modifying memory.

    A simple read by your client is easy, but that's not enough for you application, your client needs to access a specific piece of data. It needs a way of telling the application on the nRF51822 what data it wants and the nRF51822 needs to then give it that data. So the way you tell the application on the nRF51822 what data you want is by doing a write (and then a read, perhaps...)

    There's a simple concept explained in this book called a control point. It's a characteristic you send a "control" message to, and then your system does something. That message can be as simple as just a number, or a more complex payload. The something the system does depends on your design. A "pure" control point is write-only, but in real life you can make it read/write, if you want.

    So there are a couple of things you need to decide. First, you need to decide on a protocol of control messages that both your control point and your client understand. You've already gotten somewhere, designing a way to do reads. A good protocol will fit your system (not be too complex) while allow for some extendability (you can add more stuff it it later, easily).

    Right now, you need a control message the means "read" and another that means "write". One simple way to achieve this is to place a byte at the beginning of your packet that indicates the message type. For example, a 0 means read and a 1 means write. Then when your control point receives one of these packets, it decides what to do based on that byte.

    So great, you can write data (control messages) in, but how do you get the data you wanted to read back out?

    One way is to create another characteristic that contains the result of any operation commanded by the control point. This type of behavior is called a data point. After sending a command to the control point you can read the result from this data point characteristic. Alternatively, you can notify the result from the nRF51822 so the client doesn't have to go read it itself.

    A "dirtier", but probably workable, way is to have a single combined data/control point characteristic. Take the concepts above, but rather than using different characteristics for control and returned data, use the same characteristic. The benefit is some small power savings and a little less code.

    Good luck.

Children
No Data
Related