Podczas tworzenia oprogramowania dla systemu embedded wiele rzeczy może pójść nie tak, płytka może się zawiesić albo system plików może się uszkodzić. W takich okolicznościach zawsze istnieje ryzyko utraty kodu źródłowego, jeśli znajduje się on jedynie na docelowej platformie. Aby uniknąć takiego problemu, zalecane jest przechowywnie plików źródłowych na jakimś zewnetrznym komputerze (np. laptopie). Nie jest specjalnie istotne jaki system operacyjny będzie miał ten komputer, ma umożliwiać łatwą edycję plików źródłowych, kontrolę wersji oraz udostępnić usługę montowania katalogu plików dla Raspberry-Pi.
Jeśli ten komputer będzie pracował pod Linuxem, NFS może być użyty do montowania. Jeśli będzie pod Windows, to można użyć systemu plików CIFS. Skupmy się na Windows, ponieważ jest to przykład współpracy dwóch różnych systemów.
Uzyskanie podłączenia katalogu pod Windows wymaga nastepujących kroków:

1. utworzenie użytkownika przeznaczonego do dostępu zdalnego (np. pi_user),
2. utworzenie katalogu, który będzie udostepniany (shared),
3. ustawienie odwpowiednich praw dostępu do tego folderu dla nowego użytkownika (pełne prawa do tego folderu),
4. właczenie i konfiguracja współdzielenia folderu (nazwa folderu, np. shared-rpi),
5. sprawdzenie adresu IP komputera hosta.

i na Raspberry-pi:

1. utworzenie folderu gdzie będzie podmontowywany zdalny katalog (np. ~/vc4/shared-rpi),
2. utworzenie skryptu montującego jeśli chce się go montować ręcznie (jeśli ma byc montowany automatycznie, to nalezy dodać stosowna linięif w fstab)
   np. mount-win.sh,
3. dodanie praw wykonywania do skryptu
4. dodanie użytkownika pi do sudoers

Poniżej przedstawiony jest przykład skryptu montującego, który montuje zdalny folder windows z komputera o adresie IP 192.168.0.6. Katalog jest montowany w folderze domowym użytkownika pi z odpowiednimi prawami dla tego użytkownika.

#!/bin/bash

mount -t cifs -o rw,user=pi_user,uid=pi,gid=pi //192.168.0.6/shared-rpi /home/pi/vc4/shared-rpi

W celu zamontowania folderu należy uruchomić skrypt i wpisać hasło użytkownika z systemu windows. Następnie, można przejść do zamontowanego katalogu i sprawdzić czy widoczne są w nim pliki oraz czy można tam zapisać plik.

pi@raspberrypi:~ $ sudo ./mount-win.sh
Password for smb_access@//192.168.0.6/shared-rpi:  *********
pi@raspberrypi:~ $ cd vc4/shared-rpi
pi@raspberrypi:~/vc4/shared-rpi $ ls

   { tu powinny być wylistowane pliki które są w katalogu pod Windows }

pi@raspberrypi:~/vc4/shared-rpi $ echo "123" > test.txt

   { a teraz, można sprawdzić czy plik test.txt pojawił się pod Windows i zawiera 123 }

Zrzut rejestrów może być zaimplementowany jako minimalne makro, stąd łatwo jest wstawić go w dowolne miejsce w programie QPU. Jeśli będzie potrzebne sprawdzenie zawartości rejestrów po jakiejś instrukcji, to makro można wpisać w odpowiedniej linii w kodzie źródłowym.

Kiedy spojrzy się na implementację makra wywołania, to wygląda ono jak poniżej.

Główny kod używa dwóch makr wspomagających do zrzutu zestawu rejestrów (dump_regs) oraz and zapisu z pamięci VPM do SDRAM (store_dump). Wykonują one również niezbędne oczekiwanie na zakończenie transferu danych. Pełny kod źródłowy jest dostępny do pobrania jako część przykładowego projektu dla QPU (zobacz poniżej) - plik qasm/breakpoint.qinc.

