Microcontroller with low active/run current

[Howardlong]

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?

That 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.

[slugrustle]

Is this ALL the micro is doing?

Also 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.

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?

In 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 page http://www.apexhifi.com/specs.html is 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.

The FV version will run directly off your LiIon cell, the operating envelope is 2.0 to 5.5v, so no LDO required.

PIC10F202 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.

[Peabody]

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.)

[FrankBuss]

I just realized that I can put the headphone channels in series and use one output driver.

You 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.

[slugrustle]

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).

There 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 from http://www.jmargolin.com/patents/atari3.pdf and verified it with the following C++ code:

Code: [Select]

#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;
}


For low-power I've always been partial to the MSP430 parts.

From 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.

Finally, I wonder if there's a possibility of using a pre-calculated 256-byte lookup table instead of shifting and XORing.

Good 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.

[mikeselectricstuff]

[quote ]
 and STM32L011D3P6 wins out if I calculate the next LFSR state as quickly as possible and then sleep.

[/quote]
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

[Kalvin]

[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
[/quote]

Typically 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.

[slugrustle]

You 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.

FrankBuss: I see hear 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: [Select]

#include <iostream>
#include <cinttypes>

int main(void)
{
  // For 31-bit LFSR
  const 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 left
   uint8_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;
}


[FrankBuss]

You 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.

FrankBuss: I see hear 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.

In case others are interested as well, I did a quick test:

https://soundcloud.com/frankbuss/noise-test

It 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.

[slugrustle]

https://soundcloud.com/frankbuss/noise-test

Fascinating. Why are the two so different? Is it a psycho-acoustic effect?

[nctnico]

For low-power I've always been partial to the MSP430 parts.

From a little looking into this, PIC10F202 / ATTiny4 have lower run currents if I go the route of constant run,

Microchip and Atmel have always been very optimistic in their datasheets so take the numbers with a few pinches of salt.

[FrankBuss]

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 head Might be even better for relaxing.

[Howardlong]

For low-power I've always been partial to the MSP430 parts.

From a little looking into this, PIC10F202 / ATTiny4 have lower run currents if I go the route of constant run,

Microchip and Atmel have always been very optimistic in their datasheets so take the numbers with a few pinches of salt.

Indeed, 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.

[nctnico]

For low-power I've always been partial to the MSP430 parts.

From a little looking into this, PIC10F202 / ATTiny4 have lower run currents if I go the route of constant run,

Microchip and Atmel have always been very optimistic in their datasheets so take the numbers with a few pinches of salt.

Indeed, 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.

True 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.

[FrankBuss]

For low-power I've always been partial to the MSP430 parts.

From a little looking into this, PIC10F202 / ATTiny4 have lower run currents if I go the route of constant run,

Microchip and Atmel have always been very optimistic in their datasheets so take the numbers with a few pinches of salt.

At 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/

[nctnico]

For low-power I've always been partial to the MSP430 parts.

From a little looking into this, PIC10F202 / ATTiny4 have lower run currents if I go the route of constant run,

Microchip and Atmel have always been very optimistic in their datasheets so take the numbers with a few pinches of salt.

At 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/

But that is only one sample! Parts vary a lot and sometimes a new batch can have issues which stayed hidden in earlier batches.

[FrankBuss]

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,

[nctnico]

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,

There are variations in processes and variations in temperature. Try to measure the current at the minimum and maximum operating temperatures for example.

[Howardlong]

Like I said a few posts ago, the devil is in the detail.

[Howardlong]

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.

[ebclr]

Did you evaluate the analogue way ?

[Kalvin]

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.

Adding 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.

[Howardlong]

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.

Adding 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.

The 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.

[Kalvin]

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.

Adding 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.

The 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.

True, 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.