Non-blocking DHCP

[tommag]

Hello,

I know that this subject has already been discussed a number of times but there are currently no alternatives to DavyLandman's proposal in 2013 : arduino/Arduino#1240

So here are his DHCP improvements ported to Paul's last version of the lib.

I know that this is very unlikely to be merged because of API changes, code style, etc but I find it useful to keep a git version that can be rebased when the Ethernet lib gets improvements and bugfixes...

[geekfactory]

This should be a nice addition to the library.

Hopefully one day we see it as an option in official libraries, specially on this one.

[PaulStoffregen]

also discussed here
https://forum.pjrc.com/threads/27980

[mamama1]

Hi

what's the hold up here, if I may humbly ask? Everyone has the opportunity to use the library version of his choice, if API changes break his stuff. Besides, this could be published in a separate library, if we don't want to break stuff?
At least non-blocking DHCP request would REALLY be nice. Imagine a Lab PSU with Ethernet which doesn't boot up for 60 seconds (default timeout), only because the network cable is not connected.

Unfortunately my coding experience is too low, otherwhise I would have forked this library, implement all the non blocking changes and be happy forever after. If I'd try this, it would take me 10 times longer than an experienced coder, I'm afraid.

The W5500 is really a nice working, very cheap little chip and it is a shame that all available libs are kind of.. meeh.. Especially as it seems that there are no real alternatives on the market which have TCP hard-wired and which are similarly cheap.

Unfortunately, as it often happens in the OSS community, I don't have money, time nor knowledge to do what has to be done...

[PaulStoffregen]

what's the hold up here, if I may humbly ask?

I am currently working on a hardware project. No libraries I maintain will get any updates that aren't fixing extremely bad bugs. All less-than-critical problems and all new features are going onto a giant to-do list until at least mid-2019.

Yeah, this is less than ideal. But if I don't keep a sustainable business model going, then I'll be forced to go back to a corporate job and probably never manage to do much open source ever again. The cold hard reality is open source work on these libs doesn't pay the bills, so I alternate between this stuff and work that funds all the free stuff.

That's the hold up!

[mamama1]

Hi Paul,

nice hearing from you and I'm glad that you are working on new projects! Will this be a project like Teensy? Tease us! :-)

Now that is no doubts a good reason for postponing library and OSS work. Nobody likes corporate jobs.

Anyway, as this is going to take a while, I will try to publish the nonblocking Teensy Ethernet library renamed, so it can coexist with the original Ethernet library, in my repo.

If it, for whatever reason, happens that this becomes famous(ly used), I won't have any objections merging this back to the Teensy repo and/or close my repo as soon as you've got the time to implement this in your repo.

[PaulStoffregen]

Please let me know if you get it working. Ideally send a pull request... in mid-2019.

[mamama1]

unfortunately no luck so far. I did take the tree from this pull request and manually patched all your commits since then into that tree (all locally on my pc).
it compiles, but the firmware freezes as soon as the u8g2 lib tries to write to the SPI display (at the very beginning, that is, however AFTER issuing the non blocking dhcp request).

i had this issue before when i had a buffer overflow but that is now 100% fixed.
will have to dig deeper, i guess it is some kind of SPI issue, maybe. the unmodified, current ethernet library works.