Is anyone else using the ENC28J60 Ethernet module? I have been able to get several of the modules to work without a problem, like DHCP, DNS, ARP. But the TCP has been a different story. Once I implement that, my PIC becomes very unstable. I posted about this here http://www.sfcompiler.co.uk/forum/viewtopic.php?t=658
Does anyone else have any tips or tricks or similar stories they would like to share?
Quirky TCP/IP module
Moderators: David Barker, Jerry Messina
Quirky TCP/IP module
Last edited by JWinters on Tue Apr 29, 2008 9:54 pm, edited 1 time in total.
No one else I guess.
The Swordfish Ethernet module was ported from version 4.11 of Microchip's TCP/IP stack. The latest version is 4.18. I read back through the version history since 4.11, there seems to be a lot of fixes since then with over flowing arrays and off by one memory address issues. I hate to say it but I think I'm going to have to switch back to a C compiler so I can use the latest version. Too bad, I was really enjoying Swordfish
The Swordfish Ethernet module was ported from version 4.11 of Microchip's TCP/IP stack. The latest version is 4.18. I read back through the version history since 4.11, there seems to be a lot of fixes since then with over flowing arrays and off by one memory address issues. I hate to say it but I think I'm going to have to switch back to a C compiler so I can use the latest version. Too bad, I was really enjoying Swordfish
Hi JWinters,
When I ran into a similar problem with a graphic display driver, I was given code by another user for a similar driver and modified it myself then posted it back on the group, further contributing to the pool of utility for SF. I didn't have a problem with that since I received the original driver code for no cost anyway, so it shortened my design cycle. With SF, the modules are open-source so it's possible to do that. It's also why SF is 200 bucks for 2 seats and not 2000!
Of course, if you need to move more quickly and have a driver available in C or can buy one that's guaranteed, it's just one of those build-or-buy business decisions. SF is really a new product and over time, the user libraries and libraries supplied by the program author will grow. If you wanted to modify the driver yourself you can keep it to yourself or share it with the group, you have the freedom to choose that. I suppose the difference is that SF is not provided by a team of programmers that are well-funded to produce a product more like Hi-Tech, Green Hills or other "full service" products with multi-pass compiling, full COFF files for debugging and simulations, phone support, support across product and manufacturer lines, etc. SF's libraries are released as an open-source model - great for low cost but it takes longer to get the capabilities up at the beginning.
-Tom
When I ran into a similar problem with a graphic display driver, I was given code by another user for a similar driver and modified it myself then posted it back on the group, further contributing to the pool of utility for SF. I didn't have a problem with that since I received the original driver code for no cost anyway, so it shortened my design cycle. With SF, the modules are open-source so it's possible to do that. It's also why SF is 200 bucks for 2 seats and not 2000!
Of course, if you need to move more quickly and have a driver available in C or can buy one that's guaranteed, it's just one of those build-or-buy business decisions. SF is really a new product and over time, the user libraries and libraries supplied by the program author will grow. If you wanted to modify the driver yourself you can keep it to yourself or share it with the group, you have the freedom to choose that. I suppose the difference is that SF is not provided by a team of programmers that are well-funded to produce a product more like Hi-Tech, Green Hills or other "full service" products with multi-pass compiling, full COFF files for debugging and simulations, phone support, support across product and manufacturer lines, etc. SF's libraries are released as an open-source model - great for low cost but it takes longer to get the capabilities up at the beginning.
-Tom
Well, I decided to stick with it for few more days of debugging and I think I figured it out. The problem was caused by a bug in the PIC itself. I discovered the bug buried in the errata for silicon version a3 of PIC18F4610/4620. The actual problem involves incorrect branching when the PIC exits an interrupt.
Read this post for an updated Tick.bas module that includes a workaround to fix the problem.
http://www.sfcompiler.co.uk/forum/viewt ... =3686#3686
Read this post for an updated Tick.bas module that includes a workaround to fix the problem.
http://www.sfcompiler.co.uk/forum/viewt ... =3686#3686