[SOLUCIONADO] Crear un color con 4 LEDS?

Carmeloco tiene razón. Para que la obseción de tener 16 bits sin no los puedes discernir?

Mas alla de eso, esta es tu solución, en lugar de AnalogWrite usaras esta función nueva previa instalación de la librería.

Complicada la descarga de la misma
Este es el link pero permite que aproveches los timers que SI SON de 16 bits

/*
	By default Arduino's analogWrite (and consequently pwmWrite() since it mimics analogWrite()) uses 8 bit
	pwm across all timers. 8 bit PWM allows for a total of 256 possible values. This library has some methods
	for fine tuning resolution if a higher resolution is needed:
	
	void pwmWriteHR(uint8_t pin, uint16_t duty)
	  Same a pwmWrite, except the range is 0 - 65535 (16 bit) instead
	  of 0 - 255 (8 bit)
	
	float TimerX_GetResolution() (replace X with a timer number)
	  Gets the timer's resolution in base 2. The value returned in other words
	  represents the number of bits required to represent the timer's range. ie
	  the value 7 means it takes 7 bits to represent all possible pin duties at
	  that frequency, or 7-bit resolution. Note that a float is returned, not
	  an int.
	
	float GetPinResolution(uint8_t pin)
	  Returns the same value as TimerX_GetResolution(), but takes a pin number
	  as a parameter so that the caller is timer agnostic.
	
	There are several things to keep in mind when trying to optimize resolution:
	 -pwmWriteHR() is only useful for 16 bit timers, since 8 bit timers are inherently limited to 8 bit pwm
23	 -The higher the frequency, the lower the resolution. pwmWriteHR() will automatically map input to the
	  actual timer resolution
	 -Resolution can be optimized in this way for 2 pins on the Uno (9 and 10), and 11 pins on the Mega (2,
	 3, 5, 6, 7, 8, 11, 12, 44, 45,  and 46)
	 
	Use the serial moniter to see output from this program
	This example runs on mega and uno.
	*/
	
	#include <PWM.h>
	
	//use pin 11 on the mega for this example to work
	int led = 9; // the pin that the LED is attached to
	
	void setup()
	{
	  InitTimersSafe(); //initialize all timers except for 0, to save time keeping functions
	  Serial.begin(115200);
	  Serial.println();
	 
	  demonstrateFrequencysEffectOnResolution();
	  settingHighResolutionDuty();
	}
	
	void demonstrateFrequencysEffectOnResolution()
	{
	  Serial.println("As frequency increases, resolution will decrease...");
	  for(int i = 1; i < 10000; i+=10)
	    {
	      SetPinFrequency(led, i);  //setting the frequency
	     
	      uint16_t frequency = Timer1_GetFrequency();
	      uint16_t decimalResolution = Timer1_GetTop() + 1;
	      uint16_t binaryResolution = GetPinResolution(led); //this number will be inaccurately low because the float is being truncated to a int
	     
	      char strOut[75];
	      sprintf(strOut, "Frequency: %u Hz\r\n Number of Possible Duties: %u\r\n Resolution: %u bit\r\n", frequency, decimalResolution, binaryResolution );
	     
	      Serial.println(strOut);
	    }
	   
	    Serial.println("...Finished");
	}
	
	void settingHighResolutionDuty()
	{
	 SetPinFrequency(led, 10); //setting the frequency to 10 Hz
	 Serial.println("\r\npwmWrite() and pwmWriteHR() are identical except for the valid range of inputs.\r\nThe following loop calls both functions to produce the same result on the \r\nLED pin. The pin should to run 10Hz at 50% duty regardless of the function called.\r\n");
	 
	 //the led should flicker (10Hz 50% duty) for 1 second before calling
	 //the other function. This demonstrates the use of pwmWriteHR() and how its
	 //use is nearly identical to pwmWrite()
	 while(true)
	 {
	   //setting the duty to 50% with 8 bit pwm. 128 is 1/2 of 256
	   pwmWrite(led, 128);
	   Serial.println("8-Bit PWM");
	   delay(1000);
   
	   //setting the duty to 50% with the highest possible resolution that
	   //can be applied to the timer (up to 16 bit). 1/2 of 65536 is 32768.
	   pwmWriteHR(led, 32768);
	   Serial.println("High Resolution PWM");
	   delay(1000);
	 }
	 
	}
	
	void loop()	{
	}

