Publicado por: dogflu66 en 15 de Abril de 2005, 20:20:00
Publicado por: Cristianxx en 16 de Abril de 2005, 20:42:00
Publicado por: Jimmy_pop en 17 de Abril de 2005, 08:10:00
see ya
Publicado por: dogflu66 en 18 de Abril de 2005, 17:57:00
- los servos me funcionan perfectamente... rotación continua
Los controlo mediante una interrupción que me genera el tmer2, se ejecuta 600 veces durante los 20mSg “periodo” para obtener los 50Hz que necesitan los servomotores...
20mSeg es a 600 veces la unidad de tiempo
1mSeg es a 30
1,5mSeg es a 45
2mSeg es a 60
por lo que se puede ver que solo dispongo de +-15 unidades de tiempo para disponer de la velocidad de los servomotores... en estas 600 veces ya estan incorporadas las demoras de tiempo, por tiempo de ejecución de las instrucciones de la propia rutina... todo esto quita mucho tiempo de ejecución al programa principal...
he pensado que si solo ejecuto la rutina durante 2mSeg (60 unidades de tiempo) y después reprogramo el timer2 con 18mSeg, dispondre de 18 mSeg de tiempo para ejecutar las tareas del programa pricipal con lo que de cada 20 mSeg 2 seran realmente los que absorban el tiempo de la cpu.... esto en principio me complica algo mas la rutina pero pienso que salgo ganando...
todo esto viene porque me estoy diseñando una placa para controlar 16 motores dependiendo de la configuración, motores normales, de paso a paso y como no... servomotores...
y dede luego estoy interesado en PIC que tengan mas salidas para PWM de serie... si me puedes indicar alguno para facilitarme la búsqueda...
Publicado por: Nocturno en 19 de Abril de 2005, 03:35:00
Publicado por: dogflu66 en 19 de Abril de 2005, 17:49:00
Pero al ser la rutina mas complicada pierdo el control de 2 servos con lo que la nueva rutina solo tiene la capacidad de controlar dos servomotores... pero con una variante de esta rutina complicándola poco mas se podria conseguir la siguiente distribución de recursos:
M0 y M1 -> 2mSeg
Resto de procesos -> 1mSeg
M2 y M3 -> 2 mSeg
Resto de procesos -> 1mSeg
M4 y M5 -> 2mSeg
Resto de procesos -> 1mSeg
M6 y M7 -> 2mSeg
Resto de procesos -> 1mSeg
M8 y M9 -> 2 mSeg
Resto de procesos -> 1mSeg
M10 y M11 -> 2mSeg
Resto de procesos -> 1mSeg
M12 y M13 -> 2mSeg
La suma total de tiempos seguiría siendo 20mSeg, por lo que se podrían controlar 14 servos e incluso reduciendo el tiempo a “Resto de procesos” se podrían controlar 16 servos... en fin todo es cuestión de probar y optimizar el codigo....
Publicado por: Jimmy_pop en 23 de Abril de 2005, 07:32:00
schedulable or not, that"s the question my friend
Publicado por: dogflu66 en 24 de Abril de 2005, 17:05:00
Publicado por: Cristianxx en 24 de Abril de 2005, 21:16:00
Aparte algunos pic de esa serie tienen un "kernel" que permite analizar y controlar los motores paso a paso basados en la información del encoder que les llega de vuelta.
Publicado por: dogflu66 en 25 de Abril de 2005, 05:57:00
pero por el momento estoy limitado a trabajar con la serie 16Fxxx... y por otro lado también tengo curiosidad por saber cuanto se le puede exigir a esta pastilla...
Publicado por: marmatar en 25 de Abril de 2005, 17:22:00
No recuerdo donde pero lo busqué en la web, no es éste , pero quizás te pueda servir.
http://shark.sssup.it/contrib/servo/servo.html
Un abrazo...
marmatar
Publicado por: angelmoi123 en 26 de Abril de 2005, 06:04:00
AMIGO MARMATAR, ME GUSTARIA SABER SI PUEDES SEGUIR BUSCANDO EL CONTROLADOR DE SERVOS QUE MENCIONAS PARA EL 16F877. EL QUE TU MENCIONAS YA LO TENGO Y NO SE ADAPTA A LO QUE ESTOY BUSCANDO.
MUCHO SABRIA AGRADECERTE SI LO ENCUENTRAS.
aneglmoi123
Publicado por: dogflu66 en 27 de Abril de 2005, 18:32:00
Un abrazo
Publicado por: RaDoN en 08 de Mayo de 2005, 14:01:00
Gracias por anticipado
Publicado por: dogflu66 en 08 de Mayo de 2005, 15:16:00
El amigo Pocher nos escribió:
-------------------------------------------------------
RE: Proyecto ROBOT
Espero no equivocarme:
El periodo máximo que admite el pwm del PIC es de 4,096ms, lo que implica una frecuencia mínima de 244Hz.
Si lo que quieres es generar un pwm mediante el módulo hardware CCP para un servo pués no hay problema puesto que este podrá variar entre 1ms y 2ms el resto del tiempo está a 0, hasta completar los 20ms de la frecuencia (f=50Hz)
Un saludo
PD. Los números anteriores son para una fosc=4MHz, para fosc=20MHz el Tmax=819,2us que no dá para controlar al servo.
Fórmula: Tmax=(255+1) · 4 · (1/fosc) · 16
-------------------------------------------------------------
http://miarroba.com/foros/ver.php?foroid=58732&temaid=3282955&pag=5
Publicado por: dogflu66 en 08 de Mayo de 2005, 15:26:00
Publicado por: pocher en 09 de Mayo de 2005, 00:07:00
Es cierto que basándonos en: T=(PR2+1) · 4 · (1/fosc) · TMR2preescaler
El periodo máximo que admite el pwm del PIC es de 4,096ms:
Tmax=(255+1) · 4 · (1/4Mhz) · 16 = 4,096ms lo que implica que el módulo hardware CCP nunca va a poder conseguir los 20 ms de periodo que hacen falta para el control del Servo.
Los 20ms no va a haber más remedio que conseguirlos mediante temporización de un TMR.
De nuevo pido excusas, esta tarde pasaré a corregir el otro mensaje.
Un saludo
Publicado por: dogflu66 en 09 de Mayo de 2005, 06:49:00
Publicado por: pocher en 09 de Mayo de 2005, 09:33:00
Un saludo
Publicado por: pocher en 09 de Mayo de 2005, 12:27:00
Publicado por: Jimmy_pop en 10 de Mayo de 2005, 15:42:00
El servo corregidme si me equivoco está pensado para recibir una entrada analógica cuyo valor de tensión el servo lo traduce en respuesta de posición del eje. Nosotros entramos directamente una salida de pwm generada por el controlador aprovechando que la entrada analogica del servo tendrá impedancia practicamente infinita y confiamos en que el servo por su transmitancia (que juraría que es la de un sistema lineal de 2o orden de tipo 1, debido a que debe contener un motor DC con una realimentación analogica a modo de P.I.) hará de pasabajos y se cargará las componentes de alta frecuencia del pwm dejando una señal finita que se traduzca en respuesta de posicion del servo de modo fluído sin salto. No obstante, por lo que leo aquí decís que hay que usar un ciclo dutty de como mínimo 20ms... supongo que eso se debe a que los tiempos de propagacion de los integrados del control del servo hacen una mala pasada y se cargan la señal, no?¡
Si eso es verdad mas que usar un dutty tan lento (que entre otras cosas puede producir discontinuidades en las velocidades del eje) yo lo que pensaría es aprovechar esta excusa para usar un periodo muy pequeño de dutty del pwm y poner un pequeño filtro pasabajos entre la salida del PWM y la entrada del servo para cargarnos las altas frecuencias, es algo que se hace muchas veces y no tiene demasiada dificultad...
la ventaja es que generaremos una señal muy fina que dará una respuesta del servo mucho mas buena.
para hacer el filtro quizás con un amplificador operacional se puede montar alguna historia sin demasiada complicación, solo hay q tener en cuenta antes de eso qué frecuencia de dutty se elige para dimensionar correctamente el filtro poniendo de frecuencia de corte por ejemplo la frecuencia del armonico principal del pwm.
bueno comentad que os parece la idea si os apetece
saludos
Publicado por: dogflu66 en 10 de Mayo de 2005, 15:56:00
Publicado por: Cristianxx en 10 de Mayo de 2005, 21:06:00
Leyendo el datasheet me he dado cuenta que se puede conectar un segundo cristal al pic, y queria ver si alguien mas experto me podria decir si este segundo cristal puede ser usado como reloj para el modulo pwm, asi se podria conectar un cristal de 1 mhz o 32 khz y de esa manera tener al pic funcionando rapido y al pwm lento como para manejar el servo.
---EDITADO----
Acabo de descubrir que la serie pic xx31 (2431, 4431, etc), los de control de motores, tienen entre otras cosas, la capacidad de producir frecuencias mucho mas bajas, hasta de 30hz con un cristal de 10 mhz, pero no pude dar con las formulas en el datasheet para controlar frecuencia y duty cycle. A ver si alguien entiende un poco mas que yo y nos ayuda
Publicado por: dogflu66 en 11 de Mayo de 2005, 18:25:00
Ya que trabajo con los servomotores desde hace poco tiempo y solo conozco las indicaciones de la hoja de características, alimentación entre 5 y 6v, una entrada de control que trabaja a una frecuencia de 50Hz y solo puede estar a positivo como máximo 2 mSg, estando la variación de esta entrada comprendida entre 1 y 2 mSeg y completando el resto del periodo con la señal a cero...
Yo no conozco realmente el funcionamiento del circuito del servo, pero imagino que la señal de entrada sera convertida a una señal continua debidamente filtrada y traducida a señal de control de sentido de giro y velocidad pwm... que según deduzco es algo parecido a lo que tu te refieres en tu mensaje...
Realmente tengo problemas para seguirte, tengo que decirte que mi rutina realmente trabaja con una frecuencia de 500Hz, que tuve que ajustar con un frecuencimetro, lo que ocurre como es natural es que tiene grandes periodos muertos en los que sus salidas estan a cero hasta completar los 18 mSg de periodo que faltan 500Hz -> 2mSg + 18 mSg que no hace nada = 50Hz -> 20mSg en total según las especificaciones del fabricante del servo motor...
Por lo que en principio si te entendi bien estoy trabajando como tu indicas... a una frecuencia muy superior a 50Hz...
Cristianxx el tema del segundo cristal es algo que no profundice en ello por la limitación del modulo ccp -> pwm a solo dos salidas, y para mi pequeño proyecto necesito mas, cuando tenga un rato libre le daré un vistazo y te cuento, y con respecto a la otra serie de pic no la he estudiado por lo que la desconozco...
Publicado por: dogflu66 en 11 de Mayo de 2005, 19:26:00
Si yo inyecto una señal de control con una duración de 2mSg a 1 y 18 mSg a cero, que esto equivale a una frecuencia de 50Hz, esta señal sera convertida a una señal analógica (en este caso al ser siempre la misma no variara de valor), la entrada tiene que ser de alta impedancia para mantener la señal generada durante el periodo de tiempo que la señal de control esta a cero, esta señal sera analizada y convertida a valor de sentido de giro y velocidad del motor.... esto seria lo normal según el fabricante...
Entonces si inyecto una señal de control con una duración de 1.5 mSg a 1 y 0.5 mSg a cero, esto equivale a una frecuencia de 500Hz, esta señal habría que filtrar para eliminar los armonicos jodidos, después entraria a la circuiteria con lo que tendría el mismo proceso que la anterior, entrada de alta impedancia convertida a valor de tensión, y traducida a sentido de giro y velocidad de motor (en este caso motor parado), es decir este es el caso que tu expones y que debería de funcionar... igualmente que el anterior que es el que especifica el fabricante...
Publicado por: Cristianxx en 11 de Mayo de 2005, 20:34:00
Publicado por: pocher en 12 de Mayo de 2005, 06:08:00
Bien, la fórmula era: T=(PR2+1) · 4 · (1/fosc) · TMR2preescaler
El periodo máximo que admite el pwm del PIC es de 4,096ms: Tmax=(255+1) · 4 · (1/4Mhz) · 16 = 4,096ms con lo cual falta mucho para los 20ms.
Sí, pero los cálculos de arriba son para una fosc=4MHz, si queremos aumentar T, lo único que hay que hacer es disminuir la fosc. Empleando por ejemplo una fosc=1MHz tendríamos T=16ms que son suficientes para controlar al Servo ya que los 20ms no son estrictos hay un margen de aproximadamente 5ms por arriba y por abajo, y si quieres los 20ms exactos pues coges otro cristal. ¡ A que la solución era tonta!
Bien, avanzando un poco más estaba pensando en que con los 2 módulos CCP pués solo se podrían controlar 2 Servos (uno por módulo). He intentado asignar la señal pwm que sale por RC2 (ó RC1) a otro pin del PIC, por ejemplo a RB0, con output_bit(pin_b0,input(pin_C2)) pero no va bien, no sé si va a ser posible, si lo fuera conseguiríamos controlar más de 2 servos con pwm del CCP.
Un saludo
Publicado por: dogflu66 en 12 de Mayo de 2005, 10:48:00
Publicado por: Cristianxx en 12 de Mayo de 2005, 11:02:00
Escrito originalmente por pocher
Ya he encontrado una solución para poder usar los módulos hardware CCP en modo PWM con un Servo. Es una tontería, pero en su momento no la ví.
Bien, la fórmula era: T=(PR2+1) · 4 · (1/fosc) · TMR2preescaler
El periodo máximo que admite el pwm del PIC es de 4,096ms: Tmax=(255+1) · 4 · (1/4Mhz) · 16 = 4,096ms con lo cual falta mucho para los 20ms.
Sí, pero los cálculos de arriba son para una fosc=4MHz, si queremos aumentar T, lo único que hay que hacer es disminuir la fosc. Empleando por ejemplo una fosc=1MHz tendríamos T=16ms que son suficientes para controlar al Servo ya que los 20ms no son estrictos hay un margen de aproximadamente 5ms por arriba y por abajo, y si quieres los 20ms exactos pues coges otro cristal. ¡ A que la solución era tonta!
Bien, avanzando un poco más estaba pensando en que con los 2 módulos CCP pués solo se podrían controlar 2 Servos (uno por módulo). He intentado asignar la señal pwm que sale por RC2 (ó RC1) a otro pin del PIC, por ejemplo a RB0, con output_bit(pin_b0,input(pin_C2)) pero no va bien, no sé si va a ser posible, si lo fuera conseguiríamos controlar más de 2 servos con pwm del CCP.
Un saludo
El Prescaler que tiene el modulo especial de pwm del 2431/4431 admite un prescaler de hasta 128, pero no estoy seguro si la formula es la misma. Además me parece que permite un postscaler... El modulo está especialmente diseñado para producir frecuencias que puedan alcanzar valores bajos, para poder controlar motores de inducción de 3 fases y cosas asi... pero sigo sin dar con la formula para calcular la frecuencia.
Publicado por: aupadeportivo en 12 de Mayo de 2005, 12:32:00
Mi robotito es gobernado por 2 pics 16F876, uno el master que recog4e la informacion de los sensores y me manda un byte mediante i2c al esclavo que se encarga de mover en motor dc controlado por pwm y girar un servo. Para el giro del servo, cree una interrupcion con base de tiempo de 100us y mediante un contador dar el duty necesario a 1 y el resto a cero. El programita esta en el subforo de robotica en el tema robots cooperativos.
Ahi viene mi problema:
Tengo un programita sencillo de maestro y esclavo. Envio un Byte el cual es recibido correctamente. Al insertar el codigo de recpcion i2c en el esclavo (el que me recibe el byte del master y controla el motor dc y el servo) no me funciona y me falla parece ser debido a la interrupcion genrada por el timer 1 para poder controlar el servo. Con proteus veo que funciona bastante bien, pero cuando configuro timer1 y le mato la interrupcion se queda sin recibir el byte del master. Es quitar las lineas de codigo referidas al timer 1 y su correspondiente interrupcion y me funciona.
No tengo claro como arreglar esto, o si hay otra forma de enviar datos i2c y que siga funcionando la rutina de interrupcion del servo y recibiendo ese byte qe me marca todo el movimiento.
Respecto a lo de usar otro cristal mas bajo y de esa forma ahorrarme esa interrupcion, pudiera ser que me funionara el i2c?
Ademas , en mi sistema constituido por 2 pics, ¿no debemn tener los dos el mismo cristal? Si es asi no me interesaria bajarlo.
Un saludo desde Valencia!
Publicado por: pocher en 12 de Mayo de 2005, 13:36:00
Amiguete deldepor, el usar cristales diferentes en los PICs solo va a afectar a la velocidad de ejecución del programa en el PIC correspondiente, no a la comunicación I2C.
El usar la interrupción del I2C por recepción de dato y al mismo tiempo la del TMR1 puede que dé problemas, o no recibirás bien el dato por estar en la int del TMR1 o no funcionará bien el Servo por estar en la int del I2C.
Prueba a quitar la int del TMR1 y a controlar el Servo con el cristal de 1MHz mediante un módulo CCP, yo he probado en PROTEUS el controlar 2 Servos con pwm por hardware y funciona bien.
Un saludo
Publicado por: dogflu66 en 12 de Mayo de 2005, 17:28:00
Publicado por: dogflu66 en 12 de Mayo de 2005, 17:35:00
Publicado por: aupadeportivo en 19 de Mayo de 2005, 06:27:00
Otra cosa, mediante i2c se envia un byte que recibe el esclavo. Los 4 primeros bits me marcan la velocidad del motor dc, los 3 siguientes la posicion del servo y el ultimo para hacer que el cacharro vaya hacia alante o hacia atras.
Pocher, al fianl miramos eso de que porque no recibia correctamente el i2c cuando metiamos la interrupcion del servo y ya funciona. En la directiva de use i2c, en vez de fast pusimos slow, y el puerto c no esta configurado, creo que lo configuraba como salida y creemos que por eso no recibia nada (que va a ser que si).
Bueno este es el programita del esclavo:
#include <16F876A.H>
#fuses XT, NOPROTECT, NOPUT, NOWDT, NOBROWNOUT, NOLVP, NOCPD//, WRT
#use Delay(Clock=4000000)
#use i2c(SLAVE, SDA=PIN_C4, SCL=PIN_C3, ADDRESS=0X08, SLOW , NOFORCE_SW)
#use fast_io(A)
#use fast_io(B)
#use fast_io(C)
#byte port_a = 5 // Identificador asociado al registro de dirección 5
#byte port_b = 6 // Identificador asociado al registro de dirección 6
#byte port_c = 7 // Identificador asociado al registro de dirección 7
int periodo, dutty;
#INT_TIMER1 //Rutina de atención a la interrupcion
void interrupcion()
{
set_timer1(65472); //Recarga el timer a 100us (-36us) Base de tiempo
periodo=periodo+1; // cada vez que se entre incrementamso periodo
if(periodo<dutty) //Duracion de estado alto PWM segun
posicion servo
{
output_high(pin_a0);
}
else
{
output_low(pin_a0);
}
if(periodo==200) // Acaba el periodo
{
periodo=0;
}
}
void main()
{
int dato, servo, xx, dutycalculado;
set_tris_a(0x00);
set_tris_b(0x00);
enable_interrupts(GLOBAL); // Activamos interrupciones
globales
enable_interrupts(INT_TIMER1); // ... y la interrupcion por TMR1
setup_timer_1 ( T1_INTERNAL | T1_DIV_BY_1); //Configuracion TMR1 y preescaler
setup_timer_2(T2_DIV_BY_16,249,1) ; // Div=16 ; PR2=249 ; Postscale=1
setup_CCP1 (CCP_PWM);
set_timer1(65472);
delay_ms(50);
while(1)
{
if(i2c_poll())
{
dato=0;
dato=i2c_read();
i2c_stop();
}
port_b=dato;
servo= 0b01110000 & dato;
xx= 0b00001111 & dato; //velocidad (1=10%, 2=20%......10=100%)
if(xx>10) //
{
xx=0;
set_pwm1_duty(0); //Si es mayor a 10 duty=0
}
else
{
dutycalculado= 25 * xx ; // Valor a cargar en duty
set_pwm1_duty(dutycalculado);
}
switch (servo)
{
case 0:
dutty=12;
break;
case 16:
dutty=15;
break;
case 48:
dutty=18;
break;
case 64:
dutty=9;
break;
case 114:
dutty=6;
break;
}
while (!(i2c_poll()))
{
port_b=dato;
}
}
}
Bueno y el maestro es sencillo, simplemente enviar con las funciones de ccs i2c write()..... etc. Y eso funciona fisicamente sin problemas.
Una cosa que no tiene nada que ver, queremos enviar un byte de un robot a otro mediante infrarrojos y no sabemos muy bien como hacerlo. Hemos encontrado un enlace parece ser que bueno www.jdlope.tripod.com/infra.html y tal te explica como hacerlo. Si le pegais un vistazo y tal me comentais. Nos gustaria si es posible evitar modular la señal. Si alguien ha hecho algo de esto porfi que comente algo por aqui o que abra un post de comunicacion infrarroja en el subforo de robotica.
Un saludo desde valencia.
Publicado por: dogflu66 en 28 de Junio de 2005, 08:50:00
Publicado por: RaDoN en 28 de Junio de 2005, 10:22:00
Publicado por: pocher en 28 de Junio de 2005, 10:47:00
Ahora hay que encontrar a alguién que nos informe de su funcionamiento.
Publicado por: RaDoN en 28 de Junio de 2005, 12:09:00
En cuanto al PIC que dices con 5 modulos CCP, ¿me puedes indicar el modelo? Y ... ¿no habia unos PICs a los que se le podian poner un segundo cristal para estos menesteres? ó lo he soñado yo ...
Sorry, estoi leyendo entero el hilo y parece ser que llego tarde
es un tocho considerable y da pereza, de todas formas el control de los servos parece que no ha quedado del todo claro, ami me parece como mejor solución el uso de esos pics con el 2º cristal (si se puede) o otro pic para gobernarlos con un cristal lento y comunicarlos con algun protocolo, p.ej. i2c.
Publicado por: RaDoN en 28 de Junio de 2005, 17:08:00
Publicado por: RaDoN en 30 de Junio de 2005, 05:41:00
Y cito textualmente:
____________________________________________________________________
La versión de kit completo incluye el circuito SSC (Serial Servo Controller) que permite controlar desde un puerto serie RS232 hasta 8 servos independientes. Este circuito SSC recibe las ordenes de movimiento de un PC, un BASIC Stamp o cualquier otro microcontrolador y genera los pulsos de control de posición de los servos.
____________________________________________________________________
Quisiera saber que lleba eso !!
Publicado por: RaDoN en 03 de Julio de 2005, 18:22:00
http://www.the-starbearer.de/Roboterelektronik/servo/sd20.pdf
Quien tiene mas info del SD20 !!!
Publicado por: dogflu66 en 04 de Julio de 2005, 10:41:00
A ver si alguien consigue algo mas de información...
Publicado por: dogflu66 en 06 de Julio de 2005, 18:25:00
En principio había pensado en enviar una trama compuesta por un byte de arranque o cabecera + un byte de comando + el estado de los ocho servos (8 byte) + checsum...
Lo del byte de comando es por implementar ordenes abreviadas o genéricas a todos los servos como... todos a off o posición central, o todos a un lado, o a otro... etc... acepto cualquier sugerencia...
Después de esto quedaria optimizar el sistema para lograr controlar el máximo numero de servos... y posiblemente habilitar también la posibilidad de controlar el sistema por I2C...
PD.
Le deje a la rutina de puerto serie un búfer de entrada de 50 byte por si hubiera algún tipo de retrazo en la interpretación de los datos recibidos pero en principio no he observado ninguno, por lo que se ve los 20Mhz están dando su fruto...
Publicado por: dogflu66 en 07 de Julio de 2005, 19:25:00
Y por el momento todo ok...
Haciendo un resumen, el 16F877 esta gestionado un display de 2x16 caracteres, la rutina de los ocho servos por software y el puerto RS232...
Publicado por: RaDoN en 08 de Julio de 2005, 02:49:00
Publicado por: dogflu66 en 08 de Julio de 2005, 09:18:00
y mi intencion es la de publicar el trabajo...
Publicado por: RaDoN en 08 de Julio de 2005, 10:05:00
Publicado por: dogflu66 en 08 de Julio de 2005, 13:21:00
2mSeg maximo + 18 mSeg tiempo muerto = 50Hz, no?...
Publicado por: RaDoN en 08 de Julio de 2005, 13:31:00
Publicado por: dogflu66 en 11 de Julio de 2005, 08:20:00
Publicado por: dogflu66 en 22 de Julio de 2005, 19:14:00
Publicado por: RaDoN en 22 de Julio de 2005, 21:32:00
Publicado por: dogflu66 en 23 de Julio de 2005, 15:49:00
Como usamos el mismo micro a 20Mhz simplificamos...
La distribución de los servos es la siguiente:
PORTD.0
PORTD.1
PORTD.2
PORTD.3
PORTD.5
PORTD.6
PORTD.7
PORTC.5
El puerto serie es el estándar:
TX/RC6
RX/RC7
Los puertos del display son:
D. BITS = 8
Datos = PORTB
RS = PORTC.0
E = PORTC.4
R/W = PORTC.1
Ordenes serie que admite:
Grupo = 255
Orden:
velocidad_motores = 77
on_off_motores = 78
status_motores = 79
tx_motores = 80
velocidad o posicion de los servos, minimo 30 y max. 60:
30 = 1 mSg.
45 = 1.5 mSg.
60 = 2 mSg.
Orden = 78
Hserout grupo, orden, dato0, aux_checsum_lb, aux_checsum_hb
El valor de dato0 se aplica a todas las salidas (comprendido 30 a 60).
Orden = 77
Hserout grupo, orden, dato0, dato1, dato2, dato3, dato4, dato5, dato6, dato7, aux_checsum_lb, aux_checsum_hb
Dato se aplica a cada una de las salidas respectivamente.
Orden = 79 (pide el estado de los servos)
Hserout grupo, orden, aux_checsum_lb, aux_checsum_hb
Orden = 80 (cuando recibe la orden 79 la placa responde con la orden 80, con el estado
de todos los servos.)
Hserout grupo, orden, pwm_m0, pwm_m1, pwm_m2, pwm_m3, pwm_m4, pwm_m5, pwm_m6, pwm_m7, aux_checsum_lb, aux_checsum_hb
Checsum es de 16 Bit
checsum = grupo + orden + dato0 + dato1 + dato2 + dato3 + dato4 + dato5 + dato6 + dato7
aux_checsum_lb = checsum (igual al byte bajo)
aux_checsum_hb = checsum (igual al byte alto)
en el DISPLAY aparecen los valores actualizados de las salidas.
Si tienes algun problema con esta configuración indicame las modificaciones.
Publicado por: RaDoN en 23 de Julio de 2005, 18:00:00
Publicado por: dogflu66 en 23 de Julio de 2005, 21:02:00
Publicado por: dogflu66 en 23 de Julio de 2005, 21:34:00
Publicado por: RaDoN en 24 de Julio de 2005, 09:11:00
Publicado por: RaDoN en 25 de Julio de 2005, 05:36:00
Publicado por: dogflu66 en 25 de Julio de 2005, 06:19:00
Publicado por: RaDoN en 25 de Julio de 2005, 07:11:00
Publicado por: piriots en 25 de Julio de 2005, 08:10:00
Publicado por: RaDoN en 25 de Julio de 2005, 08:12:00
PIC16F877-04 ---> 4 Mhz
PIC16F877-20 ---> 20 Mhz
Publicado por: RaDoN en 25 de Julio de 2005, 10:22:00
http://miarroba.com/foros/ver.php?foroid=44527&temaid=3981737
Publicado por: Nocturno en 26 de Julio de 2005, 01:50:00
Lo que te comentan los compañeros es lo del fuse XT o HS, que según dices en el otro post ya lo has probado y nada ¿no?
Publicado por: RaDoN en 26 de Julio de 2005, 18:04:00
Publicado por: dogflu66 en 28 de Julio de 2005, 19:06:00
Publicado por: RaDoN en 29 de Julio de 2005, 05:09:00
Publicado por: dogflu66 en 29 de Julio de 2005, 06:10:00
Publicado por: RaDoN en 29 de Julio de 2005, 06:46:00
Publicado por: dogflu66 en 29 de Julio de 2005, 15:45:00
Publicado por: dogflu66 en 02 de Agosto de 2005, 07:59:00
Publicado por: dogflu66 en 05 de Agosto de 2005, 19:15:00