Kein A auf dem Bus

[ben]

Hallo HiveFans,

Ich versuche gerade zu verstehen wie die Kommunikation über den Bus läuft. Habe mir da ein kleines Programm geschrieben(zusammen kopiert). Es soll einfach ein A auf den Bus legen.

EIN A???? PSSSST... Genau!

Das Programm startet HBEAT und bus_putchar, leicht modifiziert. Die LED blinkt, aber am Bus liegt nichts an. Ich lade das Programm mit F10 direkt in den Propeller. Wird bus_putchar irgendwie terminiert?

Grüße,

Benjamin

Code: Alles auswählen

OBJ
ios: "ios"

CON
_CLKMODE     = XTAL1 + PLL16X
_XINFREQ     = 5_000_000
#24,    HBEAT                   'LED
        BUSCLK                  'Bustakt
        BUS_WR                  '/wr - Schreibsignal
        BUS_HS                  '/hs - Quittungssignal
DB_IN        = %00001001_00000000_00000000_00000000
DB_OUT       = %00001001_00000000_00000000_11111111
CNT_HBEAT    = 5_000_0000

VAR
long  stack[24]

PUB main
{{Hauptprogramm fuer Bus Test}}
  init

PUB init
{{Initialisierung}}
  cognew(led_hbeat, @stack)
  cognew(bus_putchar("A"), @stack) ' oder (str)

PUB led_hbeat
{{led_hbeat - Herzschlag fuer Front-LED}}
  dira := DB_IN
  repeat
    !outa[HBEAT]
    waitcnt(CNT_HBEAT + cnt)

PUB bus_putchar(zeichen)
{{Ein Byte über Bus ausgeben}}
  dira[BUSCLK]~~ ' Simuliert busclk
  outa[BUSCLK] := 1
waitpeq(%00000010_00000000_00000000_00000000,%00000010_00000000_00000000_00000000,0)
  dira := DB_OUT
  outa[7..0] := zeichen ' Daten werden auf den Bus gelegt. A entspricht 01000001.
  outa[BUS_HS] := 0

  ' Hier sollte das Programm doch warten auf busclk = 0
  ' Es müsste also noch A auf am Bus liegen.
 waitpeq(%00000000_00000000_00000000_00000000,%00000010_00000000_00000000_00000000,0)

  outa[BUS_HS] := 1
  dira := DB_IN

DAT
str byte "A", 0

[drohne235]

Hi.

Deine Routine "bus_putchar" wird wirklich terminiert - sie gibt das Zeichen aus und wird dann halt beendet und die COG verschwindet wieder im Tiefschlaf. Wenn eine COG schlafen geht werden automatisch die I/O's auf Eingabe geschaltet. Das einzige was noch läuft ist das Heartbeat. Bau doch zum testen ein "bus_putchar(x++)" in die Heartbeatschleife ein, damit hast du zum Testen einen inkrementierenden 8Bit-Wert an D0..7 - die höchste Frequenz an D0, die niedrigste Frequenz an D7. Oder du mußt in der zweiten COG noch eine Routine mit einer Schleife um die Busroutine einbauen.

[ben]

Deine Routine "bus_putchar" wird wirklich terminiert - sie gibt das Zeichen aus und wird dann halt beendet und die COG verschwindet wieder im Tiefschlaf. Wenn eine COG schlafen geht werden automatisch die I/O's auf Eingabe geschaltet.

Aber warum? Das zweite waitpeq sollte doch warten bis busclk wieder auf low ist. Und dass sollte doch nicht passieren, oder? So wie ich das verstanden habe sollte die Cog doch angehalten werden bis das gewünschte Ereignis eintritt.

[drohne235]

Deine Routine "bus_putchar" wird wirklich terminiert - sie gibt das Zeichen aus und wird dann halt beendet und die COG verschwindet wieder im Tiefschlaf. Wenn eine COG schlafen geht werden automatisch die I/O's auf Eingabe geschaltet.

Aber warum? Das zweite waitpeq sollte doch warten bis busclk wieder auf low ist. Und dass sollte doch nicht passieren, oder? So wie ich das verstanden habe sollte die Cog doch angehalten werden bis das gewünschte Ereignis eintritt.

Jo, ist richtig. Dann wartet die Cog aber wahrscheinlich auf ein High beim Busclock und gibt den Wert nicht aus. Auf welchem Chip läuft der Code - Regnatix oder Bellatrix? Hast du irgend einen Takt am Busclock?

[ben]

Also ich lade den Code mit F10 direkt in Regnatix. Ich setze busclk auf high. Aber ich glaube du hast recht. Es läuft bestimmt dann ein busclk im Hintergrund, so dass das Programm beendet wird.

Wenn ich ein repeat davor setzt liegt alles richtig am Bus an. Wer erzeugt eigentlich den Bustakt? Regnatix? Oder extern? Muss ich gleich mal nachschauen. So wie es aussieht habe ich heute ein wenig Zeit!!!

[drohne235]

Den Busclk erzeugt im TriOS normalerweise Regnatix. Ich hab eigentlich bloß gefragt, weil die Routine "bus_putchar" von Bellatrix oder Administra stammt. Der Bustakt wird von Regnatix erzeugt, weil Regnatix halt der Master ist und Admin/Bella die Slaves. Das Handling der Bussignale zwischen Master und Slave ist aber verschieden. So wird eine Busoperation im TriOS/IOS immer von Master (also Rergnatix) initialisiert. Im Normalzustand lauschen die Slaves also nur am Bus und warten auf ein enstprechendes Signal - /prop1 oder /prop2 auf Low - je nach Slave. Dann sendet der Master eine Funktionsnummer an den Slave. Je nach Funktion werden dann Daten vom Slave gelesen oder gesendet.

Da das Timing durch die Verwendung von SPIN nicht starr und reproduzierbar ist, quittiert jeder Slave einen Buszyklus (egal ob Byte lesen oder schreiben) mit dem Handshakesignal (/HS).

Schau dir mal den passenden Abschnitt im FAQ an, vielleicht hilft das weiter: http://hive-project.de/support/faq#QT3 Dort sind auch entsprechende Diagramme wie das aus der Sicht von Regnatix auf dem Bus abläuft. Aber man kann den Ablauf auch ganz gut an den Routinen im IOS erkennen, da ich dort alles kommentiert habe.

Momentan schreibe ich gerade am zweiten Teil des Tutorial "Build your OS - Regnatix-Code". Dabei geht es am Anfang um den Bus und dem Datenaustausch zwischen Master, Slave und RAM. Da werde ich wohl mal die Routinen auseinanderpflücken und mit genaueren Diagrammen versehen.