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.

Programator optoizolacyjny inne RS232 UART AVR soft linux

trol.six 11 Sep 2020 21:47 3516 11
  • Programator optoizolacyjny inne RS232 UART AVR soft linux

    W temacie prezentuje:
    1. Programator optoizolacyjny albo jak kto woli przejściówka do programowania ;)
    2. Program na linuxa do programowania avr przez ISP
    3. Inne schematy i konfiguracje działające z tym programem.

    Może zaczne od wad :) Wszystko co tutaj prezentuje to względnie proste sposoby realizacji programowania mikrokontrolerów AVR z wykorzystaniem ISP, przez takie interfejsy jak RS232 lub UART (np. przejściówka USB RS232 UART).

    1. Wyjścia są albo kolektorowe z podciąganiem, albo na sztywno, albo z diodą
    2. Ze względu na działanie bit-bang prędkości nie oszałamiają :)

    Niemniej jednak dające się używać w wielu przypadkach i jako dodatkowy sprzęt dla mnie przydatny.

    ----------------------------------------------------------------------------------------------------------------

    Programator optoizolacyjny inne RS232 UART AVR soft linux Programator optoizolacyjny inne RS232 UART AVR soft linux Programator optoizolacyjny inne RS232 UART AVR soft linux

    Jak widać nic nadzwyczajnego, transoptory CNY17-3, D1 D2 D3 diody zabezpieczające przed ujemnym napięciem, zastosowałem LEDy. Diody LED D4 i D5 (czerwona, żółta lub zielona) nie są konieczne, jednak oprócz tego że sygnalizują sygnał, poprawiają troszkę szybkość, R15 R16 R17 zabezpieczają tranzystory przed nadmiernym prądem. Przejściówka wymaga do odczytania stanu z CTS stanu wysokiego na RTS co realizuje program.

    Szybkość przejściówki można byłoby poprawić stosując mniejsze rezystory, ale nie chciałem obciążać już wyjść oraz zwiększać możliwego wydzielania większej mocy na rezystorach.

    Programator podczas nie działania stale ma reset zwarty do masy, co powoduje że mikrokontroler jest w stanie resetu i trzeba odłączyć programator. Można zamienić sygnał CLK z RST i wtedy nie będzie w stanie resetu w zamian za zwarty pin SCK. W programie zamiast RSOPT1 należy podać RSOPT2.

    Przejściówka przenosi prostokąt 50% 50kHz, ale już z innym wypełnieniem.

    Jak pisałem, z racji że są to wyjścia z podciąganiem rezystorowym nie da się zaprogramować np arduino bez przeróbek, ponieważ tam na pinie SCK jest dioda LED z rezystorem <1kom wpięta do masy. Można więc tutaj dać bufory bramkowe, albo przerobić układ z tranzystorami pnp-npn. Prawdopodobnie przejściówka USB-UART gdzie wyjścia mają większa obciążalność byłaby skuteczniejsza.

    --------------------------------------------------------

    Program arudet, taką sobie nazwe wymyśliłem, czyta opcje podobnie jak avrdude, może też czytać konfig z avrdude, opcje:

    -p typ mikrokontrolera (np: m8)
    -U pamięć:akcja:plik:format
    Program czyta pliki formatu hex oraz binarnym
    np: lfuse:r:lfuse.bin:b
    -c typ programatora, przejściówki:
    UART1, UART2, UART3, UART4, RSOPT1, RSOPT2, TRSPR1
    -P ścieżka do portu
    -b szybkość portu RS
    -i czas stanu bitu w mikrosekundach
    -e kasuj chip
    -F ignoruj sygnaturę
    -D nie kasuje flash przed zapisem (domyślnie kasuje)
    -h wyświetl pomoc
    -C plik z konfiguracją, program w pamięci ma tylko kilka uk reszte czyta z konfigu avrdude z /etc/avrdude.conf, można podać inną lokalizacje
    -x podwaja prędkość - widać to dla konfiguracji gdzie TxD steruje CLK (RS232), w zasadzie nie ma przyspieszenia dla przejściówek USB->UART

    Przykładowe polecenia na RS232:

    Quote:
    arudet -p m8 -U lfuse:r:lf.bin:b -P /dev/ttyUSB0 -b 9600 -c UART1
    arudet -p t13 -U flash:w:lf.bin:b -P /dev/ttyS0 -b 19200 -c RSOPT2 -x
    arudet -p t15 -U flash:w:lf.bin:b -P /dev/ttyS0 -b 19200 -i 10 -c RSOPT1

    Program wyświetla co robi plus dla flash i eeprom przewidywany czas do zakończenia.

    Program nie obsługuje masek bitowych dla fusebitów. Czyli zapisuje to co ma.
    Nie zapisuje pamięci flash mikrokontrolerów >128kb. I nie weryfikuje fusebitów, ani ich poprawności dla rodzaju.

    W przypadku komunikatu podobnego do:
    bad: 0xXX
    oznacza to błędy w komunikacji i możliwość błędu.

    --------------------------------------------------------

    Uzyskałem takie czasy odczytu ATtiny15 1 KByte flash









    RSOPT16.4s (txd -> rst)
    RSOPT211.3s -x (txd -> clk)
    RSOPT216.0s
    UART19m 28.0s (txd -> rst)
    UART23m 25.7s (txd -> clk)
    TRSPR17.5s - x
    TRSPR110.8s


    RSOPTx - prezentowany w tym wątku
    UARTx - usb->uart FTDI FT232RL
    TRSPRx - inna

    polecenia do testu (szybkości graniczne):
    Spoiler:
    ./arudet -p t15 -U flash:r:fl.bin:b -P /dev/ttyS0 -b 19200 -i 5 -c RSOPT1
    ./arudet -p t15 -U flash:r:fl.bin:b -P /dev/ttyS0 -b 115200 -i 5 -c RSOPT2
    ./arudet -p t15 -U flash:r:fl.bin:b -P /dev/ttyS0 -b 115200 -c TRSPR1
    ./arudet -p t15 -U flash:r:fl.bin:b -P /dev/ttyUSB0 -b 57600 -c UART1
    ./arudet -p t15 -U flash:r:fl.bin:b -P /dev/ttyUSB0 -b 57600 -c UART2 -x


    przykładowy zrzut
    Spoiler:
    Code:

    --------------------------------------
    mem type         : lfuse
    what do          : r
    filename         : fl.bin
    format           : b
    chip             : t15
    hardwn           : UART1
    port             : /dev/ttyS0
    delay            : 0 us
    baudrate         : 57600 kHz
    --------------------------------------
    find avrdudeconf : t15
    decsription      : ATtiny15
    signature        : 1e 90 06
    eeprom siz       : 64
    eeprom block     : 64
    flash siz        : 1024
    mode             : 0x04
    flash block      : 128
    eepagenmb        : 0
    fpagenmb         : 0
    --------------------------------------
    delay            : 190 us clk: 2631 Hz
    YES enter in program operation
    file fl.bin exist overwrite
    signature : 1e 90 06
    read flash memory
    adr bytes: data  estimated time remain
    adr 000000: ffffffffffffffff   0 min  6 s
    adr 000008: ffffffffffffffff   0 min  7 s
    adr 000010: ffffffffffffffff   0 min  6 s
    adr 000018: ffffffffffffffff   0 min  6 s
    ...



    Inne schematy podłączeń
    Programator optoizolacyjny inne RS232 UART AVR soft linux Programator optoizolacyjny inne RS232 UART AVR soft linux

    --------------------------------------------------------

    Jak pisałem prezentuje tutaj proste konstrukcje, jeśli ktoś jest zainteresowany mogę zaprezentować bardziej skomplikowane tego typu rzeczy. Mające inne wady ;)

    --------------------------------------------------------

    Program będzie także dostępny: https://gitlab.com/trolsix/arudet/

    W załącznikach schematy, program: źródła plus binarki dla 32-bit dla liuxa.
    Program wersja 0.0.9 , tak oględnie testowałem, ale będe jeszcze mu się przyglądał.
    Proponuje się nie rzucać jeśli ktoś boi się zablokować fusebity ;)

    PCB nie wrzucam bo za dużo błędów.
    .

    Cool! Ranking DIY
    Can you write similar article? Send message to me and you will get SD card 64GB.
    About Author
    trol.six
    Level 31  
    Offline 
  • #2
    kaczodp
    Level 14  
    D4 i D5 nie mają rezystorów ograniczających prąd.
    Dioda w U4 bez bufora.

    trol.six wrote:
    Przejściówka przenosi prostokąt 50% 50kHz, ale już z innym wypełnieniem.

    CNY17 są wolne. Do 20kHz jakoś to działa ale z MIDI (38kHz) już nie. Wątpię w poprawną pracę na 50kHz zwłaszcza przy niskim napięciu. R12 ma dużą wartość i przy 3,3V (AVR może pracować już od 2 a nawet mniej) to pewnie 5kHz będzie problemem.

    Programator będzie bardzo wolny, przy programowaniu kilkudziesięciu kB trzeba być cierpliwym. Są sprawdzone i szybkie rozwiązania na ADUM14.
  • #3
    trol.six
    Level 31  
    kaczodp wrote:
    D4 i D5 nie mają rezystorów ograniczających prąd.

    Bo tu nie ma być rezystorów.

    kaczodp wrote:
    R12 ma dużą wartość i przy 3,3V

    W sumie racja. Ze względu na niższe napięcia powinien być mniejszy. Bo jest już na pograniczu.

    Wolne czy szybkie to są pojęcia relatywne. To nie jest przejściówka uniwersalna tylko o specyficznym zastosowaniu. W innych może się nie sprawdzić.

    Główne założenie: ma być względnie prosto. Większa szybkość w tym przypadku jest niekonieczna i mi nie potrzebna. Jak będe czegoś szybszego potrzebował to też zrobie to lepiej.

    A jesli ktoś ma większe wymagania zrobi to sobie inaczej. Chętnie obejrze jakiś inny projekt na elektrodzie nadający się do programowania.
    .
  • #4
    kaczodp
    Level 14  
    trol.six wrote:
    kaczodp wrote:
    D4 i D5 nie mają rezystorów ograniczających prąd.

    Bo tu nie ma być rezystorów.

    Układ nie uszkadza sie bo decyduje wiele czynników jak wydajnośc zasilania, porzeciążenie LED, przeciążenie transoptora albo niepełne otwarcie fototranzystora przez RS232C spowodowany napięciami +/-5V albo +/-9 pochodzącymi z przetwornicy pojemnościowej, której wydajność niekoniecznie jest zgodna z norma +.-20mA. Z pewnością w innych warunkach +/-12V z zasilacza komputerowego itd coś się uszkodzi prędzej czy później.
  • #5
    trol.six
    Level 31  
    kaczodp wrote:
    +/-12V z zasilacza komputerowego itd coś się uszkodzi prędzej czy później.

    Myśle że nie. Transoptor musiałby mieć CTR ponad 400%. Jeśli komuś wpadnie taki transoptor w ręce, wystarczy dobrać większe rezystory na jego wejściu. Z noty katalogowej CNY17-3 typowo CTR 100-250 i to dla troche wyższego prądu diody.
    .
  • #6
    trol.six
    Level 31  
    Wersja 0.1.3

    Nie zauważyłem ale dla avrdude binary (raw binary) to jest 'r' ;) zmieniłem bo miało być w miare kompatybilnie.

    Dodałem opcje 'm' dla formatu danych i można podać fusebity z linii, opcja -U , np:
    Quote:
    arudet -p m8 -U lfuse:w:0xf4:m -i 40


    Dodałem troche obsługi błędów linni poleceń.

    Zmieniłem troche zachowanie tzn:
    odczyt:
    - w przypadku flash zapisywane do pliku hex są tylko linie (16b) inne niż 0xFF
    - w przypadku eeprom zapisywane do pliku jest wszystko
    weryfikacja:
    - weryfikuje się tylko to co jest w plikach

    Dodalem osobną funkcje do UART, jest troszkę szybciej :D ;)




    UART19m 3.6s (txd -> rst)
    UART23m 1.0s (txd -> clk)


    I poprawiłem tam jakieś błędy.
    .
  • #7
    kaczodp
    Level 14  
    trol.six wrote:
    w przypadku flash zapisywane do pliku hex są tylko linie (16b) inne niż 0xFF

    Takie nieciągłe pliki nie są czytane poprawnie przez niektóre programy.
  • #8
    trol.six
    Level 31  
    kaczodp wrote:

    Takie nieciągłe pliki nie są czytane poprawnie przez niektóre programy.

    A które to te programy? Ktoś sobie życzy moge dodać opcje zapisywania całości. Jeśli się nie mylę to asembler avrasm daje pliki nieciągłe, jeśli chodzi o avr-gcc to pewny nie jestem, ale chyba też.

    To nie jest taki trywialny problem. Weź pod uwagę że zweryfikowanie np bootloadera który jest pod koniec pamięci może być kłopotliwe, jeśli mamy jakiś program. Zwykle weryfikacja przebiega do pierwszego złego bajtu.
    .
  • #9
    kaczodp
    Level 14  
    trol.six wrote:
    A które to te programy?

    Jak pamiętam to rawie wszystkie, np hexelon. Ni wiem jak to teraz wygląda bo poważne kompilatory używają są s-recordów.
  • #10
    trol.six
    Level 31  
    Czyli nie ma się czym przejmować. Jak widzisz problem jest czysto hipotetyczny.
    Nie po to jest format hex aby zapisywać go w ciągłości. Od tego jest plik bin. Pierwsze słysze o programach z problemami tego typu. Wszystkie (kilka) jakie używałem nie mają tego problemu.

    A ten format S-record to też nie ma wymagań co do ciągłości?
  • #11
    kaczodp
    Level 14  
    trol.six wrote:
    A ten format S-record to też nie ma wymagań co do ciągłości?

    Czy intelhex czy s-recort problemem są programy a nie format pliku. Spotykałem takie, gdzie rekord intelhex mógł mieć max 16 bajtów a kompilator generował 32 (intelhex dopuszcza 255). Trzeba było dodatkowo konwertować.
    Różnica intelhex a s-record wynika głównie z tego, że intel powstał do plików max 64kb i później robiono łaty aby było więcej a s-record od początku obsługiwał 64kb+.
  • #12
    trol.six
    Level 31  
    Wersja 0.1.5

    Kolejna wersja w miare szybko, bo niektóre funkcjonalności działały w całkiem zaskakujący sposób ;)

    Dodałem też obsługe AVR dla flash >128k. Niestety nie mam takiej atmegi na stanie więc nie sprawdze w praktyce.

    Dodałem podsumowanie z czasem.

    W załączniku i na gitlabie binarna wersja dla 32 i 64 bit systemu linux.

    Gdyby ktoś chciał się tym bawić, to proponuje nie dawać zbyt małego czasu.
    Ponieważ rośnie możliwość błędu, a czas wcale nie maleje proporcjonalnie.

    Dla różnych opcji -i , czas odczytu 1k bajta




    -i510204080160320
    s67810142238


    kaczodp wrote:
    Różnica intelhex a s-record wynika głównie z tego, że intel powstał do plików max 64kb


    No więc zmieniłem troszke sposób zapisu, na bardziej kompatybilny w zakresie do 64kb.
    .