www.mikrocontroller.net

Forum: Compiler & IDEs pgm_read_byte(); --> Nur für Lower 64k Flash (mega128)???


Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Ich schreibe schon seit einiger Zeit an einem Projekt mit resistiv
touch, T6963 Grafik kontroller basierendem 240 x 128 pixel display
usw....
Als Controller verwende ich den ATmega128 mit Bootloader von MicroSyl.

Ich habe mittlerweile ein für meine Verhältnisse großes Menü aufgebaut
mit insgesammt 15 verschiedenen bmp's  a 4096 Bytes groß. Diese lege ich
als Arrays im Flash ab und habe sie bisher immer mit der funktion
pgm_read_byte(); ausgelesen und byte für byte ans Grafikram vom LCD
übertragen. Seit mein code (mit den Arrays) die 299pages (?) grenze
erreicht hat kommt beim übersetzen die Fehlermeldung:

C:\*\Temp/ccWAaaaa.s: Assembler messages:
C:\*\Temp/ccWAaaaa.s:97691:
Error: value of 67785 too large for field of 2 bytes at 7852
C:\*\Temp/ccWAaaaa.s:138:
Error: value of 67785 too large for field of 2 bytes at 0

Als IDE verwende ich die neueste WinAVR Version.

Ich sehe zwar dass 67785 zu viel für eine integer variable ist (65535 =
0xffff) aber ich weiß nicht wo das passiert!
Kann es sein dass die funktion pgm_read_byte(); nur auf die Lower 64k
Flash ausgelegt ist oder gibts da andere bekannte Fehler die ich gemacht
haben könnte?.

Ich würde den Quelltext gerne schicken aber der ist fast noch nicht
kommentiert und der würde wahrschenlich nicht viel bringen!

Welchen externen Speicherbaustein (am liebsten IIC) würdet ihr mir für
die zukunft vorschlagen?
HAb zwar schon ein 24C64 I²C EEPROM zum Temperatur loggen dranhängen
aber bei 400KHz Max. Clock leidet der Datendurchsatz für "Bewegte
Bilder" ganz schön.

Danke schonmal im Vorraus,

MainSter

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probier's doch mal mit pgm_read_byte_far().

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, da hab ich wohl wieder zu wenig gelesen.... aber an der 
Fehlermeldung vom compiler hats nichts geändert.

Wenn ich das 15. Array komplett aus meinem Code nehme kommt die 
fehlermeldung nicht mehr.
Hab mir in die Arrays mal 'Strings' reinkopiert und mir des ganze in 
Ponyprog mal angeguckt. Das 15. Array liegt an  0x0FFD0  bis   0x10FD0.
Dann müsste ich jetzt ein teil des Arrays mit pgm_read_byte() und den 
anderen mit pgm_read_byte_var() auslesen oder gibt es eine möglichkeit 
dem array zu sagen wo es liegen soll?

Danke für die schnelle Antwort!

MFG MainSter

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dann müsste ich jetzt ein teil des Arrays mit pgm_read_byte() und den
> anderen mit pgm_read_byte_var() auslesen

Warum?

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> pgm_read_byte_var()
Wenn Du das im Programm auch so geschrieben hast, dann ist es klar, dass 
Du ne Fehlermeldung bekommst...

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ johnny.m: Nein, war ein tippfehler im Forum!

@ Rolf Magnus: eben weil ich so wie ich mitgekriegt hab mit 
pgm_read_byte() nicht aus den oberen 64k lesen kann oder nicht?


mfg Mainster

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was Rolf wohl meint: Man kann mit den far-Versionen auch aus den unteren 
64KB lesen.

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahh....
Danke. Dass kann man aus der libc doku nicht eindeutig herrauslesen, 
oder?
Ich hab gelesen dass es effektiver ist die near version zu benuten!

Jetzt könnte ich doch meinen executable code in die ober 64k schreiben 
und die bmp's in den unteren 64k ablegen?! Funktioniert es dann noch mit 
dem pgm_read_byte_near() ?

Und, wie müsste ich dass genau machen? Muss ich da wirklich mit dem 
RAMPZ bit rumspielen?


