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
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?
Angehängte Dateien:
-
Screenshot.PNG
83 KB
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
Angehängte Dateien:
-
RootSec.PNG
38 KB
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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.