For my next project I require an Ethernet port. The data arriving will be decoded and retransmitted to one of four USB serial ports (FT232).
I want to keep it simple as time is a factor so I’m thinking of using a Ethernet to SPI adapter and I’m wondering if anyone had any recommendations on a module to use? Alternatively, would you advise just biting the bullet and doing the Ethernet myself?
Microcontroller is most likely going to be an STM32 or if I can’t get one suitable, a ATMega2560 (I have some on hand)
I have a need in this area myself right now. The go-to seems to be the Wiznet W5500 SPI-Ethernet bridge and similar family members (but please don’t buy them all, leave some for me!). Microchip also makes one, but availability of that seems negligible. Serial (UART) to ethernet bridges exist, but for some reason seem to generally have or require more complexity in their application, so much so that using a simple MCU to convert UART serial to SPI just to be able to use a W5500 might make sense.
Here’s another up-vote for Wiznet W5500 or W6100. I have used these on a few projects. I have also used STM32 parts with built in ethernet, but that seems to drive up size and cost of the the MCU quite a bit.
Wiznet support has also been really good. They will usually ship me ~20ish samples to get protos going.
If I had this request I would probably want to try something like the CH9121 (1300 in stock currently) before moving to an SPI>Ethernet chip just because it would involve a lot more work to get it working.
If their config allows it, this could maybe turn into a solution where you use an ethernet switch + 4 of these guys feeding directly into the serial>usb converters.
PS: If you look at the datasheet you will notice each chip has 2 uart interfaces, I wonder if both could be used but configured to filter for different TCP/UDP ports.
Thanks for bringing WCH to my attention, those parts look useful!
Interested in why you think SPI->Ethernet would involve “a lot more work” than UART->Ethernet.
Also a little unclear as to the differences between “ethernet controller” ICs and “ethernet converter” ICs, apart from more host interfaces, DHCP, and PPPOE.
Agree. The W5500 is almost magically easy to drop on a board and use. I find the SPI interface to be simpler than low speed serial. Plus, ease of DMA make the whole package pretty zippy (for the type of applications it’s intended for). Depending on what you’re driving it with and the shape of the traffic, you can expect up to ~50 mbps on the wire, IIRC.
The only thing that’s a killer for some niche applications is lack of support non-IP frames. Profinet, for example, was either a complete no-go or not worth the hassle - I forgot which (it’s been a while).
I did discover the W5500 on my travels and I’m really pleased to see it getting recommended here - especially as it is in stock at the moment - I had less success in finding the W6100 in the UK. Don’t worry about me taking all the available boards - if I sell 10 we can all afford to retire! The application is quite interesting so I’ll try to write up a build log once I’ve got a bit of time.
@voltlog The CH9121 looks really interesting - it would definitely work as a solution with a little bit of tweaking the communication protocols. However, since I won’t be doing the final installation I would prefer to keep the ethernet cabling to a minimum - I asked for a 200m Ethernet cable to be run on a similar project last year to carry RS422 which caused no end of confusion… I can see me using them in a future project for sure.
I just finished a design needing a LAN. It was a low-quantity build, only a handful will be made. I wanted to use an STM32 and Micropython, but with the chip availability problems, I went with just buying a Pyboard module and plopping that into my board. For the LAN, I found the Adafruit Ethernet Feather Wing which worked just fine for my application. Both modules are available to purchase, a big plus.
I bring this up because the ESP32 has four UARTs. One of them is set to be the debug console (and used for DFU), but depending on the specific needs, you may be able to use all four UARTs the way you want. The ESP32 has flexible IO mapping/steering so that you could have the four UARTs ports wired for your main application separate from the initial boot-time UART port assignment.
Correction: there’s only three UARTs in the ESP32, see below…
I’m a big fan of the ESP32, it’s usually my starting point. In a past project I used 3 uarts, switching one of them with jumpers to use debug/upload when required. I thought the maximum number of uarts was 3 - does one of the newer versions have four?
Oh, rats, I got myself confused. You’re right, it’s just 3. Sorry for getting your hopes up.
I had a project where I only needed half-duplex communication with 10 outbound and 2 inbound UART channels, plus a full-duplex UART channel to the host PC. When I first spec’d that project, I was thinking that I wanted 4 UARTs (so that the multiplexed UART-tx was paired to an unused UART-rx), and that’s the number that popped up in my head when I wrote my earlier comment.
the supplied library is not thread safe due to the use of strtok(). I needed to rework it to use strtok_r()
we just found problems with some w5500 and some linksys/cisco products. Solution is to omit the 33R RX/TX resistors. The jury is still out what the EMC ramifications are.
you need to put a semaphore like construct in the enter_critical_section() and exit_critical_section() prototypes, and probably also on the SPI bus driving the chip.
Who can I bill for the weeks spent figuring that out?
Your post got me thinking - provided you only needed to communicate with one port at a time in theory you could reassign uart io’s on the fly. There would be a reasonable amount of overhead disabling and enabling ports but my first thoughts are that I can’t see why it wouldn’t be possible. If I get some time over Christmas I’ll maybe give it a go as a proof of concept.
You comment about retiring after 10 units (a) made me wonder if you were serious about such a small number and (b) caused me to ponder some alternatives over the past few days. Operating on the potentially completely false premise that the BOM cost and physical space are basically non-issues, the PJRC Teensy 4.1 can operate as drop-dead simple 4-port serial to Ethernet converter, MUX, etc. It includes the PHY and offers the MagJack as an option. So, it’s pretty much plug and play.
In on subassembly of one project, I rolled a (very) customized 16-port gigabit Ethernet switch with PoE. So, I have a pretty good idea of what’s involved in implementing Ethernet and IP (TCP/IP and friends). It’s not truly difficult, but it is work.
The brilliant Paul Stoffregen (the P of PJRC) has made the whole process really smooth. Yes, by default, it’s based on the Arduino platform - which may cause some people to make weird facial expressions avoid it like a Snickers in a swimming pool.
However, it’s also not really ARDUINO at all, due to extreme performance gains over a classic 328 and the sorcery under the hood of the Teensy platform, including its clean demos and drivers. Tech support is impressively robust.
Anyway, it’s worth considering the Teensy as either the coprocessor (via a protocol of your design) or even the main processor for your system. It’s absurdly fast (up to 1GHz M7) and absurdly cheap (<30 USD) , with lots of GPIO and other goodness. I’ve been using the series for a long time a long time and have been really impressed throughout that time.
The Teensy boards always come highly recommended. Personally I’ve not tried them, but I’ve ordered one to play with over the Christmas period. For this project an M7 would be extreme overkill - but it’s not like that is a drawback. My initial thought is to use a STM32G070RBT6 (which I have an inventory of), however its success will likely lie in the amount of memory available. That’s where the Teensy would give me a great backup option.
And strictly speaking, if we sell 10 of the project alone, no we can’t retire - but considering it’s only useful with the $1m system that it connects to, and we would also have had to sell 10 of them too - that’s how we can retire One of the sales was conditional of this project which the sales team happily agreed to - now it’s my headache!
Thanks for the hints - you really brightened my day - here was I thinking I’d solved the hardest part of this one It sounds like you’ve had a lot of fun.
Sorry for the headache. Unfortunately, I understand completely.
Yeah, 32K RAM is a bit tight, but that still gives you 20K above a typical OS (if you so choose). So, fingers crossed. On the Teensy side, 1MB RAM (expandable to ~8MB) and 8MB Flash (expandable to [something huge]) should hopefully be sufficient . Expansion is based on soldering PSRAM and/or SPI Flash to the back of the board, using the pads provided. Easy peasy for small quantities.
When the shortages started to present themselves, stocked up on toilet paper and STM32s. Well, actually, only one of those is true. Regardless, I guess I may be part of the problem, as I picked up partial reels of STM32 G030, L151 and L552 MCUs. Two of the three are targeted for use 2022 Q1, so maybe it’s not _ really _ hoarding…
Have fun with your holiday project. I started a “Just For Fun” thread with a holiday project of my own for 2021-22.
No points for guessing what dev board I used to get this up and running quickly. Also no points for any comments on the iffy, “just get it done in time for the holidays” routing on the PCB.
To avoid clogging up this thread - even more! - I created yet another thread “Teensy boards, for the uninitiated.”
Yes, it’s a github library to be integrated into your program.
I’m currently in QA hell where we try to test the w5500 with all the best routers china has to offer. I have another three paragraphs to add to the above.
If I had to design the product again, I’d use more difficult to implement hardware if it meant the accompanying software lib was more widely used, and therefore more rigorously tested. Of course, for a widget that you build 100 of, this may not apply.
It sounds like you’ve had a lot of fun.
. Expansion is based on soldering PSRAM and/or SPI Flash to the back of the board, using the pads provided. Easy peasy for small quantities.