Obsługa LCD (hd44780) przez SPI?

[Bobby]

Pullupy na inputach powłączane?

[Marooned]

Prawdę powiedziawszy to nie, bo nie ma o tym informacji w datasheet.

Spróbuję zatem.

[ Dodano: 20-12-2012, 23:16 ]

Przy pull-upach wszystko wisi, zero transmisji.

[Bobby]

No to ciekawe. Prędkości i ogólnie setup transmisji w nadajniku i odbiorniku jest ten sam?

[Marooned]

Cały setup wziąłem z datasheet i zamieściłem w poprzednim poście.

8 była na 16MHz, 32 była na wewnętrznym 1MHz - zmieniłem ją na kwarc 16MHz ale to nic nie zmieniło w temacie.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[BlackJack]

Tak z mojego doświadczenia z pająkami. Bardzo często szwankują, takie połączenia typu drutek <> złącze, i to zawiesza układ, lub powoduje dziwy.

Nie jest też dobrym pomysłem zasilać takie układy z USB, często podpięcie zwykłego zasilacza wtyczkowego 9-12V, rozwiązuje problemy. USB po prostu ma za małą wydajność prądową. Teoretycznie jest to 500mA, ale to tak naprawdę MAX, wydajność, jaką przewiduje standard USB, w rzeczywistości mało kiedy jest dobrze. Na niektórych USB, pisze wręcz wprost MAX 100mA.

Co do oprogramowania, dobrze sobie go tak zmodyfikować, aby czekając na odbiór danych, monitorować np. czas oczekiwania. Można to zrobić na Timerze, ale wystarczy, jakiś licznik liczący np, do 100 (jeżeli to oczywiście wystarcza), w pętli oczekiwania, na zakończenie odbioru. Jeżeli dojdziemy do tych 100, a transmisja się nie zakończyła to mamy błąd transmisji. wtedy wiemy że należy szukać błędu w sprzęcie, lub jego konfiguracji.

[Marooned]

Tak z mojego doświadczenia z pająkami. Bardzo często szwankują, takie połączenia typu drutek <> złącze, i to zawiesza układ, lub powoduje dziwy.

Generalnie się zgadza - ten pająk dość solidnie siedzi wpięty w piny KANDY. Testowałem rezystancję od pada na ESC do jakiegoś pina GND daleko na płytce - wyszło 0.8Ω

Nie jest też dobrym pomysłem zasilać takie układy z USB

Obecnie wszystko jest na zasilaczu laboratoryjnym. Wcześniej ESC było na zasilaczu, płytka miała prąd przez złącze USB, ale nie wpięte w kompa tylko w ładowarkę. Więc o wydolność prądową się nie martwię.

(...) wtedy wiemy że należy szukać błędu w sprzęcie, lub jego konfiguracji.

Widzisz.. problem w tym, że czasem coś przechodzi, czasem nie. Dlatego tak ciężko mi namierzyć problem, bo błędy są dość losowe.

[OldSkull]

Gdyby zawsze przesyłał coś źle, ale tak samo, to bym podejrzewał program, tak nie jestem pewny, moze być program jak i połączenia. Tego pierwszego nei chce mi się zagłębiać, za to drugie: możesz sprawdzić którędy biegnie połączenie masy? Sugerowałbym dodać gruby przewód masy i poskręcać go z sygnałowymi, a je same pospinać tak, aby nie było luźnych sygnałów. W tej chwili to wygląda jak układ do łapania zakłóceń 😉 Piszę z doświadczenia, bo wiem, że przy takich połączeniach zakłócenia są kłopotliwe. Warto też sprawdzić czy któryś przewód (szczególnie jeśli korzystasz z drutów a nie linek) nie jest pęknięty.

[Marooned]

Ok, wpiąłem taśmę bezpośrednio do gniazda. Czyli lecą teraz wszystkie sygnały włącznie z RST, ale to chyba nie przeszkadza.

Dorzuciłem w tej pętli czekającej na koniec transmisji 16-bitową liczbę, więc maksymalnie czeka 2^16 pętli i wychodzi. Dzięki temu nic mi nie wisi i daję szansę odpalić się reszcie kodu. Jeśli w odbiorniku pętla wyszła nie doczekawszy się poprawnej transmisji, dodaję "error" na wyświetlaczu za liczbą.

Co więcej, dla sprawdzenia czy odbieram śmieci czy nie i czy transmisja wisi czy nie, zmieniam co chwila wysyłaną liczbę (na razie przesyłam tylko bajt, w poprzednim kodzie słałem więcej).

SPI_MasterTransmit(alternate++ ? 123 : 69);

Po tuzinach zmian w programie, ruszaniu kabelkami i innych szamańskich ceregielach doszedłem do tego co następuje:

