ATNEL tech-forum

Re: Losowe zachowanie PWM Atmega88PA

2016-07-13T00:58:00+01:00

Sprawdziłem i faktycznie rozwiązanie z dodatkowym przerwaniem okazało się strzałem w dziesiątkę.

Wielkie dzięki za pomoc

Statystyki: Napisane przez stefan_bak — 13 lip 2016, o 00:58

Re: Losowe zachowanie PWM Atmega88PA

2016-07-08T19:18:29+01:00

stefan_bak napisał(a):

Przez chwilę myślałem, że źródłem problememu jest zbyt duża częstotliwość modyfikowania rejestrów OCR1B oraz ICR1. Rozumiem, że skoro mogę to teoretycznie zmieniać przy każdym przepełnieniu timera1, to moja teoria raczej odpada?

Raczej nie częstotliwość tu decyduje, a przypadkowość momentu zmiany wartości ICR1. Podejrzewam, że problem będzie podobnej natury jak w tym wątku: http://forum.atnel.pl/topic15630.html#p162736
tylko w Twoim przypadku wartość TOP znajduje się w ICR1. Rozwiązanie, które zaproponowałem, polega na tym, że w momencie zmiany ICR1 wartość TCNT1 będzie zawsze bardzo niska, więc ICR1 zawsze będzie większe. W tej chwili moment ten jest dosyć przypadkowy, bo timery 1 i 2 nie pracują synchronicznie, to znaczy mają inne interwały czasowe, które nie są prawdopodobnie podzielne przez siebie bez reszty, tym bardziej, że przecież okres zliczania timera 1 zmienia się po zmianie ICR1.

stefan_bak napisał(a):

Dodam, że wykonałem jeszcze jeden test, a mianowicie zmieniłem w przerwaniu timera2, żeby set_frequency nie było wywoływane co 20 przerwań, a co 100 i wtedy problem nie występował przez kilka minut ciągłej pracy.

Podejrzewam, że zmniejszenie częstotliwości wywołania funkcji set_frequency() to tylko zmniejszenie prawdopodobieństwa, a problem prędzej czy później i tak wystąpi. Chwila, w której to będzie następować może być zależna od melodii, czyli od wartości ICR1 z tablicy.

Statystyki: Napisane przez andrews — 8 lip 2016, o 19:18

Re: Losowe zachowanie PWM Atmega88PA

2016-07-08T18:08:21+01:00

Dzięki za szybkie odpowiedzi. Dopiero jutro sprawdzę jak zachowa mi się kontroler z proponowanymi zmianami, jednak mam pytanie co do rady o volatile. Samo scheme_buffer nie jest volatile, a tylko zmienna prescaler_time. Wydawało mi się, że skoro inkrementuje ją przerwanie oraz resetuje funkcja Play, to jednak trzeba użyć volatile.

Przez chwilę myślałem, że źródłem problememu jest zbyt duża częstotliwość modyfikowania rejestrów OCR1B oraz ICR1. Rozumiem, że skoro mogę to teoretycznie zmieniać przy każdym przepełnieniu timera1, to moja teoria raczej odpada?

Dodam, że wykonałem jeszcze jeden test, a mianowicie zmieniłem w przerwaniu timera2, żeby set_frequency nie było wywoływane co 20 przerwań, a co 100 i wtedy problem nie występował przez kilka minut ciągłej pracy.

Statystyki: Napisane przez stefan_bak — 8 lip 2016, o 18:08

Re: Losowe zachowanie PWM Atmega88PA

2016-07-08T17:27:13+01:00

doktur napisał(a):

Tak na pierwszy rzut oka to tylko to że skoro scheme_bufer jest wykorzystywany i w przerwaniu i nie to powinno być z volatile.

Przerwanie używa tylko wskaźnika do 'scheme_buffer', a ten jest stały, więc volatile nie jest potrzebne.

Proponowałbym spróbować tak:

Zadeklarować dwie zmienne globalne:[syntax=c]volatile uint16_t OCR1B_value = 0xFF;
volatile uint16_t ICR1_value = 0xFFFF;[/syntax]

Funkcję set_frequency() zmienić na:[syntax=c]void set_frequency(const uint8_t* params)
{
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) /* zabezpieczenie, gdyby funkcja była wywoływana */
/* nie tylko wewnątrz procedury obsługi przerwania */
{
OCR1B_value = *params;
ICR1_value = *(params + 1);
}
}[/syntax]

We funkcji Init_buzzer() włączyć przerwanie od przepełnienia timera 1:[syntax=c]TIMSK1 = (1< OCR1B = OCR1B_value;
ICR1 = ICR1_value;
}[/syntax]

