date:20240116

Re: GPIO drivers

2024-01-16 Thread Stewart Charnell


Hello Bowen,

Thank you for responding to my question. Yes I think the relay framework 
will do what I want, I will try it out.


Kind regards

Stewart Charnell

On 17/01/2024 03:23, 汪博文 wrote:

Hello,

I'm Bowen Wang and nice to answer your question. Please correct me If 
I understand wrong.


I think you want to use the relay framework 
in nuttx/drivers/power/relay/relay.c and relay_gpio.c,
which are added by me in PR: power/relay: add relay driver framework 
for NuttX by CV-Bowen · Pull Request #7954 · apache/nuttx (github.com) 
.


The realy framework has two part:

1. The first part is relay.c, relay.c did a very simple thing: convert 
user ioctl(RELAYIOC_SET/GET) to the relay driver implemented 
dev->ops->set()/get(),

and you can follow the following steps to implement a relay driver:
a. implement the relay ops (set()/get());
b. call relay_register() to register your relay driver (just like 
relay_gpio.c does);


2. The second part is relay_gpio.c, relay_gpio.c base on the *alreay 
implemented* gpio driver (ioexpander) to resigter a relay driver, so 
if you has implemented
a ioexpander driver, you can enable config: CONFIG_RELAY_GPIO and then 
call relay_gpio_register() to register a driver, a simple example in 
sim is:


```c
diff --git a/boards/sim/sim/sim/src/sim_ioexpander.c 
b/boards/sim/sim/sim/src/sim_ioexpander.c

index 599ac68743..9397967a24 100644
--- a/boards/sim/sim/sim/src/sim_ioexpander.c
+++ b/boards/sim/sim/sim/src/sim_ioexpander.c
@@ -29,6 +29,7 @@
 #include 
 #include 
+#include 
 #include "sim.h"
@@ -76,6 +77,11 @@ int sim_gpio_initialize(void)
   IOEXP_SETOPTION(ioe, 1, IOEXPANDER_OPTION_INTCFG,
                   (void *)IOEXPANDER_VAL_DISABLE);
   gpio_lower_half(ioe, 1, GPIO_OUTPUT_PIN, 1);
+  int ret = relay_gpio_register(ioe, 1, false, "/dev/relay0");
+  if (ret < 0)
+    {
+      _err("relay register error\n");
+    }
   /* Pin 2: an non-inverted, edge interrupting pin */
```

And I'm sorry that I missed the docs and examples about the new added 
relay framework, I will add this later.


Kind regards
Bowen Wang



Bowen Wang, wangbow...@xiaomi.com

*From:* Stewart Charnell 
*Date:* 2024-01-17 04:33
*To:* dev@nuttx.apache.org
*Subject:* [External Mail][Quarantine]GPIO drivers

Hello,
I have a processor board with GPIO ports which I would like to use to
control such things as relays and PSU enable pins.
Do I need to write a GPIO driver? There is an I/O expander driver. Is
the I/O expander driver specific to expanders or can it be used
for GPIO
control?
Kind regards
Stewart Charnell

