PASM Bootloader

[PIC18F2550]

+++ EDIT +++

geht so nicht

[PIC18F2550]

Was noch Fehlt ist Die Rückgabe der Aktuellen COGID wenn eine neue 32k Kachel geladen wurde.
Woher soll den das neue Programm wissen auf welchen COG der Treiber werkelt.

[PIC18F2550]

In dem Zusammenhang Frage ich mich ob der Propeller von diesen großen EEPROM booten kann.
Welche Adresse hat der 24LC256 eigentlich?

=== EDIT ===

Alles OK die Adressen sind gleich %1010_A2_A1_A0_RW also kein Problem beim HIVE.

[PIC18F2550]

Kommt Zeit kommen Ideen.

Eigentlich müsste nur der Teil in den EEPROM gespeichert werden der relevant zur Programmausführung von nöten wäre.

Diese Länge müsste in den ersten Zellen des eeprom-files enthalten sein.

Theoretisch könnte man bei einen 64k EEPROM 3 Treiber unterbringen.

Aber das erst nach dem test.

[PIC18F2550]

Irgendwie habe ich einen Knoten im Hirn

Code: Alles auswählen

Entry
                        cogid   id
                        add     id, #1
                        ....

Code: Alles auswählen

                        ....
                        cmp     id, #1        wz
        if_nz           cogstop cog0
                        cmp     id, #2        wz
        if_nz           cogstop cog1
                        cmp     id, #3        wz
        if_nz           cogstop cog2
                        cmp     id, #4        wz
        if_nz           cogstop cog3
                        cmp     id, #5        wz
        if_nz           cogstop cog4
                        cmp     id, #6        wz
        if_nz           cogstop cog5
                        cmp     id, #7        wz
        if_nz           cogstop cog6
                        cmp     id, #8        wz
        if_nz           cogstop cog7
                        ....

                        'PAR            CODE           NEW  ID
cog0            long    $0000___________0000___________0____0
cog1            long    $0000___________0000___________0____1
cog2            long    $0000___________0000___________0____2
cog3            long    $0000___________0000___________0____3
cog4            long    $0000___________0000___________0____4
cog5            long    $0000___________0000___________0____5
cog6            long    $0000___________0000___________0____6
cog7            long    $0000___________0000___________0____7

Code: Alles auswählen

                        ....
                        coginit spin
                        ....

                        'PAR            CODE           NEW  ID
'spin            long    $0000___________F004___________1____0
spin            long    $0004 << 16 | $F004 << 2 | %0000

Kann das sein das hier die long adressen gebraucht werden die währen ja genau 14 Bit lang und nicht 16 Bit?
So scheint es erst mal zu gehen. $F004(byte) = $3C01 (long) das muss ich mir in BST noch mal genauer ansehen.

Code: Alles auswählen

                        'PAR                  CODE                NEW  ID
spin            long    %00_0000_0000_0001____11_110_0000_0001____1____000
'spin           long    $0004 << 16 | $F004 << 2 | %0000

OK verstehe zwar nicht ganz warum das NEW Bit 0 sein soll damit es den spininterpreter richtig startet.

Code: Alles auswählen

spin           long   $0007C010

[PIC18F2550]

Jetzt geht es ans Platzsparen.

Code: Alles auswählen

Binary Image Information :
PBASE : 0010
VBASE : 032C
DBASE : 0334
PCURR : 0320
DCURR : 0338

Was bedeutet Was:

Code: Alles auswählen

PBASE : Startadresse des Programms
VBASE : Startadresse der Variabeln
DBASE : Startadresse ???
PCURR : Startadresse ???
DCURR : Startadresse ???

Im Hexeditor konnte ich erkennen das ab der Adresse DBASE : 334 alle Zellen nur noch den wert $00 enthielten.
Oder gibt es da Ausnahmen was der Verwendung als Längenzeiger entgegen steht.

Die Daten befinden sich im EEPROM-File an folgender Stelle.

Code: Alles auswählen

$0006 PBASE
$0008 VBASE
$000A DBASE
$000C PCURR
$000E DCURR

Hoffentlich immer dort.

Gibt es eine Beschreibung was die restlichen Bytes zwischen $0000 und $0018 (DAT bereich eines Treibers) bedeuten?

[PIC18F2550]

Ok die Zeiger sind nicht die Lösung

Da muss ich wohl erst mal ein Kleines Tool schreiben was aus den verschiedenen Treibern mir ein EEPOM-FILE schreibt.

Im Loader wird dann am Anfang ein Array sein wo die einzelnen Start-Adressen hinterlegt werden.

Die Adressrechnung wird umgestellt um auch einen 128K ohne Probleme verwenden zu können.
Die A16 wird auf die Position vom nicht verwendeten Pin A2 geschoben.
An der alten A16 Position kommt beim EEPROM das R/W Bit.

Rann an Trios

[digger]

Irgendwie habe ich einen Knoten im Hirn

Also wenn ich deine Experimente so ansehe, hab ich sowieso meist einen Knoten im Hirn.

[PIC18F2550]

DU AUCH !?!?

Das ist das Schlimme an der Sache die Erkenntnis überfährt die Idee und das Ergebnis ist immer eine neue Idee.

Das ist wie Rührkuchen man dreht sich immer im Kreiße aber das Ergebnis ist lecker.

[PIC18F2550]

So das Thema eeprom-File ist vom Tisch das wird einfach zu groß.

Jetzt muss ich mich erst mal mit den binary Files befassen um herauszufinden wie die die Daten in den HUB-Ram gebaut werden müssen.

In den 32k EEPROM könnten dann 4 regnatix-treiber eingebaut werden.
Die Standard Treiber sind alle unter 8k.