Probleme mit Datenauswerten von HDD mit Atmega

Poste doch bitte deine Leseroutine. Es sieht nach einem 16-/32-Bit 
Problem aus.

#include <avr/io.h>
#include <stdint.h>

void Read16Byte (uint8_t*Low8,uint8_t*Hig8)
{
PORTB = 0;
DDRB = 0x00;  //PortB auf Eingänge schalten

  PORTD &=~ (1<<PD2);  // DIOR HDD lesepin auf 0 ziehen

  PORTC &=~ (1<<PC1);  // 8bit Latch für D8-15 aktivieren
  PORTC |=  (1<<PC0);  // CLK von Latch High8bit
*Hig8 = PINB;
  PORTC &=~ (1<<PC0);
  PORTC |=  (1<<PC1);  // 8bit Latch für D8-15 deaktivieren


  PORTC &=~ (1<<PC3);  // 8bit Latch für D0-7 aktivieren
  PORTC |=  (1<<PC5);  // CLK von Latch Low8bit
*Low8 = PINB;
  PORTC &=~ (1<<PC5);
  PORTC |=  (1<<PC3);  // 8bit Latch für D0-7 deaktivieren

  PORTD |=  (1<<PD2);  // DIOR HDD lesepin auf 1 ziehen

}


//*****************************************************
das ist das unterprogramm das ich aufrufe wenn ich 16bit daten lesen 
möchte, und je nach dem wie viele Wörter ich lesen möchte wieder hole 
ich das unterprogramm

Danke für die Schnelle Hilfe =)

>wenn ich z.B. im FAT stehen hab:
>00 00 00 07    0F FF FF FF    00 00 00 09
>macht meine nette HDD daraus
>00 00 00 07    0F FF   00 00 00 09

Deiner HDD ist es völlig egal ob die ganze FAT voller 0xFF ist.
Sie gibt dir das raus was was sie liest. Die Frage ist was
du damit machst. Der Codeschnipsel oben ist nicht die
Problemzone.

Das Problem muß in einer anderen Routine liegen. Wo kommt die 
Zusammenfassung zu 32-Bit?

Wenn es normal ist das die HDD manche Bytes mit 0xFF verschluckt ist es 
ok, einwenig blöd aber dann muß ich eben ein etwas umständlicheres 
Programm schreiben

aber wenn das nicht normal ist weiß ich echt nicht woran es liegen kann 
weil sonst alles richtig übertragen wird?!

ich hab mal einen Screenshot von einem Sektor gemacht den ich zur probe 
mal ausgelesen hab.

ich hab ein kleines LCD display an dem uC auf dem ich mir die gelesenen 
Daten schritt für schritt noch mal angesehen hab.

bis auf die blöde FF sache war alles richtig?

ihr könnt euch den Screen mal ansehen hab da auch noch was dazu 
geschrieben Falls ich mein Problem einwenig unverständlich erkläre

vielen danke für die Beiträge

Es muß an mir liegen, dass ich das Problem nicht richtig verstehe. Die 
HDD verschluckt keine Bytes, sondern eine deiner Routinen ist dafür 
verantwortlich. Oder?

>Wenn es normal ist das die HDD manche Bytes mit 0xFF verschluckt ist es
>ok, einwenig blöd aber dann muß ich eben ein etwas umständlicheres
>Programm schreiben

SIE VERSCHLUCKT 0xFF NICHT

>aber wenn das nicht normal ist weiß ich echt nicht woran es liegen kann
>weil sonst alles richtig übertragen wird?!

Das liegt an dem Teil deines Programmes wo aus zwei 16Bit
Werten ein 32Bit Wert gemacht wird. Falls du das überhaupt machst.
Oder an deiner LCD Ausgabe.

Siggi ... es kann gut sein das ich es nicht richtig gut rüber bringe =)
aber ich poste dir trotzdem mal den teil mit dem ich so einen 4Byte wert 
zusammen setze

ich hab halt ein union festgelegt mit dem ich aus den einzelnen Bytes 
ein 4Byte-Wert mache.
//*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!

#include <avr/io.h>
#include <stdint.h>

typedef union
{
uint32_t Clust;
struct {
    uint8_t Clow ;
    uint8_t Cmid ;
    uint8_t Chig ;
    uint8_t Cmost ;
  };
} convertClust;


...