Carmeloco, lo que dices no es exactamente asi, ya que si bien las maquinas que imprimen las fotos, la mayoria lo hace a 8 bits, existen que lo hacen a 16. Ademas en Photoshop se suele usar 16 para editar para evitar el efecto peine que se produce en la aparicion de vacios en el histograma, dado la falta de informacion para modificar. Incluso hay quien trabaja a 32bits para los famosos HDR. Una prueba de esto es facil de encontrar: Para que las camaras de corte profesional incluyen el formato RAW que funciona a 14-16 bits (en vez de los 8 que soporta el jpg) si luego esta informacion no va a ser aprovechada?

http://anibaldesigns.com/2014/05/30/profundidad-de-color-8-bits-y-16-bits-para-que/

Gracias por la nueva informacion Surbyte, la provaré, y como suelen decir "Seguiremos informando"

Es buena info.. me gustó y ya agregue la librería. Nunca se sabe cuando será necesario usar los timers a su máxima expresión.

¡Ejem!

Pues yo estoy más de acuerdo con carmeloco. Que se utilicen más bits de profundidad de color en aplicaciones profesionales no suele ser porque el ojo humano detecte esos niveles, sino porque permite realizar ediciones partiendo de mayor información. Por ejemplo, supongamos una imagen casi toda oscura. Nosotros apenas distinguiremos unas pocas tonalidades, pero si el "ojo digital" es capaz de obtener más diferencias, al darle más brillo nos aparecerán visibles más detalles que estaban ocultos para nuestra capacidad anteriormente. Es similar a tener más resolución de la que el ojo es capaz de detectar... en ese tamaño. Si luego necesitamos ampliar esa imagen o queremos sólo una pequeña parte de la misma, claro que podremos echar de menos los megapíxeles.

En la mayorías de los casos si es detectable ese cambio, el efecto del que hablaba LordLedBurner, se ve a simple vista, se llama "Color Banding" y es muy común en imágenes con 8bpc.

Lo que habría que considerar es que 8bpc para una imagen, no es lo mismo que para un led, a menos que se quiera formar una imagen con estos. Si trabajas los led a 8bpc no creo que tengas problemas notorios.

Usando la función map podrías hacer la conversión de los valores, hacer la prueba de que tanto es el cambio y si te sirve.

Partiendo de que no quiero imponer mi criterio, y menos en un asunto en el que ni tengo conocimientos elevados, pero creo que el banding en imágenes a 8bpc se produce por la compresión (jpg) y no porque falten tonos. De hecho las "sierras" en el histograma corresponden a tonos que a pesar de estar en la paleta no se han usado (la compresión los ha descartado por considerarlos "poco importantes"). Una imagen tomada en formato raw (sin compresión) a 8bpc no debería presentar banding.

Se armó el debate de los colores LED!!!

Jejeje…
En serio que soy muy pacífico, para nada pendenciero :wink:
Pero cuando hay algo en lo que tengo un concepto formado, aunque luego no conozca más allá, como es el caso, antes de cambiar de idea me gusta asegurarme de que cambio de incorrecto a correcto, y no al revés.
También debe ser que con la edad la cabeza tiende a endurecerse :grin: .
De todas formas, he hecho mi aseveración contando con que LordLedBurner pudiera ser fémina, porque si no, no nos engañemos, que nosotros no distinguimos más de siete u ocho colores :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: y cuando oímos verde botella pensamos “¿botella de qué?”

Lo siento Noter, va a ser que soy maromo jajaja Sobre lo de las imagenes no quiero darme el pegote, pero soy fotografo profesional y he estudiado 7 años de fotografia, por lo que puedo hablar con conocimiento de causa.

Otra cosa es la electronica, sobre la que no tengo practicamente ni idea jajajaja por decirlo de alguna manera, programo "de oído", por intuicion y he llegado a hacer unos "mejunjes" que flipariais jajaja

