Micro with easy to use ethernet

[SiliconWizard]

The Wiznet chips are easy to use. You don't need to buy a "module", they are available as bare ICs as well.
You don't need to implement any network stuff with them. They just have a few registers to fill to get a working solution.
Of course, they have limitations, but it's impossible to know whether those limitations would be a no-go for a given project without knowing the full specifications.

[free_electron]

all i need is a simple connection. telnet or a browser.
Anyway it is solved. the Wiznet chips handle all i need and they are supported by the platform i want to use (ESP32 + AnnexRDS)

[SiliconWizard]

I've used a Wiznet chip years ago, it was just supporting 10Mb at the time. It worked well, but the throughput was not that great.
The more recent ones support 100Mb with much larger internal buffers, so the throughput should be much higher. I actually ordered a couple modules (W5500) to evaluate that.
I'd like to find similar solutions, but for 1Gb ethernet, but I haven't found anything like that.

[mikeselectricstuff]

I've used a Wiznet chip years ago, it was just supporting 10Mb at the time. It worked well, but the throughput was not that great.
The more recent ones support 100Mb with much larger internal buffers, so the throughput should be much higher. I actually ordered a couple modules (W5500) to evaluate that.
I'd like to find similar solutions, but for 1Gb ethernet, but I haven't found anything like that.

W5500 supports SPI up to 60Mhz, so if your host can handle it, you can get about 50% of the possible throughput. Onboard buffer is 16K in each direction, unfortunately you can't trade off buffer space between tx and rx direction.
The problem when you go to 1G is what interface you use to talk to it. That sort of bandwidth pretty much needs DMA direct to your memory, so only practical as a peripheral on a SoC type device

[SiliconWizard]

I've used a Wiznet chip years ago, it was just supporting 10Mb at the time. It worked well, but the throughput was not that great.
The more recent ones support 100Mb with much larger internal buffers, so the throughput should be much higher. I actually ordered a couple modules (W5500) to evaluate that.
I'd like to find similar solutions, but for 1Gb ethernet, but I haven't found anything like that.

W5500 supports SPI up to 60Mhz, so if your host can handle it, you can get about 50% of the possible throughput. Onboard buffer is 16K in each direction, unfortunately you can't trade off buffer space between tx and rx direction.

The max is actually 80MHz, but the following note in the datasheet is kind of facepalming...

Even though theoretical design speed is 80MHz, the signal in the high speed may be distorted because
of the circuit crosstalk and the length of the signal line. The minimum guaranteed speed of the SCLK
is 33.3 MHz which was tested and measured with the stable waveform.

The problem when you go to 1G is what interface you use to talk to it. That sort of bandwidth pretty much needs DMA direct to your memory, so only practical as a peripheral on a SoC type device

It just needs a FIFO interface such as what you get with FTDI chips. The USB HS are just an 8-bit FIFO @60MHz and can handle the 480Mb/s throughput, from which you can achieve something like 30MBytes/s, which is not bad. The FT60x support USB SS and have either a 16-bit or 32-bit FIFO interface @100MHz. For gigabit ethernet, some 16-bit FIFO interface would be a no-brainer, but even just 8-bit @100MHz would be fine.

But there's probably not a significant market for this. Problem is, if you want gigabit ethernet, you'll usually have either to use a full, Linux-capable SoC, or some FPGA with a soft core, or with a hard core, such as the Zynq stuff. There's nothing in between.

[cdev]

There is a commercial product called Vocore that uses an SOC to provide a wireless PC running linux that can work with a mag jack and minimal additional components.

[westfw]

Ethernet and everything to do with it is incredibly complex. ... bugs in LWIP ... bugs in TLS

Oh come on.  Let's not conflate "Ethernet" with "full Internet stacks that include modern encryption features."

all i need is a simple connection. telnet or a browser.

Given that "a browser" is about two orders of magnitude more complex than "telnet", this sounds like you have a really poor idea of your actual requirements (of the Networking Layers.)  Elsewhere you said something like "just transfer a few bytes", for which even Telnet (or anything TCP) is probably overkill.

[DiTBho]

