ATNEL tech-forum

Re: dziwne zachowanie funkcji _delay_us()

2014-10-24T13:13:49+01:00

To odsłonię trochę rąbka tajemnicy - programuję falownik o częstotliwości od ok 5 do ok 60Hz na 230V pracujący w układzie mostka.
Do generowania sygnału kluczującego wykorzystuję PWM - do tego używam TIMER:0. PB1 iPB2 sterują połówkami klucza, PB0 - PWM. Na PB3 robię przerwanie zewnętrzne - przy przeciążeniu wyłączy się PWM na ok 1s. Na PB4 mierzę napięcie z dzielnika rezystancyjnego i w zależności od jego wartości ustawiana jest częstotliwość, przy czym przy (WYNIK>>2) > 230 ustawiona będzie częstotliwość stała 50Hz (około) - wszystko mierzone oscyloskopem, więc dokładność "PI razy drzwi"
A że jest to mój pierwszy program w atmedze (ba wcześniej się procków bałem jak ognia i wszystko robiłem na piechotkę - tranzystorek, scalaczek itp.) pewno powiecie że porywam się z motyką na słońce.
Ale to mi już działa.... nawet się ładnie na oscyloskopie prezentuje, choć kod programu wymaga zapewne jeszcze "oczyszczenia" - jest to wersja BARDZO robocza i wstyd mi ją tu wklejać . Pomyśleć jeszcze muszę o "watchdog" - reset jak pójdzie coś nie tak - zostało mi jeszcze jakieś 40% wolnej pamięci - tak na wszelki wypadek.
Dlatego też TIMER:0 nie wykorzystam do generacji opóźnień, mimo, że były by one bardzo precyzyjne, bo w tym momencie osiągnąłem maksimum swoich możliwości, ale dzięki za trop.

Statystyki: Napisane przez APAP75 — 24 paź 2014, o 13:13

Re: dziwne zachowanie funkcji _delay_us()

2014-10-24T10:00:10+01:00

nie wiem dlaczego nikt w Tym wątku nie wyjaśnił, dlaczego nie warto stosować funkcji opóźniających (mimo zaznaczania Mirka w powyższym filmiku jak ważne są dobre praktyki programistyczne...) i nie przedstawił jak to się robi w normalnym świecie:
w Attiny13 masz Timer0, którego możesz ustawić tak, aby uzyskać przerwanie co tyle us lub ms ile Ci potrzeba.

CS02 CS01 CS00 Description
0 0 0 No clock source (Timer/Counter stopped)
0 0 1 clkI/O/(No prescaling)
0 1 0 clkI/O/8 (From prescaler)
0 1 1 clkI/O/64 (From prescaler)
1 0 0 clkI/O/256 (From prescaler)
1 0 1 clkI/O/1024 (From prescaler)
1 1 0 External clock source on T0 pin. Clock on falling edge.
1 1 1 External clock source on T0 pin. Clock on rising edge.o

Od biedy możesz skorzystać z przerwania Watchdoga i nie jest to jakaś tajemna wiedza, którą posiądziesz dopiero po tym jak przez rok będziesz się borykał z funkcjami typu _delay.

Statystyki: Napisane przez GanzConrad — 24 paź 2014, o 10:00

Re: dziwne zachowanie funkcji _delay_us()

2014-10-23T22:50:40+01:00

APAP75 napisał(a):

A dlaczego tak tego #define F_CPU nie lubicie?

Jakby tu chodziło o jakieś tam "lubienie" to nikt by o tym nie wspominał ...

APAP75 napisał(a):

Czy po prostu nieelegancko wygląda

to też - ale to mało ważne

APAP75 napisał(a):

Bruździ w czymś?

O! tu zaczynasz dobrze myśleć - to teraz obejrzyj ten poradnik, od tego momentu jak niżej link:

https://www.youtube.com/watch?v=UhcyBpM57vo#t=2891

Statystyki: Napisane przez mirekk36 — 23 paź 2014, o 22:50

Re: dziwne zachowanie funkcji _delay_us()

2014-10-23T22:26:53+01:00

A dlaczego tak tego #define F_CPU nie lubicie?
Bruździ w czymś? Czy po prostu nieelegancko wygląda
Rozumiem, aby tego nie wstawiać do programu.

Statystyki: Napisane przez APAP75 — 23 paź 2014, o 22:26

Re: dziwne zachowanie funkcji _delay_us()

2014-10-23T22:13:49+01:00

doman89 napisał(a):

Tfu!

hehehe teraz widzi kolega co to znaczy polecać Atmel Studio początkującemu ? ... pierwsze co zrobi - poleci na bloga X .... i z tamtąd jak zarazę przyniesie to tfuuu #define F_CPU w kodzie programu

Statystyki: Napisane przez mirekk36 — 23 paź 2014, o 22:13

Re: dziwne zachowanie funkcji _delay_us()

2014-10-23T21:51:45+01:00

APAP75 napisał(a):

oczywiście podać w nagłówku zdefinicję F_CPU

Mam nadzieję, że kolega nie ma na myśli czynić herezji typu:

[syntax=c]#define F_CPU 8000000UL[/syntax]

Tfu!

z Niebieskim pozdRowieniem,
Doman89

Statystyki: Napisane przez doman89 — 23 paź 2014, o 21:51

Re: dziwne zachowanie funkcji _delay_us()

2014-10-23T21:40:33+01:00

Dzięki

Idąc Twoim tropem znalazłem to:

