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:
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
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.
你能帮我算出这是为什么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.
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
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.
Hi krishnanag,
Could you please clarify which error the application replies?
Thanks, PM_Dialog
It just sends ERROR. When I send ATrl+"string" where string is nearly 160 characters.
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
谢谢!
Hi krishnanag,
I assume that you are trying to use theATr+PRINT= or the simpler| while writing the value of the characteristic from the mobile application. Is that correct?
Thanks, PM_Dialog
I am sending ATrl+"string" from micro controller to da14580 using UART.
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
Wow!
I didn't know that. Somehow ATrl+"string" works.
I will try it your way and get back.
Thanks a lot.
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
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
谢谢!
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?
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
谢谢!