I would like to start a thread to gather some ideas about a feature on the roadmap:
Integrate a micro-controller software-based trace function, something like EE101 Insight-Pro. Could try to integrate with them if their software didn’t get such bad reviews. Sigrok? Or just in UI?
Add integration with hardware trace. Ideally, display a heat-map of energy usage and allow navigation by code module, function and line.
The basic idea is to have some kind of runtime C library running on the µC, inspired by the EE101.
It should be less intrusive than a debugger in terms of power and timings.
It should offer a way to report and trigger captures at certain points in the code.
In the long run, this could be extended to show more graphs, like IMU values, FIFO levels, etc…
As referenced by the roadmap, we are looking at features similar to the EE101 and Segger RTT/SystemView, including energy consumption.
Here are some of the possible uses-cases:
Energy consumption regression test for some signal processing or specific code section.
Measure the mean/min/max energy consumed by some functions, code sections or ISRs.
Energy consumed by one FreeRTOS/uCos3 task.
(Opt) Measure the execution time of the same task at different CPU frequencies.
(Opt) I want to see the level of my firmware FIFO’s and the effect on power consumption.
(Opt) My board does have multiple MEMS sensors and I want to see on the oscilloscope view which and when the MCU enables one.
Why not use a debugger with something like RTT?
The debugger causes a massive power consumption and sometimes prevents peripheral to go into deep-sleep modes.
I already have some idea about how this could be implemented, but I first want
to get some more infos from the community beforehand.
Feel free to discuss if you would like to see such a tool in your joulescope.
Did you feel the need to be able to trigger a capture from your DUV firmware?
Would a very light library for bare metal to trigger captures be acceptable? (Similar to EE101?)
What about a hook for RTOS?
Would you like to see an HDL entity/IP doing this capture (for FPGA related things?)
Would you rather see an integration with a debugger based trigger (RTT for example, with all debugger related issues?) instead of the lightweight library?
How many spare IO pins do you usually leave accessible on your projects? (Which could be used to communicate to the joulescope)
Should the joulescope be able to send commands to your DUV ? (UART serial like?)
Hi @JuliaTruchsess : What are the list of things that you would like the instrument and software to do on a trigger? For example, it could collect one RAM buffer (30 seconds by default) then stop.
Should work just like a 'scope - either single shot, as you describe, or repetitive. If the latter, it should restart the sweep if the trigger occurs before the current sweep has finished.
Hi There. I would plus1 for Julia.
Leave all the difficult software integration features for now. Just use what youu have in the Joulescope already. So, my list of suggestions.
Be able to trigger from each of the following three trigger (Start a recording) mechanisms.
The two digital inputs on JouleScope. ( I can trigger these from my firmware driving an IO pin)
A configureable current threshold.
Be able to set different recording parameters for each trigger type. Also different for each IO pin
Sample rate.
Fixed or not current scale.
Sample time duration. (Not only 30 seconds) Much shorter and much longer.
Re-trigger while sampling enable/disable
Different methods of stoping a sample trigger. (logging window.)
Time duration
Buffer Size
Current going under a (different than starting) threshold.
or some and / or function of the above.
Be able to re-trigger
If a sample set has run to completion. - re-trigger from any trigger methods
If enabled, For instance during a current level triggered sampling - be re-triggered from one of the IOs
Every Trigger is automatically saved in a sample file.
Setup for directory where sample files are stored.
Have a base name (part of trigger setup) with an incrementing counter appended for each sample
Have a JSON type header in each file that stores sampling setup parameters. Time at start of sample etc.
Maybe some basic parameters calculated for each file, like total enery. Maximums, average, Minimums. Etc But this can also be calculated afterwards with a python script. For instance a python script can be run on all the files of a certain base name to generate calculated statistics and store it as a .CSV text file.
I think the most important benefit of all this is being able to store define samples, on defined trigger events, with no operator involvement. And being able to let this runs for days at a time. Being able to look at the collected data without stopping Joulscope. This will enable gathering statistical data for an often occuring event that happens too fast to capture many of with manual operation. Or be able to look for that elusive event that occurs at indeterminate times and not very often.
I would love to see some sort of trigger functionality as well. For me this is the most missed feature in joulescope and the only reason why I still stick with my own home-brew solution most of the time.
In many cases I just want to see repeating signals like for example a BLE advertisement packet to calculate its duration and energy. So a repetitive power consumption based trigger which shows the latest occurence in a live capture would be perfect for me. Really like a regular Oscilloscope.
For this only joulescope_ui would need to be modified.
We have been working on architecting this feature and starting on the GUI. I have a very rough UI configuration widget that I would like to share which shows the trigger configuration options.
Is there a way to set the captured jls file name and destination folder?
And a way to automatically rearm the capture ?
I would maybe add a specific drop-down itemfor IN0/1 trrigger of the capture called “GPI”.
