HomeMade

Tak u mnie wygląda odpalony ale nie spalony "Złomek" z RIT-em.
Jeszcze bez 9850.


[attachment=9143]

Witam
A tak u mnie,Rysiu jestes 'W I E L K I"
Janek[attachment=9145][attachment=9146]

Weekend, weekend i po weekendzie... fajnie że tyle osób testuje złomka. To budujące że ktoś to buduje i testuje. A zatem do dzieła jedziemy dalej.

Dzisiaj zanim pójdę spać bo rano w trasę Postanowiłem przepisać obsługę klawiszy STEP i RIT, a konkretnie wzorem z Heńka przewalić je na jedno wejście, bo przyda nam się parę fajnych klawiszy a wejść jest jak na lekarstwo. Dodatkowo przeniosłem sygnał PTT z pinu 12 na 2, a dlaczego o tym na końcu.

Zacząłem od tego że przygotowałem dwie zmienne typu boolean by przechowywać status tych przycisków.


Do sprawdzania stanu wciśnięcia przycisków użyjemy jednego z wejść, dokładnie tego którego używaliśmy do obsługi przycisku krok syntezy, w tym miejscu by mocno w kodzie nie mieszać poprostu zapalamy flagi wciśniętych klawiszy:


A robimy to tak:


Uwagę proszę zwrócić na pierwszą linię tej funkcji, by nie opóźniać procesora podczas normalnej pracy gdy żaden z przycisków nie jest naciśnięty, funkcja ta nie sprawdza już nic więcej tylko resetuje flagi przycisków.

Poszczególne funkcje które dotychczas sprawdzały stan wejść teraz sprawdzają tylko stan flag przycisków.

Było tak:


a teraz jest tak:


Podobnie zrobiłem w części kodu obsługującego klawisz RIT.

Jesli chodzi zaś o przeniesienie sygnału PTT na pin 2 to intencją było zwolnienie pinu 12-tego który może pracować jako PWM. A na nim zrobimy sobie w następnym odcinku ściemnianie podświetlenia wyświetlacza. Taki wypas

[attachment=9150]
Mały schemat podłączenia przycisków.

W załączeniu kod po ostatnich zmianach.

Witam

Rysiu mam pytanie ile jeszcze wolnego miejsca jest , lub ile procent już zajmuje program w procku ?

Pozdrawiam

Andrzej

Wielkość binarna szkicu: 15 820 bajtów (maksymalnie: 30 720 bajtów)

Czyli mijamy powoli połowę, dlaczego pytasz?

Ostatni kod
[attachment=9157]
Janek

Brawo Janku.
Może jakies już własne zmiany w kodzie wprowadzałeś? Pytam bo jestem ciekaw czy Ty lub może inni koledzy już jakieś wersje "pod siebie" robicie?

A przy okazji PWM zasugerowałem się rysunkiem znalezionym na forum arduino, w którym był błąd. Oczywiście D12 nie jest wyjściem PWM

[attachment=9159]
Błędny rysunek.


[attachment=9160]
A tutaj poprawiony.

Trzeba mieć oczy dookoła głowy albo kolegów którzy z uwagą śledzę nasze poczynania i pokażą błędy. Dzięki Ryśku (SP6IFN).

A wracając do tematu ułożenia pinów połączeń i tego PWM do ściemniania wyświetlacza. Tak sobie myślę że może to i wodotrysk jest ale, akurat mnie się to przyda, więc dlatego to napiszę. Resztę pinów chętnie poprzesuwam, ale to czekam na sugestie osób które zajmą się PCB, na tym etapie to projekt płytki powinien decydować co gdzie przesunąć by było jak najmniej przelotek (jeśli mówimy o druku jednostronnym pod żelazko).

p.s. pozdrawiam z Piły

Ponieważ "delay()" jest kolejnym paskudztwem, którego jeżeli tylko się da to trzeba unikać, ponieważ bezproduktywnie zjada czas procesora to można zrobić tak:

zmienne pomocnicze typu buttonstate i lastbuttonstate typu boolean (czyli zerojedynkowe więc małe)
przycisk normalnie podciągnięty wewnętrznie do plusa, po wciśnięciu zwierany do masy

buttonState = digitalRead(stepPin);
if (buttonState != lastButtonState) {
if (buttonState == LOW) { zróbcotrzeba();}
}
lastButtonState = buttonState;

Styki sobie mogą drgać ile chcą, a my się debouncem wogole nie przejmujemy, bo "zróbcotrzeba()" już zostało wykonane. to oczywiście nie rozwiązuje nap problemu ze stuprocentową pewnością, ale :
1. praktyka wykazuje, że stabilność jest bardzo duża
2. unikamy delaya
3. nie odpalamy rakiet z głowicami atomowymi

czasem delaya się nie da uniknąć, np przy czytaniu z seriala albo ustabilizowaniu odczytu z analoga, ale to już trudno

MAc
mrn

PS
akurat w obsłudze klawiatury delay nie jest tragiczny, bo i tak jest szybszy od naszego palca - ale ze względów edukacyjnych przypominam, że mało jest rzeczy gorszych niż wymuszanie TOTALNEGO nic nie robienia procesora. Wszystkie procesy się zatrzymują.

Cytat:czasem delaya się nie da uniknąć, np przy czytaniu z seriala albo ustabilizowaniu odczytu z analoga, ale to już trudno

Akurat przy odczycie z wejścia analogowego delaya można "zgubić" programowo, wykonując kilka pomiarów i je uśrednić. Na pierwszej lekcjii z Arduino którą przerabiałem było:

Cytat: //pomiar napięcia z potencjometru i dodanie wyniku do wart_pot
for (int i =0; i < 20; i++); //pętla wykonywana 20 razy
wart_pot = wart_pot + analogRead(A0);
//obliczanie średniej arytmetycznej z 20 pomiarów
wart_pot = wart_pot / 20;
// przeliczanie odczytanej wartości na napięcie
wart_nap=(5.0*wart_pot*20)/1024.0;

zaczerpnięte z "Elektronika Praktyczna Nr.6/2011 str.87".
Rysio!

Rysio!
Uśrednianie to jedno a chwila spokoju dla przetwornika to drugie. Tam jest jeden multipleksowany przetwornik i najlepiej jest wywołać przetwornik, poczekać i dopiero zmierzyć.
Uśrednianie z kolei daje nam "pewność" pomiaru - np zabezpiecza przed niestabilnością potencjometru.

analogRead(A0);
delay(10);
sensorReading[0] = analogRead(A0);
analogRead(A1);
delay(10);
sensorReading[0] = analogRead(A1);

Muszę znaleźć wykład o tym - ale w tej chwili nie pamiętam linku

to nie jest zawsze potrzebne - np przy pojedynczym smetrze to nie ma większego znaczenia, ale jak w sterowniku czytałem dwa potencjometry jednocześnie kręcone, to się zaczynały cuda. Może się tak zdarzać również przy pomiarze SWR - jak bierzemy jednocześnie sygnał analogowy fwd i rev do dalszej obróbki.
MAc

PS znalazłem

"The Atmega datasheet also cautions against switching analog pins in close temporal proximity to making A/D readings (analogRead) on other analog pins. This can cause electrical noise and introduce jitter in the analog system. It may be desirable, after manipulating analog pins (in digital mode), to add a short delay before using analogRead() to read other analog pins. "
http://arduino.cc/en/pmwiki.php?n=Tutori...gInputPins