gepd:
En la mayorías de los casos si es detectable ese cambio, el efecto del que hablaba LordLedBurner, se ve a simple vista, se llama “Color Banding” y es muy común en imágenes con 8bpc.

Lo que habría que considerar es que 8bpc para una imagen, no es lo mismo que para un led, a menos que se quiera formar una imagen con estos. Si trabajas los led a 8bpc no creo que tengas problemas notorios.

Usando la función map podrías hacer la conversión de los valores, hacer la prueba de que tanto es el cambio y si te sirve.

Gped, la funcion map no descartaria valores para convertirlos en 8 bits? Quiero decir que si hago eso, no seria como trabajar directamente con 8 bits, solo que pasando por un calculo a 16 para luego encontrarle un valor correspondiente? No se si explicarme.

Podrias ponerme un ejemplo de como seria la instruccion enviando a un pin, algun color con resolucion de 16 bits para poder entenderlo?

Si no es mucho preguntar, ¿cual va a ser la utilidad final de esto?

carmeloco:
Si no es mucho preguntar, ¿cual va a ser la utilidad final de esto?

Pues controlar 4 LEDs (RGB y W) via bluetooth de forma que le pueda enviar un color determinado de 16 bits, y que el Arduino envie el valor necesario a cada PIN para que los cuatro juntos representen el mencionado color.

Alguien podria decirme si con map puedo enviar el valor del color en 16 bits y si es asi, ponerme un pequeño ejemplo?

Con map, puedes enviar el valor del color en 16 bits, pero map lo convertirá a 8 bits. Suponiendo que el nombre de la variable es "color", y la variable "mapeada" es "colormap", un ejemplo sería el siguiente:

colormap = map (color, 0, 65535, 0, 255);

Ten en cuenta que las variables dos variables tienes que declararlas como "unsigned int"

Y que quisieras que haga un map modificado porque yo he hecho un mapf para float por ejemplo.

surbyte: Y que quisieras que haga un map modificado porque yo he hecho un mapf para float por ejemplo.

No entendí lo que quieres decir. Puedes explicarme?

carmeloco: Con map, puedes enviar el valor del color en 16 bits, pero map lo convertirá a 8 bits. Suponiendo que el nombre de la variable es "color", y la variable "mapeada" es "colormap", un ejemplo sería el siguiente:

colormap = map (color, 0, 65535, 0, 255);

Ten en cuenta que las variables dos variables tienes que declararlas como "unsigned int"

Pero carmeloco, si me convierte a 8 bits no me sirve, yo quiero mandar los 16 completos, no reconvertirlos. Si lo hiciera asi, seria inutil todo el trabajo de los timers para calcular a 16 bits si luego descarto informacion, no? Si escribiera directamente el valor en 16 despues del nombre del pin (por ejemplo red =) no funcionaria?

Tú has preguntado por un map, y un map hace eso...

A ver. Creo que nos hemos ido del asunto con la discusión de color banding y demás. Creo que ahora la cuestión está en cómo enviar por BT la secuencia RGBW para que Arduino la pueda leer, ¿No? Pues la puedes enviar como te dé la gana. Dependiendo de cómo la envíes la tendrás que desentramar en el arduino. Por ejemplo podrías enviar como decías anteriormente (b=valor), valores separados por comas, o incluso datos en binario. ¿Cómo te gustaría enviarlos?

Pues la verdad, de la forma mas sencilla posible, para evitar posibles errores/fallos. De ser posible lo mejor seria que pudiera enviar un unico valor de color y el arduino “lo reparta entre los pines”, pero si hay que enviar los valores por separado tambien me vale.

Si no me equivoco, el codigo de este post hasta el momento es correcto y solo le falta “activar” los timers a 16 y lo que hablamos ahora de como “repartir la informacion”. Los pins estan bien definidos y el bluetooth activado para la recepcion de los valores. Me dejo algo?

A esto me referia, un map que satisface con creces los 16bits

long map(long x, long in_min, long in_max, long out_min, long out_max) { return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min; }