> 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?

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.

do góry

W dniu 2013-08-09 22:24, 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?
>
> 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.

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

do góry

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

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

do góry

> 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.

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.

do góry

On 2013-08-09 18:56, J.F wrote:
> 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 :-)

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

Piotrek

do góry

On 2013-08-09 22:24, sundayman wrote:
> 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.

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

do góry

W dniu 2013-08-10 10:03, Sebastian Biały pisze:
> On 2013-08-09 22:24, sundayman wrote:
>> 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.
>
> 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

do góry

On 2013-08-10 10:31, Dariusz Dorochowicz wrote:
>> 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.

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.

do góry

W dniu 2013-08-10 10:40, Sebastian Biały pisze:
> On 2013-08-10 10:31, Dariusz Dorochowicz wrote:
>>> 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.
>
> 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

do góry

> 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.

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).

do góry