add ethernet to a micromod format teensy

M

mah

Well-known member
i have decided to switch the t4.1 in project to a micromod teensy.
But i need ethernet for the project, to send and recive osc, and maybe artnet, i guess my only requirement is "no audible latency"

I feel like my options are:


-Use a spi ethernet ic on my carrier board like W5500
(afraid this migth be less effective then using the DP83825, but i wont be sending huge amounts of data)



-create my own micromod(with the pjrc boot loader) or modifying the sparkfun board design with the "native" ethernet controller (DP83825)
would i have to use the exact same pin connections as the T4.1? or is there a way to change which pins the ethernet controller connects to?
This would of course make the micromod "non standard" and i would need to sacrifice a couple of other pins



-use the DP83825 on the carrier board somehow, could it be possible?
 
if read correctly ... PaulStoffregen made a note on Twitter about possible alternate pin usage ... would take code work and a custom carrier ???
 
Before making any "final" decisions, I would imagine the first step would be to actually measure the latency using a Teensy 4.1 and both native and w5500 ethernet.

And yes, here is the twitter message about possible RMII pins

https://twitter.com/DL7PNP/status/1411089448075501577

Here's that list as text (where we're not constrained by 280 chars)

Code: 
 RMII	 NXP Pin	Schematic	M.2 Pin
 ----	 -------	---------	-------
 RX0	 SD_B0_03	34/DAT1		  66
 RX1	 SD_B0_04	38/DAT2		  68
 RXEN	 SD_B0_05	39/DAT3		  70
 RXER	 B1_00		AUD_IN/8	  54
 TX0	 B0_12		GPIO/32		  65
 TX1	 EMC_31		I2C_INT/29	  16
 TXEN	 EMC_32		GPIO/28/3.3V_EN    4
 CLK	 SD_B0_01	36/CLK		  60
 MDC	 B0_00		CS/10		  55
 MDIO	 B0_01		CIPO/12		  61
 
If all the pins are already available then making the required carrier board should be easy and as far as adding in the support to FNET that can easily be done with a couple edits to some defines to change the pins.
 
These pins bring out the RMII signals for ENET2, so the software side would also need to be adapted to use the other controller.
 
That is also easily changed with a define, luckily FNET is already setup to handle multiple ENETs if your processor is using more than one.
 
mah said:
i have decided to switch the t4.1 in project to a micromod teensy.
But i need ethernet for the project, to send and recive osc, and maybe artnet, i guess my only requirement is "no audible latency"
Click to expand...

I am very interested in your project. I have been recently experimenting with our OSC Arduino library on Native Ethernet on Teensy 4.1 and it has been working well so far.

Let me know how I can help. I can certainly review and test any board you might make.

Are you planning to put audio on your carrier?
I have been using a Tsynth for this but it isn't easy to combine a T4.1, ethernet kit connectors and the audio shield.
 
no audio. just lots of control signals (cv, midi, osc)
ill see if i can get you the gerbers later, its quite specific pcb with some expensive parts...
 
I have marked the pins with a green dot to make it easier to see.

tmmethernet.jpg
As i need both spi and sd card on this carrier, are those pins also changeable with a define?

Im gonna design my next prototype with the MM t4 and the w5500, as i already have proto with t4.1 and Ethernet up and running. and test them side by side, or i might just buy the w5500 shield.
The benchmark from here seems quite impressive https://www.pjrc.com/arduino-ethernet-library-2-0-0/ ,if im reading it right. If packets are sent with 0.1ms latency on a LAN its definitely good enough for my needs.
 
mah said:
As i need both spi and sd card on this carrier, are those pins also changeable with a define?
Click to expand...

RMII RX0 & RX1 are only available on those specific pins, so RMII and SDIO are an unresolvable conflict on MicroMod. If using RMII, any SD card needs to be connected by SPI rather than SDIO.

While the same is true for the 2 management pins and SPI, we could probably implement MDIO by bitbanging on any pins. Giving up the primary SPI port is pretty painful.
 
