Как только ставлю delay(1000) , NRF перестает работать - статус виден по светодиодам. Это же подтверждается со стороны RX.
IDE версии 1.0.5 r2
05 | const uint64_t pipe = 'ABCDEFG'; |
09 | RF24 ModuleToTest(49,53); |
16 | #define GR_LED 14 // Tx Ok |
17 | #define RED_LED 16 // Tx fail |
28 | ModuleToTest.setAutoAck(false); |
29 | ModuleToTest.setDataRate(RF24_1MBPS); |
30 | ModuleToTest.setCRCLength(RF24_CRC_16); |
31 | ModuleToTest.setChannel(66); |
32 | ModuleToTest.openWritingPipe(pipe); |
34 | pinMode(RED_LED, OUTPUT); |
35 | pinMode(GR_LED, OUTPUT); |
40 | switch(ModuleToTest.write(B_32bytes,32)) |
41 | { case false: digitalWrite(GR_LED,HIGH); digitalWrite(RED_LED,LOW); break; |
42 | case true: digitalWrite(RED_LED,HIGH); digitalWrite(GR_LED,LOW); break; |
44 | delay(1000); ///////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
Может быть delay() задействует те же прерывания и таймеры, что и библиотека для этого устройства? При delay() < 5 мсек проблема не проявляется.
?? делей - программавообще останавливается в микрконтроллере, а нрф шлет инфу.. и куда он шлет, на деревню дедушке?
1// ModuleToTest.setAutoAck(true);2ModuleToTest.setAutoAck(false);Поэтому для демонстрации ошибки не важно наличие-отсутствия приемника. В случае AutoAckn(false) считается, что доставлено в любом случае (tx_ok). Но если внести задержку между посылками больше чем delay(15), передача прекращается и включается красный LED "tx_fail".
IDE версии 1.0.5 r2
Может нечаянно сотворили импульный блок питания? Прочтите это: http://arduino.ru/forum/obshchii/lozhnoe-srabatyvanie-pir-datchika-pri-p...
Нет осциллографа, чтобы проверить напряжение питания
Помогите пожалуйста понять в каком направлении искать причину
Short Circuit вам указал направлении.
У вашей программы получается "окно" для приёма всего несколько микросекунд, во время проверки в switch. После этого секунду нечего не принимает, пока работает delay.
Копайте в сторону "Мигаем светодиодом без delay()".
Nosferatu, я не понимаю, можете объяснить мою ошибку попроще?
Приема (подтверждения ?) в программе не должно быть, так как отключено подтверждение передачи:
1//ModuleToTest.setAutoAck(true);2ModuleToTest.setAutoAck(false);// отключил прием подтвержденияА если не отключено, то прием подтверждения происходит во время выполнения
1ModuleToTest.write(B_32bytes,32);и время выполнения write при включенном приеме подтверждения немного больше, чем без подтверждения.
Мое сугубо дилетантсткое предположение, может быть дело в неправильной работе SPI и его сигналов CE и SS ?
По аналогиии с этим сообщением http://arduino.ru/forum/programmirovanie/s-kakim-obemom-rabotaet-bibliot...
Для Mega2560 стандартный SS=53, CE=не знаю какой. Для UNO см в таблице
Condensator, вы во внутрь либы RF24 загляните - при каких условия функция RF24.write() возвращает False? может станет понятнее
Заглянул, но ясности не прибавилось. https://github.com/maniacbug/RF24/issues . Проблема проявляется не только в том, что функция write возвращает false, но и приемник на второй ардуино перестает принимать пакеты.
RF24:write(const void *buf, uint8_t len) , на что влияет модификатор const для void *buf?
код функции RF24:write:
01/*02Copyright (C) 2011 J. Coliz <maniacbug@ymail.com>0304This program is free software; you can redistribute it and/or05modify it under the terms of the GNU General Public License06version 2 as published by the Free Software Foundation.07*/0809#include "nRF24L01.h"10#include "RF24_config.h"11#include "RF24.h"1213/******************************************************************/1415boolRF24::write(constvoid* buf, uint8_t len )16{17boolresult =false;1819// Begin the write20startWrite(buf,len);2122// ------------23// At this point we could return from a non-blocking write, and then call24// the rest after an interrupt2526// Instead, we are going to block here until we get TX_DS (transmission completed and ack'd)27// or MAX_RT (maximum retries, transmission failed). Also, we'll timeout in case the radio28// is flaky and we get neither.2930// IN the end, the send should be blocking. It comes back in 60ms worst case, or much faster31// if I tighted up the retry logic. (Default settings will be 1500us.32// Monitor the send33uint8_t observe_tx;34uint8_t status;35uint32_t sent_at = millis();36constuint32_t timeout = 500;//ms to wait for timeout37do38{39status = read_register(OBSERVE_TX,&observe_tx,1);40IF_SERIAL_DEBUG(Serial.print(observe_tx,HEX));41}42while( ! ( status & ( _BV(TX_DS) | _BV(MAX_RT) ) ) && ( millis() - sent_at < timeout ) );4344// The part above is what you could recreate with your own interrupt handler,45// and then call this when you got an interrupt46// ------------4748// Call this when you get an interrupt49// The status tells us three things50// * The send was successful (TX_DS)51// * The send failed, too many retries (MAX_RT)52// * There is an ack packet waiting (RX_DR)53booltx_ok, tx_fail;54whatHappened(tx_ok,tx_fail,ack_payload_available);5556//printf("%u%u%u\r\n",tx_ok,tx_fail,ack_payload_available);5758result = tx_ok;59IF_SERIAL_DEBUG(Serial.print(result?"...OK.":"...Failed"));6061// Handle the ack packet62if( ack_payload_available )63{64ack_payload_length = getDynamicPayloadSize();65IF_SERIAL_DEBUG(Serial.print("[AckPacket]/"));66IF_SERIAL_DEBUG(Serial.println(ack_payload_length,DEC));67}6869// Yay, we are done.7071// Power down72powerDown();7374// Flush buffers (Is this a relic of past experimentation, and not needed anymore??)75flush_tx();7677returnresult;78}79/****************************************************************************/Заглянул, но ясности не прибавилось.
тоже заглянул. Во-первых, может
IF_SERIAL_DEBUGвключить, чтобы увидеть какую-то диагностику? И во-вторых, что-то мне кажется. что то что вы отключили ask-пакеты - либа не отслеживает и все равно ждет ответа. Хотя могу ошибаться, смотрел мельком.Ради эксперимента можете добавить ModuleToTest.stopListening(); перед switch() (пишу с телефона, так что лучше могу ошибиться в написании), а если не поможет, то и startListening(...); после
Но цитата из описания классов библиотеки http://maniacbug.github.io/RF24/classRF24.html противоречит этому совету тк в тексте программы внутри switch используется write():
Pipe 0 is also used by the writing pipe. So if you open pipe 0 for reading, and then
startListening(), it will overwrite the writing pipe. Ergo, do an openWritingPipe() again before
write().
Перевод: Pipe 0 также используется как pipe для записи. Таким образом, если открываете pipe 0 для чтения, и затем startListening(), это перепишет pipe трубу для write. Следовательно, сделайте openWritingPipe() опять до write().
1voidloop(void)2{3switch(ModuleToTest.write(B_32bytes,32))4{casefalse: digitalWrite(GR_LED,HIGH); digitalWrite(RED_LED,LOW);break;5casetrue: digitalWrite(RED_LED,HIGH); digitalWrite(GR_LED,LOW);break;6}7delay(1000);//IF_SERIAL_DEBUGвключить, чтобы увидеть какую-то диагностику? И во-вторых, что-то мне кажется. что то что вы отключили ask-пакеты - либа не отслеживает и все равно ждет ответа. Хотя могу ошибаться, смотрел мельком.Я отключил подтверждение setAutoAck(false) (стр. 27,28 программы в сообщении 1) только в версии опубликованной на форуме, чтобы можно было тестировать программу одной картой NRF.
Если включить подтверждение при помощи setAutoAck(true), то понадобится вторая NRF в качестве приемника, но при этом возникает такая же ошибка и ее синхронно видно как со стороны TX, так и со стороны RX.
SERIAL_DEBUG попробую включить.
Не было возможности еще раз просмотреть даташит. И все равно, я бы посоветовал включить прослушку со всеми необходимыми настройками. У меня работает так и с delay и с millis.
Вы пробовали уменьшать/увеличивать значение delay?
При увеличении задержки в delay() от 15 и выше наблюдаются проблемы из-за которых и создана тема. Вместо delay() ставил длинные циклы операций с float для задержки и появляется эта же проблема.
Я не запаривался с чтением статусов вообще, только прием пакетов. Мой код отличается наличием listening и задержкой между пакетами в пару секунд. А еще ардуино спит 5 минут, в это время питание радио отключено. Соответсвенно после включения надо инициализировать заново. Может и Вам поможет.