IMP005 Design related queries



I intend to use imp005 for my new design, I want to use Ethernet to provide internet. After going through your documentation, I need some clarity on the following points:

• When will the deepsleep() feature be implemented?
• What’s the difference between SPI in IMP003 & IMP005?
• Does Ethernet have an in-built stack?
• The issues mentioned in Imp005 BlinkUp circuit have not been corrected right?


@peter please could you address these concerns


Although the imp005 is currently the only imp type which supports Ethernet (and indeed also the only one which supports 5GHz wifi), it does have important limitations in other areas, compared to other imp types.

There are no current plans to implement deepsleep() on imp005.

The SPI hardware on the imp005 implements a weirdly pedantic interpretation of the spec, which results in the final clock pulse in any transfer only being half the width you’d expect. Some SPI slaves deal with this, but others need a small RC circuit implementing to stretch the clock pulses. Additionally, the SPI hardware on other imps is fed by DMA, meaning that the bytes go out back-to-back, enabling use of SPI as effectively a digital signal generator, for instance to drive WS2812 “Neopixels” – but the SPI hardware on imp005 cannot do back-to-back bytes; there are small gaps between each one, ruling out similar designs.

Just as on other imps the wifi chip and TCP stack are dedicated to the imp’s connection to our cloud servers, so is Ethernet on the imp005. All of that is built-in. Additionally, limited forms of local (Squirrel-controlled) networking are planned in future firmware releases.

I’m not sure what issues you’re referring to, but I can’t immediately see any out-of-date information in that thread.



@hugo unlike the SPI & I2C does the UART work fine?


That’s not correct; both I2C and SPI work fine too (and are used in many commercial applications). They have restrictions that may sometimes be important - and the customer needs to be aware of - but they are totally functional for almost all use cases.

UARTs on 005 don’t have any specific limitations that mark them out as different to 001-004.