Wybrany system kontroli wersji:

• Launchpad https://launchpad.net/

Wybrana metodyka

• TDD http://en.wikipedia.org/wiki/Test-driven_development

Wymagania funkcjonalne wersji 0.0.1

• widok główny zawiera domyślnie 4 okna:
  • okno kodu - okno, w którym użytkownik może wprowadzić kod asemblera, zawiera menu (przyciski):
    • uruchom
    • uruchom ze śledzeniem instrukcji
    • wykonaj następną instrukcję
    • przerwij program
    • wznów program
    • zakończ program
  • okno pamięci - pokazuje stan pamięci
  • okno rejestrów - pokazuje stan rejestrów
  • okno schematu - pokazuje predefiniowany schemat mikrokontrolera
• użytkownik może ukryć/pokazać każde z okien
• użytkownik może kazać programowi wykonanie wprowadzonego kodu asemblera (wybiera opcję "uruchom", "uruchom ze śledzeniem instrukcji" lub "wykonaj następną instrukcję")
  • program wykonuje kod wprowadzony w oknie kodu zmieniając stan pamięci, rejestrów i wyjścia
• użytkownik może na bieżąco śledzić w oknie kodu wykonywane instrukcje (wybiera opcję "uruchom ze śledzeniem instrukcji", przydałoby się opóźnić "skok" do następnej instrukcji, by animacja była płynna)
• użytkownik może zatrzymać działanie programu w dowolnej chwili (wybiera opcję "przerwij program") a następnie wznowić jego działanie z tego samego momentu (wybiera opcję "wznów program")
• użytkownik może zakończyć działanie programu w dowolnej chwili (wybiera opcję "zakończ program")
• użytkownik może wykonać jedną, następną instrukcję (wybiera opcję "wykonaj następną instrukcję")
• program powinien być kompatybilny z rzeczywistym procesorem (wprowadzony kod powinien działać tak samo w naszym emulatorze, w RIDE i na rzeczywistym procesorze)

Jak to zrobimy (i w jakiej kolejności ;))?

• stworzymy najpierw emulator procesora 8051 (moduł czytający z pamięci kolejne opkody i wykonujący operacje na pamięci, rejestrach itd.)
• kod asemblera będzie tłumaczony na kod maszynowy (asemblacja) i umieszczany w pamięci
• zaprojektujemy GUI używając odpowiedniej biblioteki (np. jQuery UI): okienka kodu, pamięci i rejestrów.
• początki interfejsu do tworzenia układów (flash)

Oczywiście zanim przystąpimy do pisania właściwego kodu będziemy, zgodnie z TDD, pisać odpowiednie testy (może potem wrzuci się tu linka z jakimś artykułem o dobrych i złych praktykach pisania testów w TDD).

Co robimy?

Chcemy osiągnąć środowisko, w którym będzie można:

• pisać kod i go assemblować.
• debuggować kod (i widzieć które linie się wykonują w mnemonikach, a nie tylko w heksach).
• otoczyć nasz wirtualny mikroprocesor urządzeniami - diodami, oscyloskopami, przyciskami, wyświetlaczami i nauczyć go z nimi współpracować.

Chcielibyśmy, żeby uruchomienie tego środowiska wymagało jak najmniej pracy od potencjalnych użytkowników i żeby nasze środowisko było łatwe do rozszerzenia o dodatkowe urządzenia, które można podłączyć do mikroprocesora.

Dlaczego to robimy?

Bo takie środowisko nie istnieje :-)

Istniejące otwarte emulatory:

• gsim51 - służy tylko do uruchamiania już skompilowanych plików hex, wymaga kompilacji.
• emu8051 - dokładnie jak wyżej, ponadto wygląda paskudnie.
• emu51 - wymaga kompilacji, obecnie przystosowany tylko do windowsa, służy do uruchamiania plików hex, wymaga allegro w wersji z 2003 roku.

Jak to robimy?

• Kod i błędy trzymamy na Launchpadzie.
• Stosujemy TDD, a testy piszemy w JS-test-driver.
• Stosujemy następujące konwencje zapisu kodu.

Materiały dla członków zespołu:

• Dobry tutorial pisania asma na 8051
• baza konkretnej wiedzy - opis rozkazów i opkody
• Dokumentacja JS-test-driver - frameworku do testowania JS
• Szybkie wprowadzenie do JS
• JSLint
• przykładowe code conventions.