Z tego co wyczytałem, muszę wykonać kilkakrotnie funkcję _delay_us() w pętli, no i oczywiście podać w nagłówku zdefinicję F_CPU.

zaczynam przerabiać swój programik

Statystyki: Napisane przez APAP75 — 23 paź 2014, o 21:40

Re: dziwne zachowanie funkcji _delay_us()

2014-10-23T21:33:30+01:00

Witam,

Ja do kolegi wyżej dodam, że jeżeli chcesz używać delaya ze zmienną to zrób coś takiego:

[syntax=c]void delay_ms( int x)
{
while(x--) _delay_ms(1);
}[/syntax]
i teraz używasz tak:

[syntax=c]delay_ms( zmienna );[/syntax]

z Niebieskim pozdRowieniem,
Doman89

------------------------ [ Dodano po: 4 minutach ]

Dodam jeszcze kolega żebyś sobie zainstalował:

ATMEL Studio 6.2 żebyś nie korzystał ze starych kompilatorów.

albo

ECLIPSE jeżeli nie czujesz się na siłach z w/w - duże wsparcie na forum jest szczególnie dla niego.

Tak żebyś miał przede wszystkim najnowszy Toolchain

Statystyki: Napisane przez doman89 — 23 paź 2014, o 21:33

Re: dziwne zachowanie funkcji _delay_us()

2014-10-23T21:32:37+01:00

Zawsze tak jest przy funkcji delay, powinno się przekazywać do niej stałą. Najłatwiej wykorzystać jakiś timer.

Statystyki: Napisane przez gumeni — 23 paź 2014, o 21:32

Re: dziwne zachowanie funkcji _delay_us()

2014-10-23T21:29:25+01:00

Do funkcji delay_ms / us jako argument podaje się stała dosłowna liczbową.
Nie podaje się argumentu w postaci zmiennej.

Czyli powinno byc np: _delay_us(20);

Statystyki: Napisane przez bogdanc — 23 paź 2014, o 21:29

Re: dziwne zachowanie funkcji _delay_us()

2014-10-23T21:23:11+01:00

Poprawiłem i obiecuję poprawę na przyszłość - mam nadzieję, że na tym forum dozwolona jest edycja postów....
Nadal czekam na odpowiedź.

Statystyki: Napisane przez APAP75 — 23 paź 2014, o 21:23

Re: dziwne zachowanie funkcji _delay_us()

2014-10-23T21:09:36+01:00

Polecam zastosować się do tego: topic7402.html

Statystyki: Napisane przez Jaglarz — 23 paź 2014, o 21:09

dziwne zachowanie funkcji _delay_us()

2014-10-23T21:22:05+01:00

Witam

Rozpocząłem swoją zabawę z AVR od attiny13a - fajny mały procesorek z 1kB pamięci flash.... i tu zaczynają się schody.
Gdy zadeklaruję zmienną bez nadania jej wartości i użyję jej w funkcji _delay_us() program ma ponad 1kB

[syntax=c]#include
#include

int main(void)
{

unsigned char indeks=0;
unsigned int czas;
while(1)
{
while (indeks<=179)
{

_delay_us(czas);
indeks++;

}
indeks=0;
}
}[/syntax]

i nie mieści się do pamięcji procka
[syntax=c]Size after:
AVR Memory Usage
----------------
Device: attiny13a

Program: 1160 bytes (113.3% Full)
(.text + .data + .bootloader)

Data: 0 bytes (0.0% Full)
(.data + .bss + .noinit)

-------- end --------

> Process Exit Code: 0
> Time Taken: 00:03[/syntax]

Wystarczy poprawić jeden wpis:
unsigned int czas=0;
i oto wynik:
[syntax=c]Size after:
AVR Memory Usage
----------------
Device: attiny13a

Program: 58 bytes (5.7% Full)
(.text + .data + .bootloader)

Data: 0 bytes (0.0% Full)
(.data + .bss + .noinit)

-------- end --------

> Process Exit Code: 0
> Time Taken: 00:04[/syntax]

To przysłowiowy pryszcz, bo zawsze przy deklaracji zmienej mogę ją czymś zainicjować. Schody zaczynają się tu:
[syntax=c]#include
#include

int main(void)
{

unsigned char indeks=0;
unsigned int czas=0;
unsigned int zmienna=123;
while(1)
{
while (indeks<=179)
{

_delay_us(czas);
indeks++;
czas=zmienna>>2;

}
indeks=0;
}
}[/syntax]

i po kompilacji:
d[syntax=c]Size after:
AVR Memory Usage
----------------
Device: attiny13a

Program: 1164 bytes (113.7% Full)
(.text + .data + .bootloader)

Data: 0 bytes (0.0% Full)
(.data + .bss + .noinit)

-------- end --------

> Process Exit Code: 0
> Time Taken: 00:04[/syntax]
Z tego co zauważyłem, każde przypisanie do zmiennej będącej argumentem funkcji _delay_us() wyniku przesumięcia bitowego (dzielenia, mnożenia przez wielokrotność 2) kończy się kodem wynikowym ponad 1kB.
Używam WinAVR-20100110. Na innych kompilatorach nie próbowałem. Mam wprawdzie zainstalowany AVR studio 4.0 - ale jakoś nie potrafię za wiele w nim zrobić... świeżynka jestem.
Czy spotkaliście się z podobnym problemem? Jak go rozwiązać? Czy istnieje jakaś inna, w miarę precyzyjna, funkcja opóźnienia czasowego, która nie będzie robił podobnych psikusów?

Statystyki: Napisane przez APAP75 — 23 paź 2014, o 21:05