Enabling/Disabling the UART module via code?
- This topic has 6 replies, 2 voices, and was last updated 7 years, 8 months ago by Ajay K.
-
AuthorPosts
-
February 27, 2017 at 4:12 pm #17529Ajay KParticipant
I was wondering if there is a way to totally enable/disable the debug UART. Basically in production scenario, to shut off any debug printf statements flowing the USBTX and USBRX. I am aware of the LogLevel None option, but is it possible to completely disable the UART module, so we could save on further current consumption?
Thanks,
Ajay.February 27, 2017 at 5:14 pm #17530Mike FioreBlockedAjay,
There’s no way to disable the creation of the uart object in the Dot library. I don’t see why you couldn’t override that declaration if you’re sure you aren’t going to use the uart. You can create analog or digital objects with those pins and set them to a low current state or configure them like the example code does around sleeping to reduce current.
It’s up to you.
Cheers,
MikeFebruary 27, 2017 at 7:56 pm #17531Ajay KParticipantHi Mike,
Thanks for your inputs. I didn’t think I could configure USBTX and USBRX pins as AnalogIn/DigitalIn. My requirement is that one of the GPIO pins is connected to an FTDI chip and when they plug in the mini USB cable the GPIO pin goes high which indicates to me that UART needs to be used for logging purposes and when the mini USB cable is unplugged, then basically disable the UART or may be as you suggest, I can convert them to Digital In, pull down or Analog with no pull as in the sleep examples.
Do you have any concerns with this approach? Also, when the log level is set to NONE in the mdot library, other than blocking all logging, does it configure the UART in any way to prevent event any printf statements from being logged?
Thanks,
AjayFebruary 28, 2017 at 8:26 am #17536Mike FioreBlockedAjay,
Is this xDot on a custom board? If it’s on the DK, the USBTX/RX pins are also connected to a UART on the interface processor. I’d have to ask our HW guys if that would be an issue. If it’s on a custom board, you probably know better than I do if it would cause any problems or not.
The NONE log level is only for the MTSLog class. It will prevent any LogError, LogInfo, LogTrace, etc statements from printing out the debug port, but it will not prevent printf statements from printing out the UART.
Cheers,
MikeFebruary 28, 2017 at 11:21 am #17542Ajay KParticipantHi Mike,
Thanks for the clarifications regarding the logging level. No this is an mDot on a custom board. My only question can I treat the USBTX and USBRX as a GPIO pins? In which case I can toggle it as serial pins when needed and digital/Analog IO to save power consumption for the scenario i mentioned earlier. I will test it anyways but I was just wondering if you think this would be an issue configuring at run time as serial pins/as a GPIO pins depending on the mini usb cable is connected to it or not?
Thanks,
AjayFebruary 28, 2017 at 12:51 pm #17544Mike FioreBlockedAjay,
I think it would work fine. It would be good to make sure that no printf is called when the pins are configured as GPIO.
Cheers,
MikeFebruary 28, 2017 at 2:47 pm #17558Ajay KParticipantThanks Mike for getting back on this topic. I have changed all my logging to use the MDot logging API, so I can control the amount of information that will be logged during development and pre-production stages, but going into production it will be set at default of NONE, unless someone plugs a mini-usb cable.
Thanks,
Ajay -
AuthorPosts
- You must be logged in to reply to this topic.