Witam wszystkich.
Jestem w trakcie "robienia" biblioteki do obsługi lcd. Wadą a zarazem i zaletą tego wyświetlacza jest 3-pinowa transmisja danych (CS,SDA,CLK)
AtMega posiada sprzętowy interfejs SPI ale 8-mio bitowy, a tutaj jest potrzebny jeszcze dziewiąty do opcji COMAND/DATA.
Moje programowe SPI wygląda tak:

Działa bezbłędnie ale chciałbym przyśpieszyć wysyłanie danych.
Czy można skonfigurować SPI sprzętowe aby dało się wysyłać dane w takim formacie jak w załączonym kodzie?
Ewentualnie jak można inaczej zrealizować kod aby wysyłanie było bardziej "sprzętowe" lub szybsze?

Powinieneś zajrzeć do mirkowego poradnika na temat magic ledów, gdzie były opisywane, dodatkowe optymalizacje kodu dla transmisji szeregowych.
W skrócie musisz rozwinąć pętlę "for" do pojedynczych instrukcji, zyskasz wtedy na czasie, ale stracisz na objętości kodu w pamięci flash.

Zrobiłem tak:

Troszkę pomogło i jest ciut szybciej. Ale to jeszcze za mało.

Kolego a czy nie mylisz przypadkiem magistrali SPI z i2C? w Atmega masz śliczne i2c gotowe do śmigania.

_________________
SP2LUB - LA1BUA

Myślę, że Kolega nic nie myli, ale dowiemy się gdy sam się wypowie:)
SDA - to Serial Data
CS - Chip Select
CLK - Clock

SDA to prawdopodobnie zbieżność nazw z TWI.
A reszta nazw to klasyka dla transmisji szeregowej, w szerokim rozumieniu.

W datasheet jest napisane: 3-pin 9 bits Serial Peripheral Interface (SPI)
Nazwy nadałem sam. Tak jak Zealota napisał SDA - Serial Data etc.

Ok ja tam sie nie znam, ale w magistrali SPI widzę MOSI i MISO natomiast nazwy linii które podajesz są charakterystyczne dla I2C. Tak samo wyświetlacz LCD który chcesz sterować jest zrobiony pewnie dla magistrali I2C.
Jak mówię ja się nie znam i początkujący jestem, ale SPI to SPI a I2C to I2C po coś te nazwy wprowadzono i łatwiej się poroznmiewać używając takich określeń. Tym bardziej że Atmega ma rozwiązania sprzętowe zarówno dla SPI jak i I2C więc nic tylko odpalać i śmigać.

_________________
SP2LUB - LA1BUA

Tutaj MOSI i MISO jest na linii DATA. Jest dwukierunkowa. Tak jak w I2C ale nie adresujesz układu tylko wybierasz poprzez LOW na CS.
9-ty bit transmisji ustala czy nadajesz komendę(LOW) czy dane(HIGH), tzn. następne 8 bitów
Jak widać a załączonym wcześniej obrazku z datasheet, piny również mają nazwy CSX, SCL i SDA...

Zdradź może o jaki sterownik LCD chodzi.

Napisałem sterownik dla SPFD54124. Działa ale chciałbym szybciej. No i tu jest 128x160 pixeli a myślę o większym troszkę i wtedy będzie jeszcze wolniej...

To może powinieneś troszkę inaczej podejść do tej transmisji.
Zrobić sobie bufor obrazu w którym od razu na poszczególnych bitach
ustalasz co tam jest czyli dane przeplatasz tym bitem data. Wiem to
komplikuje obliczanie pozycji.
A potem jednym ciągiem wyrzucasz cały bufor na wyświetlacz korzystając
ze sprzętowego I2C czy TWI to już wsio ryba.

_________________
Jestem początkujący i moje porady mogą być błędne

Właśnie oglądam Magic Ledy p.Mirka i zaczynam mieć zarys pomysłu. Zajefajny poradnik i chyba sobie zafunduję książkę.
Natomiast bufor musiałby mieć 128*160*3 bajty to 61 440 bajtów..
Aczkolwiek można by wykorzystać Partial Area i buforować tylko potrzebny fragment.
Jeszcze raczkuję w C i AVR więc chętnie posłucham wszystkich którzy maja jakiś pomysł realizacji.

