Porting the ethernet library from Arduino

[1bit]

OK, And Thank you for the DIGOLE lib direction. I did buy maybe 8 of them to play with recently.

I have been poking around with this Ethernet issue for the better part of the day. (along with writing a bit of code for for a client.) and I think the ENC28J60 library will work more easily for this..issue ..GitHub - njh/EtherCard: EtherCard is an IPv4 driver for the ENC28J60 chip, compatible with Arduino IDE

Here is why:
the functions and classes were named differently already to coexist with most of the other Ethernet stuff. This would leverage that prior work. Also that board is very similar in function and pretty widely tested. Also it is very cheap. That library is pretty much gcc. I loaded all of the library stuff and it built fine in DEV along with the wire library and the Digole stuff and I also put in some other i2c and digital and analog components. That application compiled without complaint until I got into the PROGMEM bootloader and avr/io.h stuff. I also did port an example of one of my aps from MUDBUS to this library that I had bee using a while back. and that was easy.

UIP is another available one ..GitHub - ntruchsess/arduino_uip: UIPEthernet: A plugin-replacement of the stock Arduino Ethernet library for ENC28J60 shields and breakout boards. Full support for persistent (streaming) TCP-connections and UDP (Client and Server each), ARP, ICMP, DHCP and DNS. Build around Adam Dunkels uIP Stack. Further developed version can be found on https://github.com/UIPEthernet/UIPEthernet

As far as internal protocols go...industrial internal hardwired (or modbus TCP , S7, or CIP ) and whatever is the most reliable /secure commerce protocol for the mobile gadget world..... i am focused on the still growing industrial ethernet segment. .I also did port an example of one of my aps from MUDBUSand SNAP7 to this library that I had bee using a while back.

I only liked the MUDBUS because of the way I can handle the register tables and because it has proven very robust.

If I understand some of the other posts you have made on this topic regarding hardwired Ethernet and router capabilities of the time

Wired network Core interest?

Using another product, I’ve been working on a device that monitors and posts to the cloud data from renewable energy systems. I’ve recognized that in building this product I’m reinventing things that are already created here for the Spark Core. I did at one time consider the Spark Core, but there is one thing keeping me from doing this, and that is the device must use a wired network connection, not Wi-fi. Any talk yet about a wired network Core? Same cool everything, just connections over a…

Thisi s a relaed thread.....

Core should keep running or be able to start even w/o Cloud access

+1 from me too. My home internet connection is via 3G phone network and is particularly unreliable in high winds. No DSL available.

then this MODBUS library may be worth my time to look into as it was made for the the cc3000 stuff...

GitHub - ductsoup/ModbusTCP: A Modbus TCP class for Arduino and either...

Also look at Snap7 for Siemens protocol support....this WILL move here easily. I use that one on several platforms. even wireless as it is cleverly a push/publish type protocol and really puts the smaller processor in charge of what it CAN do, well suited for a connection dependent link.

It may end up that I knit a Teensy 3.2 or 3.6 to a particle ELECTRON as a "CELL PHONE" exchange bridge to a secure, external, protocol for the mobile user. If I go that way I can keep the hard real time stuff in the Teensy and treat the particle as another buffered Ethernet port.

After playing with the photon for a couple of days only,,,,I get a feel for it. The ELECTRON might have its hands full with a protocol conversion anyway and buffering anyway. The database size would be small atmost
255 holding registers (int)
128 input registers (int)
255 coils (bool)
255 contacts (bool)

maybe 2K-5k depending on buffering.

I have got them on a Nano with smaller structures and still have room to do useful stuff the teensy will plug into a nano form factor.

I would like to understand what tools can prioritze tasks on the particle; mission critical may need to be on a different processor. I do have a lieweight shceduler I use for the arduino and every task is looked at and the ones who need I/O gt it... but HARD I/O does real things and should preempt connectivity.

I guess I would look at having the particle as a SPI device to a Teensey if I cant have a Hard port on the PARTICLE. This would not require a PI or that level of OS i dont think at this point but I will go back to the office in berkeley an talk about it with my colleagues. We did have a meeting on the topic yesterday for a few hours.

Thanks ...