HIVE-Project

Meine RAM's haben 55 ns Zugriffszeit als Allgemeinwert, genaues Timing bei den einzelnen Signalen hab ich aber noch nicht geprüft. Wäre ja doof, wenn man da sinnlose NOP's einfügen muss, bei dem knappen Speicher...

Du kannst ja mal weiter testet: Bei dem Signal für das Adresslatch sollte man eignetlich kein NOP brauchen, an den anderen Stellen kann es möglich sein, aber dann sollte ein NOP für eine zusätzliche Bedenkzeit von 50 ns aber reichen.

Vielleicht habe ich zum nächsten KC-Treffen mal eine Testroutinen in m geschrieben, dann flashen wir auf deinem Board mal mental und testen mit meinen Routinen.

Hatte erst mit deinen Routinen getestet aus "mental-blk-16-09-2012-dr235.rar" dort bekam ich beim lesen immer $00 zurück.

Latch 2xNOP nein das ist beim schreiben.

Ich hatte auch versucht das /cs signal mit clr zurückzunehmen da wurde aber ein bit noch verändert.

Um den platz mache ich mir zur zeit noch keine gedanken da ich ja alle 7 COG's zur verfügung habe.

COG0 (Spin) bleibt zur überwachung(watchdog) aktiv.

Ich hab jetzt noch mal nach den SRAM geschaut und es ist schon ganzschön knapp bei 55ns wenn der Prop mit 50ns sein Pegel wechseln kann.
Das wird nicht jeder schaffen.

Ich hab jetzt noch mal nach den SRAM geschaut und es ist schon ganzschön knapp bei 55ns wenn der Prop mit 50ns sein Pegel wechseln kann.
Das wird nicht jeder schaffen.

Das wird nicht nur knapp, das geht definitiv nicht bei zwei direkt folgenden Befehlen - hab ich schon probiert. Aber in den m-Routinen ist da zwischen dem Anlegen der Signale und dem lesen/schreiben immer noch ein Befehl. Beim Lesevorgang ist es zum Beispiel der ret-Befehl aus setadr heraus - damit sind dann zusätzliche 50 ns verfügbar was dann reicht. Bei der Routine zum schreiben hatte ich erst zwischen dem setzen des Schreibsignales und dem Rückschalten auf Buseingabe ein NOP, aber das war nicht nötig (wahrscheinlich wird der Wert am Bus recht schnell in ein internes Latch übernommen), hab ich dann wieder entfernt. Adresse und Selektionssignale liegen ja auch beim Schreiben länger an.

...

Ich hatte an diese Sequenz in setadr gedacht:

Code: Alles auswählen

              or      outa,   _la
              nop                     '<< sehr wichtig
              andn    outa,   _la

Da wird doch das Strobesignal für den Latch erzeugt oder?

Mit dem Speicher hast du es dann aber komfortabel. Bei meinem m-Core ist aktuell genau noch 1 Long frei. An sich hab ich aber soweit fast alles drin: wenn ich mich recht entsinne ist das in einer COG der Code von 61 primäre Forthworten, die VM, beide Stacks (je 32 Longs) und die Stackroutinen. Aber wenn ich mir Mühe gebe, sind da noch ein paar Reserven drin...

habe in meinen HIVE Wahn gleich mal das Businterface angepasst

Code: Alles auswählen

'---------------------------------------------------------------------
' businterface
' ---------------------------------------------------------------------
aput    ' zeichen zu administra senden
              mov     temp2,_a1
              mov     temp3,_a2
              jmp     #put
bput    ' zeichen zu belatrix senden
              mov     temp2, _b1
              mov     temp3, _b2
put           mov     outa,   clr
              mov     dira,   dinp
              and     temp1, #$ff
              or      temp1, temp2
              waitpeq _hs,   _hs
              mov     outa,  temp1
              mov     dira,   dout
              or      outa,  temp3
              waitpeq h00000000, _hs
              mov     outa,   clr
              mov     dira,   #$0
aput_ret
bput_ret      ret
' ---------------------------------------------------------------------
aget    ' zeichen von administra empfangen
              mov     temp2, _a3
              jmp     #get
bget    ' zeichen von belatrix empfangen
              mov     temp2, _b3
get           mov     outa,   clr
              mov     dira,   dinp
              waitpeq _hs,   _hs
              mov     outa,  temp2
              waitpeq h00000000,_hs
              mov     temp1, ina
              and     temp1, #$ff
              mov     outa,   clr
              mov     dira,   #$0
aget_ret
bget_ret      ret

Der Latch ist schon schnell aber bedenke das er nur mit 3,3 V angesteuert wird und die 15ns sich auf 4,5V laut datenblatt beziehen.
Das bezieht sich nicht auf die Betriebsspannung des Latches sondern auf die schalthysterese des Eingangs.
L/H schaltflanken neigen dazu am oberen Teil etwas verzögert auf H anzukommen, das gehen schonmal je nach Schaltung 5-10nS flöten.
Aber ich gehe da lieber auf nummer sicher später so ein Problem in einem Komplexen Programm zu suchen ... nein Danke.

drohne235 hat geschrieben:
Code: Alles auswählen
              or      outa,   _la
              nop                     '<< sehr wichtig
              andn    outa,   _la
Da wird doch das Strobesignal für den Latch erzeugt oder?

Ja

>>> There are 159 ($09F) Longs left in the cog <<< das dürfte gerade noch reichen

Der Latch ist schon schnell aber bedenke das er nur mit 3,3 V angesteuert wird und die 15ns sich auf 4,5V laut datenblatt beziehen.

Da gehen sie hin, die 50 ns...

Aber bezüglich der Fehlersuche hast du natürlich recht.

