ATNEL tech-forum

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-12-13T20:48:31+01:00

dzięki za link.Musze spróbować teraz połączyć dwa procki.Mirek36 pewnie masz racje z ta zmiana jezyka i chyba po świętach zamówię sobie książkę.Trzeba się jednak rozwijać.Doba nie odbiegajmy od tematu.

Statystyki: Napisane przez grzeniu 73 — 13 gru 2013, o 20:48

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-12-13T19:59:54+01:00

grzeniu 73 napisał(a):

ale jak sobie pomyśle żeby wszystko od nowa zaczynać.

A później z kolei można sobie pluć w brodę - że szkoda, że tak późno się zaczęło od książek i wystartowania na poważnie bo - zwykle po nich już po niebieskiej (bluebooku) okazuje się - że wcale diabeł nie był taki straszny jak go malowano w naszej głowie wcześniej

Tymczasem zanim będziesz miał okazję wziąć w łapki bluebooka to rzeczywiście - skoro tak obawiasz się SPI to akurat nasz kolega SunRiver - też bardzo fajnie to wyjaśnia

http://sunduino.elektroda.eu/wordpress/ ... o-nie-spi/

Statystyki: Napisane przez mirekk36 — 13 gru 2013, o 19:59

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-12-13T19:44:36+01:00

poczytaj to : http://sunduino.elektroda.eu/wordpress/ ... o-nie-spi/
tak wiem zamotałem ...

Statystyki: Napisane przez SunRiver — 13 gru 2013, o 19:44

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-12-13T19:12:36+01:00

no wiem ale taki w połowie:) Pełnej obsługi jeszcze nie próbowałem.Ciężko znaleźć jakieś przykłady w bascom,a samemu opornie to idzie. Walcze ze sobą żeby w końcu kupić te magiczne książki,ale jak sobie pomyśle żeby wszystko od nowa zaczynać.

Statystyki: Napisane przez grzeniu 73 — 13 gru 2013, o 19:12

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-12-13T17:02:36+01:00

grzeniu 73 napisał(a):

bo dzięki niemu zrozumiałem transmisje przez SPI, a balem sie tego jak ognia.Pozdrawiam!

tak między nami ... shift register to jeszcze żadna transmisja na SPI

Statystyki: Napisane przez SunRiver — 13 gru 2013, o 17:02

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-12-13T14:14:24+01:00

Witam ! O 1.50 odpowiedz:) Napisałem tutaj ,bo to tez rejestrów przesuwnych dotyczy.Odpowiedzi nie znalazłem w sieci i trochę sie tym sam pobawiłem i sie udalo.Dla potomnych może komuś sie przyda. Wystarczy wysłać dwa bajty jeden za drugim.Proste jak drut.Dzieki za poradnik ,bo dzięki niemu zrozumiałem transmisje przez SPI, a balem sie tego jak ognia.Pozdrawiam!

Statystyki: Napisane przez grzeniu 73 — 13 gru 2013, o 14:14

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-12-13T01:50:29+01:00

grzeniu 73 napisał(a):

Witam!
Obejrzałem poradniki i zapragnelem tez tak potrafić:) No i na pragnieniach sie skończyło.Kupilem kiedyś dwa rejestry do testów ,ale 74hc164. Podłączyłem sobie jeden do wyświetlacza i wszystko ok.Działa jak powinno.Problem mam jak dołączyć drugi.Chodzi o fizyczne podłączenie z prockiem dwóch rejestrów jak i wysłanie danych.Nie mam pojęcia jak to multipleksować.Pisze w Bascom.Jakieś podpowiedzi żebym chociaż wiedział jak ruszyć to dalej.

To ja na twoim miejscu pokazałbym chociaż schemat jak próbuję to łączyć ... itp ...

toż one są inne niż w poradniku więc chyba nie myślisz że wszystko będzie identycznie ? Ogólna zasada ta sama no ale połączenia mogą się różnić - nie wspomnę już o języku ....

ja w Bascomie nie pomogę - i pytanie bardziej do działu Bascom na forum

