codeless: increase storage of a characteristic

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.wsdof.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
18 posts / 0 new
Last post
krishnanag
Offline
Last seen:2 years 1 month ago
加入:2018-05-27 21:33
codeless: increase storage of a characteristic

Hi,
I am using codeless existing service, to communicate with smartphone. So, I send ATrl+"message to be communicated" to the ble chip, and it writes this message on to this characteristic, and I read it from my smartphone.
This "message to be communicated" has an uppper limit of about 120 bytes or so. I wanted to ask if I could increase this, by increasing the database space allocated for this characteristic.
Can you please tell me where in the code I will have to make changes so as to achieve this. And upto how much can I extend this?

谢谢!

Device:
PM_Dialog
Offline
Last seen:1 day 23 hours ago
Staff
加入:2018-02-08 11:03
Hi krishnanag,

Hi krishnanag,

Please configure theDEF_CUST1_INBOUND_LENand theDEF_CUST1_OUTBOUND_LENdefinitions of the user_custs1_def.h header file in order to increase the database space allocated for this characteristic with the value that you prefer. According to BLE core specifications, be aware that the maximum length of an attribute value shall be up to 512 octets.

Thanks, PM_Dialog

krishnanag
Offline
Last seen:2 years 1 month ago
加入:2018-05-27 21:33
I changed both those

I changed both those definitions to 500 each, but still if I send ATrl+"string" where string has more than 160 characters, then some overflow happens and only few of the characters get transmitted.
Can you help me figure out why that is happening?
I did come across CMD_BUFFER_SIZE, and other sizes in user_cmd_parser.h, but changing those didn't help either. I am programming the sram of the chip.

PM_Dialog
Offline
Last seen:1 day 23 hours ago
Staff
加入:2018-02-08 11:03
Hi krishnanag,

Hi krishnanag,

Could you please change thefor(uint8_t i=0;i<160;i++)tofor(uint8_t i=0;i<500;i++)在extract_args()功能on of the user_cmd_parser.c file? Are you able to send more than 160bytes now?Also, you should define the DEF_CUST1_INBOUND_LEN, the DEF_CUST1_OUTBOUND_LEN and the CMD_BUFFER_SIZE to 500bytes.

Thanks, PM_Dialog

krishnanag
Offline
Last seen:2 years 1 month ago
加入:2018-05-27 21:33
Yes I changed all that. Still

Yes I changed all that. Still, when I send more than 160, it transmits 160 characters, and replies ERROR and then OK.
I am unable to understand why.

PM_Dialog
Offline
Last seen:1 day 23 hours ago
Staff
加入:2018-02-08 11:03
Hi krishnanag,

Hi krishnanag,

Could you please clarify which error the application replies?

Thanks, PM_Dialog

krishnanag
Offline
Last seen:2 years 1 month ago
加入:2018-05-27 21:33
It just sends ERROR. When I

It just sends ERROR. When I send ATrl+"string" where string is nearly 160 characters.

PM_Dialog
Offline
Last seen:1 day 23 hours ago
Staff
加入:2018-02-08 11:03
Hi krishnanag,

Hi krishnanag,

We are working on it in order to replicate your problem and make sure that you are able to send more than 160bytes. I will let you know as soon as possible.

Thanks, PM_Dialog

krishnanag
Offline
Last seen:2 years 1 month ago
加入:2018-05-27 21:33
谢谢!

谢谢!

PM_Dialog
Offline
Last seen:1 day 23 hours ago
Staff
加入:2018-02-08 11:03
Hi krishnanag,

Hi krishnanag,

我假设您正在使用ATr+PRINT=or the simpler|while writing the value of the characteristic from the mobile application. Is that correct?

Thanks, PM_Dialog

krishnanag
Offline
Last seen:2 years 1 month ago
加入:2018-05-27 21:33
I am sending ATrl+"string"

I am sending ATrl+"string" from micro controller to da14580 using UART.

MHv_Dialog
Offline
Last seen:1 month 2 days ago
Staff
加入:2013-12-06 15:10
Hi,

Hi,

CodeLess has no extended command that supports the format you are using. The ATI (or ATrI when used as a remote command) is a non-extended command (meaning it does not feature a '+' ). ATI is supposed to be used as a request to return a set of characters identifying the hardware and software of the physical device. Did you implement your own extended command in CodeLess?

If you want to send data over Bluetooth using already defined commands in CodeLess, you should use either the

ATr+PRINT=

or the simplified version using the '|' or "pipe" character:

