rafal2808

Początkowo myślałem, że przejściówka oparta jest na konkretnym, wyspecjalizowanym układzie, który obsługuje LCD. Dlatego nie rozumiałem danych pojawiających się na magistrali. Jednak okazało się, że zastosowano tam uniwersalny PCF8574, posiadający osiem wyjść podłączonych pod LCD. Teraz gdy dokładnie sprawdziłem połączenia między układem a LCD, wiem już, że wszystko działa w bardzo prosty sposób, poprzez przesyłanie komend i danych w 4-bitowym trybie.

No cóż wystarczyło dobrze się przyjrzeć nocie katalogowej układu z przejściówki (I2C to LCD) i wszystko się wyjaśniło.

Cześć, Z ciekawości postanowiłem podejrzeć protokół transmisji I2C między Arduino a wyświetlaczem LCD i mam w związku z tym pewne pytanie. Polecenie wysłania znaku "A" to w rzeczywistości przesłanie kolejno bajtów 0x49, 0x4D, 0x49, 0x19, 0x1D, 0x19, jednak co one w zasadzie oznaczają? Posiada ktoś może informację o znaczeniu poszczególnych bajtów danych w transmisji I2C? #include <LiquidCrystal_I2C.h> LiquidCrystal_I2C lcd(0x27,16,2); // set the LCD address to 0x27 for a 16 chars and 2 line display void setup() { lcd.init(); lcd.backlight(); delay(100); lcd.print("A"); } void loop() {}

Update: Wykonałem test na innym komputerze z windowsem 7 i wszystko działa poprawnie. Możliwe, że przyczyną błędu na moim głównym komputerze jest zainstalowany tam windows 10, który z jakiegoś powodu nie lubi się z programem DFU Tool, próbowałem uruchamiania w trybie zgodności, ale niestety to nie pomaga. Cóż na razie pozostaje tylko przenoszenie plików między komputerami.

Cześć, Ostatnio postanowiłem pobawić się płytką GD32 RISC-V, ale niestety napotkałem pewien problem. Po uruchomieniu narzędzia do konfiguracji "GigaDevice Dfu Tool" wyświetla się komunikat "Set option byte address failed" i po chwili program się zamyka. Dodam, że płytka jest poprawnie wykrywana przez system. Czy ktoś spotkał się może z takim problemem i wie jak go rozwiązać?

Pisząc, że edytor kodu nie startował miałem na myśli, że pojawia się początkowe małe okienko i to tyle. program nie uruchamiał się. Również się zdziwiłem bo wiem, że biblioteki przechowywane są w innym miejscu, ale u mnie po usunięciu folderu Arduino15 wszystko zniknęło, tak jakby zainstalować arduino od nowa.

Cześć, Wiem, że temat sprzed ponad roku, ale udało mi się go rozwiązać. Identyczny problem wystąpił dzisiaj u mnie Arduino IDE startuje, ale edytor kodu nie włącza się. Po przekopaniu internetu natknąłem się na informację, że pomóc może usunięcie folderu Arduino15 zlokalizowanego w katalogu C:\Users\nazwa_użytkownika\AppData\Local. Co ciekawe po usunięciu folderu program uruchamia się już poprawnie. Warto jednak wiedzieć, że po takim zabiegu tracimy wszystkie zainstalowane biblioteki oraz dodane płytki, mamy po prostu czystą wersję Arduino IDE.

@neurotic Na pewno zmniejszasz Clk, a nie przypadkiem LICZNIK_LIMIT?

