Warum 20K an dem SD Interface?

Allgemeine Themen rund um den Propeller Mikrocontroller und Elektronik
Antworten
DJLinux

Warum 20K an dem SD Interface?

Beitrag von DJLinux »

Warum haben die Widerstände "ausgerechnet" 20K an dem SD Interface kommt SD nicht mit den 3.3V Propeller Pegeln klar ?

Danke und Grüsse

Joshy
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: Warum 20K an dem SD Interface?

Beitrag von drohne235 »

Die 20K-Widerstände dienen nicht der Pegelanpassung, sondern sind pull up Widerstände gegen 3,3V, welche dafür sorgen, das die Pegel an der SD-Card immer auf einem definierten Potential hängt. Wenn in Administra z.B. ein Code läuft der die Ports anders oder nicht initialisiert und P10..13 sind am Prop als Eingang definiert (was ja schon beim Einschalten der Fall ist) dann marodieren auf den Leitungen eventuell irgend welchen Störungen die sich aufbauen. Was dann mit den Daten auf der SD-Card passiert ist dabei ziemlich ungewiss. Also werden sie mit den Widerständen dezent auf ein definiertes Potential gesetzt. Das gleiche findest du bei bestimmten Steuerleitungen auf dem Bus.
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
DJLinux

Re: Warum 20K an dem SD Interface?

Beitrag von DJLinux »

Das habe ich sogar verstanden, da besteht ja doch noch Hoffnung.

Danke und Grüsse

Joshy
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: Warum 20K an dem SD Interface?

Beitrag von drohne235 »

Bei den beiden ersten Prototypen hatte ich noch keine Pullups an den Steuerleitungen am Bus, weil ich dachte, das ich die ja eh immer per Software auf einem passenden Potential halte. Was ich aber nicht bedacht hatte: Wenn zum Beispiel in Regnatix eine Cog den Bus freimacht um einer anderen Cog Zugang zu verschaffen, dann hängen für einen kurzen Moment die Signale in der Luft, da die Übergabe ja nicht nahtlos vonstattengeht. Das ist als wenn zwei Staffelläufer ihren Stab nicht mehr von Hand zu Hand übergeben, sondern sich über eine gewisse Distanz zuwerfen würden. Wärend der freien Flugphase könnte da eine ganze Menge passieren... :twisted: Ich hab zwar konkret keine Probleme ohne Pullups gehabt, hab aber beim R13 dann doch noch welche eingesetzt. Solche Fehler könnten ziemlich fies sein wenn man sie suchen muss... :mrgreen:
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
DJLinux

Re: Warum 20K an dem SD Interface?

Beitrag von DJLinux »

Das mit DIRA:=0 bzw. mov DIRA,#0 habe ich immer noch nicht verstanden in Assembler brauche ich das auch nicht weder auf dem HiVe noch auf dem Steckbrett. Das Peek und Poke IOS / PASM Beispiel läuft aber ohne nicht. VGA/TV oder Sound/SD werkelt doch auch an den Pins und dessen Directions ohne das es zu irgend welchen Problemen kommt.

Wen nach dem Anlegen einer Stromversorgung / Einschalten des Propellers alle Pinne als Eingang definiert sind dann könnten zwar angeschlossene Komponenten die low aktive auf /CS reagieren sich angesprochen "fühlen" würden aber weder eine Clock noch Commando oder Daten erhalten somit könnte nichts "schlimmes" z.B. an einer eingelegten SD Karte passieren oder ???

Irgend etwas grundlegendes scheine ich immer noch nicht kapiert zu haben aber wie gesagt mein OS (wenn man es im jetzigem Stadium so nennen darf) läuft wie es soll und das ist hoffentlich nicht nur das Resultat von Glücksache.

Grüsse Joshy
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: Warum 20K an dem SD Interface?

Beitrag von drohne235 »

