Is anyone working on the IP/SLIP project?

[pfalcon]

GalenHZ, great progress, thanks for posting! I'm backlogged with other stuff so didn't have a chance to look into it yet and not show when I'll be able, but thanks for providing instructions how to test it - they'll sure help.

Few comments:

The SLIP interface with the UART module is inefficient. It would make more sense to have the UART receive interrupt copy data directly into the pbuf instead of going through an intermediary buffer in the heap. Doing that would require some work on the UART module, though.

Well, I'd leave that until later too. The whole idea is to just provide basic implementation, common ground for different people to start from or play with. It should be reusable (i.e. be able to use existing Python-level objects), not be super-efficient. Of course, unless it's just too slow (but then, how much speed you can expect from a serial connection? 115200 baud is 10KB/s. Bottleneck would be an I/O, not bufferbloat.)

Next steps ... non-blocking mode

As far as I saw, non-blocking mode is a bit easier to do than blocking, so I'm not sure why you got blocking implemented first. Anyway, it should be pretty simple to add basic non-blocking. Maybe you means all the corner cases and BSD sicket compliance as much as possible - that yes, may require more work.


Thanks again, please keep us posted!

[GalenHZ]

I've made some progress since the last posting. It's now more or less basic-feature-complete with the exception of non-blocking mode. It's a little more complex to set up now:

Code: Select all

import pyb
import network
network.LWIP().start()
tim = pyb.Timer(7)
tim.init(freq=20)
tim.callback(lambda t: network.LWIP().callback())
sl = network.SLIP(pyb.UART(2, 57600, recv_buf_len=1550), "192.168.5.2", "192.168.5.1")

It seems to work in simple sandbox testing. It does have what I think could be glaring weaknesses, but it's something.

[pfalcon]

GalenHZ, ok what are your plans regarding this? I'd suggest not to keep it in branch for too long (there're few unmerged, "lost" branches/forks already), but if it basically works, submit for review. I still didn't have time to play with it, but reviewed, and here surface (non-technical) issues I saw:

1. Codestyle issues, I left comment on github, and see that you already addressed some (not sure of there're more).
2. Location: stmhal/modnwlwip.c isn't ideal, because it isn't (or shouldn't be) stmhal-specific, so better location is extmod/modnwlwip.c . It's probably not worth to move it now, but before merging to mainline, it'll probably will need to be squashed to a single commit, so renaming at the same time would be good idea.

Another "organizational" question is how to pull lwIP itself into build, and we agreed with @dpgeorge to use git submodules for this, so committing it into mainline should/would be avoided (and definitely should stay a separate commit in PR you would do).

[GalenHZ]

My current plan is to create a new branch off current head and put my work there in a single commit, so I don't have to deal with squashing.

Submodules are a new topic for me; I'll need to do a little research on that.

As for the location, the problem with moving modnwlwip is that it's dependent on modnetwork/modusocket, which currently are stmhal-specific. If there is a plan to move these out of stmhal, modnwlwip can go with them, but it seems strange to put code in extmod which has stmhal dependencies.

[pfalcon]

Submodules are a new topic for me; I'll need to do a little research on that.

Feel free to leave that to maintainers, just make sure that upstream lwIP code stays a separate commit from anything else (and if you need tweaked config for lwIP, or something, it also should stay separate).

As for the location, the problem with moving modnwlwip is that it's dependent on modnetwork/modusocket, which currently are stmhal-specific. If there is a plan to move these out of stmhal, modnwlwip can go with them, but it seems strange to put code in extmod which has stmhal dependencies.

Well, the idea is to have generic lwIP module, which is not stmhal specific in any way. If current implementation has some dependencies on stmhal, they are to be factored out as next steps. Putting the module in the intended generic location right away will just allow to deal with history browsing easier. It can be moved afterwards too of course.

[cid254]

Someone tried this https://github.com/rhjdjong/SlipLib ?

Let us know

cid

[GalenHZ]

In order to make an extmod/modlwip useful, I'd need to also create a generic socket object which can be used with it, similar to esp.socket() from the ESP8266 port. It won't be able to interact with the current modusocket in stmhal, unless I created a new shim class to plug lwip into that framework, but that's doable.

Is this where we want to go? Or do we want to create something like the stmhal modnetwork framework in a generic form which can be used by any port?

[dhylands]

I would imagine that we want to have something fairly generic.

Some devices (like the STM32F407) have builtin ethernet controllers. Some boards, like the NetDuino Plus 2 has an STM32F405 with an ENC2860 ethernet chip on it. The ENC2860 is fairly generic and could be connected to just about any microcontroller.

So it makes sense to be able to share an ENC2860 driver. Some drivers, like the one for the builtin one in the STM32F407 are probably MCU specific and don't need to be shared. The ESP8266 driver probably fits in this class as well.

So I think that we need some type of generic network/socket thing that we can use drivers with (ENC2860, CC3000, The WizNet one, the SLIP one you're working on, etc). modsocket and modnetwork started out in stmhal, but they may or may not belong there in the long run (I'm being a bit vague, because it kind of depends on how things get factored out).

[GalenHZ]

This makes sense to me, but breaking out the network module from stmhal is going to require some thought, and I'm still relatively new to the project.

So how about this as a proposal: I'll create extmod/modlwip, which implements the lwip control functions and a lwip.socket() object. modnwslip stays where it is, because it depends on the functions exported by the stmhal serial driver. This will give us a working setup for at least one platform, and form a basis on which further work can be done.

If you'd rather I hold out until work is started on a properly generic networking framework, that's fine.

[dhylands]

I'd be inclined to create an API for registering a serial function. Then have the stmhal side call into something from the extmod modules to say here's a couple of functions for implementing the serial I/O (which may be wrapper functions).

Another approach is to just use a couple of MACROs which stmhal would need to define, and those functions would be called from the extmod code. That way you can put the code in the right spot and still not rely on the stmhal funcions directly.