Hmm a może taki "chytry sposób:
Dzielisz paczki na 8 bitowe. Każdy 9 bit jest bez znaczenia. Chodzi mi oczywiście o LSB.
Tworzysz więc 3 bajty, które wysyłasz po SPI sprzętowym, gdzie MSB jest oczywiście pierwszym wysłanym "bitem" dla każdej bajtu..
Pomiędzy każdy bajt, wysłany sprzętowo, "wrzucasz" jedno "tyknięcie" zegara, po to by sterownik będący cały czas w CS = low, tylko "odhaczył, ten 9 nic nie znaczący bit.
To 9 tyknięcie zegara należy dobrać czasowo tak by było zgodne z dokumentacją.
Prawdopodobnie wystarczy rzucić dwie komendy CLK_HI i CLK_LO, nawet bez dodatkowego opóźnienia i zbocze narastające "zaliczy" ostatni bit.
Oczywiście bajty z konkretnymi danymi w słowach 8 bitowych należy poprzestawiać przesunięciem bitowym.



Powyższy kod to taki niedoskonały zarys, ale mam nadzieję, że wiadomo o co chodzi.
Samo SPI w AVR po każdym wysłanym bajcie zatrzymuje zegar.
Dodatkowo należy oczywiście parametry dobrze ustawić CPOL, CPHA DORD i co tam jeszcze trzeba.

bity idą od Msb czyli od D8 do D0, Pierwszy ustawiony na 'H' sygnalizuje że nadaję dane a na' L' że nadaję komendę. Nie da się go pominąć. Ustawiam CS na 'L'
Nadaję komendę a potem może być od zera do kilkudziesięciu danych nawet. Czyli pierwszy bit przesyłany na' L' i 8 bitów komendy potem bit danych 'H' i 8 bitów danych, bit 'H' i następne 8 bitów danych i następne... itd.. ewentualnie następny stan 'L' i 8 bitów nowej komendy i 'H' i 8 bit danych...

"Kto szuka ten błądzi"?
W poście #8 z tego linku po drobnych przeróbkach masz kod, który powinien załatwić Twój problem (mix of bit-bang and hardware SPI):
http://www.avrfreaks.net/forum/9-bit-spi

Hmm chyba nie zrozumieliśmy się . Mi chodziło, że tę "drugą stronę" pomijamy Najpierw idzie MSB, czyli znacznik komendy albo danych i to oczywiście zostawiamy i po kolei następne bity, aż dochodzi do dwóch ostatnich, które nie mają znaczenia, a ostatni z nich, czyli LSB "nadajemy" poprzez to dodatkowe, softwarowe "tyknięcie".
Tutaj nie ma znaczenia czy L czy H bo sterownik to pomija.
Należy pamiętać, ze w HW SPI mozemy sobie ustawi czy LSB czy MSB ma iść pierwszy, oczywiście w tym wypadku MSB (nie ustawiamy bitu DORD)
Zrobiłem dodatkowe testy, zmodyfikowałem kod:

Okazuje się, że SPI musi być wyłączone, gdy chcemy sobie "tyknąć" softwarowo zegarem.
Wrzuciłem na atmege328p kod i z zrobiłem screeny z analizatora stanów:





Popatrz jak ładnie widać te 9 tyknięcie, jest nieco węższe, ale można regulować instrukcją nop.
Drugi obrazek to już prędkość 4MHz, oczywiście samego zegara SPI.

Oczywiście mogłem popełnić jakiś błąd myślowy, nie będę się upierał , ale na razie wychodzi mi, że to może działać.

------------------------ [ Dodano po: 1 minucie ]



Hehe, wydaje się, że właśnie chyba o tym pisałem w tych moich "wywodach"

O tym samym myślałem,ale komendy wykorzystują całe 9 bitów a i data tylko w przypadku kolorów wykorzystuje 3 x 6 (18 bit color) a inne też całe 9 bitów.
Więc samym zegarem tego nie przeskoczę. Myślę że może wstawka assemblerowa by lepiej zadziałała ale jeszcze jestem zbyt "zielony" w te klocki.

