Is anyone working on the IP/SLIP project?

[GalenHZ]

The SLIP driver implemented in LWIP uses three callback functions for serial support. I could move slip out of stmhal, and implement those three functions in the stmhal serial driver code. It might even work better that way than it does now.

I'll get started on lwip-prototype2 with these ideas.

[pfalcon]

Sorry for the delay with response - I was traveling/on vacation.

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.

Yes, so I suggest skipping that route. Again, the idea is that lwIP is a generic TCP/IP stack, so it should be possible to provide a generic Python module which exposes TCP/IP functionality. How lwIP integrates with particular hardware/middleware is another question, related and important, but still separate from just allowing to have a generic Python module.

So how about this as a proposal: I'll create extmod/modlwip, which implements the lwip control functions and a lwip.socket() object.

+1, that's probably what I had in mind too .

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.

Sounds good!

[GalenHZ]

All right, I've been creating the new module by merging code from my original version of the project and modusocket. So far so good.

The first real stumbling block is that I need some cross-port version of HAL_Delay at certain points. Is there an equivalent of this that's port-neutral, or do I need to have ports supply a #define for their specific version of the function.

[pfalcon]

Good news!

The first real stumbling block is that I need some cross-port version of HAL_Delay at certain points. Is there an equivalent of this that's port-neutral, or do I need to have ports supply a #define for their specific version of the function.

Well, the idea of "HAL" is that each port provides it. uPy doesn't have too consistent HAL interface, for example, some functions are "silently" inherited from vendor STM32 HAL interface, among them is HAL_Delay(). But well, it's still essentially part of uPy HAL, almost every baremetal port defines it. The naming definitely will need to be cleaned up going forward, but in the meantime, you can rely on the fact that each port provides (or should provide) HAL_Delay(), which takes delay time in milliseconds.


Other point discussed previously is using a git submodule for lwIP upstream code. There's now example of a submodule in uPy codebase: axTLS for SSL support, see https://github.com/micropython/micropyt ... master/lib , https://github.com/micropython/micropyt ... 570c3668e1 . Well, those links shows it's there, but don't show how to do it, but I find man page shown by "git submodule --help" pretty straightforward. And as I mentioned, if you need help with that, I can make a commit which adds the submodule, just confirm which revision/tag you'd like to use from official lwIP repo, http://git.savannah.gnu.org/cgit/lwip.git

[GalenHZ]

I've committed a new branch with the revised version. lib/lwip is now a submodule, the code is in extmod, and I've added build hooks and serial port hooks to stmhal.

https://github.com/galenhz/micropython/ ... prototype2

It doesn't build by default. You'll have to enable it by setting the LWIP and SLIP variables in mpconfigport.mk to 1.

Get it working by doing something like this:

Code: Select all

import lwip
import pyb
lwip.reset()
tim = pyb.Timer(7)
tim.init(freq=20)
tim.callback(lambda t:lwip.callback())

u = pyb.UART(2, 115200, read_buf_len=3100)
sl = lwip.slip(2, "192.168.5.2", "192.168.5.1")

It seems to function reasonably well for TCP and UDP. It eats more memory than it should and it would be really nice to do an interrupt based serial interface instead of polling, but the bulk of the code is in the socket glue and should be sound. If you like it, I'll submit a pull request.

[pfalcon]

Thanks, great work! I added few comments on github, and they roughly fall in 2 categories:

1. Codestyle/syntactic stuff which can be made better or fall better with existing uPy code - my guess these would come up during pull request review anyway.

2. Notes "it could be made different" or questions "why did you do it like that?" These are mostly to better understand your code, and even if something really can be done better, it should be done later, after merging the initial code, given that you tested it as is.

From my point of view, none of the issues are blockers, and I'd rather proceed to pull request phase sooner than later, as it would allow larger participation and better place to find answers to comments of type 2 later. So, please have a look at the comments and see if they makes sense and you'd be willing to address them before review, or rather go for PR directly. (And just to make sure you're not got bored with all the gazillion fixes to do on this "last mile" - I'd be happy to help with them, as time permits).

[GalenHZ]

I made the easy fixes you suggested, and created the pull request. The other fixes are good ideas but we can start from this as a base.

[pfalcon]

Ok, the largest part of patchset as posted at https://github.com/micropython/micropython/pull/1517 is now merged, though we're working out some last integration issues. Excellent work, GalenHZ!