#/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 
This e-mail and its attachments contain confidential information from 
XIAOMI, which is intended only for the person or entity whose address 
is listed above. Any use of the information contained herein in any 
way (including, but not limited to, total or partial disclosure, 
reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, 
please notify the sender by phone or email immediately and delete 
it!**/#

Re: TUN device (PPP) issue?

2024-01-16 Thread Zhe Weng 翁�

Hi Kian,


Which version of NuttX are you working on? It behaves like a problem I've met 
before. Do you have this commit in your code? If not, maybe you could have a 
try: 
https://github.com/apache/nuttx/commit/e2c9aa65883780747ca00625a1452dddc6f8a138


Best regards

Zhe



From: Kian Karas (KK) 
Sent: Tuesday, January 16, 2024 11:53:06 PM
To: dev@nuttx.apache.org
Subject: TUN device (PPP) issue?

Hi community

I am experiencing an issue with PPP/TUN and reception of packets. The network 
stack reports different decoding errors in the received packets e.g.:
[   24.56] [  WARN] ppp: ipv4_in: WARNING: IP packet shorter than length in 
IP header

I can reproduce the issue by sending a number of packets (from my PC over PPP 
to the TUN device in NuttX),  which are all larger than can fit into one IOB 
*and* which are ignored (e.g. unsupported protocol or IP destination) - i.e. 
*not* triggering a response / TX packet. I then send a correct ICMP echo 
request from my PC to NuttX, which causes the above error to be reported.

The following PC commands will trigger the error message. My PC has IP 
172.29.4.1 and the NuttX ppp interface has 172.29.4.2. Note the first command 
sends to the *wrong* IP address so that NuttX ignores the ICMP messages. The 
second commands uses the IP of NuttX and should result in a response. I run the 
test after a fresh boot and with no other network traffic to/from NuttX.

$ ping -I ppp0 -W 0.2 -i 0.2 -c 13 172.29.4.3 -s 156
$ ping -I ppp0 -W 0.2 -c 1 172.29.4.2 -s 0

If I skip the first command, ping works fine.

I think the issue is caused by the IOB management in the TUN device driver 
(drivers/net/tun.c). I am new to NuttX, so I don't quite understand the correct 
use of IOB, so I am just guessing here. I think that when a packet is received 
by tun_write() and too large to fit into a single IOB *and* the packet is 
ignored, the IOB chain "lingers" and is not freed. Subsequent packets received 
by tun_write() does not end up in the beginning of the first IOB and the 
IP/TCP/UDP header may then be split across IOB boundary. The network stack 
assumes the protocol headers are not split across IOB boundaries, so the 
network stack ends up reading outside the IOB io_data[] array boundaries 
resulting in undefined behavior.

With CONFIG_IOB_DEBUG enabled, notice how the "avail" value decrease for each 
ignored packet until the final/correct ICMP request (at time 24.54) is 
copied to the second IOB in the chain.

[   10.06] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.06] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=0 
len=184 next=0
[   10.06] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 182 
bytes new len=182
[   10.07] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 added to the 
chain
[   10.07] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=0 len=2 
next=0
[   10.08] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 2 bytes 
new len=2
[   10.08] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.08] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
[   10.26] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.26] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=168 
len=184 next=0x24002a50
[   10.27] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 168 
bytes new len=168
[   10.27] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=2 
len=16 next=0
[   10.28] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 16 bytes 
new len=16
[   10.28] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.28] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
[   10.46] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.47] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=154 
len=184 next=0x24002a50
[   10.47] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 154 
bytes new len=154
[   10.48] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=16 
len=30 next=0
[   10.48] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 30 bytes 
new len=30
[   10.48] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.49] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
...
[   12.50] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   12.51] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=14 
len=184 next=0x24002a50
[   12.51] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 14 bytes 
new len=14
[   12.52] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=156 
len=170 next=0
[   12.52] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 170 
bytes new len=170
[   12.52] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[

Re: [External Mail][Quarantine]GPIO drivers

2024-01-16 Thread 汪博文

Hello,

I'm Bowen Wang and nice to answer your question. Please correct me If I 
understand wrong.

I think you want to use the relay framework in 
nuttx/drivers/power/relay/relay.c and relay_gpio.c,
which are added by me in PR: power/relay: add relay driver framework for NuttX 
by CV-Bowen · Pull Request #7954 · apache/nuttx 
(github.com).

The realy framework has two part:

1. The first part is relay.c, relay.c did a very simple thing: convert user 
ioctl(RELAYIOC_SET/GET) to the relay driver implemented dev->ops->set()/get(),
and you can follow the following steps to implement a relay driver:
a. implement the relay ops (set()/get());
b. call relay_register() to register your relay driver (just like relay_gpio.c 
does);

2. The second part is relay_gpio.c, relay_gpio.c base on the alreay implemented 
gpio driver (ioexpander) to resigter a relay driver, so if you has implemented
a ioexpander driver, you can enable config: CONFIG_RELAY_GPIO and then call 
relay_gpio_register() to register a driver, a simple example in sim is:

```c
diff --git a/boards/sim/sim/sim/src/sim_ioexpander.c 
b/boards/sim/sim/sim/src/sim_ioexpander.c
index 599ac68743..9397967a24 100644
--- a/boards/sim/sim/sim/src/sim_ioexpander.c
+++ b/boards/sim/sim/sim/src/sim_ioexpander.c
@@ -29,6 +29,7 @@

 #include 
 #include 
+#include 

 #include "sim.h"

@@ -76,6 +77,11 @@ int sim_gpio_initialize(void)
   IOEXP_SETOPTION(ioe, 1, IOEXPANDER_OPTION_INTCFG,
   (void *)IOEXPANDER_VAL_DISABLE);
   gpio_lower_half(ioe, 1, GPIO_OUTPUT_PIN, 1);
+  int ret = relay_gpio_register(ioe, 1, false, "/dev/relay0");
+  if (ret < 0)
+{
+  _err("relay register error\n");
+}

   /* Pin 2: an non-inverted, edge interrupting pin */
```

And I'm sorry that I missed the docs and examples about the new added relay 
framework, I will add this later.

Kind regards
Bowen Wang



Bowen Wang, wangbow...@xiaomi.com

From: Stewart Charnell
Date: 2024-01-17 04:33
To: dev@nuttx.apache.org
Subject: [External Mail][Quarantine]GPIO drivers

Hello,

I have a processor board with GPIO ports which I would like to use to
control such things as relays and PSU enable pins.

Do I need to write a GPIO driver? There is an I/O expander driver. Is
the I/O expander driver specific to expanders or can it be used for GPIO
control?

Kind regards

Stewart Charnell




#/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
 This e-mail and its attachments contain confidential information from XIAOMI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!**/#

Re: [Article] NuttX in the Web Browser (TinyEMU + VirtIO)

2024-01-16 Thread Nathan Hartman

Hi Lup,

That's great! The NuttX website is hosted from the nuttx-website repository
(see [1]) so it should be pretty easy to add it there. The site is coded
with jekyll. Everyone in the project can update the site and quite a few of
us have done it at one time or another. If you have any questions just ask
here on the list!

Cheers,
Nathan

[1] https://github.com/apache/nuttx-website


On Tue, Jan 16, 2024 at 6:46 PM Lee, Lup Yuen  wrote:

> Hi Nathan: Yep it's easy to host the NuttX Online Demo on any website, it's
> just a bunch of Static HTML, JavaScript and WebAssembly files. Please lemme
> know whom I should work with :-)
>
> Meanwhile I'll upstream the TinyEMU RISC-V Port of NuttX. Thanks!
>
> Lup
>
> On Wed, Jan 17, 2024 at 8:40 AM Nathan Hartman 
> wrote:
>
> > This is very cool! Could it be possible to put it direct on the NuttX
> > website? e.g., "Try NuttX in the browser"
> >
> > On Mon, Jan 15, 2024 at 5:58 PM Alan C. Assis  wrote:
> >
> > > Interesting!
> > > Thank you very much Lup for investigating it further!
> > >
> > > BR,
> > > Alan
> > >
> > > On Mon, Jan 15, 2024 at 2:34 AM Lee, Lup Yuen 
> wrote:
> > >
> > > > << Do you think it is possible to find an alternative to use the
> users'
> > > > browser connection to communicate to the Internet? This way it avoids
> > > > users' consumption of all internet limits on the server side. >>
> > > >
> > > > Hi Alan: You're right, TinyEMU Emulator talks to a WebSocket VPN
> hosted
> > > at
> > > > `
> > > > relay.widgetry.org` that's throttled at 40 kB/s (for free, fair
> use).
> > > But
> > > > I
> > > > don't see a good alternative to this WebSocket VPN:
> > > >
> > > > (1) Can the Web Browser talk directly to the internet without
> WebSocket
> > > > VPN?
> > > >
> > > > TinyEMU and VirtIO Networking are sending Ethernet Frames / IP
> Packets
> > > from
> > > > the Web Browser to the internet. But Web Browsers are not allowed to
> > send
> > > > IP Packets directly. That's why we need to tunnel the packets
> through a
> > > > WebSocket VPN.
> > > >
> > > > (2) Can we host our own WebSocket VPN on our Local Computer?
> > > >
> > > > Possibly. But then we will have to host the Web Server on our Local
> > > > Computer too. Which makes it cumbersome to install.
> > > >
> > > > (3) Can we host the WebSocket VPN on a server operated by the NuttX
> > > > Project?
> > > >
> > > > Probably not, because we need to throttle the internet traffic for
> > free,
> > > > fair use. And prevent abuse.
> > > >
> > > > I've documented my findings on TinyEMU, VirtIO Networking and
> WebSocket
> > > > VPN:
> > > >
> > > >
> > >
> >
> https://github.com/lupyuen/nuttx-tinyemu#tinyemu-networking-in-the-web-browser
> > > >
> > > > Lup
> > > >
> > > > On Sun, Jan 14, 2024 at 9:54 PM Alan C. Assis 
> > wrote:
> > > >
> > > > > Hi Lup,
> > > > >
> > > > > Thank you very much!
> > > > >
> > > > > Looking at the WebSocket VPN article it said the connection goes
> > > through
> > > > > the server hosting the emulator.
> > > > >
> > > > > Do you think it is possible to find an alternative to use the
> users'
> > > > > browser connection to communicate to the Internet?
> > > > > This way it avoids users' consumption of all internet limits on the
> > > > server
> > > > > side.
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > > > > On Sun, Jan 14, 2024 at 4:17 AM Lee, Lup Yuen 
> > > wrote:
> > > > >
> > > > > > Thanks Alan! Yep "The Construct" looks like a cool way to learn
> ROS
> > > > > online,
> > > > > > we should do something similar for Teaching NuttX Online!
> > > > > >
> > > > > > As for Emulated Networking in the Web Browser: TinyEMU Emulator
> > > > supports
> > > > > > VirtIO Networking. But it's tunnelled through a WebSocket VPN,
> > > because
> > > > of
> > > > > > browser limitations.
> > > > > >
> > > > > > I might test this with NuttX and see how well it works. (I'm also
> > > keen
> > > > to
> > > > > > emulate Ox64 BL808 RISC-V SBC in the Web Browser)
> > > > > >
> > > > > > TinyEMU VirtIO Networking: https://bellard.org/jslinux/tech.html
> > > > > >
> > > > > > WebSocket VPN:
> > > > > >
> > https://www.benjamincburns.com/2013/11/10/jor1k-ethmac-support.html
> > > > > >
> > > > > > Lup
> > > > > >
> > > > > > On Sun, Jan 14, 2024 at 8:10 AM Alan C. Assis  >
> > > > wrote:
> > > > > >
> > > > > > > Really cool Lup!
> > > > > > >
> > > > > > > Maybe it could be used for training and deduction purposes. Do
> > you
> > > > know
> > > > > > > "The Construct" they are using a solution like that to run
> Linux
> > in
> > > > the
> > > > > > > browser:
> > > > > > >
> > > > > > > https://app.theconstructsim.com/login/
> > > > > > >
> > > > > > > Is it possible to get network enabled and use it to
> communicate?
> > It
> > > > > could
> > > > > > > open new possibilities!
> > > > > > >
> > > > > > > BR,
> > > > > > >
> > > > > > > Alan
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Jan 13, 2024 at 8:30 PM Lee, Lup Yuen <
> lu...@appkaki.com
> > >
>

