force new enums for pinMode and pinStatus to 8 bits type instead of default int
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 18/100
- Tipo de issue
- Refactorización
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Área
- embedded-iot
Línea de trabajo
Comienza buscando las declaraciones de los enums PinMode y PinStatus en la API ArduinoCore-API y, después, evalúa las consecuencias para la compatibilidad de código fuente y binaria en el código Arduino existente. Se considera terminado cuando exista una decisión del proyecto sobre si los tipos subyacentes uint8_t propuestos son aceptables; el propio issue recomienda no adoptarlos en producción.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I've seen
typedef enum {
LOW = 0,
HIGH = 1,
CHANGE = 2,
FALLING = 3,
RISING = 4,
} PinStatus;
typedef enum {
INPUT = 0x0,
OUTPUT = 0x1,
INPUT_PULLUP = 0x2,
INPUT_PULLDOWN = 0x3,
} PinMode;
This will let the compiler decide how big the backend storage needs to be for those, and it will default to an int (16 or 32 bit depending on architecture). There is no need for this waste of memory and it prevents also some compiler optimization
I suggest forcing the uint8_t type, 256 values should be plenty to represent a pinMode or a pinStatus..
proposed changes:
typedef enum : uint8_t {
LOW = 0,
HIGH = 1,
CHANGE = 2,
FALLING = 3,
RISING = 4,
} PinStatus;
typedef enum : uint8_t {
INPUT = 0x0,
OUTPUT = 0x1,
INPUT_PULLUP = 0x2,
INPUT_PULLDOWN = 0x3,
} PinMode;
but in practice I would vote against getting these changes in production. There is no value added and tons of unwanted consequences for existing code out there to make this worthwhile.
- Lenguaje dominante
- C++
- Estrellas
- 307
- Forks
- 152
- 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 arduino/ArduinoCore-API
-
Bit manipulation not working with 64 bit valuesPosiblemente ocupada @asumo-1xts la tomó hace 36 días. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 25/100
arduino/ArduinoCore-API#261 ·
-
Missing virtual destructor for `Print` classPosiblemente ocupada @andreagilardoni la tomó hace 1104 días. Abiertobug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 30/100
arduino/ArduinoCore-API#256 ·
-
enhancement
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
arduino/ArduinoCore-API#251 · 1 comentario ·
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
arduino/ArduinoCore-API#250 ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 45/100
arduino/ArduinoCore-API#249 ·
Todos los issues de arduino/ArduinoCore-API
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
MerginMaps/mobile#4741 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Icinga/icinga2#11077 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
-
agent:WSL bug linux LOW ui
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Copter: PosHold brake-entry threshold became 16 deg instead of 0.16 deg after the radians conversionPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
ArduPilot/ardupilot#34617 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día