Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)

Mraycek 19 Cze 2015 10:33 2097 30
  • #1 19 Cze 2015 10:33
    Mraycek
    Poziom 9  

    Witam, po długiej i ciężkiej pracy udało mi się zbudować układ.
    Docelowo ma to być sterownik, który będzie odpowiednio reagował na komendy podawane przez rs232 z komputera, również odsyłał znaki i sterował portami wyjścia/wejścia.

    Proszę o sprawdzenie programu i schematu, sterownik musi działać stabilnie i nie chciałbym czegoś pominąć. (w tym momencie nie mam wszystkiego, wiec nie rysowałem wyjść i wejść, ale na każde wyjście dam tranzystor + mosfet + przekaźnik albo sam tranzystor + mosfet i oczywiście optoizolację (dopiero idzie pocztą) a na wejścia dam przetworniki 24/5V i też będę coś kombinował z optoizolacją.
    W tym momencie odpowiednio reaguje na komendy przysyłane z komputera (w postaci #????@<LF>, na miejscu ? przysyłane są znaki które interpretuje uC).

    Komunikuję się przez scalak MAX232, baud 9600, 8 bitów danych, 1 bit stopu.

    Wejścia i wyjścia obsługiwane przez mikrokontroler będą optoizolowane, wiec raczej nie powinienem mieć dużych zakłuceń (czujniki omrona 24V na wejściach i przekaźniki na wyjściach).

    Program w C
    main.c

    Kod: c
    Zaloguj się, aby zobaczyć kod


    rs232.c
    Kod: c
    Zaloguj się, aby zobaczyć kod


    rs232.h
    Kod: c
    Zaloguj się, aby zobaczyć kod


    A tutaj schemat układu:
    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)

    Z góry dziękuję za pomoc :)

    Moderowany przez dondu:

    W przyszłości nie dodawaj spoilerów - SYNTAX wystarczy. Poprawiłem

    0 29
  • #2 19 Cze 2015 11:16
    jaca_76
    Poziom 12  

    Dlaczego w led_init wszystko jest za komentowane ?

    0
  • #3 19 Cze 2015 11:22
    Mraycek
    Poziom 9  

    jaca_76, miałem JTAGa włączonego, dlatego porty C źle reagowały, edytowałem pierwszy post, żeby nie robić zamieszania :)

    0
  • #4 19 Cze 2015 12:59
    BlueDraco
    Specjalista - Mikrokontrolery

    Brak odbioru znaków z UART i brak deklaracji zmiennych - program się nie skompiluje.

    0
  • #5 19 Cze 2015 13:07
    Mraycek
    Poziom 9  

    Odbiór znaków z UART

    Kod: c
    Zaloguj się, aby zobaczyć kod



    deklaracje zmiennych
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Program się kompiluje i działa (na razie bez zarzutu), chodzi o to, czy jest zrobiony dobrze, stabilnie i na ile mogę wykluczyć błędy.
    dołączyłyem jeszcze pliki rs232.c oraz rs232.h :)

    0
  • #6 21 Cze 2015 18:23
    Mraycek
    Poziom 9  

    Nikt mnie nie wesprze? :P

    Projekt jest już docelowo wykonany, natomiast czasami (dosyć często) występują problemy z komunikacją przez rs232

    Procesor po resecie ma wysłać znaki do pcta, że jest gotowy, dokładniej "uC_gotowy".
    Czasami znaki przychodzą w takiej samej formie, czasami widnieją inne napisy, tak wygląda kilkukrotne resetowanie celem sprawdzenia (nowa linia oznacza reset procesora)

    r[00]ţ
    uC_gotowy
    ň˙u
    ˙uC_gotowy
    \[00]*ŞŞ
    \[00][08]TŞ

    Wszystkie wejścia i wyjścia odpięte, żeby wykluczyć zakłócenia, testowałem na innym układzie max232, inny kabel, inne oprogramowanie na komputerze i inny komputer, wszędzie problem podobny.

    Jeśli ma jakiś pomysł, to będę bardzo wdzięczny :)

    0
  • #7 22 Cze 2015 23:00
    Intre
    Poziom 10  

    Napisałeś że korzystasz z A32 i taktowania 16Mhz - ja bym na początek dał inny kwarc np. 18.4320M


    Otwórz notę procesora od str. 165 masz podane prędkości http://www.atmel.com/images/doc2503.pdf takie z wartościami po przecinku można powiedzieć że są UART`o lubne ;)

    dalej poleciłbym Ci zrobić sobie przejściówkę na USB opartą o układ FT232 np. wg tego schematu

    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)

    Też chciałem zapytać jak u Ciebie wygląda filtracja zasilania procesora bo to również ważny aspekt i czasami może też powodować nie właściwe działanie podczas komunikacji

    Tu masz na dwóch tych blogach dobrze to omówione:

    http://mikrokontrolery.blogspot.com/2011/04/zasilanie-mikrokontrolera.html

    http://mirekk36.blogspot.com/2012/12/filtrowanie-zasilania-dlaczego-tak-wazne.html

    Znajdziesz na nich też informacje dodatkowe o komunikacji UART, a na tym drugim masz jeszcze filmiki wspomagające zrozumienie tematu.

    0
  • #8 24 Cze 2015 11:04
    Mraycek
    Poziom 9  

    Z tym kwarcem może być różnie, nota mówi, że moje 16Mhz i baud 9600 da margines błędu 0,2%, co przy dopuszczalnym 2% daje dobry wynik.

    Kompletny schemat jest na załączonym w pierwszym poście obrazku, układ zasilam z zasilacza transformatorowego 5V, 1A.
    Kiedyś robiłem interfejs rs232 tak na szybko takim samym schematem i działało, a byłem myślowo na etapie "schodów do piekła" i żadnej filtracji zasilania nie było (o ile w ogóle podłączenie było do końca poprawne), ale działało to dosyć stabilnie.

    Jeszcze zobaczyłem jedną rzecz, używając innego terminala (realterm) zauważyłem pewną zależność. Komunikat 'BREAK' czasem jest podświetlony na czerwono - wtedy, gdy następują problemy z komunikacją. Dołączam alert i komunikat.

    Jeśli chodzi o połączenie PC-uC to wymieniłem przejściówkę usb-rs232 na normalny kabel COM, bez zmian, więc winę przejściówki wykluczam.

    Dzięki za linki, zorganizuje sobie jakąś filtrację zasilania i ft232 nawet na zapas, natomiast może coś robię nie do końca poprawnie i alert się pojawia.

    0
  • #9 24 Cze 2015 11:19
    dondu
    Moderator Mikrokontrolery Projektowanie

    Mraycek napisał:
    Z tym kwarcem może być różnie, nota mówi, że moje 16Mhz i baud 9600 da margines błędu 0,2%, co przy dopuszczalnym 2% daje dobry wynik.

    Ale Realterm masz ustawiony na 57600, co widać w prawym dolnym rogu załączonego screena.
    I dla pewności pytanie: Czy na pewno masz fusebity włączone na zewnętrzny kwarc powyżej 8MHz?

    0
  • #10 24 Cze 2015 11:34
    Mraycek
    Poziom 9  

    Jeśli chodzi o screen, problem występował wcześniej, chodziło mi tylko o pokazanie komunikatu, przy 9600 jest identycznie. (dla pewności jeszcze jeden screen, baud na 9600, 8 bitów danych, jeden stopu.
    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)

    Fusebity ustawione, czas "wstawania" procesora dałem najdłuższy - 64ms
    Również screen dla pewności, z wtyczki avrdude w eclipse.
    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)

    0
  • #11 24 Cze 2015 11:44
    BlueDraco
    Specjalista - Mikrokontrolery

    Dziwne rzeczy piszesz. W którym miejscu Twój program wysyła po RS232 te komunikaty, które cytujesz?

    Pokaż najkrótszy program, na którym obserwujesz będne zachowanie.

    0
  • #12 24 Cze 2015 12:25
    Mraycek
    Poziom 9  

    Na tą chwilę jeszcze terminalem Termite (ustawienia terminala to baud 9600, 8 bitow danych, jeden stopu, bez parzystości, bez kontroli sterowania).
    Po zresetowaniu mikrokontrolera i wysłaniu komendy już brak reakcji.
    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)
    Na poniższym screenie odbieranie dane po 10 resetowaniach uC (powinienem mieć 10 linii "uC_gotowy")
    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)

    Przede wszystkim proszę o sprawdzenie części schematu dotyczącego komunikacji przez rs, ponieważ wszystko wskazuje na jakieś problemy w tym kierunku.

    Wtedy uruchomię w zupełnie oddzielnym programie na mikrokontrolerze podstawową komunikację i powoli będę szukał powodu problemu.

    0
  • #13 24 Cze 2015 12:47
    BlueDraco
    Specjalista - Mikrokontrolery

    Na schemacie masz masę uC wiszącą w powietrzu, ale myślę, że w rzeczywistości jest inaczej. Moim zdaniem problem leży w oprogramowaniu (którego nie pokazujesz, a oczekujesz, że będziemy szukać w nim błędów) lub błędnej konfiguracji środowiska - źle wybrany tym uC lub włączona dziwna opcja w bitach konfiguracyjnych uC.

    0
  • #14 24 Cze 2015 13:24
    Mraycek
    Poziom 9  

    Możesz sprecyzować co masz na myśli pisząc o błędnym połączeniu? Tak dla pewności :)

    Jeśli chodzi o programy, na mikrokontrolerze jest w tym momencie coś takiego:

    main.c

    Kod: c
    Zaloguj się, aby zobaczyć kod



    rs232.c
    Kod: c
    Zaloguj się, aby zobaczyć kod



    rs232.h
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Jeśli chodzi o ustawienia środowiska (eclipse)
    Mikrokontroler ustawiony na atmega32, zegar 16Mhz

    Fusebity:
    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)

    Układ został rozbudowany, co można zobaczyć w programie, ale fizycznie go odłączyłem celem wyeliminowania możliwych zakłuceń, więc podłączone jest wszystko dokładnie tak, jak rozrysowałem to na schemacie w pierwszym poście.

    Dodano po 14 [minuty]:

    uC powinien reagować w ten sposób (przed chwilą udało się tego dokonać)
    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)

    Ciągle zastanawia mnie to 'Rx line is broken'

    0
  • #15 24 Cze 2015 13:39
    dondu
    Moderator Mikrokontrolery Projektowanie

    Dlaczego nie reagujesz na warningi dot. F_CPU?
    Gdzie definiujesz F_CPU?

    Problemy należy rozkładać na czynniki pierwsze, więc zacznij od tego:

    BlueDraco napisał:
    Pokaż najkrótszy program, na którym obserwujesz będne zachowanie.


    Innymi słowy zostaw tylko definicje i funkcje :
    Kod: c
    Zaloguj się, aby zobaczyć kod

    oraz dodaj main(), ustaw TxD jako wyjściowy i dodaj pętlę nieskończoną, którą co 1 sekundę będziesz wysyłał ten sam bajt np. 0xAA.

    Edit:
    I nie włączaj przerwań.

    0
  • #16 24 Cze 2015 13:57
    Mraycek
    Poziom 9  

    Nie mam żadnych błędów ani warningów

    F_CPU definiuję tak:
    #define F_CPU 16000000UL (jest w pliku rs232.h)

    Cytat:
    Przede wszystkim proszę o sprawdzenie części schematu dotyczącego komunikacji przez rs, ponieważ wszystko wskazuje na jakieś problemy w tym kierunku.

    Wtedy uruchomię w zupełnie oddzielnym programie na mikrokontrolerze podstawową komunikację i powoli będę szukał powodu problemu.


    Jeśli chodzi o najprostszy program, również nie działał poprawnie, dlatego pytałem ciągle o schematy, ponieważ wydaje mi się, że to może być problemem.

    Dołożyłem jeszcze jednego ceramika między 30 i 31 nóżkę (avcc i gnd) i w tym momencie komunikacja wygląda dużo lepiej. Sporadycznie się zresetuje (przy większej ilości odebranych danych) lub zawiesi.
    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)

    Co jeszcze powinienem zmienić w schemacie (lub programie), aby nie występowały sporadyczne problemy?

    0
  • #17 24 Cze 2015 14:03
    dondu
    Moderator Mikrokontrolery Projektowanie

    Mraycek napisał:
    Nie mam żadnych błędów ani warningów

    F_CPU definiuję tak:
    #define F_CPU 16000000UL (jest w pliku rs232.h)

    Ależ oczywiście że masz jeden z dwóch:

    Cytat:
    #warning "F_CPU not defined for <util/delay.h>"
    lub
    "F_CPU" redefined [enabled by default]


    ponieważ: http://mikrokontrolery.blogspot.com/2011/03/fcpu-gcc-gdzie-definiowac.html

    Mraycek napisał:
    Jeśli chodzi o najprostszy program, również nie działał poprawnie, ...

    to go pokaż bo:

    Mraycek napisał:
    ... wydaje mi się, że to może być problemem.

    może być błędny wniosek

    Edit:
    ... i zastosuj się do postu #15.

    0
  • #18 24 Cze 2015 14:28
    Mraycek
    Poziom 9  

    Nie mam warninga, ponieważ moje środowisko to eclipse z wtyczką avrdude.
    definicja F_CPU w moim przypadku jest nawet zbędna.

    Nawet zrobiłem tak:

    Kod: c
    Zaloguj się, aby zobaczyć kod
    i nie dość, że nie mam błędów ani warningów, to mikrokontroler działa jak należy.
    Wszystko dzięki dodawaniu przez avrdude automatycznie informacji do pliku makefile o wybranym mikrokontrolerze.

    Poza tym, dołożenie ceramika do układu naprawiło problem z komunikacją, która czasami nie mogła w ogóle być nawiązana. Aktualnie wysyłam i odbieram komendy bez problemu. Dodatkowo zniknął alert "rx line is broken" w realtermie.

    Czy jeszcze mogę dokonać jakiejś poprawki w schemacie celem większej stabilności układu?

    0
  • #19 24 Cze 2015 14:53
    dondu
    Moderator Mikrokontrolery Projektowanie

    Kolego, zanim cokolwiek napiszesz zastanów się trzy razy:

    Mraycek napisał:
    Nie mam warninga, ponieważ moje środowisko to eclipse z wtyczką avrdude.

    Warningi są niezależne od środowiska. Możesz je co najwyżej wyłączyć, ze szkodą dla siebie: http://mikrokontrolery.blogspot.com/2011/04/bledy-kompilacji-programu.html

    Mraycek napisał:
    definicja F_CPU w moim przypadku jest nawet zbędna.

    Naprawdę? To jak ma zostać policzona ilość pętli w funkcjach opóźniających delay()?

    Mraycek napisał:
    Wszystko dzięki dodawaniu przez avrdude automatycznie informacji do pliku makefile o wybranym mikrokontrolerze.

    W makefile informacja o wybranym mikrokontrolerze wygląda tak:

    Cytat:
    MCU = atmega8

    Gdzie tutaj jest zawarta informacja o częstotliwości taktowania?

    Informacja o F_CPU znajduje się tutaj:

    Cytat:
    ## Compile options common for all C compilation units.
    CFLAGS = $(COMMON)
    CFLAGS += -Wall -gdwarf-2 -std=gnu99 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
    CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d

    pod warunkiem, że dodasz ją ręcznie albo w odpowiednich opcjach Eclipse, i o to pytałem:

    dondu napisał:
    Gdzie definiujesz F_CPU?


    na co odpowiedziałeś że w kodzie programu:

    Mraycek napisał:
    F_CPU definiuję tak:
    #define F_CPU 16000000UL (jest w pliku rs232.h)

    Jeśli więc tylko w tym pliku, to w makefile nie masz ustowaionej opcji:

    Cytat:
    -DF_CPU=16000000UL

    przez co dostaniesz warning:

    Cytat:
    #warning "F_CPU not defined for <util/delay.h>"


    Jeśli natomiast masz ustawione F_CPU w opcjach projektu (choć o tym nie napisałeś, gdy o to pytałem), to otrzymasz warning:

    Cytat:
    "F_CPU" redefined [enabled by default]

    ze wskazaniem na definicję F_CPU w kodzie w pliku rs232.h.

    Radzę analizować to co piszemy.


    Mraycek napisał:
    Poza tym, dołożenie ceramika do układu naprawiło problem z komunikacją, która czasami nie mogła w ogóle być nawiązana. Aktualnie wysyłam i odbieram komendy bez problemu. Dodatkowo zniknął alert "rx line is broken" w realtermie.

    Czy jeszcze mogę dokonać jakiejś poprawki w schemacie celem większej stabilności układu?

    Schemat z pierwszego postu jest prawidłowy. Ale jeśli takie Twoje działania powodują poprawę, to rodzą się pytania:

    1. W jakim środowisku to pracuje?

    2. Jakie są długości przewodów transmisyjnych i zasilających?

    3. Co jest źródłem zasilania?

    Generalne uwaga - lepiej pokaż cały schemat.

    0
  • #20 24 Cze 2015 16:20
    Mraycek
    Poziom 9  

    Cytat:
    Gdzie definiujesz F_CPU?

    Nie zrozumiałem do końca co miałeś na myśli.
    Sytuacja wygląda tak:
    W opcjach projektu, w zakładce avrdude mam ustawiony procesor atmega32 i zegar na 16Mhz
    Niezależnie od tego, czy definicję F_CPU zakomentuję, czy zostawię w pliku rs232.h nie dostaję warninga (warningi nie są wyłączone, czasem się pojawiają na co oczywiście zwracam uwagę zgodnie z zaleceniami na Twoim blogu :) )
    Natomiast program działa bez względu na to, czy definicja F_CPU jest zakomentowana czy nie. Wszystkie programy tak mam, nigdzie nie ma warningów.
    Mam książkę Mirosława Kardasia, w której pisze, że eclipse robi część spraw za mnie, co się sprawdza, a to czy już jest w makefile, czy gdzie, to już formalność, mogę się mylić
    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)

    Przy dokładaniu ceramika również sugerowałem się Twoimi zaleceniami na blogu.
    Chociaż post może sprawiać takie wrażenie, nie chcę być mądrzejszy, dlatego pytam bardziej doświadczonych ludzi. Ale nie ma co szukać w programie, skoro jest sprawny :)

    1. Środowisko - biurko ;)
    Nie mam tu blisko dużego napięcia, pól elektromagnetycznych ani tym podobnych rzeczy. (Jedynie router+wi-fi niedaleko)

    2. Długość kabli zasilających i sygnałowych to jakieś 50cm

    3. Zasilacz transformatorowy 5V, 1A
    Dodatkowo masa programatora jest połączona z masą układu (tak powinno być?)

    W tym momencie wszystko inne jest odłączone fizycznie od układu i wyłączone zasilanie, zrobię za chwile schemat w eagle jak to docelowo ma działać.

    0
  • Pomocny post
    #21 24 Cze 2015 17:27
    dondu
    Moderator Mikrokontrolery Projektowanie

    Mraycek napisał:
    W opcjach projektu, w zakładce avrdude mam ustawiony procesor atmega32 i zegar na 16Mhz

    I taką odpowiedź trzeba było udzielić na moje pytanie :)

    Mraycek napisał:
    Niezależnie od tego, czy definicję F_CPU zakomentuję, czy zostawię w pliku rs232.h nie dostaję warninga (warningi nie są wyłączone, czasem się pojawiają na co oczywiście zwracam uwagę zgodnie z zaleceniami na Twoim blogu :) )

    To bardzo niedobrze, że się nie pojawiają. Z ciekawości zrób proszę próbę i ustaw różne F_CPU w opcjach projektu i w pliku rs232.h
    Zobacz czy i jaki warning otrzymasz.

    Mraycek napisał:
    eclipse robi część spraw za mnie, co się sprawdza, ...

    Tak jest z większością środowisk programistycznych.


    Mraycek napisał:
    Chociaż post może sprawiać takie wrażenie, nie chcę być mądrzejszy, dlatego pytam bardziej doświadczonych ludzi.

    Nie odniosłem takiego wrażenia - opisałeś problem, dałeś materiały do analizy, czasami tylko niezbyt ściśle się wyrażasz. Ale generalnie jest OK :)

    Mraycek napisał:
    Ale nie ma co szukać w programie, skoro jest sprawny :)

    Poprawna komunikacja składa się z wielu wątków:
    - program,
    - fusebity,
    - definicja F_CPU,
    - poprawnego ustawienia odbiornika danych (np. teminala),
    - schemat,
    - przewody,
    - środowisko (otoczenie),
    - no i parę promili na tzw. "cuda" :)

    Dlatego szukamy po kolei.


    Ad 1. 2. 3
    Nawet bez kondensatorów przy mikrokontrolerze przy takim stanie faktycznym jak opisujesz powinien działać prawidłowo pod warunkiem, że źródło zasilania nie generuje jakichś zakłóceń - rozumiem, że ma stabilizację napięcia?.

    Spróbuj może dla testu zasilić z programatora i bez kondensatorów filtrowania zasilania mikrokontrolera.

    1
  • #22 24 Cze 2015 17:51
    Mraycek
    Poziom 9  

    Jeśli chodzi o F_CPU to zrobiłem jak pisałeś, nadal brak warninga.

    Nabazgrałem schemat kompletnego projektu (mam nadzieję, że zrozumiale), mam go na płytce stykowej i uC reaguje poprawnie na zmiany stanów
    (jeśli zmiana na wejściu - wysyła komunikat, jeśli otrzymuje komendę, daje sygnał na wyjście)

    Stabilizację napięcia jeszcze zrobię dodatkowo na płytce, zasilacz nie wiem czy ma stabilizację i czy generuje zakłócenia, to zasilacz od jakiegoś switcha pewnie (D-Link)

    0
  • #23 24 Cze 2015 17:54
    Intre
    Poziom 10  

    A ja się tak zastanawiam czy może ja albo ktoś z kolegów nie podesłałby Ci skompilowanego hexa dla A32 z 16Mhz, przetestowanego u siebie i sprawdzonego z UART co by zdiagnozowało czy przyczyn należy szukać w sprzęcie czy programie.

    0
  • #24 24 Cze 2015 20:31
    Mraycek
    Poziom 9  

    Wydaje mi się w tym momencie, że program procka jest ok.
    Zrobię wieczorem albo rano program, który będzie dawał komendy na wyjścia co sekundę, a te wyjścia podepnę do wejść uC (czyli co sekundę mikrokontroler będzie musiał pobrać komendę, odesłać potwierdzenie i zmienić stan wyjść i odczytać stan wejść odsyłając informację do komputera)

    Pochodzi taki układ pół godziny i zobaczę później jakie będą wyniki w excelu.

    A jeśli schemat od strony sprzętowej jest nie do końca poprawny, to mam nadzieję, że dondu tu jeszcze zawita i mnie o tym poinformuje ;)

    0
  • Pomocny post
    #25 24 Cze 2015 22:23
    BlueDraco
    Specjalista - Mikrokontrolery

    Schemat jest poprawny, tylko zupełnienie wiem, po co włożyłeś 8 zbędnych tranzystorów npn i tyleż zbędnych rezystorów.

    1
  • #26 25 Cze 2015 00:16
    Mraycek
    Poziom 9  

    rezystory przed transoptorami dałem, bo nie mogłem ich wysterować prądem 5V

    Teraz sprawdzam i bez rezystorów też jest ok, nie wiem czemu miałem wcześniej problemy, może po prostu coś źle podpinałem, więc rezystory przed transoptorami do wywalenia
    (rezystorów między transoptorami a tranzystorami już nie ma)

    Teraz widzę również, że tranzystory zupełnie bezsensownie połączone, jeśli już to tranzystor od razu na wyjściu uC, żeby w razie czego 20mA nie przekroczyć.

    Jeszcze dołożę stabilizator napięcia dla atmegi, na pewno jej to na złe nie wyjdzie
    W takim razie dziękuję wam za pomoc, jutro wrzucę jeszcze wyniki dłuższego testu ;)

    Dodano po 49 [minuty]:

    rezystory 7,5k na wejściach po to, żeby transoptor otwierał się przy około 15V, nie mniej

    0
  • #27 26 Cze 2015 20:38
    BlueDraco
    Specjalista - Mikrokontrolery

    Zbędne są:
    - tranzystory npn na wejściach ATmega za transoptorami i rezystory przy nich - wystarczy tranzystor transoptora włączyć pomiędzy masę i wejście uC;
    - tranzystory pnp na wyjściach za transoptorami w dodatku błędnie połączone, co spowoduje ich upalenie - możesz sterować tranzystor MOS bezpośrednio z transoptora.

    0
  • #28 27 Cze 2015 00:25
    Mraycek
    Poziom 9  

    Już doszedłem do tego, optymalizowałem układ wyrzucając niepotrzebne elementy.

    Jesli chodzi o testy - uC chodził przez niecałe 4 godziny :D , co 5 sekund dostawal komende wlaczenia 4 wyjsc, ktore podlaczone do wejsc od razu zmienialy stan na wejsciach, o czym rowniez uC mial informowac.

    tabela przedstawiajaca ilosc odebranych komend:
    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)
    komend zaczynajacych sie od # powinno byc dokladnie tyle ile jest, natomiast pozostalych dokladnie 1327, wiec wynik niezly, jednak moglo byc lepiej.

    jesli byly bledy w komunikaacji to np wyslanie znaku przejscia do nowej linii w nieodpowiednim miejscu.

    jesli ktos mialby jeszcze jakis pomysl odnosnie optymalizacji ukladu jeszcze bardziej to czekam na sugestie.
    jutro (dzisiaj) wrzuce nowa wersje programu i zmodyfikowany schemat ]Link[/url]

    0
  • #29 27 Cze 2015 15:11
    Mraycek
    Poziom 9  

    Mam jeszcze pytanie odnośnie zasilania.
    Wygląda to tak, że atmega jest zasilana 5VDC, za optoizolatorami na wyjściach również musi być 5VDC aby otwierać mosfety a za mosfetami musi być 24VDC, aby sterować wyjściami.
    Co zrobić, żeby nie musieć używać 3 osobnych zasilaczy (najlepiej byłoby jeden, 24VDC) równoczesnie zachowując sens optoizolacji?

    Druga sprawa, na wyjściach mosfetami buz10 steruję sygnałem gnd, a muszę sterować sygnałem +24V, dołożyłem zatem za p-mosfetem jeszcze n-mosfet (nie mam innych niż irf4509). Pytanie brzmi, czy będzie to działać dobrze (nic się nie grzeje) i jakich użyć n-mosfetów, żeby otwierały się przy sygnale z mikrokontrolera, dając na dren +24V?
    (trochę to pokombinowane, ale działa, wiem że nie jest to zrobione profesjonalnie, ale do testów potrzebowałem sprawne wyjścia ;) )

    [atmega32][C] - Sprawdzenie programu i schematu (sterowanie przez rs232)

    0
  • #30 27 Cze 2015 15:28
    BlueDraco
    Specjalista - Mikrokontrolery

    Rezystory 18k na wejściach są zbędne - wyrzuć je.
    Za transoptorami możesz mieć 24V, dodaj tylko rezystory w szereg z transoptorami, tak,żeby przy włączeniu transoptora napięcie na bramce MOS nie przekroczyło dopuszczalnego (zapewne 12 V, czyli w bramce każdego MOS portrzebujesz dzielnika 2:1, np 2 x 10k).

    Oczywiście nie są też potrzebne dodazkow MOSFETy za transoptorami - steruj wykonawczym bezpośrednio z transoptora.

    0
  Szukaj w 5mln produktów