Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[ATMEGA[BASCOM]Bootloader <>RS 485

adambehnke 31 Oct 2010 23:47 9848 37
IGE-XAO
  • #1
    adambehnke
    Level 24  
    Witam
    Mam czysto teoretyczne pytanie. Otóż w mojej sieci RS485 pracuje kilka urządzeń ale docelowo pewnie przekroczę 20. Co pewien czas zajdzie zapewne potrzeba zmiany programu w atmegach pracujących w modułach. Czy jest jakaś możliwość aby móc wpiąć się do sieci RS485 i zmienić sobie zdalnie oprogramowanie każdego modułu z osobna?

    Proszę o sugestie na temat możliwej realizacji takiego pomysłu. Jestem w trakcie tworzenia kilku modułów jednocześnie i mam jeszcze możliwość dołożyć(zmienić) w nich to i owo.
  • IGE-XAO
  • Helpful post
    #2
    mirekk36
    Level 42  
    A czemu miałoby nie być takich możliwości, przecież RS485 to jeden z podstawowych interfejsów komunikacyjnych ;)

    Taki Bootloader nawet nie musi się dużo różnić od bootloadera dla RS232.... wystarczy przerobić go tak, żeby "gadał na tematy podmiany firmware" z Masterem tylko wtedy gdy master adresuje to do niego ;) czyli dokładnie tak jak roisz wszystkie inne zadania na RS485.
  • Helpful post
    #3
    hotdog
    Level 26  
    Masz moim zdaniem 2 sposoby na zrobienie tego - łatwy i fajny:
    - Łatwy - wykorzystujesz normalny bootloader (jest kilka ogólnodostępnych wspierających RS485). Urządzenie przestawiasz w tryb bootloadera. Najłatwiej to zrobić ręcznie (czyli Reset + np trzymać jakiś przycisk), ale można tez zrobić to programowo. Dalej programujesz urządzenie "normalnie". Tutaj dużo zależy od Twojego protokołu. Ważne jest żeby żadne z urządzeń poza programowanym nie dokonało arbitrażu magistrali w trakcie programowania. Najłatwiej je wyłączyć podczas wgrywania, ale jest duże prawdopodobieństwo że to i tak zadziała bez tego. Zalety: Praktycznie zerowy nakład z Twojej strony.
    - Fajny sposób: Piszesz własny bootloader który będzie pracował w oparciu o twój protokół. Wtedy możesz nawet zaktualizować wszystkie urządzenia jednego typu naraz. Niestety w tym wariancie musisz napisać program na uC i loader na PC praktycznie od zera. Poza tym jego kod będzie na pewno większy od bootloadera łatwego.

    Pozdrawiam
  • #4
    adambehnke
    Level 24  
    Hmm , z tym rozpoczęciem programowania poprzez reset to lipna sprawa niestety. Moduły są rozsiane w róznych miejscach i właśnie dlatego założyłem ten temat. Myślałem że już może ktoś to zrobił wcześniej. Ja osobiście wolałbym użyć np. watchdoga do inicjacji wgrywania oprogramowania czyli : wysłać poprzez rs485 polecenie np: firmware_1 i to polecenie było by znakiem że moduł 1 będzie aktualizowany i pozostałe moduły mają siedzieć jakiś tam określony czas tylko na nasłuchu i czekać aż moduł 1 potwierdzi że jest zaktualizowany .

    Tak ja bym to widział.
  • Helpful post
    #5
    mirekk36
    Level 42  
    adambehnke wrote:
    wysłać poprzez rs485 polecenie np: firmware_1 i to polecenie było by znakiem że moduł 1 będzie aktualizowany i pozostałe moduły mają siedzieć jakiś tam określony czas tylko na nasłuchu i czekać aż moduł 1 potwierdzi że jest zaktualizowany .
    .


    A dlaczego miałyby jakoś specjalnie siedzieć na nasłuchu - a co tak normalnie sobie nadają wg życzenia ? ;) .... Wystarczy odpiąć MASTER'a i program na PC przejmie jego rolę. Wtdy tylko on będzie "gadał" z wybranym upgrejdowanym modułem. Można też bez wypinania Mastera ale wtedy trzeba zrobić sobie protokół, który sprawdza czy na magistrali nie pojawił się "Slave programator" czyli nasz PC, a jeśli tak to wtedy master dostaje rozkaz grzecznie i cicho siedzieć bo teraz programator będzie gadał ;) .... gdy już się nagada z wybrańcami które chciał zupgrejdować to poinformuje Mastera, że może wracać z urlopu i znowu rządzić na magistrali ;)
  • Helpful post
    #6
    hotdog
    Level 26  
    adambehnke wrote:
    Hmm , z tym rozpoczęciem programowania poprzez reset to lipna sprawa niestety. Moduły są rozsiane w róznych miejscach i właśnie dlatego założyłem ten temat. Myślałem że już może ktoś to zrobił wcześniej. Ja osobiście wolałbym użyć np. watchdoga do inicjacji wgrywania oprogramowania czyli : wysłać poprzez rs485 polecenie np: firmware_1 i to polecenie było by znakiem że moduł 1 będzie aktualizowany i pozostałe moduły mają siedzieć jakiś tam określony czas tylko na nasłuchu i czekać aż moduł 1 potwierdzi że jest zaktualizowany .

    Tak ja bym to widział.


    To będziesz musiał się trochę napocić. Po pierwsze jak używasz watchdoga w programie, to musisz w jakiś sposób sprawdzić czy reset aby na pewno służył do upgrade'u. Możesz to zrobić np przez zapis do eepromu jakiejś wartości, odczyt i odczyt jej bootloaderze (pamiętaj żeby bootloader ją resetował). Dobry by był też mechanizm który by pozwolił na zrezygnowanie z upgreadu jeżeli np program na PC się nie zgłosi po jakimś czasie. Ostatnio gdzieś przeczytałem że nie trzeba wykorzystywać eepromu, że wystarczy do RAM'u zapisać wartość i odczytać, ale nie sprawdzałem tego.

    Jak chcesz sobie ułatwić wszystko jak najbardziej, to wykorzystaj jakiś gotowy projekt, który pozwala wysłać jakiś ciąg znaków (czyli firmware_1) przez port szeregowy przed aktualizacją. Jest to dosyć ważne, bo niektóre projekty np czekają 3 s. na jakiś znak od PC, a później włączają już program główny. Albo np bootloader od razu wysyła znak i czeka na odp 100ms. Wtedy ciężko będzie Tobie zresetować program z terminala i szybko włączyć loader na PC.

    Możesz też dla pewności ustawić resztę urządzeń slave, których upgrade nie dotyczy w stan uśpienia (np 1min).

    Pozdrawiam
  • Helpful post
    #7
    mirekk36
    Level 42  
    hotdog wrote:
    To będziesz musiał się trochę napocić. Po pierwsze jak używasz watchdoga w programie, to musisz w jakiś sposób sprawdzić czy reset aby na pewno służył do upgrade'u. Możesz to zrobić np przez zapis do eepromu jakiejś wartości, odczyt i odczyt jej bootloaderze (pamiętaj żeby bootloader ją resetował). Dobry by był też mechanizm który by pozwolił na zrezygnowanie z upgreadu jeżeli np program na PC się nie zgłosi po jakimś czasie.


    Ależ nie potrzeba takich sztuczek aż robić, chociaż można jeśli ktoś koniecznie chce. Wystarczy po prostu, że Master, czyli komputer który chce wgrać upgrejd wyśle komendę do konkretnego modułu Slave i nakaże mu się zresetować za pomocą watchdoga. Po resecie rozpocznie się program bootloadera, który przez przez kilka sekund będzie czekał na dane od mastera, oczywiście każda paczka odpowiednio także zaadresowana - czyli bootloader musi tylko sprawdzać czy na początku każdej paczki jest jego własny adres, jeśli jest to programuje stronę i odsyła potwierdzenie i prośbę zarazem do mastera o kolejną paczkę bo już jest gotów ..... i tak aż do całkowitego wgrania nowego wsadu. W czym problem? I bez żadnych zapisów do eepromu czy ramu.

    Jeśli zaś Slave się sam zresetuje w trakcie pracy to nic się nie stanie, gdyż przez pierwszych kilka sekund będzie czekał na dane do firmware. Jeśli ich nie dostanie to rozpocznie normalną pracę i już.
  • #8
    adambehnke
    Level 24  
    To wszystko brzmi bardzo prosto ale dla Was :) W sumie dla mnie także ale z wykonaniem pewnie się sporo nagimnastyluję.
    Mam najważniejsze pytanie od strony sprzętowej. Czy od strony elektronicznej będę musiał coś zmodyfikować czy wszystko da się załatwić od strony programowej. Do załadowania nowego oprogramowania potrzebny jest reset procesora który dam radę załatwić dzięki Watchdog-owi więc chyba nic więcej zmieniać nie musze. Mam zrobione sobie przejściówkę USB-RS485 na FT232RL i właśnie przez nią mam zamiar ładować nowe oprogramowania.
    Czy o czymś nie pomyślałem. Apropo , co z programem na PC? Czego użyć? Mogę napisać coś pod Visual Basic ale nie wiem czy podołam. Mam napisane sobie programik terminalowy właśnie obsługujący moją sieć i mogę z niego wysyłać przygotowane pod klawiszami komendy do moich modułów. Ale zapewne daleka droga aby coś takiego samemu sklecić.
  • #9
    mirekk36
    Level 42  
    Tak jak piszesz, procki w modułach Slave można spokojnie a nawet trzeba i warto resetować za pomocą watchdoga (zdalnie).

    Korzystam dokładnie tak samo z przejściówki USB/RS485 na FT232RL.

    tutaj fotka - w tej chwili tak właśnie to wygląda przed moim monitorem - cały czas nad tym pracuję ;)

    [ATMEGA[BASCOM]Bootloader <>RS 485

    to sterownik Slave
    [ATMEGA[BASCOM]Bootloader <>RS 485

    a to konwerter USB/RS485
    [ATMEGA[BASCOM]Bootloader <>RS 485

    No i teraz pisanie programu na PC pozostaje. Niestety tu trzeba coś pomyśleć żeby było zgrabnie/ładnie i wygodnie.

    Ja niedługo będę wszczepiał taką możliwość w mój programik na PC - MkBootLoader

    https://www.elektroda.pl/rtvforum/topic1343484.html
  • IGE-XAO
  • #11
    mirekk36
    Level 42  
    adambehnke wrote:
    Małe pytanie. W jakim celu Stosujesz przetwornice DC/DC w tym układzie?


    Totalna izolacja galwaniczna wszystkich układów na magistrali - bo będzie ona miała długość ze 300m i będzie pomiędzy różnymi kondygnacjami dużego budynku. Każdy moduł Slave będzie zasilany lokalnie a wiadomo, że różnie to bywa z 230V ;) więc żeby nie poszło jakieś wyrównanie potencjałów po magistrali to dlatego tu akurat zastosowałem optoizolację dla sygnałów oraz przetwornicę DCDC żeby w pełni odizolować także zasilanie.
  • #12
    hotdog
    Level 26  
    mirekk36 wrote:

    Ależ nie potrzeba takich sztuczek aż robić, chociaż można jeśli ktoś koniecznie chce. Wystarczy po prostu, że Master, czyli komputer który chce wgrać upgrejd wyśle komendę do konkretnego modułu Slave i nakaże mu się zresetować za pomocą watchdoga. Po resecie rozpocznie się program bootloadera, który przez przez kilka sekund będzie czekał na dane od mastera, oczywiście każda paczka odpowiednio także zaadresowana - czyli bootloader musi tylko sprawdzać czy na początku każdej paczki jest jego własny adres, jeśli jest to programuje stronę i odsyła potwierdzenie i prośbę zarazem do mastera o kolejną paczkę bo już jest gotów ..... i tak aż do całkowitego wgrania nowego wsadu. W czym problem? I bez żadnych zapisów do eepromu czy ramu.

    Jeśli zaś Slave się sam zresetuje w trakcie pracy to nic się nie stanie, gdyż przez pierwszych kilka sekund będzie czekał na dane do firmware. Jeśli ich nie dostanie to rozpocznie normalną pracę i już.


    W sumie masz rację. Ja stosowałem taką sztuczkę bo w urządzeniu które kiedyś projektowałem a mocno nie chciałem wprowadzać opóźnienia przy włączaniu. Jakoś zapomniałem, że czasami to nie ma aż tak dużego znaczenia.

    Pozdrawiam
  • #13
    SP3SWJ
    Level 18  
    Witajcie

    Z bootloaderem na 485 to nie tak prosto... :-(

    Trzeba oczywiście bootloadera przerobic by obsługiwał TX/RX - należy pamiętać że z tym RS mam SIMPLEX a nie DUPLEX.

    Deklarujemy który pin steruje transceiverem RS485

    Code:

    Config Print0 = Portd.4 , Mode = Set
    Config Pind.4 = Output



    Trzeba zastrzec z zwykłym protolole pewne znaki które są zarezerwowane wyłącznie dla bootloadera

    Wywołanie bootloadera można zrobić "wprost"

    Code:
    If Rs_char = 27  Then : Goto &H1C00        
    

     ' "ESC" jump to BOOTLOADER  1024 kb  from end of MEGA8 memeory


    Oczywiście skakanie tam za pomocą watchdoga też działa :-)

    Zarówno część na PC i uC musi być trochę "przymulona" czyli nadawanie musi odbywać się z delikatnym opóźnieniem.

    Od kilku dni walczę z tym tematem z użyciem na PC gotowego programu z MCS BASCOM.. ale nie obejdzie się chyba bez własnego bootloadera na PC.

    Przerobiony Bootloader (BAS) na uC pod moją płytkę w trybie RS232 działa bezbłędnie - ale z RS485 aż jeden raz udało mu się przejść...

    Interfejs 485 na PC musimy mieć "bez echa" lub jak ktoś woli half duplex.

    Ja narazie na kablu mam jednego "slave", ale oczywiście selektywnie zresetowany slave i pozostałe milczące i powinno zadziałać OK.

    I jeszcze taki drobiazg - szybkość - ja używam 2400 8 n 1 - dla długich drutów oczywiście wolniejsza lepsza.

    :-) to tak moje kilka groszy w tym temacie.
  • #14
    mirekk36
    Level 42  
    SP3SWJ wrote:
    Witajcie

    Z bootloaderem na 485 to nie tak prosto... :-(

    No, no , nooo - ciekawe zdanie.

    SP3SWJ wrote:
    Trzeba oczywiście bootloadera przerobic by obsługiwał TX/RX

    No to teraz nie dziwię się powyższemu zdaniu.

    SP3SWJ wrote:
    - należy pamiętać że z tym RS mam SIMPLEX a nie DUPLEX.

    Chyba half-duplex a nie simplex ???? oj coś kolega miesza na maxa ;) Jeśli potrzebujesz obrazkowego wytłumaczenia co to simplex, half duplex i duplex to zajrzyj chociażby tutaj:

    Simplex:
    [ATMEGA[BASCOM]Bootloader <>RS 485

    half duplex:
    [ATMEGA[BASCOM]Bootloader <>RS 485

    duplex:
    [ATMEGA[BASCOM]Bootloader <>RS 485


    SP3SWJ wrote:
    Trzeba zastrzec z zwykłym protolole pewne znaki które są zarezerwowane wyłącznie dla bootloadera

    ?????

    SP3SWJ wrote:
    Wywołanie bootloadera można zrobić "wprost"

    Code:
    If Rs_char = 27  Then : Goto &H1C00        
    

     ' "ESC" jump to BOOTLOADER  1024 kb  from end of MEGA8 memeory


    Oczywiście skakanie tam za pomocą watchdoga też działa :-)

    Odwrotnie - TRZEBA zrobić za pomocą watchdoga, a "skakanie tam" jak piszesz za pomocą ulubionego GOTO może czasem działać a czasem nie - przemyśl już dalej sam dlaczego.

    SP3SWJ wrote:
    Zarówno część na PC i uC musi być trochę "przymulona" czyli nadawanie musi odbywać się z delikatnym opóźnieniem.

    No to już jest Hit ;) przepraszam że się uśmiecham ale tym "przymuleniem" to mnie kolega rozłożył na łopatki.

    SP3SWJ wrote:
    Od kilku dni walczę z tym tematem z użyciem na PC gotowego programu z MCS BASCOM.. ale nie obejdzie się chyba bez własnego bootloadera na PC.

    Zdecydowanie polecam napisać coś własnego na PC wtedy nie będzie takich opinii jak powyżej.

    SP3SWJ wrote:
    Przerobiony Bootloader (BAS) na uC pod moją płytkę w trybie RS232 działa bezbłędnie - ale z RS485 aż jeden raz udało mu się przejść...
    Robienie tego na zasadzie że raz się uda a raz nie, albo że jest ok gdy udaje się 8 na 10 razy to po prostu nieporozumienie.

    SP3SWJ wrote:
    Interfejs 485 na PC musimy mieć "bez echa" lub jak ktoś woli half duplex.
    Proszę spojrzeć na powyższe obrazki żeby na przyszłość wiedzieć już dokładnie co oznaczają terminy: simplex, half duplex i duplex. Bo to nie jest "jak kto woli". Echo to echo ;) a half duplex to half duplex.


    SP3SWJ wrote:
    I jeszcze taki drobiazg - szybkość - ja używam 2400 8 n 1 - dla długich drutów oczywiście wolniejsza lepsza.

    A co to znaczy dla kolegi "długich drutów" tak z ciekawośi pytam? - czy chodzi może o odległości typu kilka km ??? że taka niska prędkość - 2400 ???
  • #15
    SP3SWJ
    Level 18  
    mirekk36 wrote:
    ....Odwrotnie - TRZEBA zrobić za pomocą watchdoga, a "skakanie tam" jak piszesz za pomocą ulubionego GOTO może czasem działać a czasem nie - przemyśl już dalej sam dlaczego


    Jak juz uprawiasz edukację to rób to konsekwentnie ... czy masz na myśli że to jest zależne od użytego bootloadera... a watchdog zadziała zawsze OK bez względu na zastosowany inny niż pierwotnie loader...


    się napisałeś od samego rana :-) .... a już myślałem że ty takie śliczne rysunki robisz... http://www.cabledepot.com/05DTHFDUP.html :-) tak, simplex/ half duplex zamiana kierunków - ale fak jest jeden mamy tylko jedno medium trasmisyjne ( współdzielone) i jednoczesna transmisja = kolizje

    Zastrzeżone znaki... jeśli twoje CPU z jakiegoś powodu się zresetuje i bedzie czekało na bootloader to dobrze by nie trafiło na znak uruchamiający bootloader... i rozpoczęło normalną pracę.

    W kwestii "zamulenia" transmisji - jak będzie mi się chciało - to ci pokażę i wyjaśnię na konkretnych przebiegach czasowych używając narzędzia http://www.oscyloskop.eu/analizator-logiczny-...lus-lap16064-16mb-uart-inne-p-27.html?cPath=6

    cdn...
  • #16
    mirekk36
    Level 42  
    SP3SWJ wrote:

    Jak juz uprawiasz edukację to rób to konsekwentnie ... czy masz na myśli że to jest zależne od użytego bootloadera... a watchdog zadziała zawsze OK bez względu na zastosowany inny niż pierwotnie loader...


    Nie obruszaj się tak zaraz, a jeśli chodzi o watchdoga to tak - mam na myśli, że zawsze zadziała poprawnie niezależnie jakiego bootloadera i jaki aktualnie program pracuje to zadziała. Problem GOTO polega na tym, że możesz skoczyć do bootloadera a nie wyłączasz przerwań i wtedy mogą się dziać różne dziwolągi podczas pracy takiego bootloadera


    SP3SWJ wrote:

    .... a już myślałem że ty takie śliczne rysunki robisz... http://www.cabledepot.com/05DTHFDUP.html :-) tak, simplex/ half duplex zamiana kierunków - ale fak jest jeden mamy tylko jedno medium trasmisyjne ( współdzielone) i jednoczesna transmisja = kolizje

    Dlatego nazwya się to half duplex a nie simplex na co zwróciłem uwagę a rysunki oczywiście, że nie moje ale co to ma za znaczenie?


    SP3SWJ wrote:

    Zastrzeżone znaki... jeśli twoje CPU z jakiegoś powodu się zresetuje i bedzie czekało na bootloader to dobrze by nie trafiło na znak uruchamiający bootloader... i rozpoczęło normalną pracę.


    To wszystko zależy od implementacji sposobu mechanizmu bootloadera i koncepcji działania. Nie można tak uogólniać po prostu i to miałem na myśli.

    SP3SWJ wrote:

    W kwestii "zamulenia" transmisji - jak będzie mi się chciało - to ci pokażę i wyjaśnię na konkretnych przebiegach czasowych używając narzędzia http://www.oscyloskop.eu/analizator-logiczny-...lus-lap16064-16mb-uart-inne-p-27.html?cPath=6


    Panie kolego przebiegi na oscyloskopie nie świadczą o tym, że "coś tam samo się zamula" jak piszesz .... jeśli masz jakieś takie dziwne efekty to co najwyżej udowodnisz sam sobie, że albo:

    1. masz źle napisany bootloader w sekcji BLS procka
    2. masz źle napisany/działający program na PC do komunikacji z bootloaderem
    3. masz problemy w połączeniach

    nie ma wyjścia pośredniego. Jak soft jest poprawnie napisany to wszystko działa hmmm MUSI działać z założeniami. Jak nie działa czyli ci się "zamula" ;) to znaczy, że nie osiągnąłeś założeń albo one w ogóle były złe.
  • #17
    SP3SWJ
    Level 18  
    :-) tak zgadza się trzeci efekt uboczny GOTO - działające przerwania, faktycznie trzeba by zrobić najpierw disable interrupts. Jednak z trzech opcji wolę watchdoga jako najbardziej bezwzględną metodę :-)

    Ten miernik co linkowałem to nie oscyloskop... ale analizator RS232 z dekodowaniem transmisji i pomiarem czasów każdej zmiany stanu. Celowe "zamulanie" transmisji chodziło o to by dodać po każdym odebraniu malutkie opóźnienie w wysłaniu odpowiedzi. by druga strona miał szansę przestawić się z TX w RX. Jak mamy pełny duplex - wiadomo możesz nadawać zniezwłocznie. W half-dupleskie lepiej zacząć nadawać (odpowiadać) z czasem opóźnienia który gwarantuje że druga strona przejdzie w tryb RX.

    Tym analizatorem mogę podsłuchać wszystkie 6 sygnałów
    1-TX 1-RX 1-sterowanie trasiverem
    2-TX 2-RX 2-sterowanie trasiverem
    i stwierdzić (zmierzyć) jaki mamy margines pomiędzy pracą obydwu uC

    poniżej przykłądowy obrazek podsłuchiwania transmisji - ale niestety innego urządzenia - nie bootloadera

    [ATMEGA[BASCOM]Bootloader <>RS 485

    :-)
  • #18
    mirekk36
    Level 42  
    Tak znam ten analizator i uważam że jest bardzo fajny ;) więc wiem o czym pisałeś - ale to nie zmienia faktu, że nie trzeba robić jakiegoś opóźnienia ;) tym powinien się zajmować sprzęt tzn przerwania obsługujące RS485 i w tym przypadku robi to Bascom - czy do końca dobrze ? tego nie wiem - być może masz rację, że jednak coś robi nie do końca dobrze - w końcu masz miernik przed sobą...

    ... ale jeśli dobrze się napisze procedury komunikacji RS485 to nie trzeba żadnych dodatkowych opóźnień po wysłaniu dodawać ;) ... pomyśl sobie co by to było gdybyś miał na magistrali ze 30 modułów SLAVE ??? to dodając jeszcze jakieś bliżej nie określone opóźnienia o jakich piszesz to byłaby masakra jeśli chodzi o wydłużenie czasu cyklu odpytania wszystkich po kolei.

    Wiem coś o tym bo właśnie kończę projekt w którym pracować będzie w tej chwili 17 modułów Slave i transmisja jest dopracowana i zapięta już na ostatni guzik. Żadnej zwłoki nie muszę dodawać po wysłaniu czegokolwiek. U mnie wszystkim zajmują się zresztą przerwania - ja tylko spokojnie wrzucam sobie coś do bufora co mam wysłać i czochra mnie co się z tym dalej dzieje ;) .... bo wcześniej porządnie napisałem obsługę przerwań .... tyle że ja wszystko robiłem od podstaw sam w języku C

    .... a jeszcze odnośnie tego analizatorka, to kiedyś chciałem nawet sobie coś takiego zrobić bo w końcu schemat jest prosty (kilka szybkich pamięci RAM SPI) i wczytywanie równolegle wielu próbek - fajnie ... program też człowiek by sobie napisał na PC ... ale jednak czasu sporo by poszło ... więc też co jakiś czas myślę żeby kupić tego gotowca

    Dodano po 4 [minuty]:

    aaaa - tyle że ja myślałem o tym:

    http://www.ikalogic.com/scanalogic2/index.php

    ;)
  • #19
    SP3SWJ
    Level 18  
    mirekk36 wrote:

    aaaa - tyle że ja myślałem o tym:

    http://www.ikalogic.com/scanalogic2/index.php

    ;)


    IKA też - fajny - - najlepiej mieć obydwa :-) i ich przydatność przy testowaniu RS485 jest niepodważalna. ten co ja mam chodzi 5 razy szybciej i dekoduje więcej protokołów. W standardzie ma kilka popularnych - a kolejne można dokupowywać. Myślę że czasami nie warto sobie udowadniać że potrafimy wszystko zbudować - tylko skpupić się na zadaniu a niezbędne narzędzia kupić - taniej i szybciej.

    IKA ma "generator" i to bardzo duża zaleta !!!

    Jedną twoją poradę zapewne przetestuję (watchdogowy start bootloader) :-) u mnie pozostawały "duchy przerwań" i załączony bufor seriala :-)

    i jeszcze jedno - ten mój analyzer ma wyzwalanie nie tylko zboczem - ale także zdekodowaną daną z magistrali - to wyzwala zapia - a na dodatkowym wyjściu pojawia się sygnał który można użyć do wyzwolenia dodatkowego oscyloskopu.

    Jeżeli chcesz mieć jeszcze szybszą transmisję po 485 możesz to zrobić tak że uC zawsze słucha - także własnej transmisji (podobnie jak w CAN-BUS)... ale to już zagadnienie na odpowiedni wątek....

    Pozdrawiam Jarek
  • #20
    SP3SWJ
    Level 18  
    mirekk36 wrote:

    ... ale jeśli dobrze się napisze procedury komunikacji RS485 to nie trzeba żadnych dodatkowych opóźnień po wysłaniu dodawać ;)....
    ;)


    Postanowiłem zmierzyć tego "delaya".... i okazało się że w BASCOM odpowiedź SLAVE po RS485 wysyła zanim jeszcze MASTER zdejmie TX_ENABLE. Możę to i drobiazg - ale na zakładkę 60us są na magistrali dwa TX.

    Generalnie "stop" w transmisji ma około 360 uS i cała transmisja przechodzi, niemniej jednak zakładek TX nie powinno być.

    W twoim przypadku jeżeli napisałeś w C - a nie zmierzyłeś - to jesteś przekonany że działa tak jak byś chciał.... :-) ale dopóki nie masz pomiarów na ekranie.... pozosaje to w kwestii wiary :-)

    Muszę jeszcze oblukać tego bootloadera - ta na obrazkach zmierzona transmisja to zwyczajne gadanie Master-Slave.
    - Procek zaprogramowany w BASCOM
    - 2400 8 n 1
    - odbiór danych w przerwaniu (bez bufora)
    - obsługa RS485

    [ATMEGA[BASCOM]Bootloader <>RS 485 [ATMEGA[BASCOM]Bootloader <>RS 485
  • #21
    mirekk36
    Level 42  
    SP3SWJ --> no powiem ci , że mnianiuśnie, cukierkowo i coraz bardziej zachęcająco wyglądają te wyniki z tego analizatora, które tu pokazujesz ;) przez ciebie się skuszę w końcu na niego ;)

    A jeśli chodzi o to co napisałem w C to prawdziwym testem dla moich rozwiązań (bez takiej analizy) było napisanie na PC oprogramowania, które pełni rolę Mastera w RS485 i bez litości wysyłanie setek, tysięcy ramke zapytań i odpowiedzi do układów Slave na magistrali.

    Dodam, że od strony PC pracuje przejściówka USB/RS485, którą zrobiłem w oparciu o mój ulubiony scalaczek FT232RL natomiast oprogramowanie na PC do komunikacji nie wykorzystuje ŻADNYCH opóźnień po odebraniu ramki od Slave. Praktycznie OD RAZU po otrzymaniu odpowiedzi wysyła Master kolejne zapytanie w magistralę - założeniem było żeby do MAXIMUM zminimalizować czas odpytywania wielu urządzeń jak najszybciej.

    TimeOuty programowe pojawiają się dopiero, gdy jakieś urządzenie Slave wypadnie z magistrali np się uszkodzi, wtedy master musi poczekać i powtórzyć ew kilka razy zapytanie.

    Fakt musiałem nad tym wszystkim troszkę posiedzieć żeby zgarać. Ale mam okienka i liczniki serwisowe w programie, które pokazują mi : przesyłane ramki, kolizje w postaci ilości błędów CRC, timeoutów itd

    ..... po dopieszczeniu, sieć pracuje wiele wiele godzin bez ani jednego błędu czy timeouta ;)

    Na koniec jeszcze pytanko - czy np to co tera pokazałeś ta fajna analiza RS485 - to też jakiś kolejny dokupiony moduł do tego analizatora ? Drogie są takie dodatki ? co trzeba hmmm warto kupić na początek i ile kosztuje taka podstawa ? ;)
  • #22
    SP3SWJ
    Level 18  
    ten co mam to koło 800 pln i zobacz na linku wcześńiej - cztery podsatwowe UARS SPI I2C .... są w standardzie... doczytaj na linku
  • #23
    mirekk36
    Level 42  
    SP3SWJ wrote:
    ten co mam to koło 800 pln i zobacz na linku wcześńiej - cztery podsatwowe UARS SPI I2C .... są w standardzie... doczytaj na linku


    Tak tak, czytałem właśnie w tym linku ale tak tylko pobieżnie - sorki - jednak jakby na pierwszy rzut oka nie mogłem się tam dopatrzeć szybko różnic pomiędzy taką wersją za powiedzmy ok 800zł a tą za 6500zł ;) .... ładna rozpiętość.
  • #24
    SP3SWJ
    Level 18  
    aaa i zapomniałem napisać że trzy dodatkowe "dobierasz":-) w cenie... a cztery dekodery protokołów są na start. Cena.... ten mój ma 64kb ale jak pamiiętam sa i z pamięcią 2Mb i 32 wejściowe... a mój ma tylko 16 wejść :-( .... także można sobie wybrać stosownie do potrzeb.

    Ja chyba sobie wybiorę Profibusa... i myślę co jeszcze wybrać....


    Testowałem analyzerem bootloadery na PC te które są z MCS - one nadają dane w ciemno - nie patrząc czy coś leci do nich -niestety są napisane na pełny duplex :-(

    Twojego bootloadera jeszcze nie testowałem, czy możesz podać jakiś link do swojego dzieła.
  • #25
    mirekk36
    Level 42  
    SP3SWJ wrote:

    Twojego bootloadera jeszcze nie testowałem, czy możesz podać jakiś link do swojego dzieła.


    Moja wersja bootloadera czeka najpierw na znaki zapytania z uC, potem dopiero można rozpocząć dogadywanie się. A następuje też potwierdzanie w obydwie strony wysyłanych paczek danych. Pobrać można z mojej stronki ;) Link

    Aż ciekawy jestem jak to będzie wyglądało w tym analizatorze o którym piszesz ;)

    A co do ilości wejść i pamięć to rzeczywiście chyba do takich podstawowych potrzeb jest wystarczająca.
  • Helpful post
    #26
    SP3SWJ
    Level 18  
    Znalazłem w sieci wersje "transceivera" na RS485 z "auto TX" - ale jeszcze nie testowałem.

    Może rozwiązać problem dla urządzeń w których nie mamy jak zrealizować sterowania transmisja TX/RX

    Rozwiązanie trochę brutalne ale podobno działa OK. Opisywanie było na forum MCS.

    [ATMEGA[BASCOM]Bootloader <>RS 485
  • #28
    SP3SWJ
    Level 18  
    mirekk36 wrote:
    SP3SWJ --> oj coś tu jest na maxa pokręcone chyba - toż pin DI jest na stałe podpięty do GND.


    I NA TYM POLEGA PRZEKRĘT :)

    caps.... albo RX .... albo TX :-) hihihi
  • #29
    mirekk36
    Level 42  
    no ale co ten przekręt ma na celu bo nie rozumiem ? toż za jego pomocą chyba nie da rady nic nadawać ???? tylko chyba odbierać i ew przełączać kierunek transcieverka .... chociaż i tak w hmmm troszkę nieszczęśliwy sposób to przełączanie będzie robione i czy wyjdzie w ogóle. Przecież gdy na Tx poleci ramka z różnymi wartościami bitów to nadajnik będzie się załączał na nadawanie i odbieranie w zależności od stanu poszczególnych bitów w ramce - coś mi tu się nie podoba ;) .... albo czegoś nie widzę ;)
  • #30
    SP3SWJ
    Level 18  
    :-) pisałem :-) nie testowałem jeszcze .. podobno działa...znalezione w necie na forum MCS BASCOM
    .