[Jarewa0606]

to PWM było na poziomie 55% a sygnał ok. Wiec problem masz w kodzie

[MERASerwis]

@Jarewa0606 potrafisz używać rejestrów układów peryferyjnych po co jeszcze bawisz się w arduino? Nie czas porzuć je i zacząć pisać w np AS co pozwoli używać debugera?

Kolega jak taki mądry to niech pomoże.

Zmień srajduino na STM32 albo ostatecznie na AS i zaopatrz się w debuger to pomogę.
Na STM32 nie mam problemu aby sprzętowo mierzyć okres czy częstotliwość i robić dziesiątki innych rzeczy. Z AVRmega/tiny jest gorzej. Na Xmega dużo lepiej niż na mega/tiny ale cena odstrasza.
Temat pomiaru między innymi okresu i przeliczania go na częstotliwość został poruszony https://forum.elportal.pl/viewtopic.php?f=62&t=15013 i https://www.elektroda.pl/rtvforum/topic3657281.html na AVR + CPLD https://www.elektroda.pl/rtvforum/viewto...0#16729540. Na podstawie tego w AVT powstały AVT3275 i AVT5575.

Z srajduino problemy są takie, ze nie wspiera debugera. Biblioteki skopane, nawet digital write jest napisane źle. Timer jakieś cuda na kiju i przeskoki co 125ms. Obsługa kolorowych wyświetlaczy graficznych tragedia, to chyba ktoś z u$oft pisał tak jak i wire, które się zawiesza i w praktyce może służyć tylko do zabawy. Aby tego używać trzeba napisać od nowa. Kolejny problem śladowe ilości ram w AVR, bo arduino głównie na AVR jest robione, to się co prawda powoli zmienia ale biblioteki jak były kiepskie tak są coraz gorsze, pulseIn nie korzysta z timerów, mierzy czas niedokładnie a co gorsza blokuje program główny na czas pomiaru -żenada, spróbuj zmierzyć 500ms i odbierać dane po UART przychodzące w większych ilościach niż pomieści bufor. O braku DMA i przywiązaniu AVR-GCC do int o rozmiarze 16-bit nie wspomnę bo chyba to co napisałem wystarczy.

[m72]

@Jarewa0606 potrafisz używać rejestrów układów peryferyjnych po co jeszcze bawisz się w arduino? Nie czas porzuć je i zacząć pisać w np AS co pozwoli używać debugera?

Kolega jak taki mądry to niech pomoże.

Zmień srajduino na STM32 albo ostatecznie na AS i zaopatrz się w debuger to pomogę.
Na STM32 nie mam problemu aby sprzętowo mierzyć okres czy częstotliwość i robić dziesiątki innych rzeczy. Z AVRmega/tiny jest gorzej. Na Xmega dużo lepiej niż na mega/tiny ale cena odstrasza.
Temat pomiaru między innymi okresu i przeliczania go na częstotliwość został poruszony https://forum.elportal.pl/viewtopic.php?f=62&t=15013 i https://www.elektroda.pl/rtvforum/topic3657281.html na AVR + CPLD https://www.elektroda.pl/rtvforum/viewto...0#16729540. Na podstawie tego w AVT powstały AVT3275 i AVT5575.

Z srajduino problemy są takie, ze nie wspiera debugera. Biblioteki skopane, nawet digital write jest napisane źle. Timer jakieś cuda na kiju i przeskoki co 125ms. Obsługa kolorowych wyświetlaczy graficznych tragedia, to chyba ktoś z u$oft pisał tak jak i wire, które się zawiesza i w praktyce może służyć tylko do zabawy. Aby tego używać trzeba napisać od nowa. Kolejny problem śladowe ilości ram w AVR, bo arduino głównie na AVR jest robione, to się co prawda powoli zmienia ale biblioteki jak były kiepskie tak są coraz gorsze, pulseIn nie korzysta z timerów, mierzy czas niedokładnie a co gorsza blokuje program główny na czas pomiaru -żenada, spróbuj zmierzyć 500ms i odbierać dane po UART przychodzące w większych ilościach niż pomieści bufor. O braku DMA i przywiązaniu AVR-GCC do int o rozmiarze 16-bit nie wspomnę bo chyba to co napisałem wystarczy.

Niech kolega się tak nie nabzdycza i daruje sobie AGITACJE. 
STM-a mam, bawiłem się HAL-em. Projekt db-miarki na STM poniżej. 



Xmegi też trochę poznałem, nawet zrobiłem na niej wariometr do paralotni ale 
do tak pierdółkowatych projektów jak obrotomierz + jakaś temperatura itp nie będę się męczył z AS i ansi C  choćby ze względu to że chcąc dołożyć kolejne urządzenia np wyświetlacz oled, jakąś termoparę tudzież inny czujnik ciśnienia ( a to jest w planie, bo obrotomierz jest tylko częścią projetku) - znajdę się w tak czarnej dup.. że przez rok z tego nie wyjdę na STM-ach albo Xmegach.
Pozdro i zamiast agitować to pomóż skoro żeś taki kozak  

