badworm
Guest
Tue Mar 03, 2015 9:52 pm
By sobie nie komplikować życia i nie pakować do loggera GPS procka z
dwoma portami RS to postanowiłem pożenić razem AVRa, moduł GPS i port
komunikacyjny do PC (FT232R) razem. Założenie jest takie, że do wejścia
RXD w procesorze będzie podłączone THX z GPSa i TXD z FTDI a TXD z
procka będzie się rozwidlał na RXD GPSa i RXD konwertera na USB. Moduł
GPS ma wejście RST, którego pobudzenie pięknie wprowadza go w stan, w
którym nie zakłóca transmisji z AVRa do PC (w ramach testów, z
wykorzystaniem przejściówki z układem Profilic). Niestety w drugą stronę
działa to gorzej - choć Mega nic nie nadaje to blokuje transmisję z GPSa
do komputera. Czy w docelowym układzie ma to ma to szansę zadziałać w
drugą stronę, tzn. czy FT232R nie będzie mi blokował tego, co AVR będzie
odbierał z GPSa?
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066
Mario
Guest
Wed Mar 04, 2015 12:12 am
W dniu 03.03.2015 21:52, badworm pisze:
Quote:
By sobie nie komplikować życia i nie pakować do loggera GPS procka z
dwoma portami RS to postanowiłem pożenić razem AVRa, moduł GPS i port
komunikacyjny do PC (FT232R) razem. Założenie jest takie, że do wejścia
RXD w procesorze będzie podłączone THX z GPSa i TXD z FTDI a TXD z
procka będzie się rozwidlał na RXD GPSa i RXD konwertera na USB. Moduł
GPS ma wejście RST, którego pobudzenie pięknie wprowadza go w stan, w
którym nie zakłóca transmisji z AVRa do PC (w ramach testów, z
wykorzystaniem przejściówki z układem Profilic). Niestety w drugą stronę
działa to gorzej - choć Mega nic nie nadaje to blokuje transmisję z GPSa
do komputera. Czy w docelowym układzie ma to ma to szansę zadziałać w
drugą stronę, tzn. czy FT232R nie będzie mi blokował tego, co AVR będzie
odbierał z GPSa?
Ja dawałem diodę (i równolegle rezystor) w linii TXD tak aby układ
będący w spoczynku nie wymuszał mocno stanu wysokiego. Czyli stan wysoki
(-12V) był przez rezystor, a stan niski (+12V) był przez diodę.
Działało, chociaż ze standardem RS232 nie było to zgodne :)
--
pozdrawiam
MD
badworm
Guest
Wed Mar 04, 2015 10:28 pm
Dnia Wed, 04 Mar 2015 00:12:49 +0100, Mario napisał(a):
Quote:
Ja dawałem diodę (i równolegle rezystor) w linii TXD tak aby układ
będący w spoczynku nie wymuszał mocno stanu wysokiego. Czyli stan wysoki
(-12V) był przez rezystor, a stan niski (+12V) był przez diodę.
Działało, chociaż ze standardem RS232 nie było to zgodne
Może nieco nieprecyzyjnie się wyraziłem - nie chodziło o RS232 z
poziomami +/-12V ale o UART na 3,3V. Wykonałem dziś próbę na nieco innym
module GPS i wygląda to tak, że dopóki FT232 nie dostanie zasilania z
USB to jest OK, procek odbiera dane z GPSa. Podłączenie do komputera
niejako automagicznie przerzuca procek na komunikację z FT232 - dane z
modułu GPS są blokowane. Takie rozwiązanie mi całkiem pasuje
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066
janusz_k
Guest
Thu Mar 05, 2015 5:54 pm
W dniu 2015-03-04 o 22:28, badworm pisze:
Quote:
Dnia Wed, 04 Mar 2015 00:12:49 +0100, Mario napisał(a):
Ja dawałem diodę (i równolegle rezystor) w linii TXD tak aby układ
będący w spoczynku nie wymuszał mocno stanu wysokiego. Czyli stan wysoki
(-12V) był przez rezystor, a stan niski (+12V) był przez diodę.
Działało, chociaż ze standardem RS232 nie było to zgodne :)
Może nieco nieprecyzyjnie się wyraziłem - nie chodziło o RS232 z
poziomami +/-12V ale o UART na 3,3V. Wykonałem dziś próbę na nieco innym
module GPS i wygląda to tak, że dopóki FT232 nie dostanie zasilania z
USB to jest OK, procek odbiera dane z GPSa. Podłączenie do komputera
niejako automagicznie przerzuca procek na komunikację z FT232 - dane z
modułu GPS są blokowane. Takie rozwiązanie mi całkiem pasuje :)
A nie prościej ci dać klucz analogowy i po bożemu to przełączać np 4052
albo 4066 niż tak rzeźbić w g.wnie i potem się zastanawiać dlaczego nie
chodzi.
--
Pozdr
Janusz_K
Dariusz Dorochowicz
Guest
Fri Mar 06, 2015 8:08 am
W dniu 2015-03-05 o 17:54, janusz_k pisze:
Quote:
A nie prościej ci dać klucz analogowy i po bożemu to przełączać np 4052
albo 4066 niż tak rzeźbić w g.wnie i potem się zastanawiać dlaczego nie
chodzi.
Jest jeszcze prostsze rozwiązanie - procek z odpowiednią liczbą portów
Ale z jakiegoś powodu nie pasuje autorowi, nie mam pojęcia dlaczego.
Pozdrawiam
DD
badworm
Guest
Fri Mar 06, 2015 5:19 pm
Dnia Fri, 06 Mar 2015 08:08:03 +0100, Dariusz Dorochowicz napisał(a):
Quote:
Jest jeszcze prostsze rozwiązanie - procek z odpowiednią liczbą portów
Ale z jakiegoś powodu nie pasuje autorowi, nie mam pojęcia dlaczego.
Rozważałem to ale problem jest z dostępnością odpowiedniego procka z
grona małych AVRów. 2 UARTy i przetwornik ADC ma chyba dopiero MEGA128 a
ona jest nieco za duża dla mnie.
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066
adamschodowy
Guest
Sat Mar 07, 2015 9:21 pm
Quote:
Jest jeszcze prostsze rozwiązanie - procek z odpowiednią liczbą portów
Ale z jakiegoś powodu nie pasuje autorowi, nie mam pojęcia dlaczego.
Rozważałem to ale problem jest z dostępnością odpowiedniego procka z
grona małych AVRów. 2 UARTy i przetwornik ADC ma chyba dopiero MEGA128 a
ona jest nieco za duża dla mnie.
na innych można meć jeden uart sprzętowy i drugi softwarowy
Sebastian Biały
Guest
Mon Mar 09, 2015 9:23 pm
On 2015-03-06 17:19, badworm wrote:
Quote:
Rozważałem to ale problem jest z dostępnością odpowiedniego procka z
grona małych AVRów. 2 UARTy i przetwornik ADC ma chyba dopiero MEGA128 a
ona jest nieco za duża dla mnie.
162 ma dwa uarty, ale to też duża cholera.
Dariusz Dorochowicz
Guest
Tue Mar 10, 2015 7:54 am
W dniu 2015-03-06 o 17:19, badworm pisze:
Quote:
Dnia Fri, 06 Mar 2015 08:08:03 +0100, Dariusz Dorochowicz napisał(a):
Jest jeszcze prostsze rozwiązanie - procek z odpowiednią liczbą portów
Ale z jakiegoś powodu nie pasuje autorowi, nie mam pojęcia dlaczego.
Rozważałem to ale problem jest z dostępnością odpowiedniego procka z
grona małych AVRów. 2 UARTy i przetwornik ADC ma chyba dopiero MEGA128 a
ona jest nieco za duża dla mnie.
No to ja się dorzucę - użyłem Atmelowej wyszukiwarki.
Czy 1284P to też "nieco za duży"? To może 164PA? Trochę tam jest jeszcze
do znalezienia. Nie wiem, jak te trochę nowsze mają się do starszych
procków, ale "na czuja" wydaje się, że nie powinny mieć jakichś
specjalnych różnic. Większe zmiany to już mają ATXMegi - tu można
zaszaleć, taka np ATXMega32E5, ale to jednak inna klasa procków, choć
ARM to nie jest.
Pozdrawiam
DD
badworm
Guest
Wed Mar 11, 2015 10:52 pm
Dnia Tue, 10 Mar 2015 07:54:58 +0100, Dariusz Dorochowicz napisał(a):
Quote:
No to ja się dorzucę - użyłem Atmelowej wyszukiwarki.
Czy 1284P to też "nieco za duży"? To może 164PA? Trochę tam jest jeszcze
do znalezienia. Nie wiem, jak te trochę nowsze mają się do starszych
procków, ale "na czuja" wydaje się, że nie powinny mieć jakichś
specjalnych różnic. Większe zmiany to już mają ATXMegi - tu można
zaszaleć, taka np ATXMega32E5, ale to jednak inna klasa procków, choć
ARM to nie jest.
Dzięki Darku za podpowiedź. Wszelakie AVRy w TQFP44 się nadadzą. Na
jeden z dwóch zaproponowanych przez Ciebie procków się pewnie zdecyduję
- są dostępne w TME.
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066
badworm
Guest
Sun Mar 15, 2015 4:19 pm
Dnia Tue, 10 Mar 2015 07:54:58 +0100, Dariusz Dorochowicz napisał(a):
Quote:
No to ja się dorzucę - użyłem Atmelowej wyszukiwarki.
Czy 1284P to też "nieco za duży"? To może 164PA? Trochę tam jest jeszcze
do znalezienia. Nie wiem, jak te trochę nowsze mają się do starszych
procków, ale "na czuja" wydaje się, że nie powinny mieć jakichś
specjalnych różnic. Większe zmiany to już mają ATXMegi - tu można
zaszaleć, taka np ATXMega32E5, ale to jednak inna klasa procków, choć
ARM to nie jest.
Pozwolę się zapytać o jeszcze jedną rzecz - czy jeśli używana przeze
mnie wersja WinAVR nie obsługuje tych procków (aż wstyd się przyznać z
jak starej wersji korzystam...) to jeśli po skopiowaniu stosownego pliku
*.h z nowszej wersji program (stworzony wcześniej dla MEGA162) kompiluje
się bez błędów to mogę uznać, że wszystko jest ok?
--
Pozdrawiam Bad Worm badworm[maupa]post{kropek}pl
GG#2400455 ICQ#320399066
Dariusz Dorochowicz
Guest
Mon Mar 16, 2015 7:51 am
W dniu 2015-03-15 o 16:19, badworm pisze:
Quote:
Pozwolę się zapytać o jeszcze jedną rzecz - czy jeśli używana przeze
mnie wersja WinAVR nie obsługuje tych procków (aż wstyd się przyznać z
jak starej wersji korzystam...) to jeśli po skopiowaniu stosownego pliku
*.h z nowszej wersji program (stworzony wcześniej dla MEGA162) kompiluje
się bez błędów to mogę uznać, że wszystko jest ok?
Nie mam pojęcia - wstyd się przyznać, ale jak na razie nie programuję
(kiedyś, dawno temu, i ciągle sobie obiecuję, że wreszcie w ramach
rozrywki coś z tym zrobię).
Poza tym uważam, że na eksperymentowanie tego rodzaju szkoda czasu.
Może ktoś mądrzejszy ode mnie się wypowie.
Pozdrawiam
DD