PaulStoffregen said:
RMII RX0 & RX1 are only available on those specific pins, so RMII and SDIO are an unresolvable conflict on MicroMod. If using RMII, any SD card needs to be connected by SPI rather than SDIO.

While the same is true for the 2 management pins and SPI, we could probably implement MDIO by bitbanging on any pins. Giving up the primary SPI port is pretty painful.
Click to expand...

@PaulStoffregen I was looking at this, but getting PHYs these days is 39 weeks away. So I've got time to figure out the MicroMod board, but what else is needed to get this to work?

When you say software side, does the core support ethernet on these MicroMod pins? Or will the core or library (QNEthernet) need to be modified?

Are all RMII interfaces compatible? Or will only the DP83825 work with Teensy?

Thank you.
 
The library would just have to be modified which is easy enough to do since most of it overlaps with the T41. It’s not necessary to use the exact same PHY since whatever support that has to be added to QNEthernet can also add support for a different PHY though at the most basic level there aren’t too many differences between chipsets.
 
Most RMII PHY chips should work. But if it can't be configured with resistors on the pins, the MDIO communication might need to write to different config registers to put it in the proper mode.

RMII is pretty much always the same, except for the clock. Sometimes it's an input, sometimes the PHY has an oscillator and it outputs the clock. Teensy 4 creates the 50 MHz clock, so the PHY needs to be configured to receive external clock.
 
PaulStoffregen said:
Most RMII PHY chips should work. But if it can't be configured with resistors on the pins, the MDIO communication might need to write to different config registers to put it in the proper mode.

RMII is pretty much always the same, except for the clock. Sometimes it's an input, sometimes the PHY has an oscillator and it outputs the clock. Teensy 4 creates the 50 MHz clock, so the PHY needs to be configured to receive external clock.
Click to expand...

Thanks Paul & vjmuzik, perhaps @shawn can chime in on QNEthernet's effort needed, or someone else with the chops to add it. I can whip up a MicroMod board.
 
I couldn’t promise a timeline, but if you send me some hardware I could poke around with modifying QNEthernet. I think only lwip_t41.c would need to be modified.
 
I found 7 leftover LAN8720A chips from the Teensy 3.6 prototype days. Looks like the default config takes 50 MHz clock input, so if I remove the 25 MHz crystal and pulldown resistor configuring it for the crystal, looks like it should "just work" without needing MDIO config.

If nobody else is working on hardware, I'll give it a try in a few weeks and send you a board, if I can get it to ping.
 
Thanks Paul, I grabbed a handful as well. I'll update here if I catch a break and start on a MicroMod ethernet test board.
 
Here's my initial thoughts on the LAN8720A wiring. This mostly duplicates msg #3, but the MDIO pins are moved because conflicting with the primary SPI port is a huge cost for a feature we're probably not ever going to actually use. We can always bitbang MDIO if someone wants to access optional features.

We'll probably also end up not connecting RXER, but a first attempt should have a zero ohm jumper just in case. In theory, we can live without RXER (which conflicts with I2S audio) and allow the MAC to detect receive errors.

