Microcontroller with low active/run current - Page 1
Forum section: electronics / general

author: slugrustle
author_rank: Frequent Contributor
timestamp: December 14, 2017, 03:09:16 pm
content: I'm working on a project where the microcontroller runs for long periods of time (white noise generator with m-LFSR). The requirements on the microcontroller are very minimal, only that it needs to run at least 0.5 MIPS; what micros have low active run current?Best I've seen to date is the PIC10F202, with 175uA to 275uA at 2V supply. It has a non-configurable 4MHz clock (1 MIPS).Page 59 ofhttp://ww1.microchip.com/downloads/en/DeviceDoc/40001239F.pdfEven the PIC10LF320 at 1.8V has 213uA to 290uA at 500kHz/0.125MIPS (below my spec) and 330uA to 500uA at 8MHz/2MIPS.Page 162 ofhttp://ww1.microchip.com/downloads/en/DeviceDoc/40001239F.pdfI'm open to others, AVR, ARM, MSP430, STM8, EFM8, RL78, Holtek, etc. From what I recall about looking at this before, most micros optimize the sleep current and have higher active/run currents than the above two. Current values using external oscillators are often much lower, but I can't find oscillators more efficient than the internal ones.

author: Kalvin
author_rank: Super Contributor
timestamp: December 14, 2017, 03:24:18 pm
content: Low current consumption is only half truth. Energy efficiency is what you are after. If you have a tiny 8-bit processor and a 32-bit processor both consuming 1uA when in sleep mode waiting for a timer interrupt, and the 8-bit microcontroller consumes only 100 uA active current and it takes 50 us to process each sample and the 32-bit process consumes 500 uA when in active and it takes 5 us to process each sample, you should be able to compute which one is more energy efficient solution to your design.

author: RES
author_rank: Regular Contributor
timestamp: December 14, 2017, 03:28:30 pm
content: ATtiny4/5/9/10 active mode 200uA at 1.8V at 1MIPS.

author: slugrustle
author_rank: Frequent Contributor
timestamp: December 14, 2017, 03:34:36 pm
content: RES: Thank you. I'll definitely check that out.Kalvin: In this particular application, the microcontroller will remain in active mode for long periods of time (hours), as it is operating as a white noise generator.

author: Howardlong
author_rank: Super Contributor
timestamp: December 14, 2017, 03:56:19 pm
content: You can also get devices with hardware random number generators, often included in crypto peripherals. PIC24FJ64GA/GB202 as a quick example. Depending on the application, together with DMA, you might be able to switch off the CPU completely.

author: tszaboo
author_rank: Super Contributor
timestamp: December 14, 2017, 04:02:44 pm
content: STM32L4 series, have so-called Low power run mode. Ac coding to an appnote, it is using some 100uA @ 500 KHzhttp://www.st.com/content/ccc/resource/technical/document/application_note/5c/cb/90/97/4b/84/4e/81/DM00216518.pdf/files/DM00216518.pdf/jcr:content/translations/en.DM00216518.pdfMaybe other ST has this.

author: Kalvin
author_rank: Super Contributor
timestamp: December 14, 2017, 04:10:39 pm
content: Quote from: slugrustle on December 14, 2017, 03:34:36 pmSure, but you will be processing the signal as discrete samples ie. you will be outputting the noise signal only at specified sample rate. For example, you will be having a periodic timer running at some sample rate, let's say like 48 kHz or 32 kHz. Each time the timer expires it will produce an interrupt. As this application is very simple one, you can perform all processing in this interrupt routine. In the interrupt routine you need to output one noise sample and perform some computation for the next noise sample value [in order to minimize the jitter]. When the processor returns from the interrupt routine, the processor will enter very low power sleep mode consuming only 1 uA - 2 uA. Thus, it is a matter of energy efficiency vs. current consumption. Of course, you can select a small microcontroller with low current consumption, but it may not be optimal solution energy-wise.You can calculate a duty cycle for your microcontroller affecting the energy consumption: Let's assume that you are running at sample rate of 32 kHz, so the time between each sample is 31.25 us.1. Lets assume that your little 8-bit controller is consuming 100 uA and it manages just compute the next sample in this 31.25 us. Thus, your duty cycle is close to 100% and your noise generator is obviously consuming 100 uA as the 8-bit microcontroller is busy processing the samples.2. Next, you want to evaluate a 32-bit controller consuming 500 uA when it is active, and 1uA when it is the sleep mode, but you find out that it takes only 5 us to compute each sample. So, your duty cycle is 5:31.25 = 0.16, thus effectively your 32-bit microcontroller is consuming 1 uA + (500uA * 0.16) = 1 uA + 80 uA = 81 uA.From this simplified example you can see that a 32-bit controller may be 20% more energy-efficient than a smaller 8-bit microcontroller, although the 32-bit microcontroller consumes 5 times more power when it is in active state.

