Los sensores lo puedes conectar como quieras. En un mismo Air pueden ir varios sensores
Posible uso de un SL-Air: Si se precisan tomar medidas de tensiones o corrientes con una tasa no muy alta de muestreo, podria tenerse como un tester remoto.
Me acaban de confirmar el envio de los samples del 876, si necesitas cuando me llegen me comentas y te los mando grafi
Enviado desde mi Nexus 4 mediante Tapatalk
Na tranquilo, que con esto llevamos mas de un mes y ya tenemos todos samples :p
Gracias.
He estado echando un ojo a los programadores que pusiste en el otro post, los dos programadores para familias que no tienen USB nativo son serie por lo que parece, lo que limita bastante. Las otras dos versiones, son pics con bootloader, lo que no es una mala opcion, pero ya te tienes que ir a otros pics que no son el 876. La mayoria de programadores especificos de familias, que son sencillos, parece que funciona por puerto serie.
Hablo de los que son usb. Los de puerto serie ni me los planteo.
Ummm, me surge una duda, si la grabacion de los arduino es por comunicacion serie UART, no se podria conseguir algun bootloader para el 876 e implementar un programador sencillito, al estilo chip FTDI del arduino? sin tener que cambiar el modelo de PIC.
Si bien es cierto, que con la implementacion de bootloaders, en parte limitas el micro.
Hay algo para rs232, con ftid.... no lo se. No habria problema en cambiar de micro de ese tamaño, tenemos el 18f2550 con usb nativo
Triggerr escribió:Ummm, me surge una duda, si la grabacion de los arduino es por comunicacion serie UART, no se podria conseguir algun bootloader para el 876 e implementar un programador sencillito, al estilo chip FTDI del arduino? sin tener que cambiar el modelo de PIC.
Si bien es cierto, que con la implementacion de bootloaders, en parte limitas el micro.
FTDI son muy puñeteros con las muestras: hay que pedirlos por correo, presentar un proyecto redactado en 1 página, etc.
Un sustituto puede ser MCP2200 de Microchip (lo malo es que los encapsulados más grandes son SOIC/SSOP).
http://ww1.microchip.com/downloads/en/De...22228B.pdf
ark escribió:Triggerr escribió:Ummm, me surge una duda, si la grabacion de los arduino es por comunicacion serie UART, no se podria conseguir algun bootloader para el 876 e implementar un programador sencillito, al estilo chip FTDI del arduino? sin tener que cambiar el modelo de PIC.
Si bien es cierto, que con la implementacion de bootloaders, en parte limitas el micro.
FTDI son muy puñeteros con las muestras: hay que pedirlos por correo, presentar un proyecto redactado en 1 página, etc.
Un sustituto puede ser MCP2200 de Microchip (lo malo es que los encapsulados más grandes son SOIC/SSOP).
http://ww1.microchip.com/downloads/en/De...22228B.pdf
Pedidas muestras del MCP2200 y MCP2210 (este ultimo es usb-SPI) en SOIC 300 mil
Maxim antes suministraba muestras a España, sabeis si han dejado de hacerlo? No me deja completar la orden. Pensaba pedir unos sensores de temperatura y probarlos, y algun potenciometro digital, que podrian resultar interesantes para futuros shields o incorporaciones al proyecto
Lo de las muestras... poca gente da ya, las grandes empresas y poco mas
grafisoft escribió:Lo de las muestras... poca gente da ya, las grandes empresas y poco mas
Cierto es, revisare las condiciones de MAXIM, aver si dicen algo del envio a españa o algo hice mal
Tambien te puedes encontrar, que alguna no envia a ciertos paises. No seria raro. No todas envian a todos los sitios
Si alguien se adentra en la version de arduino, en este enlace hay info al final de el: http://openhardware.pe/transceptores-nrf...ss-how-to/
http://arduino-info.wikispaces.com/Nrf24...4GHz-HowTo
Aqui tambien hay info del mismo.
Tanto para PIC como ARDUINO, seria interesante obtener un buen protocolo de comunicacion y unos buenos consumos. Esto como mejor se consigue es empleando la patilla IRQ del NRF a base de interrupciones. Pero yo no consegui hacerlo funcionar...., todo seria ponerse a ello, en mi caso no podia usar interrupciones porque no tenia patas libres. Tampoco he entendido muy bien como va el buffer del transmisor, ya que parece ser que a no ser que estes leyendo en ese momento no te guarda los datos recibidos en un buffer....nose, hay que estudiarlo con detenimiento.
Tu sacaste algo en claro grafi?
No se los consumos de arduino, y en el de pic, tengo que hacer algunas medidas. En pic si que controlamos el nrf por interrupciones, la libreria que hay es relativamente facil.
El buffer del modulo son 8 bytes, asi que tienes que hacerte tu un buffer y pasarselo al modulo en bloques de 8. La comunicacion entre ardu y pic es cuestion de definir el frame y listo, o ni eso, segun cuanta info se mande.
Y como dices, hay que atender a los datos recibidos porque sino se pierden.
grafisoft escribió:No se los consumos de arduino, y en el de pic, tengo que hacer algunas medidas. En pic si que controlamos el nrf por interrupciones, la libreria que hay es relativamente facil.
El buffer del modulo son 8 bytes, asi que tienes que hacerte tu un buffer y pasarselo al modulo en bloques de 8. La comunicacion entre ardu y pic es cuestion de definir el frame y listo, o ni eso, segun cuanta info se mande.
Y como dices, hay que atender a los datos recibidos porque sino se pierden.
El buffer de este modulo nunca he llegado a comprender cono funciona, porque entonces no tiene nada que ver con el payload que envias que el maximo es de 32bytes
Enviado desde mi Nexus 4 mediante Tapatalk
No. Realmente la parte accesible de eso que comentas en la que meter info es 8 bytes, el resto es para el tema de comunicarse entre ellos.
La distribucion de la transmision es la siguiente:
Enviado desde mi Nexus 4 mediante Tapatalk
|