grafisoft escribió:Seria interesante hacerla compatible con los modulos nrf905?
Vale, si cabe no veo por qué no.
ebludt escribió:Para mi sería cojunudo. Y se hiciese para mega y el NRF905 estuviese en la parte que no taparía una motoshield ya sería la hostia en verso.
En principio sólo será para Arduino UNO, pero no hay problema para hacer un fork en un futuro.
ebludt escribió:Para mi sería cojunudo. Y se hiciese para mega y el NRF905 estuviese en la parte que no taparía una motoshield ya sería la hostia en verso.
Si se quiere mirar de hacer compatible con alguna placa en concreto, poner un enlace a la placa en cuestion.
Pasar de la shield para ardu UNO al mega, no tiene problema
Me quedo por aquí para aprender un poco de vosotros si no os importa!
Me parece una muy buena idea la shield
Un saludo!
Itead tiene por ejemplo para el arduino nano esta shield: http://imall.iteadstudio.com/development...17016.html
Para el Arduino UNO tiene esta shield: http://imall.iteadstudio.com/development...17004.html
pero no incorpora ninguno de los modulos que se han propuesto.
Seria interesante ver si se puede dejar la huella para pinchar el arduino nano, mini o micro por debajo en la shield del arduino uno.
grafisoft escribió:Pasar de la shield para ardu UNO al mega, no tiene problema
habría que diseñar una placa nueva, ya que los pines de SPI difieren para el NRF24L01
Si, habria que adaptar las conexiones, pero eso no tiene mayor misterio. La placa incluso es mas grande
Me he aventurado con un primer esquema hecho en Eagle, pero hay que consensuar donde irán los pines del NRF905 ya que tiene varios y no se cuales son necesarios para que funcione (¿Quizá siguiendo estas conexiones http://www.elechouse.com/elechouse/index...ts_id=2245 ?).
He puesto un diodo schottky en el pin D0 de la shield para evitar estropear los pines TX de los módulos serie cuando por despite se programe el Arduino sin desconectar la shield.
La resistencia y los condensadores tienen empaquetado SMD 1206.
Los diodos son normales, pero deben sustituirse por unos de empaquetado SMD SMB.
El regulador creo que es mejor y más barato usar un AMS1117-3.3
El regulador veo bien el que mencionas. Los pines necesarios del nrf905 los desconozco. Habra que mirar alguna libreria. Las antenas podria ser interesante que quedaran por fuera de la placa, por el tema de que alguna de estas puede ir con conector sma
me parece que no es necesario el regulador de 3.3 ya que la UNO proporciona 3.3 a un maximo de 50 mA
MonoPensante escribió:me parece que no es necesario el regulador de 3.3 ya que la UNO proporciona 3.3 a un maximo de 50 mA
Ten en cuenta que el ESP8266 puede llegar a consumir 240 mA., y el regulador de 3V3 de Arduino sólo es capaz de proporcionar 50 mA. que comentas.
MonoPensante escribió:me parece que no es necesario el regulador de 3.3 ya que la UNO proporciona 3.3 a un maximo de 50 mA
Se precisa regular la linea de alimentación de 3v3 porque el arduino da muy poca corriente (sobre 50mA), que es insuficiente para... diría que casi todos los módulos si se usan versiones de mayor potencia.
Los módulos comentados, algunos tienen versiones de poca potencia, y otras versiones con etapas amplificadoras. Xbee puede tener picos de mas de 200mA.
Pues tendremos que elegir un modulo en concreto, en las librerias siempre se pueden cambiar algunos pines.
En las del NRF24L01 si, pero en las tres que he encontrado del NRF905 ninguna
Primer caso, fichero NRF905.cpp, a pelo:
Código: NRF905::NRF905(void)
{
#if 1
/** Adjust pin definition */
TXEN=5;
TRX_CE=6;
PWR=A0;
CSN=4;
AM=7;
DR=3;
CD=2;
#else
TXEN=5;
TRX_CE=4;
PWR=3;
CSN=10;
AM=9;
DR=8;
CD=7;
#endif
}
Segundo caso, fichero nRF905_config.h, a pelo:
Código: #ifdef ARDUINO
// Arduino pins
#define TRX_EN 7 // Enable/standby pin
#define PWR_MODE 8 // Power mode pin
#define TX_EN 9 // TX / RX mode pin
#define CD 2 // Carrier detect pin (for collision avoidance, if enabled)
#define CSN 10 // SPI slave select pin
// Data ready pin
// If using interrupts (NRF905_INTERRUPTS 1) then this must be
// an external interrupt pin that matches the interrupt register settings below.
#define DR 3
Tercer caso, fichero NRF905.cpp, a pelo:
Código: NRF905::NRF905(void)
{
TXEN=5;
TRX_CE=4;
PWR=3;
CSN=10;
AM=9;
DR=8;
CD=7;
}
Eso se puede modificar, lo importante es el pinout del modulo de comunicacion. En el nrf24l01 hay 2 versiones, una de color negro y otra verde. La mejor es la de color negro, pero la verde tiene 10 pines.
Claro que se puede modificar, en el primer caso se podría añadir otro constructor a la clase para elegir los pines a nuestro gusto:
Código: NRF905::NRF905(int txen_p = 5 , int trx_ce_p = 4, int pwr_p = 3, int csn_p = 10, int am_p = 9, int dr_p = 8, int cd_p = 7)
{
TXEN = txen_p;
TRX_CE = trx_ce_p;
PWR = pwr_p;
CSN = csn_p;
AM = am_p;
DR = dr_p;
CD = cd_p;
}
El problema es que el usuario tendrá que modificar esa librería cada vez que se baje una nueva versión de esta. Y es un problema, a los hechos me remito, que yo recuerde ya ha pasado dos veces en Spainlabs:
-la primera con el autolevel de la Prusa http://spainlabs.com/foro/viewtopic.php?p=21731#p21731 el código ese ya no funcionaba en las últimas versiones y tuve que modificarlo http://spainlabs.com/foro/viewtopic.php?...100#p25972
-la segunda ha sido en la librería nrf24 para la Raspberry que ya conoces bien , en la página que te comenté http://www.akirasan.net/raspbpi-arduino-...-nrf24l01/ dice de poner import RPi.GPIO as GPIO en vez de import Adafruit_BBIO.GPIO as GPIO, pero en la versión más reciente ya no es necesario porque está puesto dentro del except ImportError: y que fue la que te puse y se arregló el problema que tenías.
Por eso lo de modificar la librería no lo veo, quizá sea mejor que spainlabs haga un fork de una de las anteriores en github y la mantengamos actualizada o bien pedimos al autor que nos incluya el constructor que he prpuesto al principio
Hacer el fork no es problema. O dejar documentado como van las conexiones.
He estado mirando esta placa que tiene un NRF24L01 y un NRF905 y sus conexiones de pines http://www.elechouse.com/elechouse/index...ts_id=2245
Sin embargo hay una cosa que no me queda clara, a ver si alguien ve por qué han hecho eso. Se supone que el pin CSN es el chip select del bus SPI (SS), es decir, cada módulo debe tener el suyo propio, en cambio el pin CE sólo indica al módulo que debe estar en modo envío o en modo recepción. Sin embargo veo que en esa shield que os comento han puesto el CSN en el NRF24L01 y NRF905 al pin 4 y el CE lo ha puesto en distintos pines (6 y 3 respectivamente). Para mi que es una chapuza lo que han hecho ya que tendría que ser al revés, el pin compartido para el CE y los pines distintos para el CSN, porque tal y como está no se pueden usar los dos módulos a la vez, ¿por qué han elegido usar uno a la vez en lugar de ambos al mismo tiempo que el bus spi lo permite? ¿se me escapa algo?.
Tiene pinta de ser fallo, porque el CSN, tendria que ser independiente.
He actualizado el diseño:
Cambios:
-nrf905. Los pines están configurados para la librería https://github.com/zkemble/nRF905 (Que es la más actualizada que he visto)
-nrf24l01. Los pines están configurados para la librería https://github.com/tmrh20/RF24 (Aunque hay que decir cuál es su pin CSN cuando se inicializa) He quitado el IRQ ya que el pin D2 y D3 se usan en el nrf905.
-Ahora los 3v3 se llaman VCC para que no hubiese problemas con la señal VCC del XBee.
-Resistencia del conversor de niveles cambiada a 220? para que se acerque lo más posible a los 3,3 V.
Nos quedan dos pines del Arduino libres (D4 y D5) ¿qué podemos hacer con ellos?
|