ATNEL tech-forum

Re: [ATmega88PA] Generator 20 kanałów PWM

2014-02-03T15:15:03+01:00

Świetny pomysł czasem sam też chciałbym coś przetestować i brakuje mi wolnego PWM-a a naraz jest 20 PWM Gratulacje

Statystyki: Napisane przez pawel89 — 3 lut 2014, o 15:15

Re: [ATmega88PA] Generator 20 kanałów PWM

2013-10-01T14:32:48+01:00

Dzięki za odpowiedź Mirku, teraz już wiem dlaczego robić tak a nie inaczej. Staram się pisać zgodnie z "dobrym stylem programowania", po prostu nie zdawałem sobie sprawy że to co robię jest "złe" .
Zawsze wychodziłem z założenia że najwięcej się człowiek uczy na własnych błędach - prosty projekt, a ile ciekawostek się dowiedziałem. Zmienne globalne, odpowiednie typowanie, BADISR a nawet flagi przerwań (za tę informację szczególnie dziękuję, doceniam jej znaczenie ^^).

Statystyki: Napisane przez mopsiok — 1 paź 2013, o 14:32

Re: [ATmega88PA] Generator 20 kanałów PWM

2013-10-01T11:25:17+01:00

stachu napisał(a):

Przepraszam za wprowadzanie w błąd, przykład podałem w czystym GCC dla PC

Ale nie ma za co przepraszać - wszyscy razem się tu uczymy, a przykład podałeś dobry tyle że dla zmiennych lokalnych. Przyznam, że ja nawet nie pamiętałem o tym że jak się wpisze do tablicy przy inicjalizacji pierwszą wartość w takiej zmiennej lokalnej to kolejne zostaną już uzupełnione zerami a sprawdzić też jakoś mi się nie chciało.

Więc jak widać - z takiej dyskusji zawsze można się czegoś dowiedzieć

Statystyki: Napisane przez mirekk36 — 1 paź 2013, o 11:25

Re: [ATmega88PA] Generator 20 kanałów PWM

2013-10-01T11:22:14+01:00

No cóż myliłem się późno było ale dowiedziałem się przy okazji parę ciekawych rzeczy.

Przepraszam za wprowadzanie w błąd, przykład podałem w czystym GCC dla PC

Pozdrawiam.

Statystyki: Napisane przez stachu — 1 paź 2013, o 11:22

Re: [ATmega88PA] Generator 20 kanałów PWM

2013-10-01T10:46:32+01:00

mopsiok napisał(a):

Dzięki za zainteresowanie, cieszę się że projekt nie został jakoś szczególnie skrytykowany

Projekt działa ... pokazałeś nawet dość fajne efekty. A reszta to tylko uwagi właśnie, które mogą się przyczynić do podniesienia własnego skill'a w dalszym programowaniu.

Dodam więc, tak jak mówił Antystatyczny, że akurat taką obsługę PWMów programowych też bym zrobił w przerwaniu. Flagi owszem są potrzebne no ale nie należy przesadnie do tego podchodzić bo gdyby tak miało być jak u ciebie to można byłoby JESZCZE BARDZIEJ skrócić kod i w ogóle wywalić procedurę obsługi przerwania skoro w nim jest ustawiana tylko flaga. Dlaczego ? już tłumaczę - zresztą nie pierwszy raz na tym forum .... ano dlatego że masz flagę sprzętową przerwania i z niej można korzystać dokładnie tak samo jak z tej programowej tyle tylko że tracisz O WIELE mniej czasu no i kodu we flashu robi się mniej ... jak ? o tak: (twoja pętla główna)