ps. Xmegi - fantastyczne procki, szkoda że się nie przyjęły i nie ma dla nich odpowiednika arduinowego. Atmegi to bieda przy X-ach. 
Sprzętowa obsługa enkoderów mnie powaliła, zero gubienia kroków przy kręceniu enkoderem za pomocą silnika !
ale niestety, brak bibliotek ud.pia większość projektów takich amatorów jak ja - który się w to bawi 2 razy do roku i potrzebuje G O T O W C Ó W bo to jest dla mnie zabawa a nie praca.

[MERASerwis]

do tak pierdółkowatych projektów jak obrotomierz + jakaś temperatura itp nie będę się męczył z AS i ansi C  choćby ze względu to że chcąc dołożyć kolejne urządzenia np wyświetlacz oled, jakąś termoparę tudzież inny czujnik ciśnienia ( a to jest w planie, bo obrotomierz jest tylko częścią projetku) - znajdę się w tak czarnej dup.. że przez rok z tego nie wyjdę na STM-ach albo Xmegach.

Wolisz walczyć z bibliotekami Arduino? Zaczniesz dokładać OLEDY i inne peryferia i zacznie się jazda. Używałeś STM32, Xmega to szkoda czasu na arduino.

Pozdro i zamiast agitować to pomóż skoro żeś taki kozak  

1. Pomogę ale nie na arduino. Po prostu szkoda czasu na zawracanie Wisły kijem.
2. Już pomogłem, napisałem aby użyć ICP
3. "potrzebuje G O T O W C Ó W " dalej napisałem na ich temat .Mogę napisać kod, który chcesz dla srajduino, skromne 100zł/h ale za jakieś 2 tygodnie. Jak chcesz w ekspresie to 300zł/h.

ps. Xmegi - fantastyczne procki, szkoda że się nie przyjęły i nie ma dla nich odpowiednika arduinowego. Atmegi to bieda przy X-ach. 

Xmega się nie przyjęły, z dwóch powodów:
- Nadal jest to 8-bit w cenie wyższej niż 32-bit.
- Ma rozbudowane peryferia przez co "programiści", którzy są "przyspawani" do prostych peryferii AVR nie chcą się na nowo uczyć ich obsługi.
Podobny los będzie czekał nowe AVRmega/tiny z peryferiami z Xmega.
Gdy zmieniałem platformę, bo AVR mi nie wystarczały, przez chwilę pomyślałem o Xmega ale gdy porównałem cenę do ARM wybór był prosty, bo czy zmieniam AVRmega na ARM czy Xmega to nauki nowych peryferii tyle samo a dodatkowo, do STM32 jest CubeMX. Teraz używam całego pakietu z kompilatorem CubeXDE. Nie wiem czy dla Xmega jest coś podobnego ale nawet jeśli tak, to nie mam zamiaru walczyć z problemami x <<= 16 czy sscanf i sprintf na więcej niż 16 bit no i Xmega, biorąc pod uwagę możliwości, powinna kosztować kilka razy mnie niż ARM a kosztuje więcej.

Sprzętowa obsługa enkoderów mnie powaliła, zero gubienia kroków przy kręceniu enkoderem za pomocą silnika !

STM32 ma jeszcze lepsze peryferia niż Xmega, nie ma śladowych ilości RAM, jak trzeba to 1MB można mieć wbudowanej. Szybszy średnio 7 razy przy tym samym zegarze, zegary 400 czy 600MHz nie sa niczym nadzwyczajnym. ARM to 32-bit więc prawie nie ma (poza 64-bit i double) zabaw w ATOMIC_BLOCK a najważniejsze - cena.

potrzebuje G O T O W C Ó W bo to jest dla mnie zabawa a nie praca.

Gotowce z Internetu to najczęściej chłam i wymagają gruntownej zmiany. Czasem prościej i szybciej napisać samemu. Wiem to po bibliotekach, które przenosiłem kiedyś z srajduino na AVR teraz na ARM. Są napisane bardzo ale to bardzo źle, zwłaszcza graficzne ale czego wymagać od bibliotek pisanych przez amatorów jeśli takie pulseIn, które w tym przypadku rozwiązałoby problem, jest napisane beznadziejnie źle.
Arduino to zabawka, trzeba o tym pamiętać. Plastikową piłą z zestawu dla dzieci też można ciąć ale czy ktokolwiek rozsądny użyłby tego przy budowie choćby taboretu? Z Arduino jest to samo, można pokazać, że coś tam działa ale gdy chce się tego użyć w praktyce, okazuje się, że są problemy.

[m72]

Dobra, kolega się już popisał więc niech więcej nie zajmuje miejsca w tym wątku.

[Robson Kerman]