- po włączeniu zasilania dostaję prawidłową liczbę (123) + napis "error" (choć pierwsza powinna być 69)

- liczba ta wisi, czyli nie dostaję na zmianę 123 i 69

- jak zbliżę rękę do taśmy, to zaczynam dostawać losowe liczby z czego zdecydowana większość to 65535 (zmienna jest 16 bit, ale wpisuję do niej 8 bit, więc formalnie max powinno być 255) - dodatkowo "error" miga czyli tak jakby na zmianę wychodził z pętli wcześniej niż po 2^16 iteracji a raz dochodził do końca

Brakuje mi powoli pomysłów...

[Harnas]

A co jak rozłączysz załóżmy MISO? Spróbowałeś zmniejszyć częstotliwość na SCK załóżmy do 10 khz? Skoro prąd pull-upa ma takie znaczenie, to stawiałbym właśnie na problemy z pojemnością kabla.

[Marooned]

Hmm, z MISO odłączonym nie ma różnicy.

Zmieniłem też częstotliwość z f/16 na f/128 (największy dostępny preskaler).

Zmieniłem również to co nadaję:

SPI_MasterTransmit(alternate++&1 ? 234 : 69);

i... nadal po włączeniu mam 123 🤯 a dane odczytuję tylko przy dotknięciu taśmy.

Winiłbym całkowicie długość taśmy i zakłócenia gdyby nie fakt, że przez dokładnie tę samą taśmę programuję tego ESC i nie ma żadnych problemów...

[Harnas]

W sumie po MISO nic nie leci, bo dane są wysyłane po MOSI. Jak go odłączysz to co?. Ja bym jeszcze zmienił taktowanie mastera na wewnętrzny 128 khz, wywalił cały kod poza obsługą SPI, wysyłał cały czas ramkę 0xAA (binarnie 10101010 ) i ustawił prescaler SPI na 128. Do MOSI i SCK podepnij ledy.

Led na SCK powinien migać z częstotliwością 1 Hz (albo 0.5 Hz nie chce wnikać w dokumentacje) a MOSI 2 razy rzadziej.

Jeżeli tak będzie oznacza to że master działa ok.

Tak dla pewności, nie skrzyżowałeś przypadkiem MOSI z MISO?

[Marooned]

Nie, nie skrzyżowałem.

Tak jak wspomniałem w poprzednim poście, obecnie mam f/128, a więc (16Mhz/128) 125kHz.

Dlaczego piszesz, że przy 125kHz SCK będzie miało 1Hz? Czy te 125kHz to nie właśnie częstotliwość SCK (tak rozumiem datasheet)?

Wróciłem do pająka, ale solidnego. Dzięki temu mogę się wpinać w przewody. Dioda nie miga, na SCK cały czas mam stan wysoki (przynajmniej mierząc miernikiem, ale 125kHz to za szybko na pomiar DC). Oscyloskop też pokazuje raczej stałą wartość (z szumami), ale oscyloskop mam starszej daty i nie do końca mu wierzę, więc nie opierałbym się o to.

Zastanawia mnie to "123" po odpaleniu. Czy możliwe, że po odcięciu zasilania ta wartość zostaje na zatrzaskach i ESC nie wysyła tam nowszych danych nawet jak już przeprogramowałem i dałem inne wartości niż "123"? Bo nie wierzę w przypadek, że akurat szumowo-losowo dostałem liczbę, którą wysyłałem w poprzednich wersjach softu.

[Harnas]

Miałem na myśli taktowanie procesora na 128 khz. Teraz zauważyłem że się pomyliłem i zamiast 1Hz dostaniemy 1KHz. Wydaje mi się że na SCK powinna być połowa napięcia zasilania. Mamy tam przebieg o wypełnieniu 50%. Jeżeli wysyłasz 0xAA to na MOSI też powinna być połowa zasilania.

[Marooned]

Przyznam, że nie spotkałem się z informacją, że można taktować Atmegę niżej niż 1MHz. Jesteś pewny tych 128kHz?

Tak czy siak, chwilowo przerwa świąteczna oderwała mnie od dalszych prac, ale nie wróżę sobie sukcesów z tą komunikacją.

[OldSkull]

Przyznam, że nie spotkałem się z informacją, że można taktować Atmegę niżej niż 1MHz. Jesteś pewny tych 128kHz?

Dokumentacja podaje wykres poboru prądu w zależności od taktowania od 100kHz 🙂 Ale gdzieś czytałem nawet o taktowaniu kwarcem zegarkowym 32kHz 😃 Pozostaje tylko pytanie ile jeszcze można pójść w dół, np. do 4kHz? Jeśli by to działało to ultra niski pobor prądu stoi otworem 🙂