mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Pixelfehler auf Graphikdisplay


Autor: Atomica (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag,

im Anhang befindet sich ein Bild von unserem Projekt. Das soll ein 
kreisförmiges Logo unserer Hochschule darstellen. Das Logo besteht aus 
16 einzelnen Schaufeln. Wir haben alle Schaufeln in eine 72 x 8 Matrix 
eingegeben. Jetzt treten irgendwie totale Pixelfehler auf. Unser 
Dipl.-Ing. vermutet, dass es am Speicher liegt. Wir haben die 
Speicheradressen über die Watch überprüft und müsste echt an diesem 
Problem liegen. Er hat schon ein paar Zeilen im Linker-Skript 
auskommentiert. Wir sollen da ein bisschen rumspielen, damit der 
Speicher die große Matrix packt.

Hier das Linker-Skript vom PIC18F2620

// File: 18f2620i.lkr
// Sample ICD2 linker script for the PIC18F2620 processor

LIBPATH .

FILES c018i.o
FILES clib.lib
FILES p18f2620.lib

CODEPAGE   NAME=vectors    START=0x0            END=0x29           PROTECTED
CODEPAGE   NAME=page       START=0x2A           END=0xFD7F
CODEPAGE   NAME=debug      START=0xFD80         END=0xFFFF         PROTECTED
CODEPAGE   NAME=idlocs     START=0x200000       END=0x200007       PROTECTED
CODEPAGE   NAME=config     START=0x300000       END=0x30000D       PROTECTED
CODEPAGE   NAME=devid      START=0x3FFFFE       END=0x3FFFFF       PROTECTED
CODEPAGE   NAME=eedata     START=0xF00000       END=0xF003FF       PROTECTED

ACCESSBANK NAME=accessram  START=0x0            END=0x7F
DATABANK   NAME=gpr0       START=0x80           END=0xFF
DATABANK   NAME=gpr1       START=0x100          END=0x1FF
DATABANK   NAME=gpr2       START=0x200          END=0x4FF
//DATABANK   NAME=gpr3       START=0x300          END=0x3FF
//DATABANK   NAME=gpr4       START=0x400          END=0x4FF
DATABANK   NAME=gpr5       START=0x500          END=0x5FF
DATABANK   NAME=gpr6       START=0x600          END=0x6FF
DATABANK   NAME=gpr7       START=0x700          END=0x7FF
DATABANK   NAME=gpr8       START=0x800          END=0x8FF
DATABANK   NAME=gpr9       START=0x900          END=0x9FF
DATABANK   NAME=gpr10      START=0xA00          END=0xAFF
DATABANK   NAME=gpr11      START=0xB00          END=0xBFF
DATABANK   NAME=gpr12      START=0xC00          END=0xCFF
DATABANK   NAME=gpr13      START=0xD00          END=0xDFF
DATABANK   NAME=gpr14      START=0xE00          END=0xEF3
DATABANK   NAME=dbgspr     START=0xEF4          END=0xEFF          PROTECTED
DATABANK   NAME=gpr15      START=0xF00          END=0xF7F
ACCESSBANK NAME=accesssfr  START=0xF80          END=0xFFF          PROTECTED

SECTION    NAME=CONFIG     ROM=config

STACK SIZE=0x100 RAM=gpr13







Wäre super, wenn mir jemand weiterhelfen könnte, was ich im 
Linker-Skript verändern muss. An der Eingabe der Matrixelemente liegt es 
10000% ig nicht. DAs haben wir scon überprüft.

Vielen Dank im Vorraus

lg

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du etwas auf das Display schreibst, gibt es dann den gleichen 
Fehler?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>An der Eingabe der Matrixelemente liegt es
>10000% ig nicht. DAs haben wir scon überprüft.

:-) :-) :-)

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wie schon gesagt, ist es eine 72 x 8 Matrix.

Bin in der Watch bis zur Spalte 64 alle Pixel durchgegangen und man 
konnte erkennen, dass sich die Werte von 0 auf 1 wechseln. D.h. er hat 
die 1 in die Matrix geschrieben. Ich bin immer Step für Step 
weitergegangen und mir ist aufgefallen, dass ab Spalte 64 keine 1 
reingeschrieben wird. Er schreibt in dem Bereich nichts in die Matrix 
aber verschiebt diese abgeschnittenen Schaufeln einfach in die Mitte 
(wie man erkennen kann auf dem Bild). Woran könnte das liegen?