int main (void)
{


...


  firstC.Cmost = LMost1;
  firstC.Chig  = LHigh1;
  firstC.Cmid  = LMid1;
  firstC.Clow  = LLow1;
  Clupuf = firstC.Clust;

//*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!

so hab ich bis jetzt immer die 4 1Byte-Teile immer zusammengesetzt zum 
ausrechnen des ersten Sectors des Clusters ...
und es klappt auch soweit
aber das -mich schon langsam echt nervende- FF-Problem taucht ja auch 
schon auf wenn ich nach jedem lesen die 2 Bytes auf dem Display ausgeben 
lasse.

...

Dieser Teil des Programmes dürfte interessant sein.

Du hast 12  Byte Zugriffe und erwartest diese Bytes:

00 00 00 07    0F FF FF FF    00 00 00 09

Von der HDD bekommst du die unten stehenden Bytes und natürlich zwei 
weitere, die du nicht auf geführt hast. Richtig?

00 00 00 07    0F FF   00 00 00 09

ja genau siggi so siehts aus!
und ich habe keine ahnung warum mir meine so geliebte Festplatte das 
antut


Auch wenn ich mich vielleicht für echt behämmert haltet =)
wenn ich mit dem ganz oben mal auftauchendem Read16Byte-Unterprogramm 
den Sektor auslese und nach jedem lesen gleich die Bytes auf dem Display 
ausgeben lasse, dann kann mein programm ansich nicht auf einmal FF FF 
verschlucken? weil ich nur per Taste (entprellte Tasten wohlgemerkt) nur 
immer einmal weiter lesen lasse.

ich hab mir z.B auch schon ein Rooteintrag ausgeben lassen
und bei den Namens erweiterungen wenn der zuende ist tauchen doch auch 
öfters mal FFs auf?  soweit stimmt es ja noch, ich kann auch gerne noch 
einen Screen dazu posten,
aufjeden fall zeigt er da FFs an, aber kürzt trotzdem =) lach ich weiß 
garnicht was ihr von mir denken müßt.

sind 4 FF Bytes nebeneinander, dann kürzt er 2 raus
sind es 6 dann kürzt er 3
und bei 10 kürzt er irgendwarum nur 4 raus

hört sich klasse an oder =) lach

so hab jetzt auch noch einen Screen von einem Sektor im Rootverzeichnis
dazugetan,

und wieder das gleiche rot ausgefüllte Kästchen werden nicht ausgelesen, 
rot umrahmte Kästchen lese ich so wie sie in dem screen sind aus.

Das Problem liegt bstimmt am Programm. Die HDD ist es nicht.

Ist mir schon klar, dass dies nicht hilft, aber wirf noch einmal ein 
kritisches Auge auf das Zusammenfassen der Werte zu 32-bit Variablen.

>Das Problem liegt bstimmt am Programm. Die HDD ist es nicht.

Die HDD mit Sicherheit nicht.

>Ist mir schon klar, dass dies nicht hilft, aber wirf noch einmal ein
>kritisches Auge auf das Zusammenfassen der Werte zu 32-bit Variablen.

Ich tippe mal auf die Ausgaberoutine für das LCD.
Aber die ist ja so ultrageheim das er sie nicht posten darf.

Wenn da nicht noch mehr Code rüberkommt soll er doch an seinem
Problem rumknabbern bis er schwarz wird.

Tut mir leid ...  sag doch einfach was dir helfen würde mir zu helfen 
und ich posete es =)
mußt nur noch kurz warten....

so hab kurz ein rar zusammengestellt mit einwenig erklärung was ich 
überhaupt mit den schritten bezwecken möchte

Was soll ich jetzt zu deinen Codeschnipseln sagen?

>void Show (uint8_t*ShowByte)

Ein Byte per Zeiger zu übergeben ist Verschwendung.
Naja, wenn du es so magst dann tu es.

Ansonsten sehe ich kein Problem mit deinen Codeschnipseln
hunderte von 0xFF in Folge auf dem LCD auszugeben.

Was ich aber mit Sicherheit sagen kann ist, daß es deiner HDD völlig
Wurst ist welche Daten sie überträgt. Mehrere 0xFF in Folge
werden NICHT verschluckt. Davon kannst du ausgehen. Auch wenn
du es bezweifelst.

Das Problem ist immer noch irgendwo in deinem Code.
Dann such mal schön selber weiter.

Haha
Hallo noch mal alle!!
Ich hab bestimmt noch 4 geschlagene Stunden nach Fehlern gesucht und 
rumprobiert und es ist nicht besser geworden!
Dann hab ich wirklich in letzter hoffnung 2 stunden lang Daten von 
meiner externen Festplatte auf alle anderen mir verfügbaren 
Speichermedien verteilt ( sogar meine 2 USB- Sticks sind voll =) und die 
Festplatte mit fat32 formatiert, ein paar txt dateien draufgehauen mit 
WinHex den ersten FAT sektor gesucht den avr kurz umgeschrieben und 
.........
.......... es klappt!!!!
Ich war noch nie so froh soviele FF auf meinem Display zu sehen!! lach 
!! ein halleluja für meine neue lieblingsfestplatte!!!!!!!
Ich weiß nicht ob die 11 jahre vielleicht doch ihre spuren bei der 
anderen Festplatte hinterlassen haben oder sonst was aber jetzt gehts!! 
gottseidank!!!

aber trotzdem danke für die Hilfestellung!

nur noch eine Frage Holger,
Warum ist es so schlim wenn ich ein Byte als zeiger übergebe?
wenn ich es nicht mit zeiger übergebe dann macht das Unterprogramm eben 
eine Kopie von dem Byte das ich übergeben möchte?
Ist dann doch relativ egal? oder weiß ich da etwas nicht?