Access Violation in 2D-Array-Berechnung

Hi!

Ich habe hier ein problem, hinter das ich nicht so ohne weiteres komme:

Code:

---

Ycount = Ycount - 1                                'Muss um 1 verringert werden...

        Rda2 = Ycount * 16                                'Berechnung für das 2D-Array.
        Rda2 = Rda2 + Xcount                              'Wir 'benutzen RDA2 (da WORD-Variable)

        Ycount = Ycount + 1

        Incr 2darea(rda2)

---

Da BASCOM keine 2D-Arrays unterstützt habe ich mir versucht, selber eins zu basteln 2Darea ist eine Bytevariable mit 256 Units.
Xcount und Ycount werden maximal 16 groß.
xerhöht sich immer um 16, danach wirds wieder auf 1 gesetzt und Ycount um 1 erhöht.
Aber xcount kann sich so erhöhen wie's will, rda2 geht nicht nach oben.

Kann das irgendwie am Stack liegen?
Manchmal geibts auch eine Access Violation und der AVR stürzt ab.

Danke schonmal!

VLG Tobi

Ich würde mal empfehlen, X u. Y mit den werten 0-15 zu belegen, das ist insgesamt einfach logischer und einfacher.
Nur VOR DEM ZUGRIFF auf die Tabelle würd' ich den Wert RDA2 um 1 erhöhen, damit der Bascom friedlich bleibt.
Sonst ist deine Berechnung richtig, das Problem muß woanders liegen (DIM ?)

Was anderes: Hast du schon überlegt, EIN byte für den Zugriff zu verwenden, Hi-Nibble = X und Lo-Nibble = Y ?
Für den fall 16 * 16 ist das einiges flotter

Hi!

Ja, ist mir eigentlich auch schleierhaft.
vor allem, weil die Variablen nicht zählen, wenn sie eigentlich sollten.

Könnte das mit dem Stack zusammenhängen? Dass der irgendwie überlastet wird?
Also ich denke, dass es irgendeine Zugriffsverletzung gibt, obwohl das eigentlich nicht sein kann.

>>Hast du schon überlegt, EIN byte für den Zugriff zu verwenden, Hi-Nibble = X und Lo-Nibble = Y ?
>>Für den fall 16 * 16 ist das einiges flotter
Wie meinst du das?

VLG Tobi

EDIT:

DAS IST DER 1000. BEITRAG!!!
Ich gebe einen aus...
Bild hier  
Prost!

Hi!

Ich habe mir da mal ein par Debugging-Ausgaben machen lassen.

Code:

---

<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>4 , 0
<\f>1
<\f>4 , 0
<\f>1
<\f>4 , 0
<\f>1
<\f>4 , 0
<\f>1
<\f>4 , 0
<\f>1
<\f>4 , 0
<\f>1
<\f>4 , 0
<\f>1
<\f>4 , 0
<\f>1
<\f>5 , 0
<\f>1
<\f>5 , 0
<\f>1
<\f>5 , 0
<\f>1
<\f>5 , 0
<\f>1
<\f>5 , 0
<\f>1
<\f>5 , 0
<\f>1
<\f>5 , 0
<\f>1
<\f>5 , 0
<\f>1
<\f>6 , 0
<\f>1
<\f>6 , 0
<\f>1
<\f>6 , 0
<\f>1
<\f>6 , 0
<\f>1
<\f>6 , 0
<\f>1
<\f>6 , 0
<\f>1
<\f>6 , 0
<\f>1
<\f>6 , 0
<\f>1
<\f>7 , 0
<\f>1
<\f>7 , 0
<\f>1
<\f>7 , 0
<\f>1
<\f>7 , 0
<\f>1
<\f>7 , 0
<\f>1
<\f>7 , 0
<\f>1
<\f>7 , 0
<\f>1
<\f>7 , 0
<\f>1
<\f>8 , 0
<\f>1
<\f>8 , 0
<\f>1
<\f>8 , 0
<\f>1
<\f>8 , 0
<\f>1
<\f>8 , 0
<\f>1
<\f>8 , 0
<\f>1
<\f>8 , 0
<\f>1
<\f>8 , 0
<\f>1
<\f>9 , 0
<\f>1
<\f>9 , 0
<\f>1
<\f>9 , 0
<\f>1
<\f>9 , 0
<\f>1
<\f>9 , 0
<\f>1
<\f>9 , 0
<\f>1
<\f>9 , 0
<\f>1
<\f>9 , 0
<\f>1
<\f>10 , 0
<\f>1
<\f>10 , 0
<\f>1
<\f>10 , 0
<\f>1
<\f>10 , 0
<\f>1
<\f>10 , 0
<\f>1
<\f>10 , 0
<\f>1
<\f>10 , 0
<\f>1
<\f>10 , 0
<\f>1
<\f>11 , 0
<\f>1
<\f>11 , 0
<\f>1
<\f>11 , 0
<\f>1
<\f>11 , 0
<\f>1
<\f>11 , 0
<\f>1
<\f>11 , 0
<\f>1
<\f>11 , 0
<\f>1
<\f>11 , 0
<\f>1
<\f>12 , 0
<\f>1
<\f>12 , 0
<\f>1
<\f>12 , 0
<\f>1
<\f>12 , 0
<\f>1
<\f>12 , 0
<\f>1
<\f>12 , 0
<\f>1
<\f>12 , 0
<\f>1
<\f>12 , 0
<\f>1
<\f>13 , 0
<\f>1
<\f>13 , 0
<\f>1
<\f>13 , 0
<\f>1
<\f>13 , 0
<\f>1
<\f>13 , 0
<\f>1
<\f>13 , 0
<\f>1
<\f>13 , 0
<\f>1
<\f>13 , 0
<\f>1
<\f>14 , 0
<\f>1
<\f>14 , 0
<\f>1
<\f>14 , 0
<\f>1
<\f>14 , 0
<\f>1
<\f>14 , 0
<\f>1
<\f>14 , 0
<\f>1
<\f>14 , 0
<\f>1
<\f>14 , 0
<\f>1
<\f>15 , 0
<\f>1
<\f>15 , 0
<\f>1
<\f>15 , 0
<\f>1
<\f>15 , 0
<\f>1
<\f>15 , 0
<\f>1
<\f>15 , 0
<\f>1
<\f>15 , 0
<\f>1
<\f>15 , 0
<\f>1
<\f>16 , 0
<\f>1
<\f>16 , 0
<\f>1
<\f>16 , 0
<\f>1
<\f>16 , 0
<\f>1
<\f>16 , 0
<\f>1
<\f>16 , 0
<\f>1
<\f>16 , 0
<\f>1
<\f>16 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>1 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>2 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>3 , 0
<\f>1
<\f>3 , 0  //Hier fängt es plötzlich an zu funktionieren!
<\f>3
<\f>3 , 0
<\f>3
<\f>3 , 0
<\f>3
<\f>3 , 0
<\f>3
<\f>4 , 0
<\f>4
<\f>4 , 0
<\f>4
<\f>4 , 0
//So geht das lustig weiter bis in alle Ewigkeit.