author: mark03
author_rank: Frequent Contributor
timestamp: December 14, 2017, 04:23:26 pm
content: This could be an interesting use case for a [very!] tiny FPGA, e.g.https://www.digikey.com/product-detail/en/lattice-semiconductor-corporation/ICE40LP384-SG32/220-2646-ND/3974680Static power 21 uA @ 1.2V.

author: slugrustle
author_rank: Frequent Contributor
timestamp: December 14, 2017, 04:26:40 pm
content: NANDBlog: Cool! The smaller STM32L011D3 has something similar, 67uA to 91uA with code running from flash and 524kHz MSI clock. Page 55 ofhttp://www.st.com/content/ccc/resource/technical/document/datasheet/42/c0/ab/e5/71/7a/47/0b/DM00206508.pdf/files/DM00206508.pdf/jcr:content/translations/en.DM00206508.pdfKalvin: Those specs are about right. I'm doing this:https://pages.mtu.edu/~suits/LFSR.htmlin a microcontroller to save board space. The m-LFSR is 31 bits with two taps, and I update it around 32,000 times per second. I had started with 8 bit micros, so I didn't think about micros which could do that calculation a lot more quickly. The hard part is extracting the tap bits and XORing them to perform the update, as there is no simple instruction for this. It either requires a lot of shifts (I think M0+ has a barrel shifter) or some bit tests and conditional branches.

author: Howardlong
author_rank: Super Contributor
timestamp: December 14, 2017, 09:40:36 pm
content: What are you interfacing to? A codec, or a simple parallel DAC, or something else?And what power is that taking? (I’m trying to figure out the benefit of squeezing out another 50uA if the rest of the application is taking, say, 10mW).