Das mit DIRA:=0 bzw. mov DIRA,#0 habe ich immer noch nicht verstanden in Assembler brauche ich das auch nicht weder auf dem HiVe noch auf dem Steckbrett. Das Peek und Poke IOS / PASM Beispiel läuft aber ohne nicht.
In PASM brauchst du das aber auch Joshy. Das kannst du auch gut testen: Wenn du eine COG was am RAM werkeln lässt, kannst du ja mal eine zweite Cog starten mit einem PASM-Programme, welches per DIRA P0..7 aktiviert. Wenn diese COG dann ein $ff auf dem Bus ausgiebt ist Ritze mit RAM. :) Wenn sie allerdings ein $00 ausgibt blockiert sie da nix, da alle IO-Pins der einzelnen COG's quasi verodert sind. Am sichersten ist es da man schaltet die entsprechenden Pins halt per DIRA in den Inputmodus.
VGA/TV oder Sound/SD werkelt doch auch an den Pins und dessen Directions ohne das es zu irgend welchen Problemen kommt.
Jo, aber sie definieren DIRA nur so, das die entsprechend benötigten Pins auf Ausgabe stehen - ebend genau damit sich die COG's nicht ins Gehege kommen. Das DIRA-Register ist ja für jede COG privat und unabhängig. Kannst ja mal zur Probe die Pins von Keyboard und Maus auf die gleichen Werte legen - durfte ziemlichen Salat geben, da die beiden gestarteten COG's (sofern man keinen Kombitreiber mit einer Cog nutzt) auf den gleichen Pins rumwerkeln. Dafür ist halt DIRA da - damit man festlegen kan und sollte, dass Cog 0 Pin 0..3, Cog 1 Pin 4..8 usw. bekommt. Zumindest gilt das für die Ausgabepins. Bei INA lesen alle Cogs das gleiche ein (behaupte ich jetzt mal... :).
Wen nach dem Anlegen einer Stromversorgung / Einschalten des Propellers alle Pinne als Eingang definiert sind dann könnten zwar angeschlossene Komponenten die low aktive auf /CS reagieren sich angesprochen "fühlen" würden aber weder eine Clock noch Commando oder Daten erhalten somit könnte nichts "schlimmes" z.B. an einer eingelegten SD Karte passieren oder ???
Bei den Slavepropellern sollte das so sein - müsste ich mal genauer drüber meditieren... :) Aber was ist mit den RAM's? Die sind dann selektiert, haben ein aktives Schreibsignal und wahrscheinlich ein $00 auf D0..7. Damit könnten sie bei jedem Reset die Speicherzelle auf Adresse $0 wahrscheinlich mit wahrscheinlich $0 überschreiben.

Hmpf... Hab es grad getestet - die Zelle 0 wird bei mir auch mit den Pullup-R's bei jedem Reset auf 0 gesetzt - soviel zur Theorie... :evil: Verstehe ich momentan noch nicht wirklich warum das so ist, muss ich ebenfalls drüber meditieren... :twisted:

Naja, zumindest dachte ich mir die paar Widerstände können in keinem Fall schaden.
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Benutzeravatar
Rainer
Beiträge: 510
Registriert: Fr 29. Mai 2009, 16:11

Re: Warum 20K an dem SD Interface?

Beitrag von Rainer »

drohne235 hat geschrieben:

Hmpf... Hab es grad getestet - die Zelle 0 wird bei mir auch mit den Pullup-R's bei jedem Reset auf 0 gesetzt - soviel zur Theorie... :evil: Verstehe ich momentan noch nicht wirklich warum das so ist, muss ich ebenfalls drüber meditieren... :twisted:

Naja, zumindest dachte ich mir die paar Widerstände können in keinem Fall schaden.
Hehe .. und ich dachte schon ich bin komplett verblödet. Bei meinem SFX-Helper habe ich nämlich genaus das Problem, daß bei einem Reset ALLES im SRAM erhalten bleibt, nur $0 nicht. Da liegt aber die Wellenform des ersten Slots .. die war jedesmal auf 0 = langsamer Sinus.
In meiner "Verzweiflung" habe ich dann einfach den Speicherbereich weiter nach oben verlegt.

Gruß.
Rainer
"Wer andauernd begreift, was er tut, bleibt unter seinem Niveau."
Benutzeravatar
drohne235
Administrator
Beiträge: 2284
Registriert: So 24. Mai 2009, 10:35
Wohnort: Lutherstadt Wittenberg
Kontaktdaten:

Re: Warum 20K an dem SD Interface?

Beitrag von drohne235 »

die war jedesmal auf 0 = langsamer Sinus.
In meiner "Verzweiflung" habe ich dann einfach den Speicherbereich weiter nach oben verlegt.
Hatte ich das nicht erwähnt: Die Speicherzelle $0 ist doch das Resetflag! *räusper*

Also wer rausbekommt woran es liegt und wie es zu beheben ist, bekommt auf dem nächsten internationalen Hive-Kongress ein Bier ausgegeben. :)
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Antworten