@Simonius said:
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
Yes there is that synchronous Smart Pin mode that can clock data in with an external clock. If the clock is only 25MHz and the P2 is running a lot faster than that, there could be some scope for an external RX clock to be used. RX data wouldn't be streamed though, it would be received by a Smart Pin and we'd need to re-order bits into nibbles and write the data into the FIFO. There are those MERGE/SPLIT instructions that could be useful there.
Ideally for the most processing time you'd probably want to work in quantities of up to 32 bits on each pin, but if the clock stops at the end of a packet it might be a problem as you'd be hanging at the end. If the RX clock continues all the time this is probably not an issue. You just figure out the true ending of the packet where it really is and make that known (some extra redundant bits get copied to HUB RAM).
Is RGMII SDR or DDR? I read some stuff mentioning it was DDR, which could be problematic with Smart pins unless you had a second one that had an inverted clock input for each data pin? Also RGMII might not be 3.3V, but 2.5V or 1.8V.
If RGMII worked out it would be a good mapping for a double wide breakout for P2-EVAL or JonnyMac boards with up to 16 pins used. You'd get all the needed signals in 16 pins with a couple of pins spare for maybe a copy of the LINK LED status, or resets/interrupts from PHY etc.
Does anyone have any ideas for quickly connecting the P2 to wired ethernet?
An expensive, but low-code option is the XPort module; it's a serial-to-Ethernet bridge.
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.
Building a custom board for the Tibbits. I have a selection of them and will be creating more, using the empty shells. @Cluso99 is waiting for info from me to modify the P8XBlade2 so that it will clip in to a double-wide Tibbit shell
Comments
Yes there is that synchronous Smart Pin mode that can clock data in with an external clock. If the clock is only 25MHz and the P2 is running a lot faster than that, there could be some scope for an external RX clock to be used. RX data wouldn't be streamed though, it would be received by a Smart Pin and we'd need to re-order bits into nibbles and write the data into the FIFO. There are those MERGE/SPLIT instructions that could be useful there.
Ideally for the most processing time you'd probably want to work in quantities of up to 32 bits on each pin, but if the clock stops at the end of a packet it might be a problem as you'd be hanging at the end. If the RX clock continues all the time this is probably not an issue. You just figure out the true ending of the packet where it really is and make that known (some extra redundant bits get copied to HUB RAM).
Is RGMII SDR or DDR? I read some stuff mentioning it was DDR, which could be problematic with Smart pins unless you had a second one that had an inverted clock input for each data pin? Also RGMII might not be 3.3V, but 2.5V or 1.8V.
If RGMII worked out it would be a good mapping for a double wide breakout for P2-EVAL or JonnyMac boards with up to 16 pins used. You'd get all the needed signals in 16 pins with a couple of pins spare for maybe a copy of the LINK LED status, or resets/interrupts from PHY etc.
Building a custom board for the Tibbits. I have a selection of them and will be creating more, using the empty shells. @Cluso99 is waiting for info from me to modify the P8XBlade2 so that it will clip in to a double-wide Tibbit shell