rezolut

Odpowiem sam sobie, że opóźnienia w zerowaniu portu po odjęciu sygnału wysokiego wynikają z braku rezystorów pull-down. Z rezystorami są znacząco niższe. Nie potrafię dobrać wartości rezystora, ale to kwestia czasu, prób i błędów. Nadal zagadką zostaje dlaczego bez pull-down port sam zmienia stan po określonym czasie, akurat takim a nie innym?

Prosiłbym o pomoc w ujarzmieniu MCP23017. MCP na porcie A ma diody, na porcie B chciałbym ustalać stan czujników - jeszcze nie sprecyzowanych, powiedzmy że dających 1 (VCC), która mnie interesuje w momencie zdarzenia, w spoczynku 0 (0V). MCP podpięty poprawnie, I2C działa, przerwanie teoretycznie też, Arduino reaguje na przerwanie, ale..... no właśnie. Wg noty układ porównuje stan na wejściu portu z rejestrem DEFVAL. Jeśli w DEFVAL są 0 a wejście podany stan VCC to teoretycznie powinno wystąpić przerwanie (zmiana stanu na pinie Arduino), wychwycone w trybie: albo RISING, albo FALLING. I do tego dążę. Nie bardzo mi jednak to działa. Arduino nie wychwytuje przerwania. Gdy INTCON=0, czyli gdy MCP ma generować przerwanie przy zmianie stanu wejścia w stosunku do stanu poprzedniego - program działa. Działa, ale... podanie stanu np. na portB.4 (wartość 16) jest rozpoznawane i po chwili po zdjęciu sygnału z portu wartość ta jest zmniejszana nie zerowana. Ustawienie VCC na portB.0 daje 1, potem na portB.1 daje 3 - czyli układ pamięta stan portB.0. Potem kolejno zmniejsza wartość portu na 1 i dopiero na 0. Ktoś konfigurował MCP23017 do pracy z przerwaniem? Moje ustawienia - wyżej opisane i raczej jedyne działające to: IODIR=0xFF - wejście IPOL=0x00 - bez zmiany logiki GPINTEN=0xFF - zezwolenie na przerwanie - odpalone jako ostatnie w konfiguracji DEFVAL=0x00 - wartość do porównania ze stanem na wejściu INTCON=0x00 - przerwanie gdy zmiana stanu na wejściu - powinno być raczej 0xFF, czyli przerwanie gdy wartość wejścia różna od 0 (od DEFVAL) IOCON=0x00 - przerwanie Active_Low, czyli chyba w momencie zdarzenia na porcie wystawiany stan niski - z resztą Arduino tak wychwytuje przerwanie ustawione na FALLING GPPU=0X00 - wejścia nie podciągnięte - zależy mi na 1 przy stanie VCC Co ja tu mogłem przegapić, że przerwanie nie generuje się raz, tylko po podaniu stanu wysokiego na któryś pin portu B? [ Dodano: 17-02-2017, 21:33 ] OK, powiedzmy, że ogarnąłem temat i to co osiągnąłem musi mi wystarczyć - tj. reakcja układu na impuls wysoki z czujnika i reakcja na niski. Problem w tym, że podając impulsy szybko na kolejne piny, i od razu je zdejmując MCP (albo Arduino?) nie reaguje natychmiast a z pewnym opóźnieniem. I mam coś takiego. PIN 1 PORT 1 1 PIN 2 PORT 3 3 PIN 4 PORT 7 7 PIN 8 PORT 15 15 PIN 16 PORT 31 31 /... przerwa czasowa... kilkaset ms....// PIN 1 PORT 30 30 PIN 2 PORT 28 28 PIN 4 PORT 24 24 PIN 8 PORT 16 16 PIN 16 PORT 0 0 Czy te opóźnienia to kwestia konfiguracji? Od czego one zależą?

Miałoby to sens gdybyś używał UARTa, np. do komunikacji z PC, z wpiętym monitorem portu. Jeśli nie, układ zasilony z innego źródła niż USB, pin powinien działać jak każdy inny pin.

A ja znalazłem, że to TowerPro cyfrowe: http://www.towerpro.com.tw/product/mg90s-3/ http://www.servodatabase.com/servo/towerpro/mg90s Cichość. Wiem, pojęcie względne. Serwo jednak wydaje bzyczenie 🙂 Są momenty, że go w ogóle nie słychać i o to mi właśnie chodzi. Nie myślę oczywiście o momencie pracy ale o spoczynku w ustalonej pozycji. Obciążenie niewiele tu zmienia. Zbyt duże jeszcze pogarsza sprawę, ale nie stosuję zbyt wielkiego jak mi się zdaje. Próbowałem je uchwycić https://youtu.be/nqyzktxQ7Ks, ale nie wiem czy słychać. Pod koniec filmu udało mi się ustalić położenie gdzie zamilkło. Bzyczenie może i chiche, ale docelowe miejsce jest jak pudło rezonansowe i buczenie kilku takich serw naprawdę słychać. No nic, czekam na MS90S....

