Micro with easy to use ethernet

[CJay]

looking for Logo plc

no i'm not. i am looking for a device that is cheap , can be soldered down , easy to program, has built-in , hardwired ethernet and handles the entire network stack ready done so i don't have to mess with sourcecode, protocols and the stack. it has to be SIMPLE to use without having to delve in millions of lines of code and fixing someone elses crap. it must be as simple as using a usb<>serial chip. it's all done. you have a simple pipe , bot h sides are handled.
in my case : telnet or a browser on one side , 5 or 6 ready made routines on the other side.  it would be perfect if there was something that did telnet to uart. that way i can use whatever client i wanted , and connect it to whatever platform on the other side.

Telnet to serial in an easily integrated, solder down module is a product I've been working with and supporting in (now legacy) products for nearly 2 decades and we weren't early adopters.

I suggest you define your requirements properly (because they seem to keep changing)and then hit up Google because I found at least 5 products well under $10 that do telnet to serial over wired ethernet and I didn't bother to look further than the first page of results.

[free_electron]

Telnet to serial in an easily integrated, solder down module is a product I've been working with and supporting in (now legacy) products for nearly 2 decades and we weren't early adopters.

I suggest you define your requirements properly (because they seem to keep changing)and then hit up Google because I found at least 5 products well under $10 that do telnet to serial over wired ethernet and I didn't bother to look further than the first page of results.

no modules. bare chip. either ready flashed or buy chip and flash binary yourself.
requirements are simple enough:

- browser to uart (preferred) or telnet to uart (backup)
- ability for device to other device communication (after configuration of course) to run on parallel with browser or telnet. basically the browser or telnet port needs to replicate what it sees on the uart. it is ok to have a 'protocol' on top of the uart (like an AT command set) as long as it is human readable.

browser mode : open an internet browser and point to an IP address. i get a simple webpage with a text entry box where i can type some text and click 'send' Sent text arrive on uart TX pin. Another textbox shows me whatever the uart gets on its RX pin
Telnet mode : same as above but not a webpage of course. standard telnet app.
direct mode : runs parallel with above modes. This uses a 'command' mode. for example the string !@!192.168.104.01 would set the target device to the given IP address. any subsequent activity on the uart RX pin is sent to that IP address to exit on the TX pin there . the same data should also appear on the browser or telnet session if running. data from the browser or telnet session only to the attached device

that is really all i need.

[peter-h]

But, actually, I think the real problem with that camera is HTTP - pick any 2048-character password and it can be read off the wires in plain text, so switching to HTTPS would fix that one. And you don't need full-fat Linux to have HTTPS.

This is now getting well off topic but... nobody but a serious adversary is going to be "reading stuff off the wires".

Also any "simple HTTPS", as a server, has the long term problem that, being embedded, it will have a self signed certificate (not a proper signed one, because you can't keep updating the root certificate store on it) and eventually browsers will block access to such servers. Chrome already make it difficult to access HTTP, or HTTPS with a bad certificate.

The product I am working on has a TLS server, and it works, but it cannot be used for anything due to immediate customer non-acceptance (browser warnings of your imminent death). Also MbedTLS needs about 50k of RAM for each instance so to do both client and server needs 100k which is too much. And on top of that it would need 200k to manage the ~130 root certificates IF we were somehow storing (and updating) them!

This is yet another reason why IOT calls up a private server. You maintain a fresh certificate on that server, only.

[PlainName]

nobody but a serious adversary is going to be "reading stuff off the wires"

You're waiting at the airport bored to tears and just want to check you didn't leave the back door open. There's your password gone - not a serious adversary, just a script kiddie playing MitM with the airport WiFi.

Of course, you wouldn't get caught out by that (and neither would I, now, although I might've been a while back), but if we're talking edge cases then pretty much none of this discussion is applicable.

This is yet another reason why IOT calls up a private server.

Yes, indeed. But you don't need a Linux PC to do that.

[peter-h]

For remote, I use HTTPS or a VPN. For a start you cannot have Remote Desktop on an open port, and this was an obvious weakness even when PC/Anywhere was the popular choice.

Most web servers are unix. Most virtual server packages give you e.g. LAMP (Linux, Apache, MySQL, PHP). I "run" a number of websites, all on such servers, and from the lack of apparent hacking, even some which have not been updated for 10+ years, I think the weaknesses these days are not in the OS or the web server but in the applications running e.g. XSS on a website. So it depends on the functionality you have there. If say you have a forum then your biggest hassle will be chinese and russians spamming it with fake passport adverts If you run an online shop then it will be bots filling it up with bogus shopping trolleys. If you run an IOT server then what functionality will you have there? Perhaps some simple UI for controlling the irrigation system, but you will need a login to get in, and that may be HTACCESS which is evidently secure.

[free_electron]

NO SERVERS !.
 like i said. each device runs standalone. point a browser or telnet to it and you get the equivalent of a "command prompt": you send text strings into the device and the device answers with other text strings.
it does not have any other user interface. you need to know its command set.