Re: [Article] NuttX in the Web Browser (TinyEMU + VirtIO)

2024-01-16 Thread Lee, Lup Yuen

Hi Nathan: Yep it's easy to host the NuttX Online Demo on any website, it's
just a bunch of Static HTML, JavaScript and WebAssembly files. Please lemme
know whom I should work with :-)

Meanwhile I'll upstream the TinyEMU RISC-V Port of NuttX. Thanks!

Lup

On Wed, Jan 17, 2024 at 8:40 AM Nathan Hartman 
wrote:

> This is very cool! Could it be possible to put it direct on the NuttX
> website? e.g., "Try NuttX in the browser"
>
> On Mon, Jan 15, 2024 at 5:58 PM Alan C. Assis  wrote:
>
> > Interesting!
> > Thank you very much Lup for investigating it further!
> >
> > BR,
> > Alan
> >
> > On Mon, Jan 15, 2024 at 2:34 AM Lee, Lup Yuen  wrote:
> >
> > > << Do you think it is possible to find an alternative to use the users'
> > > browser connection to communicate to the Internet? This way it avoids
> > > users' consumption of all internet limits on the server side. >>
> > >
> > > Hi Alan: You're right, TinyEMU Emulator talks to a WebSocket VPN hosted
> > at
> > > `
> > > relay.widgetry.org` that's throttled at 40 kB/s (for free, fair use).
> > But
> > > I
> > > don't see a good alternative to this WebSocket VPN:
> > >
> > > (1) Can the Web Browser talk directly to the internet without WebSocket
> > > VPN?
> > >
> > > TinyEMU and VirtIO Networking are sending Ethernet Frames / IP Packets
> > from
> > > the Web Browser to the internet. But Web Browsers are not allowed to
> send
> > > IP Packets directly. That's why we need to tunnel the packets through a
> > > WebSocket VPN.
> > >
> > > (2) Can we host our own WebSocket VPN on our Local Computer?
> > >
> > > Possibly. But then we will have to host the Web Server on our Local
> > > Computer too. Which makes it cumbersome to install.
> > >
> > > (3) Can we host the WebSocket VPN on a server operated by the NuttX
> > > Project?
> > >
> > > Probably not, because we need to throttle the internet traffic for
> free,
> > > fair use. And prevent abuse.
> > >
> > > I've documented my findings on TinyEMU, VirtIO Networking and WebSocket
> > > VPN:
> > >
> > >
> >
> https://github.com/lupyuen/nuttx-tinyemu#tinyemu-networking-in-the-web-browser
> > >
> > > Lup
> > >
> > > On Sun, Jan 14, 2024 at 9:54 PM Alan C. Assis 
> wrote:
> > >
> > > > Hi Lup,
> > > >
> > > > Thank you very much!
> > > >
> > > > Looking at the WebSocket VPN article it said the connection goes
> > through
> > > > the server hosting the emulator.
> > > >
> > > > Do you think it is possible to find an alternative to use the users'
> > > > browser connection to communicate to the Internet?
> > > > This way it avoids users' consumption of all internet limits on the
> > > server
> > > > side.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Sun, Jan 14, 2024 at 4:17 AM Lee, Lup Yuen 
> > wrote:
> > > >
> > > > > Thanks Alan! Yep "The Construct" looks like a cool way to learn ROS
> > > > online,
> > > > > we should do something similar for Teaching NuttX Online!
> > > > >
> > > > > As for Emulated Networking in the Web Browser: TinyEMU Emulator
> > > supports
> > > > > VirtIO Networking. But it's tunnelled through a WebSocket VPN,
> > because
> > > of
> > > > > browser limitations.
> > > > >
> > > > > I might test this with NuttX and see how well it works. (I'm also
> > keen
> > > to
> > > > > emulate Ox64 BL808 RISC-V SBC in the Web Browser)
> > > > >
> > > > > TinyEMU VirtIO Networking: https://bellard.org/jslinux/tech.html
> > > > >
> > > > > WebSocket VPN:
> > > > >
> https://www.benjamincburns.com/2013/11/10/jor1k-ethmac-support.html
> > > > >
> > > > > Lup
> > > > >
> > > > > On Sun, Jan 14, 2024 at 8:10 AM Alan C. Assis 
> > > wrote:
> > > > >
> > > > > > Really cool Lup!
> > > > > >
> > > > > > Maybe it could be used for training and deduction purposes. Do
> you
> > > know
> > > > > > "The Construct" they are using a solution like that to run Linux
> in
> > > the
> > > > > > browser:
> > > > > >
> > > > > > https://app.theconstructsim.com/login/
> > > > > >
> > > > > > Is it possible to get network enabled and use it to communicate?
> It
> > > > could
> > > > > > open new possibilities!
> > > > > >
> > > > > > BR,
> > > > > >
> > > > > > Alan
> > > > > >
> > > > > >
> > > > > > On Sat, Jan 13, 2024 at 8:30 PM Lee, Lup Yuen  >
> > > > wrote:
> > > > > >
> > > > > > > NuttX now boots and runs inside a Web Browser! (With
> WebAssembly)
> > > > > > >
> > > > > > > Try "ostest" here: https://lupyuen.github.io/nuttx-tinyemu
> > > > > > >
> > > > > > > This article explains how we…
> > > > > > > (1) Boot NuttX in the Web Browser with TinyEMU RISC-V Emulator
> > > > > > > (2) Modify NuttX for HTIF Console (Berkeley Host-Target
> > Interface)
> > > > > > > (3) Explore VirtIO Console with OpenAMP Library
> > > > > > > (4) And how we might use it: Emulate NuttX Gadgets in the Web
> > > > Browser?
> > > > > A
> > > > > > > Real-Time NuttX Dashboard that lights up as the various NuttX
> > > Drivers
> > > > > are
> > > > > > > called?
> > > > > > >
> > > > > > > Here's the article:
> > > > >