• Bit 0 – RAMPZ0: Extended RAM Page Z-pointer
The RAMPZ Register is normally used to select which 64K RAM Page is 
accessed bythe Z-pointer. As the ATmega128 does not support more than 
64K of SRAM memory,this register is used only to select which page in 
the program memory is accessed whenthe ELPM/SPM instruction is used. The 
different settings of the RAMPZ0 bit have the
following effects:

RAMPZ0 = 0: Program memory address $0000 - $7FFF (lower 64K bytes) is
accessed by ELPM/SPM
RAMPZ0 = 1: Program memory address $8000 - $FFFF (higher 64K bytes) is
accessed by ELPM/SPM

Note that LPM is not affected by the RAMPZ setting.

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und, wie müsste ich dass genau machen? Muss ich da wirklich mit dem
> RAMPZ bit rumspielen?
Wieso dieses? Das macht doch die entsprechende Funktion für Dich. Der 
Unterschied zwischen den near- und far-Versionen ist im Prinzip 
lediglich, dass die near-Versionen den lpm-Befehl verwenden (der mit 
einer 16-Bit-Adresse arbeitet und dementsprechend nur bis 64 K 
adressieren kann) und die far-Versionen den elpm-Befehl, der in 
Zusammenarbeit mit dem RAMPZ-Register den Rest erledigen kann.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> und die bmp's in den unteren 64k ablegen?!

Genau das machen die normalen pgmspace-Routinen und -Makros.  Da es
kein Problem ist, Code oberhalb 64 KiB anzusiedeln und auszuführen,
werden Daten (also "progmem") vorzugsweise vor den Code gelinkt
(Ausnahme: die Interruptvektortabelle und der Startupcode sind noch
davor).

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahh, ok... So langsam wirds heller!
Also das sinnvollste wäre wie oben beschrieben die Arrays in die lower 
64k zu linken. Das hab ich halt auch nochdie gemacht... Ich weiß dass 
"linken" was mit dem Compiler und der makefile zutun hat...
Kann mir jemand ungefähr sagen was ich in mein makefile eintragen muss 
dass der linker weiß das er die Arrays in die lowr 64k linkt?

Danke für die hilfe, MainSter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie stellst du es denn an, dass er sie in den Bereich oberhalb 64 KiB
lädt?

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja... mit der makefile hab ich mich eigentlich noch nicht so wirklich 
beschäftig. Ich hab halt mal eine Makefile mit Program das bei dem WIN 
AVR paket dabei ist, mfile glaub ich, generiert.

Die Arrays wurden bis jetzt ja auch nicht in die oberen 64k geschrieben 
aber seit mein code mit den Arrays größer 64k ist stehen eben alle neuen 
arrays oberhalb 64k.

Wenn ich den Programm Code in den oderen bereich linke und den Daten 
Code, eben die arrays, in den unteren bereich linke sollte es ja 
funktionieren.

MFG MainSter

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was soll dieser ganze Zirkus jetzt eigentlich? Wenn die Daten grösser 
sind als 64KB, dann passen sie nun einmal nicht in 64KB. Dann ist es 
auch schnurzpiepegal ob sie unten oder oben im ROM liegen. Weil mal 
ohnehin mit dem _far Funktionen ran mus. Und denen ist es egal wo die 
Daten liegen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MainSter wrote:

> Die Arrays wurden bis jetzt ja auch nicht in die oberen 64k
> geschrieben aber seit mein code mit den Arrays größer 64k ist stehen
> eben alle neuen arrays oberhalb 64k.

Darum frage ich dich ja, wie du das denn geschafft hast.  Das ist
nicht der Normalfall: alle "progmem"-Objekte werden im
Standardlayout vor dem Code gelinkt.
$ cat foo.c
#include <avr/pgmspace.h>

uint8_t foo[] PROGMEM = {
  42, 21, 213, 123
};

uint8_t bar[] PROGMEM = "Hello, cruel world!";

