Software Serial problem ATtiny85

[walllyyy_3]

Good morning,
I apologize if I was unable to participate in the discussion earlier but I was busy.

---

So it seems to be a problem from the “Arduino AVR” platform, which has some bugs?
Perhaps waiting for a new update the problem could be solved.

So as suggested by @maxgerhardt it was enough to switch to the development version as reported in the repository?
In addition, as mentioned by @normandunbar, the delay function also produces an error on the set time.
I didn’t pay too much attention to it (as my serial monitor doesn’t show me the timestamps) but I definitely saw that the messages didn’t arrive at a constant rate.

---

@normandunbar

So the fuses are indeed correct, however, on connecting a scope (Espotek Labrador – I can afford a proper scope!) to pin PB0, I see a period of 4 seconds and a frequency of 245 MHz. This is obviously wrong as the LED is off for 2 seconds and on for 2. The result is the same if I specify the board_build.f_cpu or leave it to default.

If I upload the same sketch, from the Arduino IDE, I get the period to correctly be 2 seconds and the frequency is 498 MHz. Checking the fuses with avrdude I see they are still the same as set by PlatformIO. Just to be doubly sure, I “burned a bootloader” with the Arduino IDE set to 8MHz internal oscillator, and the fuses burned were exactly as per PlatformIO.

In this case the value of 245 MHz and 498 MHz refers to the PWM frequency, right?
Because with a period of 4s the resulting frequency is far from that value.

BTW, Nice oscilloscope! I took a look and it looks really nice. My oscilloscope instead is the DSO150, is not very accurate but it does its job.

---

@maxgerhardt

There is an off-by-factor-2 somewhere. It must be somewhere in the build settings.

I noticed that the platform-atmelavr has had a recent update with regards to ATTiny85. Maybe the bug is already resolved? What happens you do

platform = https://github.com/platformio/platform-atmelavr.git

instead of of platform = atmelavr in the platformio.ini?

Sounds cool!

Just to be precise I would like to check if this modification also corrects the PWM frequency (bringing it to 36kHz).
After all, I can also define too that this could be the definitive solution for now (platform updates aside).

---

@normandunbar

Digging further, it seems this was known about, ATtiny85 runs at half speed due to bad clock source setting · Issue #264 · platformio/platform-atmelavr · GitHub already!

Cheers,
Norm.

I apologize if it was not new, but I did not really know where to look to be able to solve this problem

---

And so now I just have to apply these changes and do some more experiments.

In the meantime, thank you for the help.

Cheers

[normandunbar]

@walllyyy_3

So as suggested by @maxgerhardt it was enough to switch to the development version as reported in the repository?

Yes. That resolved the problems. Looking at the fix in the code, it seems that a recent change had snafu’d the clock. The development version fixes the problem.

The frequencies I mentioned in my testing simply refer to the 2 and 4 second periods, not to the PWM frequency. That is, at least on the ATmega328P, defined by the prescaler for the timer generating the PWM signal, and the PWM mode.

When I mentioned that it was a known problem, I was not thinking that you hadn’t done enough research, apologies if you thought so. I was just mentioning it in passing to everyone, for information.

Cheers,
Norm.

[walllyyy_3]

@normandunbar

The frequencies I mentioned in my testing simply refer to the 2 and 4 second periods, not to the PWM frequency. That is, at least on the ATmega328P, defined by the prescaler for the timer generating the PWM signal, and the PWM mode.

I apologize but I did not understand this part,
if the period were 4 sec the frequency would not be
245 MHz (245 x 10 ^ 6 Hz)
but about 0.25 Hz (1 / 4s = 0.25 Hz)

in the same way

if the period was 2 sec
would not be 498 MHz (498 x 10 ^ 6 Hz)
but about 0.5 Hz (1 / 2s = 0.5 Hz)

Could it be so?
Perhaps I may have misunderstood it, and to be correct I have reported how I understood it in the lines above.
Or maybe did you mean M as m (mHz) (milihertz) (10 ^ -3) which would make sense.

---

@normandunbar

When I mentioned that it was a known problem, I was not thinking that you hadn’t done enough research, apologies if you thought so. I was just mentioning it in passing to everyone, for information.

No problem, indeed thanks for reporting that link, certainly very useful.

---

However in conclusion I can confirm that the PWM now works at the right frequency!!

Here is the super simple code that I’m using to do these tests

#include <Arduino.h>
#include <SoftwareSerial.h>

SoftwareSerial SWSERIAL(8, 0);  // RX, TX

const byte pwm_CTL = 1;

void setup() {

  //PWM freq. 
  TCCR1 = TCCR1 & 0b11110000 | 0b0001;

  pinMode(pwm_CTL,OUTPUT);

  SWSERIAL.begin(4800);
}

// the loop routine runs over and over again forever:
void loop() {
	
  SWSERIAL.println("Ping");
  delay(1000);
  analogWrite(pwm_CTL,0);
  delay(1000);
  analogWrite(pwm_CTL,64);
  delay(1000);
  analogWrite(pwm_CTL,127);
  delay(1000);
  analogWrite(pwm_CTL,191);
  delay(1000);
  analogWrite(pwm_CTL,255);
}

The prescaler for the Timer1 it should be 1 and it should generate a frequency of about 36kHz.
And in addition I attach the resulting PWM waveform (duty: ⁓25%, analogWrite (64)) acquired by my scope (sorry for the low quality) but I think it is understandable.

And this verifies that the frequency obtained on D1 is consistent with the configuration of the Timer1 prescaler

---

In conclusion, thank you again @maxgerhardt and @normandunbar , for helping me to solve this problems, now I can continue with my work on this temperature controller!

Cheers!

[normandunbar]

@walllyyy_3

Or maybe did you mean M as m (mHz) (milihertz) (10 ^ -3) which would make sense.

Good point! Maybe I need to check again and see what I think I read from the scope

Cheers,
Norm.

[normandunbar]

Yup, looks like it’s milliHertz not megaHertz as I posted. My bad.

Cheers,
Norm.

[walllyyy_3]

@normandunbar

Yup, looks like it’s milliHertz not megaHertz as I posted. My bad.

Cheers,
Norm.

Sounds cool! The important thing is to have made this clear.

Cheers!