What's the best way to connect the P2 to wired ethernet?
cgracey
Posts: 14,146
in Propeller 2
Does anyone have any ideas for quickly connecting the P2 to wired ethernet? Was there anything that we did for P1 that worked well? Are there any modules available that offer simple connections with low latency?
Comments
You could probably bitbang half-duplex 10BASE-T ethernet just fine. You just need the hookup hardware (so plugging into a PoE network doesn't send 48V into the pins..)
Pretty sure Peter Jakacki is your best man for this but I would go down the Wiznet route
https://digikey.co.uk/product-detail/en/wiznet/WIZ850IO/1278-1043-ND/8789619
There are a couple Click boards with ethernet:
https://www.digikey.com/en/products/detail/mikroelektronika/MIKROE-971/4495684
https://www.digikey.com/en/products/detail/mikroelektronika/MIKROE-1718/5258596
I'd probably see if I could get one of those working...
There is a P1 driver for the chip in the first one, as I recall...
Thanks, Everyone. This will get things started. This is needed for an industrial application in a local sawmill, in order to replace a hodgepodge solution made from a camera, USB, and Windows. They have uncontrollable latencies that make it hard to get the throughput up to where it could be. I like to imagine they are one automatic Windows update away from disaster, and the P2 will fix the problem.
One of the first things I did with the P2 FPGA was port my EASYNET server for the WIZnet W5500. I guess it is easy enough to add some client modules to that too. I just loaded the module in to check that part of it.
These are the module identifiers with the dates I last updated them.
TAQOZ# .MODULES --- 3736 *EASYNET* WIZnet NETWORK SERVERS 160707.1500 2290 *W5500* WIZNET W5500 driver for TAQOZ V1.0 191007 1848 *SED* TAQOZ SIMPLE TEXT EDITOR 210205-1600 1574 *TEXT* VGA BMP TEXT 190800-0000 1184 *BMV* BMV VIDEO PLAYER 190800-0000 780 *WAVE* WAVE AUDIO FILE PLAYER 190800-0000 430 *BMP* BMP FILE VIEWER 190800-0000 2084 *MEDIA* TAQOZ INTERACTIVE MEDIA - AUDIO, TEXT, IMAGE & VIDEO DRIVERS 210220-1200 4878 *P2ASM* TAQOZ INTERACTIVE ASSEMBLER for the PARALLAX P2 - 210124-1200 2720 *DISK* SD DISK REPORTING & FORMATTING TOOLS 190800-0000 4994 *FILE* TAQOZ FAT32 FILE SYSTEM for SD CARD plus VIRTUAL MEMORY 210128-0830 1644 *SPIRAM* LY68L6400 8MB SPI RAM ACCESS 191020-0000 1766 *DECOMPILER* A decompiler for TAQOZ 190825-0000 822 *UBI2C* EFM8UB3 I2C COMMANDS 210118-0000 614 *RTC* RV-3028 RTC DATE and TIME 190800-0000 896 *SMARTPINS* SMARTPIN FUNCTIONS and drive modes 190800-0000 402 *P2CLOCK* P2 CLOCK CONTROL 190800-0000 2564 *ANSI* ANSI TERMINAL SUPPORT 200410-0000 434 *EXTEND* Primary kernel extensions for TAQOZ 210128-0830 5990 *SPIFLASH* okI got my old setup back together and made a couple of very minor changes to the code and now it's up. Time to test it out a bit more especially with the faster SPI modes although I believe that the W5500 errata says that there is a 35MHz practical limit.
An expensive, but low-code option is the XPort module; it's a serial-to-Ethernet bridge.
I used to use those before in commercial product until I needed it to do FTP and HTTP etc, so I developed EASYNET for the WIZnet chips that ran on P1s with my old Tachyon V3. It served up web pages from FAT32 cards, and I could FTP to and from the P1 as well as telnet into and even change the code remotely. That was the humble P1. Imagine what can be done with the P2.
This is my setup with my hacked P2D2r4 and my IoT5500 module which is plugged in an inverted fashion for a flush to board fit. There's also VGA hooked up too.
Is this why you asked about the video input?
Bitbanging 10baseT would be a good long term plan, as would an RMII interface. For something quick and reliable, go with the W5500.
I have ran the lwip tcp/ip stack on the P2, but only using PPP over serial connection. Code on my github.
I was just remembering how you were digitizing video, as I was thinking about what could maybe be done with Goertzel and 4 ADC pins.
Sounds like the W5500 is the way to go.
RMII would be a nice way to save pins for a network interface to an external Ethernet PHY with the P2 behaving as the MAC, and I think the TX side is very achievable from a P2. However the RX side will be tricky to delineate frames at 50MHz using CRS_DV and RX[1:0] patterns and some PASM2 code needs to be developed to achieve it. Without doing that work there is a high chance that packet data will be offset by 2,4 or 6 bits in hub memory bytes which will be slow to rearrange to extract the received data. At 50MHz and a 250MHz P2 for example, you only get 2.5 instructions per input sample which is not a lot to hunt about for the SFD after the preamble. I think it's likely you'd need to capture and check this pin data initially to registers after the CRS_DV is asserted and then setup a now aligned frame transfer to hub with the streamer only after the SFD is detected, and manually write any missing initial bytes/nibbles of the packet into hub separately. It may be doable that way with any luck.
Some useful RMII stuff here:
http://ebook.pldworld.com/_eBook/-Telecommunications,Networks-/TCPIP/RMII/rmii_rev12.pdf
Would be sweet if you could utilize the DP83867E for 10/100/1000 Ethernet connections. This is the predecessor to the DP83865 that I put together.
I think that being able to bit-bash a PHY would be great and I'd love to see it done, but I don't think that it will happen any time soon. The WIZnet does work though.
Yeah but RGMII is source-synchronous and the P2 doesn't like that type of clocked input apart from single serial bit streams with a smart pin, plus it needs more pins. The P2 streamer has to clock its data in synchronously to the P2 (async to the PHY). RMII is better that way in that the clock is supplied by the P2 to the PHY and the PHY has an elastic FIFO to deal with the bit slips arising from frequency mismatch due to crystal tolerances. But RMII would be limited to only support 10/100 speeds of course, and is not capable of gigabit Ethernet.
Don't forget that we have dual cogs sharing the LUT. This is the type of thing they were designed for.
I use a https://wiznet.io/product-item/wiz850io/ for replacement of the spinneret board.
Rsonline hold this item.
My prototyping boards are build with prop mini and wiz850i0, no extra external components need
Unfortunately we can't use the streamer and lut sharing at the same time.
...upper picture...
Gorgeous and very practical hack !
I love that style of doing things -> first get it to work and then anything else.
Almost everything already said.
The Wiznet chips would be good if someone already provided library. Do not expect full 100Mbps wire speed or highest performance.
A super simple low speed option are the UART-ETH converters (like USR TCP232).
For top performance, RGMII: Waveshare LAN8720, or DP83848. You directly feed them nibbles. Raw wire rate performance
If you look google hard enough, you will even find the Verilog code available to make your own experiments:
(Don't be scared by Chinese characters you don't need to understand the test.
The pictures already explain it all. And Verilog files are at the end.)
I was used to use lantronix's modules in the past.
Now I much more prefer the tibbo solution. Equivalent and much better than XPort you can use the EM510. And for more complex things the EM2000 which also comes as plug&play board EM2001 (which I use directly plugged and supplied from the motherboard of my low volume projects).
All the above can do wired fast-ethernet, and with the WA2000 also WiFi and Bluetooth. For all the above you have already prepared packages for the serial to ethernet(also wifi) bridge but all of them are also programmable in C and BASIC and you can do much more and offload you main microcontroller from many tasks.
Recently they have released also the WM2000 but it is only wireless and I have not yet tried it.
Another solution, much cheaper, is the ESP32 that with the addition of an external MAC and RJ45 connector can do also fast-ethernet beside WiFi and Bluetooth.
.... but when time to market on low volume products matters nothing can win against the tibbo modules.
I cannot understand why so much complex 'protocols' (and with much less available documentation) than ethernet have already surrender to P2 (like USB, HyperRAM, HDMI, .... ...) but ethernet with a simple and cheap PHY is not yet possible. And why so many people are still interested in suboptimal/proprietary/expensive solutions.
Chip, if you ask me for the BEST, Low Latency, Simple, and INDustrial then look for a 'PHY with MII and with fiber (or 100Base-FX)' connection ... and use plain/simple UDP (don't mess with high level TCP/IP stacks). (So many PHYs to choose: TLK105L, DP83620, KSZ8041FTL, ...)
(A piece of cake compared to HDMI. This is maybe just a 4 days job for you.)
I would imagine PHY based Ethernet is possible, with time and effort.
If it's a piece of cake then go bake it.
While a PHY solution has great appeal I would not think not having TCP/IP is "best" as you have stated. Of what real use is it then?
Go for something functional in the meantime which I did with the W5500 back in 2015, and play with the piece of cake solution testing it out initially with UDP but build on that with TCP/IP.
The simplest solution is add a RPi3B+ to P2.
Plus: you will get a lot more than only eth. Minus: $35.
Ultibo supports eth, so no Linux or any other kind of big, slow loading OS needed.
A piece of cake for Chip, not for me.
But yes, actually I am baking my own RMII cake. The problem is it keeps baking for two weeks, then I need to learn basic things like getting user input from serial and convert into binary and it then takes another two weeks, and then I want to synchronize my clock with the module clock so then I need to learn how can I calculate the frequency of some pin to make it match to P2 my generated streamer clock, and then it the cake need another two weeks in the oven, and the list goes on an on .. forever. Well, you know it ... All those small things are a piece of cake for Chip, so that is why I said 4 days job. But honestly, I am pretty sure that he will be able to make the 10Base-T serial mode SNI of DP83848 in just a few hours.
Chip, are you sure that they know that the issue is with latencies and windows or OS issues? The best thing (if they have not already done yet) is probably to just throw a few media converters (RJ45 to fiber ->> and <<- fiber to RJ45), around $10 second hand on ebay. I would not be surprised if the problem is just that the have a very long RJ45 cable on a shop full of devices that makes lots of RF noise.
I wonder if 10Base-T SNI might be 20 minutes (for Chip) instead of a few hours?
Once you know how to control smart pins and the streamer etc, yeah it might be 1 hour or 20 mins to get an input or output pin clocked just the way you want but there is a whole lot more work to this than just the raw transfer itself. It's not a piece of cake. It's probably many days of work to get it all to work together with some overall framework designed and built up and all the cases implemented/tested with CRCs/collisions/errors/jabbers/runts/auto-negotiation/buffer management, PHY register control etc. Working as an engineer in a data networking company I'd probably want to allocate myself a few weeks work to do all this at least in order to get it all perfected and that's assuming you already know what you are doing and are quite familiar with Ethernet and you don't encounter any HW or setup issues along the way. However if you just need something raw/simple to prove the concept that a P2 can send/receive frames to/from a PHY then yeah it can be hacked together in far less time, but that's not going to be production grade software.
You could interface the P2 to a $25 Raspberry Pi running Apache over its Ethernet connector.
Phil
10/100 ethernet should be within reach of the P2 and could be a game changer too. however there are some details especially in the timing of the synchronous signals which are not worked out yet. the MII (or RGMII) interface handles 4 bits parallel @ 25 MHz which might be the way to go for its relatively moderate speed which could eventually leave the PLL of the propeller open to any desired speed while supplying the clock(s) seperately via an input pin (not sure if that is possible). a combination of smartpins and streamer should do the trick. The TCP/IP stack could be written in TAQOZ since there exist FORTH implementations of the TCP/IP stack already which could be looked into for reference