mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Probleme mit Datenauswerten von HDD mit Atmega


Autor: McRip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo erstmal an alle!

Ich hab folgendes Problem,
ich will mir einen MP3 Stand-Alone-Player bauen -- wie so viele =) --
auf jeden  Fall soweit klappt alles auch, Commandos an HDD geben, lesen, 
schreiben, ...
aber leider macht meine Festplatte teilweise so lustige Sachen von denen 
ich nicht weiß ob das so sein sollte?!

beim lesen von Daten kürzt sie einfach Bytes raus wenn mehrere Bytes mit 
dem Inhalt " 0xFF " neben einander stehen???

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

(sie kürzt auch Bytes mit 0xFF raus wenn sie im Datenbereich stehen,
ich hab mir die Bytebelegungen mit WinHex genau angesehen und es stimmt
auch alles soweit bis mehrere FF Bytes nebeneinander auftauchen =)
???

Ist das normal?
wenn ja,
   dann ist das aber ziehmlich umständlich zu programmieren
   weil ich im FAT bestimmte Bytes lesen muß um den
   nachfolgenden Cluste herauszufinden und so habe ich
   aber einen Lesebefehl zu viel gemacht wenn die HDD
   anfängt zu kürzen,

   und es kann auch vorkommen das 0F FF nicht nur als
   End-Clust-Signal vorkommt sondern auch als die
   2-Low-Bytes eines 4-Byte-Next-Cluster-Eintrags!?

wenn das nicht normal ist,
   weiß vielleicht jemand wie ich das verhindern kann?
   beim lesen kann ich ja an sich nicht viel falsch machen
   auf low ziehen daten lesen und dann wieder auf high ziehen

   oder liegt das an meiner Platte? (die versuchsplatte
   ist immerhin gute 11 Jahre alt, vielleicht ist die ATA-Spezifikation
   etwas sehr besonders? Aber mein Pc ließt sie ansich einwandfrei)

Falls sich jemand da auskennt weil er vielleicht soetwas ähnliches 
gemacht hat oder etwas anderes mit ähnlichen Inhalt oder sich auch 
einfach so auskennt ...
   Ich bin auf jeden Fall dankbar für jede Hilfe!!
   Schonmal vielen dank

Autor: Siggi (Gast)
Datum:

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

Autor: McRip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#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 =)

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Siggi (Gast)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Siggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: McRip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...

Dieser Teil des Programmes dürfte interessant sein.

Autor: Siggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: McRip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Siggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: McRip (Gast)
Datum:

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

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

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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: McRip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

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.