Skocz do zawartości
Wyimaginowana

Lego Mindstorms - jeden czujnik do kilku portów

Pomocna odpowiedź

Witam.

Mam taki problem. Chciałabym podłączyć jeden czujnik światła do dwóch kostek. W internecie znalazłam multipleksery czujników:

- taki http://www.roboshop.pl/lego-2/nxt-multiplekser-dotyku.html

- i taki http://www.roboshop.pl/lego-2/nxt-multiplekser.html .

Wiecie może czy do portów 1, 2, 3, 4 można podłączyć kostki NXT, a do portu oznaczonego NXT wpiąć czujnik? I czy da się to zaprogramować w NXT-G?

Jeśli nie to słyszałam, że można po prostu podzielić druciki w kablach i wpiąć je do dwóch kostek równocześnie. Czy ktoś z Was już coś takiego robił?

Pozdrawiam. 🙂

Udostępnij ten post


Link to post
Share on other sites

Boże to kosztuje 100zł a taki multiplekser na bazarze dostaniesz za 50gr !!! Może nie będzie tak ładnie wyglądał ale będzie działać w 100% tak samo

Udostępnij ten post


Link to post
Share on other sites

Tak ogarnij układ 4051

Udostępnij ten post


Link to post
Share on other sites
Boże to kosztuje 100zł a taki multiplekser na bazarze dostaniesz za 50gr !!! Może nie będzie tak ładnie wyglądał ale będzie działać w 100% tak samo

Poważnie wprowadzasz kolegę w błąd.

Z tego co wyczytałem to tam siedzi układ na I²C, więc nie jest to prosty multiplekser na 4051, i raczej prosto tam niczego nie podłączysz. Gdyby był tam prosty scalak, nie kosztowało by to 130zl tylko 30zł.

Udostępnij ten post


Link to post
Share on other sites

No niestety, tu raczej nie pomogę takie prymitywne metody jak multiplekser analogowy czy nawet ten do I2C (bo niby kto miałby zarządzać jego adresowaniem?). Przede wszystkim sprzęt który wskazała Koleżanka jest jednokierunkowy. Może prowadzić sygnały z kilku czujników do jednej kostki NXT ale odwrotnie - z jednego czujnika do kilku NXT - na pewno nie.

Słusznie zauważyliście, że Lego wykorzystuje protokół I2C. Żeby podpiąć kilka układów SLAVE do jednego MASTER'a jakim jest NXT mających na dodatek te same adresy trzeba po pierwsze odseparować od siebie szyny, po drugie wpleść w informacje wychodzące z MASTER'a dodatkowy adres (czyli nowe drivery programowe) i po trzecie wstawić jakąś inteligencję w sam "multiplekser" po to, by dokonywał zamiany protokołu "rozszerzonego" na "zwykły", rozumiany przez czujnik. To zdaje się robi ten mutiplekser, a najchętniej współpracuje oczywiście z czujnikami specjalnie przygotowanymi (przez tą samą firmę) do rozszerzonego protokołu 😐

A w drugą stronę? Tutaj sytuacja może być łatwiejsza albo trudniejsza 😖 Mówimy tutaj tak naprawdę o zwarciu dwóch osobnych szyn I2C wychodzących z dwóch NXT po to, by obie miały odstęp do tego samego czujnika. Byłoby łatwo, gdyby MASTERy Lego obsługiwały tzw. arbitraż - metodę przewidzianą w protokole I2C w konfiguracjach multiMASTER czyli tam, gdzie na tej samej szynie siedzi więcej niż jeden inicjator transmisji. Metoda opiera się nasłuchiwaniu ruchu oraz wykrywaniu "utraty" kontroli nad linią SDA. Zainteresowanych szczegółami odsyłam do szczegółowych opisów protokołu. Szczerze mówiąc nie spodziewam się, by Lego to obsługiwało bo to by oznaczało, że niektóre operacje z czujnikami mogą się nie powieść (utracono magistralę na rzecz innego MASTERa i co wtedy?), więc bezpośredniego połączenia dwóch szyn raczej bym nie próbował.

Mamy więc raczej do czynienia z sytuacją trudniejszą: musimy nasłuchiwać dwie osobne szyny I2C oraz kierować zapytania z każdej z nich skierowane do tego samego czujnika wiszącego na trzeciej odnodze. To oznacza, że w przypadku jednoczesnych zgłoszeń chęci "pogadania" z czujnikiem jeden z NXT musiałby być jakoś wstrzymany. I2C przewiduje co prawda mechanizm spowolniania transmisji poprzez przytrzymywanie przez układ SLAVE linii SCK w stanie niskim, ale służy to raczej dopasowaniu do prędkości wolniejszych układów a nie do całkowitego wstrzymywania transmisji. Nie wiem, czy NXT nie uznałby tego za awarię szyny. W każdym razie przy "rozgałęzianiu" danych z jednego czujnika do dwóch lub więcej NXTów bez inteligencji (mikrokontrolera) na pokładzie raczej się nie obejdzie.

Udostępnij ten post


Link to post
Share on other sites

Proponuję obejść ten problem inną drogą. Podłącz czujnik do jednego NXT, a do drugiego wartość tegoż czujnika prześlij przez bluetooth.

Udostępnij ten post


Link to post
Share on other sites

Jeżeli dobrze zrozumiałem, działanie tego klocka to działa to bardzo prosto. Do obsługi klocka są specjalne bloczki (funkcje). Działa to w ten sposób że NXT, przepytuje po kolei podpięte do multipleksera czujniki/kanały. Skąd wie ile ich jest i jakie ? To deklarujemy w programie. Nie sądzę że mamy tutaj do czynienia z jakimś skomplikowanym arbitrażem, to prosty protokół, działający na zasadzie pierścienia, mam do kanału 1 i 2 podpięte czujniki, to przepytuje po kolei czujnik 1, za nim drugi, znowu pierwszy i tyle.

Udostępnij ten post


Link to post
Share on other sites

Gdy masz już odpowiednie drivery programowe (bloczki o których wspomniałeś) to dalej działanie jest rzeczywiście "proste". Mamy nowy protokół wymiany danych - z jednej strony realizowany przez procesor NXT a z drugiej rozumiany przez multiplekser - i całość zachowuje się po nowemu. Po prostu używasz tych bloczków i nie musisz wiedzieć, jakie wprowadziło to zmiany na poziomie łącza fizycznego.

W kontekście multipleksera nikt nie mówił o arbitrażu. To pojęcie padło przy okazji współpracy dwóch NXT na jedną magistralę i przypominam, że ten problem jest głównym pytaniem Autorki a nie dywagacje o multiplekserze. Powtórzę jeszcze raz: jeżeli kontrolery NXT nie obsługują arbitrażu I2C to nie mogą działać na wspólnej szynie i tym samym nie da się w prosty sposób podłączyć jednego czujnika do dwóch takich klocków.

Acha, na I2C nie ma czegoś takiego jak "zasada pierścienia". Być może z punktu widzenia programisty robisz coś "w kółko" albo można też sobie wyobrazić (programowe) urzeczywistnienie idei przekazywania tokenu uprawniającego np. do bycia MASTERem (patrz: token ring) ale na poziomie sprzętu szyna I2C jest strukturą w której w danej chwili do nadawania zegara ma prawo tylko jeden MASTER (nieważne czy transmitter czy receiver) a do pracy w takt tego zegara na obowiązek tylko jeden zaadresowany SLAVE (analogicznie może być być receiver lub transmitter). Każdy MASTER musi wiedzieć z kim chce rozmawiać a każdy SLAVE musi znać swój adres. Szyna nie może mieć kilku SLAVEów mających te same adresy wiec z definicji takie same czujniki mające oczywiście takie same adresy muszą być odseparowane od siebie i od reszty szyny czymś inteligentnym i przykryte nowym protokołem ich adresowania na szynie "głównej".

BlackJack, jeśli masz jakieś doświadczenie w oprogramowaniu szyny I2C to poświęć dosłownie 10 minut i spróbuj w ramach ekperymentu myślowego wyobrazić sobie układ, który z jednej strony ma szynę I2C a z drugiej kilka układów SLAVE o tych samych adresach. Czy umiesz zrobić dostęp do nich bez zmiany oryginalnego protokołu lub choćby bez procesora? Jeśli nie (lub co gorsza jeśli nigdy nie wnikałeś jak ta szyna w szczegółach działa), to proszę, nie pisz więcej "działa to bardzo prosto", OK?

Udostępnij ten post


Link to post
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Anonim
Dołącz do dyskusji! Kliknij i zacznij pisać...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.


×
×
  • Utwórz nowe...