Arduino jest traktowane 16 MHz, ale masz blokujący print, przez który
nie nadąża z odczytami.

do góry

On Fri, 7 Jul 2017 11:58:36 +0100, Cezar <c...@B...pl.invalid>
wrote:
> skróciłeś długośc impulsów. Musisz zliczać *zbocza* a nie stany.

Niekoniecznie. Tylko trzeba to robić starannie, wiedzieć co i
dlaczego.

do góry

On Fri, 7 Jul 2017 11:44:11 +0100, Cezar <c...@B...pl.invalid>
wrote:
> W powyzszym kodzie jesli impuls przyjdzie podczas gdy piszesz do
LCD,
> konsoli lub CPU wykonuje cokolwiek innego to zostanie pominięty.

Właśnie tak. A że wszystko to trwa długo...

Klasyka.

do góry

On Fri, 7 Jul 2017 11:56:43 +0100, "Michal M. Lechanski"
<m...@d...eu> wrote:
> Panowie, dziękuję bardzo - spróbuję najpierw wyeliminować wpływ
opóźnień
> związanych z obsługą LCD.

PRZERWANIA

I ew. bufor na wejściu.

do góry

On Fri, 7 Jul 2017 13:19:33 -0700 (PDT), s...@g...com wrote:
> Korzystaj z kontaktronu

Kontaktron ma mechaniczne styki, czyli ograniczoną żywotność.

do góry

W dniu 2017-07-07 o 12:56, Michal M. Lechanski pisze:
> W dniu 07/07/2017 o 11:01, Michal M. Lechanski pisze:
>
>> Ja po prośbie do doświadczonych bardziej niż ja...
>
> Panowie, dziękuję bardzo - spróbuję najpierw wyeliminować wpływ opóźnień
> związanych z obsługą LCD.
Nic Ci to nie da, nadal będziesz miał przypadkowe odczyty,, pamiętaj że
if nie czeka tylko sprawdza warunek i idzie dalej.
Musisz zamiast if dać while które będzie czekać aż warunek się zmieni
np: zamiast
if (val0 > 100)
{
licznik++;
}

daj
while (val0 > 100); // czeka na impuls
licznik++;

i zastosuj 1 czujnik (1 pomiar wg twojego opisu) najwolniejszy wtedy
będzie dość czasu na wyświetlanie.

--
Pozdr
Janusz

do góry

W dniu 2017-07-08 o 11:28, Janusz pisze:
> daj
> while (val0 > 100); // czeka na impuls
> licznik++;
>

Pętla while się kręci dopóki val0>100. Jak pojawi się val0 mniejsze od
100 to zwiększy się licznik, coś tam się zrobi i program wróci do tego
while.

A co będzie jak nadal val0 jest jeszcze mniejsze od 100?
Pętla while się nie wykona ani razu licznik się zwiększy itd.

Przy stojącym kole zliczona liczba obrotów będzie rosła.
P.G.

do góry

On Sat, 8 Jul 2017 11:28:19 +0200, Janusz <j...@o...pl> wrote:
> > Panowie, dziękuję bardzo - spróbuję najpierw wyeliminować wpływ
opóźnień
> > związanych z obsługą LCD.
> Nic Ci to nie da, nadal będziesz miał przypadkowe

De facto są dwa zadania do realizacji: obserwacja czujnika w czasie
rzeczywistym i pokazywanie przeliczonych wyników na wyświetlaczu.

Pierwsze zadanie wymaga pełnej dyspozycyjności. CPU nie może "na
chwilę zająć się czymś innym".

Drugie jest czasochłonne (LCD jest dość powolne) i może być blokujące
(jeżeli nie wiadomo jak długo trzeba będzie np. czekać na przesłanie
tych danych gdzieś jakoś).

Jest jeden CPU, jeden rdzeń. Jedyna sensowna możliwość to obsługa
czujnika w przerwaniu. Przecież Atmega 328 ma przerwania i nikt nie
broni mieć "gorącą linię" z czujnika wprost do CPU.

Oczywiście w tym momencie program robi się "dwuwątkowy". Czyli trzeba
trochę ogarnąć np. możliwość jednoczesnego dostępu do zmiennej i
takie tam. Nic drastycznie trudnego.

Alternatywą jest najpierw tylko mierzyć, potem pokazać wynik itd.

Dobrze byłoby sprawdzić jak działa biblioteka do LCD - czy np. nie
używa sama przerwań itp.

Nigdzie nie używać delay.

Jeszcze mały drobiazg: Arduino obsługuje transmisję szeregową w
głównej pętli, tj. wywołuje na przemian loop() i coś tam jeszcze.
Czyli pomiędzy kolejnymi wejściami do loop() może upłynąć bliżej
nieokreślony czas. Można się tego pozbyć, ale przestanie np. działać
monitor na porcie szeregowym.

do góry

W dniu 2017-07-08 o 12:01, Piotr Gałka pisze:
> W dniu 2017-07-08 o 11:28, Janusz pisze:
>> daj
>> while (val0 > 100); // czeka na impuls
>> licznik++;
>>
>
> Pętla while się kręci dopóki val0>100. Jak pojawi się val0 mniejsze od
> 100 to zwiększy się licznik, coś tam się zrobi i program wróci do tego
> while.
Wiadomo co będzie, to jest najprostrza wersja, juz mu nie chciałem mącić
drugą pętlą. To juzż mu będzie lepiej chodzić od tego co napisał.



--
Pozdr
Janusz

do góry

W dniu 2017-07-08 o 21:34, slawek pisze:
> On Sat, 8 Jul 2017 11:28:19 +0200, Janusz <j...@o...pl> wrote:
>> > Panowie, dziękuję bardzo - spróbuję najpierw wyeliminować wpływ
> opóźnień
>> > związanych z obsługą LCD.
>> Nic Ci to nie da, nadal będziesz miał przypadkowe
>
> De facto są dwa zadania do realizacji: obserwacja czujnika w czasie
> rzeczywistym i pokazywanie przeliczonych wyników na wyświetlaczu.
>
> Pierwsze zadanie wymaga pełnej dyspozycyjności. CPU nie może "na chwilę
> zająć się czymś innym".
>
> Drugie jest czasochłonne (LCD jest dość powolne) i może być blokujące
> (jeżeli nie wiadomo jak długo trzeba będzie np. czekać na przesłanie
> tych danych gdzieś jakoś).
>
> Jest jeden CPU, jeden rdzeń. Jedyna sensowna możliwość to obsługa
> czujnika w przerwaniu. Przecież Atmega 328 ma przerwania i nikt nie
> broni mieć "gorącą linię" z czujnika wprost do CPU.
Masz rację, my byśmy tak to napisali ale autor jeszcze nie wie co to są
przerwania i po co.
Co do czasochłonności to się mylisz, przy czujniku z taśmą czyli impuls
na obrót ma dość czasu na wyświetlanie do tych 40km/h


--
Pozdr
Janusz

do góry