|

Both of these commands require that you are in a Bluetooth connected state when the command is issued.

/MHv

krishnanag
Offline
Last seen:2 years 1 month ago
加入:2018-05-27 21:33
Wow!

Wow!
I didn't know that. Somehow ATrl+"string" works.
I will try it your way and get back.

Thanks a lot.

MHv_Dialog
Offline
Last seen:1 month 2 days ago
Staff
加入:2013-12-06 15:10
It will "work" because

It will "work" because CodeLess leaves it to the smartphone app to validate the command. So unless your app checks for syntax, you will not realize that it is wrong.

/MHv

MHv_Dialog
Offline
Last seen:1 month 2 days ago
Staff
加入:2013-12-06 15:10
CodeLess uses sprintf to

CodeLess uses sprintf to generate some of the responses which limits the response length to 255 characters. You can safely expand CodeLess to handle 255 characters following the instructions provided below. You should ensure that the remote end (in your case the smartphone app) responds either 'OK' or 'ERROR' to every data transmission from your microcontroller. Unless you use the "pipe" command as described above, CodeLess will expect to receive a reply from the remote end before it is ready for the next transmission and you may not be able to send any new data until a reply has been received. Using the "pipe" command removes the need for a reply.

Here is how you can change the implementation to support 255 characters:

In da1458x_config_basic.h:

Add a define

#define CMD_BUFFER_SIZE 255

(Moving the define to this file allows us to access it globally)

In user_cmd_parser.h:

Out-comment the old define

#define CMD_BUFFER_SIZE 160

Like this

//#define CMD_BUFFER_SIZE 160

In the same file, change:

#define CMD_MAX_ARG_LENGTH 160

to

#define CMD_MAX_ARG_LENGTH CMD_BUFFER_SIZE

In user_custs1_def.h

Change

#define DEF_CUST1_INBOUND_LEN 160

To

#define DEF_CUST1_INBOUND_LEN CMD_BUFFER_SIZE

And, in the same file, change

#define DEF_CUST1_OUTBOUND_LEN 160

To

#define DEF_CUST1_OUTBOUND_LEN CMD_BUFFER_SIZE

In the extract_args() function of the user_cmd_parser.c file

Change

for(uint8_t i=0;i< 160 ;i++)

to

for(uint32_t i=0;i< CMD_BUFFER_SIZE ;i++)

In the uart2_rec_data_avail_isr() function of the user_uart2.h file

Change

if(readData == 0x0D || bytesIn > 150)

to

if(readData == 0x0D || bytesIn > CMD_BUFFER_SIZE)

In codeless_env_t struct of the user_cmd_interpreter

Change

char current_cmd[160];

to

char current_cmd[CMD_BUFFER_SIZE];

You can change the CMD_BUFFER_SIZE to 512 (I did not test this), but all the replies from CodeLess will be reduced to 'OK' or 'ERROR'

/MHv

krishnanag
Offline
Last seen:2 years 1 month ago
加入:2018-05-27 21:33
谢谢!

谢谢!
You have been really helpful.
I am sorry, but I have just one more question, When you said :
"You should ensure that the remote end (in your case the smartphone app) responds either 'OK' or 'ERROR' to every data transmission from your microcontroller. Unless you use the "pipe" command as described above, CodeLess will expect to receive a reply from the remote end before it is ready for the next transmission and you may not be able to send any new data until a reply has been received. Using the "pipe" command removes the need for a reply"
here ATr+PRINT=text is working, even without any reply from the smart phone.
If I were to reply from my smart phone, How would I do that? By writing to one of the characteristics?

MHv_Dialog
Offline
Last seen:1 month 2 days ago
Staff
加入:2013-12-06 15:10
While the ATr+PRINT=

While the ATr+PRINT= appear to work without the response, CodeLess will likely get confused as it relies on a simplified message flow in order to keep track of whether a response should be returned to the local UART or the remote peer via Bluetooth. Using the '|' command ensures that this does not cause issues.

A reply from the smartphone back to the device is as simple as writing to the first characteristic of the custom service (UUID = 914F8FB9-E8CD-411D-B7D1-14594DE45425)

By the way: The smartphone will receive a notification whenever new data is available for a read operation If you subscribe to them on the third characteristic (UUID = E2048B39-D4F9-4A45-9F25-1856C10D5639).

/MHv

krishnanag
Offline
Last seen:2 years 1 month ago
加入:2018-05-27 21:33
谢谢!

谢谢!