-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can anyone advise on the current status of this library? #176
Comments
My opinion is there is an issue or issues but what exactly the problem is I don’t know. My fork was an attempt to fix it but I’ve given up on it. I think it is memory related, but not easy to figure out, plus the data sheet and corrections are confusing.
… On Dec 18, 2017, at 18:58, actiondannz ***@***.***> wrote:
Hi, this is not an issue as such so I apologise... I am committed to using this library and have the experience of the hang on some networks, and in an effort to resolve it over the last few months have come across the tmrh20 release. I am confused first as to where the current stable source is - is it here or the tmrh20 one, and also is that problem fixed or is this an outstanding issue?
If anyone could give their opinion on the status of this library and working with the Enc28J60 could you please let me know?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Thanks for your response.
There are two branches, one is the ntruchsess branch, and one is your
tmrh20 branch. Which one should be used? You've got quite a lot of changes
in yours - do they have any impact?
With the exception of the module becoming permanently disconnected and
needing a reboot to reconnect, the ntruchsess works. If yours does not
solve the problem, is it better to simply use ntruchsess and implement
some kind of reboot if it is not connecting?
I would appreciate your thoughts on it. Thanks!
|
My changes don’t seem to have an impact. Implementing some kind of reboot is probably your best bet.
… On Jan 4, 2018, at 14:19, actiondannz ***@***.***> wrote:
Thanks for your response.
There are two branches, one is the ntruchsess branch, and one is your
tmrh20 branch. Which one should be used? You've got quite a lot of changes
in yours - do they have any impact?
With the exception of the module becoming permanently disconnected and
needing a reboot to reconnect, the ntruchsess works. If yours does not
solve the problem, is it better to simply use ntruchsess and implement
some kind of reboot if it is not connecting?
I would appreciate your thoughts on it. Thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Hi,
I will try to spend some time trying to fix this but I'm confident that Norbert Truchsess will fix it for us. |
Hi jp-001, |
Hi actiondannz, Thank you for your attention. Anyone care to comment, please? |
Hi - me again. This is news to me about the gateway and mask parameters for a 16bit mask. I would like to run a test but I am not sure if we can configure the 16bit mask - does that essentially mean that the network subnet mask is 255.255.0.0 ? In this case maybe our problem with a switch is actually related to this? If you could confirm that perhaps I can do some research here. |
Hi again, actiondannz. First, it wasn't entirely accurate what I said about only having local traffic, I was sending UDP packets to an external address. Thus the reason for specifying a default gateway. TCP traffic was local. I'm hoping I can get one of the developers to look into these problems. Thanks. |
Some switches expect traffic before functioning. In a static IP setup (vs. DHCP) this may not occur. Some switches expect the client to support VLAN election or explicit configuration. You can generally configure them to ignore this. Some switchports are MAC address locked. FWIW I am using the ENC28J60 Ethercard library successfully. I am able to poll 100 times per second for over 1 week with stable response from an Arduino Nano HTTP server (using IMHO it seems this library is dead. |
Hi, this is not an issue as such so I apologise... I am committed to using this library and have the experience of the hang on some networks, and in an effort to resolve it over the last few months have come across the tmrh20 release. I am confused first as to where the current stable source is - is it here or the tmrh20 one, and also is that problem fixed or is this an outstanding issue?
If anyone could give their opinion on the status of this library and working with the Enc28J60 could you please let me know?
The text was updated successfully, but these errors were encountered: