bsdlib AT socket API

RE: bsdlib AT socket API

Håkon Alseth — Tue, 05 Mar 2019 11:57:12 GMT

I agree that this is not very efficient in terms of RAM usage. I'll report this back to the developers.

Unfortunately, as it's implemented as a datagram, you're unable to read a message in x byte chunks. The rest will then be discarded.

Kind regards,

Håkon

RE: bsdlib AT socket API

Martijn — Mon, 04 Mar 2019 09:36:55 GMT

Any more info on when the end of a message is received?

Is there any possibility read a portion of the data without removing the rest of it?

The examples that I found all use 4k buffers, wich seems a bit weird to me, because this is also allocated by the library. So there are 3 4k buffers allocated, 1tx in lib, 1rx in the lib and I alos need to allocate 4k in the application. seems a bit much to me.

RE: bsdlib AT socket API

Martijn — Thu, 28 Feb 2019 12:04:14 GMT

thank you, is that also the command response? I thought that was the max size of the command I could send.

And when the response is smaller than 4k. how do I know the end of the message is received?

RE: bsdlib AT socket API

Håkon Alseth — Thu, 28 Feb 2019 11:48:22 GMT

Hi,

The maximum is 4k:

https://github.com/NordicPlayground/nrfxlib/blob/master/bsdlib/include/bsd_limits.h#L47

Kind regards,

Håkon

RE: bsdlib AT socket API

Håkon Alseth — Tue, 26 Feb 2019 18:31:05 GMT

I'll check up on this internally and get back to you.

Kind regards,

Håkon

RE: bsdlib AT socket API

Martijn — Tue, 26 Feb 2019 10:40:40 GMT

Ok, so how do I know when the end of a single message is received?

How large does my buffer need to be at max?

RE: bsdlib AT socket API

Håkon Alseth — Tue, 26 Feb 2019 09:40:14 GMT

Hi Martijn,

[quote user=""]Is this expected behaviour? Do I need to allocate a massive buffer to be sure I always get all of my data?[/quote]

An AT socket is implemented as a datagram, so you can do a NRF_MSG_PEEK into it (to keep it "unread"), but once you do a NRF_MSG_DONTWAIT, it will flush/truncate unless you read out the whole message.

Kind regards,

Håkon