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
1
// File: 18f2620i.lkr
2
// Sample ICD2 linker script for the PIC18F2620 processor
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
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
> 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
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?
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
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
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.
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?
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
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.....?
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....
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
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
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?
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
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
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 :-(
> 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?
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.....
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.....
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 ;)
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....
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
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.
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....
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
1
//Page 4 Column 8
2
3
Feld[72][1].bit0=zustand;
4
5
//Page 3 Column 8
6
Feld[72][3].bit2=zustand;
7
Feld[72][3].bit3=zustand;
8
Feld[72][3].bit4=zustand;
9
Feld[72][3].bit5=zustand;
10
Feld[72][3].bit6=zustand;
11
Feld[72][3].bit7=zustand;
absolut nichts in der Matrix zu suchen.
Genauso wenig wie diese Funktion korrekt arbeitet:
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.
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
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.php/t-51550.html
"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
@ 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
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...)
> (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.
Thread beobachten
Seitenaufteilung abschalten