atricault:
Note that this sketch works great before I've updates Arduino IDE, boards and libraries...
Are you saying that it worked as expected on the ATtiny84 before you did some updates, and after the updates pulseIn() was no longer working as expected?
If so, do you remember which version of ATTinyCore you were using before the update?
Post the code. You may be doing something which makes the sketch particularly vulnerable to timing issues.
Are you using a 16MHz crystal oscillator with the ATtiny84 ?
I don't use external oscillator, and I'm using the Attiny at 8Mhz.
This is the code
#include <ATTinyCore.h>
#include "SoftwareSerial.h"
const int PWM_IN_PIN= 5;
const int LED_PIN= 8;
int msStatus = 1;
int ledState = HIGH;
long previousMillis = 0;
int intervalLed = 500;
const int MAX_PWM_VAL = 2200;
const int MIN_PWM_VAL = 800;
const int MIDDLE_PWM_VAL = (MAX_PWM_VAL + MIN_PWM_VAL) / 2;
const int DEBUG_RX= -1;
const int DEBUG_TX= 7;
SoftwareSerial mySerial(DEBUG_RX, DEBUG_TX);
void setup() {
//Configuration de la led et allumage
pinMode(LED_PIN, OUTPUT);
digitalWrite(LED_PIN, HIGH);
pinMode(PWM_IN_PIN, INPUT_PULLUP);
mySerial.begin(9600);
}
void loop() {
noInterrupts();
unsigned long pulseRead = pulseIn(PWM_IN_PIN, HIGH, 60000);
interrupts();
mySerial.println(pulseRead);
mySerial.flush();
//Lecture du signal IN PWM
if(pulseRead > MIDDLE_PWM_VAL && pulseRead < MAX_PWM_VAL){
if(msStatus){
stopm();
}
}else{
if(! msStatus ){
startm();
}
}
if(intervalLed > 0){
unsigned long currentMillis = millis(); // stocke la valeur courante de la fonction millis()
if(currentMillis - previousMillis > intervalLed) {
// mémorise la valeur de la fonction millis()
previousMillis = currentMillis;
// inverse la variable d''état de la LED
if (ledState == LOW){
ledState = HIGH;
}else{
ledState = LOW;
}
// modifie l'état de la LED
digitalWrite(LED_PIN, ledState);
}
}
}
void stopm(){
if(msStatus){
msStatus = 0; //On coupe le signal PWM
//Gestion de la led, clignotement à 2Hz
intervalLed = 100;
}
}
void startm(){
if(! msStatus){
msStatus = 1; //On coupe le signal PWM
//Gestion de la led, clignotement à 2Hz
intervalLed = 500;
}
}
When you used the Nano, did you also use softwareSerial or did you use the normal hardware serial port ?
That and with only an 8MHz clock makes the results of the Nano and the ATtiny84 difficult to compare.
What is the frequency of the PWM signal ?
Does it appear to work better if you comment out the debug print statements ? These will be slow.
6v6gt:
When you used the Nano, did you also use softwareSerial or did you use the normal hardware serial port ?
That and with only an 8MHz clock makes the results of the Nano and the ATtiny84 difficult to compare.
What is the frequency of the PWM signal ?
Does it appear to work better if you comment out the debug print statements ? These will be slow.
In fact I added SoftwareSerial for debug purpose... It was not working without SoftwareSerial.
I tired also with 4MHz and 1Mhz, I get the same result.
I tried several PWM signals, but the signals I tried to get is :
1200us, then I read 765us with ATTiny
1800us, then I read 1150us with ATTiny
If I check the ratio between original signal and read signal, I get around 64%...
Hello, I am dealing with the same problem - attiny84 and RC PWM signal read via PulseIn stopped working properly after recent update. I was delaying all updates to Arduino software and boards since few months, and I have no idea which was the last working combination ;(
But I will try to downgrade and find out working solution to this = Arduino + attiny84 Core by Spence Konde (aka Dr. Azzy).
Also while I was gasping for space to fit my code and managed 99%, after the upgrade suddenly my code was using 78% of space
A fix for this issue is in github version and will be in next release.
With recent compiler versions, the loop used for pulseIn gets optimized differently, and the code depends on knowing how many cycles the loop is (interestingly, the optimization on the new compiler is worse - the loop runs more slowly!). The fix is simply to pull in the pre-compiled loop and slightly modified version of pulseIn as used in the official core.
What's sort of interesting is that this bug has been present since circa 1.6.11, and nobody noticed until now, when two people reported it (one on t85 on github, the other on t84 here). pulseIn() doesn't seem to be the most popular function on the block, but all of a sudden...
Spent hours on this. pulseInLong now works in github version, at least the timeout it gets is right - pulseIn itself is completely mangling the 'timeout' parameter, though, and I am not sure why....
Follow this issue on github for updates.... there is something that I am missing here....
The quick fix worked for the length of pulses, though it didnt honor timeout properly (if no pulse was detected, timeout expired in 11/16ths of the specified time). After taking forever to understand what was actually going on, I confirmed that it was also broken in the official core, and also that only the first two pieces of the loop were running fast. the third part that actually times the pulse was fine (but to "simplify" the testing, I was only testing the timeout with no pulse - I foolishly assumed that the function did what the reference said it did). Honestly, had I recognized those two facts, i could have saved myself many hours.
Armed with that knowledge, I was able to slow down the first two loops by adding some no-op's, and now timeout is honored when no pulse is detected. After some testing with short pulses to make sure I haven't thrown off the accuracy there (though I don't think I could have), will submit PR to official core. As far as I can tell, this (as in the timeout issue, not problems with actual pulse lengths) has been broken literally as long as pulseIn has existed!