Powinno pomóc

Statystyki: Napisane przez andrews — 8 lip 2016, o 17:27

Re: Losowe zachowanie PWM Atmega88PA

2016-07-08T16:29:32+01:00

Tak na pierwszy rzut oka to tylko to że skoro scheme_bufer jest wykorzystywany i w przerwaniu i nie to powinno być z volatile.

Może jakaś inna część kodu bruździ?

Pozdrawiam

Statystyki: Napisane przez doktur — 8 lip 2016, o 16:29

Losowe zachowanie PWM Atmega88PA

2016-07-08T15:42:25+01:00

Cześć,
Mam problem z PWM sterowanym z timera1 używanym do sterowania on buzzerem. Działa to tak, że timer2 odlicza konkretny czas, aby zmienić częstotliwość dla PWM. W tablicy mam zapisane kilka zestawów częstotliwości, na które po kolei ma się przestawiać PWM, co daje w efekcie krótką melodyjkę. Na potrzeby testów zmieniłem program, żeby po wywołaniu funkcji Play wywoływał na przemian tylko dwie częstotliwości i ku memu zdumieniu działa to bardzo losowo. Np. 30 sekund gra tak jak powinien, następnie zawieszą się i przez sekundę w ogóle nie wydaje dźwięku albo nie działa jeden z tonów i efekt jest taki, że na przemian gra i cichnie. Pomierzyłem oscyloskopem i wygląda na to, że winnym jest PWM, licznik timer2 wywołuje się prawidłowo - regularnie, natomiast zachowanie PWM jest totalnie losowe. Poniżej załączam kod obsługujący buzzer oraz krótki film z obrazem z oscyloskopu oraz dźwiękiem buzzera (przyciąłem tak, żeby było widać przejście, ale dzieję się tak za każdym razem inaczej i po kolejnym losowym czasie zestaw sam znowu wraca do tonu z początku). Męczę się już z tym jakiś czas i nie mam pojęcia co tam się może dziać. Funkcja Play jest wywoływana z raspberry pi pi I2C. Ogólnie komunikacja z Atmegą działa i jej inne zadania również, więc wnioskuje, że nie zawiesza (resetuje) się cały procesor, a jedynie PWM.

Film:

iframe

Code:

#include 
#include 
#include 


#include "buzzer.h"
volatile uint16_t prescaler_timer = 0;
volatile uint8_t test = 0;
uint8_t scheme_buffer[12];

const uint8_t schemes[] PROGMEM = {
                            0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                            0x28, 0x2A, 0xFF, 0xFF, 0x28, 0x2A, 0x28, 0x2A, 0xFF, 0xFF, 0xFF, 0xFF,
                            0x28, 0x2A, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                            0x28, 0x2A, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                            0x28, 0xE0, 0xFF, 0xFF, 0x28, 0xE0, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                            0x28, 0xE0, 0xFF, 0xFF, 0x28, 0xE0, 0xFF, 0xFF, 0x28, 0xE0, 0xFF, 0xFF,
                            0x28, 0x2A, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                            0x28, 0x2A, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                            0x28, 0x2A, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                            0x28, 0x2A, 0xFF, 0xFF, 0x28, 0x2A, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
                        };

void set_frequency(const uint8_t* params)
{
   OCR1B = *params;
   ICR1 = *(params + 1);
}

ISR (TIMER2_COMPA_vect)
{
   if(prescaler_timer % 30 == 0)
   {
      //if(prescaler_timer < 120)
         set_frequency(scheme_buffer + ((prescaler_timer / 30) % 2));
      //else
      //   prescaler_timer = 99;
   }
   if(prescaler_timer == 300)
      prescaler_timer = 0;
   prescaler_timer++;

}

void Init_buzzer()
{
   DDRB |= (1 << PB2);

   TCCR1A |= (1 << COM1B1) | (1 << WGM11);
   TCCR1B |= (1 << WGM12) | (1 << WGM13);
   
   TCCR1B |= (1 << CS11) | (1 << CS10);
   
   OCR1B = 0xFF;
   ICR1 = 0xFFFF;

   
   TCCR2A = (1 << WGM21);
   TCCR2B = (1 << CS20) | (1 << CS21) | (1 << CS22);
   TCNT2 = 0;
   OCR2A = 71;
   TIMSK2 = (1 << OCIE2A);
}

void Play(uint8_t scheme)
{
   memcpy_P(scheme_buffer, schemes + (scheme * 12), 12);
   TCNT2 = 0;
   prescaler_timer = 0;
}

Statystyki: Napisane przez stefan_bak — 8 lip 2016, o 15:42