Re: [Article] NuttX in the Web Browser (TinyEMU + VirtIO)

2024-01-16 Thread Nathan Hartman

This is very cool! Could it be possible to put it direct on the NuttX
website? e.g., "Try NuttX in the browser"

On Mon, Jan 15, 2024 at 5:58 PM Alan C. Assis  wrote:

> Interesting!
> Thank you very much Lup for investigating it further!
>
> BR,
> Alan
>
> On Mon, Jan 15, 2024 at 2:34 AM Lee, Lup Yuen  wrote:
>
> > << Do you think it is possible to find an alternative to use the users'
> > browser connection to communicate to the Internet? This way it avoids
> > users' consumption of all internet limits on the server side. >>
> >
> > Hi Alan: You're right, TinyEMU Emulator talks to a WebSocket VPN hosted
> at
> > `
> > relay.widgetry.org` that's throttled at 40 kB/s (for free, fair use).
> But
> > I
> > don't see a good alternative to this WebSocket VPN:
> >
> > (1) Can the Web Browser talk directly to the internet without WebSocket
> > VPN?
> >
> > TinyEMU and VirtIO Networking are sending Ethernet Frames / IP Packets
> from
> > the Web Browser to the internet. But Web Browsers are not allowed to send
> > IP Packets directly. That's why we need to tunnel the packets through a
> > WebSocket VPN.
> >
> > (2) Can we host our own WebSocket VPN on our Local Computer?
> >
> > Possibly. But then we will have to host the Web Server on our Local
> > Computer too. Which makes it cumbersome to install.
> >
> > (3) Can we host the WebSocket VPN on a server operated by the NuttX
> > Project?
> >
> > Probably not, because we need to throttle the internet traffic for free,
> > fair use. And prevent abuse.
> >
> > I've documented my findings on TinyEMU, VirtIO Networking and WebSocket
> > VPN:
> >
> >
> https://github.com/lupyuen/nuttx-tinyemu#tinyemu-networking-in-the-web-browser
> >
> > Lup
> >
> > On Sun, Jan 14, 2024 at 9:54 PM Alan C. Assis  wrote:
> >
> > > Hi Lup,
> > >
> > > Thank you very much!
> > >
> > > Looking at the WebSocket VPN article it said the connection goes
> through
> > > the server hosting the emulator.
> > >
> > > Do you think it is possible to find an alternative to use the users'
> > > browser connection to communicate to the Internet?
> > > This way it avoids users' consumption of all internet limits on the
> > server
> > > side.
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Sun, Jan 14, 2024 at 4:17 AM Lee, Lup Yuen 
> wrote:
> > >
> > > > Thanks Alan! Yep "The Construct" looks like a cool way to learn ROS
> > > online,
> > > > we should do something similar for Teaching NuttX Online!
> > > >
> > > > As for Emulated Networking in the Web Browser: TinyEMU Emulator
> > supports
> > > > VirtIO Networking. But it's tunnelled through a WebSocket VPN,
> because
> > of
> > > > browser limitations.
> > > >
> > > > I might test this with NuttX and see how well it works. (I'm also
> keen
> > to
> > > > emulate Ox64 BL808 RISC-V SBC in the Web Browser)
> > > >
> > > > TinyEMU VirtIO Networking: https://bellard.org/jslinux/tech.html
> > > >
> > > > WebSocket VPN:
> > > > https://www.benjamincburns.com/2013/11/10/jor1k-ethmac-support.html
> > > >
> > > > Lup
> > > >
> > > > On Sun, Jan 14, 2024 at 8:10 AM Alan C. Assis 
> > wrote:
> > > >
> > > > > Really cool Lup!
> > > > >
> > > > > Maybe it could be used for training and deduction purposes. Do you
> > know
> > > > > "The Construct" they are using a solution like that to run Linux in
> > the
> > > > > browser:
> > > > >
> > > > > https://app.theconstructsim.com/login/
> > > > >
> > > > > Is it possible to get network enabled and use it to communicate? It
> > > could
> > > > > open new possibilities!
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > > > >
> > > > > On Sat, Jan 13, 2024 at 8:30 PM Lee, Lup Yuen 
> > > wrote:
> > > > >
> > > > > > NuttX now boots and runs inside a Web Browser! (With WebAssembly)
> > > > > >
> > > > > > Try "ostest" here: https://lupyuen.github.io/nuttx-tinyemu
> > > > > >
> > > > > > This article explains how we…
> > > > > > (1) Boot NuttX in the Web Browser with TinyEMU RISC-V Emulator
> > > > > > (2) Modify NuttX for HTIF Console (Berkeley Host-Target
> Interface)
> > > > > > (3) Explore VirtIO Console with OpenAMP Library
> > > > > > (4) And how we might use it: Emulate NuttX Gadgets in the Web
> > > Browser?
> > > > A
> > > > > > Real-Time NuttX Dashboard that lights up as the various NuttX
> > Drivers
> > > > are
> > > > > > called?
> > > > > >
> > > > > > Here's the article:
> > > > https://lupyuen.codeberg.page/articles/tinyemu.html
> > > > > >
> > > > > > How will you use NuttX in a Web Browser? Please lemme know 
> > > > > >
> > > > > > Lup
> > > > > >
> > > > >
> > > >
> > >
> >
>