Napisałem kiedyś dla kolegi z forum taki prosty licznik.
Jest dosyć dokładny, ale powinieneś poeksperymentować z ilością zbieranych próbek w linii 16, pamiętając że wzór na częstotliwość się zmieni (linia 42)

Kod:

/*
    Name:       LicznikCzestotliwosci.ino
    Created:    2019-11-27 22:08:49
    Author:     Robson Kerman
*/
volatile int startTime;
volatile int stopTime;
volatile int periodTime;
volatile int omega;


void licznik()
{
    if(omega==0) startTime = millis();
    omega++;
    if (omega > 99)
    {
        stopTime = millis();
        periodTime = stopTime - startTime;
        omega = 0;
    }
    
}

void setup()
{
    Serial.begin(9600);    
    pinMode(2, INPUT_PULLUP);
    attachInterrupt(digitalPinToInterrupt(2), licznik, RISING);
    pinMode(10,OUTPUT);
    analogWrite(10, 128);

}

void loop()
{
    Serial.print("Czas ");
    Serial.println(periodTime);
    Serial.print("Omega ");
    Serial.println(omega);
    Serial.print("Czestotliwosc  ");
    int f = 100000 / periodTime;
    Serial.println(f);
}

[m72]

Poddaje się, to jakiś psychiatryk.

Spróbowałem to przepisać na funkcji "micros"

Kod:

volatile int32_t  licznik;
volatile int32_t  licznik_old;
volatile int32_t  roznica;
volatile int32_t  roznica_old;

void setup() {
    Serial.begin(2000000);   
    //pinMode(2, INPUT_PULLUP);
    attachInterrupt(digitalPinToInterrupt(2), przerwanie, FALLING);
}
void loop() {
   if (roznica != roznica_old){
        Serial.print("Roznica: ");Serial.println(roznica);
        roznica=roznica_old;
  }   
   
}

void przerwanie()
{
   
    licznik = micros();
    roznica=licznik-licznik_old;
    licznik_old=licznik;
         
}

 
I dalej jest to samo !
Oto wyniki przy zapodaniu na wejście 10Hz.

Kod:

Roznica: 45276
Roznica: 55036
Roznica: 45272
Roznica: 55036
Roznica: 45276
Roznica: 55032
Roznica: 45276
Roznica: 55032
Roznica: 45276
Roznica: 55036
Roznica: 45276
Roznica: 55032
Roznica: 45276
Roznica: 55032
Roznica: 45276
Roznica: 55036
Roznica: 45276
Roznica: 55032
Roznica: 45280
Roznica: 55028
Roznica: 45276
Roznica: 55032
Roznica: 45276
Roznica: 55036
Roznica: 45276
Roznica: 55032
Roznica: 45276
Roznica: 55032
Roznica: 45280
Roznica: 55032
Roznica: 45276

 
Cały czas naprzemiennie lecą dwie zbliżone do siebie warości, nie zależnie od częstotliwości.

Słuchajcie problem jest moim zdaniem z tym że przerwanie jest wywoływane zarówno na opadającym i rosnącym zboczu bo wystarczy zsumować dwa kolejne wyniki i zawsze wychodzi prawie idealnie 100tys mikrosekund czyli prawidłowo dla 10Hz .

[Robson Kerman]

A próbowałeś przerwania w innych trybach?

[elvis]

m72 skoro program z obsługą przerwania nie działa jak powinien proponuję zrobić krok wstecz i napisać program bez przerwań. Przykładowy program do przetestowania wygląda następująco:

Kod:

#define N_SAMPLES  10

void setup() {
  Serial.begin(115200);
  pinMode(2, INPUT);
  pinMode(2, INPUT_PULLUP);

  Serial.println("hello!");
}

void loop() {
  static int samples[N_SAMPLES];
  static int n_samples = 0;
  static int prev_value = digitalRead(2);

  while (n_samples < N_SAMPLES) {
    int value = digitalRead(2);
    if (prev_value != value) {
      samples[n_samples++] = millis();
      prev_value = value;
    }
  }
     
  for (int i = 0; i < N_SAMPLES; i++) {
    Serial.print(samples[i]);
    Serial.println(F(" ms"));
  }
 
  while (1);
}

Uruchomiłem ten kod na Arduino Uno i przy sygnale 1Hz miałem takie wyniki:
   
Natomiast przy 10Hz:
   
Wygląda więc na to, że z sygnałem wzorcowym program zwraca to co powinien - mógłbyś przetestować ten sam program z Twoim układem? Chodzi mi o upewnienie się czy przypadkiem sygnał który "widzi" mikrokontroler nie zawiera zakłóceń.

[m72]

Dla 1Hz
hello!
510 ms
967 ms
1523 ms
1980 ms
2535 ms
2992 ms
3547 ms
4003 ms
4558 ms
5015 ms


Dla 10Hz

hello!
15 ms
70 ms
115 ms
171 ms
216 ms
271 ms
316 ms
371 ms
416 ms
472 ms