int
main(void)
{
  int i;

  i = pgm_read_byte(&foo[0]) + pgm_read_word(&bar[1]);

  return i;
}
$ avr-gcc -Os -mmcu=atmega128 -o foo.elf foo.c
$ avr-nm -n foo.elf
...
00000000 T __vectors
...
0000008c T foo
00000090 T bar
000000a4 T __ctors_end
000000a4 T __ctors_start
000000a4 T __dtors_end
000000a4 T __dtors_start
000000a4 W __init
000000a4 T __trampolines_end
000000a4 T __trampolines_start
000000b0 T __do_copy_data
000000ca T __do_clear_bss
000000d2 t .do_clear_bss_loop
000000d4 t .do_clear_bss_start
000000de T __bad_interrupt
000000de W __vector_1
...
000000de W __vector_9
000000e2 T main
000000f8 A __data_load_end
000000f8 A __data_load_start
000000f8 T _etext
...
(Ich habe mal alle nicht mit dem ROM in Zusammenhang stehenden
Symbole rausgestrichen.)

Es ist deutlich zu sehen, dass die beiden ROM-Arrays foo und bar sogar
noch vor dem Initialisierungscode platziert werden.

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Hilfe....
@Jörg Wunsch: Sehr schönes Beispiel. Jetzt weiß ich wie es sein sollte!
Bei mir wird auf jeden fall nicht nach Standart gelinkt!

Aber ich glaub ich muss mir da noch einiges durchlesen.
Kann mir jemand ein einfaches Makefile schicken mitdem die programmteile 
nach dem Standardlayout gelinkt werden?
Und/oder kann mir jemand ne doku zu Makefiles empfehlen? Ich wollte mich 
schon länger mal mit dem thema auseinandersetzen.

Vielen Dank, MainSter

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Hab jetzt nochmal ein Standart Makefile mit Mfile generiert. Wenn ich 
mir die lst file anschaue wird alles so gelinkt wie es soll (das andere 
Makefile wahr wohl nichtmehr standart). Alle Arrays werden vor den 
Quellcode und nach die INT Vectoren gelinkt. mein 16. Array liegt jetzt 
wie gesagt genau auf der Grenze von 64k zu 128k. Dieses Array kann ich 
jetzt mit pgm_read_byte_far(); erreichen, oder??

Was kann man für fehler machen da ich mein 16. Array mit meiner far 
funktion nicht auslesen kann.
--> Die anderen Arrays (< 64k) können mit der selben funktion 
einwandfrei ausgelesen werden.

Muss man die Pointervariable vergrößern? In der LIBC doku steht nähmlich 
auch bei der funktion pgm_read_byte_far(); dass der Arrayname (Addresse) 
ein char (8Bit) ist.

MFG MainSter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pgm_read_byte_far() sollte allerdings in der Tat funktionieren, da
es explizit das RAMPZ-Register setzt.  Was passiert denn genau?

Die Adresse ist übrigens nicht 8 bits, sondern 32.  Du verwechselst
die Größe der Adresse mit der Größe des Objekts, auf die die Adresse
verweist.

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie hast du es geschaft dass er es dir überhaupt auf/über die grenze 
ablegt hat?
  ich gehe mal davon aus dass deines ein zusammenhängendes array ist. 
bei mir meckerte der compiler rum, dass ihm das array "nicht mehr 
erreichtbar scheint" und er es deswegen nicht abgelegt hat ('attribut' 
PROGMEM):

Error: value of 73728 too large for field of 2 bytes at 1736

hatte also erstmal nichts mit dem lesen zutun. im makefile habe ich auch 
gewühlt, war jedoch schnell ernüchtert...

pumpkin

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
73728 passt auch nicht in 2 Bytes (16 Bit). Da hat der Compiler vollig 
Recht. Das hört bei 65535 auf. Mehr besagt die Fehlermeldung nicht.

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha!

@Jörg Wunsch: Hast recht, habs verwechselt!

Diese Fehlermeldung kommt bei mir wenn ich ein 17es 4k Array mit in 
meinen Code aufnehme!

Error: value of 73728 too large for field of 2 bytes at 1736