GPIO drivers

2024-01-16 Thread Stewart Charnell


Hello,

I have a processor board with GPIO ports which I would like to use to 
control such things as relays and PSU enable pins.


Do I need to write a GPIO driver? There is an I/O expander driver. Is 
the I/O expander driver specific to expanders or can it be used for GPIO 
control?


Kind regards

Stewart Charnell

TUN device (PPP) issue?

2024-01-16 Thread Kian Karas (KK)

Hi community

I am experiencing an issue with PPP/TUN and reception of packets. The network 
stack reports different decoding errors in the received packets e.g.:
[   24.56] [  WARN] ppp: ipv4_in: WARNING: IP packet shorter than length in 
IP header

I can reproduce the issue by sending a number of packets (from my PC over PPP 
to the TUN device in NuttX),  which are all larger than can fit into one IOB 
*and* which are ignored (e.g. unsupported protocol or IP destination) - i.e. 
*not* triggering a response / TX packet. I then send a correct ICMP echo 
request from my PC to NuttX, which causes the above error to be reported.

The following PC commands will trigger the error message. My PC has IP 
172.29.4.1 and the NuttX ppp interface has 172.29.4.2. Note the first command 
sends to the *wrong* IP address so that NuttX ignores the ICMP messages. The 
second commands uses the IP of NuttX and should result in a response. I run the 
test after a fresh boot and with no other network traffic to/from NuttX.

