Title: Debug Print re-enabled in OVI40?
Post by: w7dm on 15. February 2018, 16:43:30
On the UHSDR wiki, there is a section saying that Debug Print was disabled and no longer supported, and in older mcHF Group posts, it's explained that PA9 (Debug Print) was cannibalized for use in the Touch interface. I don't find any posts after that showing how a developer could reasonably hack in support on mcHF for Debug Print to facilitate in debugging and profiling.
Since the OVI40 uses a much more spacious pin count, and the Debug Print line appears connected in its schematic, can I expect the "Live Debuggging" section to be updated in a way that encourages developers to resume using live debug statements in OVI40?
https://github.com/df8oe/UHSDR/wiki/Setting-up-Firmware-Development-Software#live-debuggging
I have access to a Monsoon power monitor, and sometime after I get my OVI40 I would like to start doing some power profiling -- but this requires debug prints to manually couple power consumption to sections of code. From there, I can take measurements, put my findings on UHSDR GitHub, and look for areas that could be improved.
http://msoon.github.io/powermonitor/
73 de Jason W7DM |
Title: Re:Debug Print re-enabled in OVI40?
Post by: DF8OE on 15. February 2018, 16:47:57
A much, much better way for debugging than stupid printing is using a STLink for debug purposes. We highly recommend to use this for debugging.
vy 73
Andreas |
Title: Re:Debug Print re-enabled in OVI40?
Post by: df9ts on 15. February 2018, 17:30:07
Jason,
If you are interested to look in tooling then besides ST-Link - preferred here - also have a look at Segger's RTT approach. RTT does debug outputs on the one pin standard SWV interface, available in OVI40 and mcHF, for debugging. So it doesn't need an additional pin at all for debug output and works high speed. Requires J-Link Edu probe or similar.
https://www.segger.com/products/debug-probes/j-link/technology/real-time-transfer/about-real-time-transfer/
BR
Gerd.
|
Title: Re:Debug Print re-enabled in OVI40?
Post by: DB4PLE on 15. February 2018, 18:09:56
Hi,
while I know that the J-Link stuff is considered to be much cooler than the poor ST-Link, and absolutely everyone is free to debug with whatever tool he or she wants, in general we should focus on the ST-Link because of price of the real thing AND clones, the availability of additional tools e.g. to easily flash the processor and even option bytes (STM32 ST-Link utility) etc. Supporting multiple debug approaches takes simply more time from the actual development.
Having said this, there is a thing called semihosting supported by the ST-Link which uses the ST-Link to provide printf capabilities from the device to the host similar to the J-Link concept.
Main issue: All of these debug printf approaches have an unfortunate effect: They slow down execution massively so in many interesting places such a printf debug approach is not applicable. Whereas live debugging with ST-Link (or J-Link) makes it possible to stop the whole thing (even inside an interrupt handler), inspect everything and continue as if nothing has ever happend. Much, much more convenient and reliable and worked pretty well for me in the last 2 years when debugging the UHSDR firmware.
And for the printf die hards: Well, there is a screen on the mcHF/OVI40 I heard. But beware: Never ever use our screen writing functions inside any kind of interrupt triggered code as this can have desastrose side effects (the scrambled screen being only a minor annoyance here) since our display code does not support concurrent execution and its internal data structures may get corrupted if this rule is not being followed.
73
Danilo |
Title: Re:Debug Print re-enabled in OVI40?
Post by: w7dm on 15. February 2018, 21:27:06
Hi all, thanks for the replies. I am already using the knockoff WINGONEER branded ST-Link V2 adapter and can successfully flash, debug, set breakpoints, and read variables in scope directly in Eclipse+OpenOCD.
https://www.amazon.com/dp/B012VR3PVA
But I am asking specifically about debug printouts of live datapoints while executing, without stopping the debugger, that I can log to a file and review later. Primarily of the profiling kind that announce enter/exit of sections of code. Does this capability exist using ST-Link without using the Debug Print line?
73 de Jason W7DM
|
Title: Re:Debug Print re-enabled in OVI40?
Post by: DB4PLE on 16. February 2018, 07:42:26
Hi Jason,
But I am asking specifically about debug printouts of live datapoints while executing, without stopping the debugger, that I can log to a file and review later. Primarily of the profiling kind that announce enter/exit of sections of code. Does this capability exist using ST-Link without using the Debug Print line?
|
|
That is what semihosting is for, it allows you to write data to files on the debug host (or to a console). But it is terrible slow, at least from my experience. Especially if this is related to your interest in improving the beep generation and measuring times, it is absolutely unusable to be used directly in the interrupt code.
What we have built into UHSDR firmware is profiling support, see misc/profiling.h, it uses the MCU integrated debug clock cycle counters to measure how long certain things take. If used right, it gives you execution times for code pieces with a resolution of 168Mhz.
To read the accumulated measurement data, I basically look into the data structure with the ST-Link but here you could use things like semihosting to printout the data from time to time on the host console. We used that a while ago, currently code for printing out via semihosting is disabled but you'll get the idea how to use all of that.
The working example for that stuff is btw, the infamous L ..% indicator, which tells you how much time we spend inside the audio interrupt. BTW, you turn on the display of this value by enabling the "Debug Info" in the debug and experts menu.
73
Danilo
|
Title: Re:Debug Print re-enabled in OVI40?
Post by: w7dm on 17. February 2018, 06:46:15
Thanks Danilo for the information about enabling semihosting. It seems that is a non-starter. Same goes for the profiling code. The reason is that for power profiling purposes, I am not interested in the execution time, but instead in the power consumed by a given scope of code being executed, and I need to match up entry/exit of multiple code blocks using timestamps that I later align to my power monitor's captured measurements. This won't be possible with a screen indicator, and I suspect enabling semihosting would massively interfere with "normal" power consumption measurements if it is slowing down the processor all the time.
Maybe this will have to wait until we have ability to write data to a file for retrieval later. It'd be a simple annotation printed out, just "Timestamp XXXXXXXX enter function foo::bar", "Timestamp XXXXXXXX exit function foo::bar", or even just a unique ID and a timestamp, or unique ID and system clock, whatever is fast and could be converted back into an approximate timestamp log later. Flag only entry/exit for the highest level routines to start, find the ones that unexpectedly eat a lot of power compared to the value they provide. Start annotating further and further down into their functions until we start turning up sections that eat more power than we would expect ("expect" is arguable and an art of sorts).
I would most likely use Google's GitHub project battery-historian, which is trivial to repurpose for non-Android profiling and accepts Monsoon logs. It makes hunting for power hogs easy. Check out the first screenshot on the project page.
https://github.com/google/battery-historian
73 de Jason W7DM
|
Title: Re:Debug Print re-enabled in OVI40?
Post by: DB4PLE on 17. February 2018, 08:44:08
Hi,
for linking an external measurement, like an oscilloscope, you can use the LED on/off code and use that signal to know when something happens. But given the number of leds, you cannot distinguish many diffent situations with that approach.
But I have to tell you some very unfortunate news: The UHSDR firmware is by its design without power management and always uses 100% of the processor cycles, not matter what. You cannot compare our software architecture in UHSDR with the multicore architectures with dynamic clock scaling found in modern smartphones.
Although I assume that certain MCU operations (possibly FPU operations) will cause a slightly higher power consumption than others, I doubt there is too much variation visible. Use a current measurement shunt in the MCU powersupply bath and an oscilloscope to track power consumption is relatively easy and you'll see it how much or how little variation there is in current consumption over time.
So, from my point of knowledge, local code optimization will not significantly change power consumption as long as we keep the 100% dutycycle approach. If you want to know what I am talking about: Checkout UiDriver_TaskHandler_MainTask(). This function is executed in an infinite loop and makes the MCU eat all cycles left over from interrupt handling.
BTW, I am not saying there is no way to save power, but the very start would be to make the software architecture "power management ready" which is quite an task. Very fascinating on but also very demanding.
73
Danilo |
Title: Re:Debug Print re-enabled in OVI40?
Post by: SP9BSL on 26. February 2018, 20:42:44
Hi,
there is nice feature from ST which I use sometimes when I need some "realtime" data without using peripherials or semihosting, it's STMstudio. Take look here for more information:
http://www.st.com/en/development-tools/stm-studio-stm32.html
It uses ".elf" file to import variables from the last build and ST-Link interface. One remark: some variables are "hidden" due to optimization we use, so sometimes there is little more effort needed to redeclare it as "volatile" temporarily. |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|