Ich kann nicht genau sagen was passiert! Ich lade in einer Function byte 
für byte aus dem Array und übertrage diese ins Grafik Ram bis 4096 bytes 
gelesen wurden.
Für das array >64k habe ich die selbe Function nur anstatt 
pgm_read_byte_near() benutze ich pgm_read_byte_far();

Im display werden die ersten zwei byte weiß (die ersten 16 Punkte) und 
der rest bleibt schwarz.

Die Adresse ist aber nur bei der far() version 32Bit und bei der near() 
version 16Bit, oder? Sonst würde es ja fast keinen Sinn machen.

Könnte es auch daran liegen? Weil ich müsste die Variable für den Zeiger 
ja auch 32Bit groß machen....
Sorry für die NOP fragen aber ich bin grade zimlich verunsichert!

Danke, MainSter


Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 73728 passt auch nicht in 2 Bytes (16 Bit). Da hat der Compiler vollig
>> Recht. Das hört bei 65535 auf. Mehr besagt die Fehlermeldung nicht.

hat er ja auch, aber was soll der blödsinn? dann soll er halt 32bit 
adressen nehmen, habe ich doch keinen einfluss drauf. also wie löst man 
das problem? bisher konnte ich keine lösung finden...

pumpkin

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nachtrag:

was ich meine ist, dass es schön und gut ist dass es _far zugriffe gibt, 
aber sie nichts nützen wenn ich nichts explizit dort ablegen kann. 
können bestimmt, aber wie...

pumpkin

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> können bestimmt, aber wie...

Explizite Zuordnung der Variablen zu Sektionen, die man per 
Linker-Script an die gewünschten Stelle im Speicher plaziert.

Findet sich alles in Doku von GCC (Zuordnung zu Sektionen) und LD 
(Anordnung der Sektionen im Speicher per Linker-Script). Bei AVRs 
normalerweise nicht nötig, aber bei ARMs kommt man mit sowas öfter in 
Kontakt.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst auf alle pgmspace-Daten per _far-Funktionen zugreifen. Du 
kannst soviele Daten ins Flash packen, wie dort überhaupt reinpasst. 
Wenn du jedoch partout zwischen den Daten in den ersten 64KB und dem 
Rest unterschieden willst, dann laste das bitte weder Compiler noch 
Library an.

> dann soll er halt 32bit adressen nehmen, habe
> ich doch keinen einfluss drauf.

Ob eine Variable mit 16 Bits adressierbar ist, weiss der Compiler nicht. 
Kann also auch nicht abhängig davon unterschiedlichen Code erzeugen. 
Erst der Linker kriegt das spitz, dann aber ist es dafür zu spät.

Und so erzeugt der Compiler immer dann 16bit-Adressverarbeitung, wenn es 
man ihm nicht ausdrücklich anders mitteilt. Weil das in 99% der Fälle 
sinnvoll ist, alles andere wäre grober Unfug und würde den Code massiv 
aufblähen.

In deinem Fall merkt der Linker, dass die Adresse einer Variable nicht 
in das nur 16 Bits grosse Adressfeld eines Befehles oder einer 
Adressvariablen passt und meckert entsprechend.

Niemand hindert dich daran, mit geschickt plazierten 32bit Datentypen, 
den Compiler dazu zu überreden, für Adressen 32 Bits vorzusehen. Und 
sieh an, auf einmal geht es.

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Niemand hindert dich daran, mit geschickt plazierten 32bit Datentypen,
>> den Compiler dazu zu überreden, für Adressen 32 Bits vorzusehen. Und
>> sieh an, auf einmal geht es.

find ich gut!

pumpkin

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Bin mir immernoch unsicher wegen dem Pointer....

const uchar  *array1_ptr    PROGMEM = array1;
const uchar  *array2_ptr  ................

So hab ich bis jetzt allen Arrays einen Pointer zugewiesen.
Ich hatte das mal aus einem anderen Code abgeschrieben und es 
funktioniert auch...  Bis jetzt....

MFG MainSter

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das mit den 32bit pointern würde mich interessieren wie man das macht. 
so'n bissl beispielcode wäre phänomenal.


pumpkin

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi MainSter

Woher hast denn du deine Touch Folie?? Oder war die schon am Display 
oben?

