Micro with easy to use ethernet

[cdev]

Ralink makes some SOCs that can do Ethernet x2 and can run Open WRT which is a full featured Linux distro for small devices with an emphasis on wireless devices like firewall-routers. You can make them Ethernet ready by just adding the jack and magnetics. The resulting device is very small, has multiple GPIOs and is fairly flexible. Its a good way to make use of old hardware that has Ethernet jacks in it already, like old routers.

[newbrain]

...and let me do the reset

Well, that part I can do too! 

(sorry, I could not resist)

[free_electron]

You probably already thought about galvanic isolation

not needed. i send 24v AC down the line. sprinkler valves run on 24v ac. i use the two unused pairs as power carrier. current draw is minimal. like 30 mA

[free_electron]

it's more expensive to implement [ethernet]

I noticed that an ESP8266 wireless module (which does essentially what you want by default - send it AT-like dial commands and get a simple TCP connection to somewhere) is cheaper than (just) a CAT5 Ethernet cable of reasonable length (say, 10ft.)
(On Amazon:  ESP8266 module: 3 for about $12.  10ft "Amazon Basics CAT6 Ethernet cable": about $7.)

That's just ... really weird.

amazing isn't it ? it cost less than the effing cable !

[free_electron]

If you want my help I can design it for you, it would take under 5 hours to make a webserver and it has all the bells and whistles that  you need, any ARM cortex device plus a simple PHY like KSZ8081RNAIA would do it, it has a very easy layout too!
This combo is cheap and has very good bang per buck,

STM32H750VB + KSZ8081RNAIA

If you do not like this, Just choose your ARM cortex Device and let me do the reset

thanks, but no thanks. i need to be able to work with it. i don't want a webserver. Simple transport. packet in , packet out. basically a serial port with an address
the rest is plaintext ascii. no json ,xml  or other complicated ballast. It has to be simple. I can design hardware like the best. coding ? not so much , and i don't feel like delving into all the networking stuff and other complicated mess that typically comes along with things. I did all that stuff in the 80's and 90's. it's 2022 . i expect this to be much easier now. a couple of simple functions and off we go. So an interactive code editing is the way to go. Think commodore 64 over a remote terminal ( but without line numbers )

This thing is not well defined yet and will grow as i work with it. i may want to add local soil moisture and other things.