$ ping -I ppp0 -W 0.2 -i 0.2 -c 13 172.29.4.3 -s 156
$ ping -I ppp0 -W 0.2 -c 1 172.29.4.2 -s 0

If I skip the first command, ping works fine.

I think the issue is caused by the IOB management in the TUN device driver 
(drivers/net/tun.c). I am new to NuttX, so I don't quite understand the correct 
use of IOB, so I am just guessing here. I think that when a packet is received 
by tun_write() and too large to fit into a single IOB *and* the packet is 
ignored, the IOB chain "lingers" and is not freed. Subsequent packets received 
by tun_write() does not end up in the beginning of the first IOB and the 
IP/TCP/UDP header may then be split across IOB boundary. The network stack 
assumes the protocol headers are not split across IOB boundaries, so the 
network stack ends up reading outside the IOB io_data[] array boundaries 
resulting in undefined behavior.

With CONFIG_IOB_DEBUG enabled, notice how the "avail" value decrease for each 
ignored packet until the final/correct ICMP request (at time 24.54) is 
copied to the second IOB in the chain.

[   10.06] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.06] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=0 
len=184 next=0
[   10.06] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 182 
bytes new len=182
[   10.07] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 added to the 
chain
[   10.07] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=0 len=2 
next=0
[   10.08] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 2 bytes 
new len=2
[   10.08] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.08] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
[   10.26] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.26] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=168 
len=184 next=0x24002a50
[   10.27] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 168 
bytes new len=168
[   10.27] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=2 
len=16 next=0
[   10.28] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 16 bytes 
new len=16
[   10.28] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.28] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
[   10.46] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   10.47] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=154 
len=184 next=0x24002a50
[   10.47] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 154 
bytes new len=154
[   10.48] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=16 
len=30 next=0
[   10.48] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 30 bytes 
new len=30
[   10.48] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   10.49] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
...
[   12.50] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=184 
offset=0
[   12.51] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=14 
len=184 next=0x24002a50
[   12.51] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 14 bytes 
new len=14
[   12.52] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=156 
len=170 next=0
[   12.52] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 Copy 170 
bytes new len=170
[   12.52] [  INFO] ppp0: tun_net_receive_tun: IPv4 frame
[   12.53] [  INFO] ppp0: ipv4_in: WARNING: Not destined for us; not 
forwardable... Dropping!
[   24.54] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 len=28 
offset=0
[   24.54] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 avail=0 
len=28 next=0x24002a50
[   24.55] [  INFO] ppp0: iob_copyin_internal: iob=0x24002b20 Copy 0 bytes 
new len=0
[   24.55] [  INFO] ppp0: iob_copyin_internal: iob=0x24002a50 avail=170

