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
1 | CHANGE_BANK:
|
2 | LDS temp_1, (SRAM_BANK_NUMBER_NEW)
|
3 | LDS temp_2, (SRAM_BANK_NUMBER_OLD)
|
4 |
|
5 | CP temp_1, temp_2
|
6 | BREQ CHANGE_BANK_END
|
7 | TST temp_1
|
8 | BREQ BANK_00
|
9 | CPI temp_1, 1
|
10 | BREQ BANK_01
|
11 | CPI temp_1, 2
|
12 | BREQ BANK_02
|
13 | CPI temp_1, 3
|
14 | BREQ BANK_03
|
15 |
|
16 | ....
|
sowieso mit den Konstanten 0, 1, 2, 3 für die Banknummer vergleichst,
dann solltest du hier beim Aufruf
1 | LDI temp_1, (1<<ENC28J60_BIT_ECON1_BSEL_1)|(0<<ENC28J60_BIT_ECON1_BSEL_0) //Bank 0x02
|
2 | STS (SRAM_BANK_NUMBER_NEW), temp_1
|
3 |
|
4 | 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
1 | LDI temp_1, 2
|
2 | STS (SRAM_BANK_NUMBER_NEW), temp_1
|
3 |
|
4 | RCALL CHANGE_BANK
|
den Kommentar sparen kannst, weil die Bank-Nummer direkt lesbar im Code
steht. Noch besser wäre ein wenig Assembler-Hilfe
1 | LDI temp_1, BANK_2
|
2 | STS (SRAM_BANK_NUMBER_NEW), temp_1
|
3 |
|
4 | 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.
ENC28J60_MAMXFLH.jpg
(54 KB)
