Commit graph

14 commits

Author SHA1 Message Date
jgromes
01f1122823 [XBee] Added low-level access macro 2021-03-13 19:58:01 +01:00
jgromes
ffe1c38c1f [XBee] Fixed CodeQL alerts 2020-09-12 13:45:08 +02:00
jgromes
123b2f507f [XBee] Added Module overrides for all Arduino core functions 2020-08-01 16:35:00 +02:00
jgromes
29d24c916b [XBee] Added Doxygen TODOs 2020-07-10 08:51:37 +02:00
jgromes
0ee58ff770 [XBee] Updated line feed assignment 2020-07-05 10:02:11 +02:00
jgromes
57b46386e8 [XBee] Fixes from cppcheck scan 2020-07-04 15:03:26 +02:00
jgromes
78c1f94233 [XBee] Reworked driver exclusion 2020-06-30 10:44:33 +02:00
jgromes
305d880926 [Xbee] Lowered findChip delay to 10 ms 2020-05-01 20:52:59 +02:00
jgromes
eb71582a96 [XBee] Added missing calls to yield 2020-04-01 14:01:57 +02:00
Callan Bryant
6c99486343
Swap delayMicroseconds() to delay where appropriate
See https://github.com/jgromes/RadioLib/issues/126 for context.
2020-03-16 12:12:06 +00:00
Callan Bryant
c49323fa78
Prevent spurious resets on some boards
My receiver was failing to receive after a random amount of time (2 - 60
seconds). I discovered some power supply issues (DC-DC converter
related) that turned out to be another cause of the same problem but
only on some boards.

The reset procedure for most of the boards that RadioLib can drive
changes the pin mode of the reset line to an input after reset,
effectively tri-stating the output. I had seen this but dismissed it
after checking that the SX126x has a pullup on NRST meaning this was not
an issue.

The receiver I have produced uses a level converter to translate the 5v0
signals to 3v3. The level converters are not themselves pulled up or
down, which means when a pin is connected in a high-impedance input
state it will float around possibly randomly.

This can cause spurious resets on my board, and possibly others. I
remembered the reset procedure when I realised I could reproduce the
problem by rubbing the board on my shirt, probably causing some ESD to
trigger a change on the reset line.

This PR simply removes the lines that change the pinmode to input after
reset leaving it as an output which is hard-driven and the safest way. I
assume that the current behaviour was chosen to decrease the chance of a
conflict if used incorrectly.
2020-01-29 15:00:36 +00:00
jgromes
016fb0d462 [XBee] Added assert macro 2020-01-13 16:37:37 +01:00
jgromes
6f0496e06e [XBee] Changed pin mapping 2019-12-27 13:18:36 +01:00
jgromes
915f3780cc Reworked directory structure 2019-11-20 17:19:15 +01:00