ATtiny13 extreme space constraint?

Hello everyone. I am trying to compile below code for ATtiny13A in arduino ide. I am using Microcore library. This code works as a frequency to frequency conversion but unfortunately I am getting some memory constraint issue in tiny13. Code is working fine with arduino uno. Can anyone help?

const byte InputPin = 2;
const byte OutputPin = 1;

volatile unsigned long PreviousInterruptTime = 0;
volatile unsigned long InputCycleTime = 0;

void setup()
{
  pinMode(InputPin, INPUT_PULLUP);
  pinMode(OutputPin, OUTPUT);

  attachInterrupt(digitalPinToInterrupt(InputPin), InputISR, RISING);
}

void InputISR()
{
  unsigned long thisInterruptTime = micros();
  InputCycleTime = thisInterruptTime - PreviousInterruptTime;
  PreviousInterruptTime = thisInterruptTime;
}

unsigned long ConvertToHalfCycleTime(unsigned long inputCycleTime)
{
  return inputCycleTime * 2.7; 
}

void loop()
{
  unsigned long currentMicros = micros();
  static unsigned long lastOutputChangeTime = 0;

  noInterrupts();
  unsigned long ict = InputCycleTime;
  unsigned long pit = PreviousInterruptTime;
  interrupts();

  // Only pulse output if the time since the last interrupt is less than one second.
  if (currentMicros - pit < 1000000ul)
  {
    unsigned long outputHalfCycleTime = ConvertToHalfCycleTime(ict);
    
    if (currentMicros - lastOutputChangeTime >= outputHalfCycleTime)
    {
      lastOutputChangeTime = currentMicros;
      digitalWrite(OutputPin, !digitalRead(OutputPin)); 
    }
  }
}

Can you got into more detail? Not everyone here in the forum has that rather exotic core installed.

Why does it have to be a Tiny with only 64 bytes of RAM?

To save RAM, inline the ConvertToHalfCycleTime function and replace the currentMicros variable by direct calls to millis(). That's not much but might save the relevant bytes.

Another problem could be that you are using floats which are emulated with software and thus require extra memory to compute. You could avoid the float operation and get close to the result with either return inputCycleCount + inputCycleCount + (inputCycleCount / 10 * 7) or return (inputCycleCount * 2) + (inputCycleCount / 10 * 7). Dunno if it helps, though..

That helps a ton.

using your suggestion

unsigned long ConvertToHalfCycleTime(unsigned long inputCycleTime)
{
  return (inputCycleTime * 2) + (inputCycleTime / 10 * 7); 
}

compiles to this on the T13

Sketch uses 748 bytes (73%) of program storage space. Maximum is 1024 bytes.
Global variables use 18 bytes (28%) of dynamic memory, leaving 46 bytes for local variables. Maximum is 64 bytes.

Just mind that it is not as accurate as a float operation.

The micro's on a T13 are not accurate either, so that is a nice match :slight_smile:

Care to expand on this with some facts?

The processor only supports running from the internal 9.6 MHz clock. There is no amount of math and AVR clock tick counting that gets to 1 microsecond.

Plus, the internal oscillator has some jitter, drift, and can only be tuned to about ±0.1 % under ideal conditions.

Thanks.

1 Like

do NOT use floating point. If your input is a long, and your output is a long, do something like return (inputCycleTime * 270 + 50) / 100;

Comments taken from wiring.c in the source code of microcore

/***** MICROS() *****/
// Enabling micros() will cause the processor to interrupt more often (every 2048th clock cycle if
// F_CPU < 4.8 MHz, every 16384th clock cycle if F_CPU >= 4.8 MHz. This will add some overhead when F_CPU is
// less than 4.8 MHz. It's disabled by default because it occupies precious flash space and loads the CPU with
// additional interrupts and calculations. Also note that micros() aren't very precise for frequencies that 64
// doesn't divide evenly by, such as 9.6 and 4.8 MHz.

Yes, probably better because it does proper rounding. This is probably the simplest: return inputCycleTime * 27 / 10; and will only be off by at most 1 and thus is better than my suggestion in #3.

Thank you everyone for your suggestion and valuable time. I think suggestion at post #12 had solved the issue and storage space reduced to 48%.

1 Like

6 posts were split to a new topic: To shift or not to shift?

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.