Jeśli chodzi o komendy i ostatni fragment z dokumentacji wydaje mi się że to nic nie zmienia w implementacji pomysłu.
Jest tylko jedna różnica, najpierw należy "wrzucić" nadmiarowy, dziewiąty bit (C/D) oczywiście w zależności czy 0 czy 1 ustawić wyjście MOSI, pamiętając o wyłączeniu sprzętowego SPI na ten czas. Następnie włączyć SPI i podać 8 kolejnych bitów.



Patrząc pobieżnie na ten sterownik i jego dokumentację wydaje się, ze sposób jego sterowania jest bardzo podobny do innych sterowników, nawet tych prostszych, jak popularne oledowe SSD1306.


Zajrzyj może na mirkowe poradniki o SSD1306. Przydałby Ci się również greenbook, bo tam był sposób programowania wyświetlaczy graficznych.

Zabrałem się za napisanie tego w asm. Za przykład
Biorę wstawkę z poradnika o magic ledach.
Ale tam jest błąd chyba i zamiast jednego pinu
Zmienia sie cały port. Brak operacji or i and przed sts.
Aczkolwiek mogę się mylić bo dopiero raczkuje.
Jak ktoś się zna to niech mnie poprawi będę miał dodatkową wiedzę.
Zamówiłem dziś analizator stanów to będę mógł
sprawdzić tą wstawkę i dopracować kod czasowo.

Wypociłem dziś taki kod:

kompiluje się ,mikroprocesor pracuje ale na wyświetlaczu nic się nie dzieje.
Jakie błędy popełniłem?
Ps wyciąłem wszystkie "nopy" z kodu żeby był czytelniejszy.

Po walce z asemblerem udało mi się stworzyć działający kod ale wyszło jakoś wolno. Za cienki w uszach widać jeszcze jestem.
Zmontowałem więc kod w c++ i nawet udało mi się osiągnąć coś koło 2Mhz zegara.
Może komuś się przyda

Tak to wygląda w analizatorze który niedawno mi dostarczono (zajefajna rzecz, polecam)

Spróbuję w wolnej chwili powalczyć z kodem od Zealota.
Dzięki wszystkim za pomoc i zainteresowanie.
Pozdrawiam

Wałkuję ten sam temat w kontekście sterownika do LCD od Nokii 1202. Sposób z AVR Freaks działa (mix HW SPI i bit-banging), ale zastanawiam się czy próbowaliście przesłać np. 2 bajty przez SPI w taki sposób:



Najstarsze bity hi_byte zostaną przepchnięte i "wylecą" - zostanie tylko jeden bit określający DATA/COMMAND. Sterownik zinterpretuje tylko ten jeden bit i cały lo_byte. Machnięcie linią CS powinno zatrzasnąć te 9-bitów w rejestrze sterownika. Dobrze kombinuję?

Poniżej fragment noty do STE2007, który sugerowałby taki mechanizm:

Eh... Niestety. Po transferze 8 bitów na linii MOSI jest dodatkowe zbocze po zboczu zatrzaskującym na SCK, czyli występuje pierwszy warunek transferu do sterownika. Klapnięcie linią CS nic już wtedy nie wnosi - czyli zostaje mix SW i HW.

Witajcie,

Poniższa koncepcja działa dla wyświetlacza.

Jeżeli mam wysłać 9 bitów a mam sprzętowo 8 bitów, to wysyłając kolejno 9 bajtów mam wysłane 8 tych 9-cio bitowych.
Nie trzeba się martwić o to, że jedno 9cio bitowe słowo jest zawsze w dwóch kolejnych transmisjach.

Jedyne co jest ważne, to
- trzymać cały czas linię CS aktywną
- zakończyć transmisję po przesłaniu wielokrotności paczek po 9 bajtów.

Jak brakuje danych do wysłania żeby zakończyć na wielokrotności 9 bajtów to podpowiadam, że mamy instrukcję NOP i można ich wstawić dowolnie dużo.

Poniżej obrazek jak to wygląda w praktyce. Dekodowane jest 9 bitowe SPI.

Andrzej