Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I need to put an Arduino to sleep mode to save battery, but after x hour (A choice that makes the user), I need that the Arduino wakes up, do some action, and then goes to sleep again. How can I do it? I see that the sleep mode can be interrupt by Interrupt, but I need that the interrupt is trigger not by a pin but by the time. Any suggestion?
Thanks in advance!
The answer to your question depends on how much low power you need and which time precision you need. Achive 200nA sleep current requires some work and time precision is a compromise with low power.
However, here are some clues:
Use an external RTC module able to generate an interrupt at some precise moment
Use an external 32kHz Xtal to clock timer2 asynchronously and generate interupt to wake up from "power-save" sleep mode
Use the internal watchdog timer in interrupt and reset mode to wake up from "power-down" mode. You will wake up every 8s but for very short duration if the code is optimized.
The last solution seems most appropriate for some basic demo. With a good code you will achieve honorable results. And do not forget to read "Minimizing Power Consumption" section of the MCU datasheet.
EDIT
how much more current I consume if the Arduino wakes up every 8 seconds?
There is a way to calculate it?
Too calculate the average current (I would say estimate) read datasheet at section "atmega328P typical characteristics"
#5V 8MHz the consumption is about 5.5mA,
in power down #5V with watchdog 6.5µA.
With about 1ms active every 8s you will achieve 7.2µA mean.
Note that the board consumption is not only the MCU on Arduino board. With an Arduino I don't know how much you will globally consume but it will be more than my calculation. To achieve 200nA stated in datasheet, you will need to do your own board and use external low power watchdog...
And second: the AtMega will ruin faster if wakes up every 8 seconds?
An AtMega does not have ageing issues. It can run constantly for 20 years without issues (except if you use EEPROM or flash self-programming).
Related
Closed. This question is not about programming or software development. 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 last month.
Improve this question
I need to control 12 leds through 4 GPIO pins. I did some reading online and saw we can use Charlieplexing method to control leds with fewer gpio pins. But is it possible to make two or more leds to glow at the same time in this method. Those 12 leds are grouped into 4 groups(3 leds in a group) and 1 led would be lit in each group at a time.
Anybody used this method or any other method please provide some guidance on how to go about this implementation. I'll try it. Thanks.
You can turn on more than one led, using 4 GPIOs (let's alone the current limiting problems - hardware problem), but not in any combination.
BUT: if you manage to turn on any single led at a time, you can fool the user by turning on multiple leds, one after the other, in a quick loop. At any given moment only a LED is on, but the human eye continues to see it lit for about 1/20th of second.
Have a interrupt run every ms (or so), and a mask of 12 bit indicating which leds have to be on. The interrupt handler continuosly "rotates" the GPIOs in order to touch every combination of rows and columns, and in the same time rotates a bit in an internal register (1000b, 0100b, 0010b 0001b, then reload 1000). When the AND of the internal register and the LEDs mask is not zero, the GPIO configuration must be left active, otherwise set the GPIO to off.
Update: forgot to mention, keeping the LEDS on for so short time, will make them less bright than normal. You can partly correct this by allowing more current (up to a safe limit), and/or by choosing brighter LEDs...
You can accomplish this by using external shift registers with latched outputs (e.g. MC74HCT595A) and resistors. The GPIO pins can provide the data, shift clock, and latch clock. Also, the shift registers can be daisy chained so that you can go beyond 12 LEDs if you wish. Be sure that the logic family of the shift registers chosen matches that of your MCU.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I'm trying to read in a 0-10V analog signal from a pressure gauge (Balzers SingleGauge TPG 251) with the help of an arduino nano. With a voltage divider I'm able to get to a 0-5V range to not damage my arduino. Sad thing is that the resolution of the integrated 10-bit ADC is pretty low (5000mV/1023 ~ 5mV steps) for my purposes. The pressure gauge can measure from 10e-11 mbar to 1000 mbar and will give a value from 0-10V accordingly. Through observations I've seen the display change values in this way:
1000 to 100 being in 10 steps = 91 numbers
100 to 1 in 0.1 steps = 991 numbers
9.9e-1 to 1e-2 = 99 numbers per decade (there are 11 decades --> 99*1 = 1089 numbers)
Total of 2171 separate analog steps (if the steps are linear).
This means that each analog step will be of 4.6 mV in a 0-10V range. Since I'm using a voltage devider the mV/step difference will be halved, reaching a 2.3 mV/step. This is obviously to low to resolve and so I need to use an 12- or 16-bit ADC. I decided to use a 16-bit ADC because why not have a better precision, right? I have bought the ADS1115 and I hope to be able to read the values a lot better and more precise (max 0.15mV). With the analog value I can then reversly get the pressure as a number.
The real problems come in now. I want to have the setup connected to the local wifi where people can look at the pressure. And I would also like to let them enter the value they want to be alerted on per email that they also enter.
I've seen this tutorial with an ESP32 (https://randomnerdtutorials.com/esp32-email-alert-temperature-threshold/) where it's possible. So I'll try to follow through that with an ESP8266 nodeMCU.
I know this is a lot to take in and I hope somebody has an Idea how I can advance in this project. Here are some questions from my side:
Do I need both an arduino and a ESP8266 for this project? Since Arduinos analog range is from 0-5V and the ESPs analog range is from 0-1V, arduino can thus handle more. ESP would then just have the purpose of sending the email and web server stuff.
Is there a way to just use the ESP8266 and the ADS1115 and still read the analog values with a high precision? Or is it just not possible?
Any feedback what would make sense here? Maybe there is a way to do this that I've not yet googled.
Thank you in advance!
ADS1115 has a I2C interface. Just hook it up to the ESP. There is no need for the Arduino nano.
Please read the datasheet of your ADC.
http://www.esp8266learning.com/ads1115-analog-to-digital-converter-and-esp8266.php
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
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
What is the potential maximum speed for rs232 serial port on a modern PC? I know that the specification says it is 115200 bps. But i believe it can be faster. What influences the speed of the rs232 port? I believe it is quartz resonator but i am not sure.
This goes back to the original IBM PC. The engineers that designed it needed a cheap way to generate a stable frequency. And turned to crystals that were widely in use at the time, used in any color TV in the USA. A crystal made to run an oscillator circuit at the color burst frequency in the NTSC television standard. Which is 315/88 = 3.579545 megahertz. From there, it first went through a programmable divider, the one you change to set the baudrate. The UART itself then divides it by 16 to generate the sub-sampling clock for the data line.
So the highest baudrate you can get is by setting the divider to the smallest value, 2. Which produces 3579545 / 2 / 16 = 111861 baud. A 2.3% error from the ideal baudrate. But close enough, the clock rate doesn't have to be exact. The point of asynchronous signalling, the A in UART, the start bit always re-synchronizes the receiver.
Getting real RS-232 hardware running at 115200 baud reliably is a significant challenge. The electrical standard is very sensitive to noise, there is no attempt at canceling induced noise and no attempt at creating an impedance-matched transmission line. The maximum recommended cable length at 9600 baud is only 50 feet. At 115200 only very short cables will do in practice. To go further you need a different approach, like RS-422's differential signals.
This is all ancient history and doesn't exactly apply to modern hardware anymore. True serial hardware based on a UART chip like 16550 have been disappearing rapidly and replaced by USB emulators. Which have a custom driver to emulate a serial port. They do accept a baudrate selection but just ignore it for the USB bus itself, it only applies to the last half-inch in the dongle you plug in the device. Whether or not the driver accepts 115200 as the maximum value is a driver implementation detail, they usually accept higher values.
The maximum speed is limited by the specs of the UART hardware.
I believe the "classical" PC UART (the 16550) in modern implementations can handle at least 1.5 Mbps. If you use a USB-based serial adapter, there's no 16550 involved and the limit is instead set by the specific chip(s) used in the adapter, of course.
I regularly use a RS232 link running at 460,800 bps, with a USB-based adapter.
In response to the comment about clocking (with a caveat: I'm a software guy): asynchronous serial communication doesn't transmit the clock (that's the asynchronous part right there) along with the data. Instead, transmitter and receiver are supposed to agree beforehand about which bitrate to use.
A start bit on the data line signals the start of each "character" (typically a byte, but with start/stop/parity bits framing it). The receiver then starts sampling the data line in order to determine if its a 0 or a 1. This sampling is typically done at least 16 times faster than the actual bit rate, to make sure it's stable. So for a UART communicating at 460,800 bps like I mentioned above, the receiver will be sampling the RX signal at around 7.4 MHz. This means that even if you clock the actual UART with a raw frequency f, you can't expect it to reliably receive data at that rate. There is overhead.
Yes it is possible to run at higher speeds but the major limitation is the environment, in a noisy environment there will be more corrupt data limitating the speed. Another limitation is the length of the cable between the devices, you may need to add a repeater or some other device to strengthen the signal.