Liegt das am Speicher??

Wo oder wie kann ich den vergrößern?

Oder hat jemand ne andere Idee, wie man das lösen kann mit der Matrix?


Wäre echt super, wenn sich jemand melden würde und mir einen sinnvollen 
Vorschlag gibt.

Dankeee

Autor: Magnus Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wäre echt super, wenn sich jemand melden würde und mir einen sinnvollen
> Vorschlag gibt.

Wäre echt super, wenn du mal dein Programm posten könntest. Eine Info 
über den genauen Displaytyp (evtl. mit Link zum Datenblatt) wäre auch 
nicht verkehrt.

Gruß,
Magnetus

Autor: Thomas B. (detritus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie adressiert ihr denn die Matrix intern durch? Kann es sein, dass euch 
ein Index überläuft?

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt ihr schon mal versucht, ein Pixel auf der rechten Displayhäfte zu 
setzen, unabhängig von irgendwelchen Matrizen?  Geht das überhaupt?

Oliver

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein Beispiel für 1 Schaufel:

void Schaufel_1(int zustand)
{
//Page 0 Column 6

Feld[49][0].bit2 = zustand;
Feld[49][0].bit3 = zustand;
Feld[49][0].bit4 = zustand;

Feld[50][0].bit2 = zustand;
Feld[50][0].bit3 = zustand;
Feld[50][0].bit4 = zustand;

Feld[51][0].bit3 = zustand;
Feld[51][0].bit4 = zustand;

Feld[52][0].bit4 = zustand;
Feld[52][0].bit5 = zustand;

//Page 0 Column 5

Feld[41][0].bit7 = zustand;

Feld[42][0].bit6 = zustand;
Feld[42][0].bit7 = zustand;

Feld[43][0].bit4 = zustand;
Feld[43][0].bit5 = zustand;
Feld[43][0].bit6 = zustand;
Feld[43][0].bit7 = zustand;

Feld[44][0].bit3 = zustand;
Feld[44][0].bit4 = zustand;
Feld[44][0].bit5 = zustand;
Feld[44][0].bit6 = zustand;
Feld[44][0].bit7 = zustand;

Feld[45][0].bit2 = zustand;
Feld[45][0].bit3 = zustand;
Feld[45][0].bit4 = zustand;
Feld[45][0].bit5 = zustand;
Feld[45][0].bit6 = zustand;
Feld[45][0].bit7 = zustand;

Feld[46][0].bit2 = zustand;
Feld[46][0].bit3 = zustand;
Feld[46][0].bit4 = zustand;
Feld[46][0].bit5 = zustand;
Feld[46][0].bit6 = zustand;

Feld[47][0].bit2 = zustand;
Feld[47][0].bit3 = zustand;
Feld[47][0].bit4 = zustand;
Feld[47][0].bit5 = zustand;
Feld[47][0].bit6 = zustand;

Feld[48][0].bit2 = zustand;
Feld[48][0].bit3 = zustand;
Feld[48][0].bit4 = zustand;
Feld[48][0].bit5 = zustand;

//Page 1 Column 4

Feld[40][1].bit0 = zustand;
Feld[40][1].bit1 = zustand;
Feld[40][1].bit2 = zustand;
Feld[40][1].bit3 = zustand;
Feld[40][1].bit4 = zustand;
Feld[40][1].bit5 = zustand;
Feld[40][1].bit6 = zustand;
Feld[40][1].bit7 = zustand;

//Page 1 Column 5

Feld[41][1].bit0 = zustand;
Feld[41][1].bit1 = zustand;
Feld[41][1].bit2 = zustand;
Feld[41][1].bit3 = zustand;
Feld[41][1].bit4 = zustand;
Feld[41][1].bit5 = zustand;
Feld[41][1].bit6 = zustand;
Feld[41][1].bit7 = zustand;

Feld[42][1].bit0 = zustand;
Feld[42][1].bit1 = zustand;
Feld[42][1].bit2 = zustand;
Feld[42][1].bit3 = zustand;
Feld[42][1].bit4 = zustand;
Feld[42][1].bit5 = zustand;
Feld[42][1].bit6 = zustand;
Feld[42][1].bit7 = zustand;

Feld[43][1].bit0 = zustand;
Feld[43][1].bit1 = zustand;
Feld[43][1].bit2 = zustand;
Feld[43][1].bit3 = zustand;
Feld[43][1].bit4 = zustand;
Feld[43][1].bit5 = zustand;
Feld[43][1].bit6 = zustand;
Feld[43][1].bit7 = zustand;

Feld[44][1].bit0 = zustand;
Feld[44][1].bit1 = zustand;
Feld[44][1].bit2 = zustand;

//Page 2 Column 4

Feld[40][2].bit0 = zustand;
Feld[40][2].bit1 = zustand;

//Page 2 Column 5

Feld[41][2].bit0 = zustand;
Feld[41][2].bit1 = zustand;
Feld[41][2].bit2 = zustand;

Feld[42][2].bit0 = zustand;
Feld[42][2].bit1 = zustand;
Feld[42][2].bit2 = zustand;
Feld[42][2].bit3 = zustand;

Feld[43][2].bit0 = zustand;
Feld[43][2].bit1 = zustand;
Feld[43][2].bit2 = zustand;
Feld[43][2].bit3 = zustand;
Feld[43][2].bit4 = zustand;
Feld[43][2].bit5 = zustand;

Feld[44][2].bit2 = zustand;
Feld[44][2].bit3 = zustand;
Feld[44][2].bit4 = zustand;
Feld[44][2].bit5 = zustand;
Feld[44][2].bit6 = zustand;

Feld[45][2].bit6 = zustand;
}


Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
union v8bit
{
   struct
   {
       unsigned char bit0 : 1;
       unsigned char bit1 : 1;
       unsigned char bit2 : 1;
       unsigned char bit3 : 1;
       unsigned char bit4 : 1;
       unsigned char bit5 : 1;
       unsigned char bit6 : 1;
       unsigned char bit7 : 1;
   };
   unsigned char _byte;        // word (or int)
};

Autor: Atomica (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich übergebe der Funktion entweder 1 oder 0.

Datenblatt vom Display befindet sich im Anhang


Vielen Dank im Vorraus.

Wie kann ich verhindern, dass die Matrix überläuft?

Autor: Magnus Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, aber entweder bin ich zu doof, oder mit deinem Codeschnipsel kann 
man wirklich nichts anfangen.

Autor: Magnus Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleine Info für meine Kollegen:

Bei dem Displaycontroller handelt es sich wohl um einen S1D10605D04B. 
Wer sich mit dem schon mal beschäftigt hat, darf sich gerne an der 
Problemlösung beteiligen ;)

Gruß,
Magnetus

Autor: hs_mat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau richtig. So heißt der interne Treiber.

Werde nachher versuchen mal auf der rechten seite des displays was 
anzeigen zu lassen unabhängig von der Matrix. Uns ist z.b. aufgefallen, 
wenn wir z.b. nur 1 pixel aus der Schaufel 1 z.b. auskommentieren, dann 
erscheint die Schaufel am richtigen Platz. Sobald ich dieses pixel 
wieder mit reinnehme, wird die ganze schaufel nach links verschoben. 
Kein Plan woran das liegt. Ich geb euch gegen spätnachmittag neue infos.

danke schonmal für die tipps

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stell doch mal den ganzen Code hier rein. Mit dem Ausschnitt kann keiner 
was anfangen.

Oliver

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entweder Stacküberlauf: 72  8  16 = 9216 Bytes (1152 Bytes wenn das 72 
* 8 Bit sind) und die Displayroutinen bauen bei durch 32 teilbaren 
Adressen Mist oder nur letzteres.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne das vollständige Programm kann man nur raten. Das Ganze scheint
aber eher ein Adressierungsproblem zu sein, da die in der Mitte des
Schaufelrads fehlenden Pixel nicht komplett fehlen, sondern am linken
Rand des Displays angezeigt werden.

In der Funktion Schaufel_1() fällt mir auf, dass der erste Index von
Feld[][] für die Column n von 8*n+1 bis 8*n+8 zu laufen scheint. Wäre
ein Bereich von 8*n bis 8*n+7 nicht logischer? Würde das vielleicht
eine horizontale Verschiebung um 8 Pixel nach rechts mit einem
Wrap-around an den Page-Grenzen (auf Grund der Maskierung beim
Schreiben der Adressteile in die Displayregister) erklären?

So ganz passt's mit dieser Erklärung zwar noch nicht, aber vielleicht
ist das ein erster Ansatz. Ich glaube jedenfalls nicht, dass das
Display defekt ist. Der Fehler liegt mit hoher Wahrscheinlichkeit in
eurer Software ;-)

Deswegen musst du uns jetzt endlich verraten, was genau mit den
Inhalten von Feld[][] passiert. Wie werden diese an das Display
geschickt?

Autor: Morpheus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie kann ich verhindern, dass die Matrix überläuft?

Nimm entweder die Blaue oder die Rote Pille ...!

Duck und weg ...

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab auch schon versucht das Logo in 3 horizontale Matrizen aufzuteilen. 
Hat leider auch nicht zum Erfolg geführt. Hätte es vielleicht mehr Sinn, 
das Logo in vertikale Matrizen zu teilen, falls das echt ein Problem ist 
mit der Zahl 32 wie oben genannt.

Im Anhang befindet sich der komplette Quelltext. Man beachte die Dateien 
Schaufeln.c und KSWW_MAIN_C.c


ich probier jetzt mal aus, unabhängig von der Matrix pixel auf dem 
rechten rand des Displays anzeigen zu lassen

meld mich gleich nochmal

Autor: Atomica (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ups hier die datei

Autor: Thomas B. (detritus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
for (i=0; i<=72; i++)    //Spalte
{             
lcd_wrdata(Feld[i][j]._byte);    //Übertragung Daten Matrix 1
}

und
union v8bit Feld[72][8];

Du adressierst das Feld also mit Index 0-72 durch, also 73 Elemente. 
Deklariert ist das Feld mit einem Element weniger.

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das stimmt allerdings. Hab das Feld jetzt mal mit 73 gemacht. Kommen 
aber immernoch die gleichen Effekte. Zuerst mach ich aus der Matrix ja 
ne 0-Matrix. Dann geh ich in die Schaufel 1-16 Routinen und fülle Die 
Matrix mit 0 bzw. 1. Danach schreib ich des aufs Display.


Habe jetzt mal getestet unabhängig von der Matrix einfach mal ein 
Quadrat am rechten Rand des Displays anzuzeigen. Funkioniert perfekt. 
Also liegt definitiv an der Matrix.

Wäre es sinnvoll, das Logo in 3 24x8 vertikalen Matrizen aufzuteilen. 
Wäre nicht sooo viel Arbeit. Aber ob das Sinn macht.....?

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schreib euch mal paar Adressen hin, wo es in die Matrix nichts 
reinschreibt, obwohl es eigentlich sollte:

Adressen z.b. wie

- 409
- 443
- 42D

usw....

Autor: Thomas B. (detritus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atomica wrote:
> Das stimmt allerdings. Hab das Feld jetzt mal mit 73 gemacht. Kommen
> aber immernoch die gleichen Effekte. Zuerst mach ich aus der Matrix ja
> ne 0-Matrix. Dann geh ich in die Schaufel 1-16 Routinen und fülle Die
> Matrix mit 0 bzw. 1. Danach schreib ich des aufs Display.

Ohne Debugger halt schwierig nachzuvollziehen...

Machst du in der startup() nicht eher

- eine Schaufel in die Matrix laden
- die Matrix auf Display schreiben
- die nächste Schaufel rein
.
.
.

Und was macht dann die main()? Zyklisch neuzeichnen?

Was bewirkt
for (i=0; i<=28; i++)    //Spalte
{
lcd_wrdata(0x00);    //Übertragung Daten  
}
in der startup()?

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau, in der Startup geht quasi Schaufel 1 bis 16 nacheinander an. 
Sozusagen als lustiger Startbildschirm. Immer mit nem Delay 
zwischendrin.


for (i=0; i<=28; i++)    //Spalte
{
lcd_wrdata(0x00);    //Übertragung Daten
}


Das bewirkt bloß, dass er in der Mitte vom Display anfängt zum 
schreiben. Als Profi kann man das bestimmt eleganter lösen, aber bin 
Anfänger. tut mir leid.

ich probier jetzt mal, die matrix in 3 vertikale matrizen aufzuteilen.

Ich mach nachher Meldung

Danke

Autor: T. H. (pumpkin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atomica wrote:

> Habe jetzt mal getestet unabhängig von der Matrix einfach mal ein
> Quadrat am rechten Rand des Displays anzuzeigen. Funkioniert perfekt.
> Also liegt definitiv an der Matrix.


Hatte dieses mindestens Quadrat die selben Abmaße wie das Logo? Das 
riecht extrem nach einer fehlerhaften Adressierung deiner Bitmap. Leider 
ist das so schräg programmiert, dass ich da nicht durchblicke. Wieso 
legst du das Logo nicht als ein großes Array ab und schreibst es am 
Stück, oder sollen die Schaufeln nacheinander eingeblendet werden?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry aber nach "Pixelfehler" sieht das nicht aus. Falsch angesteuert 
oder falsche Daten. Einfacher Test: Alle Pixel schwarz und alle weiss 
schalten. Wenn es das tut ist der Speicher offensichtlich OK.

Gruss,
Michael

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
All Pixel on funktioniert.

p.s. das Logo ist in einem großen Array abgelegt

Autor: Thomas B. (detritus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du das Problem mit den verschobenen Schaufeln nur in der main() 
oder auch in der startup()?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so so die Herren der FH Ulm. :-)

Autor: Magnus Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atomica wrote:
> All Pixel on funktioniert.

Schön. Aber das ist eine Hardwarefunktion des Controllers.

Nun fülle mal dein komplettes Array mit 0xFF und übertrage es an das 
Display. Wenn dann die rechte Hälfte tot bleibt, hast du halt einen 
Programmfehler im Bereich der Bilddatenschaufelei µC --> Display.

Gruß,
Magnetus

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HS Ulm lieber Gast :-). Gut erkannt.

Hab jetzt in die komplette Matrix 0xFF reingeschrieben. Wird auf dem 
Display auch richtig angezeigt. Komplett schwarzes Quadrat.

Langsam weiß ich echt nicht mehr weiter :-(

Die Idee mit der Aufteilung in 3 vertikalen Matrizen bringt genau die 
gleichen fehler :-(

Autor: Magnus Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hab jetzt in die komplette Matrix 0xFF reingeschrieben. Wird auf dem
> Display auch richtig angezeigt. Komplett schwarzes Quadrat.

Du hast aber das Kommando "All pixel on" vorher wieder raus genommen, 
oder?

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach was ich ganz vergessen habe.

Die Pixel sind nicht Quadratisch, was dazu führte, dass das runde Logo 
bisschen eingedrückt wirkte. Diese Matrix hatten wir letzte Woche mit 
der ganz gleichen Taktik in eine einzige Matrix eingegeben. Dort trat 
nur ein Fehler in Schaufel 8 auf. Die Schaufel wurde auch nach links 
verschoben.

Jetzt haben wir ne neue Matrix geschrieben nach der ganz gleichen Taktik 
und gleiches Vorgehen, bloß dass sich die Matrix logischerweise in der 
Breite vergrößert hat (von 64 Breite auf 72 Breite). Und jetzt kommen 
noch mehr Fehler, wie man im oberen Bild sieht.

Also die erste matrix hat garnicht schlecht ausgesehen.

muss doch am speicher liegen???

Kann man da nicht tricksen?

hat noch keiner was zu meinem linkerskript header gesagt?

unser dipl.-ing hat da was verändert. Das könnte man manipulieren hat er 
gesagt.....

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau  Magnus Müller, hab das Command wieder rausgemacht,

Dann in die komplette Matrix ne 1 geschrieben und dann mit nem 
Breakpoint nur bis zu der Zeile ablaufen lassen. Da wurde alles schwarz 
angezeigt. Eigentlich super.

Weißt wenn ich die ganze schaufelfunktionen durchgehe und die ganzen 
Aktionen in der Watch beochate, ist klar ersichtlich, wie die ganzen 1en 
in die Matrix geschrieben werden. Sobald ich zu Column 8 komme, schreibt 
er nix rein und alle bits bleiben bei 0x00. Des kann doch nciht sein. 
Bei allen anderen Matrixelementen klappt es doch.....

Autor: Thomas B. (detritus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du im Debugger den RAM anschauen?

Dein Fehler scheint aufzutauchen, sobald der erste Index deiner Matrix 
über ~65 geht. Es scheint also einfach der Speicher voll zu sein.

Guck doch mal, wo die "fehlenden" 1en hingeschrieben werden.


>HS Ulm lieber Gast :-). Gut erkannt.

Insider sehen das auch schon an dem Schaufelrad ;)

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau Thomas, z.b. ab Spalte 65 spinnt es. er verschiebt die 
Schaufelelemente, die ab spalte 65 kommen einfach automatisch in die 
Mitte auf ca. Spalte 35 oder so.

Was kann man dagegen tun, wenn der Speicher voll ist?

Kann man den nicht erhöhen, Manipulieren, etc????

wird das in der Linkerdatei gemacht?

Schau dir mal oben das Linker-skript an. Unser Dipl.-Ing. hat die zwei 
zelen auskommentiert und eine Zeile drüber irgendeine Zahl verändert....


Gute Frage, ob ich im Debugger den Ram anschauen kann, ich weiß es nicht 
wie es geht....

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ein Auszug aus dem Datenblatt des MC PIC18F2620

Program Memory (Bytes): 65536
Data Memory (Bytes): 3968

Autor: Thomas B. (detritus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dafür sollte man sich mit der PIC-Architektur auskennen... Kann ich zwar 
nicht von mir behaupten, aber ich versuchs mal:

Wenn ich das DB richtig verstehe, ist der RAM in Blöcke a 256Byte 
unterteilt und diese Blöcke heissen GPR. (-->Linker-File)

Über einen Block kommst du augenscheinlich problemlos drüber, aber beim 
Wechsel auf den dritten hängts wohl.

72x8=576Bytes-->2GPRs+64Bytes. Und diese 64Bytes sind 8 Matrixzeilen. 
73-8=65! Das ist so der Index, ab dem es kracht.

Wenn du 8 Matrixzeilen weniger machst, geht es dann?

DB S.59

Autor: Dieter Werner (dds5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die 256 Byte gpr RAM-Blöcke sind nur bei direkter Adressierung von 
Interesse (wegen 8 Bit Adressfeld im Befehl), indirekt kann man alle RAM 
Adressen erreichen (über die 3 pointer mit Namen fsr).

Es sollte also auch möglich sein, mehr als 256 Byte zu einem gpr Bereich 
zusammen zu fassen.
Kann aber sein, dass man dazu ein anderes memory model wählen muss.

Autor: Atomica (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab ich jetzt nicht ausprobiert. Aber die alte Matrix von letzte Woche 
War ein Array 64 x8. Da ging die Matrix bis 64 und kamen nur leichte 
Fehler in der Grafik. Wir wollten das ja nur neu machen, weil das Logo 
eingestaucht war wegen der nichtquadratischen Pixelform. Die Frage ist, 
welche Paramter ich verändern muss/darf in dem Linkerskript, um den 
Fehler zu vermeiden....

Ich frag mal morgen nochmal den Dipl.-Ing. und geb dann Feedback hier.


Vielen Dank schonmal für die super Hilfe....

Bis morgen schlaft gut....

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleine Anmerkung: In Schaufel_8 ist ein Fehler:
  Feld[46][7].bit0 = zustand;
  Feld[46][7].bit1 = zustand;
  Feld[46][7].bit2 = zustand;
  Feld[46][1].bit3 = zustand;
           ^
Betrifft aber nicht das eigentliche Problem.

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich mag ja nur ein blöder Delphi Entwickler sein und meine C-Kenntnisse 
sind eher bescheiden, aber ein Array [72][8] hat doch 0 bis 71 und 0 bis 
7 Elemente?

Wenn das korrekt ist, dann haben die Zeilen
//Page 4 Column 8

Feld[72][1].bit0 = zustand;

//Page 3 Column 8
Feld[72][3].bit2 = zustand;
Feld[72][3].bit3 = zustand;
Feld[72][3].bit4 = zustand;
Feld[72][3].bit5 = zustand;
Feld[72][3].bit6 = zustand;
Feld[72][3].bit7 = zustand;

absolut nichts in der Matrix zu suchen.

Genauso wenig wie diese Funktion korrekt arbeitet:
void FieldsInit(void)
{
  int i,j;
  for (j=0; j<=7;j++)
  {    
    for (i=0; i<=72; i++) //Spalte
    {
      Feld[i][j]._byte = 0x00;//0-Matrix
    }
  }
}

Gruß
Frank

Autor: Thomas B. (detritus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Link wrote:
> Hallo,
> ich mag ja nur ein blöder Delphi Entwickler sein und meine C-Kenntnisse
> sind eher bescheiden, aber ein Array [72][8] hat doch 0 bis 71 und 0 bis
> 7 Elemente?


Es wird Speicherplatz für 72x8 Bytes reserviert, die man mit den Indizes 
0 bis 71 sowie 0 bis 7 ansprechen kann.
Das Problem mit den zu großen Indizes hatten wir aber schon 
angesprochen.

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,
Du hattest tatsächlich den Indexfehler in der Funktion angesprochen, 
aber den Indexfehler in der Arraydefinition hat noch keiner 
angesprochen. Meine Vermutung ist lediglich, dass hier Pixel auf 0 
gesetzt werden, die eigentlich auf 1 gesetzt werden sollten. Wobei ich 
natürlich nicht weiß, was passiert, wenn auf ein Arrayindex zurück 
gegriffen wird, dass es nicht gibt. Meine Vermutung ist, dass je nach 
Anordnung ein Bit der Nachbarmatrix adressiert wird. Leider hat c keine 
so strikte Überprüfung von Arrayindizes wie Pascal.

Gruß
Frank

Autor: Thomas B. (detritus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atomica wrote:
> Das stimmt allerdings. Hab das Feld jetzt mal mit 73 gemacht. Kommen
> aber immernoch die gleichen Effekte.

Hätt ich jetzt so interpretiert, dass er die Matrix größer gemacht hat, 
wodurch alle Funktionen, die aus der Matrix lesen oder reinschreiben, 
das Problem nicht mehr haben und die Matrix bis zum Index 72 
durchadressieren können.

Dass es keinen Unterschied macht, heist wohl, dass nach der Matrix nix 
mehr im Speicher kommt.

ok, mal google angeworfen->auf das Problem sind schon andere gekommen:

http://www.chiefdelphi.com/forums/archive/index.ph...


"You are only able to declare 256 bytes of variable space in any one 
MPLAB project file."

That is the default. The default is based upon the h/w architecture 
having 256 byte ram banks. PIC18F instructions have 8bit ram address 
offset hence the default of 256 byte banks. However, you can override by 
changing the setup in the lkr file.

This shouldn't be done lightly because it introduces more overhead in 
accessing data - but you essentially tell the linker to merge two 
adjacent ram banks and treat them in software as a single resource. 
Refer to the C18 user guide.

Changed 18f8722.lkr:
DATABANK NAME=gpr2 START=0x200 END=0x2FF
DATABANK NAME=grp3 START=0x300 END=0x3FF
DATABANK NAME=gpr4 START=0x400 END=0x4FF
To:
DATABANK NAME=gpr2 START=0x200 END=0x3FF
DATABANK NAME=gpr4 START=0x400 END=0x4FF


created:
static unsigned char bigarray[500];

Build project, map file shows:

bigarray 0x000202 data static user_routines.c
i 0x0003f6 data static user_routines.c

x3f6-x202 = 500 byte array. Compiles/links/runs ok. I read about this in 
the C18 user guide somewhere. Currently only the "3.2.4 Managing the 
Software Stack" section jumps out at me - but it shows the steps for 
doing the same thing to create larger stack areas. Ram is a limited 
resource... use it wisely.

Bud

Autor: Atomica (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@ Yalu: Danke für den Tipp. War echt ein Fehler. Aber kein Wunder, hab 
das ganze Wochenende alle Möglichkeiten von Matrizen ausprobiert. 
Irgendwann verblödet man vor lauter Matrix. Also die 1 sollte echt eine 
7 sein. DANKESCHÖN

@all: Das Array sollte echt 73 x 8 sein und nicht 72 x 8


Nun zur Aufklärung des Problems. Es lag echt nicht an der Matrix sondern 
an der Speicheraufteilung mit diesen Banks wie schon oben angesprochen.

Man musste lediglich "BSR++;" bzw. "BSR--;" reinschreiben.

Hab bei jeder Schaufel geschaut, wo die Spalten größer wie 64 werden, 
davor einfach BSR++; eingeben. Genau das gleiche vor Spalte 32. Kann die 
nächsten Tage mal ein Beispiel hochladen an einer Schaufel.

Es funktioniert zwar, aber so zu 100 % verstanden hab ich das noch 
nicht. Man schiebt die betreffende Matrixelemente einfach in die nexte 
Databank oder?


Funktioniert jetzt alles perfekt und die schaufeln gehen je nach Neigung 
der Platine an oder aus. Elektronische Wasserwaage mit Displayanzeige.

Im Anhang befindet sich ein Bild (sorry ziemlich unscharf)


An dieser Stelle wollte ich allen extrem danken für die schnelle und vor 
allem kompetente Hilfe.

In anderen Foreneinträgen hab ich sehr schlechte Erfahrungen gemacht, 
weil einem keiner Tipps geben will, wenn man merkt, dass man Anfänger 
ist.

Daher DAUMEN hoch.

Tolles Forum....

liebe grüße Matthias


p.s.: Beispielschaufelcode lad ich morgen noch hoch, falls es jemand 
interessiert

Autor: Thomas B. (detritus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atomica wrote:

>
> Man musste lediglich "BSR++;" bzw. "BSR--;" reinschreiben.
>
> Hab bei jeder Schaufel geschaut, wo die Spalten größer wie 64 werden,
> davor einfach BSR++; eingeben. Genau das gleiche vor Spalte 32. Kann die
> nächsten Tage mal ein Beispiel hochladen an einer Schaufel.
>
> Es funktioniert zwar, aber so zu 100 % verstanden hab ich das noch
> nicht. Man schiebt die betreffende Matrixelemente einfach in die nexte
> Databank oder?


Der Ram ist offensichtlich in Einheiten von 256 Byte unterteilt. In 
diesen kann man mit nem 8bit-Wert adressieren, was auf der 
pic-architectur wohl schnell ist. Jeder Block wird jeweils mit einem 
Wert von den 4Bits des BSR-Reg angeprochen, innerhalb des Blockes wird 
mit den 8bit adressiert.

Will man grössere Blöcke, sagt man das dem Linker. Dazu gibt man Start- 
und Endadresse des gewünschten Blockes an. Dann muss der PIC halt mit 
mehr bits adressieren, was eben länger dauert. Das habt ihr wohl in 
eurem Linkerfile für 2 Blocks gemacht, nicht aber für 3, was wohl nötig 
gewesen wäre.
Aber kein Plan, wie man den Compiler zwingt, die riesen Matrix dann 
ausgerechnet in den grossen Block zu legen.

Alternativ kann man die Bänke mit dem BSR durchadressieren. Und das 
machst du wohl jetzt durch das BSR++, wenn der Index zu groß wird und du 
die Bereichsgrenze überschreitest.


> An dieser Stelle wollte ich allen extrem danken für die schnelle und vor
> allem kompetente Hilfe.
>
> In anderen Foreneinträgen hab ich sehr schlechte Erfahrungen gemacht,
> weil einem keiner Tipps geben will, wenn man merkt, dass man Anfänger
> ist.
>
> Daher DAUMEN hoch.
>
> Tolles Forum....
>
> liebe grüße Matthias

Kein Ding, war doch interessant :D

(Jetzt weis ich, dass es gut war, als ich mich für AVR/8051 statt PIC 
entschieden hab...)

Autor: Dieter Werner (dds5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> (Jetzt weis ich, dass es gut war, als ich mich für AVR/8051 statt
> PIC entschieden hab...)

Guter Spruch ... ist wohl mit Augenzwinkern gemeint.

Über AVR kann (besser will) ich nichts sagen - kenn ich nicht, aber der 
8051 ist ja nun nicht so der Brüller wenn es um die Adressierung von 
Daten im (internen oder externen) XRAM geht.

Das soll jetzt aber bitte kein Anstoß zu einer neuen AVR vs PIC 
Diskussion sein, die gab es hier im Forum schon bis zum Abwinken.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.