ATNEL tech-forum

Re: Programowy counter... marne działanie

2012-08-07T08:00:19+01:00

Tak. Zlicza oba zbocza, ale można to poprawić.
[syntax=c]switch ( (stan_portu ^ poprzedni_stan) & stan_portu ) {[/syntax]
Teraz port musi i się zmienić i zmienić się na 0 (po zanegowaniu 1).

Statystyki: Napisane przez Krauser — 7 sie 2012, o 08:00

Re: Programowy counter... marne działanie

2012-08-06T20:54:04+01:00

[syntax=c]void obsluga_pulsow(void) {
if (_FLAGA.CheckPort == FLAG_S) {

switch (stan_portu ^ poprzedni_stan) {
case 1: PULSE.A++;break;
case 2:PULSE.B++;break;
case 3:PULSE.A++; PULSE.B++;break;
case 4:PULSE.C++;break;
case 5:PULSE.A++; PULSE.C++;break;
case 6: PULSE.B++; PULSE.C++;break;
case 7:PULSE.A++; PULSE.B++; PULSE.C++;break;
case 8:PULSE.D++;break;
case 9:PULSE.A++; PULSE.D++;break;
case 10:PULSE.B++; PULSE.D++;break;
case 11:PULSE.A++; PULSE.B++; PULSE.D++;break;
case 12:PULSE.C++; PULSE.D++;break;
case 13:PULSE.A++; PULSE.C++; PULSE.D++;break;
case 14:PULSE.B++; PULSE.C++; PULSE.D++;break;
case 15:PULSE.A++; PULSE.B++; PULSE.C++; PULSE.D++;break;
}
_FLAGA.CheckPort = FLAG_R;
poprzedni_stan = stan_portu;
}
}[/syntax]
[syntax=c]ISR(PCINT0_vect)
{
stan_portu = ~(PINA) & 0b00001111;
_FLAGA.CheckPort = FLAG_S;
}[/syntax]

Mam dziwne wrażenie, że teraz zlicza oba zbocza...

Statystyki: Napisane przez szopler — 6 sie 2012, o 20:54

Re: Programowy counter... marne działanie

2012-08-06T19:17:21+01:00

To musisz przebudować program, bo zmiana stanu powoduje odczyt. Ciągłe zero jest traktowane jako zmiana stanu również pod warunkiem, że inne wejście wyzwoliło przerwanie od zmiany stanu. Musisz zapamiętać ostatni stan każdego bitu i jak się nie zmienił to usunąć go przed instrukcją switch. Do tego celu dobrze nadaje się XOR (^).

Statystyki: Napisane przez Krauser — 6 sie 2012, o 19:17

Re: Programowy counter... marne działanie

2012-08-06T18:56:45+01:00

OK.

Jest jeszcze jeden poważny babool nad którym pracuję .
Jak pod jeden pin podłączę generator a pod drugi przycisk i wcisnę przycisk to licznik do niego przypisany liczy w tempie generatora zamiast wykonać jedno zliczenie i stop.

Statystyki: Napisane przez szopler — 6 sie 2012, o 18:56

Re: Programowy counter... marne działanie

2012-08-06T18:10:50+01:00

W programie dałem błędny warunek, bo powinno być
[syntax=c]if( (pinState != 0x0F) && (pinState != 0x00) )[/syntax]

Statystyki: Napisane przez Krauser — 6 sie 2012, o 18:10

Re: Programowy counter... marne działanie

2012-08-06T14:57:46+01:00

Podłączenie jest takie: PB0 -->|-- rezystor - GND
Od razu po wgraniu programu zapala się LED niezależnie od taktowania nawet jak do portu PA nie jest nic podłączone.
W kodzie chyba zabrakło '&' .

Jest PORTB = ~(1<Powinno być PORTB &= ~(1<
I tak led od razu ON.

Faktycznie jak generuję prostokąt na jednym z pinów i podłączę do wejść to liczy poprawnie.

Statystyki: Napisane przez szopler — 6 sie 2012, o 14:57

Re: Programowy counter... marne działanie

2012-08-06T14:34:09+01:00

szopler napisał(a):

Led zapala się natychmiast

Led powinna być wpięta pomiędzy wyjście a masę. Mam nadzieję, że kod jest dobry.
A co jak nie podasz sygnału?
A jak się zachowuje przy obniżonym taktowaniu?

Statystyki: Napisane przez Krauser — 6 sie 2012, o 14:34

Re: Programowy counter... marne działanie

2012-08-06T13:58:19+01:00

Przed chwilką sprawdziłem jeszcze raz i nadal nie ma róznicy pomiędzy poszczególnymi licznikami, a kręci się już chyba od 10 rano

Statystyki: Napisane przez Malutki_27 — 6 sie 2012, o 13:58

Re: Programowy counter... marne działanie

2012-08-06T13:47:05+01:00

Zabieram się zatem za testy...

Krauser napisał(a):

1. Inny prosty test. Piny Porta.0..4 nadal masz połączone razem i do generatora.
[syntax=c]
#include
int main(void)
{
uint8_t pinState;
DDRB |= (1< PORTA = 0xFF;
PORTB = ~(1< PORTC = 0xFF;
//CLKPR = (1< //CLKPR = (1< while(1)
{
pinState = PINA & 0x0F;
if( (pinState != 0x0F) || (pinState != 0x00) )
{
PORTB |= (1< }
}
return 0;
}[/syntax]
skoro piny są spięte razem to LED nigdy się nie powinien zapalić.
2. Spróbuj zmniejszyć częstotliwość taktowania (linie wyłączone poprzez komentarz)

Led zapala się natychmiast

Statystyki: Napisane przez szopler — 6 sie 2012, o 13:47

Re: Programowy counter... marne działanie

2012-08-06T09:20:35+01:00

Więc tak ..... udało mi się wywyołać taki przypadek jak u ciebie. U mnie powodem takiej sytuacji było to że nie było prawidłowego styku do portów.

Postaram się to w miarę przejrzyście opisać.
Test zrobiłem na timerze który masz odpalony zmieniając stan jednego z wyjść co 2ms, wejście podpiełem pod nózki od przerwań PCINT.

I tak, jeżeli nie odłączałem nóżki "mojego generatora" to się kręciło jak należy, ale w momencie jak zacząłem podłączać i odłączać w miarę szybko kabelek to liczniki sie rozjechały jak siemasz.
Dla mnie wniosek jest taki że w przypadku microswicha jednak dużą rolę odgrywają drgania styków ponieważ uC nie ma na tyle dużo czasu aby prawidłowo odczytać stany na nóżkach od przerwań. Skoro u ciebie rozjeżdżają się za każdym razem to myślę że jest problem gdzieś z jakością połączeń lub z zakłóceniami.
Jeżeli się mylę to bardzo proszę o naprostowanie mojego rozumowania za co będę bardzo wdzięczny

Statystyki: Napisane przez Malutki_27 — 6 sie 2012, o 09:20

Re: Programowy counter... marne działanie

2012-08-06T08:09:40+01:00

Statystyki: Napisane przez Krauser — 6 sie 2012, o 08:09

Re: Programowy counter... marne działanie

2012-08-06T08:05:49+01:00

Hmmmm, więc tak ...... wgrałem Twój programik u siebie na płytkę i zasuwa jak ta lala. Nawet się nie chce pomylić o jeden, a robi już jakieś 20 okrążenie.
Jedyna różnica jest taka że ja akurat w tej chwili popędzam atmegę kwarcem 11 MHz, jak wygrzebię jakiś szybszy to zmienię i sprawdzę jeszcze raz . Powiedz mi jeszcze tylko jak mam rozumieć "stwierdzenie w dłuższym okresie czasu"

Statystyki: Napisane przez Malutki_27 — 6 sie 2012, o 08:05

Re: Programowy counter... marne działanie

2012-08-06T00:01:01+01:00

Tyle, że nawet przy podłączeniu generatora wzorcowego z oscyloskopu - 1kHz 0.5V (przez wzmacniacz operacyjny naturalnie) problem zliczania występuje.

Statystyki: Napisane przez szopler — 6 sie 2012, o 00:01

Re: Programowy counter... marne działanie

2012-08-05T23:36:29+01:00

Z tym draganiem to chodzi o to że; pomiedzy odczytem stanu jedengo pinu a drugiego mija pewien czas i mimo wciśniętego przycisku może zmienić się stan jednego z pinów. Ja bym to sprawdził za pomocą dwóch zwieranych przewodów, bo tam raczej nie występują drgania styków

------------------------ [ Dodano po: 7 minutach ]

Co do tego czy mam rację z negacją bitową możesz zrobić prosty eksperyment wartość zamiast wrzucać do funkcji wyrzuć na wyświetlacz i wszystko będzie jasne. np tak lcd_int(PINA) oraz lcd_int(~PINA) znając stan portów będziesz wiedział co uzyskałeś.
Ja dzisiaj raczej nie ma takiej możliwości, ale jutro nawet tak dla siebie to sprawdzę

------------------------ [ Dodano po: 13 minutach ]

I całkiem rozsądna jest podpowieź kol Krauser żeby zrobić programowy PWM. Timer i tak masz już odpalony to czemu nie podłączyć tych pinów od przerwania do jakiegość pinu i nie zmieniać jego stanu poprzez timer.

Statystyki: Napisane przez Malutki_27 — 5 sie 2012, o 23:36

Re: Programowy counter... marne działanie

2012-08-05T23:30:28+01:00

Wracając jednak do meritum... ?

Statystyki: Napisane przez szopler — 5 sie 2012, o 23:30

Re: Programowy counter... marne działanie

2012-08-05T20:05:21+01:00

No właśnie - odczyt jest w tym samym momencie. Jak mam zwarte piny wejściowe to cały czas powinien wykonywać się ten sam "case", ale jednak coś się krzaczy.
Maksymalna częstotliwość przychodzących impulsów to 5kHz, ale zwykle jest to nawet 100x mniej.

Statystyki: Napisane przez szopler — 5 sie 2012, o 20:05

Re: Programowy counter... marne działanie

2012-08-05T19:38:54+01:00

To pewnie działanie sił nieczystych = stanów nieustalonych. Bo w końcu odczyt wszystkich linii występuje w tym samym momencie.
Duża prędkość taktowania nie jest tutaj bez winy.
Jaka ma być częstotliwość impulsów, które chcesz zliczać? Może dobrym testem byłoby wygenerowanie tej częstotliwości na wolnym kanale PWM i podanie na wejścia przez pewien czas.

Statystyki: Napisane przez Krauser — 5 sie 2012, o 19:38

Re: Programowy counter... marne działanie

2012-08-05T18:30:59+01:00

No to ja nie mardzo mam pomysł .... co jest nie tak....

Jedynie ja osobiście bym jeszcze zrezygnował z odczytu stanu portów w funkcji na rzecz przerwania.
np: if (!(PINA&(1<<0))) PULSE.A++;

Statystyki: Napisane przez Malutki_27 — 5 sie 2012, o 18:30

Re: Programowy counter... marne działanie

2012-08-05T17:59:23+01:00

OK. To zmieniłem. Nie miało wpływu na błędy zliczania, które nadal występują.

Statystyki: Napisane przez szopler — 5 sie 2012, o 17:59

Re: Programowy counter... marne działanie

2012-08-05T17:55:34+01:00

A jeżeli użyjesz tyldy w ten sposób jak napisałem to powinieneś wykorzystać maskowanie jeszcze raz w samej funkcji żeby ukryć wyższe bity.

Na przykłąd wartość portu przed negacją będzie np:

00001001
teraz negacja
11110110
i taka wartość jest przekazywana, żeby teraz była dobra dla ciebie powinieneś jeszcze raz ją zamaskować czyli:
11110110&b00001111 i dopiero teraz będziesz miał prawidłową wartość dla instrukcji switch czyli:
00000110

Statystyki: Napisane przez Malutki_27 — 5 sie 2012, o 17:55

Re: Programowy counter... marne działanie

2012-08-05T17:56:39+01:00

Uh... a myślałem, że to neguje wartość.

Statystyki: Napisane przez szopler — 5 sie 2012, o 17:50

Re: Programowy counter... marne działanie

2012-08-05T17:39:30+01:00

A raczej duża.
ponieważ nie negujesz całego wyrażenia, a tylko sam port i zamiast czytać rejestr 0x19 (PINA) dzięki tyldzie czytasz i maskujesz rejestr 0xE6 ( nawet nie wiem co to jest), innaczej by było gdyby tylda była przed nawiasem czyli ~(PINA&0b00001111)

Statystyki: Napisane przez Malutki_27 — 5 sie 2012, o 17:39

Re: Programowy counter... marne działanie

2012-08-05T17:33:00+01:00

Domyślnie na pinach jest stan wysoki więc (PINA & 0b00001111) daje gdy nic się nie dzieje wynik 0b1111 = 15 natomiast (~PINA & 0b00001111) da 0b0000 = 0. Różnica niewielka, moim zdaniem bez wpływu na działanie całości.

Statystyki: Napisane przez szopler — 5 sie 2012, o 17:33

Re: Programowy counter... marne działanie

2012-08-05T17:09:46+01:00

A tak mi przyszło do głowy ..........
Co do wentylatorów bardzo podobną technikę stosuję się przy kilku wentylatorach komputerowych jeżeli się chce odczytywać ich prędkości obrotowe.

------------------------ [ Dodano po: 16 minutach ]

A czasem funkcja obsługa pulsów nie powinna być wywołana zamiast tak obsluga_pulsow((~PINA & 0b00001111)); np tak obsluga_pulsow((PINA & 0b00001111));

Nie bardzo wiem jak to powinno wyglądać w tym przypadku ...... ale jakoś wzrokowo nie bardzo mi to pasuje

------------------------ [ Dodano po: 18 minutach ]

A nawet na pewno ..... przecież chcesz odczytać wartość na PINA więc używasz maskowania żeby uzuskać wartości, więc na pewno ta tylda nie jest potzreba

Statystyki: Napisane przez Malutki_27 — 5 sie 2012, o 17:09

Re: Programowy counter... marne działanie

2012-08-05T16:56:56+01:00

Na 4 piny procesora fizycznie i jednocześnie wchodzą te same sygnały, więc co tu mają drgania styków? I nie - to nie będzie do wentylatorów akurat...

Statystyki: Napisane przez szopler — 5 sie 2012, o 16:56