Как только ставлю 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);
2
ModuleToTest.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);
2
ModuleToTest.setAutoAck(
false
);
// отключил прием подтверждения
А если не отключено, то прием подтверждения происходит во время выполнения
1
ModuleToTest.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
/*
02
Copyright (C) 2011 J. Coliz <maniacbug@ymail.com>
03
04
This program is free software; you can redistribute it and/or
05
modify it under the terms of the GNU General Public License
06
version 2 as published by the Free Software Foundation.
07
*/
08
09
#include "nRF24L01.h"
10
#include "RF24_config.h"
11
#include "RF24.h"
12
13
/******************************************************************/
14
15
bool
RF24::write(
const
void
* buf, uint8_t len )
16
{
17
bool
result =
false
;
18
19
// Begin the write
20
startWrite(buf,len);
21
22
// ------------
23
// At this point we could return from a non-blocking write, and then call
24
// the rest after an interrupt
25
26
// 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 radio
28
// is flaky and we get neither.
29
30
// IN the end, the send should be blocking. It comes back in 60ms worst case, or much faster
31
// if I tighted up the retry logic. (Default settings will be 1500us.
32
// Monitor the send
33
uint8_t observe_tx;
34
uint8_t status;
35
uint32_t sent_at = millis();
36
const
uint32_t timeout = 500;
//ms to wait for timeout
37
do
38
{
39
status = read_register(OBSERVE_TX,&observe_tx,1);
40
IF_SERIAL_DEBUG(
Serial
.print(observe_tx,HEX));
41
}
42
while
( ! ( status & ( _BV(TX_DS) | _BV(MAX_RT) ) ) && ( millis() - sent_at < timeout ) );
43
44
// The part above is what you could recreate with your own interrupt handler,
45
// and then call this when you got an interrupt
46
// ------------
47
48
// Call this when you get an interrupt
49
// The status tells us three things
50
// * The send was successful (TX_DS)
51
// * The send failed, too many retries (MAX_RT)
52
// * There is an ack packet waiting (RX_DR)
53
bool
tx_ok, tx_fail;
54
whatHappened(tx_ok,tx_fail,ack_payload_available);
55
56
//printf("%u%u%u\r\n",tx_ok,tx_fail,ack_payload_available);
57
58
result = tx_ok;
59
IF_SERIAL_DEBUG(
Serial
.print(result?
"...OK."
:
"...Failed"
));
60
61
// Handle the ack packet
62
if
( ack_payload_available )
63
{
64
ack_payload_length = getDynamicPayloadSize();
65
IF_SERIAL_DEBUG(
Serial
.print(
"[AckPacket]/"
));
66
IF_SERIAL_DEBUG(
Serial
.println(ack_payload_length,DEC));
67
}
68
69
// Yay, we are done.
70
71
// Power down
72
powerDown();
73
74
// Flush buffers (Is this a relic of past experimentation, and not needed anymore??)
75
flush_tx();
76
77
return
result;
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().
1
void
loop
(
void
)
2
{
3
switch
(ModuleToTest.write(B_32bytes,32))
4
{
case
false
: digitalWrite(GR_LED,HIGH); digitalWrite(RED_LED,LOW);
break
;
5
case
true
: digitalWrite(RED_LED,HIGH); digitalWrite(GR_LED,LOW);
break
;
6
}
7
delay(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 минут, в это время питание радио отключено. Соответсвенно после включения надо инициализировать заново. Может и Вам поможет.