Kod makra (_breakpoint) zapisuje zrzucane rejestry (zestaw rejestrów oraz akumulatory) do pamięci VPM (Vertex Pipe Memory) a potem przepisuje to do pamięci współdzielonej z CPU. Adresy buforów są przekazywane przez tabelę uniforms i zapamiętywane w dwóch rejestrach z zestawu, ukrywanymi pod nazwami symbolicznymi: dbg_rfile_dump and dbg_accus_dump. Po wykonaniu niezbędnych zapisów makro zakończy program QPU, więc oczekujący program CPU zostanie zwolniony i może wypisać zawartość buforów w czytelnej formie. Przykład takiego loga jest przedstawiony poniżej:

UWAGA
Powyższy zrzut jest wykonany dla jednego rdzenia QPU. Sklada się on z 2 części: treści akumulatorów oraz zestawu rejestrów (zestaw rejestrów rb jest widoczny tylko w części na tym rysunku). Każdy rejestr jest wypisany poziomo, z kolejnymi 16-ma elementami wektora SIMD od lewej do prawej. Akumulatory są wypisane dwukrotnie, raz jako zmiennoprzecinkowe, a drugi raz jako 32-bitowe liczby całkowite szestnastkowe. Akumulatory specjalne r4 i r5 są pominięte. Dla każdego rejestru z zestawu jego format i nazwa symboliczna jest definiowana w aplikacji.

W tym przypadku, podejście przyrostowe do programowania oznacza, że zaczyna się od programu dla jednego QPU, który przetwarza małą cześć danych, a następnie skaluje ten program na wiele rdzeni oraz duzy zestaw danych.
W pierwszej fazie można skupic się na tworzeniu programu w asemblerze i sprawdzaniu specyficznego zachowania procesora QPU. Jeśli jest to pierwszy program, który się tworzy dla QPU, z pewnością okaże się, że niektóre instrukcje działają inaczej niż się tego spodziewało. 'Odkryje' się też, że pewne kombinacje argumentów są niedopuszczalne, więc instrukcje nie są aż tak elastyczne jakby się mogło wydawać. W programowaniu QPU, są też pewne zależności pomiędzy kolejnymi instrukcjami, których trzeba przestrzegać, bo w przeciwnym przypadku wynik będzie niewłaściwy (np. zapis do rejestru zestawu nie jest jeszcze dostępny w następnej instrukcji).
To jest oczywiście faza debugowania, kiedy koryguje się program. Nie będzie to zbytnio klopotliwe, jeśli korzysta się ze zrzutu rejestrów. Kod może być w tym momencie również poddany optymalizacji, szczególnie poprzez użycie dwubieżności ALU.
W kolejnej fazie można dodać pętlę, która przetwarza następne paczki danych. Makro do zrzutu rejestrów kończy program, więc nie jest zbyt dobre do badania zachowania pętli. Niemniej jednak możliwe jest obejście tej niedogodności. Można wykonać skopiowac treść pętli, więc będzie wtedy pierwsza i druga iteracja w osobnych miejscach kodu. W ten sposób możliwe stanie się sprawdzenie zachowania pętli (tzn. sprawdzenie czy zmienne pętli sa własciwie modyfikowane z jednej iteracji na drugą).
Kolejny etap jest rtudniejszy, trzeba przejść jednego QPU na wiele. Można zacząć od programu na dwa QPU a kiedy będzie działać rozszerzyć na więcej QPU. Trzeba pamięteć, że powinno się mieć jeden program dla wielu QPU, moga być jego wersje ale kod powinien być jeden - rozmiar pamięci cache dla instrukcji QPU jest dość ograniczony!
Należy przydzielić każdemu QPU inną porcję danych. Nowym elementem programu dla wielu rdzeni będzie synchronizacja pomiędzy rdzeniami. Można nauczyć się jak to zrobić obserwując gotowe przykłady.
W tej fazie wyniki będą zapisywane do pamięci VPM a potem gdy wszystkie QPU zakończą obliczenia do pamięci współdzielonej z CPU. W ten sposób będą juz dostępne do zweryfikowania.

Linki