Gruß Robert

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo Robert,

ich mache grade eine Ausbildung asl elektroniker für geräte und systeme. 
In meiner Berufschulklasse hab ich einen kollegen der bei einer Firma 
arbeitet wo sie Industrie PC s herstellen. Da kann der hin und wieder 
mal ne scheibe abgreifen....
Ich hab noch eine 15" resistiv scheibe in einem ca. 3-4 cm breiten 
rahmen... Die könnt ich für nen zehner inclusive versand entbehren.... 
Sind sogar noch 4 folientaster drauf....

Die Ansteuerung ist mehr als einfach (wenn der verwendete µC nen 
intergrierten AD wandler hat)

MFG Mainster

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi MainSter

Das ist ein Deal :)

Bitte meld dich unter robert.schilling@gmx.at. Bitte beachte wegen den 
Versandkosten, dass ich aus Österreich komme.

Bitte schick mir dann deine Kontodaten, um da Geld überweisen zu können 
(bitte mit IBAN und BIC).

Zum Schaltplan, den werd ich später noch online stellen. (Muss erst 
einen Screenshot machen...)

mfg Robert

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welches Display verwendest du?

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

Bewertung
0 lesenswert
nicht lesenswert
Hier nun der Schaltplan. Hast du deine T6963 Routinen selbst 
geschrieben?

mfg Robert

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Das display hab ich auch von dem kumpel der mir die folien besorgt hat!

Die Grafik lib hab ich auch mal irgendwo im netz gefunden.... Es waren 
die grundfunktionen (init, bytes ins grafik & textram ablegen) 
implementiert. Mittlerweile hab ich aber sehr viel funktionen 
implmentiert hauptsächlich fürs grafikram. Z.B. Bytes und pixel lesen 
(zum Invertieren der per touch gedrückten buttons) Ist allerdings noch 
fast alles für die Port version (nicht memmory mapped)

Wenn ich das mal umgeschrieben und kommentiert hab werd ich die Lib auch 
online stellen....

Danke für den schaltplan....

Ich meld mich bis spätestens dienstag wegen dem Touch.

MFG MainSter

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo robert,

könntest du mir noch sagen was das unten rechts in der ecke für 2 
Bauteile sind (das eine is n OPAxx) aber die beiden drüber mit 14 und 8 
Pins sind selbsgemachte symbole, oder?

MFG MainSter

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...und dann wäre da noch die Funktion von PD7 & PD6 an SV1
(LCD connector?)

Einer davon wird der C/D Pin sein und der andere wahrscheinlich 
/Disp_OFF.
Die eine Leitung die von dem unbeschrifteten 8pin bauteil (irgendwas 
richtung Resetbaustein ?) weggeht wird am /reset vom T6963 angeschlossen 
sein, oder??

So wie ich deine Schaltung verstehe verwendest du zur Addressierung des 
Grafik - RAMs Adressen wo die obersten vier addr. pins (A15...A12) high 
sind.
Und bei dem 128k sram? es wird ja nur als 64k sram verwendet. Die CS 
pins von dem sram sind aber nur dann aktiv wenn eine der obersten 4 
Addr. bits low ist, oder? Dann kannst du ja da auch wieder nicht die 
vollen 64k verwenden, oder?

Hab noch nie was mit dem Addr. Bus gemacht außer jetzt mit dem T6963! 
darum die vielen fragen!

Danke, MainSter

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab grad noch gesehen dass du nen JTAG connector auf deinem board 
hast...

Verwendeset du diesen zufällig als debugger schnittstelle?
Wenn ja, hast du dir die debugger-hardware auch selber gebastelt oder 
verwendest du was gekauftes??

Danke, MainSter

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MainSter

Der OPA547 ist ein Leistungs OP. DEn hab ich zum steuern der Helligkeit 
der Hintergrundbeleuchtung. Das schnell erzeugte Eigenbauteil ist ein 
MC34063 und dient zur Erzeugung der negativen Kontrastspannung. Sowohl 
die Kontrastspannung, als auch die Hintergrundbeleuchtung wird über ein 
Digtales Poti (MCP42010) gesteuert. DIe Leitung die vo 8 PIn IC weg 
geht, ist die negative Kontrastspannung.