No... za 17zł - MG90S. ale czy ono będzie ciche?

Dokładnie tak jest, na 8 serw pracujących "graja" 2-3, za chwilę jakieś 2-3 inne... Czyli zabawka za 10 zł, ale cyfrowa, mogłaby poprawić sytuację? Potrzebuję 26 takich serw, więc koszt ma tu znaczenie. Rozmiar, szybkość, dokładność, udźwig - mniej, ale cisza - jak najbardziej.

Zasilanie - 5V z USB Sterowanie - Arduino 16MHz, biblioteka Serho.h Zasilanie - zasilacz impulsowy 5V/3A Sterowanie - układ z ATmega328 16MHz, PWM (nie pamiętam czy sprzętowy, czy programowy) W obu wypadkach to samo. Nie tyle, że się rusza. W zasadzie stoi, trzyma pozycję, ale to trzymanie czasami dość głośno słychać. Ruchu serwa praktycznie nie ma, jeśli jest to jakiś mikro. Czy to tylko piski plastikowych trybów? Nie wiem, czy zmiana na MG90s z metalowymi trybami załatwi sprawę, czy musiałbym mieć rozmiarowo większe serwo.

Mam problem z serwem SG90. Problem polega na tym, że serwo po wybraniu odpowiedniej pozycji cały czas dokonuje badania i korekt położenia. Ja wiem, że to normalna sytuacja, ale serwo przy tym dość głośno hałasuje i to bez obciążenia. Raz przy tym samym nastawieniu znajdzie jakiś złoty środek i milknie całkiem, kiedy indziej cały czas pracuje "wokół" zadanego położenia robiąc przy tym spory hałas. Hałas czasami ustaje po dłuższym lub krótszym czasie Domyślam się, że "rozdzielczość" pracy serwa jest pewnie związana z mechaniką trybów jakie posiada i w małych serwach nie ma się czego innego spodziewać. Że ten typ po prostu tak ma. Ale czy aby na pewno? Czy istnieją jakieś małe serwa - wielkości zbliżonej do SG90 - które posiadają więcej zębów w trybach przekładni i dokładniej stabilizują się w zadanej pozycji bez dodatkowych buczeń i hałasów?

Nic odkrywczego. Układ działa na przykładach z https://www.arduino.cc/en/Reference/SoftwareSerial choć mam problemy z komunikacją dwustronną - że tak powiem - dłuższą wymianą zdań między procesorami 🙂 Problemem jest że procesor na raz może słuchać tylko jednego UARTa programowego, więc trzeba się między nimi przełączać [listen()]. To wymaga albo zwrotnych danych z układu do Arduino, albo timeoutu w Arduino. Z pierwszym mam problem, drugiego jeszcze nie umiem napisać.

Dzięki za obszerne rozważania. Wiedza taka się na pewno przyda. Układ oczywiście narysowany mocno ideowo. W docelowym układzie pin "A1" podciągnięty jest jeszcze do VCC przez rezystor 4,7k a na bazie tranzystora planowałem dać również rezystor. Okazało się na szczęście, że układ posiada dwa wolne piny, na których w Arduino mogę stworzyć softwareserial. W poprzedniej wersji programu, tworzonej w BASCOM nie mogłem (może bardziej - nie umiałem). Testowo układ działa: i na przycisk, i reaguje na rx/tx.

Pomysł jest jeszcze taki, żebyś ożywił stare Arduino i wgrał bootloader.

Przycisk Arduino - sorry, skrót myślowy. Oczywiście chodzi o pin/wyjście. Część czarna to układ istniejący - ATmega16, 5V, przycisk to zwykły switch. Część niebieska - to coś co chcę dorobić np. na Arduino 5V Właściwie to zasilanie 5V mogłoby od biedy być wspólne. Choć rozważam oddzielne i wolałbym połączyć układy tylko masami. Nie chcę używać przekaźników, chciałbym możliwie najprostsze rozwiązanie.

Spróbuj w menedżerze zmienić nr COM na np. COM9. Nic to nie kosztuje a ciekawi mnie czy zadziała 🙂

Mam układ mikropresora z przyciskami sterującymi - standardowo zwieranymi do masy. Układ zamknięty i nie chcę tworzyć nowego. Czy jest możliwość wysterowania jego przyciskami z Arduino? Oba układy mają oddzielne zasilania (masa wspólna). Czy mniej więcej taka byłaby idea połączenia?

A to nie jest kwestia konfliktu starych sterowników USB? Aktualizuj sterownik wirtualnego portu COM. We właściwościach portu, w menedżerze urządzeń zweryfikuj ustawienia transmisji. Można też zmienić na wyższy nr COM, żeby przypadkiem nie kolidował z jakimiś innymi programami. Podczas wgrywania programu wszystkie terminale korzystające z COM powinny być odłączone.