WOW, no sabía que los routers tambien tienen gpios!!! 
ahora mismo ando chanchulleando con Arduino y estaba pensando en juntar arduino con routers openwrt para meterle al arduino una especie de "ethernet" (por ahorrar los 3 cochinos euros que cuestan los modulos ethernet, sí :V) pero viendo que con WRT puedo hacer casi lo mismo.. tendre que probar!
Eso si, para algunos proyectos no creo que me pueda servir... imagino que los gpio solo leen y sacan niveles bajos y altos, tengo algunos proyectos que leen valores analogicos.

Un coversor de analógico a I2C, y ¡¡¡lo tienes hecho!!! 
Aunque si tienes un arduino, puede utilizar el firmata con openwrt, o comunicarlo por el puerto serie del router, y utilizar ser2net para acceder a los datos del puerto serie a través de TCP. O utilizar un adaptador USB/serie en el router y comunicarlo con el arduino.
Opciones hay...

Cita de: Tki2000 en 27-05-2016, 08:09 (Viernes)

Cita de: noentiendero en 27-05-2016, 00:29 (Viernes)

WOW, no sabía que los routers tambien tienen gpios!!! 
ahora mismo ando chanchulleando con Arduino y estaba pensando en juntar arduino con routers openwrt para meterle al arduino una especie de "ethernet" (por ahorrar los 3 cochinos euros que cuestan los modulos ethernet, sí :V) pero viendo que con WRT puedo hacer casi lo mismo.. tendre que probar!
Eso si, para algunos proyectos no creo que me pueda servir... imagino que los gpio solo leen y sacan niveles bajos y altos, tengo algunos proyectos que leen valores analogicos.

Un coversor de analógico a I2C, y ¡¡¡lo tienes hecho!!! 
Aunque si tienes un arduino, puede utilizar el firmata con openwrt, o comunicarlo por el puerto serie del router, y utilizar ser2net para acceder a los datos del puerto serie a través de TCP. O utilizar un adaptador USB/serie en el router y comunicarlo con el arduino.
Opciones hay...

Sí, estuve buscando sobre eso, librerías para Arduino que le permite tener su propia IP y servidor http y tal. Sobre los sensores, tambien hay "empaquetados" sensores que sacan datos digitales. Por ejemplo, el DHT11 que mide temperatura y humedad y voy a usar en un proyecto, un sistema deshumificador para una bodega (le conectaré un ventilador-extractor y un deshumificador mediante relés). La cosa son las librerías de Arduino (como la del DHT11) que no sé si se podría usar en el WRT.

Pues si que están disponibles en los repositorios openwrt para compilar las librerias DHT11

Buenas, para mi proyecto y en general, veo que los GPIO's y/o al menos el GPIO 25 del HG556a Ver.C, cuando se enciende el router es nivel alto = 1 = 3,3 v. Esto supone una problemática, ya q acaba de ocurrir un cambio de estado en el/los GPIO's de 0 = 0,00 v (router apagado) a 1 = 3,3 v por sólo encenderlo. Si lo mantenemos encendido siempre y luego realizamos la configuración de lo que vayamos a hacer pues no hay problema, pero no es mi caso. En mi proyecto yo parto de: 1º router apagado, 2º lo enciendo, 3º graba vídeo de 30 sg y 4º luego activa relé (N.C) = 1   --> a (N.O) = 0 para producir un reset en el watímetro que controlo diariamente. De esta forma cada día sobre las 22:00 horas se graba un vídeo de 30sg con los valores del watímetro y le hace un reset al watímetro para el día siguiente.

¿Qué habría que hacer para poner ciertos GPIO's (los que vayamos a usar) a nivel 0 y que no cambién ni por una milésima su estado al encender el router? Vaya, como si tuviera un/os GPIO's con un 0 tanto apagado como encendido.

¿Modificando el kernel se consigue esto o siempre vamos a tener x un instante un cambio de estado?

Y en el peor de los casos..., ni aun modificando el kernel sucede esto: ¿el procesador del router exará un 1 por todos sus GPIO's al encenderse y según reciba la instrucción "del kernel" lo pasará a 0?


¿Alguien sabe algo sobre este asunto de que no exista cambio de estado de alguna forma, del router apagado al router encendido?

Saludos y muchas gracias.

Cita de: edudi en 02-07-2016, 18:42 (Sábado)

Buenas, para mi proyecto y en general, veo que los GPIO's y/o al menos el GPIO 25 del HG556a Ver.C, cuando se enciende el router es nivel alto = 1 = 3,3 v. Esto supone una problemática, ya q acaba de ocurrir un cambio de estado en el/los GPIO's de 0 = 0,00 v (router apagado) a 1 = 3,3 v por sólo encenderlo. Si lo mantenemos encendido siempre y luego realizamos la configuración de lo que vayamos a hacer pues no hay problema, pero no es mi caso. En mi proyecto yo parto de: 1º router apagado, 2º lo enciendo, 3º graba vídeo de 30 sg y 4º luego activa relé (N.C) = 1   --> a (N.O) = 0 para producir un reset en el watímetro que controlo diariamente. De esta forma cada día sobre las 22:00 horas se graba un vídeo de 30sg con los valores del watímetro y le hace un reset al watímetro para el día siguiente.

