Salut, je teste le pilote xbee avec une carte arduino due.
Le pilote actuel pour xbee ne fonctionne pas avec la carte, le pilote s'arrête à la ligne 126 de xbee.c :
while (dev->resp_limit != dev->resp_count) {
mutex_lock(&(dev->resp_lock));
}
La même configuration et la même carte fonctionnent avec riot release 2015.09.
Peut-être que le problème vient du pilote uart, mais je pense que le pilote xbee doit avoir un délai d'attente. Parce que maintenant, riot est verrouillé et il n'enregistre aucune information pour détecter le problème.
Création du PR #4734.
Les commits suivants ajoutent des sorties de débogage supplémentaires.
https://github.com/Yonezawa-T2/RIOT/commit/0b437f440d114a28bbc63c3c6a7ff9dc4ded4bfd
https://github.com/Yonezawa-T2/RIOT/commit/c16cd9281821aaec8c9dd8260a3a98db659e8ef5
Réglez ENABLE_DEBUG
et XBEE_ENABLE_DETAILED_DEBUG
sur 1.
Vous pouvez également être intéressé par le #4445 si vous avez d'autres problèmes.
J'ai essayé le pilote avec l'arduino-due et il échoue toujours, mais je pense que c'est un problème d'uart.
Mais le pilote xbee ne fonctionne pas parfaitement :
xbee_init n'échoue pas si _api_at_cmd échoue, par exemple si _get_addr_long renvoie une valeur <0 xbee_init doit échouer, quelque chose comme :
if(_get_addr_long(dev, dev->addr_long.uint8, 8) < 0) {
DEBUG("xbee: Initialization failed\n");
return -1;
}
Enfin, ne consignez pas les informations de débogage "xbee: response timeout"
dans isr_resp_timeout mais déplacez-les dans _api_at_cmd, car dans le premier cas, elles s'exécutent dans un autre thread et ne peuvent pas toujours imprimer le débogage.
Création du PR #4749.
Bien, j'ai testé le nouveau pilote et il fonctionne comme je le souhaitais.
J'ai remarqué d'autres problèmes sur le pilote xbee, dans la fonction d'envoi :
dev->tx_buf[0] = API_START_DELIMITER; dev->tx_buf[4] = 0; /* set to zero to disable response frame */ /* set size, API id and address field depending on dst address length */ if (_is_broadcast(hdr)) { dev->tx_buf[1] = (uint8_t)((size + 5) >> 8); dev->tx_buf[2] = (uint8_t)(size + 5); dev->tx_buf[3] = API_ID_TX_SHORT_ADDR; dev->tx_buf[4] = 0xff; dev->tx_buf[5] = 0xff; } if (hdr->dst_l2addr_len == 2) { dev->tx_buf[1] = (uint8_t)((size + 5) >> 8); dev->tx_buf[2] = (uint8_t)(size + 5); dev->tx_buf[3] = API_ID_TX_SHORT_ADDR; memcpy(dev->tx_buf + 5, gnrc_netif_hdr_get_dst_addr(hdr), 2); pos = 7; } else { dev->tx_buf[1] = (uint8_t)((size + 11) >> 8); dev->tx_buf[2] = (uint8_t)(size + 11); dev->tx_buf[3] = API_ID_TX_LONG_ADDR; memcpy(dev->tx_buf + 5, gnrc_netif_hdr_get_dst_addr(hdr), 8); pos = 13; }
- en premier si : tx_buf[4] est écrasé, l'adresse courte de destination est aux index 5 et 6
- deuxième si peut-être ce serait
else if (hdr->dst_l2addr_len == 2)
Dernière question : destination longue adresse comment est-elle obtenue ? car avec mon xbee ça ne correspond pas.
@l3nko
J'ai remarqué d'autres problèmes sur le pilote xbee, dans la fonction d'envoi :
Oui. Voir #4445.Dernière question : destination longue adresse comment est-elle obtenue ? car avec mon xbee ça ne correspond pas.
Je ne suis pas sûr d'avoir bien compris votre question. XBee utilise l'adresse courte comme adresse source à moins que son adresse courte ne soit configurée sur 0xFFFF
. Cela a également été corrigé dans #4445.
Ce problème peut être fermé, car #4445 a été fusionné.
Commentaire le plus utile
Ce problème peut être fermé, car #4445 a été fusionné.