HIVE-Project

Hallo,

ich schreibe ein Programm, das 3 Cogs beschäftigt (siehe Anhang). Im 1. läuft der "Controller", der einen Testfall abspult. Im 2. Cog laufen 2 Routinen, die den 3. Cog über 2 Mailboxen mit Daten versorgen bzw. Daten abholen (z.Z. von Hub zu Hub, also relativ sinnlos; wird später erst sinnvoll). Im 3. Cog läuft die Verarbeitung der Daten.

Im GEAR funktioniert das Programm. Dazu schalte ich in contrl.spin USE_IO auf NOTHING. Dann wird die 1. Cog per Step Instruction bis zum Start der 3. Cog durchgesteppt. Dann lasse ich die 3. Cog bis zum Ende der 1. Hauptschleife (Adr. 5) laufen, die 2. Cog die Daten aus der 2. MBox nach data_out kopieren und sehe der 1. Cog beim Vergleichen in check_result zu.

Mit _IOS bleibt der Hive immer irgendwo hängen. Manchmal wird "failed" ausgegeben und ein völlig sinnloser expected-Datensatz. Schon die erste Ausgabe (Press any key to start) beginnt mit einem "B", das ich nicht so richtig deuten kann.

Mit _PTERM als Ausgabemodus erscheint nach der Startabfrage nur noch Durcheinander auf dem Terminal.

Hat jemand von Euch eine Idee, wo der Fehler liegen könnte?

Grüße

fehlt da nicht erst noch das ios.start?

PIC18F2550 hat geschrieben:fehlt da nicht erst noch das ios.start?

Ich verwende ios.startram (zumindest, wenn ich etwas auf dem Bildschirm ausgeben will), weil ich das Programm per F10 vom BST in den Regnatix-RAM lade. Ios.start und Start von SD-Karte bringt auch nichts.

Ich vermute den Fehler im 2. Cog (hub_streamer), kann ihn aber im GEAR nicht nachweisen. Wahrscheinlich werden irgendwelche Speicherbereiche überschrieben. Dazu brauche ich noch eine Debugging-Idee.

Hab es mir gerade mal angeschaut. Spontan hätte ich gesagt, dass es doch gar kein ios.startram mehr gibt, hab dann aber festgestellt, dass die Routine noch im ios enthalten ist. Im Prinzip wird sie nicht mehr benötigt und es MUSS ios.start in allen Lebensituationen verwendet werden, also sowohl wenn von SDCard oder per F10 gestartet wird. In der nächsten Version werde ich das mal auspflegen.

Mit ios.start startet es zumindes korrekt, die ersten Ausschriften kommen, allerdings kann ich mit den Werten aus deiner Testroutine gerade nichts anfangen. Ändere mal ios.startram --> ios.start und schau mal was sich tut.

U-Held hat geschrieben:Hat jemand von Euch eine Idee, wo der Fehler liegen könnte?

In ctrl.spin rufst Du zweimal mb.mbox16_init(@mbox?) auf, d.h. Du uebergibst die Adresse einer mailbox. Im mb Object nutzt Du aber die Adresse des Parameters (byte[@p_mbox][MBOX_LEN_B]). In diesem Fall solltest Du nur byte[p_mbox][MBOX_LEN_B] nehmen.

Weiterhin, in chk_last_elem (hubstrm.spin) counter ist immer 16. D.h. das Z-Flag ist immer 0 (max setzt Z wenn src == 0). Ist das Absicht?

Hab' gerade mal ueberlegt, das erste Problem sollte eigentlich keine negativen Auswirkungen haben (im Prinzip wird ja nur ein byte auf dem Stack auf Null gesetzt und das noch ziemlich weit weg von wichtigen Dingen). Muss dann wohl an etwas anderem liegen.

a128.init_const: p_key_addr ist eine Adresse auf ein byte array (tc0_key) aber Du nutzt es als long array. Geht zwar wenn es aligned ist, sollte man aber vorsichtig sein.

Aber wenn nicht mal PST funktioniert dann ist wohl irgendwo der Wurm drin. Mal schauen.

[20150225] Im hubstrm Objekt werden in_addr und out_addr nie zurueckgesetzt. Nicht so gut fuer mehrfache Aufrufe. Es waere vielleicht angebracht, alle Teilkomponenten mal fuer sich zu testen bevor man alles zusammenschmeisst :)

Hallo Kuroneko,

danke für Deine Hinweise.

kuroneko hat geschrieben: In ctrl.spin rufst Du zweimal mb.mbox16_init(@mbox?) auf, d.h. Du uebergibst die Adresse einer mailbox. Im mb Object nutzt Du aber die Adresse des Parameters (byte[@p_mbox][MBOX_LEN_B]). In diesem Fall solltest Du nur byte[p_mbox][MBOX_LEN_B] nehmen.

Stimmt, das ist falsch und wieder mal ein Argument für die ungarische Notation. Habs korrigiert.

kuroneko hat geschrieben: Weiterhin, in chk_last_elem (hubstrm.spin) counter ist immer 16. D.h. das Z-Flag ist immer 0 (max setzt Z wenn src == 0). Ist das Absicht?

Im Propeller P8X32A Datasheet steht auf Seite 21 bei MAX: Z Result: D = S. Und so habe ich es im GEAR auch beobachtet. Vielleicht ist das falsch?

kuroneko hat geschrieben: a128.init_const: p_key_addr ist eine Adresse auf ein byte array (tc0_key) aber Du nutzt es als long array. Geht zwar wenn es aligned ist, sollte man aber vorsichtig sein.

Richtig. Ich habe es versucht zu korrigieren. Ich weiß wieder nicht, ob jetzt noch die Byte-Reihenfolge stimmt. Das prüfe ich später.

kuroneko hat geschrieben: Aber wenn nicht mal PST funktioniert dann ist wohl irgendwo der Wurm drin. Mal schauen.

Definitiv. Mit ein paar einfacheren Testfällen sollte es möglich sein, dem Fehler auf die Spur zu kommen.

kuroneko hat geschrieben: Im hubstrm Objekt werden in_addr und out_addr nie zurueckgesetzt. Nicht so gut fuer mehrfache Aufrufe.

Die Objekte sind bis auf weiteres Einweg-Objekte. Ein Teil der Initialisierung ist in Spin ausgelagert. Damit soll die Länge des Assembler-Codes reduziert werden. Im Hub-Streamer ist das natürlich Quatsch, aber im AES könnte es mal knapp werden, wenn ich noch CBC oder einen anderen Block-Mode dazupacke.

kuroneko hat geschrieben: Es waere vielleicht angebracht, alle Teilkomponenten mal fuer sich zu testen bevor man alles zusammenschmeisst

Natürlich. Im GEAR lief der Mist ja auch, allerdings ohne IOS oder pterm. Leider komme ich eher selten an meinen Hive ran und muss mich im ÖPNV mit einem Notebook begnügen. Ein Hive-Laptop wäre da schon besser...

Die neue Version liegt im Anhang. Irgendwann teste ich weiter.

U-Held hat geschrieben:Im Propeller P8X32A Datasheet steht auf Seite 21 bei MAX: Z Result: D = S. Und so habe ich es im GEAR auch beobachtet. Vielleicht ist das falsch?

Ja (falsch). Besorg Dir mal Version 1.4 des Datenblattes.