Uint8_t arduino

Formato doble-pr… flotante-po…

Creo que todo el sistema de tipificación de C, cuando se trata de int está roto. Por varias razones, en la tierra de los 64 bits, se eligió mantener int en 32 bits, en lugar de hacerlo en 64 bits (lo que habría sido más natural). Es una de esas situaciones de compromiso en las que cualquiera de las dos elecciones que se hagan afectan al código existente.

No del todo… El estándar C sólo define char, int, short, long… y variantes sin signo, por supuesto. Tanto byte como boolean son sólo conveniencias. Los estándares C posteriores añadieron los tipos intxx_t y uintxx_t para resolver un antiguo problema de no saber con seguridad el tamaño real de un int. Sin embargo, no todos los compiladores de C tienen definidos estos tipos, así que técnicamente no son buenos para la mejor portabilidad.

En cuanto a cuál es «mejor», eso depende de ti y de la aplicación. Yo uso MUCHO uint8_t para números pequeños porque no quiero asignar >8 bits para algo que nunca será mayor que 255. Uso char para caracteres individuales (o matrices) de texto, y a menudo uso byte para denotar bytes arbitrarios de datos. Todos se refieren a lo mismo -un byte de memoria- pero la definición ayuda a iluminar su intención, junto con un nombre de variable bien elegido, por supuesto.

Entero

El único difuso es int. Esto es «un valor entero con signo en el tamaño nativo para el compilador». En un sistema de 8 bits, como los chips ATMega, son 16 bits, es decir, 2 bytes. En sistemas de 32 bits, como los Due basados en ARM, son 32 bits, es decir, 4 bytes. De los tres es el único que cambia.

Personalmente, rara vez uso int y siempre uso uint8_t, etc., ya que el tipo de variable es el mismo independientemente de la arquitectura para la que se compile. Cuando usas int puedes encontrarte con problemas si tienes un programa que funciona bien en un ARM de 32 bits pero luego no funciona bien en un ATMega de 8 bits, ya que el int sólo puede almacenar una fracción del rango de números en el sistema de 8 bits comparado con el de 32 bits.

Uint8_t*

Estoy aprendiendo esp8266 usando arduino IDE. Todavía soy un principiante en la programación de la placa de desarrollo. Lo que he tratado de hacer es usar una librería de criptografía. Estoy probando AES en arduino y elegí esa librería porque parecía completa, y era una de las únicas que usaba ECB. Mi problema es que mientras llamo a la función encrypt, me confundo con la salida.

La librería que enlaza señala, justo en la posición de enlace, que los parámetros de salida y entrada deben tener una longitud mínima de blockSize() bytes. Haciendo referencia a blockSize(), señala que esta función siempre devuelve 16. Por lo tanto, es necesario pasar un array de uint8_ts de al menos 16 de longitud.

Cada uno de los 16 bytes puede tener un valor en el rango de 0 a 255. No tienen que estar limitados a números de un solo dígito; sólo he copiado/traducido lo que has escrito para demostrar el ejemplo. Podrías establecer tu clave de esta manera:

Una cadena de estilo C es una secuencia de bytes, con el tipo char para indicar datos ASCII, aunque cualquier tipo de bytes podría funcionar en teoría. La secuencia de bytes termina con un valor de 0 (es decir, 0x00, no el carácter ASCII ‘0’), por lo que debe recordar que el byte de terminación ocupa un byte de memoria.

Const uint8_t arduino

Así que const uint8_t motorDirectionPin = 3; declara una constante, que requiere 8 bits de memoria, representando un número sin signo e inicializado con el valor 3 al que puedes referirte más adelante en el código con el nombre motorDirectionPin.

Sí, hay algunas funciones que no están implementadas por defecto, ya que podrían inflar el código binario hasta un tamaño irrazonable (como el manejo de float en algunas funciones de cadena), pero estás bastante seguro con el estándar c++ como guía.

Esto ayuda al compilador. Si ese nombre se declara como una constante, por lo que no va a cambiar, el compilador probablemente no va a asignar memoria para ello en absoluto y sólo sustituirá en lenguaje ensamblador la referencia a la búsqueda de memoria que tendría que hacer con el número 3. Así que se utiliza menos memoria y el código es más rápido.

También te ladrará si tienes un error y más tarde en tu código intentas cambiar el valor a otra cosa por error porque const no puede cambiar el valor. Así que eso es un beneficio también en términos de calidad del código.