HIVE-Project

Retro Style Eigenbau Computer mit Parallax Propeller
Aktuelle Zeit: Sa 19. Okt 2019, 05:07

Alle Zeiten sind UTC [ Sommerzeit ]




Ein neues Thema erstellen Auf das Thema antworten  [ 7 Beiträge ] 
Autor Nachricht
 Betreff des Beitrags: Hilfe beim Debuggen
BeitragVerfasst: Mi 18. Feb 2015, 22:12 
Offline

Registriert: Mi 14. Dez 2011, 22:05
Beiträge: 65
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


Dateianhänge:
aes-20150218.zip [13.64 KiB]
297-mal heruntergeladen
Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Hilfe beim Debuggen
BeitragVerfasst: Mi 18. Feb 2015, 22:26 
Offline
Benutzeravatar

Registriert: Fr 30. Sep 2011, 13:08
Beiträge: 2562
fehlt da nicht erst noch das ios.start?

_________________
Gruß
PIC18F2550

drone265/278
Barbarus hic ergo sum, quia non intellegor ulli.
Ein Barbar bin ich hier, da ich von keinem verstanden werde.


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Hilfe beim Debuggen
BeitragVerfasst: Fr 20. Feb 2015, 22:17 
Offline

Registriert: Mi 14. Dez 2011, 22:05
Beiträge: 65
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.


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Hilfe beim Debuggen
BeitragVerfasst: Sa 21. Feb 2015, 11:39 
Offline
Administrator
Benutzeravatar

Registriert: So 24. Mai 2009, 10:35
Beiträge: 2275
Wohnort: Lutherstadt Wittenberg
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. :o 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.

_________________
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Hilfe beim Debuggen
BeitragVerfasst: Di 24. Feb 2015, 14:11 
Offline
Benutzeravatar

Registriert: Sa 22. Okt 2011, 13:05
Beiträge: 199
Wohnort: FN, Germany
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 :)


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Hilfe beim Debuggen
BeitragVerfasst: Mi 25. Feb 2015, 23:09 
Offline

Registriert: Mi 14. Dez 2011, 22:05
Beiträge: 65
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.


Dateianhänge:
aes-20150225.zip [24.21 KiB]
264-mal heruntergeladen
Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Hilfe beim Debuggen
BeitragVerfasst: Do 26. Feb 2015, 00:03 
Offline
Benutzeravatar

Registriert: Sa 22. Okt 2011, 13:05
Beiträge: 199
Wohnort: FN, Germany
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.


Dateianhänge:
P8X32A-Propeller-Datasheet-v1.4.0_0.pdf [1.38 MiB]
268-mal heruntergeladen
Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 7 Beiträge ] 

Alle Zeiten sind UTC [ Sommerzeit ]


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de