Moduł zintegrowano z istniejącym już projektem procesora, stworzonym w ramach innych prac magisterskich, przez innych studentów.

Znaczną część pracy poświęciłem nie tylko na tworzenie predyktora, ale na analizę i naprawę projektu procesora RISC‑V, gdyż okazał się on być pełny błędów oraz niezgodności z dostarczoną dokumentacją.

Oprócz samego predyktora, stworzone zostało rozbudowane środowisko testowe, pozwalające na w pełni zautomatyzowaną kompilację programów, uruchamianie symulacji oraz tworzenie raportów. Na środowisko składają się skrypty (napisane w języku JavaScript) oraz plik Makefile, pozwalający na wybór konfiguracji, z jakim wariantem predyktora należy skompilować projekt, oraz który z programów testowych uruchomić.

Dodatkowo, stworzono wizualizator sygnałów wewnętrznych procesora, prezentujący za pomocą pliku HTML wgląd do jego działania, z podziałem na cykle oraz etapy pipeline'u.

Bardziej rozbudowany opis struktury projektu, oraz jak można go uruchomić, znajduje się na GitHub'owym readme.

Gra Master Mind polega na odgadnięciu pewnej sekwencji kolorów (ustawionej losowo przez urządzenie lub przez innego gracza). Wraz z każdą próbą odgadnięcia, urządzenie wyznacza i wyświetla podpowiedzi, co do tego ile kolorów jest poprawnych, i ile z nich jest na poprawnej pozycji.

Grę stworzono w całości w języku opisu sprzętu SystemVerilog. Takie podejście wymaga innego myślenia, niż jak w przypadku zwyczajnego języka programowania (jak np. C++). Ponieważ całą logikę zaprojektowano sprzętowo (na hardware'że), nie można było po prostu zdefiniować sekwencji instrukcji do wykonania - nie ma procesora, który by je wykonywał. Dane przetwarzane są w sposób znacznie bardziej współbieżny, niż gdyby zastosowano CPU, co wymagało trochę kreatywności, szczególnie przy implementacji logiki wyliczającej podpowiedzi.

Zaprojektowany układ wyświetla obraz gry na monitorze z interfejsem VGA i/lub HDMI. Sterowanie odbywa się poprzez przyciski obecne na osobnej płytce stykowej podłączonej do urządzenia. Projekt wyposażony jest również w głośnik, potrafiący odtwarzać proste melodie. Użytkownik jest w stanie konfigurować wiele parametrów gry, takich jak ilość dostępnych kolorów, rozmiar planszy oraz liczba dozwolonych prób odgadnięcia ukrytej sekwencji. Możliwe jest też ustawienie rozmiaru czcionki wyświetlanej na ekranie oraz palety barw, jaka jest wykorzystywana do rysowania wielu elementów.

Stanowisko składa się z:

• Robota ASTORINO
• ESP8266 (do łączenia robota z innymi komponentami)
• Interfejsu sterowania przez HTTP (na RaspberryPi)
• Struktura magazynowa z profili aluminiowych
• Zbiór wielokolorowych elementów drukowanych w technologii 3D (podstawki i nakrętki)
• Mały stół obrotowy, sterowany przez PLC
• Zbiór czujników (kamera, odległości, siły i indukcyjny)

Stanowisko działa w następujący sposób: Użytkownik tworzy żądanie za pośrednictwem interfejsu HTTP, aby wyprodukować element z częściami o 2 określonych kolorach. Następnie robot chwyta części z odpowiednich szyn i sprawdza je za pomocą czujnika odległości. Części są umieszczane na stole obrotowym, a ich kolor jest sprawdzany przez kamerę. Robot skręca ze sobą obie części, a następnie odkłada cały element na szynę wyjściową (lub wyrzuca części do kosza, jeśli kontrola czujnikami była negatywna).

Przez cały proces użytkownik może podglądać stan wszystkich czujników i sygnałów wewnętrznych poprzez interfejs HTTP.

Robot komunikuje się z ESP za pośrednictwem portów wejściowych i wyjściowych ogólnego przeznaczenia. Ponieważ ESP ma ich zbyt mało, aby w pełni zaimplementować podgląd stanu i niezawodną komunikację, konieczne było użycie dodatkowych rozszerzeń portów, na magistrali I2C. Komunikacja odbywa się za pośrednictwem customowego protokołu handshake. Robot ma wstępnie zakodowany zestaw możliwych akcji, które są wysyłane szeregowo z ESP.

Komunikacja z innymi komponentami (RaspberryPi i kamera) odbywa się za pośrednictwem protokołu MQTT przez WiFi. RaspberryPi działa jako broker MQTT. PLC sterujący stołem obrotowym musiał być kontrolowany za pośrednictwem ModbusTCP.

Robot ASTORINO używany w projekcie był wciąż w fazie rozwoju alfa. Spowodowało to, że wiele rzeczy cały czas się psuło. Na przykład, najbardziej "zabawną” rzeczą, na jaką się natknęliśmy, był robot odczytujący pin wejściowy jako odwrotność jego rzeczywistego stanu, raz na około 10000 poll-ów, co doprowadziło do niespodziewanego uderzenia w stół :).

Oryginalna aplikacja w MS Access była pełna makr, co uniemożliwiało jej prosty import do nowszej wersji Access'a, i musiała być uruchamiana na maszynie wirtualnej Windows XP, ogólnie będąc nieporęczna w użyciu.
Postanowiłem zbudować nową aplikację od podstaw. Pozwoliło to na znacznie łatwiejsze dodawanie nowych niestandardowych funkcji, niż gdybym miał używać innego programu podobnego do Access'a. Skorzystałem z bazę danych SQLite jako backend'u.

Aplikacja została stworzona przy użyciu framework'a Tauri. Tauri pozwala na korzystanie z wbudowanego w system operacyjny WebViewAPI, co umożliwia mojej aplikacji korzystanie ze wszystkich funkcji przeglądarki internetowej (przede wszystkim HTML, CSS i JS dla interfejsu graficznego), bez dołączania całego runtime'u NodeJS, jak w przypadku framework'a Electron.

Backend Tauri został napisany w Rust. Interfejsowanie się z SQLite i zarządzanie plikami jest obsługiwane przez Rust. Interfejs użytkownika jest tworzony przy użyciu framework'a Vue. Użytkownik może dodawać i edytować klientów, zarejestrowane samochody, części samochodowe i zamówienia. Może również filtrować widoki na podstawie wielu parametrów. Dla każdego zamówienia można automatycznie wygenerować i wydrukować fakturę w formacie PDF.

Jako dodatkowe zabezpieczenie, moja aplikacja może importować i eksportować swój bieżący stan do/z oryginalnej aplikacji MS Access, z pośrednim użyciem plików CSV. Utworzyłem również kilka skryptów w NodeJS, które pomagają z konwersją oryginalnej struktury bazy danych MS Access na strukturę SQLite. Aplikacja wykonuje również regularne konfigurowalne kopie zapasowe bazy danych.