I lost several plants due to valve problems. ( stuck valve refusing to open or wire disconnected due to corrosion , or simply a broken coil) This controller will sense the coil current. if i activate a valve and there is no current (or overcurrent. i've seen irrigation controllers fried due to shorts): send notification. It will also "autodetect" valves. after wiring send the autodetect command and it lists you all channels that are in use. it saves this as a I/O bitmap. It will poll this every few hours. so if a channel "disappears" -> notification

The simple irrigation controllers (even rachio and b-hyve) are "stupid" in that respect. They are also stupid in the sense they cannot activate more than one output simultaneously. i want to use a fertilizer injector. every other week : open the injector valve. I have different injectors. (depending on citrus or other plants)

[free_electron]

Ralink makes some SOCs that can do Ethernet x2 and can run Open WRT which is a full featured Linux distro for small devices with an emphasis on wireless devices like firewall-routers. You can make them Ethernet ready by just adding the jack and magnetics. The resulting device is very small, has multiple GPIOs and is fairly flexible. Its a good way to make use of old hardware that has Ethernet jacks in it already, like old routers.

i said SIMPLE. 1 trillion transistors and 50 megabytes of operating system is not SIMPLE by my definition.

[free_electron]

The wiznet part is also not very easy to work with.

In what way? - I've used the W5500 for UDP applications and once you have the SPI set up right and understand the buffer pointer handling it's pretty straightforward - about 100 lines of C to implement and Artnet receiver. I don't know if TCP/IP is any trickier though.
The only limitation I've found is it doesn't support fragmented UDP packets

i plan on using that one. Fragmentation is not a problem. my commands fit well within the 1500-odd bytes max length of a packet.
Command structure is a fixed number of bytes (3)
out -> [target][register][databyte]  (3 bytes , coded in ASCII HEX so 6 characters)
in <- [response] (1 byte coded in ASCII HEX 2 characters
target is the direct i2c address, last bit is r/w bit. based on that bit

I had one of the first devkits for the 7100 and that left a sour taste ... that thing was so complicated. You needed to handle the protocol state machine in code. ( you had to craft the packet yourself. so you needed to learn how to craft a ping command, a http command etc ...) There were no simple routines like OpenPort , UDP_Sendstring or HTTP_Send etc. i spent days trying to get ARP and PING to work. I had done this on a CS8900 years before. That thing was similar. it behaved as a chunk of RAM (16 bit addres and 8 byte data on a motel bus wired to a Silabs F120 cpu). Simply fill the TX buffer ,  set a bit and the packet left. it gave you an interrupt when a packet came in (it could only do MAC address filtering, but no IP). you needed to encode/decode the packet. I spent weeks learning how to make ping and arp and upd send. It was wonderful and exciting. Succeeding in sending the first hello world as a http packet to a browser and receive a POST operation. Now ? I don't want to go down that route anymore. It's 2022. it should be handled by now.

I don't have the patience nor drive anymore to do all that stuff. I have a heart condition that has hit very hard (people probably noticed i got crankier in the last year on the forum). So i try to find joy in still building things and repairing stuff. But the "fiddly annoying bits ?" not so much. I expect my resistor to be a resistor and my communication port be as simple as a RS232. This block of data here, send there.

Anyway, i have a solution. AnnexRDS basically gives me a BASIC interpreter over ethernet. So it's easy to write code. no need for compilers. interactive commands. open a web browser and we're done. I can focus on writing code that opens the valve on time (as opposed to debugging why a packet is malformed.)

[PlainName]

i said SIMPLE. 1 trillion transistors and 50 megabytes of operating system is not SIMPLE by my definition.

But if it's in a module where, you already said, you don't want to deal with the internals, what do you care how it's implemented? Logically, your only beef should be a) complexity to you and b) cost.

[hans]

I think this is converging towards the classic "Use RPi and Python" or "use a 555 timer" --  to blink a LED.

Each solution is easy, for a software and hardware engineer, respectively.

Using a 400MHz SoC/MCU to transmit a I2C GPIO write to some I/O board, is overkill (which is not necessarily an issue), but can also make things incredibly complex by itself.
Since those SoCs are designed to do many other things well, you would first have to crawl through all those holes to finally get to the level of abstraction you want.

For example, as a hardware engineer, I imagine it's easier to just send raw UDP frames with the Mac and IPv4 header hard-coded for the given protocol, than it is to initialize a complete Lwip TCP/IP stack, configure ARP/ICMP/DHCP correctly, make sure none of the statemachines or allocating structures ever lock up, and then deploy it in the field (literally).
OTOH if you were to spawn a Linux OS, you can be pretty certain those things are bullet proof, but you must go more and more out of your way to get the same level of low abstraction in that environment.. given all the dependencies (that will keep changing, so it's like chasing a moving target). If you don't work with these systems every day, then I can imagine why something lower level and perhaps hardcoded can be easier.

Now FE did state to want to have UDP/TCP, DHCP and easy to set up IPv4, so the target device must have some polished (embedded) TCP/IP stack/library built in.

[free_electron]

I think this is converging towards the classic "Use RPi and Python" or "use a 555 timer" --  to blink a LED.

Close. What i'm looking for is the FTDI equivalent for WIFI. USB was bloody hard trying to do it with the first cypress/intel micros. Then comes along FTDI . USB to serial. easy peasy. now the world is peppered with dirt cheap usb to serial chips. Why ? because it's simple. The drivers exist for any OS and the application firmware is dead easy. You get a pipe: throw a byte in and it comes out the other side. No need to mess around with the USB stack. You didn't really have to learn anything new.

That's what i seek for Wifi / ethernet. No need to muck with anything. Same virtual wire. Throw a byte in and it comes out the other way. OK, it's a bit more complicated as you need to specify an endpoint (IP address) , but not much.
in stead of

serial.print("hello world") you do

Ethernet.Print(IP_Address,Port,"Hello world")

or if you want a bit more low level

Ethernet.Sendpacket(IP_Address,*packet,packetlength)

Espressif's ESP8266 and ESP32 seem to fulfill that role. They are literally everywhere. pop open any Wi-Fi thingy and there's a good chance you find on of them. And they are cheap. 2.5$. By the time i buy an STM32 and a wifi chip i just blasted by a t 3 times the cost , and i'm nowhere. I still need to muck around with complicated software frameworks that have a steep learning curve. The ESPxxxx ? Not so much, it comes ready out of the box. They even have a special ESP network mode that emulates virtual serial ports.

My case is a bit different because i want hardwired ethernet , not wifi. There wiznet seems to fit the bill. So making a little board with both on it gives me all i want : a cheap powerful processor and cheap simple ethernet with wifi and ble on top of that should i want it. There is framework that lets me write code easily using a BASIC interpreter. Open a web browser and off we go. It's like having a distributed network of commodore 64's.

Since i need to send power to the slaves i can just as well send the data . I don't need  "internet" , only networking. I can see at least 10 other routers and peoples printers and whatnot in the air here. No need to throw in a bunch of new wireless things. You stay off my network , i stay off yours.

Why not do something like modbus or a distributed serial over RS485. or even CAN ? Well, i thought it's 2022... IoT is everywhere.. so ethernet by now should be easy.
not so much apparently.

[SiliconWizard]

If you're looking for something very simple that is higher level and doesn't require fiddling with network stacks and such, there is this chip: http://wch-ic.com/products/CH9121.html
You can find eval boards of it  (and the bare chip) on Aliexpress (also on LCSC.)

Wiznet chips/modules are frankly easy enough to work with, but this one is even easier if you directly want Ethernet to UART connection.

[free_electron]

If you're looking for something very simple that is higher level and doesn't require fiddling with network stacks and such, there is this chip: http://wch-ic.com/products/CH9121.html
You can find eval boards of it  (and the bare chip) on Aliexpress (also on LCSC.)

Wiznet chips/modules are frankly easy enough to work with, but this one is even easier if you directly want Ethernet to UART connection.

they seem to have mulitple one. Let's see where i can get those ...

[ali_asadzadeh]

Is this code considerd easy enough!?

The receiving part

Code: [Select]

// Notify the user application about UDP socket events.
uint32_t udp_cb_func (int32_t socket, const NET_ADDR *addr, const uint8_t *buf, uint32_t len) {
 
  // Data received
  if ((buf[0] == 0x01) && (len == 2)) {
    // Switch LEDs on and off
   LED_out (buf[1]);
  }
  return (0);
}
The Transmitting part

Code: [Select]

// Send UDP data to destination client.
void send_udp_data (void) {
 
  if (udp_sock >= 0) {
    // IPv4 address: 192.168.0.1
    NET_ADDR addr = { NET_ADDR_IP4, 2000, 192, 168, 1, 10 };
    // IPv6 address: [fe80::1c30:6cff:fea2:455e]
    //  NET_ADDR addr = { NET_ADDR_IP6, 2000,
    //                    0xfe, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    //                    0x1c, 0x30, 0x6c, 0xff, 0xfe, 0xa2, 0x45, 0x5e };
    uint8_t *sendbuf;
 
    sendbuf = netUDP_GetBuffer (2);
    sendbuf[0] = 'A';
    sendbuf[1] = 'l';
    sendbuf[2] = 'i';
    sendbuf[3] = '\r';
    sendbuf[4] = '\n';
 
    netUDP_Send (udp_sock, &addr, sendbuf, 5);
  }
}

[Miyuki]

Just beware if you send a UDP packet over wifi, you will never have that 100% delivered as with send over serial port or other methods
You must always expect, some will just vanish into the ether

[fchk]

I've used a PIC18F67J60 in the past for various projects. The hardware is basically a single-chip design, comparable to an FTDI FT2232H UART-Serial in complexity. Software and compilers can be downloaded from Microchip for free. The most expensive part in the board shown below is the RJ45 MagJack. This ist the cheapest, smallest, and least complicated way to get wired Ethernet. The PIC contains CPU, RAM, Flash, Ethernet MAC, Ethernet PHY, UART, SPI, I2C, timers,... - just add a 25 MHz crystal, some passives and 3.3V power supply. There are also PIC18F87J60 and PIC18F97J60 - same chip, just more IO pins.





fchk

[nctnico]

Looks interesting but could do with EMI filtering and protection on the ethernet lines. As-is this device likely won't pass / survive certification testing.

[T3sl4co1l]

It's a Magjack, it's got that internally??

Tim

[nctnico]

Typically only some common mode filtering but that is not enough to suppress higher harmonics (coming from crappy phys) and deal with surges / pulses. Typically I put 10 Ohm @100MHz ferrite beads (with even higher impedance at higher frequencies) in series with ethernet signals coming from Microchip devices. For some devices Microchip themselves recommends to use series resistors and ESD diodes to make sure a device stays OK. Such information is usually hidden deep in application notes.

[T3sl4co1l]

Ah, MCP specific?  Haven't worked with any yet, at least in terms of lab testing.  Good to know.

ESD not usually a big deal in my experience, but can indeed be done, there are TVSs available specifically for that.  Usually just clamping diodes into a TVS, which charges up to peak signal level and so doesn't load the signal much.  Even easier with H-bridge style output drivers (mostly gigabit, but I've seen a family that does it for 100M also) which can be pre-biased by (A)VDD for even less signal loading.

Tim

[nctnico]

Power over ethernet is a situation where you have to add protection against spikes on the signal lines. I'd say any of the lower cost ethernet chips are suspect; better safe than sorry.

[DiTBho]

The Cirrus Logic CS8900 is an old and well documented Ethernet module with a parallel bus.
Easy to be interfaced to a MPU with a parallel bus (8 or 16bit), easy to be initialized and used.

CH9121 is easier, but you lose the control. I mean, it's more like a "trans-receiver" that adapts uart to Ethernet, and only with limited networking services.

CS8900 isn't so much complex 

[KE5FX]

Netburner's MODM7AE70 is pretty nice.

[free_electron]

The Cirrus Logic CS8900 is an old and well documented Ethernet module with a parallel bus.
Easy to be interfaced to a MPU with a parallel bus (8 or 16bit), easy to be initialized and used.

CH9121 is easier, but you lose the control. I mean, it's more like a "trans-receiver" that adapts uart to Ethernet, and only with limited networking services.

CS8900 isn't so much complex 

CS8900 is very easy , from a base hardware and software layer ( register read/write). it sits on a standard motel bus (motorola/intel) so yuo can hook it to almost any processor out there. The problem begins implementing the network stack... like i said , i did that in the late 90's. from scratch. i got as far as getting arp, ping and a base telnet working . hardcoded mac and ip address. done on an 8051. All the stuff was written in PL/M from scratch based of the protocol specifications. It was fun .... 20 years ago. i don't want to go through all this again. I expected this to be solved by now. And it looks like it is. just not as ubiquitous as FTDI yet..

[free_electron]

Is this code considerd easy enough!?

The receiving part

Code: [Select]

// Notify the user application about UDP socket events.
uint32_t udp_cb_func (int32_t socket, const NET_ADDR *addr, const uint8_t *buf, uint32_t len) {
 
  // Data received
  if ((buf[0] == 0x01) && (len == 2)) {
    // Switch LEDs on and off
   LED_out (buf[1]);
  }
  return (0);
}
The Transmitting part

Code: [Select]

// Send UDP data to destination client.
void send_udp_data (void) {
 
  if (udp_sock >= 0) {
    // IPv4 address: 192.168.0.1
    NET_ADDR addr = { NET_ADDR_IP4, 2000, 192, 168, 1, 10 };
    // IPv6 address: [fe80::1c30:6cff:fea2:455e]
    //  NET_ADDR addr = { NET_ADDR_IP6, 2000,
    //                    0xfe, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    //                    0x1c, 0x30, 0x6c, 0xff, 0xfe, 0xa2, 0x45, 0x5e };
    uint8_t *sendbuf;
 
    sendbuf = netUDP_GetBuffer (2);
    sendbuf[0] = 'A';
    sendbuf[1] = 'l';
    sendbuf[2] = 'i';
    sendbuf[3] = '\r';
    sendbuf[4] = '\n';
 
    netUDP_Send (udp_sock, &addr, sendbuf, 5);
  }
}

I want to be able to connect to this using a web browser, or at least something like telnet. anyway, leave it. software wise i have a solution now.

[peter-h]

There is no such thing as "easy to use ethernet" unless you use a ready made Linux or similar board, or get one and copy the schematic and the software, and use ready made OS and apps.

Or you buy-in a module, which works (quite a few are buggy too). This is how it was done in the old days of 8/16 bit micros (Z80 etc) which could never run a TCP/IP stack.

Ethernet and everything to do with it is incredibly complex. The libraries for the various chips are full of bugs. Almost nobody understands in detail how it works, well enough to fix bugs. I am working on a ST 32F417 with the ST ETH libs and someone here spent a year of Mondays (he works 1 day a week only - not much I can do because I never found anybody else who understands this stuff) fixing bugs in LWIP, and then another god knows how long fixing bugs in TLS (and everybody and their dog "needs" HTTPS now). I would pay someone to do this work but nobody wants to take it on because it is never ending, and my budget isn't

Then once you got the bugs out of some narrow application scenario, you find some other part of the API which you didn't use but somebody else does, doesn't work properly.

Fortunately USB is working well enough otherwise I would go crazy and drop this whole project. Everything else I can code myself.

ETH and USB are both incredibly complex. Most libraries are buggy as hell and implementers spend months googling for bug reports. Most of these lead nowhere (because 99% of those who fix bugs don't usefully describe what they did, because they did it in company time, etc) and occassionally you find a snippet which enables you to fix a bug. Then you move to the next bug. Then you get a bug which breaks the system just once a month. The mfg doesn't support the product, other than via a, you've guessed it, a forum And on there are 1000 desperate posts every week, most remaining unresolved.