Skocz do zawartości

andrews

Użytkownicy
  • Zawartość

    13
  • Rejestracja

  • Ostatnio

Reputacja

5 Neutralna

O andrews

  • Ranga
    2/10
  1. Na początek: gdzie masz definicję zmiennej im5? Kompilator się nie buntował? Zakładając, że to pomyłka i w miejscu im5 miało być im10. Jeśli zostanie naciśnięty 3 razy np. IMPULS_1 to zmienna im1 nadal będzie równa 1, bo za każdym razem przypisujesz jej wartość 1. Jeśli chcesz sumować punkty, to spróbuj może tak: if (impuls(IMPULS_1)) { LED3_TOG; _delay_ms(500); LED3_TOG; im1 += 1; } Oczywiście dla IMPULS_2 powinno być im2 += 2; Nie wiem też, czy to zamierzone działanie, ale przy takim kodzie wciśnięcie przycisku na dłużej niż 500ms spowoduje ponowne naliczenie punktów. Poza tym nie rozumiem, skoro suma punktów ma być większa równa 10, to dlaczego piszesz: Istnieje też duże prawdopodobieństwo, że wynik tego działania będzie ujemny: a zmienną reszta masz zadeklarowaną jako unsigned. Ogólnie niezbyt rozumiem z Twojego opisu, jaki dokładnie ma być algorytm działania programu, więc trudno mi tu coś konkretnego doradzić. Może tymczasem przemyśl to, o czym napisałem.
  2. andrews

    Problemy z Pololu A4988

    Teoretycznie coś powinno być. Trudno jednak pomagać na odległość, kiedy Ty podajesz tak mało danych. W tej sytuacji istotne jest także: jakie jest napięcie pomiędzy 2A i 2B, jakie jest w ogóle napięcie zasilania silnika mierzone bezpośrednio na płytce (pomiędzy VMOT i GND), jakie napięcie jest na wyjściu stabilizatora napięcia. Dodatkowo należałoby sprawdzić dla pewności stabilność wszystkich połączeń, zmierzyć napięcia wejściowe na poszczególnych pinach sterujących oraz napięcie zasilające logikę (pomiędzy VDD i GND) bezpośrednio na płytce. Problemem może też być ustawienie potencjometru na płytce sterownika. Zgodnie z dokumentacją dla prądu cewki 0,4A i wartości rezystora RS=0,05 Ohm, na pinie REF układu A4988 należy potencjometrem ustawić napięcie 0,16V (160mV). Prawidłowe i dokładne ustawienie tego napięcia jest szczególnie istotne podczas pracy mikrokrokowej, ale nawet przy pełnokrokowej ustawienie tego napięcia na 0V może skutkować wyłączeniem lub znacznym ograniczeniem prądu cewek. Przy okazji nie zaszkodzi też sprawdzić, czy rezystory R7 i R8 na płytce sterownika przewodzą. Dobrze byłoby też zmierzyć (przy wyłączonym zasilaniu), czy pomiędzy pinami 1A-1B oraz pomiędzy pinami 2A-2B jest prawidłowa rezystancja cewek (powinno być 30 Ohm). Ogólnie należy się upewnić, czy między przewodami łączącymi sterownik z silnikiem nie ma jakichś zwarć. Trochę tego jest do sprawdzenia, ale nie widziałem Twojego układu ani nie wiem dokładnie co i w jaki sposób już sprawdziłeś. Lepiej i szybciej jest diagnozować problem metodą wykluczeń, czyli zmierzyć lub sprawdzić coś, a dalsze działania podjąć na podstawie wyciągniętych wniosków, tylko że przy tym tempie wymiany informacji mogłoby nam to trochę czasu zająć
  3. andrews

    Problemy z Pololu A4988

    Witam. Jak już mierzysz napięcie, to na cewkach, czyli pomiędzy 1A-1B lub 2A-2B. Kiedy silnik stoi, należy mierzyć napięcie stałe, kiedy się kręci - przemienne. Taka różnica nie ma krytycznego znaczenia. Ja bym tu widział inny problem. Jak tak patrzę na schemat, który przedstawiłeś, to widzę, że w zasilaniu silnika masz włączony stabilizator napięcia. Ten stabilizator właściwie jest zbędny. Oprócz tego pomiędzy wyjściem stabilizatora a sterownikiem masz wstawione szeregowo dwa rezystory o łącznej rezystancji (jeśli dobrze widzę) 30 Ohm. Te rezystory też są zbędne, a właściwie mogą przeszkadzać. W trybie pełnokrokowym (piny MS1-3 podłączone do masy) sterownik zasila dwie cewki jednocześnie, więc łączny prąd dostarczony do silnika powinien wynosić 0,8A. Biorąc pod uwagę, że równolegle połączone cewki będą miały rezystancję wypadkową 15 Ohm + dodane przez Ciebie dwa rezystory łącznie 30 Ohm, to razem 45 Ohm, razy 0,8A to daje potrzebne napięcie zasilające 36V. Nie wiem, jakie masz napięcie na wyjściu stabilizatora, ale podejrzewam, że mniejsze. Poza tym w różnych trybach w różnych pozycjach silnika zapotrzebowanie na prąd zasilający może się zmieniać, a to spowoduje różne spadki napięcia na rezystorach szeregowych. Dlatego ja proponowałbym (biorąc pod uwagę rezystancję cewki i wymagany prąd) zwykły zasilacz 12V napięcia stałego (wystarczy niestabilizowany) o wydajności prądowej minimum 1A, bez rezystorów w szereg z zasilaniem silnika. Do prób powinno wystarczyć. Gdybyś chciał bardziej precyzyjnie dobrać zasilanie silników, zerknij tutaj. Jak już wspomniał wcześniej kolega @FlyingDutch , jednego kroku możesz nie zauważyć, więc dobrze byłoby zrobić pętlę nieskończoną. Ja chciałbym tylko zwrócić uwagę, że kiedy tworzysz pętlę, to trzeba dodać w pętli jeszcze jedno opóźnienie. No i dałbym krótsze te opóźnienia. Podczas pracy pełnokrokowej, przy opóźnieniu 0,1s i 200 krokach na obrót, jeden obrót będzie trwał 40 sekund (podczas pracy mikrokrokowej jeszcze więcej) więc to i tak bardzo wolne obroty. while True: GPIO.output(16, GPIO.HIGH) #stan_wysoki time.sleep(0.1) GPIO.output(16, GPIO.LOW) #stan_niski time.sleep(0.1)
  4. andrews

    Duszki NIXIE SN74141 - multipleksowanie

    Jeśli chodzi o częstotliwość multipleksowania, to chyba trzeba będzie dobrać eksperymentalnie. Być może trzeba będzie nieco zwiększyć, ale nie przesadzałbym. Myślę, że maksymalnie około 600Hz powinno wystarczyć. Istnieje jednak jeszcze inna możliwość. W przypadku multipleksowania wyświetlaczy LED wystarczy zgaszenie jednej cyfry i zapalenie w trakcie jednej procedury obsługi przerwania. W przypadku nixie jednak taki czas wygaszania cyfry może być niewystarczający. Rozwiązanie, które przedstawiłem powoduje, że ten czas wygaszenia jest wystarczająco długi, ale może niekoniecznie musi być aż tak długi. Właściwie powinien być tylko tak długi, na ile to konieczne, by uniknąć prześwitywania, oraz wystarczająco krótki, aby uniknąć ewentualnego efektu migotania. Dlatego dobrym rozwiązaniem byłoby skrócenie czasu wygaszenia, a wydłużenie czasu, kiedy cyfra świeci. Można to osiągnąć, zmieniając odpowiednio wartość rejestru OCR0 w trakcie obsługi przerwania, np.: // wewnątrz procedury obsługi przerwnia można dodać linijki if (licznik) { // ustalenie czasu wygaszenia OCR0 = 2; // wygaszenie wszystkich wyświetlaczy; ANODY_PORT = (ANODY_PORT | MASKA_ANODY); NIXIE_DATA = 0xFF; } else { // ustalenie czasu świecenia OCR0 = 10; // cykliczne przełączanie kolejnej anody ANODY_PORT = (ANODY_PORT & ~MASKA_ANODY) | (anoda & MASKA_ANODY); // ... reszta kodu } Wartości rejestru OCR0 są przykładowe, należy je dobrać eksperymentalnie, ale dzięki takiemu rozwiązaniu można uzyskać lepsze proporcje czasu świecenia do czasu wygaszenia.
  5. andrews

    Duszki NIXIE SN74141 - multipleksowanie

    Moim zdaniem w przypadku multipleksowania nixie lepszym sposobem jest naprzemienne gaszenie i zapalanie kolejnych cyfr. Inaczej to ujmując, w nieparzystych przerwaniach gasisz wszystko (wyłączasz wszystkie anody i katody), a w parzystych zapalasz kolejne cyfry. Przykładowa procedura obsługi przerwania (starałem się zbyt wiele nie zmieniać, więc może nie być optymalnie, ale powinno działać): ISR(TIMER0_COMP_vect) { static uint8_t anoda = 1, licznik; licznik ^= 1; if (licznik) { // wygaszenie wszystkich wyświetlaczy; ANODY_PORT = (ANODY_PORT | MASKA_ANODY); NIXIE_DATA = 0xFF; } else { // cykliczne przełączanie kolejnej anody ANODY_PORT = (ANODY_PORT & ~MASKA_ANODY) | (anoda & MASKA_ANODY); switch (anoda) { case 1: NIXIE_DATA = pgm_read_byte( &cyfry[godzina1] ); break; case 2: NIXIE_DATA = pgm_read_byte( &cyfry[godzina2] ); break; case 4: NIXIE_DATA = pgm_read_byte( &cyfry[minuta1] ); break; case 8: NIXIE_DATA = pgm_read_byte( &cyfry[minuta2] ); break; case 16: NIXIE_DATA = pgm_read_byte( &cyfry[sekunda1] ); break; case 32: NIXIE_DATA = pgm_read_byte( &cyfry[sekunda2] ); break; default: NIXIE_DATA = 0xFF; break; } anoda <<= 1; } if (anoda > 32) { anoda = 1; } }
  6. andrews

    Sterownik Pololu i pompka

    A sprawdzałeś może używając większych współczynników wypełnienia PWM? ...lub nawet podając na pin PWMA na stałe logiczną jedynkę (czyli PWM=100%)? Jeszcze uwaga dotycząca zmiany kierunku obrotów. Wprawdzie to mały silniczek i ma zapewne małą bezwładność, niemniej nie polecałbym takiej gwałtownej zmiany kierunku wirowania. Po odczekaniu tych 20s najpierw wyłącz obroty (np. wolny wybieg poprzez AIN1=0, AIN2=0 lub hamowanie poprzez PWMA=0), odczekaj chwilę i dopiero włącz obroty w drugą stronę.
  7. andrews

    Duszki NIXIE SN74141 - multipleksowanie

    Schemat to jedno, istotny jest również algorytm multipleksowania. Lampy NIXIE mają dużo większą bezwładność (czas gaśnięcia cyfry po odłączeniu napięcia sterującego) w porównaniu z LED, dlatego należałoby to uwzględnić w kodzie. Kodu nie przedstawiłeś, więc trudno się wypowiedzieć, czy Twój algorytm multipleksujący jest odpowiedni. Zwykle multipleksowanie odbywa się cyklicznie w procedurze obsługi przerwania jakiegoś timera, więc gdybyś mógł przedstawić chociaż ten fragment kodu, może udałoby się coś podpowiedzieć. Myślę, że przy prawidłowym algorytmie multipleksowania kombinowanie z diodami może okazać się zbędne.
  8. andrews

    AVR util/delay.h problem

    Problemem mogą być źle skonfigurowane ścieżki do plików nagłówkowych. Poczytaj może ten wątek.
  9. Nie sądzę, że to powoduje problemy. Przed zaprogramowaniem nowego wsadu zawsze wykonywana jest komenda Chjp Erase, która kasuje zawartość FLASH, EEPROM oraz lock bity, więc jeśli tam miałeś jakiś bootloader, to już powinien zostać wykasowany po wgraniu programu przez avrdude. Chip Erase nie kasuje tylko fuse bitów, więc trzeba je zmienić samodzielnie. Stąd zapewne ta "pozostałość" w postaci ustawionego fuse bitu BOOTRST. Napisałeś, że przekompilowałeś program. Zakładam, że wgrałeś go do mikrokontrolera przed sprawdzeniem, czy dioda działa? Przy takich ustawieniach fuse bitów z prawidłowo podłączonym rezonatorem kwarcowym program musi działać. Jesteś pewny, że fuse bity zostają faktycznie prawidłowo zmienione w mikrokontrolerze? Odczytywałeś je z mikrokontrolera po ich ustawieniu? Czy na pewno program jest prawidłowo wgrany i zweryfikowany? avrdude nie wyświetla żadnych błędów w konsoli? Zasilanie masz stabilne i dobrze odfiltrowane? Operujesz na płytce stykowej? Połączenia dobrze kontaktują? Z Twoich postów wynika, że raz coś działa, raz nie, więc może problem nie jest w fuse bitach tylko po stronie sprzętowej (np. niestabilne połączenia). Jeśli w programie nic nie zmieniasz, tylko ponownie go kompilujesz przed wgraniem z odpowiednio zmienioną wartością F_CPU, to raczej nie jest to wina kodu, skoro działa przy wewnętrznym oscylatorze. Trudno tak zdalnie doradzić co jeszcze może być nie tak. Podałeś trochę mało informacji, więc trudno się domyślać. Mógłbyś ewentualnie pokazać jednak mimo wszystko kod programu i może jakieś zdjęcie, jak to masz połączone.
  10. Stopień komplikacji programu nie ma związku ze stabilnością pracy oscylatora. Proponuję jednak podłączyć te kondensatory (z zakresu12-22pF). Jeśli chodzi o wartość bajtu low, powinno być OK. Jeśli chodzi o wartość bajtu high, to obydwie użyte przez Ciebie wartości włączają fuse bit BOOTRST, który powinien być zaprogramowany w przypadku używania w mikrokontrolerze tzw. bootloadera. Z Twojej wypowiedzi wynika, że nie używasz bootloadera, więc ten bit powinien być wyłączony. Dodatkowo wartość high równa DA oznacza wyłączenie fuse bitu CKOPT, który w przypadku użycia kwarcu 16MHz powinien być włączony. Podsumowując, w Twoim przypadku (po zastosowaniu kwarcu 16MHz prawidłową wartością bajtu high będzie C9. Oczywiście program również wymaga ponownego skompilowania z odpowiednio ustawioną wartością -DF_CPU=16000000UL oraz wgrania do mikrokontrolera. No i pamiętaj o dołożeniu kondensatorów.
  11. Tylko że tak naprawdę program mkAVR Calculator zapisuje bajty konfiguracyjne (fuse bity) do mikrokontrolera właśnie używając avrdude. Jedną z przyczyn Twoich problemów (skoro przy innych ustawieniach taktowania program działa) mogą być źle ustawione fuse bity, dlatego chciałem, żebyś podał wartości bajtów konfiguracyjnych fuse low byte oraz fuse high byte, jakie ustawiłeś, zanim program przestał działać, aby sprawdzić, czy ustawiłeś je prawidłowo. W mkAVR Calculator wartości te powinny być podane na górze okna programu (dwie dwucyfrowe wartości w formacie szesnastkowym oznaczone jako LOW i HIGH). Mógłbyś też dokładniej opisać, jakie kolejne kroki podejmujesz, aby zmienić częstotliwość taktowania. Skoro przy niższej częstotliwości program działa prawidłowo, to przy wyższej też musi, więc jeśli nie działa, to coś na pewno robisz nieprawidłowo.
  12. Rozumiem, że w celu zmiany częstotliwości taktowania ustawienia fuse bit'ów również zmieniasz za pomocą avrdude. Jakiego polecenia używasz, aby zmienić źródło taktowania na wewnętrzny oscylator 8MHz?
  13. Najprawdopodobniej przyczyną jest brak atomowego dostępu do portu LED_PORT. Instrukcja języka C - LED_PORT ^= (1 << LED1); wymaga tak naprawdę wykonania przez mikrokontroler kilku instrukcji asemblera. Jeśli pomiędzy tymi instrukcjami wystąpi przerwanie i zmieni zawartość portu, to po powrocie z procedury obsługi przerwania ta zmiana zostanie cofnięta. Rozwiązaniem może być wyłączenie przerwań na czas zmiany stanu portu: // ... while (1) { _delay_ms(1000); cli(); LED_PORT ^= (1 << LED1); sei(); } // ... Powinno pomóc, jednakże stosowanie funkcji _delay_ms() (szczególnie przy włączonej obsłudze przerwań) nie pozwala na jakieś precyzyjne odmierzanie czasu, więc miganie i tak się prędzej czy później rozjedzie
×