Zum Ram. Mit dem Mega128 kann an maximal 64kB Ram ansteuern (mit dem 
XMEM Interface) ohn irgendwelche Zusatzlogik... Die Unteren 56kB Ram die 
adressiert werden, sind für den SRAM reserviert. (NAND GAtter aktiviert 
die CS Pins des SRAM). Sobald man über 56kB adressiert, sind die oberen 
4 Bits der Adresse HIGH und das NAND GAtter akiviert den CS Pin des 
Displays. C/D ist an A0 angschlosssen. Somit sind bei allesn geraden 
Adressen A0 auf LOW, sprich es ist ein Datenbyte. Bei einer ungeraden 
Adresse über 56kB wird es zu einem Kommandobyte.

Als JTAG Debugger verwende ich einen selbstgebautes Evertool --> GOOGLE. 
Vereint ISP und JTAG.

Wenn noch Fragen offen sind, einfach Fragen.
mfg Robert

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Robert,

danke für die Erklärung. DAs mit den 56k ist mir gestern Nacht auch noch 
gekommen! Die sache mit der
geraden Addr > 56k = Datenbyte fürs Display und
ungerade Addr > 56k = Befehlsbyte fürs display ist sehr schön gelöst!

Hast du dein Projekt auch mit 16MHz am Laufen???
Wenn ja, brauchst du auch einen Wait State bei datenübertragungen zum 
Grafik Ram???

MFG, MainSter

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi MainSter,

Danke ;)

Am LAufen hab ich noch gar nicgts, da die PLatine erst geätzt werden 
muss. Als Quarz hab ich einen 18.irgendwas gedacht. (Es kommen sehr 
viele Daten per Uart). Dann aber 2 Wait States...

Läuft deiner mit 16MHz?

Gruß Robert

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
läuft mit einem wait state wunderbar. Wenn ich ihn ohne Waits laufen 
lass hab ich nach ca. 5 sekunden übertragungsfehler.
Zum testen lass ich eine bmp 50x50pixel auf dem Bildschirm umherkreisen. 
Nach dieser zeit werden manche datenpakete die fürs GRafik - ram gedacht 
waren durch die übertragungsfehler ins Textram geschrieben.....

Mit einem wait gehts aber echt klasse! Man kommt ohne probleme auf 
einige Frames / sekunde..... genaueres werd ich nacher mal austesten!!!

MFG MainSter

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Das Geld müsste heute angekommen sein (Ich hab das ganze am Montag Abend 
überwiesen).

mfg Robert

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MainSter

Hast du das Touch Panel schon verschickt?

mfg Robert

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Robert,
sorry dass ich so lange auf mich warten lassen hab!! Ich muss dir leider 
mitteilen dass das Panel nicht mehr funktionsfähig ist. Ich habe es 
dummer weise auf dem "Plastik- Anschluss" gelagert und mit der zeit ist 
da wohl ein kontakt gebrochen..... Wenn man ein bischen dran rumdrückt 
dann funktionierts wieder....
Ist aber nicht wirklich toll... Ich hab auf den kollege gewartet weil er 
gemeint hat, dass er vll. nochmal eins Abstauben kann aber so wies 
aussieht dauert es noch..... Ich würde sagen dass ich dir dein geld 
zurücküberweise... Ich versprech dir dass du der erste bist der ne email 
kriegt falls es nochmal klappen sollte dass der kollege welche 
organisiert kriegt.

Denk an BIC usw....

Sorry nochmal,

MainSter

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MainSter

Das ist natürlich ncht gut. In welchem Zeitraum denkst du du, wirst du 
das nächste Touchpanel bekommen??

Kannst du mir bitte deine Mail nochmal schicken??

mfg Robert

Autor: Robert S. (razer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Kannst du mir bitte deine EMail Adresse nochmals schicken?

mfg Robert

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Robert!

Es tut mir leid dass ich so lange nichts von mir hören lassen hab aber 
ich hab auf ne E-mail gewartet....

Meine Mail: ManuelDelBasso@web.de

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.