Shop OBEX P1 Docs P2 Docs Learn Events
P2 Ethernet — Parallax Forums

P2 Ethernet

JohnCJohnC Posts: 64
edited 2019-10-03 16:48 in Propeller 2
Anyone currently working on ethernet for P2? Seems like a Wiznet W5500 coupled with a port of the old Spinneret webserver code would be useful.

John
«1

Comments

  • Peter JakackiPeter Jakacki Posts: 10,193
    EASYNET works with the W5500 on P1 with Tachyon and on the P2 with TAQOZ. It's been a while since I fired it up on the P2 though so I will have to check it out again. It includes FTP and HTTP servers as well as Telnet and uses EASYFILE to access the FAT32 files off the SD card.
  • localrogerlocalroger Posts: 3,451
    edited 2019-10-03 22:24
    I got Harrison's base code for the ENC28J60 ported awhile back.

    http://forums.parallax.com/discussion/170022/enc28j60-ethernet-driver

    This does a robust UDP client and server. Harrison had to really strip down his TCP implementation to fit it in 32K, so a much better solution could probably be fleshed out for P2, but I mostly use UDP in my projects anyway.
  • JohnCJohnC Posts: 64
    edited 2019-10-04 01:33
    Thanks so far. I've looked at the ENC part several times, but I've also heard stories of enterprise switchgear no longer negotiating down to 10bT. For that reason I'm wary of using it on things which may be installed commercially.
  • ntosme2ntosme2 Posts: 38
    The ENC424J is 10/100 Mb and would probably have a very similar driver.
    https://www.mouser.com/datasheet/2/268/39935b-29829.pdf

    Another option, also from Microchip:
    KSZ8851SNLI
    https://www.mouser.com/datasheet/2/268/00002381a-1138397.pdf
  • JohnCJohnC Posts: 64
    Thanks Brian. I've used the 424 on a PIC24 (very definitely pre-Harmony). May be worth a revisit, especially now that C is a more viable option.

  • RaymanRayman Posts: 14,646
    I looked just a bit for some example code for ENC424J600 with permissive license, but couldn't find one...

    Hopefully, Harrison's code could be adapted for this chip, as suggested...
  • JohnCJohnC Posts: 64
    It seems like the fine print ties all the Microchip TCP/IP stuff pretty tightly to their own processors.

    I like the idea of offloading much of the stack and its logic to a separate processor. Wiznet has a pretty substantial Github these days which definitely didn't exist the back when P1 was getting started.

    https://github.com/Wiznet/W5500_EVB
    https://github.com/Wiznet -

    Firmware flash over ethernet, and moving forward, some sort of encrypted firmware delivery service like what Dr. Bob has come up with (http://www.tracesystemsinc.com/sums/sums-overview.html) would be really useful. And yes, I know P2 itself can't be code-locked.
  • localrogerlocalroger Posts: 3,451
    Well it's the IP thing that makes the simple interface thing attractive. I've always been suspicious of the WizNet because if there is a problem, what is your recourse? It may be an older 10bt part but I've deployed the ENC28J60 in hundreds of industrial applications and never had a problem with it so far. But then, most of those have been in places where I could go physically and fix things if there was a bad enough problem.
  • Peter JakackiPeter Jakacki Posts: 10,193
    I have used the WIZnet chips in product that are hard and distant to get to. Like all chips they have their quirks but they are reliable. I'm testing an updated P2 TAQOZ version of EASYNET right at this moment with my W5500 modules and it is very fast and responsive since the file system reads at around 3MB/s and the WIZnet chip is accessed at a similar speed. I'm mainly concentrating on the FTP and web server side but I will tie it in with my VGA 640x480x8 screen to do screen caps and also load screens.
    NETWORK STATUS:
LINK *UP*
HARDWARE: P2D2  using WIZnet W5500 V4
SRC IP    192.168.000.150
MASK      255.255.255.000
GATEWAY   192.168.000.001
MAC       02.FF.50.AD.00.21.
SKT HH:MM:SS MODE  PORT  DEST TXRD TXWR RXRD RXWR RXSZ  IR STATUS            IP ADDR
#1  80:81:06 TCP     21 35038 0000.0000.0000.0000.0000. 00 14 LISTEN      
#3  80:81:06 TCP     23     0 0000.0000.0000.0000.0000. 00 14 LISTEN      
#4  80:81:06 TCP     80 43870 0000.0000.0000.0000.0000. 00 14 LISTEN      

* WEB, FTP, and TELNET servers running * 
 ok
  • RaymanRayman Posts: 14,646
    edited 2019-10-07 14:26
    I guess I would choose W5500... Only ~$1 more and sounds like it works.
    Found the Eagle footprint here: https://github.com/Wiznet/EagleCAD_library

    Not of fan of it not coming with a MAC address though...
    The ENC424J600 comes with a MAC.

    Actually, I guess I'm still on the fence on which way I'd go...
  • localrogerlocalroger Posts: 3,451
    I've had good results using locally administered MAC addresses -- just make the first octet 2 and it will never conflict with a commercial device, and I usually make the IP address the last 4 octets so that no two of my own devices on the same subnet will conflict either.
  • dMajodMajo Posts: 855
    Rayman wrote: »
    ... Not of fan of it not coming with a MAC address though...

    If you need an unique MAC address have a look over this microchip parts (they come factory pre-programmed with 48 and 64 bit MAC)

    Flash: 16Mbit 32Mbit and 64Mbit

    They have also a series of lower size EEPROMs with the same MAC address options

    Of course they have Microchip OUI
  • RaymanRayman Posts: 14,646
    That's interesting... Look like you could use the flash chip's EUI-48 as your ethernet MAC address...
  • JohnCJohnC Posts: 64
    I've used their one-wire parts for MAC address in the past. Not much money but it does add another part to be placed.

    @Roger in all your travels have you ever met a modern switch that wouldn't negotiate down to 10bT? I've not seen it myself, just heard rumors in other forums.
  • dMajodMajo Posts: 855
    Rayman wrote: »
    That's interesting... Look like you could use the flash chip's EUI-48 as your ethernet MAC address...

    Yes, the MAC address is pre-programmed in the flash. It is a globbaly unique MAC with Microchip OUI (the first 3 bytes which identify the producer)
    Beside the MAC it have also a nearly 2KB of user OTP area. Except for this is a normal flash that is accessed via SPI and/or SQI. I presume it could be used for P2 boot
  • localrogerlocalroger Posts: 3,451
    The only time I have been told of problems with 10bt hardware have been by IT guys for a couple of large corporations, and they were having problems with large rack-mounted enterprise grade systems. In addition to my own ENC28J60's I've used a lot of embedded hardware from our manufacturers with AnyBus cards, which are also 10bt. I think in one case they had to link my device to a consumer grade switch and then another port on the switch to the high speed plant network hardware. But like I said, I've put in hundreds of 10bt ports and never been unable to make them work.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-10-08 00:41
    I would never have thought that having a preprogrammed mac address was a big priority over other functions or a deal breaker. Sure, it's a nice thing but when my code starts up it checks the "eeprom" settings in code and if they are blank it sets them to defaults and generates a random mac and the top 16 bits of the oui set to $02FF.

    Performance wise I am finding that the w5500 is very snappy and especially so on the p2 with the higher bus speeds that are possible. Before I used to dole out a file sector by sector but I can see now that by increasing the block size using multi block card reads that it will be even snappier. But all of this including the TAQOZ console are working out of the same cog and when I move the server into its own cog it should be even better.


    EDIT: I've attached a screenshot from Wireshark during an FTP transfer which at present seems to indicate a 512 byte packet every 650us or so. Using a continuous non-breaking multi-block read with 2k packets should make it really zip.
    The whole server code including diagnostic routines and the W5500 driver take up just a tiny corner of memory, less than 6KB: 
    1273 lines and 5,598 bytes compiled,  with 0 errors in 2,324ms  ok
    FTPDATA.png
    1414 x 694 - 385K
  • CircuitsoftCircuitsoft Posts: 1,166
    Is the P2 fast enough to speak MII, RMII, or even RGMII?
  • AJLAJL Posts: 517
    Circuitsoft wrote: »
    Is the P2 fast enough to speak MII, RMII, or even RGMII?

    Pin toggling speed is more than enough, but I don't know how much layer 2 functionality you can fit before you start taking a significant chunk of resources.

    Given that the Wiznet W5500 chip in single unit pricing is ~AUD$4 from Mouser, and there are a number of fairly mature SPI solutions for the P2, what circumstances would motivate for this approach?


  • roglohrogloh Posts: 5,787
    edited 2019-10-15 06:08
    @Circuitsoft,
    As far as transfer speeds go, MII is 25 MHz nibble oriented transfers. The P2 can do this even with bit banging, though overclocking will help as will making use of the streamer. I believe ozpropdev is bit banging a 8 bit HyperRAM bus faster than this.

    RMII is two bits at 50MHz. Probably quite doable as well but more shifting is needed and there are not really that many native instructions to work on two bit quantities unlike nibbles, so you might need to accumulate them in software somewhere with your own shifting and that adds overhead. The streamer does have support for two bit quantities so it might do this for you.

    RGMII is 125MHz 4 bit DDR. This could be pushing the P2 a bit on receive side processing but raw transmission out at this speed could be doable, given the chip is already capable of outputting DVI data at a similar 250Mt/s. You may of course then have to start to deal with signal integrity issues and board layouts etc.

    Now while the P2 can probably transfer the raw data in and out at these rates, there would be additional overhead needed to do the framing and other control signal processing, any CRC etc. That's where it will get more interesting, and you may not be able to do line speed for long (which is probably ok if you can use Ethernet flow control or just allow TCP to try to rate adapt for the consequent packet loss if you are doing IP and have an IP stack to go with it).

    The biggest issue here is probably the clock source for receive data from the PHY. It would not be the same as the P2 clock if the P2 has its own crystal oscillator, and it will be derived from the recovered incoming data. I don't think the P2 can reliably clock data in that is asynchronous to it, as it's always synchronously sampled in using the P2 clock, right? However if you were to clock the P2 from the 125MHz or 25MHz received clock from the PHY and this clock remains active the entire time and doesn't shut off in between packets, that perhaps that could potentially work.

    Would be an interesting project to try...and supporting full duplex would need at least two COGs of course.
  • jmgjmg Posts: 15,173
    rogloh wrote: »
    As far as transfer speeds go, MII is 25 MHz nibble oriented transfers. The P2 can do this even with bit banging, though overclocking will help as will making use of the streamer. I believe ozpropdev is bit banging a 8 bit HyperRAM bus faster than this.

    RMII is two bits at 50MHz. Probably quite doable as well but more shifting is needed and there are not really that many native instructions to work on two bit quantities unlike nibbles, so you might need to accumulate them in software somewhere with your own shifting and that adds overhead. The streamer does have support for two bit quantities so it might do this for you.

    RGMII is 125MHz 4 bit DDR. This could be pushing the P2 a bit on receive side processing but raw transmission out at this speed could be doable, given the chip is already capable of outputting DVI data at a similar 250Mt/s. You may of course then have to start to deal with signal integrity issues and board layouts etc.
    ...
    It would not be as fast, but there are parts like XR2280x, that have USB <-> 10/100 Ethernet+Phy, that could give a pathway.
    I'm not sure what speeds P2 USB can sustain, but USB is somewhat proven on P2.

    Or, maybe a more common part like W5500 or W6100 can do 'good enough' Ethernet ?

  • JohnCJohnC Posts: 64
    Thought I'd revive this thread now that I've got samples on my desk. A handful of new Wiznet 850io modules should be here in a few days.

    To begin I'm working with this fork of Wiznet's GitHub:

    https://github.com/sstaub/Ethernet3

    ...which so far (I think) just requires edits to the Arduino SPI library:

    https://github.com/arduino/ArduinoCore-avr/blob/master/libraries/SPI/src/SPI.h

    I'll start with bit banging, then move up to using smart pins and the streamer.

    Finally I'm hoping to recreate most of the functionality of their Wiz-web platform, including web page serving via SD card or flash and remote firmware flashing over ethernet.

    https://github.com/Wiznet/WIZ550web

    Anyone interested in playing along? Or maybe I'm unknowingly duplicating a stack of existing work?

    @"Peter Jakacki" Super naive question here, but can Taqoz run other objects (C, spin...) in other cogs? Clearly I need to do more research.

    John

  • roglohrogloh Posts: 5,787
    edited 2020-02-05 23:42
    @JohnC, Looks interesting.

    I have some of these devices linked below myself and plan to use one with the P2D2 at some point after it arrives in my own custom project. Having some code that can drive the Wiznet5500 devices would be great.
    https://forums.parallax.com/discussion/157167/iot5500-p8-ethernet-server-lan-ant-ultra-compact-module

    The Arduino codebase is C++, are you going to run with that language or translate to something else first? Which C++ compiler are you targeting for P2? P2gcc?

    I've not yet looked into the code for adding socket support etc myself. But it makes sense to base it off something already available, or at least learn from that first before doing a P2 version if there are things you can do to optimize for that, or if porting APIs to SPIN2 etc. I imagine Peter Jakacki probably already has some Forth code that can drive these modules too. That could be of use if you know Forth and want to work in that environment.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2020-02-06 00:28
    While I enjoy using Forth and for me it is very natural and logical and consistent, I know that it is not most people's cup of tea. However if you do load up TAQOZ you can at the very least interact with the hardware to understand more about how it operates or can be made to operate. I have general-purpose SPI read and write routines in the kernel that are used for for the SD card and also for the W5500 etc.

    Then I have a W5500 layer on top of that which can access the registers the same as it would memory, so dumping and changing values interactively is very possible. There are also the fast block transfer routines too of course which can write at 3MB/s @250MHz and there are the little extras to look after the W5500 quirks.

    Write from 0 in hub to 0 in the currently selected W5500 memory for 2048 bytes while using LAP to time and report it. 
    TAQOZ# 0 0 2048 LAP LWRITE LAP .LAP --- 173,041 cycles= 692,164ns @250MHz ok

    You can assign the pinout at runtime so it is also possible to have multiple devices running and you can configure IP and other settings interactively. 
    TAQOZ# &20.23.22.21 WIZPINS ---  ok
TAQOZ# &192.168.0.101 SIP ---  ok
    (The & prefix is to force dotted decimal notation which is also useful to pass up to 4 parameters in a single long when setting pins for instance)

    On top of this is the socket interface, named registers and modes etc, a basic Telnet layer, and then FTP and HTTP server layers. It is possible to execute Forth code remotely too and the Telnet socket defaults to a Forth console anyway.

    By default the software reports activity and status to the serial console and extra message layers can be enabled.

    So, even if you don't program in Forth, there is no reason why you can't "use the Forth".
  • JohnCJohnC Posts: 64
    @rogloh good catch on the C++. The original Wiznet GitHub documents were written in straight C, so I may roll back to them instead. It just appeared the Ethernet3 guy had made some useful and recent changes.

    Making a version of this stable on Prop2 would be pretty useful to the community. In my own applications, I need a couple UDP or TCP sockets, T/FTP, and a webserver.

    https://github.com/Wiznet/W5500_EVB

    Of course the old Spinneret code is still around as well at https://www.parallax.com/product/32203. I gave up on it years ago because so much codespace was chomped up by the SD and webserver code that I didn't have much left to do what I needed.

    Also, it looks like the riscvp2 compiler will handle C++ code but I don't know if I'm smart enough to get it stable: http://forums.parallax.com/discussion/170295/riscvp2-a-c-and-c-compiler-for-p2/
  • roglohrogloh Posts: 5,787
    edited 2020-02-06 01:54
    JohnC wrote: »
    Making a version of this stable on Prop2 would be pretty useful to the community
    Yes it would. The WizNet stuff simplifies Ethernet/Internet access as you avoid the need to port or build a full IP stack first.

    I wonder if ultimately something could be developed to run as a standalone "Network COG" that provided network services to other COGs written in other languages via simple hub RAM / mailbox type API calls. Then you could develop it in whatever language you wanted and other environments could still make good use of it. The key thing to do then is probably the development of a generic useful API that covers almost all use cases.
  • ElectrodudeElectrodude Posts: 1,657
    @VonSzarvas Could you consider making an Ethernet accessory board for the P2-ES that uses a W5500 or something?
  • ManAtWorkManAtWork Posts: 2,176
    I always thought that the WZ5500 was way too expensive for my applications. But I just saw that it is <$2 if you buy 1000. So it's actually even cheaper than the ENC28J60 in large quantities.

    My case is a bit special. I don't need an IP stack but access to the raw packet level. But I think that would be no problem. Once the SPI and register level driver is working there should also be a way to bypass the IP stack.
  • JohnCJohnC Posts: 64
    edited 2020-02-06 15:27
    @ManAtWork I've done this on the W5200 chip using UDP, simply open a socket & port number combination. Then you can bring in raw packets (including for UDP the header calling out source address, destination address and packet size) and do what you want with the data.
  • Peter JakackiPeter Jakacki Posts: 10,193
    Seems that you can only do RAW mode in socket 0, so I tried it by setting it with a one-liner including enabling the MAC filter. 
    TAQOZ# 0 SOCKET sCLOSE MACRAW $84 0 LC! sOPEN ---  ok
    Then checked the status 
    TAQOZ# ifconfig --- 
NETWORK STATUS:
LINK *UP*
HARDWARE: P2D2  using WIZnet W5500 V4 
SRC IP    192.168.000.150
MASK      255.255.255.000
GATEWAY   192.168.000.001
MAC       02.FF.62.69.02.01.
SKT HH:MM:SS MODE  PORT  DEST  TXRD TXWR RXRD RXWR RXSZ  IR STATUS            IP ADDR
#0   02:07:57 MACR     0     0 0000.0000.0000.0000.0000. 04 42 
#1   02:07:57 TCP     21 44004 0000.0000.0000.0000.0000. 17 14 LISTEN      
#2   02:07:57 TCP      0 43200 99FD.99FD.0000.0000.0000. 13 00 closed      
#3   02:07:57 TCP     23     0 0000.0000.0000.0000.0000. 00 14 LISTEN      
#4   02:07:57 TCP     80     0 0000.0000.0000.0000.0000. 00 14 LISTEN

    Then dumped the socket registers and part of the receive buffer to check it a bit more. 
    TAQOZ# 0 SOCKET @SOCKET 0 $40 WIZ DUMP --- 
00000: 84 00 04 42  00 00 FF FF  FF FF FF FF  00 00 00 00     '...B............'
00010: 00 00 05 C0  00 00 00 00  00 00 00 00  00 00 00 00     '................'
00020: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
00030: 01 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................' ok
TAQOZ# @RX 0 $40 WIZ DUMP --- 
00000: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
00010: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
00020: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
00030: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................' ok
TAQOZ#

    I will have to play with that part of it a bit more yet in the morning but I will try out UDP as well.
Sign In or Register to comment.