I'm looking to develop an ultrasonic time-of-flight (ToF) sensor and have been looking at high speed timing circuits. Many versions use the TDC7200, but ST offers the STM32F334 which has a high-resolution timer with apparent 217ps resolution.
What I'm wondering whether this timer can actually be used to measure time with 217ps between each count value (assuming it's run at maximum clock rate)?
Does anyone have experience using this microcontroller's high-resolution timer like this?
According to the reference manual it should be possible:
High-Resolution Timer (HRTIM) : For control and monitoring purposes, the timer has also timing measure capabilities and links to built-in ADC and DAC converters. Last, it features light-load management mode and
is able to handle various fault schemes for safe shut-down purposes. --page 626
The timing unit has the capability to capture the counter value, triggered by internal and
external events. The purpose is to:
• measure events arrival timings or occurrence intervals --page 641
Related
I am trying to measure power usage using dds353 kWh meter. This meter has a pulse output. I am interested in using the esp32 since I can periodically send the data over the internet to nodered dashboard.I am also very interested in using the esp32 in low power mode and periodically wake up to send data over mqtt. I have tried out examples from github using espressif idf but I would not mind an arduino equivalent. I would like to do hardware interrupt which when one of the rtc gpio pin goes high a counter is incremented while a seperate timer interrupt run and occasionally wakes up the main xtensia cores which fetches data from the rtc and sends it over. I have looked at the pulse counter examples and with my limited knowledge can not tell if the interrupts are triggered when the ulp is in sleep mode or only when it is on. I would really be glad if someone would show me how to basically use the ulp for counting pulses even when it is sleep mode and periodically wake up the main cores. I am ok with IDF or arduino examples
If you want to count pulses while in deep sleep youuse the ULP. Code on the ULP continues to execute when the board wakes up and goes to normal power mode. So when it is awake, it will still run the counter on the ULP processor unless you stop the ULP periodic wake up timer, ULP will keep waking up and running while the main CPU is active.
As you gave already checked with this example , it should be pretty close to what you need. The only difference seems to be that the example is set to wake up after a given number of pulses, rather than a fixed amount of time. However it should be easy to change that, by enabling deep sleep wake up from timer.For the Arduino you could check Some additional info:
ULP doesn't have GPIO interrupts. So you use deep sleep wake stub (small piece of code which runs immediately after deep sleep, prior to loading application from flash into RAM) you can increment the pulse counter variable, and go to sleep again. This way you can get low power consumption (~5uA) between pulses and moderate power consumption while running the wake stub (around 13mA), for a very short time.
So its up to you to experiment with your specific scenario.
You can use Pulse Counter(PCNT) feature in ESP32 to count the number of pulse in background, Understanding by using same you can able to do some periodic wake-up and read the count.. Its also possible to configure event when number of counts reached certain threshold and had lot of options,
For get information and available Interfaces and API's for Pulse Counter(PCNT) please follow below link, https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/pcnt.html
Initially I faced lot of issue to make Pulse Counter(PCNT) work in Adrino IDE for ESP-32, After multiple attempt I make it working, And same sample code is uploaded in GitHub for reference. I have not use all the API's in the official documentation but but used few of them and are working..
I have created sample program for a water flow meter, there also we use to get pulse which needs to count to measure the water flow rate, understanding simile to kWh meter.
GitHub Sample code Path:- https://github.com/Embedded-Linux-Developement/Arduino_Sample_Programs/tree/main/ESP_32/Water_Flow_Pulse_counter_WithOut_Interrupt_Using_PCNT
I have not placing the code here, because its there in GitHub and not directly for the asked question, but simile one and can use it. Its a working code I tested in HW.
Hopes Its helpful,
Regards, Jerry James
I'm working with the efm32gg380f1024 on a project.
I currently use the BURTC timer (ULFRC clock) as tick source and I would like to use the normal RTC timer(LFRC clock) as well.
Do they exclude each other or can I use both the same time?
I was wondering if someone has already experience with the GG-series of silicon labs and give me some hints?
also what I'm wondering, I do have both LFXO and HFXO on my board currently not used. when I initialize the external clock setup, can I disable the interal rcos since they are not used (??) and just need energy.
the target is battery powered and each uWs counts..
thanks
You have a couple of questions here.
Yes you can use the LETIMER (which is what I think you mean when you say LERTC) peripheral independently of the RTC. They are separate peripherals, but note that the LETIMER is clocked from the same clock as the RTC.
As for using the external crystal oscillators, you need only enable the clocking sources that you actually use. However, clocking sources and entry/exit of the various low power energy modes interact. It can be rather tricky and complex. I suggest you use emlib to control these peripherals and in particular to enter and exit lower power energy modes.
If power consumption is important to you, note that high frequency clocking of the processor core consumes lots of power. Of course this must be traded off with how long you remain awake before going back to a lower power mode and with any real time requirements you might have for processing. Pushing off work to peripherals and using DMA to perform data movement is generally a win. Expect to do a good bit of tuning and you will need ways to accurately measure the power consumption. Using internal RC oscillators for clocking may be sufficient and a lower power approach. The low frequency external crystals tend to be 32 KHz clock crystals and don't consume that much power. They are a good alternative to the internal RC oscillators if you need better frequency stability.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
The topic is rather straight forward and I admit i wasn't able to find much on google.
Recently i started to code on STM32 and for a person that is coming from PC-related application, setting all the clocks was rather new.
I was wondering why a developer would want to discard/avoid maximum clock and in which condition?
Say that a microcontroller could work at 168Mhz, why should i choose 84Mhz?
Is it mainly related to power consumption? Are there any other reason?
Why the STM32 team (and microchip as well i guess) took the hassle of setting up a really nice UI on STM32CubeMX to select different combination?
Why should i use an external oscillator directly rather than the PLL path if i can achieve higher working frequency?
Is it mainly related to power consumption?
Yes, mainly. Lower frequency means lower consumption.
One could also save power by doing the work fast, then putting the cpu to sleep, thus improving average consumption, but the power supply might not like the variable load, and exact timekeeping would be rather difficult.
Are there any other reason?
Yes. Some peripherals don't work above certain frequencies. An example: the STM32F429 core can run at 180 MHz, but then there is no way to generate 48 MHz for USB. In order to use USB, the core must run at 168 MHz.
Why should i use an external oscillator directly rather than the PLL path if i can achieve higher working frequency?
An external oscillator has a much higher accuracy than an internal one, and it may take too long for a PLL to stabilize when waking up from standby. It depends on the application requirements.
Power is probably the main reason. But there may be various other reasons that a specific clock speed is used such as:
EMC emmissions.
Avoiding harmonics which interfere with sensitive analogue electronics.
Driving timers / clocks / ADCs etc that are required to be run at a very specific frequency as part of the design (For example I worked on a processor that run at 120MHz, however in order to get the exact required ADC sampling we had to run at something like 119.4MHz).
You might want to use an external oscillator if you intend to use the clock elsewhere on the board. Also you might want to use a very accurate crystal, or maybe not want to wait for the PLL to lock.
There are lots of reasons. However if you are doing something straight forward and don't care about power consumption or noise then running at max speed with the PLL is probably the best place to start in my opinion.
Power is the obvious one, and as it has been touched on in other answers but not directly. Performance. Faster clock does not mean faster code. ST has this magic cachy thing in front of the flash in addition to a real-ish cache in front of the flash (and disabled the arm cache it appears on the cortex-m4's I have tried). But in general the flash is your bottleneck, if as you see on a number of other vendor parts and sometimes ST, you have to keep adding wait states as you increase the system clock. So say at 16Mhz no wait states, at 32, one, 48 two and so on, depends on the system, you are dancing around the speed limit of the flash, making the processor sit around extra clocks while it waits for instructions to come in. And even on an st but easier to see on others, that directly affects your performance, you want to be perhaps right at the frequency where you go from zero to one wait states to maximize what you can feed the cpu.
Some designs the flash is already at half speed of the cpu/system clock where sram generally tracks and can cover the full range, so take the same code at zero wait states and run from flash then run from ram, on some number of MCUs the same machine code runs half speed on flash as it does on sram. some it is one to one and then when you add a wait state flash is half speed vs ram, and so on.
Peripherals have the same problem as mentioned. You may have to use a prescaler on the peripheral clock, so now reading a gpio pin that at 24mhz might have taken one clock at 80mhz may take three or four clocks.
PLLs are analog and jittery, they dont necessarily "lose" any clock cycles, but are worse as far as jitter as the oscillator which itself has a spec on jitter and accuracy as well as temperature affects. So the internal RC is the worst quality clock, direct from the oscillator bypassing the PLL is the best, then multiplying with the PLL will add jitter, but will allow you to go faster.
Back to power. The battery in your remote control on your TV might last a year or so (infra red, the bluetooth ones are days or weeks), they run the lowest clock rate they can to barely do the job and stay off as much as possible or in low power state. If they were to hop up to 120Mhz when they were awake and the battery now lasts weeks or half a year, vs a year, for no real benefit other than it is really cool to run at full speed. That doesnt make much sense. We heavily rely on battery based products now, if the microcontroller in the bluetooth module on your phone ran at its fully rated pll speed, and the microcontroller in your wifi module in your phone, and the one that drives the display, etc, all ran at max speed, your phone might not last even a day on one full charge. Nothing was gained by running faster, but something was lost.
For hobbies and stuff plugged into the wall, burn whatever power you want, but a noticable percentage of the mcu market is about price and power, chips that are screened to a higher speed cost more, lower speed parts, in some cases are just the chips that failed the higher screen, and cost less. tighter smaller code uses less flash you can buy a smaller/cheaper part, your clock can run slower because it takes fewer instructions to do the same thing than a possibly sloppy program and/or bad choice in programming languages, bigger part, lower yield both add to cost. then lowering the clock as low as you can go to keep your tightly written code to just barely meet timing uses the least amount of power ideally (As well as turning off or not turning on peripherals you are not using and prescaling the ones that are on even slower).
For cost and power you want the slowest clock you can tolerate with the smallest binary that is also tight and efficient so that you can just barely make timing. That is your ideal goal. But if you plan for field upgrades then you need to leave some margin for slower/larger code to be part of the upgrade and not have a dramatic effect on power consumption.
QTimer seems to actually create a "timer" that consumes CPU ticks and posts events etc. Is the same true for QElapsedTimer?
Or is this just something like win32's GetTickCount where by when you call a method on QElapsedTimer it grabs the current tick count and subtracts from the count where it was started?
I want to know if its a good idea to have these things hanging around, or will they eat battery like QTimer?
QTimer will "eat" battery only in some cases. Specifically, if it is a Qt::PreciseTimer on Windows 7 and earlier - on those systems, it will ramp up the tick frequency to 1000Hz. Very short timers will force the same behavior. Since those systems are not tickless, the presence of an active coarse timer does nothing to power consumption, since the system ticks at a fixed rate whether it needs to or not.
On a tickless operating system, QTimer does not have such ill effects. This includes OS X/xnu, Windows 8 or tickless Linux.
QElapsedTimer is not a QObject and does not provide any asynchronous events. It simply provides an interface to the platform's time APIs (not timer APIs).
I need to flash some images with very precise timing (order of milliseconds) for which I developed a subclass of QGLwidget. The images are loaded as textures at initialization. I am using a QTimer instance to change the image being displayed. The timer's timeOut signal is connected to a timeOutSlot which does some file I/O and then calls updateGL().
While I understand that event handlers are for external events and signal/slot is for communication internal to the GUI, I could also implement this as a timeOutEvent handler.
Is there any performance difference between the two? Any performance penalty above 2-3 milliseconds is important to me (hardware is average, say Intel core 2 duo T5700 with nVidia 8600M GT graphics card).
Signals and slots are about 10 x slower than the plain old function calls. But they are definitely not so slow that they would take milliseconds to process. The time to process one signal is about 0.001 ms (see slide 27).
You say that you are requiring a very precise timing, so are you aware how the display refresh rate affects the drawing? Image is (usually) drawn using 60 Hz refresh rate. The time between images is 16.7 ms so that is the maximum accuracy you can get.
I would say signal/slot because events are added to an event queue where Qt often does call optimisations and importance ordering, whilst s/s are executed immediately - albeit slower than direct calls.