Re: [riot-devel] LWM2M using ethos
Dear Ken Thank you very much! Everything worked like a charm. I just have a few follow up questions. It seems that usually tap is preferred over tun for most of the RIOT applications. Why is this? Also is it possible to get a tun interface set up with ethos? Kind regards Ashim Asharaph >>> Ken Bannister 06/22/19 1:34 PM >>> [The e-mail server of the sender could not be verified (SPF Record)] I forgot one other thing. You'll need the header for SLIP parameters. Grab the one from gcoap and copy it to the location of your Makefile [1]. [1] https://github.com/RIOT-OS/RIOT/blob/master/examples/gcoap/slipdev_params.h On 6/22/19 7:23 AM, Ken Bannister wrote: > Hi Ashim, > > I tried to get ethos to work with a samr21-xpro, but failed. I was not > permitted to assign an IP address to the wired interface. Rather than > pursue that, I was successful with SLIP, the legacy border router tool. > > See the gist for the Wakaama Makefile modified for SLIP [1]. Compile > and flash that, which uses fd00:dead:beef for the network prefix. In a > separate terminal, set up a TUN interface on your workstation. I use > Ubuntu 19.04: > >$ sudo dist/tools/tunslip/tunslip6 -s ttyUSB0 -t tun0 > fd00:dead:beef::1/64 > > Then in the terminal for the border router, configure the interface: > >> ifconfig 7 add unicast fd00:dead:beef::2/64 >> nib neigh add 7 fd00:dead:beef::1 > > Then you should be able to startup the Wakaama client to talk to the > LwM2M server. > > Ken > > [1] https://gist.github.com/kb2ma/462a1375ee50735cd58fb3aac7c3c021 > > > On 6/21/19 10:29 AM, Ashim Asharaph wrote: >> Dear RIOT developers >> >> I would like to get LWM2M communication through ethos between a board >> and computer (without using a border router). It is necessary to do >> it this way because the board does not have any wireless or ethernet >> capability. I am testing the idea on a samr21-xpro for now. I am >> using the wakaama example from one of the PRs and have enabled ethos. >> >> >> The problem is that the wired interface does not have a global ip >> address. The wakaama client can register itself with the Leshan >> server but the server cannot communicate with the client due to the >> absence of a global address. I have also tried binding the Leshan >> server to the tap interface, but that does not work. Any suggestions >> would be highly appreciated. >> >> >> Kind regards >> Ashim Asharaph >> >> >> ___ >> devel mailing list >> devel@riot-os.org >> https://lists.riot-os.org/mailman/listinfo/devel > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] LWM2M using ethos
Dear RIOT developers I would like to get LWM2M communication through ethos between a board and computer (without using a border router). It is necessary to do it this way because the board does not have any wireless or ethernet capability. I am testing the idea on a samr21-xpro for now. I am using the wakaama example from one of the PRs and have enabled ethos. The problem is that the wired interface does not have a global ip address. The wakaama client can register itself with the Leshan server but the server cannot communicate with the client due to the absence of a global address. I have also tried binding the Leshan server to the tap interface, but that does not work. Any suggestions would be highly appreciated. Kind regards Ashim Asharaph ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT vectors for Smartfusion2 port
Dear Juan and Hauke Thank you for the suggestions. To answer Juan's questions, I am not too sure about whether the vectors will change or not. It is likely but I might have to get a better understanding to know whether that is the case or not. The peripherals will definitely change though, depending on the FPGA configuration we use. We do have some ideas in mind on how to tackle this but they are not concrete yet. To fix the dependency issue, I simply renamed the "startup_m2sxxx.S" file to "vectors.S". I am not too sure whether this completely solves the problem and is an acceptable fix or not, but hopefully that solves the problem. Your help is much appreciated. Kind regards Ashim Asharaph >>> Juan Ignacio Carrano 05/29/19 1:31 PM >>> [The e-mail server of the sender could not be verified (SPF Record)] Assim, Hauke, To comment a bit on Hauke's suggestion. On 29/5/19 08:47, Hauke Petersen wrote: > The general approach for porting CPUs in RIOT is to rely as much as > possible on shared code... That's very important, try to take advantage of what's already in RIOT. > . All the specific CPU > implementations have to provide, are their interrupt vector structure > (see e.g. `cpu/samd21/vectors.c` or `cpu/stm32f4/vectors.c`), Hauke, The SmartFusion is integrated is integrated into a FPGA, so the vectors can change depending on how one programs it (am I right, Assim?) It would be highly desirable if he does not have to translate the automatically generated assembly file into C. Specially considering it contains some platform-specific code (I see something about eSRAM EDAC and ECC mempory). I think this is the piece of code that introduces the dependency on vectors: https://github.com/RIOT-OS/RIOT/blob/7e3c382547430fae0a81e4f44c64d23e18629549/makefiles/arch/cortexm.inc.mk#L138 See the UNDEF. I may be wrong here, but I believe it is to prevent the symbols being dropped. What you can do is either: - Provide an empty vectors.c (to make the build system happy) AND add startup_m2sxxx.o to the UNDEF. - Add a rule to build vectors.o from startup_m2sxxx.S AND also make sure startup_m2sxxx.o does not get built. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT vectors for Smartfusion2 port
Dear Juan The board is the sf2-starter-kit and the CPU is the m2s010, which contains a Cortex M3. I have made a publicly accessible repo with all the code available at: https://github.com/ashimasharaph/SmartFusion2_riot_port I see now that the makefile in makefiles/arch/cortexm.inc.mk has the code # Explicitly tell the linker to link the startup code. # Without this the interrupt vectors will not be linked correctly! VECTORS_O ?= $(BINDIR)/cpu/vectors.o ifeq ($(COMMON_STARTUP),) export UNDEF += $(VECTORS_O) endif and the Makefile.include in the m2s_xxx cpu folder has: include $(RIOTMAKE)/arch/cortexm.inc.mk How should I go about removing that code and do I need to replace it with anything? Any help would be appreciated. Kind regards Ashim Asharaph >>> Juan Ignacio Carrano 05/28/19 5:01 PM >>> [The e-mail server of the sender could not be verified (SPF Record)] Hi Ashim, I assume you are basing your SmartFusion port on some existing CPU. If that's the case, it would be useful to know which one. Even better if you can link us to a publicly accessible repo. > I have tried including this file in the new cpu folder I > created but get the following error when trying to make: > arm-none-eabi-gcc: error: > /home/user/Desktop/SmartFusion2/testjig/riot/2019.04/examples/hello-world/bin/sf2-starter-kit/cpu/vectors.o: > > No such file or directory > The first question is why the build system is expecting to find vectors.o. Not all CPUs generate that file (in your case you would compile startup_m2sxxx.S into startup_m2sxxx.o) I believe the answer to this question lies in the CPU you started with. For example: you mention the LPC2387. If you compile any example with BOARD=msba2 (which uses that cpu) and look inside "bin/msba2/cpu" you will not find any vectors.o and that's OK. > How do I use the above file correctly in the RIOT port? Is there some > configuration that should be changed to use the file properly or should > I convert it to a vectors.c file? If so, how do I go about doing so? > AFAIK you should not need to convert anything, just place the .S file in your CPU directory, but without knowing the full contents of the dir it is hard to tell what is happening. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT vectors for Smartfusion2 port
Dear RIOT Developers I am currently working on a port for RIOT to the Microsemi SmartFusion2 board which has a Cortex M3. I see that most of the CPUs have a vectors.c file which specify all the interrupt vectors. Some of the other boards have an assembly file for startup such as the lpc2387 which define the interrupt vectors. I have attached an assembly file that is generated by some Microsemi software which defines the interrupt vectors. I have tried including this file in the new cpu folder I created but get the following error when trying to make: arm-none-eabi-gcc: error: /home/user/Desktop/SmartFusion2/testjig/riot/2019.04/examples/hello-world/bin/sf2-starter-kit/cpu/vectors.o: No such file or directory How do I use the above file correctly in the RIOT port? Is there some configuration that should be changed to use the file properly or should I convert it to a vectors.c file? If so, how do I go about doing so? Kind regards Ashim Asharaph startup_m2sxxx.S Description: Binary data ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Ethos global wired address
Dear RIOT community I am using ethos for a project I have. The computer needs to communicate with a samr21-xpro. The board needs to have a global address so that I can reach it. I have tried to adapt the gnrc_border_router example but I see only the wireless interface has a global address. How can I get the wired interface to also have a global address? Any help would be appreciated. Kind regards Ashim Asharaph ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] gcoap blockwise transfer
Dear Ken
So I decided to use the gcoap blockwise transfer from PR #11057 with a GET
request. On native it works fine. When testing on real hardware using two
samr21-xpro boards with one running the gnrc _border_router example, the block
transfer only completes successfully about 50% of the time with a 50kB file and
128 byte packets. The application says "gcoap: timeout for msg ID x". The
time at which the timeout occurs seems random at any point during the blockwise
transfer.
The final plan is to integrate the gcoap with wakaama and use both together for
an OTA firmware update. When the integrated version is used, the success rate
is about 5%. Are there any parameters or code that could be tweaked on either
the RIOT application or on the Californium file server to improve the success
rate? What could be causing the issue or how can I try to determine the problem?
Kind regards
Ashim Asharaph
>>> Ken Bannister 05/02/19 4:45 PM >>>
[The e-mail server of the sender could not be verified (SPF Record)]Hi
Ashim and welcome to RIOT!
As you say, we have two CoAP tools -- nanocoap and gcoap. Here are
your options.
In the latest release, 2019.04, nanocoap has server-based block
capabilities. So, it would work if Californium acted as a client and
PUT/POSTed the file contents to your nanocoap server. See the
nanocoap_server example in the source repository and documentation at
Modules > Networking > Nanocoap.
There also are PRs for full client/server block capabilities. In this
case it's probably easier to use gcoap because it's fully documented, but
a nanocoap client would work, too. See #11057 for the final PR in the
series. If you build the source documentation (make doc), you will find
detailed instructions and links to examples. See the Modules > Networking
> Gcoap topic.
I am the author of the PR series, and would appreciate you testing it
out. We are actively (if slowly) reviewing and merging these PRs.
Ken
On 5/2/19 2:05 PM, Ashim Asharaph wrote:
body p {
margin: 0.0px;
}
Dear RIOT developers
I'm sending a GET request from gcoap running on native to a
californium server hosting a file. The file is about 56kB insize. I can
receive the file correctly (multiple blocks) whenusing Californium
Copper. I can only receive one 512 byte blockof data through gcoap. I
have tried changing GCOAP_PDU_BUF_SIZEbut this only affects whether I
can receive the one block. Howdo I receive multiple blocks? Has coap
blockwise transfer beenimplemented in gcoap? Is nanocoap a suitable
alternative forreceiving the file?
Kind regards
Ashim Asharaph
___devel mailing
listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] gcoap blockwise transfer
Dear RIOT developers I'm sending a GET request from gcoap running on native to a californium server hosting a file. The file is about 56kB in size. I can receive the file correctly (multiple blocks) when using Californium Copper. I can only receive one 512 byte block of data through gcoap. I have tried changing GCOAP_PDU_BUF_SIZE but this only affects whether I can receive the one block. How do I receive multiple blocks? Has coap blockwise transfer been implemented in gcoap? Is nanocoap a suitable alternative for receiving the file? Kind regards Ashim Asharaph ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
