|
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 - © Jonathan ©
Páginas: 1 ... 33 34 [35] 36 37 ... 65
851
« en: Miércoles 19 de Enero de 2005, 06:05 »
Hola rAm0n23, estuve buscandote algo de info, no entiendo el basic, prefiero el ASM o el C, encontre la siguiente info navegando por google. Espero te sea util. Saludos  PD: No toy seguro de que sea Basic, pero miralo tu que lo conoces http://www.melabs.com/resources/samples/submitted/MN1307.txt
852
« en: Lunes 17 de Enero de 2005, 13:57 »
Muy buenos screen shots, habria que investigar, seguramente existe algun software para lo que necesitas, lo raro es que solo triviales, eso llama la atencion, y por cierto, no tienen apariencias de diapositivas  . Buscare info al respecto veo que logro encontrar, si encuentro algo interesante te paso el dato. Saludos!
853
« en: Lunes 17 de Enero de 2005, 02:44 »
Muy interesante, la verdad no lo conocia... ahora una opinion, no creo que haya un lenguaje o compilador para programar aplicaciones de ese tipo, o talves si  . De ser asi, vendrian con juegos de carreras, futbol y otras cositas  ... ese trivial se podria hacer en el pc y luego grabarlo en el DVD.. debe venir algo, estilo powerpoint para hacer las diapositivas y que al presionar en el mando a distancia el boton >> (avance) envie la diapositiva siguiente, que en el caso de un trivial contendra la respuesta. No se me ocurre nada mas  . Seria cuestion de investigar si hay programas para compaginar videos para DVD  . Si encuentro algo similar te paso el comentario. Saludos!
854
« en: Lunes 17 de Enero de 2005, 02:32 »
Holas, recomendable seria que uses un transistor para activar el relay, es simple y te asegura que siempre funcionara. chequeate los links puestos mas arriba, ante dudas consulta. Saludos!
855
« en: Sábado 15 de Enero de 2005, 04:31 »
No entiendo a que te refieres cuando mensionas "aplicaciones para grabar en DVD y luego poder ejecutarlas en el e interactuar con el mando a distancia" ... aun le busco respuesta, pero no entiendo a que ! . Podrias aclararme algunas dudas?. Saludos
856
« en: Jueves 13 de Enero de 2005, 23:46 »
Holas, la idea es buena, pero de seguro debe haber traba... nos alcanzaran los pines del LPT?? .. es raro que los programadores necesiten de otro micro para quemar un simple 89C51... el unico que encontre que no requiere de otro atmel es uno que necesita 6 integrados. Con respecto a la idea de realizar un programador, no tengo problemas, solo seria bueno que sean varios los usuarios que se agreguen al proyecto, veamos si hay mas interesados, si se agregan algunos mas seria mas facil... pruebo el programador que publique en el post de links y te comento. Talves no sea necesario hacer uno desde cero, ya sabes, el tiempo es muy valioso y se debe invertir en lo que nos sea util en un futuro. Saludos y Suertes!
857
« en: Jueves 13 de Enero de 2005, 11:45 »
Diodo, la entrevista esta muy buena..jejej .. y el post de patitofeo si que esta claro  .. muy bueno todo.. que polemica!!
859
« en: Martes 11 de Enero de 2005, 01:23 »
reptil, interesante la prueba que realizaras, espero los resultados... te cuento que aparentemente con el manchester se solucionan varios conflictos, no he terminado mis codigos aun, porque estoy con otras cosas, pero colegas lo han probado y con muy buenos resultados, solo me queda comprobarlo y confirmar que es cierto. Huguen_aus_Tirol, un millon de gracias por los links... en verdad que hay info, esa pagina alemana si que es buena  ... busque sobre el programador que mensionas y si necesita un micro ATMEL para funcionar... encontre el programador APOLO para la serie de microcontroladores AVR, es mas simple que el programador para el 89C51... estoy buscando algo similar, pero no logro dar con la tecla... Muchas gracias por la info, si deseas y tienes tiempo, coloca la lista de links en el foro atmel. Te estare agradecido. Saludos y Suerte!
860
« en: Lunes 10 de Enero de 2005, 05:47 »
En realidad no estoy seguro, creo que es en segundos, es que uso delay... probare, pense que sleep era como delay, disculpa si no era como te respondi .. Saludos!
861
« en: Sábado 8 de Enero de 2005, 22:07 »
HOlas, utiliza 'Sleep(x)' donde x es el tiempo en ms. Saludos
862
« en: Sábado 8 de Enero de 2005, 05:12 »
863
« en: Sábado 8 de Enero de 2005, 04:57 »
Gracias, lo bajare cuanto antes... si encuentro algo para ayudarte en disminuir interferencias te paso el dato, por el momento solo busco. Saludos!
864
« en: Sábado 8 de Enero de 2005, 00:28 »
jonothan por aqui tenemos un prototipo de programador , las pruebas dicen que si funciona pero parece perdido el esquematico voy a darme tiempo para hacerlo y enviartelo
Las Gracias Antisipadas.!  El limite para archivos adjuntos es de 128k ... si no puedes subirlo al FTP enviamelo a mi correo .. lo encuentras en el Perfil. Saludos y Suerte!
865
« en: Sábado 8 de Enero de 2005, 00:04 »
Holas a todos, como seguro habran leido en el foro novedades, Solocodigo dispone de un FTP donde se pueden colgar archivos sin importar su tamaño, pueden ver como accesar y subir archivos en el siguiente link: http://foros.solocodigo.com/index.php?showtopic=12696 He creado una carpeta llamada Microcontroladores donde te invito a que subas archivos los cuales creas utiles para el trabajo con PICs. Para ver el contenido actual y descargar lo que te interese, puedes accesar mediante el siguiente link: FTP Microcontroladores PIC Saludos!
866
« en: Viernes 7 de Enero de 2005, 23:49 »
Holas, los modulos que utilizo son linpac en 868Mhz .. intento implementar el manchester en el mismo micro, pero si tienes a mano el datashee te lo encargo... no se si sabes, pero en el foro hay un FTP para colgar archivos... en el foro de noticias esta el como accesar... fabrique una carpeta denominada Microcontroladores... ahi puedes colgar todo lo que creas que es interesante.. intenta siempre de que sean menos de 15 Mg.. si puedes accesar y colgarlo en el FTP te estare agradecido, sino, enviamelo por mail y me encargo del resto. Estoy investigando por programadores para el 89C51 .. los AVR se programan mas facil, este necesita de un micro aparte para quemarlo y eso es un problema. Saludos y hasta la proxima!
867
« en: Viernes 7 de Enero de 2005, 21:08 »
868
« en: Viernes 7 de Enero de 2005, 06:59 »
Seria util que habiliten en el FTP la posibilidad de crear carpetas. Intente crear una de microcontroladores para colgar algunas rutinas utiles y dejar el acceso en el foro correspondiente, pero no logre crearla. Admin, podrias crearme una Carpeta llamada Microcontroladores.. Gracias y Saludos!
869
« en: Viernes 7 de Enero de 2005, 06:31 »
Hola a todos, este post es para contarles de una experiencia algo traumatica. Seguro conoceran la famosa directiva DT, la cual es muy utilizada para crear tablas en una sola linea. Esta directiva trae un grave inconveniente, un error que no es visto por Mplab. El error solo aparece si acostumbras a colocar las tablas al inicio del programa, despues del org 5 y antes de cualquier otro banco... mi experiencia fue en un codigo en el cual coloco 3 tablas entre org 5 y org 100 en formato utilizando el DT para ahorrar lineas, las tablas constan de 84 bytes cada una, por lo que entre el org 5 y org 100 solo entrarian 2 y media, para mi sorpresa, usando el DT, puedo colocar las 3 sin problemas y sin aviso de escritura en espacio ya utilizado. Al intentar colocar esas mismas tablas pero reemplazando la directiva DT por el acostumbrado RETLW, Mplab me arroja el siguiente error: Error[118] D:\LCD\PROGRAMA\ICONO.ASM 319 : Overwriting previous address contents (0100) Error[118] D:\LCD\PROGRAMA\ICONO.ASM 319 : Overwriting previous address contents (0100)
Como es posible que Mplab no vea el error usando la directiva DT???... esta directiva no fue hecha para reemplazar el inmenso trabajo al crear tablas en varias lineas??, me costo bastante encontrar la falla, ya que mirando el archivo .lst todo parecia normal. Espero les sea util la experiencia, si tienes alguna interesante para contarnos, bienvenida sea. Gracias por leerme y hasta pronto!
870
« en: Jueves 6 de Enero de 2005, 21:29 »
Bienvenidos al foro de Microcontroladore Atmel. Para los que esten interesados en iniciarse en el mundo Atmel, dejo un minicurso de iniciacion, no es un super manual, es informacion recolectada de internet la cual estoy ordenando para facilitarme el aprender en el mundo de estos microcontroladores. El manual esta en documento de word y no es muy completo, si encuentras informacion para añadirle, modificalo y subelo al foro, te estare inmensamente agradecido. No es mucha la informacion que se encuentra en español, por eso pido a todos los que puedan aportar, que no duden en corregirme, y desde el corazon me den una mano en mi iniciacion con esta serie de Microcontroladores. Lo que vaya aprendiendo sera colgado en este foro, si encuentras algo interesante, no dudes en colgarlo tambien. Me despido Atte. y espero participen. Saludos!
871
« en: Jueves 6 de Enero de 2005, 07:15 »
Disculpame el extenso mensaje, sinceramente no conosco si existe algun integrado que haga la codificacion y decodificacion manchester, por eso estoy implementandola en el mismo micro, esa era la explicacion de como trabaja y como hacerlo. El proyecto que llevo a cabo es algo raro, por el momento debo comunicar dos pic por RF a buena velocidad, e ir aumentado la velocidad al maximo, necesito que la comunicacion sea ligera, pero es afectada por el ruido  .. en fin, tenemos los dos el mismo problema  . En el mensaje anterior mencionas que trabajas con el AT89C51, necesitaria saber que tipo de programador usas para el micro, es fabricado casero?.. hace bastante que programar uno que tengo aqui y no encuentro un programador de facil armado y que no requiera otro micro para quemar el 89C51. Si tienes el esquema te lo encargo, me seria ampliamente util. Lamento no tener los conimientos para dar solucion a tu problema, por aqui sufro en lo mismo, si encuentro solucion seras el primero en adquirirla. Un abrazo
872
« en: Miércoles 5 de Enero de 2005, 21:09 »
No se realmente a que te refieres, ya que el codigo manchester es una forma especial de "codificar" los datos de tal modo que el nivel medio de tension en la transmision sea de cero voltios, en el caso de una transmision simetrica en la cual los ceros y unos sean representados por p.ej. por +10v y -10v como pueda ser una transmission RS232, o bien de v/2 en al caso de que la transmision se realice entre 0v y v, sea v la tension que sea. Esa tecnica se usa en los casos que es necesario mantener una tension media, tal y como se ha indicado antes, de ((+v)+(-v))/2. Un ejemplo claro son los modulos de transmision de datos por RF. Estos modulos disponen de un sistemas de control automatico de ganancia en la recepcion que a medio y largo plazo pueden verse afectados por la preponderancia de unos o ceros. Si por ejemplo enviamos una serie de bytes como: 11110110 10111010 01101111 00111110 se ve que hay un preponderancia de unos y al aplicar un sistema de control de ganancia automatico a esta cadena de ceros y unos ( el control de ganancia se realiza simplemente alimentando un filtro pasobajo a estos datos, es decir una resistencia serie y un condensador a masa, para obtener una tension continua proporcional a la señal y con esta tension como referencia se controla el amplificador del control de ganancia ) se tendera a bajar el nivel de ganancia, si se diera el caso contrario en que hubiese una preponderancia de ceros se elevaria la ganancia.... Esto es malo? Pues si ya que si tenemos una cadena en la que preponderan los ceros y sube la ganancia y a continuacion llega una cadena en la que preponderan los unos el discriminador de recepcion podria llegar a saturarse o en caso contrario a confundir ruido de fondo con datos. Para evitar esto se transmiten cadenas de datos en las que el promedio de unos y ceros debe tender al 50% Si no es muy critico el sistema podemos ocuparnos de codificar unicamente los datos y dejar los bits de inicio y stop a su aire ( estoy pensando por ejemplo en una transmision RS-232 a traves de Rf o bien de fibra optica ) ya que estos en una transmision de 8 bits sin paridad y un bit de stop casi casi que se compensan entre si. Habitualmente y en su forma mas sencilla se realiza substituyendo los "1" por el par "01" y los "0" por el par "10". por ejemplo si hemos de codificar el byte 11010111 lo transformariamos en 01 01 10 01 10 01 01 01 es decir en 01011001 10010101 que como podemos comprobar si tiene el mismo numero de ceros que de unos. El efecto de este tipo de codificacion es que multiplica por dos la cantidad de informacion a enviar, por otro lado los procesos de codificacion y decodificacion son muy sencillos. Existen sistemas mas complicados en los que no solo se consigue el mantener al 50% los unos y ceros sino que ademas se consigue reducir la cantidad de datos ( tecnologia empleada por ejemplo en la grabacion de los datos en los discos duros ). creo que como introcuccion esta bien, si quieres mas datos al respecto con una sencilla busqueda en google o yahoo encontraras un monton de informacion muy profunda. Espero me hayas entendido, si necesitas un codigo en asm para decodificar datos en manchester te lo adjunto. El de Codificacion aun esta en proceso de construccion, aunque no me creas, tambien tengo problemas con la RF  ... Saludos y mucha Suerte!
873
« en: Miércoles 5 de Enero de 2005, 20:56 »
No Puedo creer que todo eso sea gratuito  .... es sorprendente.. ya me registre mi dominio. Probare el servicio, es probable que pasado un tiempo comiencen a cobrar :S .. pero bueno, si es bueno veremos que se hace. Saludos!
874
« en: Miércoles 5 de Enero de 2005, 05:40 »
Aqui te dejo los esquemas del reset y el oscilador para trabajar en modo HS o XT .. es como trabajo yo .. Bajare el codigo y mirare, no tengo mucha experiencia con el C, le hago mas bien al ASM.. pero veo que puedo hacer. Un Abrazo!
875
« en: Domingo 2 de Enero de 2005, 23:42 »
Yo te propongo que utilices la transmision usando el codigo MANCHESTER.. es para igualar la cantidad de ceros y unos, esto haria que la transmision contenga menos errores... con respecto a que el dato llega erroneo, todo debe ser por las interferencias, imagina, cualquier minimo error en los datos modifica todo en grande. Saludos
Páginas: 1 ... 33 34 [35] 36 37 ... 65
|
|
|