Statystyki: Napisane przez mirekk36 — 13 gru 2013, o 01:50

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-12-12T19:10:45+01:00

Statystyki: Napisane przez grzeniu 73 — 12 gru 2013, o 19:10

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-08T18:51:09+01:00

mirekk36 napisał(a):

xamrex napisał(a):

Czyli teroretycznie, żeby działał mi ten rejestr na TWI to muszę go odłączyć, potem wysłac bit startu (te TWSTA)
Potem go(rejestr) podłączyć i mój kod powinien ruszyć?

ale teraz to kolega zrobił kosmiczno-marsjańską końbinację

rezasurmar napisał(a):

Po drugie przeczytaj note TWI do AVRów, bez ustawienia TWSTA sprzętowy i2c nie wystartuje tzn, nie jako master

Dokładnie - proponuję zacząć od tego "Po drugie" co kolega wyżej napisał - bo widać że próbujesz coś tam zrobić całkowicie na ślepo ... ot tak może się uda - może się nie uda .... biorąc pod uwagę że to co chcesz zrobić to tak jakby np hmm za pomocą widelca jeść zupę .... No pewnie jakoś się da widelcem zjeść troszkę tej zupy ale w większości się zachlapiesz i zniechęcisz ... po co tak?

Proponuję ci zostaw I2C i poczytaj w nocie o możliwości konfiguracji modułu sprzętowego TWI do pracy w trybie SPI/USI ... bo tym sposobem pewnie da radę - a nie w trybie I2C bo to jak ten widelec i zupa.

