Debugging with LMIC_X_DEBUG_PRINTF() #877
-
I'm interested in some of the LMIC_X_DEBUG_PRINTF() lines that are in the code, for instance here: Lines 1519 to 1531 in 8d378ea Contents of lmic_project_config.h:
I'm getting this error:
I tried out a few different values for LMIC_DEBUG_PRINTF_FN, sadly without success Can someone help me enable the LMIC_X_DEBUG_PRINTF() debug lines? I'm testing with a 328p in the Arduino IDE. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
I've only tested Remember that the debug-prints break timing. For this reason, unless you're debugging changes to the LMIC library, they're not useful-- if the LMIC's logic is correct, the only thing they'll do is break timing. Since they're focused on LMIC debugging, they generally don't give any useful info about integration problems. If you're using a release version of the LMIC and you're having problems, almost certainly it's an integration problem, or a known issue. In my experience, for general debugging and catching what's going on, it's much more useful to enable logging, and then do something to capture and display the logs as in the compliance sketch. As long as you don't dump the log buffer while the LMIC is busy, this approach is non-intrusive. |
Beta Was this translation helpful? Give feedback.
I've only tested
LMIC_X_DEBUG_PRINTF()
on Arm Cortex M0 ports, and non-Arduino C ports, where it was easy enough to provide aprintf()
-like function. As I recall, this is not easy to do with a 328p because there is not aprintf()
-like function you can use. I debug LMIC changes on ARM ports so I don't have to deal with size constraints.Remember that the debug-prints break timing. For this reason, unless you're debugging changes to the LMIC library, they're not useful-- if the LMIC's logic is correct, the only thing they'll do is break timing. Since they're focused on LMIC debugging, they generally don't give any useful info about integration problems. If you're using a release version of …