NuttX correct version
Hi When I create a library export of the NuttX project I receive a library *nuttx-export-12.4.0-RC0.tar.gz*. Is this correct or I have to get a *12.4.0* version? Thanks in advance Roberto
Re: Re: RPTUN usage
So, please check the remote core call uart_rpmsg_init with isconsole=true, and no other uart driver register as console. On Wed, Feb 7, 2024 at 9:15 PM yfliu2008 wrote: > Xiang. > > > > Thanks for that. Yes I can see hello echo from master to remote and vice > versa as you suggested. > > > > > Regards, > yf > > > > Original > > > > From:"Xiang Xiao"< xiaoxiang781...@gmail.com ; > > Date:2024/2/7 20:09 > > To:"dev"< dev@nuttx.apache.org ; > > Subject:Re: RPTUN usage > > > You can try: > >1. echo hello /dev/ttyRpmsg on one core >2. and cat /dev/ttyRpmsg on another core > > to confirm rpmsg uart work as expected before testing with cu. > > On Wed, Feb 7, 2024 at 8:00 PM yfliu2008 wrote: > > Xiang and Bowen, > > > > I noticed that I didn't initialize the call the "uart_rpmsg_init()" > properly thus last time "rpmsg-ttyRpmsg" end point didn't shown in the > "rpmsg dump" result. After fixing the call parameters, they shows out > now: > > > master rpmsg dump /dev/rptun/remote > > >Dump rpmsg info > between cpu > (master: yes)master <== remote: > > rpmsg vq RX: > > > > rpmsg vq TX: > > > > rpmsg ept list: > > > > >ept NS > > > >ept rpmsg-ttyRpmsg > > > > >ept rpmsg-ping > > > > rpmsg buffer list: > > > > >RX buffer, total 8, pending 0 > > > >TX buffer, total 8, pending 0 > > The "echo hello /dev/ttyRpmsg" command doesn't block any > more, > however the "cu" command doesn't work yet. I am not sure what is > still missing. I think it is better to make uart-rpmsg work first > before > try any other RPMsg device types. Please let me know if you have any > suggestions. > > > > Regards, > yf > > > > > Original > > > > From:"yfliu2008"< yfliu2...@qq.com ; > > Date:2024/2/7 19:20 > > To:"dev"< dev@nuttx.apache.org ; > > Subject:RPTUN usage > > > > Xiang Bowen, > > > > > Here I seemed have RPTUN running on the two cores of K230 device and > I can > use "rpmsg dump" to show some basic information on both cores: > > > > master rpmsg dump /dev/rptun/remote > > >Dump rpmsg info > between cpu > (master: yes)master <== remote: > > rpmsg vq RX: > > > > rpmsg vq TX: > > > > rpmsg ept list: > > > > >ept NS > > > >ept rpmsg-ping > > > > rpmsg buffer list: > > > > >RX buffer, total 8, pending 0 > > > > >TX buffer, total 8, pending 0 > > > remote rpmsg /dev/rptun/master > > nsh: > rpmsg: > missing required argument(s) > > > remote rpmsg dump /dev/rptun/master > > > > Dump rpmsg info between cpu (master: no)remote <== master: > > rpmsg vq RX: > > > > rpmsg vq TX: > > > > rpmsg ept list: > > > > >ept NS > > > > rpmsg buffer list: > > > > >RX buffer, total 8, pending 0 > > > >TX buffer, total 8, pending 0 > > > > However, I don't know how to further check the RPTUN link yet. It > seems > that "rpmsg ping /dev/rptun/remote 1 64 0 10" doesn't show anything. > Also > "echo hello /dev/ttyRpmsg" gets blocked. > > > > > > I tried "rpmsg ping" with "sim/rpserver" and "sim/rpproxy", it also > doesn't show any thing. However, the "echo hello /dev/ttyproxy" > command can show the message on console. > > > > > Can you please suggest where should I start looking for RPTUN trouble > shooting information? > > > > > Regards, > > yf
Re: RPTUN usage
You can try: 1. echo hello > /dev/ttyRpmsg on one core 2. and cat /dev/ttyRpmsg on another core to confirm rpmsg uart work as expected before testing with cu. On Wed, Feb 7, 2024 at 8:00 PM yfliu2008 wrote: > Xiang and Bowen, > > > > I noticed that I didn't initialize the call the "uart_rpmsg_init()" > properly thus last time "rpmsg-ttyRpmsg" end point didn't shown in the > "rpmsg dump" result. After fixing the call parameters, they shows out now: > > > master rpmsg dump /dev/rptun/remote > > Dump rpmsg info between cpu > (master: yes)master <== remote: > > rpmsg vq RX: > > > > rpmsg vq TX: > > > > rpmsg ept list: > > > > ept NS > > > > ept rpmsg-ttyRpmsg > > > > ept rpmsg-ping > > > > rpmsg buffer list: > > > > RX buffer, total 8, pending 0 > > > TX buffer, total 8, pending 0 > > The "echo hello /dev/ttyRpmsg" command doesn't block any more, > however the "cu" command doesn't work yet. I am not sure what is > still missing. I think it is better to make uart-rpmsg work first before > try any other RPMsg device types. Please let me know if you have any > suggestions. > > > > Regards, > yf > > > > > Original > > > > From:"yfliu2008"< yfliu2...@qq.com ; > > Date:2024/2/7 19:20 > > To:"dev"< dev@nuttx.apache.org ; > > Subject:RPTUN usage > > > > Xiang Bowen, > > > > > Here I seemed have RPTUN running on the two cores of K230 device and I can > use "rpmsg dump" to show some basic information on both cores: > > > > master rpmsg dump /dev/rptun/remote > > Dump rpmsg info between cpu > (master: yes)master <== remote: > > rpmsg vq RX: > > > > rpmsg vq TX: > > > > rpmsg ept list: > > > > ept NS > > > > ept rpmsg-ping > > > > rpmsg buffer list: > > > > RX buffer, total 8, pending 0 > > > > TX buffer, total 8, pending 0 > > > remote rpmsg /dev/rptun/master > > nsh: rpmsg: > missing required argument(s) > > > remote rpmsg dump /dev/rptun/master > > > Dump rpmsg info between cpu (master: no)remote <== master: > > rpmsg vq RX: > > > > rpmsg vq TX: > > > > rpmsg ept list: > > > > ept NS > > > > rpmsg buffer list: > > > > RX buffer, total 8, pending 0 > > > TX buffer, total 8, pending 0 > > > > However, I don't know how to further check the RPTUN link yet. It seems > that "rpmsg ping /dev/rptun/remote 1 64 0 10" doesn't show anything. Also > "echo hello /dev/ttyRpmsg" gets blocked. > > > > > > I tried "rpmsg ping" with "sim/rpserver" and "sim/rpproxy", it also > doesn't show any thing. However, the "echo hello /dev/ttyproxy" > command can show the message on console. > > > > > Can you please suggest where should I start looking for RPTUN trouble > shooting information? > > > > > Regards, > > yf
Re: STM32H7 board with ethernet
I did some tests and sometimes it works and sometimes (the most times...) it gives the error... The error usually appears when I give the command nsh> ifconfig or nsh> renew eth0 but not all the times. I think that it can be a problem with memory sizes; I'll try more investigations BR Roberto NuttShell (NSH) NuttX-12.4.0-RC0 nsh> ping 192.168.1.155 PING 192.168.1.155 56 bytes of data 56 bytes from 192.168.1.155: icmp_seq=0 time=38.0 ms 56 bytes from 192.168.1.155: icmp_seq=1 time=62.0 ms 56 bytes from 192.168.1.155: icmp_seq=2 time=104.0 ms 56 bytes from 192.168.1.155: icmp_seq=3 time=124.0 ms 56 bytes from 192.168.1.155: icmp_seq=4 time=62.0 ms 56 bytes from 192.168.1.155: icmp_seq=5 time=84.0 ms 56 bytes from 192.168.1.155: icmp_seq=6 time=12.0 ms 56 bytes from 192.168.1.155: icmp_seq=7 time=46.0 ms 56 bytes from 192.168.1.155: icmp_seq=8 time=75.0 ms 56 bytes from 192.168.1.155: icmp_seq=9 time=106.0 ms 10 packets transmitted, 10 received, 0% packet loss, time 10010 ms rtt min/avg/max/mdev = 12.000/71.300/124.000/32.655 ms nsh> ifconfig eth0 Link encap:Ethernet HWaddr 52:d3:8e:aa:5d:41 at UP mtu 1486 inet addr:192.168.1.251 DRaddr:192.168.1.1 Mask:255.255.255.0 lo Link encap:Local Loopback at RUNNING mtu 1518 inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0 IPv4 TCP UDP ICMP Received 000c 0002 000a Dropped IPv4 VHL: Frg: Checksum TCP ACK: SYN: RST: Type Sent 000c 0002 000a Rexmit On 2/6/24 16:55, Gregory Nutt wrote: The network monitor is part of apps/netutils/netinit so it is not a part of NSH. NSH can automatically perform the network initialization if so configured and which, optionally, starts the network monitor thread. But the logic is not architecturally a part of NSH nor does it depend on N SH. On 2/6/2024 9:32 AM, Nathan Hartman wrote: On Tue, Feb 6, 2024 at 8:45 AM Sebastien Lorquet wrote: However, the default network configuration provided in NuttX examples is cumbersome and too much linked with NSH It can work for simple tests and demos, but you will have to write a proper network management daemon if you plan to use more than one network app. It would be a nice thing if the network management daemon could be factored out of NSH so that boards that don't run NSH could have the same network management without implementing it again. Cheers Nathan