Oczywiście tego typu projekty są bardzo ciekawe, jednak tym razem chciałbym zaprojektować coś swojego. Nawet jeśli będzie to obarczone wieloma błędami, a bądźmy szczerzy będzie, to mimo wszystko dla mnie osobiście proces rozwiązywania tych problemów jest jak najbardziej przyjemny. Miałem tutaj na myśli iż układ posiadał będzie dedykowane bloki oraz rejestry odpowiedzialne za obsługę tych interfejsów. Przy okazji uświadomiłem sobie że trafniejszym określeniem mojego projektu będzie mikrokontroler, nie procesor. Tak prezentuje się poprawiona architektura projektowanego przeze mnie układu. Nie różni się ona znacząco od schematów udostępnianych wcześniej. Różnice są raczej kosmetyczne, według mnie najważniejszą z nich jest dodanie "obejścia ALU" umożliwiającego łatwiejsze przesyłanie danych. Dodatkowo muszę wspomnieć, że układ z założenia projektowany jest według architektury Harwardzkiej. Dlaczego nie von Neumanna, po prostu nie podoba mi się koncepcja przechowywania programu i danych w tej samej pamięci. Układ nie będzie posiadał jako takiej przestrzeni adresowej. Jedyne adresy występujące w układzie to te dla pamięci ROM generowane przez licznik adresów oraz dla RAM, które stają się adresami dopiero po wpisaniu do rejestru ARR, wcześniej jest to po po prostu zwykła zmienna.

Po otrzymaniu rad od @FlyingDutch oraz @marek1707 postanowiłem zmienić nieco założenia całego projektu. Project A będzie 8-bitowym procesorem zrealizowanym na układzie FPGA, początkowo planowałem umieścić go na płytce Elbert v2 jednak w międzyczasie udało mi się zdobyć płytkę Core3S500E na której umieszczono chip FPGA dysponujący zasobami większymi niż ten umieszczony na Elbert v2. Tak więc Project A będzie bazować Core3S500E. Modułowa budowa procesora w stylu podobnym jak np.Nios II na razie odpada, a bardziej przerasta moje możliwości. Architektura również uległa pewnym zmianą, postaram się udostępnić ją w najbliższym czasie. Planuję wprowadzić cztery tryby adresowania: natychmiastowy, rejestrowy, bezpośredni oraz pośredni. Ułatwią one znacznie programowanie procesora. Układ wspierać będzie interfejsy UART i I2C, oraz obsługa wyświetlaczy LCD i 7 segm. Na początek planuję zaprojektować bardzo prosty układ przerwań wspierający tylko jedno maskowalne przerwanie zewnętrzne. Po jego otrzymaniu procesor zapisywał będzie tylko adres powrotu. Stan innych rejestrów będzie w pełni zależny od programisty. Ich zawartość można będzie odłożyć na stosie, którego obsługa również zostanie dodana. Procesor posiadać będzie dodatkowe 8 rejestrów ogólnego przeznaczenia, nie będą one jednak osobną strukturą a wydzielonym obszarem pamięci RAM. Programowanie odbywać się będzie podobnie jak w moich wcześniejszych projektach poprzez określenie zawartości pamięci w pliku VHDL. Wiem że są to dość szczątkowe informacje na temat mojego procesora, ale chciałem dać znać że Project A nie został zapomniany.

Na ten moment komunikacja z rejestrami realizowana jest właśnie za pomocą osobnych instrukcji. Myślę że w przyszłych projektach wszystko realizowane będzie właśnie na zasadzie większych bloków a komunikacja zostanie ujednolicona. W mojej wizji rejestr A pełni funkcję czegoś na wzór rejestru wejściowego. Dane na początek zapisywane są tam dopiero później rozsyłane są dalej. W taki sam sposób przesyłany jest rozkaz dla ALU zapisywany docelowo w rejestrze C. Jako iż wszystko działa w sposób wspomniany wyżej nie mamy możliwości zmiany zawartości rejestru poprzez jeden rozkaz. Należy wprowadzić odpowiedni rozkaz dla ALU a następnie wynik zapisać w docelowym rejestrze. Procesor jest 8 bitowy. Pamięć ROM posiada strukturę 2048x16 natomiast RAM 256x8. Raczej kluczowa jest zajętość FPGA. Układ na płytce Elbert v2 nie dysponuje dużą ilością zasobów, a przy syntezie prostszego projektu tak wygląda ich zużycie. Co do układu przerwań to będę eksperymentował. Na początek myślę że zaprojektuje coś prostego na zasadzie wystąpi przerwanie->skok do podprogramu->powrót. Na razie świadomie rezygnuje z zabezpieczenia się przed sytuacjami typu w trakcie obsługi przerwania wystąpi kolejne. Adresowanie bezpośrednie, listę instrukcji umieszczę wkrótce. Na razie funkcji zatrzymania CPU nie planuję. BTW: Uwaga co do przerwań jak najbardziej słuszna.