I have a couple of miniPCI Ethernet modules (not express), never hit more than 30Mbyte/sec on an udp/ip connection.

To go faster, you need to off-load the CPU and allocate the largest buffer possible. It is also necessary to improve the DMA policy or the DMA engine itself.

Out of curiosity, I built a miniPCI-to-PCI bridge to interface a Tulip Giga Ethernet card, a large professional card, used in 2009 for serious business (server), and ... well, on the same router, with the same Linux kernel, it offloads so much the CPU and it has such efficient DMA and bigger buffers that I have seen 50Mbyte/sec!

boooooooom from 20 to 50 Mbyte/sec is impressive 

Not bad at all! So the hardware chip of the net-module can make a big difference

[free_electron]

"just transfer a few bytes", for which even Telnet (or anything TCP) is probably overkill.

Well , how do i talk to it without having to reinvent the wheel ? telnet and browsers are available on every computer. It has to be simple. just like using an FTDI chip. open serial port using putty or a terminal program and off we go.
That's what i want , but for ethernet. That was clear from the beginning no ? i stated very clearly that i did not want to be bothered with complicated software development. give me a virtual pipe and i'm happy. that means BOTH sides need to be handled readily. Yes, i don't know all the details of all those protocols. i'm not interested in them. Too complex.

Anyway, it is solved. I have my dev platform in an easy to use language (basic interpreter on the esp32) and it does everything i want ethernet wise.
This is not for a commercial produc.t it's for a one-off to control the sprinklers in my landscaping. The commercial sprinkler controllers can't do what i want.

[Kjelt]

For that application rs485 would have been more than enough.
You have a proprietary protocol, no need to use it on top of an international defined standard protocol to communicate with other parties.

I think the reason there are no (or limited) cpu's with integrated PHY is:
- a PHY is also pretty intelligent, fast and takes on plenty silicon surface which would make the cpu too expensive
- it would limit the customer, to a certain max. datarate

Pretty much why there are no cpu's with built in rs485 transceivers. Some want more robust expensive 15kV esd protection, or high speed, others want the cheapest.

The reason there is no ethernet firmware in a cpu is obvious, pretty much  every new disclosed cve security vulnerability requires a fix, at least when you are connected to the world wide bad guys web.
But since you are not, as said ethernet is perhaps not the most obvious choice for your project.

[peter-h]

The OP states (post 1) he wants to run over a LAN, and use DHCP. That is a "modern LAN" And rest assured that any customer who reads the internet will ask about "security"

If he can use an RS232 or RS485 connection, that is of course dead simple to implement. But he didn't say that.

There is a mid-way, for a LAN: use UDP packets. Many years ago I nearly became a distributor for a German product - basically what used to be called a "statistical multiplexer - which ran four RS232 lines over ethernet. You set up the MAC # on each box, on dipswitches So it would not work through any switch or router. But it needed to contain almost no software. Back then, that would have been ok. I didn't take it on because I asked the guy ~10 questions and he answered only 7 of them, then I spent weeks extracting the answers to the other 3, generating 20 other questions in the process, and eventually I gave up

Oh and BTW that product avoided the need to purchase a block of MAC numbers, because you created your own Actually I think a lot of chinese firms do that too; if you pick random numbers, the chance of a collission is miniscule, so long as nobody reports you.

[free_electron]

For that application rs485 would have been more than enough.
You have a proprietary protocol, no need to use it on top of an international defined standard protocol to communicate with other parties.