pin 1: VDDA: analog 3.3V (connected to digital 3.3V by ferrite bead) - same as pin 19
pin 2: (optional) 100 Mbit LED cathode. LED anode connects to 220 ohm resistor to analog 3.3V. (optional) 10K pullup to analog 3.3V.
pin 3: activity LED anode. LED cathode connects to 220 ohm resistor to GND
pin 4: no connection - this pin would normally be for a crystal, but MicroMod Teensy outputs 50 MHz clock
pin 5: REF CLOCK: connect to low-value resistor which connects to Arduino pin 36 - place resistor close to M.2 socket
pin 6: VDDCR - decouple with 1uF and 1nF capacitors
pin 7: RXD1 - Arduino pin 38 - M.2 pin 68
pin 8: RXD0 - Arduino pin 34 - M.2 pin 66
pin 9: VDDIO - digital 3.3V
pin 10: RXER - Arduino pin 8 - M.2 pin 54 - use 0 ohm resistor, probably will not connect this signal in final usage
pin 11: CRSDV - (aka RXEN) Arduino pin 39 - M.2 pin 70
pin 12: MDIO - Arduino pin 35 (optional, MDIO config not required)
pin 13: MDC - Arduino pin 33 (optional, MDIO config not required)
pin 14: INT/REFCLKOUT - no connection
pin 15: RESET- Arduino pin 37
pin 16: TXEN - Arduino pin 28 - M.2 pin 4
pin 17: TXD0 - Arduino pin 32 - M.2 pin 65
pin 18: TXD1 - Arduino pin 29 - M.2 pin 16
pin 19: VDDA: analog 3.3V (connected to digital 3.3V by ferrite bead) - same as pin 1
pin 20: TX_NEG - 49.9 ohm pullup to analog 3.3V - connect to magjack or transformer
pin 21: TX_POS - 49.9 ohm pullup to analog 3.3V - connect to magjack or transformer
pin 22: RX_NEG - 49.9 ohm pullup to analog 3.3V - connect to magjack or transformer
pin 23: RX_POS - 49.9 ohm pullup to analog 3.3V - connect to magjack or transformer
pin 24: RBIAS - 12.1K resistor to GND
center pad: GND
 
Thanks for the groundwork on this Paul. I started an Eagle schematic, pdf attached.

I'm not quite done, need to find an LDO and finish up the voltage regulation section. Maybe bring out some pins to a header and add an LED for debugging.

Let me know if I goofed on anything.

View attachment Teensy MM Ethernet.pdf
 
Here's a few possible issues I see...

VDDCR must not connect to 3.3V. This is the output of a 1.2V LDO regulator which powers internal circuitry. Add capacitors to this pin, but do not connect to any other power, only the capacitors connect to that pin.

Activity LED+resistor needs to connect to GND. During startup, the chip looks at whether the LED connects to GND vs 3.3V to enable / disable its LDO regulator. Connecting to 3.3V will disable the 1.2V power. See Figure 3-10 on page 32 of the LAN8720A datasheet for detail.

The other LED does connect to 3.3V (which configures LAN8720A to receive clock from Teensy and disable its crystal oscillator). But it's supposed to connect to analog 3.3V, not digital 3.3V.

Analog 3.3V should have decoupling capacitors. See Figure 3-18 on page 39.

R12 & R27 (49.9 ohms) and the transformer center tap (pin 6) probably want to connect to analog 3.3V, like in Figure 3-18.

I don't understand the 33 ohm resistors. Maybe they're meant for ESD? I don't understand why they would be between the 49.9 ohm resistors and PHY chip. Maybe that's ok?

I didn't (yet) check the connections to the M.2 pins.
 
I should also mention, a few other pins configure the chip (in the absence of MDIO usage) depending on their voltage at startup. But I believe they all have built in pullups for the settings we will use. And even if they don't automatically work, we can solve the problem with software that drives the pins before pulsing reset. So the 2 LEDs are the only config pins to really worry about getting correct pullup / pulldown, because Teensy won't have those 2 signals connected to GPIO pins.
 
TeensyWolf said:
might be less effort to use instead of the chips.
Click to expand...

I don't understand how this design works with LED1 (pin 3) connected to a LED tied to 3.3V. Maybe the LED's forward voltage is enough that it doesn't conduct enough at startup to overpower the weak pulldown resistor inside the LAN8720A chip. But it's meant to be overridden by only 10K, according to page 32 of the datasheet, so I'd guess this LED connection is rather risky of having the 1.2V regulator not enabled.

I also don't understand connecting RXER to 3.3V by only 10 ohms. RXER is meant to be an output, right?

The 50 MHz oscillator would need to be removed, since Teensy creates the 50 MHz clock.
 
You must log in or register to reply here.
Back
Top