Diferencia entre el tipo de datos int y long en Arduino

Estaba aprendiendo a programar para un robot de obstáculo vacío pero cuando miré el código Vi dos tipos de datos long e int.

Int son tipos de datos que contienen -2,147,483,648 a 2,147,483,647. Long también son tipos de datos que contienen -2,147,483,648 a 2,147,483,647.

Int y long son iguales pero se me ocurrió el código donde se usan dos tipos de tipos de datos como se ve a continuación:

int trigPin = 2; int echoPin = 4; long duration, cm, inches; 

Pero, ¿cómo puede saber cuándo usar qué tipo de datos? Busqué mucho en la web pero no entendí, así que alguien me puede explicar esto por favor.

Comentarios

  • » Int son tipos de datos que contienen -2,147,483,648 a 2,147,483,647 » ¿Dónde escuchaste eso?

Respuesta

En Arduino (modelos AVR) un int es de 16 bits, no de 32 bits. Por lo tanto, va de -32768 a +32767.

Eso es diferente de long que es de 32 bits.

Comentarios

  • ¿Cuáles son los anchos de int y long en los Arduinos ARM de 32 bits como Due?
  • Creo que en el Due que un int es de 32 bits, lo mismo que long. Consulte aquí , por ejemplo.

Respuesta

int en AVR GCC es 16 bits , no 32.

Respuesta

De acuerdo con la especificación del lenguaje C , int debe tener al menos 16 bits o más y long debe tener al menos 32 bits o más.

Está bien que un compilador implemente int como 32 bits o incluso 64 bits. Está bien que un compilador implemente long como 64 bits o más. Pero no está permitido que un compilador implemente long como 16 bits.

Entonces, ¿cuándo usar qué tipo?

Si los valores con el que trabajará se puede representar en 16 bits, entonces está bien usar int. Si necesita más de 16 bits, use long. Si necesita más de 32 bits, use long long.

No se deje atrapar por las especificaciones del compilador y / o CPU. Como han mencionado otros, incluso dentro de la misma gama de productos, Arduinos, hay CPU de 16 y 32 bits disponibles. En su lugar, solo confíe en lo que garantiza el estándar.

La especificación completa de los tipos en C son:

  • char debe tener al menos 8 bits
  • int debe tener al menos 16 bits
  • long debe tener al menos 32 bits
  • long long debe tener al menos 64 bits

Nota: Es perfectamente legal para los compiladores implementar char, int, long y long long como 64 bits. De hecho, esto no es infrecuente entre los DSP.

Comentarios

  • Además: lea la documentación del compilador
  • Y: sizeof(char) <= sizeof(int) <= sizeof(long) <= sizeof(long long) según estándar. Entonces, si int es de 64 bits, entonces long también debe ser de al menos 64 bits.

Respuesta

Es el mismo razonamiento que en C: se espera el tamaño del tipo int para ser el tamaño de palabra natural que su sistema maneja de manera más eficiente . También debe tener al menos 16 bits de ancho, no menor que short y no mayor que un long.

Por tanto, un int puede basarse en 16, 32 o 64 bits en lo que sea que su sistema maneje mejor, por lo que es más probable que tenga 16 bits de ancho en una CPU de 8 o 16 bits, 32 en una CPU de 32 bits, etc.

Yo uso int cuando quiero el mejor rendimiento, mientras tengo cuidado de protegerme cuando necesito más rango que el ofrecido por 16 bits. En estos días, tiende a saber cuándo está escribiendo código de aplicación para sistemas de 16 bits, aunque eso no es tan cierto para el código de «biblioteca» donde la portabilidad puede ser de mayor preocupación.

En su ejemplo, suponiendo que el autor haya elegido sus tipos con cuidado, las int variables probablemente requieran un rango pequeño y podrían permitirse el tamaño de una palabra , lo que conduce a un código potencialmente más corto o más rápido (o ambos). Los long presumiblemente requieren un rango de más de 16 bits (se garantiza que tengan al menos 32 bits de ancho). En el procesador que seleccionó como destino de compilación, parece que int y long se implementaron como de 32 bits; esto ser diferente (o debería ser) si seleccionó una CPU de destino de 16 bits.

Respuesta

Me gusta usar tipos de stdint.h.

Si bien tienen pequeños inconvenientes, el beneficio que brindan es que usted sabe exactamente el tamaño que está manejando, incluso cuando se compila en otras arquitecturas.

#include <stdint.h> uint8_t my_byte = 0xf0; int16_t trig_pin = 2; int16_t echo_pin = 4; uint32_t duration, cm , blah; uint64_t big_int; // etc. 

Pero, obviamente, no desea moverse por un montón de int32_t cuando sus datos solo necesitan int16_t.

Comentarios

  • Por lo tanto, no use palabras de máquina el tamaño no afecta el rendimiento en AVR?
  • @Ren é – Generalmente, no usar el tamaño de palabra puede afectar el rendimiento en la mayoría de las CPU. Pero tradicionalmente las CPU AVR tienen registros de 8 bits & acumuladores con algunas instrucciones de 16 bits para operaciones de puntero. Entonces, cuando programo, hago que el código se ejecute primero, luego lo optimizo para la velocidad si es ‘ es demasiado lento.
  • @Ren é – Pero si realmente quieres ser pedante al respecto, podrías usar word como su tipo de datos. Esto es 16 bits en Arduino Uno y 32 bits en Arduino Due & Zero. Pero esto vuelve al problema de saber realmente solo el tamaño mínimo de su tipo de datos. Supongamos que usa word en algún código Due, ¡pero luego quiere hacer un back-port a Uno ?! Usar uint32_t en su lugar resolvería este problema antes de que comience, pero sí, el tamaño de una palabra será subóptimo en Uno. ¿Qué pasa con las futuras placas Arduino … qué tamaño de palabra tendrán? 32? 64? 128 !?
  • OK. Entonces, usaría el tamaño de la palabra de máquina (int? WORD parece ser una definición obsoleta de tipo de Windows) si el límite inferior es suficiente, no me importa el tamaño de la memoria y necesito la velocidad, * _t si me importa el tamaño?
  • eliminar eso … gnu.org/software/libc/manual/html_node/Integers.html dice *fast*_t parece ser el camino a seguir …

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *