Valued on Reset

[BerndB (Gast)]

Geehrte Kollegen,

wenn eine Speicherzelle (Reg.= MAMXFLH IC=ENC28J60) ein "Value of Reset" 
von 6 hat und ich gebe dort eine 5 ein so erhalte ich beim Auslesen 
dieser Zelle eine 7 (0110 + 0101 = 0111).
Die voreingestellte 6 läßt sich nicht löschen.
Wie gehe ich damit um wenn der richtige Wert dieser Zelle für den 
ENC28J60 entscheident ist.
In dieser Speicherzelle soll die Framelänge (hier High-Byte) eingtragen 
werden.

Danke euch,
Bernd

[Karl H. (kbuchegg)]

BerndB schrieb:
> Geehrte Kollegen,
>
> wenn eine Speicherzelle (Reg.= MAMXFLH IC=ENC28J60) ein "Value of Reset"
> von 6 hat und ich gebe dort eine 5 ein so erhalte ich beim Auslesen
> dieser Zelle eine 7 (0110 + 0101 = 0111).
> Die voreingestellte 6 läßt sich nicht löschen.

Das klingt in höchstem Masse unlogisch. So etwas wäre in der Paxis nicht 
sehr brauchbar. Womit sich der Verdacht erhärtet, das eigentliche 
Problem sitzt irgendwo in deinem Code.

[BerndB (Gast)]

Hallo Karl Heinz,

danke für deine Antwort!
Bei der Initialisierung des ENC28J60 habe ich bis auf diese 
Speicherzelle keine Probleme. Was ich reinschreibe kann ich aus 
auslesen. Bis auf die eine Zelle und mir ist aufgefallen das im 
Datenblatt "Value on Reset = 6" steht.
Und diese "6" ist nicht löschbar.

Mache ich was falsch, oder soll dieser Wert hier eine Mindestframelänge 
angeben?

[BerndB (Gast)]

Hier noch ein Aszug aus meinem Code.

[Peter D. (peda)]

Nenne Code *.c oder *.asm, aber nicht *.txt!

BerndB schrieb:

> STS (SRAM_DATA_CODE), temp_1          //HIER IST EIN FEHLER ERGEBNIS = 7 statt 5

Und wie hast Du das geprüft?
Und was hat das mit der "6" zu tun?

Ethernet in Assembler, sehr ambitioniert.


Peter

[BerndB (Gast)]

Hallo Peter,

ich hab es in Assembler geschrieben.

Geprüft habe ich das indem ich dem Speicherinhalt (hier MAMXFLH) über 
UART zu meiner LCD-Anzeige gesendet habe.

Bernd

[Karl H. (kbuchegg)]

BerndB schrieb:
> Hallo Peter,
>
> ich hab es in Assembler geschrieben.
>
> Geprüft habe ich das indem ich dem Speicherinhalt (hier MAMXFLH) über
> UART zu meiner LCD-Anzeige gesendet habe.

Und wo sieht man das in deinem Code?

Nach dem Setzen kommt zwar ein Abschnitt, der mit Kontrolle übertitelt 
ist, aber da wird nicht MAMXFLH ausgelesen sondern ein Teil der 
MAC-Adresse




Ich finde deinen Code sehr unübersichtlich und schwer zu lesen. Mir 
wimmelt es da auch zu sehr von STS und LDS und temp1. Wenn du sowieso 
dauernd das temp1 Register benutzt, wozu soll es dann gut sein, wenn du 
dir dauernd irgendwas im SRAM als Parameter zwischenspeicherst. Definier 
dir 2 Register, die als Schnittstelle zu den SPI Funktionen dienen (aber 
nenn sie nicht temp1 und temp2 ... ordentliche aussagekräftige Namen!), 
lade die mit den Werten und ruf die Funktion auf. Ich sehe nicht 
wirklich, was es bringen soll, wenn du vorher alles mittels STS in den 
Speicher schreibst, nur damit es sich die Funktion dann wieder mittels 
LDS erneut wieder nach temp1 holt.


Es wird zwar wahrscheinlich egal sein, aber wenn du hier

CHANGE_BANK:
  LDS temp_1, (SRAM_BANK_NUMBER_NEW)
  LDS temp_2, (SRAM_BANK_NUMBER_OLD)

  CP temp_1, temp_2
  BREQ CHANGE_BANK_END
  TST temp_1
  BREQ BANK_00
  CPI temp_1, 1
  BREQ BANK_01
  CPI temp_1, 2
  BREQ BANK_02
  CPI temp_1, 3
  BREQ BANK_03

....

sowieso mit den Konstanten 0, 1, 2, 3 für die Banknummer vergleichst, 
dann solltest du hier beim Aufruf

  LDI temp_1, (1<<ENC28J60_BIT_ECON1_BSEL_1)|(0<<ENC28J60_BIT_ECON1_BSEL_0)  //Bank 0x02
  STS (SRAM_BANK_NUMBER_NEW), temp_1    
  
  RCALL CHANGE_BANK

dann auch diese Konstanten benutzen und nicht die Bitdefinitionen (auch 
wenn es aufs gleiche rausläuft). Denn die Funktion erwartet laut 
Funktions-API eine der Konstanten 0, 1, 2, oder 3 in 
SRAM_BANK_NUMBER_NEW. Das hat dann auch den Vorteil, dass du dir hier

  LDI temp_1, 2
  STS (SRAM_BANK_NUMBER_NEW), temp_1    
  
  RCALL CHANGE_BANK