author: nctnico
author_rank: Super Contributor
timestamp: December 14, 2017, 10:26:47 pm
content: AFAIK MSP430 is still king of the hill. What also matters (and often isn't specified on the cheaper parts) is the time between the wake-up event and until the microcontrollers starts to actually do something. A couple of years ago I did a redesign of a circuit which used a PIC controller. The MSP430 based circuit needed 25% of what it was before so the device ran longer or could do with a smaller (cheaper) battery.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 14, 2017, 10:35:04 pm
content: If all you want is an LFSR, it might be worth looking at low power CPLDs - I don't know how they compare, but in principle you'll only be clocking the parts that are doing something, not a whole processor.You may also want to look at optimising your code, maybe writing in assembler, so you can run at lower clock rates.C isn't good at using things like carry flags efficiently, so for bit-twiddly things assembler may help a lot, and wouldn't be hard to do.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 14, 2017, 10:41:02 pm
content: Quote from: slugrustle on December 14, 2017, 04:26:40 pmI don't recall details but there is an LFSR variant where you simply shift the register, and conditionally XOR the whole register with a constant if the carry-out was set by the shift. This is trivially easy to do, and very fast on pretty much any micro - on an ARM with its conditional instructions you can do it in about 4 cycles.On an 8 bit PIC it would be about 10 instructions, probably similar on an AVR.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 14, 2017, 10:57:16 pm
content: I can't immediately find any power figures but if it's for a moderate volume, it may be worth looking at the Silego Greenpak devices

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 15, 2017, 01:36:40 am
content: STM32L4 series is pretty good in that respect. You could select the smallest in the series (such as the STM32L431) and could probably get away with a run current of approx. 50 µA at 500 kHz (in low-power run mode, running code from SRAM). You may be able to improve on that further with having it run at the lowest Vdd possible (1.71 V) and using an ultra-low power step-down regulator to generate this voltage from your energy source if it's nominally higher than 1.71 V.On a side note, if you need to generate white noise, STM32L4 microcontrollers have a "random number generator" built-in which may allow you to make the µC sleep between each sample and reduce the average power draw drastically. Since the random generators are analog-based, they are probably much better than simple LFSR.An interesting reference when looking for low-power microcontrollers is:http://www.eembc.org/ulpbench/Ambiq microcontrollers are what I think the lowest power 32-bit microcontrollers (ARM-based, Cortex M4F). I've evaluated the Apollo 1 which is fantastic. Not tried the Apollo 2 yet, but it's supposed to be even better.

author: slugrustle
author_rank: Frequent Contributor
timestamp: December 15, 2017, 01:43:04 am
content: I did write the initial test in assembler for the PIC10F322 (attached as WNoise.asm). The main loop that runs the LFSR is about 16 cycles, which on the PIC is 64 clocks. The output is just one of the LFSR bits sent to a pin on each iteration of the main loop. For testing, I loaded the pin with a 19.4kHz low-pass filter, followed by a unity-gain LM358 and a 16Hz high-pass filter, the output of which went to the line-in on my PC.Attached are spectrum plots (smooth line is average) of the noise when running the PIC at various clock frequencies. The plots are just screen shots of SpecAn_3v97c, which I found athttp://www.techmind.org/audio/specanaly.html.In the final application, I plan to use several MCP6411 opamps (35uA-55uA quiescent each) to filter the noise such that the 100Hz-1kHz region is flat on an A-weighted scale and the output rolls off at about 20dB/decade starting at 5-7kHz. This will be followed by a digital potentiometer and two LMV611 opamps (116uA-210uA quiescent each) to drive a stereo headphone jack. I'm thinking to run the micro from an AP2138 linear regulator supplied by a 10440 Li-Ion cell and power all of the opamps at 5V with an MCP1640C boost converter. The micro will disable the boost converter and sleep when the power button is pressed off.For now, I'm wiring a protoboard with LM358s in the filter topology I want to use and trimpots in place of various gain and filter resistors. Once I have a noise output that sounds "pleasant", I will make an SMD version with the above listed parts.

author: Howardlong
author_rank: Super Contributor
timestamp: December 15, 2017, 09:14:55 am
content: I wonder what it is that you are driving, i.e., what is the power taken by the load?

author: tszaboo
author_rank: Super Contributor
timestamp: December 15, 2017, 02:24:13 pm
content: Quote from: Howardlong on December 15, 2017, 09:14:55 amProbablyQuoteso headphone. A typical headphone has about 100dB/mW, so they take 1mW to drive loud. High end models are less efficient.So, are you making a headphone burn-in device?

author: coppice
author_rank: Super Contributor
timestamp: December 15, 2017, 04:17:59 pm
content: Quote from: NANDBlog on December 15, 2017, 02:24:13 pmWhy would power consumption be an issue for that? On the other hand, if its some application where someone would listen to the headphones you'd think the statistics, as well as the spectrum, of the noise would be important.

author: slugrustle
author_rank: Frequent Contributor
timestamp: December 15, 2017, 04:38:21 pm
content: Thanks for all the replies. I'm looking at two options for the final project:1. Using an STM32L011D3P6 in the manner Kalvin suggested with an ISL23415 digital potentiometer (separate logic and analog supplies). One micro for noise generation, power button, 5V boost enable, vol up/down buttons, and SPI to digital potentiometer.2. Using PIC10F202 or ATTiny4 for noise generation, power button, and 5V boost enable. Using a PIC12F1571 or ATTiny13A on the 5V side to read volume up/down buttons and connect to MCP1451 digital potentiometer over SPI.Interesting find: The EM Microelectronic EM6580 has 60uA run current at 0.4MIPs.http://www.emmicroelectronic.com/products/microcontrollers/flash-based-mcu/em6580. That company has some really neat low power chips, including 4 bit chips that run at 32kHz. They are too niche to be practical for my purposes.I am indeed driving headphones with this. Given that I am planning on using a single 10440 Li-Ion cell as the supply (http://www.batteryspace.com/li-ion-10440-cylindral-cell-aaa-size-3-7v-350mah-lc-10440a-button-top---un-38-3-passed.aspx), I want to at least consider my options for reducing operating current. Noise drives me a little crazy sometimes (dogs, lawnmowers, whistling, loud talking in adjacent cubicles, etc.) so I plan to pair this with some Shure noise-isolating earbuds. I have played white/brown/pink noise on large headphones while wearing 33dB earplugs before, and the subsequent total absence of sounds that annoy me is such a relief. Making that more portable and discrete would be nice.

author: tszaboo
author_rank: Super Contributor
timestamp: December 15, 2017, 06:53:02 pm
content: Quote from: slugrustle on December 15, 2017, 04:38:21 pmOh, it is for relaxing! OK. I totally understand that. So here is what I have:3M Peltor X5Ahttps://www.3m.com/3M/en_US/company-us/all-3m-products/~/3M-PELTOR-X5-Earmuffs-X5A-37274-AAD-Over-the-Head-10-EA-Case?N=5002385+3294326317&rt=rud-31dB it makes everything quiet. I kid you not, sometimes I go to sleep with this.Also, I would try using a phone with an app for white noise. There are several apps for this, you can change the tone/pitch apply filters, etc...

author: slugrustle
author_rank: Frequent Contributor
timestamp: December 15, 2017, 07:57:24 pm
content: QuoteAh, the easy solution. Once I get the protoboard version where I want it, I plan to record a long MP3 and put that on a small MP3 player.I was also considering looking up the WAV file format and synthesizing the spectrum I want with FFT and digital filters, but I realized that at the end of the day, I like making electronic stuff. When I found out you could generate broad spectrum noise with an m-LFSR, I just had to do it. I fully understand this is not practical.

author: coppice
author_rank: Super Contributor
timestamp: December 15, 2017, 10:54:58 pm
content: Quote from: slugrustle on December 15, 2017, 07:57:24 pmGenerating a broad flat spectrum is trivial. There are many ways to do that. However, the simple ways leave you with flat statistics, which is a highly unnatural kind of noise, and not very pleasant. You really want to add enough separate streams together, so you start to approximate Gaussian statistics before the noise starts to sound pleasant. 5 to 10 of them is usually enough for a pleasing result.

author: jmelson
author_rank: Super Contributor
timestamp: December 15, 2017, 11:01:01 pm
content: Quote from: slugrustle on December 14, 2017, 03:34:36 pmIs this ALL the micro is doing? It might make sense to use either an FPGA or CPLD for this. Xilinx's CoolRunner II CPLDs can run on really low current as they are pure CMOS, and if the number of gates/FFs that are changing state are small, the current should be less than a microcontroller. The clock could be turned down to the LFSR bit rate, which sounds like it might be in the 10's of KHz, which should drop the power into the 10's of uA, maybe.Jon

author: westfw
author_rank: Super Contributor
timestamp: December 16, 2017, 04:53:39 am
content: Isn't the 300uA current that most of the microcontrollers will beat, still much less than you'll end up needing to drive into your headphones? Or are they separately powered?

author: Howardlong
author_rank: Super Contributor
timestamp: December 16, 2017, 01:40:02 pm
content: Quote from: westfw on December 16, 2017, 04:53:39 amThat was my thought also.Forget my suggestion earlier of a PIC24 with crypto RNG, I just tried it and it takes about 500 odd cycles to generate. While you could use the 128 bit result it produces, that nullifies the point of it running without the CPU core.Another option, PIC24F(V)16KM202. The FV version will run directly off your LiIon cell, the operating envelope is 2.0 to 5.5v, so no LDO required. Also, it has a pair of 8 bit DACs and two R-R opamps, so there is no need for external opamps or digital pots.

author: slugrustle
author_rank: Frequent Contributor
timestamp: December 16, 2017, 03:15:33 pm
content: QuoteAlso monitoring a power on/off button. I want it to work like a phone: you have to hold down for a couple seconds for on, off is instant. The micro sends an enable signal to a 5V boost converter that powers the opamps. Finally, it reads the output of a voltage monitor and shuts everything down if the battery voltage goes below a certain threshold.Those CPLDs look really neat, but the time it would take me to learn how to use them would push this project out too far. Also, the smallest ones are much larger on a board than a SOT23-6 or even TSSOP-14 microcontroller.QuoteIn general, I still like to be smart about current usage wherever I can. Also, I started this thread out of curiosity to see if there were micros out there with really low run currents.The headphones are 16ohms nominal and 105dB SPL/mW. If this pagehttp://www.apexhifi.com/specs.htmlis correct about how db SPL works, the headphones would reach 85dB SPL at 10uW. Given this is louder than I will use, it's a good figure for estimating power.I just realized that I can put the headphone channels in series and use one output driver. This saves both parts and operating current. I would need about 35.8mV peak into this 32ohm load to acheive 20uW (10uW per earbud), and this draws 791uA RMS.Running these numbers again was really good. I'm going to ditch the boost converter and run the opamps from the battery, with a load switch to turn them off in powerdown.QuotePIC10F202 and ATTiny4 will do the same. I don't want the output volume to drift with battery voltage, and the AP2138 regulator needs about 1uA of supply current. Given that these micros run at much higher currents with higher input voltage, adding the LDO is a net savings in power usage.

author: Peabody
author_rank: Super Contributor
timestamp: December 16, 2017, 05:06:53 pm
content: slugrustle, this doesn't directly address your question, but I'm having some trouble with taps at 31 and 13 for a 31-bit LFSR. The tables I have show either 31 and 28, or 31 and 3, for a 31-bit register for maximal length (most pseudo random).For low-power I've always been partial to the MSP430 parts. Dave even has an episode showing one running with no power at Vcc. :-) And they are 16-bit processors, which is my Goldilocks size.Finally, I wonder if there's a possibility of using a pre-calculated 256-byte lookup table instead of shifting and XORing. That's if you do 31 and 28. (Your mother never needs to know you used a lookup table instead of calculating it properly.)

author: FrankBuss
author_rank: Unknown
timestamp: December 16, 2017, 05:56:24 pm
content: Quote from: slugrustle on December 16, 2017, 03:15:33 pmYou would hear a difference. Stereo noise with two non-coherent noise sources would sound more natural, one noise source would sound mono, like the noise is in the middle of your head. You can generate and test both with programs like Audacity.

author: slugrustle
author_rank: Frequent Contributor
timestamp: December 16, 2017, 06:47:44 pm
content: QuoteThere are many 31-bit m-LFSRs and at least two different ways to specify the tap bits. I found the one for taps 13 and 31 fromhttp://www.jmargolin.com/patents/atari3.pdfand verified it with the following C++ code:Code:#include <iostream>#include <cinttypes>int main(void){uint64_t stateCount = 0u;const uint32_t initState = 0x55555555u;uint32_t shiftReg = initState;do {uint8_t nextBit = static_cast<uint8_t>((shiftReg & 0x00000002u) > 0) ^static_cast<uint8_t>((shiftReg & 0x00080000u) > 0);shiftReg >>= 1u;if (nextBit > 0) {shiftReg |= 0x80000000u;}stateCount++;} while (shiftReg != initState);std::cout << "state count: " << stateCount << std::endl;return 0;}QuoteFrom a little looking into this, PIC10F202 / ATTiny4 have lower run currents if I go the route of constant run, and STM32L011D3P6 wins out if I calculate the next LFSR state as quickly as possible and then sleep.QuoteGood idea. With 31 and 28, indexed from left, one could get by with a mask operation and a 4-entry jump table. Each entry in the jump table either sets or clears the carry bit and then jumps to the LFSR rotate block. I wrote the code for this, and the main loop takes 13 or 15 cycles. My current code does conditional jumps based on bit tests, and the main loop takes 13 or 14 cycles.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 16, 2017, 06:59:43 pm
content: [quote ]and STM32L011D3P6 wins out if I calculate the next LFSR state as quickly as possible and then sleep.Problem with that is that you probably want a constant, jitter-free playback rate, so unless the MCU has an accurate wake mechanism, that may not be a good option, though switching the clock down to as slow as possible may work

author: Kalvin
author_rank: Super Contributor
timestamp: December 16, 2017, 07:08:22 pm
content: Quote from: mikeselectricstuff on December 16, 2017, 06:59:43 pmProblem with that is that you probably want a constant, jitter-free playback rate, so unless the MCU has an accurate wake mechanism, that may not be a good option, though switching the clock down to as slow as possible may workTypically the simple MCUs have quite constant cycle times when wakening from the sleep and entering an interrupt routine. If one constructs the interrupt routine so that it will first output the new sample and only after that compute the next sample to be output in the next wakeup, one can minimize the jitter. On-chip low-power RC-clocks are good enough for providing the sample clock.

author: slugrustle
author_rank: Frequent Contributor
timestamp: December 16, 2017, 07:45:08 pm
content: QuoteFrankBuss: Iseehear what you mean about middle of the head; very interesting. The design has only ever had one noise source, just a question of how many output drivers. I will try the simulation with audacity that you suggested to see if the difference is worth building essentially two of these.Here is an improved LFSR test code, if anyone is interested. I neglected to mask the 32nd bit before, which isn't actually part of the 31-bit LFSR state. Also added code to test 23-bit LFSR.Code:#include <iostream>#include <cinttypes>int main(void){// For 31-bit LFSRconst uint32_t bitMask = 0xFFFFFFFEu;// For 23-bit LFSR//const uint32_t bitMask = 0xFFFFFE00u;uint64_t stateCount = 0u;const uint32_t initState = (0x55555555u & bitMask);uint32_t shiftReg = initState;do {// 31-bit LFSR taps at 13 and 31, 1-indexed from leftuint8_t nextBit = static_cast<uint8_t>((shiftReg & 0x00000002u) > 0) ^static_cast<uint8_t>((shiftReg & 0x00080000u) > 0);// 31-bit LFSR taps at 28 and 31, 1-indexed from left//uint8_t nextBit = static_cast<uint8_t>((shiftReg & 0x00000002u) > 0) ^// static_cast<uint8_t>((shiftReg & 0x00000010u) > 0);// 23-bit LFSR taps at 5 and 23, 1-indexed from left//uint8_t nextBit = static_cast<uint8_t>((shiftReg & 0x00000200u) > 0) ^// static_cast<uint8_t>((shiftReg & 0x08000000u) > 0);shiftReg >>= 1u;if (nextBit > 0) {shiftReg |= 0x80000000u;}stateCount++;} while ((shiftReg & bitMask) != initState);std::cout << "state count: " << stateCount << std::endl;std::cout << "max 23-bit: " << ((1u << 23u) - 1) << std::endl;std::cout << "max 31-bit: " << ((1u << 31u) - 1) << std::endl;return 0;}

author: FrankBuss
author_rank: Unknown
timestamp: December 17, 2017, 02:13:06 pm
content: Quote from: slugrustle on December 16, 2017, 07:45:08 pmIn case others are interested as well, I did a quick test:https://soundcloud.com/frankbuss/noise-testIt is white noise, with an additional 1 kHz low pass filter with 6 dB rolloff per octave. Listen with headphones, then guess what is mono and what is stereo, but I think it is quite obvious.

author: slugrustle
author_rank: Frequent Contributor
timestamp: December 17, 2017, 03:22:53 pm
content: QuoteFascinating. Why are the two so different? Is it a psycho-acoustic effect?

author: nctnico
author_rank: Super Contributor
timestamp: December 17, 2017, 03:40:08 pm
content: Quote from: slugrustle on December 16, 2017, 06:47:44 pmMicrochip and Atmel have always been very optimistic in their datasheets so take the numbers with a few pinches of salt.

author: FrankBuss
author_rank: Unknown
timestamp: December 17, 2017, 03:41:04 pm
content: The human ears have a high resolution for phase shifts and interprets them as sound from different directions. Non-coherent noise has lots of phase shifts for the individual frequency components in a given time window, so it appears to be all around you. If there is no phase shift, no loudness difference and no visual clue, the only logical conclusion for the brain is that the noise is in the center of your headMight be even better for relaxing.

author: Howardlong
author_rank: Super Contributor
timestamp: December 17, 2017, 05:59:58 pm
content: Quote from: nctnico on December 17, 2017, 03:40:08 pmIndeed, I'll add that the devil is in the detail, precisely how you use the device makes a significant difference. I strongly suggest that many of the figures in the data sheets haven't ever been properly characterised. Sometimes I achieve significantly _better_ than specified figures, but usually if it's not in the ball park, it's worse.Practically speaking if there is a design specification to be met, the only way to find it out is to do it empirically.

author: nctnico
author_rank: Super Contributor
timestamp: December 17, 2017, 07:11:12 pm
content: Quote from: Howardlong on December 17, 2017, 05:59:58 pmTrue but it helps to put manufacturers like Microchip and Atmel (which is now part of Microchip) on the blacklist. Especially if you have to put a circuit together quickly and need to rely on the headline numbers in a datasheet.

author: FrankBuss
author_rank: Unknown
timestamp: December 17, 2017, 08:08:41 pm
content: Quote from: nctnico on December 17, 2017, 03:40:08 pmAt least for the sleep mode for one chip from Microchip I tried, the values I measured were much better than the 20 nA stated in the datasheet (after fixing some problems on my side) :https://www.eevblog.com/forum/microcontrollers/pic12f1572-sleep-current/

author: nctnico
author_rank: Super Contributor
timestamp: December 17, 2017, 09:40:45 pm
content: Quote from: FrankBuss on December 17, 2017, 08:08:41 pmBut that is only one sample! Parts vary a lot and sometimes a new batch can have issues which stayed hidden in earlier batches.

author: FrankBuss
author_rank: Unknown
timestamp: December 17, 2017, 10:00:35 pm
content: I don't know much about IC manufacturing, but I doubt that the sleep current would vary that much, and it was already nearly twice as good as the datahseet says,

author: nctnico
author_rank: Super Contributor
timestamp: December 17, 2017, 10:51:03 pm
content: Quote from: FrankBuss on December 17, 2017, 10:00:35 pmThere are variations in processes and variations in temperature. Try to measure the current at the minimum and maximum operating temperatures for example.

author: Howardlong
author_rank: Super Contributor
timestamp: December 17, 2017, 11:12:55 pm
content: Like I said a few posts ago, the devil is in the detail.

author: Howardlong
author_rank: Super Contributor
timestamp: December 21, 2017, 10:36:31 am
content: I did some experimentation with the CRC peripheral available in some PIC16 devices. While this will generate LFSR random numbers easily quickly enough, it's only a 16 bit LFSR. Interestingly I could easily determine a repetitive pattern in the audio, even if slowed down to 8ksps, so a repetition rate of about 8s.

author: ebclr
author_rank: Super Contributor
timestamp: December 21, 2017, 11:20:08 am
content: Did you evaluate the analogue way ?

author: Kalvin
author_rank: Super Contributor
timestamp: December 21, 2017, 06:38:59 pm
content: Quote from: Howardlong on December 21, 2017, 10:36:31 amAdding the outputs from a few 16-bit LFSRs with different polynomes will improve the situation considerably. That was a valid solution when generating a noise using those older LFSR ICs.

author: Howardlong
author_rank: Super Contributor
timestamp: December 21, 2017, 06:51:22 pm
content: Quote from: Kalvin on December 21, 2017, 06:38:59 pmThe problem is that by the time you’ve had to reconfigure the CRC peripheral each time in an effort to extend its length, you’re better off doing it in software. I was trying to see if was possible to reduce CPU power to the minimum as the OP’s low power requirements are quite hard in practice to achieve.

author: Kalvin
author_rank: Super Contributor
timestamp: December 21, 2017, 07:12:26 pm
content: Quote from: Howardlong on December 21, 2017, 06:51:22 pmTrue, but I was just commenting on how to reduce the problem with short LFSRs MM5837 or simiilar for audio noise generation. Of course today one can quite easily generate very long pseudo-random sequencies with a single microcontroller.