The reason i wanted to go that route is the following
- simple prewired cables ( ok i can run whatever over ethernet cables. i2c if i'd wanted )
- simple ethernet switch can do multipoint. i was going to use hardcoded ip addresses, no need for dhcp. but if it can do that : bonus points
- this thing is off the big bad internet. it runs in a vlan on my home network. so i can point a browser there to see the status and alter settings.
- the slaves have no intelligence. they export a simply command interpreter.
    Waarrdd -> reply with dd
    Raarrdd -> reply with dd.
    (aa = address on the local i2c bus , rr is register in the device , dd is data byte).
    xxxxxxx -> abort (a single X aborts. sending 7 means that no matter where you were in the command string it gets flushed) this is for humans only. This also aborts the i2c bus
    Any valid read or write operation resets the watchdog. Non recognized commands do nothing. (it's the i2c routine that resets the watchdog)
    no valid command for longer than roughly 5 minutes -> hard reboot a simple r/c with a schmitt-trigger that gets reset with a transistor by the SCL line of the i2c bus. (capacitively coupled. so if the i2c bus gets stuck it still trips the watchdog after 5 minutes. there needs to be bus activity (transitions).
- why ethernet ? cause its 2021 and i was wondering if we were at the same ease of use like USB-Serial. These things are everywhere now. My train of thought was "if they got this nailed down, it should be at the point where i can just open a remote terminal and off we go. since iot is everywhere these days ... apparently we are still in the stone age when it comes to ease of use. Espressif seem to be the only ones that have solved a lot of the things.

i had the intention writing this on a 8051 (cause i know those best) but during preliminary research i found that an esp32 is so cheap... but is wifi only. then i found the basic interpreter that can run on it. write code using a browser. no need for stinking compilers , jtag dongles. it's like having a distributed network of commodore 64's accessible through a browser.

this is a one off project. The reason for attempting ethernet was purely because i thought that would be easy by now (and it's galvanicaly isolated. i will be sending 24 volt AC down the unused other pairs (sprinkler valves run on 24v ac) and use a small 1:3 transformer to produce local dc and maintain isolation.

[SiliconWizard]

I wasn't considering your project as one-off, but if it is, then why not use something like a SBC (RPi or similar)? You'd get a full OS, full Ethernet support...

[mikeselectricstuff]

Oh and BTW that product avoided the need to purchase a block of MAC numbers, because you created your own Actually I think a lot of chinese firms do that too; if you pick random numbers, the chance of a collission is miniscule, so long as nobody reports you.

Nobody could do anything even if they did 'report' you.
If you want legit MACs, Microchip sell EEPROMs with a MAC preprogrammed

[fchk]

- this thing is off the big bad internet. it runs in a vlan on my home network. so i can point a browser there to see the status and alter settings.

Please note that the Wiznet chips you have chosen don't support 802.1q VLANs.

For hardcoded Ip addresses you may consider IPv6. Each IPv6 port has got a default local address, and gateways and other information are distributed via stateless discovery.

fchk

[free_electron]

I wasn't considering your project as one-off, but if it is, then why not use something like a SBC (RPi or similar)? You'd get a full OS, full Ethernet support...

To steep of a learning curve. not interested. needs ot be simple. rpi and linux is anything but simple.

[free_electron]

- this thing is off the big bad internet. it runs in a vlan on my home network. so i can point a browser there to see the status and alter settings.

Please note that the Wiznet chips you have chosen don't support 802.1q VLANs.

For hardcoded Ip addresses you may consider IPv6. Each IPv6 port has got a default local address, and gateways and other information are distributed via stateless discovery.

fchk

VLAN may not be the right terminology. It is a regular network that is blocked at the switch level. One simple switch ties all these devices (8 or 9 slaves and one controller) together so they see each other. The slaves don't talk unless talked to by the controller. Slaves don't talk to each other. There is one "uplink" from that switch to my regular network where there is a managed switch. That one is set up so only one computer on my home network can see the devices. (IP/MAC filtering). The idea is the PC used only for software development. Otherwise the uplink port is closed (i simply tell the managed switch to shut that port down when i don't need to be on that network) and the thing runs headless.

My home network is already partitioned like this.

[Kjelt]

Ofcourse I respect your choices, everyone would make different choices I guess.
If you go the ethernet way then I would make it PoE so you have DC already at every node to switch valves etc.

To steep of a learning curve. not interested. needs ot be simple. rpi and linux is anything but simple.

I beg to differ. Lots of examples on the internet and my sixteen year old nephew wrote an UDP based controller for his AV receiver in thirty lines of python code in a couple of hours.
The problem with rpi is that it is not OS so a beaglebone would probably be more your cup of tea since you can design everything yourself if needed and it has an M3 I believe coprocessor to do some nice low level embedded stuff if you need it.

[pqass]

I haven't seen any mention so far for the ENC28J60 from Microchip. 
It is a 3.3V part but is 5V tolerant.  It interfaces to your MCU via SPI and only needs a crystal, some passives and a modular RJ45 with magnetics (SI-60002-F). Digikey doesn't have any in stock right now but you can get ready made modules; google "enc28j60 module".  Although it can only do 10mbit, it may be all you need. 

I've successfully built this implementation: https://www.open-electronics.org/low-cost-ethernet-shield-with-enc28j60/
See the EtherCard library (download) in the link above. It provides a simple library for TCP, UDP, DNS, DHCP, and HTTP server (no SSL).  The C++ code is fairly easy to understand. It's GPL.

[ve7xen]

- simple ethernet switch can do multipoint. i was going to use hardcoded ip addresses, no need for dhcp. but if it can do that : bonus points
- this thing is off the big bad internet. it runs in a vlan on my home network. so i can point a browser there to see the status and alter settings.

To each their own, I guess, but as a networking professional, these small-scale or niche embedded hardware designed this way is a bane of my existence. Nonstandard behaviour. Possibly hardcoded things like addresses because they couldn't be bothered / didn't know how to make it configurable, then you can only have one such on the network and the one device dictates the configuration of everything else. Duplicate MACs, no ARP caching, no respect of DHCP lease timers, the list just goes on and on. They also tend to be *incredibly* fragile when sent unexpected traffic or when there's a lot of broadcast traffic on the network or whatever. The protocols are usually undocumented and weird. Not to even get started on the security considerations... And even so, these guys probably put a lot of work into their implementations, it's just a huge task to do properly. If what you 'really' want is a UART, I would just use a UART-based system like RS485. CAN might also be an interesting choice here.

If you actually want to make a decent networked product, either a *lot* of work needs to go into the stack, or you avoid reinventing the wheel and use one of the existing ones, whether that's lwIP or Linux (mostly the latter, because even with lwIP it's kinda a pain to actually make a proper robust product). Products these days aren't trivial, almost nobody wants to use Ethernet as an expensive UART; they need a full-fledged HTTPS client or server to actually talk to the I of IoT. Sure you could I guess embed some TCP/IP implementation in mask ROM, but you're still writing C against it, so there's really no practical difference between that and using a source library like lwIP except that it lives in user flash and you have to write a few dozen lines of HAL code - and have the opportunity to tune the capabilities of the stack to your application or add bug fixes. There's only disadvantages to doing it as gateware instead, at least outside of niche high performance use cases.

Not really grokking why you are so opposed to using a library. As far as the developer interface is concerned, it's basically the same as any other embedded solution including WizNet - you write the HAL, then you call the high-level (existing TCP/IP library or your HAL->SPI one) functions to implement your application. Sure it requires some flash space, which costs money, but so does a WizNet chip. Hell, writing the HAL driver for lwIP is probably simpler than writing the higher-level mapping to the WizNet SPI interface. CubeMX or whatever high-level development environment for your micro platform will pretty much take care of this all for you these days.

FWIW while you seem to think Espressif offers what you want, the networking is all just library code... Also the ESP32 has an Ethernet MAC, so if you like that solution, go ahead and use it, just add a PHY, they are cheap as chips.

If you like the idea of BASIC on ESP32 to solve this, microPython does include full network abstraction and an easy to use interpreted language. It has been ported to many boards with Ethernet already there like Nucleo 746ZG, and also ESP32 (though not sure which boards might have a PHY).

A small off-topic bugbear (not directed at you free_electron, I was just a bit triggered reading the thread): WiFi is Ethernet. Fibre Ethernet is Ethernet. Copper Ethernet is Ethernet. Ethernet specifies many physical layers, it's not a synonym for RJ45 or base-T.

Edit: ENC28J60 doesn't really make a lot of sense here, it's just a MAC+PHY, if you already have a MAC (which many micros do) it offers nothing, and it does nothing to solve the stack implementation problem, since it doesn't implement any of that.

[free_electron]

Ofcourse I respect your choices, everyone would make different choices I guess.
If you go the ethernet way then I would make it PoE so you have DC already at every node to switch valves etc.

The valves require 24V AC (50 or 60hz...) not pulsed DC but true AC (polarity reversal) so POE doesn't work. i need AC at point of load. i will send 24VAC down the wire on the two unused pairs. a small local transformer will maintain isolation. or i may use a simple rectifier driving a DC/DC. depends on what is cheaper. i do want to retain galvanic isolation between modules. have not looked into detail on this yet.

Too steep of a learning curve. not interested. needs to be simple. rpi and linux is anything but simple.

[/quote]

rpi is expensive (compared to esp32), draws way more power than an esp32 and they are hard to get these days and an annoying form factor. hats, capes , whatever. yuck. even using the CM is a problem. Those connectors are finnicky.
Python is not up for discussion, nor is anything that smells like or is lunix for that matter. I don't want a whole OS. So many times i had to reformat my SD card in the rpi i have played with. It got hosed during an uncontrolled shutdown. no thanks.

following is NOT a rant. just trying to clarify what i seek in simple terms :

Besides solving my irrigation problem i used this as a kind of experiment to figure out if we have a simple AND cheap ethernet/wifi networking solution yet.

The ESP32 (or 8266) is a winner hands down in the price camp. can't beat it. 
My definition of cheap is 5$ max (i can get a usb uart for 2$ and a processor for 3$)
Espressif is actually cheaper than that.

It is also the winner in the simplicity camp , albeit way more complex than an FTDI solution. yes you can do udp in an easy way but that is not "simple" as it requires custom stuff on the other side. To stick within the realm of simple : point a browser or open a telnet port. something ready made that itself is cheap and simple.

Simple means just that : simple. Simple as in commodore 64 simple. Basic simple. FTDI usb simple. i am looking for that kind of simple to use ethernet. in 2022 it should be simple by now. Python on a pi may be simple for others , it is not my definition of simple. a small micro is simple. granted, esp32 is not exactly a small micro but it comes in small 48 pin QFN (pico-d4), does not need an OS and i could even use the factory built in basic interpreter. That classifies as simple.

commodore simple means : apply power and 10 milliseconds later you have a prompt and can start writing code. no need for compilers, ide's , jtag probes and whatnot. turn it off when you want. will not turn into a brick , doesnt take 10 seconds to boot , hard rom. no need for endless os updates.
ftdi simple means : write string, read string. behaves as a buffered uart.
Basic simple means : interactivity , non endless space / tab / whitespace nonsense , no case sensitivity no semicolons or other nonsense that cramps my colon. understanding when = means assign and when it means compare. simple english without fluff. no endless [ compile , fix case mismatch / missing semicolon / forgot to define variable, compile again , flash , crash , figure out problem using printf statement] cycles.

i can fire up an old 8052-ah-basic processor, hook it to a ftdi chip (i would use the silabs 2021 now) , open a terminal program and off we go. that's simple in my mind. Or i can take a raw 8052 (feel free to substitute with your micro of choice) and do the same using a cross compiler ( i would use PL/M since that is close to pascal as a language and highly efficient for small processors. it was designed for intel micros). driving a uart is like 5 instructions. wait for buffer empty bit , throw byte in tx register , repeat for however many bytes you want to send. you get an interrupt on receive. Print hello world is like 30 bytes of rom space (and that includes the constant "Hello world") and requires no ram. That kind of simple. The FTDI chip hides the complex stuff. And it just works. That's what i am looking for , but on ethernet or wifi network.

Damn it starts looking like a rant.
Maybe it's because i am from a different generation. Things were simple in my day. Not so much anymore.

[ve7xen]

What you want is not fundamentally simple like a UART that like you said can be implemented with a handful of instructions - especially if you want to do it remotely 'correctly'. The idea of comparing the two is pretty ridiculous, there is a good reason your UART driver is a handful of instructions and your TCP/IP stack is a couple dozen KB, that code wasn't written for shits and giggles. You're also eschewing most of the simple-to-use solutions that are internally complex but hide that complexity for you (though you seem to be okay with some of them for reasons I don't understand). Either you deal with the complexity yourself (and please don't...), or you embed a fairly thick stack of abstraction to deal with it for you. You can't have it both ways.

Besides solving my irrigation problem i used this as a kind of experiment to figure out if we have a simple AND cheap ethernet/wifi networking solution yet.

There are several cheap and easy to use options, you are just choosing not to use them because you call them 'complex' or for very dubious reasons like your bias against Python and Linux. It's not 1985 and in 2022 if someone is going to be designing something to parallel the intent of your ROM BASIC chip with an interactive interpreter for a scripting language, dollars to donuts it's going to use the most popular scripting language of 2022, which is by far Python, it'd be silly to choose something else for your product.

[uer166]

I don't think Ethernet is a good solution here, you want something RS485/CAN/whatever based. I would recommend PLC RS485 using a THVD8000 chip: basically you have shared 24V (or whatever) power and the AC riding on top is the data. It's super easy to use, you need one master, and multiple slaves that reply. Everything is normal half-duplex UART, just like regulat RS485. 2 wires makes the whole bus, which delivers both power and data.

If you want to totally avoid the PLC filter complication (although it's super easy to prototype with their dev-board), then you're looking at CAN or RS485, CAN being the much more complicated option. Horses for courses, use full featured, secure Ethernet to talk to external world, use something much simpler to implement and manage if it's internal (there is a reason vehicles still use largely CAN bus to talk to all the nodes, unless high speed is required).

[SiliconWizard]

Ethernet is pretty old (several decades), and things were never simple with it. Networking is not simple.

And, if you wanted something "simple" to develop for Ethernet (of course "simple" means very different things to each of us), I still think going for a SBC would be the easier path. You don't have to know all the minute details, as there are tons of languages and libraries you can use for that. The real downside IMO is power consumption (if that ever matters in your case), and boot time (again, if that ever matters in your case - certainly a SBC would take a couple seconds, if you don't start X/ a desktop environment, compared to a couple ms for a MCU-based solution). Now boot time is probably not all that relevant in this case though, because anything using Ethernet will take a few seconds to be ready to communicate on the network anyway, especially if you use DHCP, so...)

[Bassman59]

Besides solving my irrigation problem i used this as a kind of experiment to figure out if we have a simple AND cheap ethernet/wifi networking solution yet.

I'm following this because I want to do the exact same thing: create a better irrigation controller and learn microcontroller-based Ethernet control.

Face it: everyone who has to set up a yard/garden irrigation system has gone to the big box home improvement stores and seen the Orbit and Rain Bird value controllers. And ... they really suck. The user interface is crap. My back yard timer can control up to six valves but it has only three "programs." It's annoying to set up. There's no easy way to see how it's configured. Etc etc. And as much as I'm annoyed by things that "have an app," well, fuck, I'd like to "have an app" that lets me control the valves without having to walk across the yard, enable manual mode for a valve, walk over to where I think the tubing has sprung a leak, note it, walk over to the timer, turn off the value, lather, rinse, repeat.

The things we are controlling are trivial. The micro needs to control four relays that switch the 24 VAC that energizes the values, so literally four output ports, four transistors, four relays, done. The micros all have real-time clocks, so "programs" are just a list of events. Not difficult.

So yeah, the timer box needs to run a web server. I have a dozen examples of how to control bits and things with a webserver -- TI CCS has examples for TM4C and MSP432. SiLabs has examples for EFM32GG. NXP has examples for LPC54628. I'm sure ST has examples.

My problem is that I get all bogged down in the weeds of implementation. For example, with the TM4C I got it to work with lwIP 1.4 ... sort of. (Also lwIP 1.4 is ancient.) I rigged up a a temperature and humidity sensor and a strain gauge reader for my 3D printer. That all gets read by the TM4C and the web page displays the readings. Except that there's something going on security-wise that Safari doesn't like and it won't run the little Javascript that manages the web page. Firefox is happy with it. An NXP version of this has TLS and serves up https with a certificate, and that works. but then there's the overhead of an RTOS and that gets in the way.

And then I think, "why not just send little messages over TCP/IP to sockets ..." because you can do that from Python and there are nice examples of how to do that from macOS and iOS but that's more weeds.

And I don't smoke weed.

We all can learn this stuff if we set aside the time to actually study it. Maybe that's the problem. Who has the time when it's not directly related to the job?