smoltcp-rs/enc424j600

smoltcp driver for the ENC424J600 SPI Ethernet MAC

enc424j600's Issues

Delays are needed when initialising the controller

Description

Currently, there is no delay code within the driver library itself. To properly initialise the controller, the following delays (in us) should appear in user's own implementation:

1. On power-up, set SPISEL to high for 1-10 us in order to have enough time to latch the selection of the SPI interface (done outside of init_dev() and before instantiating SpiEth, e.g. in tx_stm32f407). [Section 2.7 of the datasheet]
2. After instantiating SpiEth, during init_dev():
   1. Set ETHRST to 1, delay ≥25 us, then read EUDAST. [Point 5, Section 8.1 of datasheet]
   2. After reading and checking EUDAST, delay ≥256 us, then end the init_dev() function. [Point 7, Section 8.1 of datasheet]

Point 2i & 2ii should be done within the library and the user wouldn't need to care about the delays. In contrast, point 1 is hard to implement within the library since this must be done before instantiating any controller-related objects, e.g. the SPI port abstraction or the SpiEth controller itself.

Possible approaches

We can probably implement 2i & 2ii delays by acquiring some delay functions when init_dev() is called. Here are some examples:

1. Require the user to pass a delay function/closure (e.g. cortex_m::asm::delay()) to the SpiEth::new() constructor
2. Require the user to pass a delay function/closure to the SpiEth::init_dev() function
3. Require the user to pass an object capable of delaying (e.g. embedded_hal::blocking::delay::DelayUs) to the SpiEth::new() constructor
4. Require the user to pass an object capable of delaying to the SpiEth::init_dev() function

Update: As of e9a3a5e, the 4th approach is chosen and has been tested on STM32-H407.

Large stack memory usage

Description

With a large MTU / RAW_FRAME_LENGTH_MAX at 0x1000, large amount stack space is consumed. Seems that large arrays are allocated onto the stack on transmitting/receiving packets.
On transmitting case, these few lines of code may have contributed to this issue.

ENC424J600/src/tx.rs

Lines 54 to 60 in 010be3e

	impl TxPacket {
	pub fn new() -> Self {
	TxPacket {
	frame: [0; RAW_FRAME_LENGTH_MAX],
	frame_length: 0
	}
	}

ENC424J600/src/lib.rs

Lines 161 to 163 in 010be3e

	// Copy packet data to SRAM Buffer
	// 1-byte Opcode is included
	let mut txdat_buf: [u8; RAW_FRAME_LENGTH_MAX + 1] = [0; RAW_FRAME_LENGTH_MAX + 1];

Shrinking RAW_FRAME_LENGTH_MAX to 1500 have improved this significantly in my case.
Is it worth looking into reusing large arrays? Or even allow static buffers to be supplied by user?

Any plans to turn this into a generic driver?

Hi there.

First of all great work, I've managed to this get this crate to work easily on my homebrewn ENC424J600 board.

Currently this is all very much dependent on stm32f4xx-hal (which is cool 😎) but it doesn't make for a great universal driver, even the embedded-hal trait is re-exported from there:

ENC424J600/src/spi.rs

Lines 2 to 8 in b38c5ae

	use stm32f4xx_hal::{
	hal::{
	blocking::spi::Transfer,
	digital::v2::OutputPin,
	},
	spi,
	};

The Cargo.toml is lying, too, since stm32f4xx-hal is defacto not an optional dependency. Even just using it from another project which is based on a STM32F4 is not possible at the moment due to this. 😢

Hence my question what the plans for the future are.