Feature Request: Refactor SPI to allow alternative implementations (e.g., Software SPI)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- cpp
- Área
- embedded-iot
Línea de trabajo
Comienza leyendo ESP8266AVRISP.cpp y la implementación principal de SPIClass, centrándote en las llamadas directas a SPI.begin() y SPI.transfer(), así como en la dependencia global de SPI. Compara el diseño existente de hardware SPI con la implementación propuesta de Software SPI. Se considerará completado cuando ESP8266AVRISP pueda usar una implementación alternativa de SPI inyectada en lugar de estar vinculada a los pines de hardware SPI.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- Lenguaje dominante
- C++
- Estrellas
- 16.7k
- Forks
- 13.1k
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de esp8266/Arduino
-
Typo in Scan Class DocumentationPosiblemente ocupada @MukundaKatta la tomó hace 179 días. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 70/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
lwip2 time-wait.patch: TCP_TW_LIMIT can abort the pcb that tcp_process() is still handling -> double free, heap corruptionPosiblemente ocupada @scardus la tomó hace 13 días. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
Todos los issues de esp8266/Arduino
Issues similares
-
[BUG] Process Tab LayourAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
Add a FakeAudioIo for host testsAbiertoc++ good first issue M2: audio plumbing no hardware needed tests
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
GageLawton/noise-cancellation#23 ·
Los mantenedores suelen responder en 1 día
-
Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
scipy/xsf#312 · 4 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
nullmoth/nvidia-macos-driver#126 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
objectionary/eo-graphs#85 ·