Re: MBUF sizing for the bluetooth stack

Thanks Chris, It appears to me that there is questionable benefit to having mbufs sized larger than the largest L2CAP fragment size (plus overhead), i.e. the 80 bytes that Will mentioned. Is that a reasonable statement, or am I missing something? For incoming data, you always waste memory with

Re: Tutorial problem with the Docker Container

Hi Chris, I switched to Linux by installing Ubuntu on the same virtual box and am not using the Docker Container any more. I could try it again today and get back to you later. Previously the problem I encountered seemed to be I was compiling a tutorial package that doesn't exist (as pointed out

Re: Tutorial problem with the Docker Container

Hi Li-Chun, I'm glad you got it working, but now I'm confused. The docker container should already use the correct version of gcc (multilib). Furthermore, as I understand it, installing a different compiler on your machine should not have any effect on the docker container. Are you still using

Re: MBUF sizing for the bluetooth stack

On Thu, Jan 19, 2017 at 10:57:58AM -0800, Christopher Collins wrote: > On Thu, Jan 19, 2017 at 03:46:49AM -0800, Simon Ratner wrote: > > A related question: how does this map to large ATT_MTU and fragmented > > packets at the L2CAP level (assuming no data length extension)? Does each > > fragment

Re: MBUF sizing for the bluetooth stack

On Thu, Jan 19, 2017 at 03:46:49AM -0800, Simon Ratner wrote: > A related question: how does this map to large ATT_MTU and fragmented > packets at the L2CAP level (assuming no data length extension)? Does each > fragment get its own mbuf, which are then chained together, or does the > entire

Re: MBUF sizing for the bluetooth stack

That is a good question. I should let Chris answer this one as he knows for sure. I suspect you will have a chain of mbufs but I would have to look over the code to be sure. > On Jan 19, 2017, at 3:46 AM, Simon Ratner wrote: > > Hi Will, > > A related question: how does this

Re: Tutorial problem with the Docker Container

Hi Fabio, After I install gcc-multilib all problems solved! I guess it is worthwhile to add a note for this in the tutorial. Thank you very much. BTW, I am using Ubuntu 16.04.1 64 bit version. Br, Lichun 2017-01-19 22:44 GMT+08:00 Li-Chun Ko : > Hi all, > > I tried

Re: Tutorial problem with the Docker Container

On Thu, Jan 19, 2017, at 12:44 PM, Li-Chun Ko wrote: > Hi all, > > 2. Error message when executing $newt test all: > > lcko@lcko-VirtualBox:~/dev/go/myproj$ cd repos > lcko@lcko-VirtualBox:~/dev/go/myproj/repos$ $newt test all > Testing package @apache-mynewt-core/boot/boot_serial/test >

Re: Tutorial problem with the Docker Container

Hi all, I tried "$newt test @repos/apache-mynewt-core/kernel/os" in Linux but it still doesn't work. I also attached the error message of executing "$newt test all" below. It seems some files are missing. Br, Lichun 1. Error message when executing $newt test @repos/apache-mynewt-core/kernel/os:

Re: Tutorial problem with the Docker Container

On Thu, Jan 19, 2017, at 06:55 AM, Li-Chun Ko wrote: > > In addition, I also found the conmend: > > newt test all > > did not work in Linux and resulted in compiling errors and somehow I feel > there is some issues with the newt install commend. Hi, could you copy the error here?

Adding support for an external SPI flash (AT45DB)

Hi, Just opened a new PR (https://github.com/apache/incubator-mynewt-core/pull/162) that adds support for the AT45DB321 SPI flash. AFAIK this AT45DB series consists of chips supporting 16, 32 and 64Mb (321 is 32Mb!). The size is still hardcoded so only DB321 for now. Also got NFFS working on this

Re: MBUF sizing for the bluetooth stack

Hi Will, A related question: how does this map to large ATT_MTU and fragmented packets at the L2CAP level (assuming no data length extension)? Does each fragment get its own mbuf, which are then chained together, or does the entire packet get reassembled into a single mbuf if there is room? On