Re: Addition of STM32H7 MCU's

2024-01-16 Thread Robert Turner

Did anyone finish supporting the broader STM32H7xx family? If so, is it
close to being mergeable or sendable as a patch?

Thanks,
Robert

On Fri, Sep 8, 2023 at 10:33 PM raiden00pl  wrote:

> > You're right, but not entirely) For example, chips of different subseries
> have different interrupt vector tables. Those. The stm32h7x3xx_irq.h file
> lists interrupt vectors for the RM0433, but not for the RM0455 or
> RM0468. Although
> some chips from all these series have 7x3 in the name.
>
> I think they are the same (not checked, intuition tells me so). But some
> peripherals are not available on some chips and then the
> corresponding interrupt line is marked RESERVED, or its the same peripheral
> but with upgraded functionality (QSPI/OCTOSPI) or
> for some reason ST changed its name to confuse devs. There should be no
> conflict between IRQ lines.
>
> > Even if it duplicates 90% of the file it is better than #ifdefing the
> > stm32h7x3xx_irq.h file. AKA ifdef rash!
>
> One file approach can be done with only one level of #ifdefs, one level of
> #ifdefs doesn't have a negative impact on code quality (but
> it's probably a matter of individual feelings).
> For IRQ and memory map (and probably DMAMUX), the approach with separate
> files may make sense but for peripheral definitions
> I don't see any benefit in duplicating files.
>
> pt., 8 wrz 2023 o 12:01  napisał(a):
>
> > You're right, but not entirely) For example, chips of different subseries
> > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h file
> > lists interrupt vectors for the RM0433, but not for the RM0455 or
> RM0468. Although
> > some chips from all these series have 7x3 in the name.
> >
> >
> >
> > --
> > *От:* "raiden00pl" 
> > *Кому:* "undefined" 
> > *Отправлено:* пятница, 8 сентября 2023 г., 12:52
> > *Тема:* Re: Addition of STM32H7 MCU's
> >
> > From what I'm familiar with STM32H7, all chips use the same registers and
> > bit definitions.
> > Therefore, keeping definitions for different chips in different files
> > doesn't make sense in my opinion.
> > The only problem is that some chips support some peripherals while others
> > do not. But this can be
> > solved using definitions from Kconfig, where we define the supported
> > peripherals anyway, using
> > `select STM32H7_HAVE_xxx`. In that case, it's possible to have only one
> > version of files with hardware
> > definitions (irq, peripherals) and guard the optional functionalities
> with
> > `#ifdef CONFIG_STM32H7_HAVE_xxx`.
> > Moreover, I think this can be done for all stm32 families, but it's a lot
> > of work that no one has undertaken
> > so far (I tried, but failed ;) )
> >
> > I understand that code duplication is often not bad, but in the case of
> > stm32 it is a bit too high. It's partly ST's fault
> > because of how they release their manuals. The user must spend a lot of
> > time to come to the conclusion
> > that the only thing that changes in the other version of the chip is the
> > chip code number in the reference manual :)
> >
> >
> > pt., 8 wrz 2023 o 11:11 napisał(a):
> >
> > > Hi, all
> > >
> > > I would like to start working on developing support for STM32H735
> > > microcontrollers in NuttX OS, but I found some strange things in the
> > > principle of configuring this series of microcontrollers.
> > >
> > > Microcontrollers of the H7 series are divided into several subseries,
> > each
> > > united by one reference manual:
> > > - STM32H723/733, STM32H725/735 and STM32H730 (RM0468)
> > > - STM32H745/755 and STM32H747/757 (RM0399)
> > > - STM32H742, STM32H743/753 and STM32H750 (RM0433)
> > > - STM32H7A3/7B3 and STM32H7B0 (RM0455)
> > >
> > > But some header files in arch/arm/include/stm32h7 are designated as
> > > stm32h7x3xx_irq.h or stm32h7x5xx_irq.h, although they are only for the
> > H743
> > > or H745 series respectively, not for H723 or H735. And such a
> > discrepancy
> > > is also present in other source code files that belong to the H7
> series.
> > >
> > > Maybe it's worth fixing this somehow? Will this break anything
> > important?
> > >
> > >
> > > Oleg Svezhinskiy
> > >
> >
>

Re: GPIO drivers

Re: TUN device (PPP) issue?

Re: [External Mail][Quarantine]GPIO drivers

Re: [Article] NuttX in the Web Browser (TinyEMU + VirtIO)

Re: [Article] NuttX in the Web Browser (TinyEMU + VirtIO)

Re: [Article] NuttX in the Web Browser (TinyEMU + VirtIO)

GPIO drivers

TUN device (PPP) issue?

Re: Addition of STM32H7 MCU's

9 matches

Site Navigation

Mail list logo

Footer information