|
|
Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.
Mensajes - Huguen_aus_Tirol
Páginas: 1 ... 8 9 [10] 11 12 13
226
« en: Miércoles 23 de Noviembre de 2005, 23:42 »
Hola! Según mi punto de vista, que se envien 8 o 9 bits, con bit de parada y demás yerbas, es parte del estandar. Y protocolo lo entiendo como el "idioma" que usemos para que las dos partes se entiendan. Por ejemplo, en la caso que les comenté anteriormente, en los paquetes que armaba para la transmisión cada byte tenía un significado en particular; esto es el "protocolo". Que haya usado RS232 o 485, es cosa del estandar. Yo al menos lo veo así  Como tu dices, si envias el caracter "a" como el codigo 0x61 (ASCII), el receptor debe saber que está recibiendo codigos ASCII (es el protocolo). Que hayas configurado el puerto de comunicación serie con 8 bits, bit de parada y paridad, a 9600 baudios, por ejemplo, es parte del estandar. No se si esta correcto esto, pero es mi punto de vista. Gracias Ale! Trabaje mucho con la serie S7 400, más precisamente con los 413; lo mismo con los Micro y Mini Master, todos en red por Profibus y comandados por varios PLC (estos en red Ethernet). Habran sido unos 300 variadores  Pero no había tenido tiempo de ver detenidamente los manuales. Tengo algunos CD´s de Siemens en algún lugar guardados, ya me fijo si encuentro algo... Es una idea de aquella época, pero no sería malo poder implementar algo con un MCU para este interesante bus de campo. Alguien se engancha? Pero no es fácil  Tengo el estandar, pero muy poco (nada) del protocolo  Bueno, gracias!
227
« en: Miércoles 23 de Noviembre de 2005, 23:12 »
Hola Ian! "CCP" no es una instrucción, es un modulo (Compare/Capture/PWM). Según lo configures te realiza una de estas tres funciones.
Fijate en la hoja de datos del 16F628, o cualquier otro micro que tenga este modulo, y encontrarás como configurarlo y como funciona.
Saludos
228
« en: Miércoles 23 de Noviembre de 2005, 20:23 »
Hola a todos (chicas y chicos)  Hace poco implementé comunicación serie (RS232) entre un 18F y la PC. Siempre se envían 1 y 0, no hay otra opción... Que usemos el codigo ASCII o cualquier otro, depende del protocolo que implementemos; pero en cualquier caso el PIC vé 1 y 0, somos nosotros los que debemos decirle al PIC que significa esa combinación de 1 y 0 En mi caso con el 18F (18F452) utilizé dos bancos de RAM, cada banco tiene 256 bytes; uno para buffer de recepción y el otro para buffer de transmisión. En la aplicación escribo o leo las distintas posiciones de cada banco. Entonces, según la necesidad, digo: de tal posición a tal otra, son caracteres ASCII para mostrar en el LCD; de esta otra a esta otra son valores numéricos (es decir el número hexa, nada de ASCII); entre esta y esta dirección tengo valores de los que me interesa el estado de los bits (registros, o flags, o bits de configuración, o lo que necesitemos...); y asi según lo que necesitemos. En la aplicación no necesitaba 256 bytes, pero este era el tamaño de mi paquete de datos; los bytes sobrantes estaban ahí, pero los ignoraba. Los paquetes los hacemos del tamaño que queremos, pueden ser menos o más bytes Al terminar cada lazo de mi programa principal enviaba un paquete y a continuación la PC me respondía con otro. Si no hay respuesta, se que no hay comunicación y hago lo que corresponda  Algo similar hice antes, pero usando detección de dirección (9 bits de datos). Comunique varios PIC (16F y 18F), cada uno con una dirección diferente. En este caso los paquetes eran de 16 bytes, un paquete por esclavo; y estaban armados según la necesidad. Cada comunicación era atendida por el esclavo direccionado. El maestro era un 18F452, y la comunicación RS485. Ya que que estamos en el baile, alguien sabe donde conseguir buena información sobre Profibus???? Bueno, después de aburrirles tanto, dejen que me despida... Saludos!
229
« en: Martes 22 de Noviembre de 2005, 20:05 »
Hola! Estuve viendo el tema del compilador, y ya está solucionado. El tonto que escribió el código, es decir yo  , declaró las variables "tmr_ms" y "aux_ms" como byte, cuando en realidad son int16 (llegan a tener hasta el valor 1000 decimal). Esto fue todo, ahora funciona! Me llama la atención que el compilador no de ningún error, o al menos un warning  Es el CCS C, en "Acerca de..." aparece PCWH; no se... Saludos!
230
« en: Martes 22 de Noviembre de 2005, 18:44 »
Bueno, el fin de semana me bajé algunos DS de Motorola. Estuve viendo el 68HC908GP32CP (que nombres tan largos...). Aclaro que los vi muy por arriba En lo que respecta a los periféricos, no están mal; tampoco los de los PIC. Por lo que vi, no hay la posibilidad en la comunicación serie de generar interrupción solo cuando el bit 9 es 1 (detección de dirección); en los PIC con EUSART si existe esta posibilidad, que la encuentro muy útil. Me parece más simple el modulo PWM de los PIC. No es muy importante, pero practicamente todos los PIC´s tienen AD de 10 bits. En los Motorola encontré pocos de 10 bits. Es muy lamentable que los PIC no tengan una instrucción para realizar divisiones; Motorola sí la tiene. En cuanto a los precios y disponibilidad, aquí en Austria están a la par de los PIC. La posibilidad de conectarlos a la PC por el puerto serie para ver "que pasa" dentro (creo que es algo de monitor ROM, o algo asi), no la tienen los PIC. La encuentro interesante No se como se los programa, si necesitan un grabador. Busqué en la red, pero no encontré nada; de los PIC hay de sobra. No se si las herramientas de desarrollo (compiladores, IDE, etc) son gratuitas y donde se consiguen. Microchip pone a nuestra disposición el MPLab, gratuito! Bueno, para hablar más primero debería tener un Motorola entre mis dedos y ver como se porta. Asi que si alguien ayuda con el programador y las herramientas, le agradezco enormemente... No creo que sean (ninguna de las dos marcas) para nada malos, al contrario. Solo creo que son distintas opciones. Saludos
231
« en: Martes 22 de Noviembre de 2005, 18:15 »
Hola a todos! Estoy escribiendo algo de código en C, con el PCWH, y al compilar no me convierte todo el código No tengo mucha experiencia en C, pero por ahora no intento realizar nada complicado. La parte que no compila es una sección de la atención a la interrupción del timer 0. Aqui les dejo esta parte del programa... .................... #int_TIMER0 .................... TIMER0_isr() .................... { .................... TMR0L = 237; * 013A: MOVLW ED 013C: MOVWF FD6 .................... --tmr_ms; 013E: DECF 17,F .................... ++aux_ms; 0140: INCF 1A,F .................... if( aux_ms >= 1000 ) .................... { .................... if( bit_test( PORTA,4 )) .................... bit_clear( PORTA,4 ); .................... else .................... bit_set( PORTA,4 ); .................... aux_ms = 0; .................... --tmr_s; .................... ++aux_s; .................... if( aux_s >= 60 ) .................... { .................... aux_s = 0; .................... --tmr_m; .................... ++aux_m; .................... } .................... } .................... } .................... 0142: BCF FF2.2 0144: GOTO 0060
Lo copié y pegué del listado, asi pueden ver que es lo que compila y que no. El resto del programa lo compila y se ejecuta sin problemas... No se que puede ser, alguien me da una mano? Saludos
232
« en: Martes 22 de Noviembre de 2005, 17:56 »
Gracias por la corrección, Alternative!!! Por lo visto la trigonometría se me está borrando de la RAM...   Entonces tienes que hacer dos rotaciones a la derecha; cuidado que el carry no meta algún 1 en el bit 7! Bueno, gracias... Es bueno que nos corrijan cuando nos equivacamos Ojalá puedas conseguir el libro, yo lamentablemente no lo tengo y aquí no lo puedo conseguir... Saludos y suerte!
233
« en: Lunes 21 de Noviembre de 2005, 23:45 »
Hola Ian! Bueno, según lo que entiendo de tu problema, creo que sería conveniente usar un micro con modulo CCP, configurado en modo de captura; con esto mides el ancho del pulso. Que estén desfasados 90º significa que el segundo pulso comienza justo a la mitad del tiempo del primero, si no me equivoco . Es decir, el valor medido lo divides por 2 (rotas una vez este valor a la derecha ); generas tu primer pulso (en fase), esperas este tiempo calculado, y generas el pulso desfasado. Se me ocurre usar el modulo CCP porque creo que es lo más rápido. En este caso tienes ocupado el timer1 para la captura, asi que tendrás que usar el timer0 para generar tu pulso. Es lo que se me viene a la cabeza en este momento... puede que haya otra solución... Bueno, que micro? Puede ser el 16F627/8. Saludos!
234
« en: Miércoles 16 de Noviembre de 2005, 23:53 »
Hola Alejandra! Recuerdo que una vez me armé una placa con un 8255 que iba en un slot ISA en la PC, funcionaba de maravilla Pero hace muuuuucho (la época del DOS y placas madre con slots ISA de sobra, ahhh!! qué tiempos!)... Es buena la idea de usar un micro; pero ten encuenta que necesitas 8 lineas para el bus de datos más otras tantas para el control, no recuerdo bien pero creo que son lectura, escritura, chip select y un par de direcciones. Es decir, necesitas el micro con, digamos, 18 pines más otro CI de 40 pines Todo para conseguir 8 * 3 = 24 lineas, que puedes configurar como entrada/salida en grupos de 8. Puedes conseguir (a buen precio) micros de 40 pines con 36 lineas I/O, configurables indepencientemente. Y te ahorras trabajo con el diseño del PCB . De cualquier manera, la idea no es mala. Si me hago un tiempo voy a ver de dar una mano con este tema; pero ten algo de paciencia, que estoy a los saltos (como sapo en campo recién arado ) Saludos, y hasta la próxima!
235
« en: Jueves 10 de Noviembre de 2005, 19:32 »
Hola Ian! Gracias, pero no es para tanto... Fijate en el registro OPTION_REG, bit 6 (INTEDG). Si pones este bit a 1, se genera una interrupción en RB0 con un flanco de subida (cambio de 0 a 1); si lo pones a 0 se genera interrupción con flanco de bajada. Esto siempre que la interrupción esté habilitada Este registro tiene otros bit´s interesantes... Bueno, estamos aquí para dar una mano, no es así? Saludos!
236
« en: Miércoles 9 de Noviembre de 2005, 22:29 »
237
« en: Miércoles 9 de Noviembre de 2005, 22:26 »
Hola! De nuevo por aquí El problemita de Ian me llevó a pensar y se me ocurrió lo siguiente... Bajen el pdf y vean, creo que es bastante simple. Normalmente el micro se alimenta con una tensión AC (o DC) desde el conector VAC; el puente rectificador convierte la tensión AC en DC (o corrige la polaridad). En el conector BAT conectamos nuestra bateria, creo que una pila de 9 voltios debería funcionar bien. La tensión en VAC debe ser algo mayor que la de BAT, de lo contrario la bateria estará alimentando permanentemente al micro Cómo funciona? En el caso de alimentar con AC, por medio de R1, R2 y D3 tenemos pulsos en RB0. Estos pulsos dicen al micro que tenemos alimentación normal; podemos implementar en soft una especie de watchdog por la interrupción INT0. En caso de alimentar con DC, tambien tenemos la confirmación, pero con un nivel alto permanente. Al desaparecer los pulsos (o caer el pin RB0), hacemos lo que deseamos en caso de corte de energía (guardar datos en EEPROM, por ejemplo) y dejamos al micro en modo de bajo consumo. El consumo es tan bajo, que la bateria debería durar bastante. Al volver la alimentación normal, tenemos una interrupción en RB0, y el micro se despierta, y la vida continúa Creo que hay muchas variantes para el soft, asi que dejo en manos del que le interese; no debería ser muy complicado... Los valores de los componentes son indicativos, deberíamos ver cada caso en particular para C1, R1 y R2. No nos olvidemos de desconectar cualquier carga innecesaria en caso de falta de VAC (LED´s por ejemplo). Bueno, espero les sea útil. Saludos ; y gracias Ian por pasarnos el problemita
238
« en: Jueves 3 de Noviembre de 2005, 07:07 »
Hola Jaumegs! Es buena la idea de usar el 876. Reserva la USART para comunicarte con una PC, si es que lo necesitas; para comunicarte con otros IC's aprovecha el IIC (para eso fue creado ) Puedes emular IIC en un 16F84, aunque fijate que consigues en tu zona, ya que hay infinidad de PIC's. Si consigues alguno con el modulo incorporado, es lo mejor. Es más, depende de lo que quieras, se consiguen integrados específicos que soportan IIC (expancion de I/O, RTC, memorias, conversores AD, etc...) Otra sería usar la USART con el estandar RS485. El 876 soporta comunicación serie con 9 bits, es decir con posibilidad de direccionamiento. Se consiguen distancias más largas que con IIC; aunque debes agregar un integrado extra para convertir los niveles de tensión (SN75176 o similar), y solo podrás comunicar micros con otros micros (no hay integrados específicos) Mi sugerencia: IIC, y buscas que consigues de PIC's con este modulo, o CI's específicos Bueno, espero haber ayudado algo  Saludos
239
« en: Viernes 30 de Septiembre de 2005, 13:17 »
Hola! El circuito que publica Chicoteleco funciona a la perfección, yo ya lo he montado anteriormente y los resultados son más que buenos Si controlas la dirección de los datos con RA4, tienes que tener en cuenta que esta salida es drenador abierto, es decir que cuando escribas un 1 en RA4 tendrás 0V en el pin, en tanto que cuando escribas un 0 RA4 queda al aire y el nivel de tensión se define por R32 (unos 10K esta bien) Cuando escribas un 1 en RA4 (0V en el pin), se habilita la recepción de datos; caso contrario se habilita la transmisión. En RS485 se pueden "colgar" varios puntos de la red. Dejas normalmente como transmisor al maestro y en modo recepción a los esclavos; el esclavo que sea direccionado actua según la necesidad... Bueno, hay mucho de que hablar sobre este tema. No necesitas nada más, solo el esquema tal cual está publicado. El resto pasa por la programación. Con los modulos USART de los PIC, hacer redes 485 es bastante simple e interesante (y divertido ). Bueno, espero haber ayudado con algo. Nos cuentas como te ha ido Saludos
240
« en: Jueves 29 de Septiembre de 2005, 20:33 »
Bueno, no des las gracias... para eso estamos aqui Por qué no pruebas el WinPic? Encontraras aqui en el foro donde bajarlo, o bien con el Google Con el ICProg (lo usaba bastante) ultimamente tuve problemas, asi que cambié a este otro soft y funciona de maravilla. Estaba buscando el esquemático del PIPO, recuerdo haberlo bajado, pero no se donde lo dejé. Ya lo busco mejor y lo veo, a ver si te puedo dar una mano con respecto al hardware. Yo uso el programador que publiqué aquí, y me funciona perfecto; no tengo noticias de si alguien más lo ha armado, para saber como le ha ido. Siempre grabo en ICSP, es decir sin sacar el micro de la placa donde lo utilizo. Me evito tener que estar sacando el micro y que le pueda pasar como a la cucaracha de la canción Bueno, ya nos cuentas... Saludos
241
« en: Martes 27 de Septiembre de 2005, 07:19 »
Hola! No conzco mucho de este programador, pero estaba viendo la hoja de datos del PIC y un manual que habla de la programación de estos. En primer lugar, la tensión de programación (Vpp) debe ser 13V +/- 0.5V; es decir entre 12.5 y 13.5V. En segundo lugar, el micro se puede programar en todo el rango admitido de tensión de alimentación (Vcc), pero para un borrado completo de memoria (bulk erase) Vcc debe estar entre 4.5 y 5.5V. Entonces, por qué lo programó una vez? En el registro de configuración del PIC (CONFIG), el bit LVP cuando está a 1 permite programar el PIC sin necesitar que Vpp sea 13V; para ello se utiliza el pin RB3, en este caso cuando RB3 tiene un nivel alto se entra al modo de programación. Por defecto, el bit LVP es 1, es decir que esta habilitada la opción de "Low Voltage Programming". Posiblemente el pin RB3 este al aire y no tenga un nivel definido, pudiendo ser motivo de algún problema. Por supuesto, independientemente del bit LVP, al aplicar 13 V a MCLR entramos al modo de programación. Te aconsejo que controles las tensiones de tu programador, Vpp debe ser unos 13V y Vcc 5V. Es raro que la tensión caiga tanto, controla que no haya conflictos entre las conecciones de Vpp y Vcc, 0.8 V es algo bajo para Vcc Bueno, espero haber podido colaborar con algo... Despues nos cuentas. En la página de Microchip se encuentran las especificaciones para la programación de los PIC, es facil llegar a encontrarlas Saludos
242
« en: Jueves 22 de Septiembre de 2005, 19:20 »
Hola Ecoes! Felicitaciones!!!!  No es necesario que des las gracias, para eso estamos aqui en el foro Aproposito, tengo unos pequeños motores paso a paso que me estan esperando... quizá más adelante te haga alguna consulta Saludos
243
« en: Martes 20 de Septiembre de 2005, 07:02 »
Hola Ascari! Antes que nada, debes configurar el PIC para oscilador XT. Los capacitores de 22 pF están bien; debería funcionar. Usas una proto?  Presta mucha atención en los contactos, fijate que esté todo bien... Saludos y nos cuentas
244
« en: Lunes 19 de Septiembre de 2005, 20:47 »
Hola! El puerto C se comparte con algunos de los perifericos del micro; deberías verificar que la configuración de estos perifericos no esté interfiriendo en los pines del puerto C. Quizá este sea tu problema. Cuando necesito un LCD lo conecto al puerto B, asi me quedan libres las opciones del puerto C . Pero de todas formas debería funcionar. Bueno, chequea la configuración y nos cuentas. Ojala se solucione Saludos
245
« en: Lunes 19 de Septiembre de 2005, 01:05 »
Hola! A ver si puedo ayudarte... Que tipo de cristal usas? Tiene cada uno de los terminales un capacitor conectado a masa? (Generalmente son de entre 22 pF y 33 pF) No hay problemas en las conecciones? Soldaduras frías, pistas cortadas, etc... Saludos
246
« en: Lunes 19 de Septiembre de 2005, 00:58 »
Hoa! De vuelta por el foro Hace un tiempo programo el 452, y no tuve nada de problemas; es más, estoy cambiando a los 18F despues de conocer este micro. No sabía que Microchip aconseja no usarlo... Es raro que un grabador del fabricante no funcione. Yo uso el que publiqué aqui, lo programo en ICSP, con el ICProg, y sin ningún tipo de problemas. Otra cosa rara es que se queme por haberlo dejado en alta impedancia; deberías fijarte bien si está quemado o no. Los 18F se programan distinto a los 16F, si el soft que usas no soporta la serie 18F, entonces no podrás programarlo. A lo mejor el soft de Microchip no está actualizado. Bueno, espero puedas solucionar tu problema. Saludos!
247
« en: Martes 6 de Septiembre de 2005, 01:09 »
Hi Boni! Los viejitos micros como el 16C54 se programan en paralelo. De ninguna manera podras hacer un adaptador para los programadores serie Yo los solia programar con el Picstart, de Microchip.... pero no creo que te convenga comprar uno. Tampoco conozco ningun soft que puedas descargar para programarlos. Deberias buscar a alguien que tenga algun programador viejito, o dejar a los micros que sigan descansando... Saludos
248
« en: Martes 6 de Septiembre de 2005, 01:03 »
Hola Boni! Puede que tu problema sea que no esta correctamente configurado el puerto A. El 876 posee conversor AD, usando para ello los pines de este puerto; por defecto estos pines estan asignados al conversor. Fijate que los registros del AD, creo que es el ADCON, este correctamente configurado. Creo que este tu problema Prueba, a ver que pasa... Saludos
249
« en: Miércoles 31 de Agosto de 2005, 16:29 »
Hola! No estoy del todo seguro, pero creo que el MI2C tiene la posibilidad de trabajar como maestro, en tanto que el I2C es solo esclavo. Lamentablemente en este momento no tengo ningún manual al alcance de la mano (estoy de vacaciones); pero podrían ver en algún manual de la serie 18F (todos soportan MI2C).
En cuanto a la comunicación serie (USART o cualquier variante), entregan niveles TTL. Los estandares RS232 o RS485 se consiguen por medio de integrados que adaptan los niveles de tensión. Para RS232 es muy bueno el MAX232, y para RS485 el TL75176. Con RS232 podemos hacer una comunicación punto a punto, p.e. micro - PC; con RS485 podemos "colgarnos" con más de dos modulos (no es compatible con el puerto serie del PC), en este caso es muy bueno un micro con AUSART.
Bueno, espero haber ayudado un poco.
Saludos!
250
« en: Jueves 18 de Agosto de 2005, 07:09 »
Hola! Gracias por la corrección; me había fijado en un manual de los 16F, pero para los 18F y los dsPIC son 100000 ciclos, y no 1000 Lo que podrías hacer es programar el PIC con las rutinas de control de, como tu dices, la agenda, el reloj, el control de juegos, grabador, etc, etc... Estas rutinas las dejas permanentemente en el micro; en una memoria externa, p.e. las populares y económicas memorias de multimedia (para camaras digitales, se consiguen en cualquier tienda del rubro, y de hasta 1 GB sin problemas ) En esta memoria cargas tu aplicación en particular, pero no como código para el PIC, sino te creas tu propio "set de instrucciones" ó "lenguage". Estas instrucciones las lee el PIC y actua según corresponda. Con esto puedes aprovechar más la memoria externa; además, rápidamente, cambiar sin problemas de aplicación (cambiar la memoria, reset, y listo...) Es algo asi como un PC y un diskette Bueno, es solo una idea... Espero que en una de esas te sirva y pueda ayudarte en algo! Tu proyecto es realmente bueno, y espero puedas llevarlo a la práctica! Saludos
Páginas: 1 ... 8 9 [10] 11 12 13
|
|
|
Mostrar Mensajes
