MicroPython Forum (Archive)

Sorry to resurrect a dead topic, but I have some news which might make this port viable again. Kinesis recently released a new 2.0 version of their SDK. I grabbed a copy from their site, and found that the usb middleware stack is now licensed under simple 3-clause BSD. It's not dependent on the MQX ...

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.

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/tree/lwip-prototype2 It doesn't build by default. You'll have to enable it by setting the LWIP ...

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 ...

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.

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 ...

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,...

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 ...

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: import pyb import network network.LWIP().start() tim = pyb.Timer(7) tim.init(freq=20) tim.callback(lambda t: network.LWIP()....

Since it's been a while since I've posted, I'll give a quick status update. Free time to work on this project has been hard to come by, but I've at least made a little progress, committed into a branch called lwip-prototype. I'm not going to offer this for merging, it's just to hold my work. Once I'...