[syntax=c]for (;;) {
if ( TIFR0 & (1< compare();
TIFR0 |= (1< }
}[/syntax]
(a oczywiście wywalasz całego ISR'a no i przy inicjalizacji nie włączasz przerwań w tym timerze0 )

Widzisz jak prosto .... ? ... dlatego twój przykład jest można powiedzieć troszkę nawet (ale nie odbierz tego źle - żartobliwie mówię) wynaturzeniem wręcz korzystania z flag. Ja wprawdzie w niebieskiej książce podaję podobny przykład przy obsłudze RTC i ustawianiu w ten sposób flagi ... ale to TYLKO po to żeby zrozumieć w ogóle o co chodzi w tych mechanizmach flag. Warto ich używać gdy coś jeszcze się dzieje w przerwaniu i niejako przy okazji wtedy można machać flagą albo flagami do innych celów.

Do tego dodam, że u ciebie to działa bo w pętli głównej nic innego nie robisz poza obsługą tych PWM'ów .... ale gdybyś tam miał jeszcze kawał innego programu to sam byś zobaczył że nastąpiłaby MASAKRAAAA .... wtedy jedynym znowu ratunkiem byłoby przeniesienie tych porównań bezpośrednio do procedury obsługi przerwania ... a program główny robiłby swoje w pętli głównej .... taką drogą warto iść

Kolejna sprawa, to ten dziwoląg mały w kodzie

[syntax=c]ISR (BADISR_vect) {} //obsluga pozostalych przerwan[/syntax]

w ogóle niepotrzebny bo domyślnie kompilator sam to robi - to DOKŁADNIE tak samo jak z tą inicjalizacją zerami przez ciebie - niepotrzebną zresztą jak już wiesz.

--------------

unsigned char vs uint8_t

tu nie chodzi o różnicę pomiędzy typami ... bo jest to DOKŁADNIE to samo ale ... ale jest pewne ale ... o którym rzadko kto wspomina a potem początkujący tacy jak ty, którzy mówią z uporem że im się to podoba a programują w AVR GCC później mają rwanie włosów z głowy gdy przyjdzie wchodzić w dalsze bardziej zaawansowane techniki programowania - gdzie szczególnie wtedy początki są trudne ....

Po części wyjaśniam to także w swoim Bluebooku

http://atnel.pl/mikrokontrolery-avr-jezyk-c.html

i także już niejednokrotnie pisałem o tym na forum ale co tam jeszcze raz

1. char - jest DOMYŚLNIE w opcjach kompilacji w AVR GCC zamieniany i tak na unsigned char - więc już chociażby z tego powodu nie ma w ogóle sensu pisać unsigned char (znowu to coś jak z tymi inicjalizacjami zerem) ... Oczywiście można sobie wyłączyć w opcjach kompilatora tą automatyczną zamianę tylko po co panie? po co ?

A tymczasem taki początkujący jak ty - sporo piszący w AVR GCC dość szybko się przyzwyczaja do kociego unsigned char i jeszcze mówi że mu się to podoba (matko! TYLE pisaniny zamiast krótkiego uint8_t)
Ale ok pierwsza zaleta jak widać to mniej pisania, ok ktoś powie czochra mnie to, Druga w takim razie zaleta - jak widać typ uint8_t to dla oka od razu jasne jest że chodzi o unsigned int short (8-bit) ....

No i NAJWAŻNIEJSZE - uważaj teraz dobrze - przede wszystkim twórcy C stworzyli typ char jak myślisz dlaczego ? zadałeś sobie kiedyś to pytanie ? ... ja tak i poszukałem , odpowiedź jest prosta char to skrót od character, czyli znak. I właśnie ten typ zwyczajowo służył do trzymania zmiennych które związane były z trzymaniem w nich np kodów ASCII znaków .... natomiast wszelkiego rodzaju liczby trzyma się w typach wszelkiej maści int, short int, long int itp

Tyle że z kolei stwórcy AVR GCC (mądrzy ludzie zresztą) postanowili znacząco uprościć życie programistom procków i żeby nikt się nie zastanawiał za długo ile bajtów/bitów ma np typ int czy long int czy short int w AVR GCC to stworzono (i słusznie)

uint8_t
int8_t

uint16_t (odpowiednik unsigned int)
int16_t (odpowiednik int)

uint32_t

.... i tak dalej

i teraz UWAGA .... przyjdzie ci w swojej dalszej karierze AVR GCC korzystać z wbudowanych funkcji w AVR GCC szczególnie operujących na wskaźnikach do char , wskaźnikach do uintX_t itp ....

i SZLAG cię będzie trafiał gdy zaczną się pojawiać kocie warningi no bo np do jakiejś tam funkcji przekazać chcesz wskaźnik do tablicy znaków ASCII np twoja zmienna:

unsigned char tab[]="test";

funkcja( tab );

a tu warning i warning - że typy się nie zgadzają I dobrze ci tak powiedziałbym - a po co stosujesz KOCI unsigned char zamiast char panie ? Bo z punktu widzenia kompilatora to już jest RÓŻNICA którą trzeba owarningować ....

więc gdybyś szedł za poradami tych ludzi którzy stworzyli kompilator z którego korzystasz - to nie pisałbyś właśnie unsigned char tylko char (bo domyślnie kompilator i tak zamieni to na unsigned) i masz z głowy

ale jak się uprzesz to możesz zostać przy swoim kocim unsigned i funkcję wołać tak

funkcja( (char*) tab );

czyli robiąc jawne rzutowanie na typ char* ... ale skoro lubisz tyle pisania to może przy tym zostaniesz do czasu aż kiedyś i tak cię to wkurzy - tak samo jak (wciąż wracam - zerowanie zmiennych globalnych)

jak to mówią - wystarczy tylko poczytać instrukcję

------------------------

i ostatni argument dlaczego uint8_t zamiast unsigned char czy też zamiast char.

bo oczywiście taka forma syntaktycznie jest w pełni poprawna, np:

[syntax=c]char i;
for( i=0; i<10; i++ ) rób_coś_tam();[/syntax]

ale styl dobrego programowania w C a nie jakieś tam wymogi formalne mówi nam że warto to zrobić tak:

[syntax=c]uint8_t i;
for( i=0; i<10; i++ ) rób_coś_tam();[/syntax]

mniej więcej z takiego samego powodu jak ten poniżej, bo np jak widzisz takie zmienne w kodzie gdzie masz akurat tysiąc różnych zmiennych a pomiędzy nimi widać:

[syntax=c]char buf[20];
char i,z,k;
char p,m;[/syntax]

dla mnie - jak widzę taki kod - to widzę od razu niedbalstwo o typy o ich nazewnictwo, bo gdyby to napisać tak:

[syntax=c]char buf[20];
char zn;
uint8_t i,z,k;
uint8_t p,m;[/syntax]

to ja od razu na pierwszy rzut oka widzę, że O! gościu używa zmiennej tablicowej buf na jakiś bufor znaków ASCII, tak samo zmiennej zn. A pozostałe zmienne to typowe numeryczne do jakichś tam obliczeń.

Czyli NAWET z tak trywialnego kawałka kodu coś widać dla oka - na pierwszy RZUT ... a wiadomo że im dłuższy kod tym ważniejsza jest jego CZYTELNOŚĆ i PRZEJRZYSTOŚĆ. A to był jeden z NAJWAŻNIEJSZYCH celów jaki przyświecał stwórcom języka C. Tyle że ma on tak dużo możliwości i można go używać na milion sposobów, że bardzo szybko tam gdzie wkrada się niedbałość o styl dobrego programowania to kody są o wiele trudniejsze do analizy nawet dla samego siebie po kilku latach ....

Popytaj ludzi - ci którzy używają char zgodnie z tą zasadą - powiedzą ci , że jak tylko człowiek to zrozumie i się przyzwyczai to później samemu inaczej wręcz czyta się własne nawet kody programów.

O to chodzi

------------------------ [ Dodano po: 1 minucie ]

mopsiok napisał(a):

2. Przyzwyczajenia . Staram się nie pakować dłuższego kodu w obsługę przerwania, a stosować raczej flagi.

I sam widzisz - już masz przyzwyczajenia ale wcale nie najlepsze bo nie chodzi o długość ale o jakość ... to taki żarcik - ale nawiązujący też do tego co napisałem wyżej.

Statystyki: Napisane przez mirekk36 — 1 paź 2013, o 10:46

Re: [ATmega88PA] Generator 20 kanałów PWM

2013-10-01T09:46:37+01:00

Cześć!

Miło mi że rozwinęła się dyskusja w związku z moim tworem, a raczej w związku z moimi błędami programowymi . Dzięki za rady, bardzo fajnie że nie trzeba ustawiać tablic i zmiennych globalnych, doprowadzało mnie to do szału . Odpowiadając po kolei:

Antystatyczny napisał(a):

1. W jakim celu obsługujesz skok w złe przerwanie?
2. Co zadecydowało o tym, że compare() jest funkcją w pętli głównej zamiast w przerwaniu?

1. Przyznam że nie wiem, C uczyłem się z jakiejś tam książki i we wszystkich przykładach była ta obsługa. Pewnie nie ma to sensu, ale wolę dmuchać na zimne, bo to i tak tylko dwie linijki kodu.
2. Przyzwyczajenia . Staram się nie pakować dłuższego kodu w obsługę przerwania, a stosować raczej flagi.

mirekk36 napisał(a):

no i te paskudne typy [...]

Przyznam że nie bardzo rozumiem różnicę między unsigned char a uint8_t. Dla mnie to pierwsze wygląda ładniej, dlatego go używam . Poszukałem na szybko różnicy między tymi dwoma typami, ale znalazłem tylko coś o tym że to drugie informuje kompilator o tym że przechowujemy liczbę a nie znak, ale... co za różnica? Byłbym wdzięczny gdyby ktoś obeznany mi to wytłumaczył.

Dzięki za zainteresowanie, cieszę się że projekt nie został jakoś szczególnie skrytykowany .

Statystyki: Napisane przez mopsiok — 1 paź 2013, o 09:46

Re: [ATmega88PA] Generator 20 kanałów PWM

2013-10-01T04:51:22+01:00

stachu napisał(a):

Tylko skopiowałem ale dzięki za info

To prawda przynajmniej dla czystego GCC i PC bo o tym mówi standard C

Stachu nie chcę się kłócić ale ....

standard C mówi co innego wg mnie

przykłady które pokazałeś pięknie pokazują co się dzieje ze zmiennymi które inicjalizujemy jako zmienne lokalne czyli wewnątrz funkcji.

Ba! nawet w pierwszym przypadku na fotce po lewej kompilator KRZYCZY i wymiotuje warningami że tablica jest niezainicjalizowana ale że używasz kociego Atmel Studio to pewnie nawet tego nie widzisz bo domyślnie te warningi są wyłączone - a to jest właśnie jeden z wielu kamyczków z mojej strony do tego że atmel studio jest KOCIE niestety Poza tym wyjaśniam w Bluebooku co się dzieje ze zmiennymi inicjalizowanymi wewnątrz funkcji - że tworzą się na stosie i może się zdarzyć choć nie musi, że nie nie będą one miały zerowych wartości. To jest NORMALNE ... i o tym mówi standard C

ale mówi też jeszcze o czymś innym .... otóż o tym, że jeśli zmienne definiujemy jako GLOBALNE, to czy tego chcesz czy nie chcesz będą one miały ZEROWE wartości i nie ma sensu w ogóle ich inicjalizować zerem ani tak:

[syntax=c]volatile unsigned char OCR_[20] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; //wartosci programowych PWM[/syntax]

ani tak

[syntax=c]volatile unsigned char OCR_[20] = {0}; //wartosci programowych PWM[/syntax]

bo pojawią się w sekcji zmiennych globalnych gdzie wszystkie są ZEROWANE automatycznie przy starcie ... i nawet nie ma sensu ich inicjalizować wtedy zerami "tak na wszelki wypadek" bo i tak kompilator będzie miał to głęboko gdzieś Zresztą zrób sobie taki sam test jak na obrazku po lewej tylko że definicję tablicy daj w obszarze zmiennych globalnych czyli przed main ok ?

--------------------------------------------

oczywiście, że specyfikator volatile jest tu absolutnie niepotrzebny przy tej tablicy i to z dwóch powodów:

1. bo nie jest to zmienna używana w przerwaniu
2. nawet gdyby była używana w przerwaniu i programie głównym - to w przypadku tablic volatile można pominąć bo i tak dostęp do nich jeśli odwołujemy się oczywiście przez indeks do całej tablicy jest także w asemblerze w ten sam sposób obsługiwany i nie może być zoptymalizowany. Ale gdyby gdzieś w kodzie programu ktoś chciał użyć jednego elementu tablicy np &tab[3] przez wrzucenie go do zmiennej trzeba byłoby sprawdzić bo teraz nie pamiętam.

--------------------------------

mopsiok - z tego co wyżej napisałem widać, że w ogóle niepotrzebnie próbujesz inicjalizować zerem wszystkie zmienne globalne - po prostu musisz na przyszłość zapamiętać co robi standardowo kompilator będziesz miał mniej pisania

no i te paskudne typy

[syntax=c]unsigned char[/syntax]

doprowadzą cię kiedyś do rozpaczy w AVR GCC zobaczysz - po to wymyślono typ

[syntax=c]uint8_t[/syntax]

żeby go stosować w takich przypadkach....

Statystyki: Napisane przez mirekk36 — 1 paź 2013, o 04:51

Re: [ATmega88PA] Generator 20 kanałów PWM

2013-09-30T23:35:46+01:00

Tylko skopiowałem ale dzięki za info

To prawda przynajmniej dla czystego GCC i PC bo o tym mówi standard C

Statystyki: Napisane przez stachu — 30 wrz 2013, o 23:35

Re: [ATmega88PA] Generator 20 kanałów PWM

2013-09-30T22:45:19+01:00

Witam super

Może się czepiam ale warto wiedzieć, że jeżeli deklarujemy np 20 elemntową tablicę i wpiszemy jedną wartość w tablicy to automatycznie reszta wartości otrzymuje zera. W przeciwieństwie kiedy deklarujemy tylko tablice bez przypisywania jakichkolwiek wartości bo wtedy mamy przypadek dokładnie jak ze zmienną czyli mamy przypadkowe wartości.

czyli starczy zapisać

[syntax=c]volatile unsigned char OCR_[20] = {0}; //wartosci programowych PWM[/syntax]

bo reszta tablicy zostaje wypełniona zerami

wykonanie super

Pozdrawiam

Statystyki: Napisane przez stachu — 30 wrz 2013, o 22:45

[ATmega88PA] Generator 20 kanałów PWM

2013-09-30T21:53:30+01:00

Cześć!
Chciałbym po raz pierwszy na tym forum pochwalić się swoim tworem . Na wstępie zaznaczę, że ani toto nowatorskie, ani wybitne, ale kiedyś trzeba zacząć, a tak się złożyło że akurat skończyłem tworzyć coś nowego. Pragnę więc przedstawić Wam generator 20 kanałów PWM.

Projekt zrealizowany jest w oparciu o ATmegę88PA z kwarcem 20MHz. Postawiłem na prostą komunikację - 2 bajty po UART i mamy zmodyfikowany dowolny z 20 kanałów. Choć tak naprawdę w normalnej pracy można użyć tylko 19 - dwudziesty jest na pinie resetu, który trzeba wyłączyć by móc go używać jako kanału PWM. Raczej nigdy z niego nie skorzystam, nie mam narzędzi do późniejszego odblokowania procka.
W każdym razie, warto napisać coś o osiągach tego tworu. Przed kompilacją programu w pliku nagłówkowym należy określić które kanały mają być włączone - każdy taki jeden kanał to 8 cykli zegara więcej przy każdym przerwaniu timera. Dla wszystkich 20 kanałów cała funkcja generująca sygnały trwa 180 cykli, co przy 8-bitowej rozdzielczości sprawia że docelowa częstotliwość kanałów PWM nie może przekroczyć 434Hz. Oczywiście im więcej kanałów wyłączymy, tym większą częstotliwość możemy ustawić - przykładowo, dla 5 kanałów możemy ustawić częstotliwość do 1300Hz.
Wszystkie te opcje - wybór kanałów, częstotliwość, szybkość USART - można zmienić w pliku nagłówkowym.

Jeśli chodzi o sam kod generujący kanały, rozwiązanie jest bajecznie proste. Jest sobie tablica przechowująca wartości "programowych OCR" dla wszystkich 20 kanałów, jest również zmienna "programowego TCNT". Ich działanie jest analogiczne ze sprzętowymi odpowiednikami - wartość TCNT jest zwiększana przy każdym wywołaniu funkcji, a potem sprawdzany jest warunek czy TCNT przekroczyło wartość OCR - jeśli tak, dany kanał jest zerowany. Przy powrocie TCNT do 0, następuje powtórne ustawienie wszystkich kanałów i jazda zaczyna się od nowa.

Uwagi montażowe:
Po wytrawieniu i zlutowaniu płytki, należy jeszcze przystosować ją do docelowej pracy. Jeśli mamy zamiar wykorzystać pin resetu jako 20. kanał PWM, należy rozewrzeć zworkę resetEN. W moim przypadku mam tam na stałe wlutowany rezystor zworkopodobny ("0R"). Drugą sprawą jest wybór zasilania - zakładając zworkę regON włączamy do obwodu zasilającego stabilizator, na który możemy podać napięcie >5V. W przeciwnym wypadku układ należy zasilić stabilizowanymi 5V.
Układ można zaprogramować bezpośrednio na płytce, podłączając linie programatora do odpowiednio oznaczonych wyprowadzeń. Podczas programowania stabilizator musi być odłączony.

Wnioski na dziś:
Spodziewałem się po tym dziwolągu nieco więcej niż mi dał . Miałem nadzieję na jakiś sensowny multipleksing, ale według moich obserwacji wymagałby on innej komunikacji - najpierw wysyłanie modyfikacji PWMów, a dopiero potem "zatrzaskiwanie" wszystkich nowych wartości. Może komuś będzie się to chciało dopisać, ale ja nie mam już ochoty na zmianę sposobu komunikacji.

Na koniec chciałbym jeszcze podkreślić, że zdaję sobie sprawę z istnienia dedykowanych scalaków do generowania PWM, które zapewne robią to lepiej niż ta oto zabaweczka. Nie zawsze chodzi jednak o możliwość wielu zastosowań - czasem warto coś zrobić dla samego faktu robienia . No a poza tym nie mogłem znaleźć tych scalaków w SMD. Dodatkowo sporym plusem jest fakt, że zabawka używa do komunikacji USART, co umożliwia sterowanie przy pomocy komputera. Poniżej zdjęcie i filmik z efektu sterowania PWMów komputerem przy pomocy Pythona. Genialny efekt to to może nie jest, ale dobrze ukazuje jak łatwo się tym steruje.

iframe

Tymczasem pozdrawiam i zapraszam do dyskusji
mopsiok

Plik main.c:
[syntax=c]/*
* PWM generator
* ATmega88PA generujaca 20 sygnalow PWM o zadanej czestotliwosci wzorcowej i 8bitowej rozdzielczosci
*
* Aby zmienic wypelnienie jednego z kanalow, nalezy wyslac po USART 1-bajtowy numer kanalu [0..19],
* a nastepnie nowa wartosc wypelnienia.
*
* numeracja kanalow:
* PWM0..PWM3PD4..PD1
* PWM4..PWM9PC5..PC0
* PWM10..PWM15PB5..PB0
* PWM16..PWM18PD7..PD5
* PWM19PC6 (aktywny po wylaczeniu resetu)
*
* Fusebity - kwarc 20Mhz
* low: 0xCF
* high: 0xDF
*
* autor: mopsiok
* data utworzenia: 23-09-2013
*/

#include
#include
#include "config.h"

//zmienne na potrzeby komunikacji
volatile unsigned char data_type = 0; //rodzaj odbieranych danych [0: numer PWMa; 1: wartosc do ustawienia]
volatile unsigned char i = 0; //indeks elementu do zmiany

//zmienne na potrzeby generowania PWMow
volatile unsigned char timer_flag = 0; //flaga ustawiana przez timer
volatile unsigned char TCNT_ = 0; //licznik programowych PWM
volatile unsigned char OCR_[20] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; //wartosci programowych PWM

//przerwania
ISR (TIMER0_COMPA_vect) { //przerwanie timera sprzetowego do generowania PWMow
timer_flag = 1;
}

ISR (USART_RX_vect) { //przerwanie odebrania danych po USART
char byte = UDR0; //odbierz dane
if (data_type == 0) { //pierwszy bajt - numer kanalu
if (byte < 20) i = byte; //jesli w zakresie tablicy, to zapisz indeks
else data_type = 1; //wroc do zapisu indeksu - pod koniec funkcji zamieni sie z powrotem na 0
} else OCR_[i] = byte; //lub drugi bajt - nowa wartosc
data_type = 1-data_type; //na zmiane 0 i 1
}

ISR (BADISR_vect) {} //obsluga pozostalych przerwan

//deklaracje funkcji
void compare(void); //funkcja porownujaca programowy TCNT z OCR

int main(void) { //funkcja glowna programu
//konfiguracja portow - wszystko wyjscia
DDRB = 255, DDRC = 255, DDRD = 255;
PORTB = 0, PORTC = 0, PORTD = 0;

//konfiguracja modulu USART
UBRR0H = (unsigned char)(_UBRR>>8);
UBRR0L = (unsigned char)_UBRR;
UCSR0B = (1<UCSR0C = (1<
//konfiguracja timera0 - tryb CTC
TCCR0A = (1<TCCR0B = __PRESCALER;
OCR0A = _OCR;
TIMSK0 |= (1<
sei(); //globalna obsluga przerwan

for (;;) {
if (timer_flag) {
compare();
timer_flag = 0;
}
}

return 0;
}

void compare(void) { //funkcja porownujaca programowy TCNT z OCR
char b=PORTB, c=PORTC, d=PORTD; //bufory dla portow (zeby nie ustawialo kanalu jesli dany OCR=0)

if (++TCNT_ == 0) { //jesli nastapilo przepelnienie
b=255, c=255, d=255; } //to trzeba z powrotem ustawic wszystkie kanaly

#ifdef PWM0 //instrukcje preprocesora pomijaja wylaczone kanaly, co skraca czas wykonania funkcji
if (TCNT_ >= OCR_[0]) d &= 0b11101111; //zeruj bit jesli licznik przekroczyl dane wypelnienie
#endif
#ifdef PWM1
if (TCNT_ >= OCR_[1]) d &= 0b11110111;
#endif
#ifdef PWM2
if (TCNT_ >= OCR_[2]) d &= 0b11111011;
#endif
#ifdef PWM3
if (TCNT_ >= OCR_[3]) d &= 0b11111101;
#endif
#ifdef PWM4
if (TCNT_ >= OCR_[4]) c &= 0b11011111;
#endif
#ifdef PWM5
if (TCNT_ >= OCR_[5]) c &= 0b11101111;
#endif
#ifdef PWM6
if (TCNT_ >= OCR_[6]) c &= 0b11110111;
#endif
#ifdef PWM7
if (TCNT_ >= OCR_[7]) c &= 0b11111011;
#endif
#ifdef PWM8
if (TCNT_ >= OCR_[8]) c &= 0b11111101;
#endif
#ifdef PWM9
if (TCNT_ >= OCR_[9]) c &= 0b11111110;
#endif
#ifdef PWM10
if (TCNT_ >= OCR_[10]) b &= 0b11011111;
#endif
#ifdef PWM11
if (TCNT_ >= OCR_[11]) b &= 0b11101111;
#endif
#ifdef PWM12
if (TCNT_ >= OCR_[12]) b &= 0b11110111;
#endif
#ifdef PWM13
if (TCNT_ >= OCR_[13]) b &= 0b11111011;
#endif
#ifdef PWM14
if (TCNT_ >= OCR_[14]) b &= 0b11111101;
#endif
#ifdef PWM15
if (TCNT_ >= OCR_[15]) b &= 0b11111110;
#endif
#ifdef PWM16
if (TCNT_ >= OCR_[16]) d &= 0b01111111;
#endif
#ifdef PWM17
if (TCNT_ >= OCR_[17]) d &= 0b10111111;
#endif
#ifdef PWM18
if (TCNT_ >= OCR_[18]) d &= 0b11011111;
#endif

//po wylaczeniu resetu
#if PWM19 == 1
if (TCNT_ >= OCR_[19]) c &= 0b10111111;
#endif

PORTB=b, PORTC=c, PORTD=d; //aktualizacja portow
}[/syntax]

Plik config.h:
[syntax=c]/*
* PWM generator - plik konfiguracyjny
* autor: mopsiok
* data utworzenia: 23-09-2013
*
* UWAGA!
* Duza ilosc kanalow PWM ogranicza maksymalna czestotliwosc sygnalow - wlacz tylko te kanaly, ktorych uzyjesz.
*
* obliczanie czestotliwosci kanalow PWM:
* f_pwm = f_cpu / PRESKALER / (OCR+1) / 256
*
* w zaleznosci od wybranego preskalera, w makro _PRESCALER wpisac odpowiednia wartosc:
* 1/8/64/256/1024
*/

#ifndef CONFIG_H_
#define CONFIG_H_

//konfiguracja timera Timer0
#define _PRESCALER 8
#define _OCR 15

//konfiguracja modulu USART (ubrr = f_osc/16/baud - 1): komunikacja obustronna, format ramki 8;1;N
#define _UBRR 24 //50000 baud

//wlaczanie kanalow - aby wlaczyc dany kanal, nalezy zdefiniowac jego nazwe
#define PWM0
#define PWM1
#define PWM2
#define PWM3
#define PWM4
#define PWM5
#define PWM6
#define PWM7
/*#define PWM8
#define PWM9
#define PWM10
#define PWM11
#define PWM12
#define PWM13
#define PWM14
#define PWM15
#define PWM16
#define PWM17
#define PWM18*/

/* UWAGA!
* odkomentowanie ponizszego makra wlaczy obsluge 20. kanalu PWM, znajdujacego sie na pinie resetu
* konieczne bedzie zablokowanie pinu resetu, co uniemozliwi ponowne zaprogramowanie mikrokontrolera przez ISP
*/
//#define PWM19 1

//nie ruszac!
#if _PRESCALER == 1
#define __PRESCALER 1
#elif _PRESCALER == 8
#define __PRESCALER 2
#elif _PRESCALER == 64
#define __PRESCALER 3
#elif _PRESCALER == 256
#define __PRESCALER 4
#else
#define __PRESCALER 5
#endif

#endif /* CONFIG_H_ */[/syntax]

Skrypt w Pythonie generujący powyższy efekt:
[syntax=python]import serial, time
from math import *

p = serial.Serial(8, 50000)
p.open()

def _sin(x, fi=0, m=255):
return int(m*(sin(radians(x+fi))+1)/2)

for i in range(180*2+1):
for j in range(8):
_ = p.write(chr(j) + chr(_sin(i*2, -12*j, 50)))
time.sleep(0.015)[/syntax]

Statystyki: Napisane przez mopsiok — 30 wrz 2013, o 21:53