Porządki w projekcie, ciąg dalszy Można powiedzieć że, zaczynam od początku. Projekt zyskał całkowicie nową architekturę, jest to ulepszona wersja pierwotnego pomysłu. Najważniejszym elementem jest dodanie obsługi przerwań zewnętrznych jak i wewnętrznych. Do tej pory żaden realizowany przeze mnie projekt procesora nie posiadał tej funkcji. Sama forma pracy nad projektem również ulegnie pewnej zmianie. Z czasem pojawiać się będą wpisy (facebook+blog+forbot) informujące o zakończeniu etapu projektowania poszczególnych elementów. Dotychczas informowałem raczej o ukończeniu, czy zaktualizowaniu całego projektu, nie jego konkretnych elementów. Dodatkowo nazwa procesora również ulega zmianie od teraz będzie to "Project A". Tak prezentuje się architektura procesora. Każdy z bloków możemy przypisać do jednej z czterech kategorii. Kolorem żółtym zaznaczone zostały wszystkie rejestry, czerwonym bloki pamięci (RAM, ROM), niebieskim multipleksery. Na zielono zaznaczone zostały bloki, które możemy określić jako te najbardziej zaawansowane takie jak ALU, dekoder instrukcji czy kontroler wyświetlaczy 7 segmentowych. Blok kryjący się pod tajemniczą nazwą "LOGIC" jest najprościej mówiąc głównym elementem układu sterowania. To tutaj na podstawie instrukcji, zegara oraz kilku pomniejszych sygnałów określających stan procesora generowane są wszystkie sygnały sterujące dla innych bloków. Najważniejszą z nowości jest dodanie układu przerwań. Na początek obsługiwane będą trzy typy przerwań. Dwa z nich będą aktywowane w momencie wysłania lub odbioru znaku poprzez interfejs UART, trzecim natomiast będzie sygnał zewnętrzny (np. przycisk). Oczywiście dzięki rejestrowi ICR (interrupt control register) możliwe będzie wyłączenie dowolnego z przerwań. Fizycznie projekt zrealizowany zostanie na dobrze już znanej płytce Elbert v2. Oczywiście założenie iż wszystko zrealizowane ma być tylko na tej płytce pozostaje nadal aktualne. Ciąg dalszy nastąpi... Jeśli ktoś zainteresowany jest tym czy innym z moich projektów zapraszam na prowadzoną przeze mnie stronę na facebooku, gdyż to właśnie tam w pierwszej kolejności pojawiają się najnowsze informację.

Po dość sporej przerwie wracam do projektu, miała ona również swoje plusy, ponieważ udało mi się spojrzeć na całość z nieco innej perspektywy. Wracając do poprzednich wpisów, plany implementacji obsługi kolejnych interfejsów oraz obsługi wyświetlaczy 7 segmentowych zostają. Jednak rezygnuję z wyświetlacza LCD oraz zewnętrznej pamięci RAM. Powodem tego jest początkowe założenie projektu, w czasie jego trwania nieco zapomniane. Cały system ma być ograniczony tylko do płytki Elbert v2. Ewentualne zewnętrzne dodatki nie powinny być wymagane do poprawnego uruchomienia projektu. Jak sama nazwa wskazuje mają to być tylko dodatki. Pojawiła się kolejna wersja projektu DCEQ818 z nieco zoptymalizowanym kodem procesora, dodatkowo sam opis również został zaktualizowany.

@Treker W przyszłości na pewno pojawi się obsługa kolejnych interfejsów takich jak SPI, I2C itd. Dodatkowo planuję też wprowadzenie obsługi wyświetlacza LCD oraz 7-segmentowego. Poważnie też myślę nad dodaniem zewnętrznej pamięci RAM. Można by wówczas zrezygnować z implementowania jej na strukturze FPGA i zwiększyć pojemność pamięci ROM, ale to temat na dalszą przyszłość. Oczywiście cały czas staram się pracować nad projektem i metodą małych kroków zwiększać jego funkcjonalność.

Zapraszam do zapoznania się z zaktualizowaną wersją opisu procesora Q818. Pojawiła się już dość spora sekcja poświęcona architekturze układu oraz blokom tworzącym procesor.