---

Format:
xcount , ycount
rda2

Was kann denn da nur falschlaufen?

Danke!

VLG Tobi

1 Den Stack kannst du nicht überlasten, der schreibt im Zweifelsfall einfach deine Daten nieder und wackelt mit keiner Borste dabei.
Symptom---> Programm verhält sich wirr
2 Zugriffsverletzungen kennt der AVR auch nicht wirklich, das ist irgendeine Spinnerei vom Simulator, nehm ich an.
Vielleicht prüft er, ob den Tabellenindex irgendwannmal > als 256 ist (du hast ja ein Word definiert) ?

In diese Bredouille kannst du kommen, wenn du in deiner Rechnung den Xcount von 1 - 16 nimmst , da gehört auch -1, also 0 - 15

Ein Byte:
Du hast 16 Elemente (0-15), die 16 Byte lang sind (0-15)
Dein RDA2 = Y * 16 + X, dabei kann rauskommen 0-255
na, das ist ja offensichtlich ein einzelnes Byte
Zugiff natürlich dann BasCommäßig 1-256

Hi!

Dim 2darea(256) As Byte
So ist das gedimmt.

Er zählt von 1-16, ich werde das mal kurz ändern.

VLG Tobi

Hallo Tobi,

Ich habe mal Funktionen zu 2D-Array geschrieben, welche Du hier http://www.grote.net/bascom/msg18130.html.
Vielleicht kannst Du etwas davon gebrauchen.

HI!

Du warst das? Na da hab ich's abgeschrieben... :D
Naja, aber ich glaube, dass es noch an meiner etwas komplexen zählweise liegt.
Ich weis nicht, obs mir was bringt, aber ich werd mal alle incrs durch x = x + 1 ersetzen, oder gleich in ASM schreiben.

sehr ominös bis jetzt...

VLG Tobi

Vielleicht kannst Du mal soviel vom Code publizieren, dass ich das Problem bei mir nachvollziehen kann?

Hi!

Ich kann euch verstehen, aber das problem ist, dass es sich bei den paar zeilen code, um die's geht um mein JuFo-Projekt geht.
Das hat zwar damit nicht so viel zu tun, aber... !

hm. Ich habe gerade was geändert, hm.
mal sehen, ich mache nal einen test.

Hi!

Jaaaaaa!
Es funktioniert!
Ich hatte noch ne dumme IF drin, die die Berechnung nur dann startet, wenn sie auh gebraucht wird. Das habe ich zur Zeitersparnis gemacht.
naja, jetzt siehts auf jeden Fall gut aus.
hatte das problem, dass ein auslesen aus einem externen Ram nur ncoh Müll zu Tage förderte...