No i się udało mi przesłać dane po I2C (trzeba było wywołać na początku funkcję TWI_start(); aby ruszyło
Nie do końca działa to poprawnie, bo:
wysyłając np.
0x00 jest stan wysoki na Q0
0x01 jest stan wysoki na Q1 i Q0
0x02 jest stan wysoki na Q2 i Q0
..
..
wysyłając 0x40 jest stan wysoki na Q7 i Q0

Ale mniej więcej działa

Statystyki: Napisane przez xamrex — 8 paź 2013, o 18:51

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-04T12:58:44+01:00

mirekk36 napisał(a):

tylko jeden zatrzask

No faktycznie hehehe. Nie wiem czemu tak zrobiłem... Przecież latchowanie i tak będzie zawsze następowało jednocześnie bo inaczej nie ma sensu, tylko dodatkowy kod. Czyli wystarczą 3 piny.

Statystyki: Napisane przez sq8dsr — 4 paź 2013, o 12:58

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-04T12:24:02+01:00

squeez napisał(a):

Oddzielne zatrzaski zrobiłeś celowo?

Bo jeśli dobrze rozumiem to i tak musisz wysłać dwa bajty, pierwszy trafi do rejestru dla wyświetlaczy a drugi bajt do rejestru z segmentami i wówczas zatrzaskujesz je. Więc wystarczy jeden wspólny zatrzask.

Dwa zatrzaski mają sens jeśli raz wysyłasz 2 bajty z czasami tylko 1 bajt na pierwszy rejestr i nie chcesz by drugi rejestr zmieniał swoje wyjścia.

Słuszna uwaga, umknęło mi to .... tylko jeden zatrzask

Statystyki: Napisane przez mirekk36 — 4 paź 2013, o 12:24

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-04T12:09:48+01:00

Wiesz tak naprawdę to myślę, że warto to sprawdzić w praktyce .... Przy 8 wyświetlaczach powinno to działać spokojnie. Im więcej wyświetlaczy tym bardziej warto zadbać i maksymalną częstotliwość SCK na SPI.

Co do schematu - jaka tam laurkowość ? człowiek patrzy i od razu widzi o co chodzi .... a to czy elementy ułożone tak czy inaczej, czy w ramkach czy nie - to już naprawdę drugorzędna sprawa. Jak na pierwszy schemat to i tak widać, że masz już duże doświadczenie w tworzeniu schematów. Tam gdzie trzeba jest BUS, tam gdzie trzeba są etykiety itp

Statystyki: Napisane przez mirekk36 — 4 paź 2013, o 12:09

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-04T11:57:18+01:00

mirekk36 napisał(a):

oczywiście że można tak właśnie na rejestrach robić wspominam o tym właśnie w tym poradniku

Tak Mirku, wiem, zresztą wcześniej sam kombinowałem teoretycznie nad tym. Wcześniej widziałem tylko układy gdzie wsp. katody są podłączone na stałe, a każda cyfra ma swój własny 595.

Chodziło mi o to, czy idea tego schematu jest poprawna, zanim zacznę coś takiego budować
No i przy okazji czy są tam jakieś "laurkowatości" bo to mój pierwszy schemat który pokazuję na forum publicum

Statystyki: Napisane przez sq8dsr — 4 paź 2013, o 11:57

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-04T11:41:47+01:00

oczywiście że można tak właśnie na rejestrach robić wspominam o tym właśnie w tym poradniku

Statystyki: Napisane przez mirekk36 — 4 paź 2013, o 11:41

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-04T10:52:25+01:00

W sumie idea sterowania się nie zmienia, można zrobić podobnie jak została przerobiona biblioteka hd44780 przez kolegę shoc na i2c, po prostu zamiast wywalać zmienną na port w postaci 8bitów, przekazujemy go do funkcji obsługującej i2c,spi czy co tam mamy podpięte.

Statystyki: Napisane przez Gość — 4 paź 2013, o 10:52

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-04T10:42:19+01:00

Bardzo fajny poradnik, jak zwykle zresztą
Zastanawiałem się jak zrobić multipleksowany wyświetlacz LED na rejestrach przesuwnych i tak sobie myślę, że wystarczą dwa rejestry 595 żeby zrobić 8 pozycyjny wyświetlacz. Nie wiem czy dobrze kombinuję, nie próbowałem jeszcze czegoś takie budować. Ale chodzi mi o coś takiego:

W schemacie są pewnie jakieś elementy laurkowe, ale to mój pierwszy schemat zrobiony w Eagle. Oczywiście chodzi mi w nim o idee stosowania rejestrów do sterowania segmentami i anodami. Docelowo nie dałbym pojedynczych segmentów tylko dwa moduły po 4 cyfry, z segmentami połączonymi wewnętrznie.

Idea pracy czegoś takiego, według mnie jest następująca:
Sterujemy stanem niskim.
1. Wysyłamy dwa bajty. Pierwszy zawiera informację o "aktywnej" anodzie, drugi o konfiguracji segmentów.
2. Latch'ujemy oba rejestry.
3. Czekamy na następne przerwanie w którym wyślemy po SPI dwa kolejne bajty.

Rozwijając te idee dalej można przy użyciu 3 rejestrów sterować 8 wyświetlaczami 16-to segmentowymi.

Statystyki: Napisane przez sq8dsr — 4 paź 2013, o 10:42

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-03T14:39:49+01:00

rezasurmar napisał(a):

... chodziło mi o to że każdy osprzęt jest opisany w nocie, jak się go inicjuje .

Tak tak - dokładnie i akurat przy tym I2C widać, że kolegę xarmexa jakoś mocno od noty odrzuca

Statystyki: Napisane przez mirekk36 — 3 paź 2013, o 14:39

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-03T14:33:55+01:00

No masz rację Mirku, chodziło mi o to że każdy osprzęt jest opisany w nocie, jak się go inicjuje .

Statystyki: Napisane przez Gość — 3 paź 2013, o 14:33

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-03T14:11:17+01:00

rezasurmar napisał(a):

Jeżeli korzystasz w wewnętrznych peryferii jakiegokolwiek procesora to nie interesują cię wtedy PINy tego procesora jako porty, tylko interesują cię tylko rejestry danego "sprzętu" czy to i2c, uart, SPI etc.

No z tym to jednak chyba nie tak do końca ... tzn np w SPI trzeba ustawić piny jako wyjścia , przy UARCIE już nie, przy I2C też nie... Ale np kolejny przypadeg gdy trzeba to sterowanie wyjść OCx za pomocą PWM czy CTC. Po prostu niektóre moduły sprzętowe przejmują PEŁNĄ kontrolę nad pinem i jego kierunkiem a inne nie.

tak troszkę w kratkę jest czasem trzeba a czasem nie

ale jak zwykle PODSTAWA to zajrzeć do noty - co racja to racja

Statystyki: Napisane przez mirekk36 — 3 paź 2013, o 14:11

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-03T12:00:17+01:00

Quote:

Przecież napisałem
xamrex napisał(a):
Pracuje na Atmedze8

A ona ma Twi na PC5, i PC4

No ale po co ustawiasz ręcznie te piny? powiedz mi w którym miejscu jest napisane że tak trzeba, o to mi chodziło.

Jeżeli korzystasz w wewnętrznych peryferii jakiegokolwiek procesora to nie interesują cię wtedy PINy tego procesora jako porty, tylko interesują cię tylko rejestry danego "sprzętu" czy to i2c, uart, SPI etc.

Statystyki: Napisane przez Gość — 3 paź 2013, o 12:00

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-03T11:33:44+01:00

xamrex napisał(a):

Czyli teroretycznie, żeby działał mi ten rejestr na TWI to muszę go odłączyć, potem wysłac bit startu (te TWSTA)
Potem go(rejestr) podłączyć i mój kod powinien ruszyć?

ale teraz to kolega zrobił kosmiczno-marsjańską końbinację

rezasurmar napisał(a):

Po drugie przeczytaj note TWI do AVRów, bez ustawienia TWSTA sprzętowy i2c nie wystartuje tzn, nie jako master

Statystyki: Napisane przez mirekk36 — 3 paź 2013, o 11:33

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-03T11:28:07+01:00

rezasurmar napisał(a):

Tzn. że co, że myślisz że jak ustawisz za pomocą define na innym porcie niż PC1 PC0 ( w przypadku Atmegi32/644 etc.) to sprzętowy I2C jak za machnięciem różdżki przeskoczy ci na inne porty?

Przecież napisałem

xamrex napisał(a):

Pracuje na Atmedze8

A ona ma Twi na PC5, i PC4

Czyli teroretycznie, żeby działał mi ten rejestr na TWI to muszę go odłączyć, potem wysłac bit startu (te TWSTA)
Potem go(rejestr) podłączyć i mój kod powinien ruszyć?

Statystyki: Napisane przez xamrex — 3 paź 2013, o 11:28

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-03T10:29:46+01:00

mirekk36 napisał(a):

No ja też ci nie powiem jak się zachowa I2C (nadajnik sprzętowy) jeśli nie wygenerujesz startu i stopu

No właśnie zachowa się tak jak powyżej . Po za tym co to za pomysł z tym

[syntax=c]#define SCL PC5
#define SDA PC4
........
int main(void){........
DDRC|=(1< PORTC|=(1<
Tzn. że co, że myślisz że jak ustawisz za pomocą define na innym porcie niż PC1 PC0 ( w przypadku Atmegi32/644 etc.) to sprzętowy I2C jak za machnięciem różdżki przeskoczy ci na inne porty?
Po drugie przeczytaj note TWI do AVRów, bez ustawienia TWSTA sprzętowy i2c nie wystartuje tzn, nie jako master.

Statystyki: Napisane przez Gość — 3 paź 2013, o 10:29

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-03T09:23:16+01:00

Nie mam pojęcia
Mógłbyś zdradzić tę tajemnicę?

Statystyki: Napisane przez xamrex — 3 paź 2013, o 09:23

Re: ATB-SHIELD-IO - uzupełnienie do rej. przesuwnych ;)

2013-10-03T06:28:44+01:00

Najpierw pomyśl czemu po wrzuceniu nawet do while

[syntax=c]int main(void){
DDRC|=(1< PORTC|=(1<
i2cSetBitrate(100);
TWI_write(0x0f);

while(1){
TWI_write(0xAA);
TWI_write(0x55);
}
}[/syntax]

Na PC5 i PC4 dzieje się tyle, że stan ustawia się na wysoki i nic więcej .

Statystyki: Napisane przez Gość — 3 paź 2013, o 06:28