Vergleich Adresse und INT

soll das C sein?
(das Semikolon im if spricht dagegen)

RUFFYDEMONKEY schrieb:
> Hallo ich möchte eine Adresse und ein Wert vergleichen aber wie?
> [...]
> bekomme aber eine Fehlermeldung dass ich ein int mit einem uint_8 nicht
> vergelichen kann.

Definition von _pucImageDst?
Definition von pImage->dwFinalLength?
Was ist BOARD_PSRAM_BASE?
Was ist IMAGE_SIZE_QVGA?

Was soll das Semikolon vor dem "<=" im ersten if?

Mit dem Codeausschnitt kann man nix anfangen.

2 Fragen beantwortet, 3 Fragen ignoriert.

Bleiben:

Definition von _pucImageDst?
Definition von pImage->dwFinalLength?
Was ist BOARD_PSRAM_BASE?

Kommen 2 Fragen hinzu:

Welcher Prozessor?
Welcher Compiler?

RUFFYDEMONKEY schrieb:

> if((_pucImageDst + pImage->dwFinalLength) <= 0x60080000 )

Q: Welchen Datentyp hat der Ausdruck links vom <= ?
A: Es ist uint8_t*  (rate ich mal aus dem Rest vom Code)

Q: Welchen Datentyp hat der Ausdruck rechts vom <= ?
A: Es ist int (oder long, je nachdem welches System du vor dir hast)

Q: Kann ein uint8_t* (also ein Pointer) mit einem int verglichen werden?
A: Nein, Pointer und int sind nicht zuweisungskompatible Datentypen.
   Sie können daher auch nicht direkt miteinander verglichen werden.

Q: Kann man den int zu einem Pointer casten, da ich ja den Zahlenwert
   kenne und eigentlich nur einen Pointer haben möchte, der diesen
   Zahlenwert als Adresse ausdrückt?
A: Selbstverständlich.


if((_pucImageDst + pImage->dwFinalLength) <= (uint8_t*)0x60080000 )

Und das nächste mal machst du die Analyse nach genau diesem Muster 
alleine. Es reicht nicht, einfach irgendwelche Variablen hinzuschreiben, 
man muss sich auch über die beteiligten Datentypen im klaren sein.

2 Fragen beantwortet, 3 Fragen ignoriert.

Bleiben:

Definition von _pucImageDst?
Definition von pImage->dwFinalLength?
Welcher Compiler?

Kommen zwei Fragen hinzu:

Exakte (wortwörtliche) Fehlermeldung?
Auf welche Zeile bezieht sich die Fehlermeldung?

Sach mal... muss man Dir alles aus der Nase ziehen? Das ist ja ätzend.

Die Frage nach den Definitionen der Variablen beziehen sich auf den Typ 
derselben. Vermutlich stimmt da einfach der cast in der letzten Zeile 
nicht. Aber solange Du nicht mit den Infos rausrückst, kommen wir hier 
nicht weiter.

RUFFYDEMONKEY schrieb:
> Kopierfehler.....

Ja, ja.
Genauso sorgfältig kopiert, wie du die Fehlermeldung sorgfältig 
abgeschrieben oder alle wichtigen Zusatzinformationen (wie zb so 
Kleinigkeiten wie Datentypen der beteiligten Variablen) gegeben hast.

> #define BOARD_PSRAM_BASE (0x60000000)

Da es sich hier offenbar um einen Basispointer handelt, warum wird 
dieser Zahlenwert nicht in einen uint8_t Pointer gecastet? Stattdessen 
castest du dann lieber hier

    _pucImageDst=(uint8_t*)BOARD_PSRAM_BASE+IMAGE_SIZE_QVGA*2 ;

dir den Zahlenwert auf den richtigen Datentyp zurecht.

Und warum steht eigentlich hier

> if((_pucImageDst + pImage->dwFinalLength) <= 0x60080000 )

eine magische Zahl mitten im Code? Könnte es eventuell sein, dass 
zwischen den Zahlenwerten 0x60080000 und dem Wert von BOARD_PSRAM_BASE 
ein Zusammenhang besteht, so dass man das eine in Einheiten des anderen 
ausdrücken könnte? Würde das dann nicht sogar den Code vereinfachen, 
indem man da gar keine Pointer mehr vergleichen muss, sonden sich im 
Grunde fragt, ob pImage->dwFinalLength kleiner/gleich 0x8000 ist?

(Vorsicht: Kleiner gleich ist in C meistens falsch. Wir fangen bei 0 zu 
zählen an und wenn man das berücksichtigt, bleibt von kleiner/gleich 
meistens nur das kleiner übrig und es stellt sich raus, dass gleich 
oftmals einen Arrayoverflow bedeutet)

RUFFYDEMONKEY schrieb:

> Endadresse des Specihers. Aber aus irgendeinem Grund hat der Prozessor
> einfach über die 0x60080000 gespeichert, weiss nicht wie das geht? eigtl
> kam es in eine endlosschleife auf exit. Naja jetzt kann es nicht mir
> drüber hinaus. Kannst du mir erklären wieso er einfach weiterschreibt

Warum denn nicht?
Glaubst den den Prozessor interessiert das, ob an der Speicheradresse, 
die du ihm angibst auch wirklich physikalisch Speicher liegt? Das 
interessiert den µC nicht die Bohne. Der legt die Adresse auf den Bus, 
legt die Daten auf den Bus und legt ein Schreibkommando an den Bus. Ob 
ihm da tatsächlich in Speicherbaustein zuhört oder nicht, ist ihm aber 
sowas von egal.

> und wohin?

Ins Nirvana

Karl Heinz Buchegger schrieb:
> Ins Nirvana

Nicht unbedingt. Wenn der Adressdecoder nicht vollständig implementiert 
ist, kann es auch sein, dass der Speicher mehrfach eingeblendet wird, 
d.h. irgendwann überschreibt er sich wieder den Anfang des RAMS. 
Allerspätestens beim Überlauf der Adresse.

RUFFYDEMONKEY schrieb:
> Ist es jetzt möglich diese JPEG dateien irgendwie am Rechner
> aufzurufen/auszulesen? Und wie geht das?

Was heißt "aufrufen/auslesen"?

Da ist Speicher und da sind irgendwelche Werte drinnen. Was immer du mit 
diesen Werten machen willst, musst du eben programmieren.

> Irgendein Sichwort? UART?

Ich könnte genausogut 'berittener Bote mit einem Ausdruck der Daten in 
der Satteltasche' sagen.

RUFFYDEMONKEY schrieb:
> Ok ich möchte die Daten die auf dem SRAM gespeichert sind an den Rechner
> schicken.

Was hindert dich daran?

(war eine rhetorische Frage)

Welche Möglichkeiten der Kommunikation mit einem anderen Rechner hast du 
zur Verfügung? Mit welcher hast du Erfahrung?
Wenn die Antwort: mit gar keiner lautet, dann wirst du dich da eben 
einlesen müssen und lernen müssen wie man das auf deinem konkreten 
System macht.