Xiang,
Thank you! It's late here in Seattle WA USA; I'll try it tomorrow!
cheers
adam
On Mon, Feb 10, 2020 at 10:40 PM Xiang Xiao
wrote:
> MAC is assigned through:
> tapdev_init->set_macaddr->netdriver_setmacaddr
>
> netinit task is responsible for the networking initialization, so it
> is a g
MAC is assigned through:
tapdev_init->set_macaddr->netdriver_setmacaddr
netinit task is responsible for the networking initialization, so it
is a good indicator that the iniitaliation finish succesfully if ps
doesn't list it any more.
Here is my config:
#
# This file is autogenerated: PLEASE DO N
Xiang,
Looks like attachments aren't making it through for some reason. Would you
be willing to just paste the config into an email message?
BTW my ethernet interface isn't getting a MAC address... it's all 0's. Your
virtual ethernet has one. So something is wrong with the netinit for my
interfac
It's my full config, but to avoid the LittleVGL downloading, I remove
some graphic related config.
Here is my output with the latest mainline:
xiaoxiang@xiaoxiang-VirtualBox:~/nuttx/nuttx$ sudo ./nuttx
NuttShell (NSH) NuttX-8.2
nsh> ps
PID GROUP PRI POLICY TYPENPX STATEEVENT SIGMAS
Thank you Xiang.
I tried your config options, but the simulator still crashes when I do a
ping.
You didn't attach a whole config file– would you be willing to send one?
cheers
adam
On Mon, Feb 10, 2020 at 8:50 PM Xiang Xiao
wrote:
> Do you enable CONFIG_SIM_NET_BRIDGE?
> To get the basic netw
Do you enable CONFIG_SIM_NET_BRIDGE?
To get the basic network, the below options are required:
CONFIG_NET=y
CONFIG_NETINIT_DHCPC=y
CONFIG_NETUTILS_DHCPC=y
CONFIG_NET_ICMP=y
CONFIG_NET_ICMP_SOCKET=y
CONFIG_NET_UDP=y
CONFIG_NET_UDP_BINDTODEVICE=y
CONFIG_SIM_NET_BRIDGE=y
CONFIG_SYSTEM_PING=y
IPv
Yamamoto-san,
Could you tell me what kind of network applications you
are trying with Spresense + GS2200M?
Also, are you using a Wi-Fi router or directly connecting to
a PC in AP mode? I'd like to know about your network
environment.
On 2020/02/11 1:20, "Takashi Yamamoto" wrote:
Thank you
Xiang,
I changed my config so I now see an eth0 interface, but when I ifconfig it
to have a static IP on my local net, I can't ping anything– I get this:
>
> nsh>ping 192.168.46.1
> ERROR: socket() failed: 106
>
Here's my ifconfig output:
>
> nsh>ifconfig
> lo Link encap:Local Loopback at UP
>
Xiang,
Thanks for the tips! I tried to get this working, but I don't see any
network interfaces on my nuttx system other than loopback.
I ran the script on my Linux box, it created a nuttx0: interface with an IP
address. But on the nuttx simulator all I see is this:
nsh> ifconfig
> lo Link enca
Adam, please follow this instruction if you want to connect the real
network instead loopback:
https://github.com/apache/incubator-nuttx/pull/249/commits/1b489449f790c2b4618df9133114bb05f0132e87
The setup is very simple, you don't need config any IP address manually.
Thanks
Xiang
On Tue, Feb 11,
I put a log statement in sam_txdone()... what appears to be happening is
that the TX descriptor-in-use case is executed at sam_txdone(), line 1364,
in sam_gmac.c, so the TX buffer fills up.
So it seems like the GMAC driver or hardware gets into a state where it is
not able to send packets until th
It seems like the SAMA5D36 GMAC driver in sam_gmac.c is running out of TX
buffers. I can set a large number of buffers, but it always seems to run
out. I get these entries in the log:
[ 402.31] sam_transmit: Disabling RX interrupts
That seems to come from line 769 which notes that it's doing
Well, at least that is a lot of progress for a day. Going from clueless
> to pinpointing the failure.
>
Greg,
Yes! Thank you for the help.
cheers
adam
--
Adam Feuer
I turned the debugging output on – the stuff Greg showed me in the email
thread on simulator networking. So I have more data.
What appears to be happening is that the GMAC driver's tx timeout fires,
and the GMAC is restarted:
[ 528.35] sam_txtimeout_work: ERROR: Timeout!
[ 528.35] s
I turned the debugging output on – the stuff Greg showed me in the email
thread on simulator networking. So I have more data.
What appears to be happening is that the GMAC driver's tx timeout fires,
and the GMAC is restarted:
[ 528.35] sam_txtimeout_work: ERROR: Timeout!
[ 528.35] sam_i
Greg,
Ok, I will see what I can do to improve the sim tcpblaster.
-adam
On Mon, Feb 10, 2020 at 1:06 PM Gregory Nutt wrote:
>
> >
> >> The debugging output is great! Thanks. I'll try that on the SAMA5D36
> >> too.
> >> With CONFIG_SIM_WALLTIME=y the loopback tcpblaster seems to chunk along
> >
The debugging output is great! Thanks. I'll try that on the SAMA5D36
too.
With CONFIG_SIM_WALLTIME=y the loopback tcpblaster seems to chunk along
pretty quickly:
Sent 50 buffers: 200.0 Kb (avg 4.0 Kb) in 7823.46 Sec ( 0.0 Kb/Sec)
Received 50 buffers: 66.6 Kb (avg 1.3 Kb) in 2575.5
The debugging output is great! Thanks. I'll try that on the SAMA5D36 too.
With CONFIG_SIM_WALLTIME=y the loopback tcpblaster seems to chunk along
pretty quickly:
Sent 50 buffers:200.0 Kb (avg 4.0 Kb) in 7823.46 Sec (0.0 Kb/Sec)
Received 50 buffers: 66.6 Kb (avg 1.3 Kb) in 2575.5
Greg,
The debugging output is great! Thanks. I'll try that on the SAMA5D36 too.
With CONFIG_SIM_WALLTIME=y the loopback tcpblaster seems to chunk along
pretty quickly:
Sent 50 buffers:200.0 Kb (avg 4.0 Kb) in 7823.46 Sec (0.0 Kb/Sec)
Received 50 buffers: 66.6 Kb (avg 1.3 Kb) in 257
Received 50 buffers: 66.8 Kb (avg 1.3 Kb) in 101.00 Sec ( 0.6
Kb/Sec)
So maybe it's going very very slowly?
Okay. I just didn't way long enough. Remove CONFIG_SIM_WALLTIME=y
from your configuration and it should go a lot faster (maybe too fast).
OR maybe there really is some ki
Oops, I spoke too soon. I did get an output line after a bunch of minutes:
Received 50 buffers: 66.8 Kb (avg 1.3 Kb) in 101.00 Sec (0.6
Kb/Sec)
So maybe it's going very very slowly?
Okay. I just didn't way long enough. Remove CONFIG_SIM_WALLTIME=y from
your configuration and
On 2/10/2020 2:19 PM, Adam Feuer wrote:
Greg,
I tried the IPv6 version you sent... It starts, but there's no further
output:
nsh> tcpclient
Binding to IPv6 Address: :::::::
server: Accepting connections on port 5471
Connecting to IPv6 Address: :::000
Yeah it's going but very slowly:
> Received 50 buffers: 66.8 Kb (avg 1.3 Kb) in 101.00 Sec (0.6
> Kb/Sec)
> Received 50 buffers: 66.6 Kb (avg 1.3 Kb) in 101.00 Sec (0.6
> Kb/Sec)
> Sent 50 buffers:200.0 Kb (avg 4.0 Kb) in 292.90 Sec (0.6 Kb/Sec)
> Received 50 buffers:
Well, it does look like it is sending TCP packets. I switched to IPv4
and enabled debug output. In the debug output I can see that it is
sending and receiving TCP packets and that the TCP packets are being
ACKed. But, for some reason, there is no printf output. I think TCP
is working in thi
Oops, I spoke too soon. I did get an output line after a bunch of minutes:
Received 50 buffers: 66.8 Kb (avg 1.3 Kb) in 101.00 Sec (0.6
> Kb/Sec)
>
So maybe it's going very very slowly?
-adam
On Mon, Feb 10, 2020 at 12:19 PM Adam Feuer wrote:
> Greg,
>
> I tried the IPv6 version you
Greg,
I tried the IPv6 version you sent... It starts, but there's no further
output:
>
> nsh> tcpclient
> Binding to IPv6 Address: :::::::
> server: Accepting connections on port 5471
> Connecting to IPv6 Address: :::::::0100
> client: C
nsh> tcpclient
Binding to IPv6 Address: :::::::
server: Accepting connections on port 5471
Connecting to IPv6 Address: :::::::0100
client: Connected
server: Connection accepted -- receiving
Then nothing more.
I
I am creating a simulator example that runs the TCP blaster example
using the loopback 127.0.0.1 device. I will give that to you once I
verify it.
Thanks Greg. That is exactly what I am trying to create, so I can get some
insight into what's wrong with my SAMA5D36 configuration.
I submitted
> I am creating a simulator example that runs the TCP blaster example
> using the loopback 127.0.0.1 device. I will give that to you once I
> verify it.
>
Thanks Greg. That is exactly what I am trying to create, so I can get some
insight into what's wrong with my SAMA5D36 configuration.
cheers
a
I'm trying to get the NuttX simulator working with TCP/IP networking. I
used the sim:nsh defconfig as a base, then used "make menuconfig" to select
TCP/IP, ICMP, and ping commands.
My host is Ubuntu 19.10 Eoan. I installed bridge-utils and configured a
bridge device nuttx0 and gave it an IP ad
Hi,
I'm trying to get the NuttX simulator working with TCP/IP networking. I
used the sim:nsh defconfig as a base, then used "make menuconfig" to select
TCP/IP, ICMP, and ping commands.
My host is Ubuntu 19.10 Eoan. I installed bridge-utils and configured a
bridge device nuttx0 and gave it an IP a
my colleague worked on it
https://developer.sony.com/posts/zerynth-provides-python-support-for-spresense-microcontroller-board-from-sony/
Regards
Alin
On Mon, Feb 10, 2020 at 5:16 PM Xiang Xiao
wrote:
> Alin,
> do you upstream your work? I can't find here:
> https://github.com/micropython/mic
Thank you.
It looks like the same board as I have.
For me I feel it works 30% of the time.
I wonder what's the difference.
On Tue, Feb 11, 2020, 01:10 Alin Jerpelea wrote:
> I am using this one
>
> https://www.chip1stop.com/SWE/en/product/detail?partId=IDYC-001&mpn=iS110B&keyword=spresense&z
Alin,
do you upstream your work? I can't find here:
https://github.com/micropython/micropython/tree/master/ports
There even has a zephyr porting.
It's greet if you can upstream nuttx porting to the mainline.
On Tue, Feb 11, 2020 at 12:04 AM Alin Jerpelea wrote:
>
> Hi
>
> as a best practice inste
I am using this one
https://www.chip1stop.com/SWE/en/product/detail?partId=IDYC-001&mpn=iS110B&keyword=spresense&zaikoFlg=false&partSameFlg=false
On Mon, Feb 10, 2020 at 5:06 PM Xiang Xiao
wrote:
> Ubuntu 18.04 run on VirtualBox with NAT. For me, I just spend the time
> with the hardware my
Ubuntu 18.04 run on VirtualBox with NAT. For me, I just spend the time
with the hardware my project will use or the simulator.
On Mon, Feb 10, 2020 at 11:53 PM Takashi Yamamoto
wrote:
>
> which host os are you using?
>
> On Tue, Feb 11, 2020 at 12:46 AM Xiang Xiao wrote:
> >
> > We use sim which
Hi
as a best practice instead of forking a project and maintaining it you
should try to upstream the needed patches do that the project can be built
on top of NuttX.
For reference you can check how microPython or circuit python are built on
top of NuttX without the need of forking the code
https:
are you using the same wifi board as i am?
https://idy-design.com/product/is110b.html
spresense itself work great for me. the wifi board is not.
On Tue, Feb 11, 2020 at 12:57 AM Alin Jerpelea wrote:
>
> Hi
>
> I do not know how stable are other boards but I can recommend the spresense
> board sin
Hi
I do not know how stable are other boards but I can recommend the spresense
board since I am working on it and the WiFi implementation seems to be
stable
//Alin
On Mon, Feb 10, 2020, 16:53 Takashi Yamamoto
wrote:
> which host os are you using?
>
> On Tue, Feb 11, 2020 at 12:46 AM Xiang Xiao
How about we host the active project porting on github.com/nuttx? so
the community could share the work.
The ideal solution would be to have the Pahu MQTT support NuttX natively
in their code. Then you do not have to port it at all. We don't want
responsibility for maintaining forks of other
which host os are you using?
On Tue, Feb 11, 2020 at 12:46 AM Xiang Xiao wrote:
>
> We use sim which work very well and stable, all
> TCP/IP(IP[v6]/ICMP[v6]/UDP/DHCP/DNS/NTP/TCP/TELNET) stack can run in
> this virtual environment.
>
> On Mon, Feb 10, 2020 at 11:41 PM Takashi Yamamoto
> wrote:
>
On Tue, Feb 11, 2020 at 12:34 AM Gregory Nutt wrote:
>
>
> > How about we host the active project porting on github.com/nuttx? so
> > the community could share the work.
> The ideal solution would be to have the Pahu MQTT support NuttX natively
> in their code. Then you do not have to port it at
i'm working on some apps which need network connectivity.
does anyone have a recommendation of a board for development on which
i can run nuttx reliably with network? (wifi or ethernet)
either a real board i can purchase, or emulators/simulators.
right now i'm using spresense and gs2200m-based
We use sim which work very well and stable, all
TCP/IP(IP[v6]/ICMP[v6]/UDP/DHCP/DNS/NTP/TCP/TELNET) stack can run in
this virtual environment.
On Mon, Feb 10, 2020 at 11:41 PM Takashi Yamamoto
wrote:
>
> hi,
>
> i'm working on some apps which need network connectivity.
> does anyone have a recomm
hi,
i'm working on some apps which need network connectivity.
does anyone have a recommendation of a board for development on which
i can run nuttx reliably with network? (wifi or ethernet)
either a real board i can purchase, or emulators/simulators.
right now i'm using spresense and gs2200m-base
How about we host the active project porting on github.com/nuttx? so
the community could share the work.
The ideal solution would be to have the Pahu MQTT support NuttX natively
in their code. Then you do not have to port it at all. We don't want
responsibility for maintaining forks of othe
i'm looking for something like __Darwin__, __Linux__, etc for nuttx
so that i can have something like the following in my app.
#ifdef __NuttX__
#include
#endif
i found some Make.defs defining -D__NuttX__.
is it commonly used?
In general, those definitions come from the compiler, not from t
How about we host the active project porting on github.com/nuttx? so
the community could share the work.
On Mon, Feb 10, 2020 at 11:11 PM Gregory Nutt wrote:
>
>
> > I wanted to use mqtt on nuttx.
> > I found a nuttx port of paho.mqtt.embedded-c in spresense sdk. [1]
> > I modified it for my nutt
hi,
i'm looking for something like __Darwin__, __Linux__, etc for nuttx
so that i can have something like the following in my app.
#ifdef __NuttX__
#include
#endif
i found some Make.defs defining -D__NuttX__.
is it commonly used?
I wanted to use mqtt on nuttx.
I found a nuttx port of paho.mqtt.embedded-c in spresense sdk. [1]
I modified it for my nuttx $(APPDIR)/external.
you can find it here: https://github.com/yamt/mqtt_nuttx
while it worked, i'm not quite happy with having a fork like this.
can anyone suggest a bette
hi,
I wanted to use mqtt on nuttx.
I found a nuttx port of paho.mqtt.embedded-c in spresense sdk. [1]
I modified it for my nuttx $(APPDIR)/external.
you can find it here: https://github.com/yamt/mqtt_nuttx
while it worked, i'm not quite happy with having a fork like this.
can anyone suggest a bett
xiaoxiang781216 merged pull request #7: cibuild.sh: decouple -b option to do
run_builds only
URL: https://github.com/apache/incubator-nuttx-testing/pull/7
This is an automated message from the Apache Git Service.
To respond
is there any support for thread aware debugging using JLink? Something
like sony/openocd-nuttx but usable with JLink adapter.
I have heard "through the grapevine" that such a work is in progress but
have no further information. I would suggest that you contact Segger
directly.
Hello,
is there any support for thread aware debugging using JLink? Something
like sony/openocd-nuttx but usable with JLink adapter.
Thanks.
Petr
54 matches
Mail list logo
