codeless: increase storage of a characteristic

⚠️
嗨,...感谢您来论坛。令人兴奋的消息!我们现在正在迁至我们的新论坛平台,将提供更好的功能,并包含在主对话框网站中。所有帖子和帐户都已迁移。我们现在只接受新论坛上的流量 - 请发布任何新线程https://www.dialog-seminile.com/support.。我们将在未来几天修复错误/优化搜索和标记。
18个帖子/ 0新
最后一篇
克里斯南纳格
离线
最后一次露面:2年1个月前
加入:2018-05-27 21:33
codeless: increase storage of a characteristic

你好,
我正在使用无附件现有服务,与智能手机进行通信。因此,我将ATRL +“要传达的消息”发送给BLE芯片,并将此消息写入此特性,我从智能手机读取它。
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.
你能告诉我代码在哪里我必须做出更改以实现这一目标。我可以延伸多少钱?

非常感谢!

Device:
PM_DIALOG.
离线
最后一次露面:2 days 2 hours ago
职员
加入:2018-02-08 11:03
嗨克里斯南纳格,

嗨克里斯南纳格,

Please configure thedef_cust1_inbound_len.DEF_CUST1_OUTBOUND_LENuser_custs1_def.h报头文件的定义,以便增加为此特征分配的数据库空间,其中包含您喜欢的值。根据BLE核心规范,请注意属性值的最大长度应高达512个八位字节。

谢谢,PM_DIALOG.

克里斯南纳格
离线
最后一次露面:2年1个月前
加入:2018-05-27 21:33
我改变了那些

我改变了那些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.
你能帮我弄清楚为什么发生?
我确实遇到了cmd_buffer_size,而user_cmd_parser.h中的其他大小,但更改这些大小也没有帮助。我正在编程芯片的SRAM。

PM_DIALOG.
离线
最后一次露面:2 days 2 hours ago
职员
加入:2018-02-08 11:03
嗨克里斯南纳格,

嗨克里斯南纳格,

请你改变for(Uint8_t i = 0; i <160; i ++)for(uint8_t i=0;i<500;i++)在user_cmd_parser.c文件的extract_args()函数中?您是否能够立即发送超过160byte?此外,您应该定义def_cust1_inbound_len,def_cust1_outbound_len和cmd_buffer_size到500bytes。

谢谢,PM_DIALOG.

克里斯南纳格
离线
最后一次露面:2年1个月前
加入: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.
离线
最后一次露面:2 days 2 hours ago
职员
加入:2018-02-08 11:03
嗨克里斯南纳格,

嗨克里斯南纳格,

Could you please clarify which error the application replies?

谢谢,PM_DIALOG.

克里斯南纳格
离线
最后一次露面:2年1个月前
加入:2018-05-27 21:33
它只是发送错误。当我

它只是发送错误。当我发送atrl +“字符串”时,字符串近160个字符。

PM_DIALOG.
离线
最后一次露面:2 days 2 hours ago
职员
加入:2018-02-08 11:03
嗨克里斯南纳格,

嗨克里斯南纳格,

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.

谢谢,PM_DIALOG.

克里斯南纳格
离线
最后一次露面:2年1个月前
加入:2018-05-27 21:33
非常感谢!

非常感谢!

PM_DIALOG.
离线
最后一次露面:2 days 2 hours ago
职员
加入:2018-02-08 11:03
嗨克里斯南纳格,

嗨克里斯南纳格,

我假设你正在尝试使用ATR + PRINT = <发送>or the simpler| <发送>while writing the value of the characteristic from the mobile application. Is that correct?

谢谢,PM_DIALOG.

克里斯南纳格
离线
最后一次露面:2年1个月前
加入:2018-05-27 21:33
我正在发送atrl +“字符串”

我使用UART向DA14580发送ATRL +“字符串”。

mhv_dialog.
离线
最后一次露面:1 month 3 days ago
职员
加入:2013-12-06 15:10
你好,

你好,

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?

如果要在无附带的已定义命令中使用已定义的命令将数据发送到蓝牙上,则应使用

ATR + PRINT =

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

|

发出命令时,这些命令都要求您处于蓝牙连接状态。

/MHv

克里斯南纳格
离线
最后一次露面:2年1个月前
加入:2018-05-27 21:33
Wow!

Wow!
我不知道。某种方式atrl +“string”工作。
我会尝试你的方式并回来。

非常感谢。

mhv_dialog.
离线
最后一次露面:1 month 3 days ago
职员
加入:2013-12-06 15:10
它会“工作”,因为

它会“工作”,因为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.
离线
最后一次露面:1 month 3 days ago
职员
加入:2013-12-06 15:10
无附加用来使用sprintf到

无附加用来生成SprIntf生成一些限制响应长度到255个字符的响应。您可以安全地扩展无附件以处理下面提供的说明后的255个字符。您应该确保远端(在您的案例中智能手机应用程序)响应“确定”或“错误”或从微控制器的每个数据传输响应。除非您使用如上所述的“管道”命令,否则无附加无附加无附近终端的回复,然后在其准备好下次传输之前,您可能无法发送任何新数据,直到接收到回复。使用“pipe”命令删除对回复的需求。

以下是如何更改实现以支持255个字符:

在da1458x_config_basic.h中:

添加一个定义

#define cmd_buffer_size 255.

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

在user_cmd_parser.h中:

Out-评论旧的定义

#define cmd_buffer_size 160.

像这样

//#define CMD_BUFFER_SIZE 160

In the same file, change:

#define CMD_MAX_ARG_LENGTH 160

#define CMD_MAX_ARG_LENGTH CMD_BUFFER_SIZE

在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 ++)

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

在User_uart2.h文件的UART2_REC_DATA_AVAIL_ISR()函数中

Change

if(readdata == 0x0d || bytesin> 150)

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

在user_cmd_Interpreter的亚辅作用_env_t结构中

Change

char current_cmd [160];

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

克里斯南纳格
离线
最后一次露面:2年1个月前
加入:2018-05-27 21:33
非常感谢!

非常感谢!
You have been really helpful.
对不起,当你说的时候,我还有一个问题:
“您应该确保远端(在您的情况下智能手机应用程序)响应”确定“或”错误“到从微控制器的每个数据传输响应。除非使用上述”管道“命令,否则无附加无附带在接下来的下一个传输之前,远程终端的回复,并且在收到回复之前,您可能无法发送任何新数据。使用“pipe”命令删除对回复的需要“
here ATr+PRINT=text is working, even without any reply from the smart phone.
如果我要从我的智能手机回复,我该怎么做?通过写作一个特征?

mhv_dialog.
离线
最后一次露面:1 month 3 days ago
职员
加入:2013-12-06 15:10
虽然ATR + PRINT =

虽然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

克里斯南纳格
离线
最后一次露面:2年1个月前
加入:2018-05-27 21:33
非常感谢!

非常感谢!