Aber jetzt gehts. warscheinlich, weil die Zähler nciht über 16 Zählen... :D

Naja, dann wurde die Variable zu groß, und dann gabs eine Zugriffsverletzung. So schätz ich mal.

Ncoh eine dumme Frage: Bascom legt ja seine Variablen im Ram ab. Auch Arrys. Dann kann ich beim M8 also locker ein kb an Variablen deklarieren, ohne die irgendwie auslagern zu müssen, gell?!

VLG Tobi

Wenn für den Stack noch genug überbleibt, sicher

Hi!

Welcher den Soften oder den HW-Stack?
HW steht auf 64, der softe auf 32.

naja, ich weis nciht, aber er scheint mit der Berechnung schon ausgelastet zu sein...

VLG Tobi

Das zählt zusammen.
https://www.roboternetz.de/wiki/pmwi...in.Bascomstack

Hi!

Ahja! Gute Wikiseite!
Kann man sich irgendwo anzeigen lassen, wie viel Platz man noch für den Stack hat?
Hm. ich glaube, ich mach den nochmal ein Bisschen größer. Obwohls jetzt eigentlich recht zufriedenstelend funktioniert!

VLG Tobi

Zitat:

---

Zitat von tobimc

Gute Wikiseite!

---

Danke, man hat sich bemüht. :mrgreen:

Ich mach die Stacks immer so groß wie irgend möglich.

In der RPT-File sagt der BasCom ja, wie viel SRAM er belegt. da leg ich ein paar zerquetschte drauf, und der Rest geht an den Stack.

HI!

Ja, ich sehs! *good work!*

Wie erklärt man sich dasda:

Zitat:

---

--------------------------------------------------------------------------------
Warnings:
--------------------------------------------------------------------------------
HWSTACK not used
SWSTACK not used
FRAME not used
COUNTER2 not used
PWM2 not used

---

?!

Woanders (weiter oben) aber:

Zitat:

---

Stack start : 45F hex
Stack size : 40 hex
S-Stacksize : 10 hex
S-Stackstart : 420 hex
Framesize : 20 hex
Framestart : 3FF hex

---

...?

Naja, es scheint ja zu funzen.
Meckert Bascom nciht, wenn der Stack zu klein ist?

VLG Tobi

Zitat:

---

Zitat von tobimc

not used

---

dieses Geheimnis ist mir verborgen geblieben

Zitat:

---

Zitat von tobimc

meckert BasCom nicht ?

---

Nein. Stack wird erst im Laufen verbraucht, je nach call und return. Das Nachrechnen wäre eine Schweinearbeit und außerdem sehr theoretisch.
Es gibt da im Help unter "STKCHECK" was, aber das war mir zu hoch.
Ich würde eher als letztes im SRAM ein fixes Feld definieren und gelegentlich prüfen. wenn es sich ändert, muss es der Stack niedergeschrieben haben, dann kann ich "Feuer" schreien.

Hi!

>>dann kann ich "Feuer" schreien
Was schrei' ich dann? Wasser marsch?! :D

Naja, aber es wird nicht mehr Stack verbraucht, je öfter man einen call macht oder Funktionen aufruft?!

VLG Tobi

Hauptsächlich dann, wenn die aufgerufene Funktion wiederum "Call" macht, usw. Und wenn dann ein Interrupt zuschlägt, verbraucht der mindestens 32 Byte HwStack zum Sichern der Register. Soft-Stack geht hauptsächlich drauf, wenn man viele Funktions-Argumente und/oder lokale Daten hat.
Und dann ist noch die Dunkelziffer, was der BasCom in seinen eigenen Routinen an fortlaufenden "Calls" macht.
Man kann das schon einigermaßen ausrechnen, aber mitten in der Programm entwicklung nervt das. Da mußt du richtig im Simulator steppen und mitzählen.

Wasser marsch ist gut, durch Feuchtigkeit kann man den Stackverbrauch schlagartig stoppen. :mrgreen:

Hi!

icnterrupts benutze ich eigentlcih keine, sind aber noch geplant...
(Aber auch nur der ADC-Interrupt, und der nur in einem ganz bestimmten Bereich...)

>>Soft-Stack geht hauptsächlich drauf, wenn man viele Funktions-Argumente und/oder lokale Daten hat.
naja, abrbeite viel mit call.

>>Da musst du richtig im Simulator steppen und mitzählen.
na, den kann ich sowieso nciht benutzen, weil ich auf viel externe Hardware zugreife, und ohne die würde die gesamte Software eh nicht funzen...
(Ausserdem ist das recht prozessorbelastend, für eine komplette Simulation brauch ich schätz ich jetzt einfach mal so 1-2Tage...)

>>Wasser marsch ist gut, durch Feuchtigkeit kann man den Stackverbrauch schlagartig stoppen.
ja, uns sie spart das lästige abschalten nach dem Benutzen....... :D

Thanks!

VLG Tobi