bst <-> bstc

[PIC18F2550]

Hallo,

obwohl beide den gleichen Quellcode bekommen haben ist das Ergebnis doch unterschiedlich.
BST

Code: Alles auswählen

Binary Image Information :
0000	00
0001	D8
0002	B8
0003	05
0004	6F 
0005	D4
0006 PBASE : 0010 Object Constants & Object DAT Blocks
0008 VBASE : 0024 ?
000A DBASE : 002C ?
000C PCURR : 001C Object Spin
000E DCURR : 0030 Ende

BSTC

Code: Alles auswählen

Binary Image Information :
0000	00
0001	1B
0002	B7
0003	00
0004	00 
0005	06
0006 PBASE : 0010 Object Constants & Object DAT Blocks
0008 VBASE : 0024 ?
000A DBASE : 002C ?
000C PCURR : 001C Object Spin
000E DCURR : 0030 Ende

Weis jemand was die 5 Byte ab 0000h bedeuten?
Und warum sind die unterschiedlich?

[kuroneko]

Code: Alles auswählen

long[0] = clkfreq
byte[4] = clkmode
byte[5] = checksum

Warum die jetzt anders sind kann ich so nicht sagen.

[yeti]

https://github.com/rosco-pc/propeller-w ... Memory-Map hat leider ein togal dorschenanner gekommenes Layout und ich komm grad nicht drauf, woran es liegt. Wenn man sich den Quelltext anschaut, ist's etwas besser lesbar.

Mal die relevanten Zeilen manüell ein bissl gerade gebogen:

• $0000 | LONG ClkFreq
  This value is created by the spin compiler, and is equivalent to the system variable _CLKFREQ that may be set in the Spin Top Object. If a user program changes the frequency using the CLKSET command, it should also update this value. Default is 12,000,000 which is the approximate frequency of RCFAST mode.
• $0004 | BYTE Clk
  Equivalent to the system variable _CLKMODE that may be set in the Spin Top Object. If a user program changes the frequency using the CLKSET command, it should also update this value. Default is 0 which corresponds to RCFAST mode.
• $0005 | BYTE Checksum
  -

Ich sehe keinen Grund, warum bei gleichem Quelltext zwei Kompiler in den Bytes 0000-0004 unterschiedliche Werte produzieren sollten. Bei unterschiedlichem Codegenarator oder unterschiedlicher Optimierung mag die Checksum bei 0005 anders ausfallen.

[PIC18F2550]

Ok da hatte ich das falsche eeprom file erwischt.

Code: Alles auswählen

Constant _clkmode = 00000408 (1032) _clkmode = xtal1 + pll16x
Constant _xinfreq = 004C4B40 (5000000) _xinfreq = 5_000_000

0000   00 B4 C4 04      _CLKFREQ = 80_000_000
0004   6F               _CLKMODE
0005   CRC

Wie sehen die Werte von 0004 bei den _CLKMODE varianten aus?

Wie berechnet sich die 0005 CRC prüfsumme?

ebenso unklar sind die werte und bedeutung von 0010 bis 0017?

[yeti]

Wie sehen die Werte von 0004 bei den _CLKMODE varianten aus?

QuickReference-v15.pdf, Seite 4, Tabelle "Valid Clock Modes"

Wie berechnet sich die 0005 CRC prüfsumme?

Die Prüfsumme wird so gesetzt, daß die unteren 8 Bits der Summe aller Bytes des gesamten 32k RAM Bereiches NULL ergibt.

Code: Alles auswählen

$ python -c 'print(reduce(lambda a,b:a+b,map(ord,open("xyzzy.eeprom").read())) & 255)'
0

ebenso unklar sind die werte und bedeutung von 0010 bis 0017?

Da werveise ich wieder auf die nun nicht mehr so ganz kaputte Tabelle im Propeller-Wiki.

——————————

[PIC18F2550]

yeti,

danke für die Tabelle.
Ich war bei "Valid Clock Modes" auch auf 32bit aus.

wenn ich eine prüfsumme berechne das eine byte ändere kähme bei der nächsten prüfsummenberechnung eine andere prüfsumme raus.
python super das ich das nicht auch noch kann,
Bisschen wass soliedes BASIC

Code: Alles auswählen

a=0
for b=0h to 7fffh
  a=a+peek(b)
next b
print a & ffh

oder wird die Zelle beim erstellen ausgelassen? und nach dem berechnen gesetzt.

Oh die tabelle sieht wieder besser aus.
$0010- Top object Usual start of top object.
sagt mir nichts. oder ist da näheres flöten gegangen?
ich vermute das das die Startparrameter für den SPIN-COG sind.
Das währe von 0004 bis 0017.

Ab 0018 kähme der DAT oder SPIN-Code bereich.