Skip to content

Feature Request: Refactor SPI to allow alternative implementations (e.g., Software SPI) #9293

@loplex

Description

@loplex

The problem

Currently, the core SPIClass is a concrete implementation tied directly to the hardware SPI peripheral (HSPI).

Libraries included in this repository, such as ESP8266AVRISP, are hard-coded to use the global SPI instance. For example, ESP8266AVRISP.cpp directly calls SPI.begin() and SPI.transfer().

This creates a problem: it's impossible to use ESP8266AVRISP (or other similarly-coded libraries) if the hardware SPI pins (GPIO 12, 13, 14) are already in use by another device. It also prevents the use of a "bit-bang" (software) SPI implementation on arbitrary pins.

My goal is to add a Software SPI implementation and be able to use it with the ESP8266AVRISP library.

Proposed solution

I propose refactoring the SPI ecosystem to allow for "Dependency Injection," where a library (like ESP8266AVRISP) accepts an SPI implementation in its constructor instead of being hard-coded to the global SPI object.

My contribution

I have working solution with modified ESP8266AVRISP which use software SPI implementation I made. I can make PR if this propose is accepted

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions