kto ma dobrą pamięć...?

Aug 09, 2013 23 Replies

Użytkownik "sundayman" napisał w wiadomości

Czasem sie spotykalo projekty ktore to uzywaly i ponoc dzialaly.

Zwroc uwage na rezystancje kanalu - rzedu 70ohm. Z CMOS i niskimi predkosciami dzialac powinno, na wysokich niekoniecznie (taa, 50pF * 70 ohm= 3.5ns :-)

J.

I może podpowiedzieć z głowy, co się nada ;



potrzebuję przełączać linie TX/RX dwóch mikrokontrolerów do jednego MAX232. Znaczy, żeby jakimś sygnałem wybierać, który MCU jest podłączony do MAX'a. Czyli jakiś 3-stanowy przełącznik mały, kiedyś były jakieś układy 74xxx do tego, ale potrzebowałbym coś SMD.



Podpowiecie ?


Chyba znalazłem - 74HC125 o ile dobrze widzę powinien się nadać.

W dniu 2013-08-09 21:43, sundayman pisze:

a jednak nie bardzo... bo wymaga dodatkowego inwertera, żeby jednym sygnałem sterować.

sundayman snipped-for-privacy@poczta.onet.pl> napisał(a):

A nie masz wolnej nogi w MCU żeby sterować dwoma sygnałami? Z resztą inwerter możesz sobie zrobić na tranzystorze. A układy 74, jak pewnie już zauwazyłeś, bez problemu dostaniesz w obudowach SMD.

nóg mam od cholery, ale to musi być przełączane ręcznie przełącznikiem, i to oddalonym , więc 1 kabelek wskazany. No ostatecznie będę musiał ten negator dać kuśwa, ale niechętnie...kuśwa !

ooo to to ! To załatwia sprawę mam wrażenie. Co prawda to niby "analogowe" jest, ale chyba powinno działać, nie ?

W dniu 2013-08-09 21:32, sundayman pisze:

Na wszelki wypadek zapytam: masz wpływ na program mikrokontrolerów i ich konfigurację? Czy musisz po prostu użyć sygnału niezależnego od tego, co siedzi w kontrolerach?

Pozdrawiam

DD

sundayman snipped-for-privacy@poczta.onet.pl> napisał(a):

Jak to ma służyć do wgrywania firmware'u, to nie wystarczą po prostu piny i jumpery/zworki?

Mam oczywiście, ale chodzi o to, żeby rozwiązanie było niezależnie od nich, bo trzeba przełączać RS w tym celu, żeby można było wgrać firmware via bootloader obu MCU. Czyli przełączanie będzie małym przyciskiem na PCB - albo RS jest podłaczony do 1-go, albo do 2-go.

No taka kombinacja trochę, ale to jest modyfikacja już istniejącego urządzenia - musiałem dołożyć drugi MCU, ale chcę zachować możliwość zmiany softu przez RS.

W dniu 2013-08-09 22:24, sundayman pisze:

Aha, no to potencjalnie (bo to zależy od tego, co masz) dałoby się zrobić tak, że łączysz odbiornik MAXa do obu procków na raz, a odpowiednim poleceniem dopiero włączasz sterowanie z odpowiedniego procka nadajnikiem na jakiś czas itd... Wtedy zero dodatkowego hardware, ale to już zależy od tego, co masz i co możesz, bo jeżeli jest standardowy bootloader na który nie masz wpływu, to faktycznie będzie problem. Wtedy rozwiązanie z kluczem analogowym jest OK, tak się robi np na płytkach z Atmega128, gdzie któryś z interfejsów programowania bodaj właśnie z UARTem się pokrywa.

Pozdrawiam

DD

Nie, bo RS jest dostępny od frontu dla użyszkodnika, i to on ma ew. wymienić firmware.

bootloadery mogę przerabiać, ale tak czy owak najbezpieczniej jest dać na PCB switch. W 99% zmieniany będzie firmware w MCU"głównym", a w tym dodatkowym nie spodziewam się, więc konieczność przełączenia mechanicznym przełącznikiem nie jest problemem, a może nawet dodatkowym zabezpieczniem.

No oczywiście, ale wątkotwórca chce przez to przepuścić jedynie transmisję szeregową z/do MAX232.

Piotrek

Nie możesz zmienić protokołu wymiany firmware tak aby był adresowalny? Wtedy sluchają oba a tylko jeden reaguje.

A jest (być może) również taka opcja, że jeden może robić za pośrednika dla drugiego... Oczywiście zawsze trzeba przemyśleć konsekwencje.

Pozdrawiam

DD

To wymaga w pośredniku 2x układu komunikacji, a to zapewne oznacza 2x uart lub jakieś obleśne rękodzieło. IMHO trywialny adresowalny protokół wymiany firmware pozwala zrobić iloczyn montażowy na drutach tx i rx i nie przejmowaz się zbędnym hardware, w dodatku jest bardziej odporny na błedy niż przeciętny user który ma wcisnąć jakiś przycisk i jak ma jeden do wyboru to już ma dylemat.

Mam tak zrobione (adresowalny protokół i iloczyn montażowy)i sobie chwalę, z resztą na tych samych drutach komunikuje się z nimi jeszcze inny procesor i nikt nikomu nie przeszkadza.

A pewnie, i to jest generalnie lepsze rozwiązanie, tylko właśnie czasem może być trudniejsze. Konkretnej aplikacji nie znam, nie wiem, co łatwiej zrealizować w konkretnym przypadku. Tylko podaję jeszcze jedno rozwiązanie.

Pozdrawiam

DD

pomysły ciekawe, ale tutaj to przerost formy nad treścią. Sprawa jest taka - trzeba szybko (czyli bez wymyślania zbytecznych rzeczy) rozbudować istniejący projekt urządzenia o dodatkowy MCU, pełniący w sumie funkcję nadzorczą ( takie dodatkowe zabezpieczenie ).

Zmiany firmware są jak dotąd wykonywane w przypadku ew. wykrycia jakiegoś poważnego błędu w programie, i dlatego użyszkodnik musi mieć taką możliwość. Ale, nadal będą to raczej zmiany w MCU1 (czyli tym pierwotnym), a możliwość zmiany w MCU2 jest tylko na "wszelki wypadek".

Użyszkodnik to nie osoba z ulicy, a przeszkolony instalator, więc ew. konieczność przełączenia przełącznika na PCB nie jest żadnym problemem.

Wszystkie inne koncepcje wymagają przeróbek programowych, w zamian nie oferując niczego poza rezygnacją z tego switcha, a to jest zysk nie wart zachodu w tym przypadku. W pierwszym podejściu miałem nawet zrobić po prostu dodatkowe złącze (schowane), i wyprowadzić na nie TX/RS bez MAX'a, no ale w razie konieczności wymiany firmware MCU1 trzeba by wtedy użyć czegoś więcej niż kabelek RS. A skoro mam RS232 i tak już wyprowadzony, to rozwiązanie ze switchem jest całkowicie wystarczające.

W przyszłości, jeśli będę miał czas na to, to mogę wersję switchową zamienić w "szeregową", ponieważ oba procesory się komunikują via TX/RX i mogą się wzajemnie resetować, więc jest to tylko wtedy zabieg softwareowy (no i oczywiście nie montujemy zbytecznego switcha).

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required