den Kommentar sparen kannst, weil die Bank-Nummer direkt lesbar im Code 
steht. Noch besser wäre ein wenig Assembler-Hilfe

  LDI temp_1, BANK_2
  STS (SRAM_BANK_NUMBER_NEW), temp_1    
  
  RCALL CHANGE_BANK

(und natürlich dann auch die entsprechenden Konstanten in der Funktion 
benutzen)-

Mit deinen ursprünglichen Bits bei diesem Aufruf suggerierst du, dass da 
etwas speziell bitmässiges passiert, was ja laut Auswertung in der 
Funktion gar nicht der Fall ist.

Es sind solche Kleinigkeiten, die einen Code schwer lesbar machen 
können, weil man sich dann wieder ein Detail mehr merken muss. Wie 
gesagt: Ich kenne zwar die Bitdefinitionen nicht, aber aus dem Rest der 
CHANGE_BANK Funktion wird klar, dass es keinen Unterschied macht, weil 
die Bits ohnehin so sind, dass sich die Zahlen ergeben, aber es ist ein 
Punkt der einen bei der Analyse zu unnötigem Kopfkratzen und der Analyse 
eines Details zwingt, das völlig unnötig analysiert wird.

[Karl H. (kbuchegg)]

Aahhhh.
Hier liegt der Hund!


Wenn du ein Register beschreiben willst, dann benutze auch das Kommando 
"Write Register". Dazu wurde es gemacht! Mit deinem Bitfield-Clear und 
Bitfield-Set hast du dich selber in Teufels Küche gebracht.
Die Bitfield Operationen benutzt du, wann du tatsächlich ein einzelnes 
Bit setzen oder löschen willst. Um einem ganzen Register einen neuen 
Wert zuzuweisen gibt es das wunderbare Kommando 'Write Control 
Register'.

The Bit Field Set (BFS) command is used to set up to
8 bits in any of the ETH Control registers. Note that this
command cannot be used on the MAC registers, MII
registers, PHY registers or buffer memory. The BFS command
uses the provided data byte to perform a bit-wise
OR operation on the addressed register contents.

Und da steckt dann auch die Oder-Operation drinnen, die du anhand deiner 
Daten gesehen hast.

[BerndB (Gast)]

Danke Karl Heinz für den Tip, er wird mir sehr helfen!

Ich habe jetzt herausgefunden das meine "Bit Field Clear" Funktion gar 
nicht richtig funktioniert!
Mal sehen ob ich das hin bekomme!

[Karl H. (kbuchegg)]

Was in die gleiche Kerbe schlägt, wie die Anmerkung von weiter oben.

Warum muss in

  LDI temp_1, (ENC28J60_OP_BF_SET | MAMXFLH)    //0x80 | 0x0B  
  STS (SRAM_OP_CODE), temp_1  
  LDI temp_1, HIGH(1518)              //0x05EE  =  5 238        
  STS (SRAM_DATA_CODE), temp_1          //HIER IST EIN FEHLER ERGEBNIS = 7 statt 5
  
  RCALL WRITE_REGISTER_VALUE

eigentlich das ENC28J60_OP_BF_SET angegeben werden (das ja eigentlich 
ein WRITE REGISTER sein sollte). Da wird doch sowieso eine spezielle 
Funktion zum Beschreiben eines Registers aufgerufen! Den entsprechenden 
Opcode kann auch die Funktion einfügen! Und dann hat man dieses Detail 
an einer zentralen Stelle und muss sich nicht bei jedem Aufruf darum 
kümmern.

[Karl H. (kbuchegg)]

BerndB schrieb:
> Danke Karl Heinz für den Tip, er wird mir sehr helfen!
>
> Ich habe jetzt herausgefunden das meine "Bit Field Clear" Funktion gar
> nicht richtig funktioniert!
> Mal sehen ob ich das hin bekomme!

Wirf sie raus.
Um ein Register zu beschreiben gibt es ein eigenes Kommando!


(Bitfield Clear will genauso wie Bitfield Set ein Argument. Nämlich 
WELCHE Bits zu clearen sind. Das kann ich in deinem Code nirgends sehen.
ABER: Der ganze Ansatz mit den Bitfield Commandos ist schon Unsinn. Es 
gibt ein Commando um ein Register zu beschreiben. Ganz einfach und 
simpel. Du machst dir hier viel zu viel Arbeit selber)

[Karl H. (kbuchegg)]

Hack. Der ganze Bitfield Quatsch zieht sich quer durch deinen ganzen 
Code. Die Bank-Umschaltungen sind auch davon betroffen.

Hast du denn nicht mal anderen Code studiert, wie die das machen, ehe du 
dich auf dieses Abenteuer eingelassen hast?

[BerndB (Gast)]

Karl Heinz,

"genau das war es". BFS anstatt WCR!!!

Ich weiß nicht was mich geritten hat, aber ich habe komischer Weise nur 
für dieses Register den BFS-Befehl benutzt.

VIELEN DANK Karl Heinz!

Gruß,
Bernd