Elektroda.pl
Elektroda.pl
X

Search our partners

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

Programator VHH -- tropic -- mikrokontrolery pic i inne

trol.six 22 May 2021 23:39 1689 2
  • Programator VHH -- tropic -- mikrokontrolery pic i inne

    Programator tropic, jak sama nazwa wskazuje, to programator zrobiony z myślą o picach, którego autorem jest jakiś trol, w tym przypadku, trol.six. ;)

    - obsługa przez polecenia, tzn nie potrzeba dedykowanego oprogramowania
    - uniwersalny protokół UART, obsługuje XON-XOFF na razie jednostronnie
    - czyta oraz wysyła w formacie hex

    Wersja którą prezentuje, można określić numerkami: 0.2.1 dla oprogramowania, 0.4 dla schematu

    Na chwile obecną umożliwia programowanie kilku modeli z napięciem "high voltage", jednak wyprowadzenie jest bardziej wielopinowe. Ponieważ w planach może dorzuce inne. Jak można zobaczyć do kodu są już funkcje odczytujące co nie co, m.in. attiny13 w trybie "high voltage". z tym, że raczej w planach będzie on robił za fuse doctora w tym trybie, czyli przywracał domyślne fusebity.

    Sam programator nie ma zasilacza, wymaga zasilania albo z układu albo z innego źródła, jednak napięcie VHH tworzy sobie sam z przetwornicy step-up sterowanej z mikrokontrolera. Zasilanie 3V3-5V. Tutaj trzeba uważać ponieważ do niektórych operacji wymagane jest napięcie minimum 4V5 dla piców. Programator w tej wersji nie sprawdza tego.

    Z początku myślałem o zworce zależnej od tego czy napięcie podajemy czy pobieramy z płytki programowanego mikrokontrolera, ale zrezygnowałem z tego i dałem dam diode schotkiego D3. W przyszłej wersji programator sam zmierzy to napięcie.

    Wersja z atmega8 ma 240 bajtowy bufor, natomiast na atmega328 1024.

    Na płytce są jeszcze tranzystorki które obciążają linie VCC oraz VHH. Dałem je ze względu na fakt że podanie czasem VCC po VHH powinno być z opóźnieniem. A mając rezystor na lini reset nie jest to możliwe. Na chwile obecną nie używane.

    Lista układów:
    18f24q10, 18f25q10, 18f26q10, 18f27q10, 18f45q10, 18f46q10, 18f47q10,
    18f1220, 18f2220, 18f4220, 12f629, 12f675

    Lista poleceń:
    CHIP name, CHIP_LIST, CONT, END, ERASE,HELP, READ,
    SYGN, SYGN_OFF, SYGN_ON, WRITE, VCC_ON, VER

    Złącze:

    Programator VHH -- tropic -- mikrokontrolery pic i inne Programator VHH -- tropic -- mikrokontrolery pic i inne

    Kabelek ma zamienione VCC z CLK dla ograniczenia zakłóceń, bez tego może nie działać.
    Kolejność wyprowadzeń jest taka ponieważ łatwiej PCB zaprojektować.

    Programator na razie przetestowałem wstępnie na trzech mikrokontrolerach. Nie wiem na ile nie zawiera jeszcze błędów.

    Prezentuje już projekt, i wrzucam te wersje ponieważ mieści się ona jeszcze do mikrokontrolera atmega8. Mieści się też dzięki kompilatorowi avr-gcc w wersji 10.2.0

    Jednak to co wypada zrobić w pierwszej kolejności:
    - program sprawdza zakresy pamięci, jednak w razie przekroczenia nie informuje.
    - nie ma weryfikacji poprawności podczas zapisu ani jako osobna funkcja.
    - nie ma sprawdzania czy układ jest skasowany
    - nie ma weryfikowania napięć podczas działania, jedynie przed użyciem

    Z weryfikowaniem jest tyle niuans, że weryfikacja po zapisie gdy bity blokady odczytu są zaprogramowane jest niemożliwa.

    Całość jest ogólnie przetestowana, ale w praktyce jeszcze nie wiem na ile dobrze to jest.

    Czas odczytu ( bez dodatkowych 400ms ):
    18f25q10 : 7.96 sec
    18f1220 : 1.16 sec
    12f675 : 2.27 sec

    Solidnych czasów programowania nie mam, ale 12f675 ok 10 sek, 18f1220 ok 4 sek. (dla UART 115k2)

    Inne zdjęcia:

    Programator VHH -- tropic -- mikrokontrolery pic i inne Programator VHH -- tropic -- mikrokontrolery pic i inne

    I tyle ogólnie. Co nie co też jest w dokumentacji. Macie jakieś uwagi, pytania, to piszcie. Tutaj porusze tylko trzy kwestie.

    --------

    1. Programowanie odbywa się przez wybór typu układu, wydanie polecenia WRITE oraz przesłania pliku hex. Tak się jednak składa że szybkość wysyłania (115kbs) jest często szybsza niż programowania. Stąd obsługa protokołu xon-xoff. Co jeśli nasz sprzęt wysyłający tego nie potrafi? Jest kilka opcji, skorzystać z wolniejszej transmisji, ale to spowolni programowanie "szybszych". Zwiększyć bufor wejściowy. Wysyłać plik partiami, co jednak troche komplikuje rzecz. Dodałem więc polecenie CONT. Po prostu wysyłamy znowu plik, aż do skutku. Co demonstruje na poniższym zrzucie z dwóch terminali.

    Programator VHH -- tropic -- mikrokontrolery pic i inne

    Na chwile obecną po odczytaniu zawartości mikrokontrolera, przesyłany jest znak EOT. Ale zastanawiam się czy nie dać go do każdego polecenia.
    Ponieważ poza odczytem terminal wisi sobie ciągle czekając na odczyt.

    --------

    2. Weźmy sobie taki rysunek z dokumentacji:

    Programator VHH -- tropic -- mikrokontrolery pic i inne

    Jak widać rezystor na resecie ma 1kom a kondensator do masy 100nF. Całkiem optymistyczne można rzecz. Niestety tak małe rezystancje oraz duże pojemności w tym miejscu rodzą całkiem sporą ilość problemów podczas programowania.

    Po pierwsze czytając specyfikację programowania, czas przejścia od stanu zero do stanu napięcia programowania ma być mniejszy niż 1us. Łatwo policzyć że prąd potrzebny do naładowania takiej pojemności w tym czasie od 0 do 10V to 1A. Jak na mój gust całkiem sporo, szczególnie że musimy to przetransportować kabelkiem który na pewno ma jakąś indukcyjność. Grozi to niestabilnościami i przekroczeniem dopuszczalnego napięcia VHH.

    Druga rzecz to rezystor 1kom, co oznacza że podczas kiedy podaliśmy napięcie 10V na VHH prąd płynący do napięcia VCC, zasilający mikrokontroler to 10mA. Co jest za dużo. Oczywiście prąd ten spadnie do 5mA przy napięciu 5V na VCC, ale wciąż za dużo. Rozwiązania są dwa, jedno gdy napięcie programowanego układu jest podłączone do programatora, wraca przez diode schotkyego. Jeśli z jakiegoś powodu nie korzystamy z takiego podłączenia (osobne VCC), to bez diody zenera układ programowany może zostać uszkodzony.

    Przetwornicę która z niskiego napięcia robi wysokie, typowo można obciążyć 5 mA. O tym decyduje dławik oraz prąd ograniczony przez tranzystor. A większy pobór prądu podczas włączenia zapewnia kondensator 47uF.

    --------

    3. Układ ma włączony watch-dog działający najszybciej w atmegach, czyli ok 17ms. Jednak jest to troche za wolno. Jest to istotne ze względu że gdyby atmega się zwiesiła w niekorzystnej sytuacji, tzn podczas kiedy narasta napięcie na VHH, to mogłoby dojść do uszkodzenia niektórych programowanych mikrokontrolerów z powodu za wysokiego napięcia. Wprawdzie atmegi jeśli już, raczej się resetują podczas zakłócenia, ale różnie może się zdarzyć. Dlatego pojemność na wyjściu przetwornicy to minimum 47uF. Co w pewnym tylko stopniu zabezpiecza przed taką ewentualnością. Można ją zwiększyć.

    --------

    Źródła i inne na będą na gitlabie: https://gitlab.com/trolsix/tropic

    --------

    W załączniku na forum (do wyboru zip lub gzip), są trzy wersje hex dla atmega8, i atmega328. Różnią się prędkością UART.
    Plus troche dokumentacji, oraz schemat, pcb z powodu błędów nie zamieszczam.
    Fusebity mają być ustawione na kwarc 11059200, można sobie włączyć watch-doga plus brown-out na 2V7

    --------

    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 
  • Farnell IoTFarnell IoT
  • #2
    viayner
    Level 41  
    Na Githubie jest odwołanie do Readme.MD i tyle.

    Nie widzę sensu czy wyższości tego rozwiązania, na razie nie obsługuje nawet weryfikacji, obsługuje wybrane kilka chipów; nie wiadomo, jak rozwiązane będzie dodawanie nowych chipów. Plus za protokół komunikacyjny nie wymagający specjalistycznego oprogramowania.

    Jaka jest wyższość tego układu w stosunku np. do PICkita? Wymaga oprogramowania, ale darmowego, a jeżeli zapewnia stabilność i obsługę wszystkich chipów Microchipa, to masz twardy orzech do zgryzienia.

    Wspominasz że: "Z weryfikowaniem jest taki niuans, że weryfikacja po zapisie, gdy bity blokady odczytu są zaprogramowane, jest niemożliwa." Czyli nie weryfikujemy, co zapisaliśmy, jak wiemy, że "wgrało się to, co chcemy, i dobrze". Chyba nie do końca się orientujesz jak to należy zrobić. PICkit weryfikuje wgrany kod, nawet gdy układ jest zabezpieczony.
  • #3
    kamyczek
    Level 37  
    Plusik za chęci , ale już dziś ci powiem że projekt jest nierozwojowy . Żeby miał sens musiał by obsługiwać dużo i być relatywnie tani , ten jest tani , ale nie obsługuje większości układów . więcej byś zdziałał robiąc programator uniwersalny do eepromów szeregowych . Choć tam też jest pony prog do zrobienia za kilka pln .