>>> There are 159 ($09F) Longs left in the cog <<< das dürfte gerade noch reichen

Ich hab noch nicht ganz verstanden, wie du das machst: Der Bytecode liegt im eRAM und wird von einer COG gelesen - wahrscheinlich verwaltet diese COG alle Zugriffe auf den Bus. Andere Funktionen verteilen sich dann über die verbleibenden COG's. Wenn diese BusCog einen Bytecode aus dem eRAM geholt hat -wo landet der dann und wie werden diese Funktionen dann abgearbeitet?

Im Prinzip habe ich ja ähnliche Optionen auch noch in m, denn ich muss ja nicht in allen COG's die gleiche VM starten. Hmm, muss ich mal drüber nachdenken...

Das Basic Programm liegt im hRAM von $0 - $7F00 danach kommen alle Varibeln und zum schluss 2 Steuervariabeln.
Alle COG'S lesen den Basic Code gleichzeitig und nur der den Befehl kennt darf die 2 Steuervariabeln ändern.

PIC18F2550 hat geschrieben:Das Basic Programm liegt im hRAM von $0 - $7F00 danach kommen alle Varibeln und zum schluss 2 Steuervariabeln.
Alle COG'S lesen den Basic Code gleichzeitig und nur der den Befehl kennt darf die 2 Steuervariabeln ändern.

Ahh, eine COG adressiert und realisiert die adressrelevanten Befehle und die anderen COG's lesen quasi mit! Gute Idee! Mit dem externen RAM funktioniert das natürlich gut, da ja alle COG's am Datenbus mitlesen können. Coole Sache, bin mal auf die Geschwindigkeit gespannt.

Nein die anderen COG's werden nicht über den Bus bedient sie kennen nur die 2 Systemvariabeln

Die Grundschleife umfast 20 PASM Befehle zuzüglich die Befehle die für den jeweiligen Code/Routine gebraucht werden.

in den 20 Befehlen sind endhalten:

1. Kontrolle uns Steuerung Statusregister
2. Prüfung auf gültigen Befehlsbereich(Jede COG hat einen eigenen Bereich aus 0-65535)
3. Aufbereitung der Argumente 16Bit in longvariabel(arg1, arg2, arg3), 32Bit(arg23)
4. Manipulation der COG-Codes zur generierung eines Sprungverteilers(64 Sprünge/Token/Routinen pro COG)

Ersteinmal muß die Runtime0 stehen bevor mit der IDE gegonnen wird.
Die IDE ist im Prinzip ein BasicCompiler ähnlich VB.

Funktionen wie print_HEX, print_String, ... oder die Commandlinie werden in Bellatrix ausgelagert.
Als Anzeige werde ich ersteinmal meinen "VGA 80x60, COLOR 16/16 RASTER 8x8 Treiber mit Z1013.A2 Zeichensatz" einsetzen.

Da fällt mir ein konntest du den Zeichensatz verwenden?

Kleiner Aufbau

Code: Alles auswählen

  Jeder Befehl ist zwischen 1 word und 2 long's lang.
  Der Programmcode beginnt ab adresse 0300 und endet bei 7FF7.
  32 Strings sind max. 255Byte + 0x00 lang davon sind genau 26 direckt ansprechbar der rest ist internen Funktionen vorbehalten
  32 Strings sind max. 255Byte lang mit Längenangabe davon sind genau 26 direckt ansprechbar der rest ist internen Funktionen vorbehalten
prog.long[0] 1.long
'      = byte[0]+byte[1]  Befehl
'      = byte[2]+byte[3]  Argument 1
prog.long[4] 2.long
'      = byte[4]+byte[5]  Argument 2     + als 32Bit Argument
'      = byte[6]+byte[7]  Argument 3     +
prog.long[8]...
         0    1    2    3    4    5    6    7    8    9    A    B    C    D    E    F
    long x,x, x,x, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0

  Variabeln sind immer ein long lang egal was für ein Typ sich dahinter verbirgt.

bit1.long[0000]
        'a b c d e f g h i j k l m n o p q r s t u v w x y z (interne Variabeln oder Zeiger)
    long 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0

bit8.long[0080]
        'a b c d e f g h i j k l m n o p q r s t u v w x y z
    long 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0

bit16.long[0100]
        'a b c d e f g h i j k l m n o p q r s t u v w x y z
    long 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0

bit32.long[0180]
        'a b c d e f g h i j k l m n o p q r s t u v w x y z
    long 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0

text1.long[0200] --> Zeiger in den eRAM 0 therminiert
        'a b c d e f g h i j k l m n o p q r s t u v w x y z (Zeiger auf Externen Ram jede Variable=255 Byte)
    long 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0

text2.long[0280] --> Zeiger in den eRAM mit Längenangabe Es können dadurch auch $0 übertragen werden.
        'a b c d e f g h i j k l m n o p q r s t u v w x y z (Zeiger auf Externen Ram jede Variable=255 Byte)
    long 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0

frei.long[0300]...[7FF7]

addr.long[7FF8]
        Adresse des Programmspeichers dient zur syncronisation der COG's
        1.) Adresse lesen
        2.) Abarbeiten
            ja    Neue adresse schreiben
            nein  warten auf neue Adresse

status.long[7FFC]
        Sreuerregiste zum steuern der Runtimmodule
        $0000_0000 = Go/COUNT
        $0000_0001 = STOP
        $7F7F_F7F7 = INIT/RUN
        $FFFF_FFFF = Stop/END

HIVE-Project

HBasic

Re: HBasic

Re: HBasic

Re: HBasic

Re: HBasic

Re: HBasic

Re: HBasic

Re: HBasic

Re: HBasic

Re: HBasic

Re: HBasic