¿Qué habría que hacer para poner ciertos GPIO's (los que vayamos a usar) a nivel 0 y que no cambién ni por una milésima su estado al encender el router? Vaya, como si tuviera un/os GPIO's con un 0 tanto apagado como encendido.

¿Modificando el kernel se consigue esto o siempre vamos a tener x un instante un cambio de estado?

Y en el peor de los casos..., ni aun modificando el kernel sucede esto: ¿el procesador del router exará un 1 por todos sus GPIO's al encenderse y según reciba la instrucción "del kernel" lo pasará a 0?


¿Alguien sabe algo sobre este asunto de que no exista cambio de estado de alguna forma, del router apagado al router encendido?

Saludos y muchas gracias.

Puedes buscar un relé con lógica inversa, o invertir la señal con una puerta lógica (por ejemplo una 74LVT04), o un transistor (por ej.: http://electronics.stackexchange.com/questions/30238/how-to-invert-a-digital-signal). De esa forma trabajarías con 0 para activar y con 1 para desactivar el relé. Sólo tendrías que invertir la señal del GPIO en tu aplicación.
La lógica inversa se suele utilizar bastante en entornos industriales, ya que se sabe si una señal está funcionando o no por falta de alimentación (si no hay alimentación no valdría 1), o por no dar bien la señal (en cuyo caso nunca se pondría a 0).

Ok, muchas gracias por la respuesta, la famosa puerta NOT.......de ahí que se pasen los circuitos a puertas lógicas inversas: NAND, NOR, etc... no hubiera caído de que se usa en entornos industriales de esa forma por ese motivo, aparte de que se simplifican a únicamente un tipo de puerta lógica.


AÑADO: Tengo la placa de relé delante ahora mismo, lo que esta es de 8 relés.
 

Thks, ya estoy trabajando en ello. Un saludo

Cita de: Tki2000 en 02-07-2016, 19:09 (Sábado)

Cita de: edudi en 02-07-2016, 18:42 (Sábado)

Buenas, para mi proyecto y en general, veo que los GPIO's y/o al menos el GPIO 25 del HG556a Ver.C, cuando se enciende el router es nivel alto = 1 = 3,3 v. Esto supone una problemática, ya q acaba de ocurrir un cambio de estado en el/los GPIO's de 0 = 0,00 v (router apagado) a 1 = 3,3 v por sólo encenderlo. Si lo mantenemos encendido siempre y luego realizamos la configuración de lo que vayamos a hacer pues no hay problema, pero no es mi caso. En mi proyecto yo parto de: 1º router apagado, 2º lo enciendo, 3º graba vídeo de 30 sg y 4º luego activa relé (N.C) = 1   --> a (N.O) = 0 para producir un reset en el watímetro que controlo diariamente. De esta forma cada día sobre las 22:00 horas se graba un vídeo de 30sg con los valores del watímetro y le hace un reset al watímetro para el día siguiente.

¿Qué habría que hacer para poner ciertos GPIO's (los que vayamos a usar) a nivel 0 y que no cambién ni por una milésima su estado al encender el router? Vaya, como si tuviera un/os GPIO's con un 0 tanto apagado como encendido.

¿Modificando el kernel se consigue esto o siempre vamos a tener x un instante un cambio de estado?

Y en el peor de los casos..., ni aun modificando el kernel sucede esto: ¿el procesador del router exará un 1 por todos sus GPIO's al encenderse y según reciba la instrucción "del kernel" lo pasará a 0?


¿Alguien sabe algo sobre este asunto de que no exista cambio de estado de alguna forma, del router apagado al router encendido?

Saludos y muchas gracias.

Puedes buscar un relé con lógica inversa, o invertir la señal con una puerta lógica (por ejemplo una 74LVT04), o un transistor (por ej.: http://electronics.stackexchange.com/questions/30238/how-to-invert-a-digital-signal). De esa forma trabajarías con 0 para activar y con 1 para desactivar el relé. Sólo tendrías que invertir la señal del GPIO en tu aplicación.
La lógica inversa se suele utilizar bastante en entornos industriales, ya que se sabe si una señal está funcionando o no por falta de alimentación (si no hay alimentación no valdría 1), o por no dar bien la señal (en cuyo caso nunca se pondría a 0).

Ok, muchas gracias por la respuesta, la famosa puerta NOT.......de ahí que se pasen los circuitos a puertas lógicas inversas: NAND, NOR, etc... no hubiera caído de que se usa en entornos industriales de esa forma por ese motivo, aparte de que se simplifican a únicamente un tipo de puerta lógica.


AÑADO: Tengo la placa de relé delante ahora mismo, lo que esta es de 8 relés.
 

Thks, ya estoy trabajando en ello. Un saludo

Correcto compañero, gracias a tu aporte solventado el problema ante la duda que planteé. Si no llego haber posteado y hubiera probado primero el resultado hubierda sido el mismo positivo, pero vino bien plantear la duda y que respondieras con esa "lógica" aplastante.


Si quiero aprovechar para matizar varias cosas:

1º La placa de relés y el circuito intermedio que usé es el mismo del esquema de la Raspberry que hay en el 1º mensaje (usando de momento 1 relé "IN1": resistencia de 10K entre tierra y el GPIO, resistencia de 2,2K entre el GPIO y el cable que va al "IN1" de la placa de relés).

2º He usado la configuración del relé N.C. (normalmente cerrado = terminales B y C) y con el router apagado están con continuidad --> como si fuera un 1 (aunque no lógico sino que el relé no se activado por lo que no se ha movido a la otra posición = N.O. "normalmente abierto-open").

- Router apagado   --> B y C con continuidad = 1 (no lógico)  ---> Led del relé IN1 apagado

- Router encendido --> B y C con continuidad = 1 (no lógico)  ---> Led del relé IN1 con la luz roja muy tenue.


Según voy configurando el GPIO hay un cambio de estado y la luz roja se vuelve de roja muy tenue, intensa a apagada:

echo 25 > /sys/class/gpio/export                       <---- No hay cambio de estado = B y C con continuidad = 1 (no lógico) = Led muy tenue

echo "out" > /sys/class/gpio/gpio25/direction    <---- Cambio de estado = B y C sin continuidad = 0 (no lógico) = RESET = Led intenso

echo 1 > /sys/class/gpio/gpio25/value               <---- Cambio de estado = B y C con continuidad = 1 (no lógico) = Led apagado

echo 0 > /sys/class/gpio/gpio25/value               <---- Cambio de estado = B y C sin continuidad = 0 (no lógico) = RESET = Led intenso

echo 1 > /sys/class/gpio/gpio25/value               <---- Cambio de estado = B y C con continuidad = 1 (no lógico) = Led apagado



Por tanto, ya queda resuelto el camino para mi proyecto y de guía como conocimiento general los estados que va mostrando la placa de relés, que por cierto, tiene todas las protecciones incluidas, los optoacopladores y los diodos para prevenir el pico inverso de los relés al desactivarse.

Gracias por la ayuda como siempre. Igual subo un vídeo de esto mismo, aunque creo que no es necesario.


AÑADO: Que bueno tu aporte, se sale, encima configurable cada uno de los 8 relés por separado para hacerlo de lógica normal o inversa, muy bueno:

Pues una de éstas con optoacoplador y configurable con lógica normal e inversa: http://www.ebay.de/itm/5V-8-Channel-Relay-Module-With-OPTO-Isolated-High-and-Low-Level-Trigger-/201053180872?

Saludos

Si el led del relé se te queda tenue, significa que está en un punto flotante, ni vale 3,3v ni vale 0v. Haría falta ponerle una resistencia pulldown si la lógica es normal, o una resistencia pullup, si la lógica es inversa. Según veo dices que tienes una resistencia pulldown de 10k entre el gpio y tierra. Me parece que ofrece demasiada resistencia para dejar pasar corriente a tierra, y por eso circula algo de corriente hacia el led del relé (se ve tenue). Prueba a bajar el valor de esa resistencia, si no es un valor crítico para el diseño.

Hola Tki2000, según entiendo de @edudi, una vez que termina el arranque, y que exporta el GPIO estableciendo el valor a 1, ya el Led queda encendido con normalidad y doy por echo que el relé le trabaje correctamente.
¿Esto es así?

En mis pruebas con el HG556a  Ver C (ralink) habían 2 GPIO's  que al arrancar el router se quedaban así en un punto flotante, pero ya una vez rodado el script para cotrolar los GPIO's estos primero a 0 y luego a 1 ya encendían el led con normalidad... pero aún así,  cuando estaban a medias, también eran capaces de activar el relé (supongo que era debido a la sensibilidad del optoacoplador)

Cita de: Tki2000 en 03-07-2016, 15:52 (Domingo)

Si el led del relé se te queda tenue, significa que está en un punto flotante, ni vale 3,3v ni vale 0v. Haría falta ponerle una resistencia pulldown si la lógica es normal, o una resistencia pullup, si la lógica es inversa. Según veo dices que tienes una resistencia pulldown de 10k entre el gpio y tierra. Me parece que ofrece demasiada resistencia para dejar pasar corriente a tierra, y por eso circula algo de corriente hacia el led del relé (se ve tenue). Prueba a bajar el valor de esa resistencia, si no es un valor crítico para el diseño.

En estos días compruebo con un potenciómetro y una resistencia con menores valores (4,8K x ej) y comento si hay cambios.

Del circuito que comenté, acabo de hacer un puente para hacer unas mediciones de voltaje justo antes de la entrada IN1 en la placa de relés, estos son los valores:

Router Apagado                                               = 0,00v
Router Encendido                                             = 0,29v
echo 25 > /sys/class/gpio/export                        = 0,29v
echo "out" > /sys/class/gpio/gpio25/direction        = 1,47v      ---> Si levanto el cable del IN1 el voltaje cae a 0,00v
echo 1 > /sys/class/gpio/gpio25/value                 = 0,00v      ---> Si levanto el cable del IN1 el voltaje permanece en 0,00v
echo 0 > /sys/class/gpio/gpio25/value                 = 1,47v
echo 1 > /sys/class/gpio/gpio25/value                 = 0,00v


Todo esto a modo de testeo de voltaje para sacar conclusiones, lo que con la hora que es no estoy para sacarlas. Desde que pruebe con otros valores de resistencia comento si es que saco conclusiones, que esa es otra. Porque lo de que se caiga el voltaje si levanto el cable del IN1 a 0,00v me acaba de descuadrar.....como digo, no son horas.

Cita de: Ficht en 03-07-2016, 17:32 (Domingo)

En mis pruebas con el HG556a  Ver C (ralink) habían 2 GPIO's  que al arrancar el router se quedaban así en un punto flotante, pero ya una vez rodado el script para cotrolar los GPIO's estos primero a 0 y luego a 1 ya encendían el led con normalidad... pero aún así,  cuando estaban a medias, también eran capaces de activar el relé (supongo que era debido a la sensibilidad del optoacoplador)

Me imagino que en tu caso si el relé se te activaba estando en un punto flotante, sería porque el voltaje a la entrada del INx sería bastante más alto que en mi caso de 0,29v (los diodos tienen una caída de tensión de 0,7v, imagino que si tu voltaje flotante era superior a 0,7v le llegase algo de voltaje al optoacoplador que también tiene su diodo interno con la misma caída de tensión, pero como dices por la sensibilidad, al igual no necesitaría el total de los 0,7v para que se activara el relé, cosa que como dices si hace)

En breve posteo resultados con otros valores de resistencia. Interesante esto del voltaje flotante...


Saludos y gracias, ....lo que es unir conocimientos y datos....

Seguramente el pin será de tipo sink, no de tipo driver. Un pin driver hace que la corriente circule "hacia fuera", desde el VCC del router, hasta la tierra de la carga puesta. La intensidad que puede manejar es relativamente baja. Un pin del tipo sink, deja pasar la corriente "hacia dentro", desde el VCC que haya conectado al pin, hasta la tierra del router. La intensidad que puede manejar es mayor. Por eso al quitar el voltage a la "salida" del pin, deja de fluir a tierra, y la tensión cae a 0. La corriente fluye hacia dentro, no hacia fuera del pin.
Generalmente solemos asociar el voltaje del pin, a que éste "sale" del pin, pero en realidad un voltaje es una diferencia de potencial a tierra, que puede ser provocado por un sentido contrario de corriente.

Es una forma un poco borrica de explicarlo, pero creo que se entiende.

Buenas, como buena noticia referente a un GPIO que su estado inicial con el router apagado sea 0 (no lógico) en el HG556a Atheros tenemos el GPIO 4, una vez se enciende pasa de 0 (no lógico) a 0,28v lo cual es insuficiente para accionar ningún led y espero que ningún optoacoplador.




Aquí detallo los voltajes de cada GPIO en cada uno de sus estados --> 1º desde apagado a encendido el router, 2º una vez exportardo, 3º asignada la dirección como salida, 4º enviando un 1 y 5º enviando un 0:

======
GPIO 4: --> Router de OFF a ON  --> 0,28 v
======

echo 4 > /sys/class/gpio/export                    --> 0,28 v
echo "out" > /sys/class/gpio/gpio4/direction   --> 0,00 v
echo 1 > /sys/class/gpio/gpio4/value             --> 3,29 v
echo 0 > /sys/class/gpio/gpio4/value             --> 0,00 v


=====
GPIO 5: --> Router de OFF a ON  -->  1,00 v al iniciar luego oscila entre 0,79 v y 0,62 v
=====

echo 5 > /sys/class/gpio/export                    --> sigue oscilando entre 0,79 v y 0,62 v
echo "out" > /sys/class/gpio/gpio5/direction   --> 0,00 v
echo 1 > /sys/class/gpio/gpio5/value             --> 3,30 v
echo 0 > /sys/class/gpio/gpio5/value             --> 0,00 v


======
GPIO 24: --> Router de OFF a ON  --> 3,31 v
======

echo 24 > /sys/class/gpio/export                    --> 3,31 v
echo "out" > /sys/class/gpio/gpio24/direction   --> 0,00 v
echo 1 > /sys/class/gpio/gpio24/value             --> 3,31 v
echo 0 > /sys/class/gpio/gpio24/value             --> 0,00 v


======
GPIO 25: --> Router de OFF a ON  --> 3,27 v
======

echo 25 > /sys/class/gpio/export                    --> 3,27 v   
echo "out" > /sys/class/gpio/gpio25/direction   --> 0,00 v
echo 1 > /sys/class/gpio/gpio25/value             --> 3,31 v
echo 0 > /sys/class/gpio/gpio25/value             --> 0,00 v


======
GPIO 29: --> Router de OFF a ON  --> 3,30 v
======

echo 29 > /sys/class/gpio/export                    --> 3,30 v
echo "out" > /sys/class/gpio/gpio29/direction   --> 0,02 v
echo 1 > /sys/class/gpio/gpio29/value             --> 3,31 v
echo 0 > /sys/class/gpio/gpio29/value             --> 0,02 v


======
GPIO 32: --> Router de OFF a ON  --> 3,27 v
======

echo 32 > /sys/class/gpio/export                    --> 3,27 v
echo "out" > /sys/class/gpio/gpio32/direction   --> 0,00 v
echo 1 > /sys/class/gpio/gpio32/value             --> 3,31 v
echo 0 > /sys/class/gpio/gpio32/value             --> 0,00 v


======
GPIO 14: --> Router de OFF a ON --> Relé en posición (N.O.) --> 1º Continuidad y al encender es N.O.
======

echo 14 > /sys/class/gpio/export                    --> N.O.
echo "out" > /sys/class/gpio/gpio14/direction   --> Continuidad
echo 1 > /sys/class/gpio/gpio14/value             --> N.O.
echo 0 > /sys/class/gpio/gpio14/value             --> Continuidad


======
GPIO 14: --> Router de OFF a ON --> Relé en posición (N.C.) --> 1º Sin continuidad y al encender es N.C.
======

echo 14 > /sys/class/gpio/export                    --> N.C.
echo "out" > /sys/class/gpio/gpio14/direction   --> Sin continuidad
echo 1 > /sys/class/gpio/gpio14/value             --> N.C.
echo 0 > /sys/class/gpio/gpio14/value             --> Sin continuidad



Por otra parte, he estado localizando (de muy fácil averiguación) en PCB los puntos donde soldar en la zona de los LEDs (DSL, HSPA y MESSAGE que están sin uso al menos en la 14.07 RC3 "parte frontal del router") con lo que sumaríamos 3 GPIOs más, con el añadido de que tienen el LED que nos sirve de chivato de estado del GPIO correspondiente. También he localizado (algo más lioso para soldar la verdad pero posible) los 4 leds bicolor de los puertos LAN "obviamente en la parte trasera del router" (sumarían otros 8 GPIOs más, con un total solamente en LEDs de 11 GPIOs). Si le sumamos los 7 GPIOs que están "libres" o que podemos reutilizar hacen un total de 18 GPIOs (11 de ellos con leds de estado), que no es poco.

En estos días subo unas fotos de los puntos en placa de los 8 GPIOs de los leds bicolor LANS (rojos y verdes).


Para poder usar los LEDs como GPIOs de forma sencilla como detalló danitool en el 2º mensaje de este hilo. No hace falta ni abrir el router para probarlos, ponemos estos comandos y listo:

===========
LEDs a controlar:
===========

HW556:red:message

HW556:red:hspa

HW556:red:dsl

HW556:red:lan1
HW556:red:lan2
HW556:red:lan3
HW556:red:lan4

HW556:green:lan1
HW556:green:lan2
HW556:green:lan3
HW556:green:lan4


=============
1º izq --> message:
=============

echo 1 > /sys/class/leds/HW556:red:message/brightness
echo 0 > /sys/class/leds/HW556:red:message/brightness


==========
2º izq --> hspa:
==========

echo 1 > /sys/class/leds/HW556:red:hspa/brightness
echo 0 > /sys/class/leds/HW556:red:hspa/brightness


============
2º derecha --> dsl:
============

echo 1 > /sys/class/leds/HW556:red:dsl/brightness
echo 0 > /sys/class/leds/HW556:red:dsl/brightness


=====================
LAN1 (1º en rojo y 2º en verde):
=====================

echo 1 > /sys/class/leds/HW556:red:lan1/brightness
echo 0 > /sys/class/leds/HW556:red:lan1/brightness

echo 1 > /sys/class/leds/HW556:green:lan1/brightness
echo 0 > /sys/class/leds/HW556:green:lan1/brightness


Resto de LANs para activar: con sustituir lan1 por el lanX que se desee.



Bueno, hasta aquí todo por esta noche...no se como me lo monto pero casi siempre escribo en la nocturnidad.


PD1: Creía haber localizado en placa el GPIO 14 desde su raiz de 3,3v, pero me confundí donde lo hallé el punto es a 5v, de todas formas puede servirnos de igual modo si le ponemos un simple divisor de tensión de 5v a 3,3v.

PD2: Ya tengo suficientes GPIOs para controlar motores paso a paso (para los bipolares hacen falta 4, para los unipolares 5 ó 6), no tengo en mente ningún proyecto con ellos, pero si que quiero hacerlo funcionar con el router en vez de con un PIC, Arduino, Raspberry, etc...  ya pedí el driver para el motor en nuestro maravilloso Ebay por un simple €, y como no podía ser de otra forma, si vale a €, envíame 2 que nunca se sabe:

http://www.ebay.es/itm/272272743977?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Buenas a todos, he estado dándole vueltas al uso de los motores paso a paso con los GPIOs en OPENWRT, pero tenía la problemática de que aun faltan 3 semanas para que me llegue el driver (1€),...así que me acordé de los LEDs LAN que son 4, y de que el motor bipolar que voy a usar tb es de 4 pines, así que me lancé a hacer el código con los 4 LEDs LAN simulando los 4 GPIOs que usaré para el motor paso a paso bipolar (GPIO nº 24, 25, 29 y 32).

De esta página cogí los datos para poder controlar un motor paso a paso, es interesante la verdad y lo explican muy bien, con tablas de la verdad, esquemas, diagramas de conexión, etc:

http://diymakers.es/mover-motores-paso-paso-con-arduino/


Cualquiera que tenga un router OpenWRT (esto ha sido probado en un HG556a Atheros 14.07 RC3) puede probar y ver como se mueven las luces LAN hacia la derecha (simulando la secuencia de un motor paso a paso en modo --> Medio paso: Se activan primero dos bobinas y después solo una y así sucesivamente. Esto provoca que el motor avance la mitad del paso real.  Esto se traduce en un giro más suave y preciso.)

root@OpenWrt:/Edu_Pruebas# sh ./1_pasos_lan_der.sh 4 8000
Vuelta Nº 4
Vuelta Nº 3
Vuelta Nº 2
Vuelta Nº 1
root@OpenWrt:/Edu_Pruebas#

Vídeo               -=  Pincha Aquí para verlo  =-   

1_pasos_lan_der.sh ---> LINK: https://www.dropbox.com/s/k7ntvtauo3jf9u7/1_pasos_lan_der.sh?dl=0

La forma de usarlo es super sencilla: script 1º argumento =  número de vueltas completas y 2º argumento = velocidad del giro.

1_pasos_lan_der.sh 5 8000

Código: [Seleccionar]

#!/bin/bash

# 1_pasos_lan_der.sh   (versión 0.1 beta)   

# Gracias a la web de OPENWRT apartado GPIO y para conocimientos básicos en bash de la web:
# http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-7.html



# Realiza un nº de vueltas "expresión 1ª" (1 vuelta = 8 pasos) siendo el paso a una velocidad "expresión 2ª" (8000 = 0,58 sg)

# FUNCIÓN: Simulación con los LEDs LAN del control de un motor paso a paso bipolar girando hacia la derecha.

# root@OpenWrt:/Edu_Pruebas# time nice -n 5 seq 500 >/dev/null
# real    0m 0.05s
# user    0m 0.02s
# sys     0m 0.02s


show_usage()
{
    printf "\n1_pasos_lan_der.sh <nº de vueltas> <velocidad del giro>\n"
    printf "\nEj: 1_pasos_lan_der.sh 5 8000    <-- 5 vueltas completas a una velocidad de 8000 = 0,58 sg por paso del motor\n"
    printf "\n\n-= IMP =- Para saber cuantos segundos son X's ciclos de reloj del micro la línea de comandos es:\n"
    printf "\ntime nice -n 5 seq 8000 >/dev/null  \n"
    printf "\nroot@OpenWrt:/Edu_Pruebas# time nice -n 5 seq 8000 >/dev/null"
    printf "\nreal    0m 0.58s"
    printf "\nuser    0m 0.54s"
    printf "\nsys     0m 0.02s\n"

}

if [ \( $# -eq 0 \) -o \( $# -gt 3 \) ] ; then
    show_usage
    printf "\n\nERROR: Falta poner el nº de "vueltas" y la "velocidad" por paso del motor\n\n"
    exit 255
fi


LAN1="/sys/class/leds/HW556:red:lan1/brightness"
LAN2="/sys/class/leds/HW556:red:lan2/brightness"
LAN3="/sys/class/leds/HW556:red:lan3/brightness"
LAN4="/sys/class/leds/HW556:red:lan4/brightness"
VUELTAS=`expr $1`
TIME=`expr $2`
COUNTER=$VUELTAS


echo 0 > $LAN1 ; echo 0 > $LAN2 ; echo 0 > $LAN3 ; echo 0 > $LAN4

sleep 1

until [  $COUNTER -lt 1 ]; do

#LAN1 y LAN2

echo 1 > $LAN1
nice -n 5 seq $TIME >/dev/null
echo 1 > $LAN2
nice -n 5 seq $TIME >/dev/null
echo 0 > $LAN1


#LAN2 y LAN3

echo 1 > $LAN2
nice -n 5 seq $TIME >/dev/null
echo 1 > $LAN3
nice -n 5 seq $TIME >/dev/null
echo 0 > $LAN2


#LAN3 y LAN4

echo 1 > $LAN3
nice -n 5 seq $TIME >/dev/null
echo 1 > $LAN4
nice -n 5 seq $TIME >/dev/null
echo 0 > $LAN3


#LAN4 y LAN1

echo 1 > $LAN4
nice -n 5 seq $TIME >/dev/null
echo 1 > $LAN1
nice -n 5 seq $TIME >/dev/null
echo 0 > $LAN4

echo Vuelta Nº $COUNTER
             
let COUNTER-=1

done


Cuando tenga el driver o lo tengan si algunos quieren realizar sus pruebas y códigos, sólo hay que sustituir LAN1, 2, 3 y 4 por el GPIO que se vaya a usar en su lugar.


Y como frikada, me hizo gracia replicar las luces del coche fantástico usando los LEDs LAN, este es el código y el argumento para pasarle, para que la velocidad de los LEDs sean lo más parecido a los del cerebro de Kitt, .....chiquita frikada, pero me partí cuando salió.

Vídeo               -=  Pincha Aquí para verlo  =-   

   

(TinyPic ha girado el vídeo, no sé el motivo, trataré de solucionarlo)

10leds_lan_KiTT.sh  ---> LINK: https://www.dropbox.com/s/4txt5di1m0sgsif/10leds_lan_KiTT.sh?dl=0

La forma de usarlo es super sencilla: script 1º argumento = velocidad de las luces

sh ./10leds_lan_KiTT.sh 2000

Código: [Seleccionar]

#!/bin/bash

# Imitación de las luces del coche fantástico (frikada .com por mi parte, pero se caía de maduro hacerlo)

# FUNCIÓN: Simulación con LEDs del cerebro del Kitt = el coche fantástico

show_usage()
{
    printf "\n10leds_lan_KiTT.sh <nº en ciclos para convertir a sg>\n"
    printf "\nEj: 10leds_lan_KiTT.sh 8000    <-- 8000 = 0,58 sg entre cada paso del motor\n"
    printf "\n\n-= IMP =- Para saber cuantos segundos son X's ciclos la línea de comandos es:\n"
    printf "\ntime nice -n 5 seq 8000 >/dev/null  \n"
    printf "\nroot@OpenWrt:/Edu_Pruebas# time nice -n 5 seq 8000 >/dev/null"
    printf "\nreal    0m 0.58s"
    printf "\nuser    0m 0.54s"
    printf "\nsys     0m 0.02s\n"

}

if [ \( $# -eq 0 \) -o \( $# -gt 3 \) ] ; then
    show_usage
    printf "\n\nERROR: Falta poner el nº ciclos como temporizador entre pasos del motor\n\n"
    exit 255
fi


LAN1="/sys/class/leds/HW556:red:lan1/brightness"
LAN2="/sys/class/leds/HW556:red:lan2/brightness"
LAN3="/sys/class/leds/HW556:red:lan3/brightness"
LAN4="/sys/class/leds/HW556:red:lan4/brightness"
TIME=`expr $1`


echo 0 > $LAN1 ; echo 0 > $LAN2 ; echo 0 > $LAN3 ; echo 0 > $LAN4

sleep 1

while true; do

#LAN1 y LAN2

echo 1 > $LAN1
nice -n 5 seq $TIME >/dev/null
echo 1 > $LAN2
nice -n 5 seq $TIME >/dev/null
echo 0 > $LAN1


#LAN2 y LAN3

echo 1 > $LAN2
nice -n 5 seq $TIME >/dev/null
echo 1 > $LAN3
nice -n 5 seq $TIME >/dev/null
echo 0 > $LAN2


#LAN3 y LAN4, y marcha atrás

echo 1 > $LAN3
nice -n 5 seq $TIME >/dev/null
echo 1 > $LAN4
nice -n 5 seq $TIME >/dev/null
echo 0 > $LAN3
nice -n 5 seq $TIME >/dev/null
echo 1 > $LAN3
nice -n 5 seq $TIME >/dev/null
echo 0 > $LAN4
nice -n 5 seq $TIME >/dev/null


#LAN3 y LAN2

echo 1 > $LAN2
nice -n 5 seq $TIME >/dev/null
echo 0 > $LAN3


#LAN2 y LAN1

echo 1 > $LAN2
nice -n 5 seq $TIME >/dev/null
echo 1 > $LAN1
nice -n 5 seq $TIME >/dev/null
echo 0 > $LAN2


done


A ver si cuando me llegue el driver, le pongo un bolígrafo al rail del motor paso a paso de alguna forma para ver como va desplazándolo y este dibujando una línea, de esta forma y movimiendo el folio hacia arriba se podrá ver la precisión de una línea con respecto a la anterior. Tendré que realizar el mismo script pero haciendo el giro a la izquierda, ya que este es a la derecha o, si me pongo en modo frikistyler hago uno que se le pueda pasar por argumento la dirección (derecha o izquierda), vueltas (nº de vueltas) y velocidad (velocidad del giro entre pasos)...que sería lo adecuado para ir progresando con el script.


IMP --> ¿A alguien se le ocurre como hacer un retardo menor de 1sg que es el menor que permite el "sleep", traté de instalar el "coreutils-sleep" pero me dió varios fallos al igual que el "luasocket" tal como comentan en esta web:

http://ediy.com.my/tutorials/item/41-lua-sleep-function-in-milliseconds

Lo digo más bien, porque buscando como hacer retardos inferiores a 1 sg, encontré lo que uso: nice -n 5 seq 8000 >/dev/null
y sinceramente, no tengo ni idea (aunque tp me he puesto a buscar) de que hace el nice y que hace al redireccionar a /dev/null, porque la función del retardo se consigue, pero ni idea si puede afectar a algo o no ser preciso. En alguna ocasión me pareció que se trabó un poco y luego siguió, no sé si fue porque está haciendo algo más allá de lo correcto y está metiendo en bucles raros al router.


Saludos a todos.

nice es la función para dar más o menos prioridad a un proceso : http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/?utm_source=tuicool
seq es simplemente un contador de secuencia, en tu caso 8000 : http://scienceblogs.com/gregladen/2009/09/19/fun-with-the-linux-seq-command/
Conseguirías lo mismo sin nice, incluso más preciso, porque con el nice le estás bajando la prioridad 5 puntos al comendo seq. Y con seq, simplemente cuentas hasta 8000, sin tener en cuenta el tiempo real que tarde en hacerlo.

¿Qué problema tienes con el coreutils-sleep?, porque yo recuerdo que lo tuve que instalar alguna vez, y sí me funcionó.

Cita de: Tki2000 en 12-07-2016, 10:55 (Martes)

nice es la función para dar más o menos prioridad a un proceso : http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/?utm_source=tuicool
seq es simplemente un contador de secuencia, en tu caso 8000 : http://scienceblogs.com/gregladen/2009/09/19/fun-with-the-linux-seq-command/
Conseguirías lo mismo sin nice, incluso más preciso, porque con el nice le estás bajando la prioridad 5 puntos al comendo seq. Y con seq, simplemente cuentas hasta 8000, sin tener en cuenta el tiempo real que tarde en hacerlo.

¿Qué problema tienes con el coreutils-sleep?, porque yo recuerdo que lo tuve que instalar alguna vez, y sí me funcionó.

Gracias por la info, cierto: funciona perfectamente con el comando: seq 8000 >/dev/null      sin el nice -n 5.


.... ni adredes, lo instalé en el otro router que lo tengo con extroot, swap y no dió fallo alguno.........

Installing coreutils-sleep (8.16-1) to root...
Downloading http://downloads.openwrt.org/barrier_breaker/14.07-rc3/brcm63xx/generic/packages/coreutils-sleep_8.16-1_brcm63xx.ipk.
Installing coreutils (8.16-1) to root...
Downloading http://downloads.openwrt.org/barrier_breaker/14.07-rc3/brcm63xx/generic/packages/coreutils_8.16-1_brcm63xx.ipk.
Configuring coreutils.
Configuring coreutils-sleep.

Sin embargo, googleando he mirado como ejecutar el sleep inferior a 1 sg y he lanzado el comando y como si no le hubiera instalado nada:

root@OpenWrt:~# time sleep 0.300
sleep: invalid number '0.300'
Command exited with non-zero status 1
real    0m 0.01s
user    0m 0.00s
sys     0m 0.00s


Me interesaría poder manejar el sleep de forma precisa en cuanto a tiempos cortos (2, 5 ms, etc...), ya que el valor más bajo es:

root@OpenWrt:~# time seq 0.002 >/dev/null
real    0m 0.01s
user    0m 0.00s
sys     0m 0.01s


Estos son los fallos al querer instalar "coreutils-sleep" en el otro router con el mismo firmware, pero sin extroot ni swap, vaya es el que uso para los GPIOs (lo pude desinstalar y al volverlo a instalar...)

Installing coreutils-sleep (8.23-1) to root...
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm63xx/generic/packages/packages//coreutils-sleep_8.23-1_brcm63xx.ipk.
Configuring coreutils.
Configuring luasocket.
Configuring coreutils-sleep.

//usr/lib/opkg/info/coreutils.postinst: line 4: default_postinst: not found
//usr/lib/opkg/info/luasocket.postinst: line 4: default_postinst: not found
//usr/lib/opkg/info/coreutils-sleep.postinst: line 4: default_postinst: not found
Collected errors:
 * pkg_run_script: package "coreutils" postinst script returned status 127.
 * opkg_configure: coreutils.postinst returned 127.
 * pkg_run_script: package "luasocket" postinst script returned status 127.
 * opkg_configure: luasocket.postinst returned 127.
 * pkg_run_script: package "coreutils-sleep" postinst script returned status 127.
 * opkg_configure: coreutils-sleep.postinst returned 127.


Al margen de todo esto, saludos y muchas gracias por la atención y los aportes, ....fuerte base del conocimiento estar entre ustedes.

Estás bajando los paquetes de sitios distintos. El primero es de la rama BB, el segundo de un trunk. Cambia el sitio de donde se baja el repositorio.
En un WD750N tengo instalado el sleep-8.16, y me funciona perfectamente con 0.3, por ejemplo. Tampoco me fiaría de la precisión que pueda tener, ya que ten en cuenta que no sólo interviene el comando sleep, sino también el tiempo que tarda en lanzar el comando, el tiempo de retorno de la línea de comando, y si el router está más o menos sobrecargado. Pero bueno, si buscas aproximaciones de +-20%, en tiempos menores de 1 segundo, te puede servir. Tampoco esperes mucha precisión en tiempos de escasos milisegundos. Hay tiempos mínimos en el lanzamiento de procesos que no se pueden eliminar.