DA14580
Basic Development Kit with added analog sensors & EEPROM
SDK 5.0.3
Hello again Dialog,
I'm continuing work on an application based on the ble_app_peripheral example where I've been updating characteristic values using a CUSTS1_VAL_SET_REQ message and the ke_msg_send(req) method. One of these characteristics is a status byte sent to the host app (an Andriod tablet/phone). I'd like to send some status from an operation that runs when not connected, then present it when I wakeup and do get connected. I first tried to update the status characteristic within user_app_connected but that didn't work. If I issue the exact same value update message within another routine that I use to update other characteristics when connected, it works. These updates run off a timer once per second, so there's a one second delay before any characteristic update messages are sent. So my questions are: Is there a delay needed upon connecting to a host before characteristic value updates using CUSTS1_VAL_SET_REQ will function? Is there any kind of indicator or known time for this? Or perhaps even a way to update the characteristic value when not connected?
Along similar lines, I'm wondering if there's a setup time needed to update a characteristic value before disconnecting or going to sleep?
Thanks, Max
Hi Max44,
The profile is enabled when the device gets connected (in the default_app_on_connection) so when you are not connected you wont be able to update the characteristic via the CUSTS1_VAL_SET_REQ if the profile has not being enabled yet (since the profile specifies a set of handlers regarding the state of the connection) if you place the message right after the enabling of the custom profile your value should be updated. Other than that you can directly access the database (without using any messages) whatever moment you would like by using the attmdb_att_set_value() of course you will have to create the database first before updating it and you will have to know the handle of the characteristic you are about to update.
I dont get exactly what you mean regarding the setup time, as long as you have send a message in order to update the characteristic the kernel will serve any messages, if you send any additional message after the pass of the scheduling function and then you fall back to sleep the message will execute on the next wake up of the device when the scheduling function gets executed again unless if when sending the message you call of the sleeping procedure be returning KEEP_POWERED and not GOTO_SLEEP.
Thanks MT_dialog
Thanks MT,
I think you interpreted my question on "setup time" correctly. I wanted to make sure there wasn't a time constraint on sending a message before going to sleep or it would be lost. From what you said that shouldn't happen if the message has been submitted.
I'd like to learn how to use attmdb_att_set_value() if you can give me some further guidance on how to set the characteristic handle. I looked at custs1_val_set_req_handler and I see:
// Update value in DB
attmdb_att_set_value(custs1_env.shdl + param->handle, param->length, (uint8_t *)¶m->value);
So using this as a guide (after several hours of fumbling around), I inserted the values used in the message as follows:
attmdb_att_set_value(custs1_env.shdl + CUST1_IDX_STATUS_VAL, DEF_CUST1_STATUS_CHAR_LEN, (uint8_t *)&status_value);
I inserted this in my code where an operation completed while not connected and I wanted to present some status. This compiled and appears to be working. I get the status byte code I'm expecting when I reconnect from the Android tablet after running the offline operation. However, I have to confess I don't really know what I'm doing here. Let me know if it looks correct. If it is, it seems considerably simpler than the messaging system I was following in the ble_app_peripheral example.
Regards, Max
Hi Max44,
是的,这应该不会发生,因为你已经发送t message from your application the scheduler should serve it either on the current time period that the device is awake or at the next time the device is going to be awaken. Of course as i ve mentioned if you issue a kernel message after passing the scheduler function you can always cancel out the "go to sleeping procedure" in order to execute the message while you are awake.
Regarding the attmdb_att_set_value() yes the way that you ve posted is a quick and dirty way to use it (quick and dirty since you are placing the handle of the characteristic explictly not for any other reason, if you would like to change only that specific characteristic its fine).
Thanks MT_dialog
MT,
Thanks for the review. This answers all my questions here.
Quick and "dirty" works fine for me ...... and fits in well with my crude coding style. :)
Regards, Max