[PlainName]

like i said. each device runs standalone. point a browser or telnet to it and you get the equivalent of a "command prompt"

You keep saying this, and I keep wondering what it gets you over a box that does the networky stuff and acts as a hub using something simple and appropriate like RS485 to the devices. The only thing I can think of is WiFi ability, but you've explicitly ruled that out.

You have to run network cables and power to these things, so proper comms and power isn't any different. You're complicating the devices by adding Ethernet and TCP/IP to them. OK, so they are standalone, but they have to connect back to some hub (unless, WiFi) so that Ethernet switch isn't any different to a protocol converter hub.

That hub would be easy to implement whatever front end you want on it. Telnet in, type 'sprinkler1' and there you are at the sprinkler1 command line to do what you want. But, if you wanted, you could have a web GUI and point to the sprinkler1 graphic that shows it, ah, sprinkling and click 'stop'. Or pop up a command prompt to type whatever weird command you've implemented on it.

It makes sense to me to keep the devices simple. Tiny MCU, relay, interface chip, bosh. I am failing to see what adding complexity and bloat (and cost and failures) gives you apart from having to either keep updating DNS or have a cheat sheet of IP addresses.

[free_electron]

You keep saying this, and I keep wondering what it gets you over a box that does the networky stuff and acts as a hub using something simple and appropriate like RS485 to the devices. The only thing I can think of is WiFi ability, but you've explicitly ruled that out.

because its 2022 and i expect ethernet to be as simple as usb to uart is . that is the real answer.
the secondary answer is that my entire property is ethernet wired , all the way to the back shed. so plugging devices is easy. even managed ethernet switches are cheap these days (mikrotik) .
it goes beyond that sprinkler controller. that is just step one. it can be all kinds of devices. if i want a camera somewhere : i have ethernet ready.

ethernet is distributed , galvanically isolated, bus . i only need one bus in the entire home. i can plug anything. no need for translators. if i want to add some wireless devices they can go on the wifi. it is all one network of things.
if i want remote access i run a VPN. (i have two properties and they share one network through a VPN link. so it doesn't matter where i am : i can see everything. for example i have a NAS in both locations. one replicates itself to the other. )

It is more of an experiment than anything else but one with a purpose. It would be great to be able to release a firmware that does exactly this on a cheap device. it exists for wifi on esp32 and esp8266. those are cheap
But it does not exist for wired, in the sense there is stuff out there but it requires handling the networking on your target device. It really needs to be ethernet to uart. The target is unaware where the data comes from. It comes from the uart. Just like when you are using a usb to uart. it's a pipe.

This is what i am working on (in flux. evolves...)
the device is a network bridge. the application is your processor dangling off the uart.

- Ethernet auto mdx to a magjack with ACT and LINK leds 10/100TX
- Two wire uart (TX RX) programmable baudrate but always 8n1.
- TXEMPTY output: BRIDGE can accept uart data, uart buffer is empty
- HOLD input : application you can tell the BRIDGE not to send data on the uart. the application is not ready to take uart data.
- DAV output: bridge has data
- INTERRUPT output : if something BRIDGE has received something that is for us . programmable OR logic
-- Pulse per packet: every time there is a packet with our ip on it.
-- goes high on reception, but only goes back low if incoming (from network) buffer is empty
-- loss of network
-- acquisition of network
-- buffer overrun from uart : application is blabbering too fast.
-- buffer overrun from network : application is stalling (via HOLD)

- Net_ready output : goes high when bridge have a working network( IP obtained and ready to roll )
- RESET input : resets bridge and flushes uart buffer. falling edge sensitive. deadlock cannot block reset
- FLUSH input : flushes uart buffer (both).  rising edge sensitive. so a deadlock cannot block the buffers.
- i2c port. Here you must wire an 2402 eeprom holding mac address , static ip if set , uart settings and other options. it also supports a 2x16 lcd display. if display installed : top line shows your ip address , bottom line uart speed and some status indicators. no guessing. If i can get on-board eeprom working this will be optional. But the advantage is that, if the eeprom is missing (or corrupted : you remove it) it defaults the uart. Hook up the display and you see what is going on. I may go for a DEFAULT input pin . If you pull that one the device shuts down network and goes into CMD mode with 9600  baud. Have not made up my mind yet. it needs to be fool proof both for recovery , initialisation and usage

- cmd/data input. To configure from uart : pull line low and execute commands (configuration). If this input is high it is a data pipe. Data passes through. There is no configuration from network side or in data mode. If eeprom is blank this defaults the uart to 9600,n,8,1. If eeprom has settings then it stays in those settings. I do not want to encumber the user with things like AT commands or using special characters(or sequences). in DATA mode it is a pipe. just like uart to usb is. CMD mode is for initial configuration during build.

- watchdog output (programmable functionality) this is a logical OR from several functions that can be enabled/disabled. should be tied to application reset pin
-- no data from uart for X seconds (application locked up)
-- no packet for us for x seconds (network locked up)
-- replication of NET_READY pin (this can hold application in reset until network is ready)
-- receive buffer full (application has locked HOLD pin and bridge has buffer overflow... so application may be in deadlock
-- watchdog is disabled in CMD mode
-- activate on 'magic packet' reception. this allows a remote entity to reset the application. i'll probably use a specific port for that. ideally there should be no need for this. the other watchdog functions can handle this. you can just send a very long packet to overload the uart buffer.

something along those lines. right now im attempting this with esp32 + wiz5500 but i would like to see this as a simple to use single chip. PIC18F97J60 is a possibility.

[PlainName]

because its 2022 and i expect ethernet to be as simple as usb to uart is . that is the real answer.

Well it's an inappropriate one. It's essentially reinventing the wheel because nowadays you can have blue rubber instead of black (but it's softer so needs netting to keep it in one piece, etc).

the secondary answer is that my entire property is ethernet wired , all the way to the back shed.

But that is a much better reason and should be the primary one

[free_electron]

because its 2022 and i expect ethernet to be as simple as usb to uart is . that is the real answer.

Well it's an inappropriate one. It's essentially reinventing the wheel because nowadays you can have blue rubber instead of black (but it's softer so needs netting to keep it in one piece, etc).

the secondary answer is that my entire property is ethernet wired , all the way to the back shed.

But that is a much better reason and should be the primary one

let me rephrase that : it's 2022 and we SHOULD have ethernet to uart, just like we have usb to uart.

[DrGeoff]

like i said. each device runs standalone. point a browser or telnet to it and you get the equivalent of a "command prompt"

You keep saying this, and I keep wondering what it gets you over a box that does the networky stuff and acts as a hub using something simple and appropriate like RS485 to the devices. The only thing I can think of is WiFi ability, but you've explicitly ruled that out.

You have to run network cables and power to these things, so proper comms and power isn't any different. You're complicating the devices by adding Ethernet and TCP/IP to them. OK, so they are standalone, but they have to connect back to some hub (unless, WiFi) so that Ethernet switch isn't any different to a protocol converter hub.

That hub would be easy to implement whatever front end you want on it. Telnet in, type 'sprinkler1' and there you are at the sprinkler1 command line to do what you want. But, if you wanted, you could have a web GUI and point to the sprinkler1 graphic that shows it, ah, sprinkling and click 'stop'. Or pop up a command prompt to type whatever weird command you've implemented on it.

It makes sense to me to keep the devices simple. Tiny MCU, relay, interface chip, bosh. I am failing to see what adding complexity and bloat (and cost and failures) gives you apart from having to either keep updating DNS or have a cheat sheet of IP addresses.

Because you are over thinking it. Forget TCP, just use UDP and a simple point-to-point messaging protocol (effectively emulating RS485). You don't need TCP, you don't need web servers, it just adds overhead and security problems. The solution really is trivial.

[coppice]

let me rephrase that : it's 2022 and we SHOULD have ethernet to uart, just like we have usb to uart.

The production volumes for ethernet to UART products are impressively high.

[free_electron]

Because you are over thinking it. Forget TCP, just use UDP and a simple point-to-point messaging protocol (effectively emulating RS485). You don't need TCP, you don't need web servers, it just adds overhead and security problems. The solution really is trivial.

No udp. Telnet and or browser (preferred) interface. it needs to be accessible with readily available tools. Anything these days has a web browser. even my TV and car have one. Have ip address, will browse, or telnet.
dont want to invent yap (yet another protocol)

[free_electron]

let me rephrase that : it's 2022 and we SHOULD have ethernet to uart, just like we have usb to uart.

The production volumes for ethernet to UART products are impressively high.

that's what they said for USB too. oh it's so easy ... given the success of these usb to uart devices.. someone is lying about the ease of use...
same is true for ethernet/wifi. it is NOT easy. tons of code, bugyy , difficult libraries. same misery as usb was/is.
we have bluetooth/uart and usb/uart.

anyway all these points are moot.

[coppice]

let me rephrase that : it's 2022 and we SHOULD have ethernet to uart, just like we have usb to uart.

The production volumes for ethernet to UART products are impressively high.

that's what they said for USB too. oh it's so easy ... given the success of these usb to uart devices.. someone is lying about the ease of use...
same is true for ethernet/wifi. it is NOT easy. tons of code, bugyy , difficult libraries. same misery as usb was/is.
we have bluetooth/uart and usb/uart.

anyway all these points are moot.

I didn't say they were easy to make. The software to do it well, and follow standards, is fairly complex. However, people have worked that out for a few MCUs. I've no idea how to get access to suitable software in the west, but interface makers in China mostly seem to be using similar software, so I guess there is one key source.

[tellurium]

same is true for ethernet/wifi. it is NOT easy. tons of code, bugyy , difficult libraries. same misery as usb was/is.
we have bluetooth/uart and usb/uart.

Not sure that will help at all, but just FYI - we've added a uart/wifi bridge reference app for ESP32, https://github.com/cesanta/mongoose/tree/master/examples/esp32/uart-bridge