Hallo, ich würde gerne mal wissen, ob man direkt sagen kann, wieviele Variablen in einem Schreibzyklus geschrieben werden. Kann man dazu auch einen Test machen, um dies genau raus zu finden? Gruß
Dass in einem einzigen Schreibzyklus mehrere Variablen geschrieben werden, darf als eher unwahrscheinlich gelten.
Warum 42? "... die einen Computer namens Deep Thought gebaut haben, um die Antwort auf „die Ultimative Frage des Lebens, des Universums und dem ganzen Rest“ zu bekommen. Nachdem als Antwort 42 berechnet wurde, ..." http://de.wikipedia.org/wiki/Per_Anhalter_durch_die_Galaxis_(Romanreihe)#Per_Anhalter_durch_die_Galaxis
Magnus Müller schrieb:
> Der Wikipedia Artikel existiert nicht mehr ( -> gelöscht )
Bloedsinn, der URL ist nur unvollstaendig. Schliessende Klammer fehlt.
Doch, er existiert noch, aber die URL-Erkennung der Forensoftware scheitert bei Klammern. Also nicht blind klicken, sondern mitlesen und -denken. de.wikipedia.org/wiki/42_(Antwort)
A. K. schrieb: > Also nicht blind klicken, sondern mitlesen und -denken. > > de.wikipedia.org/wiki/42_(Antwort) Selber denken tut aber weh !!!!
Naja... schön das jetzt auch mal zu wissen, aber die eigentliche Frage war, wieviele Variablen in einem Schreibzyklus geschrieben werden. @prx: Du hast gemeint, dass es eher unwahrscheinlich ist, dass mehrere in einem Schreibzyklus geschrieben werden. Aber worauf bezieht sich deine Vermutung? Kann man auch sagen, welche Größe die Variablen haben?
Sandra Nowak schrieb: > Naja... schön das jetzt auch mal zu wissen, aber die eigentliche Frage > war, wieviele Variablen in einem Schreibzyklus geschrieben werden. Peter (Gast) schrieb: > es sind immer 42. Egal welcher Prozessor, Compiler und überhaupt. man beachte jetzt vielleicht auch mal den Teil nach dem ersten "."
Soll das etwa heißen, dass 42 Variablen geschrieben werden? Worauf stützt ihr die Behauptung und diesmal bitte nicht schon wieder die Wiki seite.
Ja, genau. Wenn man weniger Variablen angelegt hat, spendiert der Compiler sogenannte Füllbytes.
Na, auch hier: http://de.wikipedia.org/wiki/42_(Antwort) Genaugenommen dieser Satz: >„I think the problem, to be quite honest with you, is that you've never actually >known what the question is.“ Und als Service auch direkt die Übersetzung für Dich: Kein Mensch versteht deine Frage. Was ist ein Schreibzyklus? Was ist eine Variable? Auf welches System, welchen Compiler, welche Hardeware, was auch immer, beziehst du dich? Oder, noch einfacher: Was willst du eigentlich wissen? Oliver
Oh Mann Was man dir die vanze Zeit durch die Blume zu sagen versucht: Deine Angaben sind unvollstaendig! Die Frage ist so nicht beantwortbar.
In den Unterlagen/Data sheets/Handbüchern zu dem Rechner, den hier niemand kennt - weil du es niemandem verrätst. Welche das sind, weiß nur der Wind. Wenn du mal überlegst, wieviele mögliche Systeme es gibt und dagegen hältst, wie ungenau deine ursprüngliche Frage ist, kannst du doch keine konkrete und ernsthafte Antwort erwarten. Fragen dieser Art führen entweder zu - einer elend langen Diskussion, wo alle spekulieren, was damit gemeint seint könnte, oder - zu einer gewissen Ausgelassenheit wie hier -- Auf einfachen Systemen wird wohl maximal eine Variable zu einem Zeitpunkt geschrieben werden können (falls du mit "Schreibzyklus" einen Zyklus des physikalischen RAM meinst). Es kann aber auch mehrere (CPU-) Takte für eine Variable brauchen, insbesondere wenn sie größer als ein Byte ist - je nach System. Andererseits gibt es Systeme, die eine oder mehrere Ebenen zur Zwischenpufferung (Cache) haben. Dann können auch mal mehrere Variablen in einem Rutsch übertragen werden, aber das sind eher nicht die Mikrocontroller, um die es hier geht. Prüfen kann man das mit den Unterlagen wieder, oder durch Simulation oder evtl. Debuggen - je nach System, das hier keiner kennt.
@Sandra: Du wirst garde ein wenig veräppelt, weil deine Fragestellung drauf hinweist, daß du dich grad weniger als überhaupt nicht mit dem Thema auskennst. Nein, man kann nicht "direkt sagen, wieviele Variablen in einem Schreibzyklus geschrieben werden". Man kann natürlich ermitten (prozessor-spezifisch), welche Speicherbreite der Prozessor hat (z.B. 32 bit). Und dann kann man ermitteln, daß ein einzelner Assemblerbefehl xy Takte braucht, um 32 Bit aus einem Prozessor-Register in den Speicher zu schreiben, oder pq Takte braucht, um 32 Bit von einem Ende des Speichers in einen anderen Ende des Speichers zu kopieren. Beides wäre "ein Schreibzyklus", welche jedoch schon mal unterschiedlich schnell laufen. Wenn du die Taktfrequenz kennst, könntest du dann sogar errechnen, wieviele (Kilo-, Mega-, Giga-) Bytes du pro Sekunde bei einem solchen Block-Befüllung oder einem solchen Blocktransfer übertragen kannst. Sicherlich könntest du auch ein Programm schreiben, welches z.B. 1 Mio Speicherzugriffe der genannten Art durchführt, und dann de Zeit stoppen, wie lange dieser Vorgang gedauert hat. Aber auch das Programm selbst (welches ja z.B. einen Schleifenzähler hochzählen muß) macht ja keinen permanenten Zugriff, also ist diese Angabe auch entsprechend "verfälscht". Wieviele Variablen du jetzt aber in 32 Bit "hinein bekommst", hängt unter anderem von dir ab. Du könntest z.B. 32 bit so nutzen, daß jedes Bit eine Variable repräsentiert, dann hättest du "32 Variablen in einem Schreibzyklus geschrieben". Du könntest es aber auch so nutzen, daß die 32 Bit eine Gleitkommazahl repräsentieren. Damit hättest du "1 Variable in einem Schreibzyklus geschrieben". Ich vermute, der eigentliche tiefere Sinn deiner Frage ist ganz wo anders. Nenne ihn uns mal, dann kann man auch eine passendere Antwort geben.
Es handelt sich um den TMS 570 von TI. Er hat einen 32 bit breiten Bus und einen Prozessortakt von 190 MHz. Es wurde eine Test mit einer Performance Monitoring Unit gemacht. Damit kann man unter anderem die Größen wie RAM Zugriffe der CPU messen. Dabei hat sich herausgestellt, dass die CPU ungefähr 18000 Schreibzugriffe innerhalb von 5ms macht. Ich möchte im eigentlich wissen, wie Groß die Datenmenge ist, die ich in diesem Fall habe und wie ich diese berechne. Hoffe diese Angaben reichen aus. Ansonsten müsst ihr mir das sagen.
Ein Schreibzugriff bei einem 32 Bit Bus beinhaltet naheliegenderweise maximal 4 Bytes, möglicherweise aber auch 1 oder 2 Bytes. Bei 18000 Schreibzugriffen sind also zwischen 18000 und 72000 Bytes über den Bus gewandert. Es ist daraus nicht ersichtlich, ob das 18000 verschiedene Variablen waren oder nur eine einzige immer wieder.
Tja Und dann gibt es dann auch noch das weite Feld der 'Spezial-CPUs' Wie ist das auf Mehrprozessorsystemen? Wenn 10 Transputer gleichzeitig jeweils eine 'Variable' (was immer das auch sein mag) beschreiben, kann man dann sagen, dass 10 Variablen gleichzeitig beschrieben wurden? Wie ist/war das auf Vektorrechnern, wie zb der legendären Cray-1. Ihr Rechenwerk war darauf ausgelegt, dieselbe Operation auf mehrere Daten gleichzeitig anzuwenden. Ich hab jetzt die Details nicht mehr im Kopf, aber es würde Sinn machen, diesen Multi-Akkumulator auch mit einem entsprechend breiten Datenbus in einem Rutsch wieder in den Speicher zurückschreiben zu können. In einem gewissen Sinne sind daher auch hier 'mehrere Variablen' in einem Rutsch geschrieben worden. Was ist mit Bit-Slice Prozessoren? Was ist mit ...
Also im schlimmsten Fall sind das 4 Byte. Kann man das genauer spezifieren? Also mit einem Test oder eventuell den Herstellen kontaktieren? Oder kann man das herausfinden, indem man das Programm debuggt?
Variablen ist sind die, die man im Programm erzeugt hat. Ich habe gedacht, dass das wenigstens verständlich gewesen wäre.
Sa No schrieb: > Also im schlimmsten Fall sind das 4 Byte. Nicht im schlimmsten Fall. Im besten Fall! > Kann man das genauer > spezifieren? Ohne das Programm zu kennen: Nein Aber man kann wohl davon ausgehen, dass ein Hersteller seine Testprogramme so schreibt, dass sie das System im bestmöglichen Licht dastehen lassen. Und ja: Meistens gibt der Hersteller seine Test und Messprogramme in Source-Code Form zum System dazu. Also mal alle CD's und Dokus dorchforsten ob sich der Quellcode irgendwo findet. Ansonsten bleibt nur: Zigeunerin suchen und deren Glaskugel benutzen.
Sa No schrieb:
> Also im schlimmsten Fall sind das 4 Byte.
Dass ein Byte i.A. aus 8 Bits besteht ist bekannt?
Und ob die Statistik die Speicherzugriffe exakt zählt oder abschätzt
oder Stichproben nimmt oder schlicht erfindet, das kann ausser dir
niemand wissen. Sind deine Zahlen, nicht meine.
Allerdings kann hinzu kommen, dass Prozessoren mit Caches teilweise in
Cacheblöcken statt Bytes oder Busworten operieren. Dann sollte man
wissen, ob die Zugriffe auf den Cache gezählt werden, oder die Transfers
zwischen Cache und Speicher. Auch dies kann ausser dir und den um dich
herum gestapelten aber entweder nicht gelesenen oder nicht verstandenen
Handbüchern niemand wissen.
ja klar ist das bekannt, dass 4 Byte 8 bit sind. Die Speicherzugriffe wurden nicht aus einer Statistik entnommen sondern über mehrere verschiedene Tests gemessen. Ich habe allerdings keine Handbücher und auch nicht den Source Code. Ich habe nur das Datenblatt des Micos. Wenn ich mir dann aber allerdings die Datenrate betrachten würde, dann hätte ich bei 18000 Zugriffen der CPU auf das RAM eine Datenrate von 115,2Mbit/s = 14,4 MByte/s. Wenn ich diese dann aber noch weiter über Kupfer Transportieren wollte, dann ist das aber für mich der worst case. Oder hab ich da wieder einen Fehler gemacht?
Die Datenraten auf den externen Verbindungen aktueller PC-Prozessoren liegen im zweistelligen GB/s Bereich. Trotz Kupfer. Wo also ist das Problem? Oder willst du den Prozessor in London betreiben, den Speicher aber in Warschau? Sogar ein 8 Bit AVR schafft zwischen RAM und CPU bis zu 20MB/s. Kann es sein, dass du noch nicht einmal die Fragestellung verstanden hast? Den Eindruck kriege ich jedenfalls.
> Wenn ich mir dann aber allerdings die Datenrate betrachten würde, dann > hätte ich bei 18000 Zugriffen der CPU auf das RAM eine Datenrate von > 115,2Mbit/s = 14,4 MByte/s. Wenn ich diese dann aber noch weiter über > Kupfer Transportieren wollte, dann ist das aber für mich der worst case. Willst du etwas die Verbindung vom RAM zur CPU verlängern? Für welchen Zweck interriessiert dich den die Datenrate von einem Testprogramm. Wenn du für die CPU ein Programm schreibst, können die Zugriffe komplett anders ausehen.
Ich glaub das läuft hier alles aus dem Ruder. Also... Ich bekomme alle 5ms Daten. Diese sind z.B. bei 4 Byte und 18000 Zugriffen der CPU ja 72kbyte. Diese Datenmenge bekomme ich dann alle 5ms und wenn ich diese Daten auswerten möchte, MUSS ich die Daten irgendwo anders abspeichern. Deshalb das mit der Datenrate. Aber das wäre nicht die eigentliche Frage. Anscheinend kann ich das nur klären, indem ich das Programm verstehen muss, was im Mikro arbeitet, um die wirkliche Datenmenge zu erfahren
Sa No schrieb:
> Ich glaub das läuft hier alles aus dem Ruder.
Das liegt daran, dass du Maulfaul bist und denjenigen, die dir helfen
sollen, nur so wenig wie moeglich verraetst.
Sa No schrieb: > Diese Datenmenge bekomme ich dann alle 5ms und wenn ich diese Daten > auswerten möchte, MUSS ich die Daten irgendwo anders abspeichern. > Deshalb das mit der Datenrate. Willst du die über den Prozessorbus laufenden Daten protokollieren??? Da sind bei diesem Prozessor 14MB/s aber ausgesprochen wenig. Oder willst du ganz etwas anderes und stellst nach wie vor mit beachtlicher Konsequenz die falschen Fragen?
Bei diesem Prozessor gibt es auch noch eine RTP(RAM TRACE PORT) Schnittstelle. Dies erkennt die Änderungen im RAM und kann diese rausdumpen. Ich weiß einfach nicht wie ich das anders erklären soll.
Den Teil habe ich bereits vermutet. Geht es also darum, die Trace-Daten des Prozessors längerfristig aufzuzeichnen? Oder geht es um eine bestimmte Anwendung, deren Daten aufgezeichnet werden sollen, und du suchst permanent an der falschen Stelle? Jedenfalls liegt das Ausmass an Daten, dass an einem Trace-Port eines solchen Prozessors auftreten kann, bei weitem höher als die mickrigen 14,4MB/s.
Oh gut, also doch ein Detail vergessen zu erwähnen g Sorry. Das hätte sonst doch schneller gehen können Es geht darum die Daten längerfristig aufzuzeichen. Die RTP Schnittstelle besitzt 16 Daten Pins und an jedem Pin sind 100Mbit/s.
Die Frage die ich ursprünglich hatte war, wie man nur die Änderung des RAMs erfassen kann. Also wenn man nicht die RTP hat. Ein Schritt der gemacht wurde und auch gemessen wurde war es mit der PMU. Diese gibt mir aber nur den Zugriff der CPU auf das RAM. Womit ich immer noch nicht richtig die tatsächliche Änderung wüsste, sondern nur eine Abschätzung hätte. Ich hoffe das versteht man
Also: Du willst wissen was sich im RAM ändert. Die PMU liefert den Zugriff der CPU auf das RAM. Wäre im ersten Ansatz also das was du suchst. Reicht aber nicht. Grund mal wieder nicht genannt. Sorry, aber jetzt ist Schluss. Diese Salamitaktik nervt nur noch. Ausserdem geht das zu sehr in die Details dieses speziellen Prozessors mit RTP und PMU und wassweissichnoch. Und es entsteht bei mir der Eindruck einer etwas zu eklatanten Diskrepanz zwischen Anspruch/Aufgabe und Ahnung.
Wegstaben Verbuchsler schrieb: >> ja klar ist das bekannt, dass 4 Byte 8 bit sind. > > tja, das wars dann wohl ... Nicht so voreilig! Es ist nur üblich, aber nicht zwangsläufig so, daß ein Byte auch 8 Bit hat. Auf ihrem Rechner scheint ein Byte halt nur zwei Bit zu haben. Das erleichtert vielleicht die Suche nach der Typbezeichnung etwas, so viele kann es davon ja nicht geben.
Der Flaschenhals ist bei gängigen Systemen idR. der Bus zum externen Ram. Die maximale Datenrate ist das Produkt aus Busbreite und Busfrequenz. Diese wird aber, vor allem wegen der nötigen Refreshzyklen, Seitenwechseln etc., nie erreicht. Die maximale interne Datenrate ist bei den üblichen RISC Prozessoren die Registerbreite mal der (internen) Taktfrequenz. Wird aber ebenso praktisch nie erreicht weil der Cache irgendwann voll ist und man die Daten ja auch noch irgendwie verarbeiten möchte. Dann gibt es noch viele Mechanismen, wie z.B. Page faults in der MMU, die den Speicherzugriff für längere Zeit unterbrechen und somit die effektive Datenrate drücken. In Programmteilen wo man auf die Performance angewiesen ist sollte man also Vorkehrungen treffen, dass sowas nicht passiert. Viele Grüße, Martin L.
> Ich weiß einfach nicht wie ich das anders erklären soll
Hm, du arbeitest in einem technischen Beruf, und bist nicht in der Lage,
dein Anliegen präzise zu artikulieren, zumindest so zu formulieren, daß
auch ein anderer "Techniker" dich versteht. (muß ja nicht
Marketing-Blah-Sprache oder Management-Klickibunti Sprache sein)
Da ist du dir aber eine ziemlich elementare Fähigkeit für technische
Berufe abgängig.
Hast du schon mal über einen Berufswechsel nachgedacht, bei dem
derartige Fähigkeiten weniger häufig benötigt werden, z.B. im
künstlerisch-kreativen Bereich?
Naja... wenn man sich bei einer Sache vertippt, z.B. 4 Byte = 8 bit, dann wird man hier als blöd dargestellt. Ich hab mein Problem hier klar erläutert, aber anscheinend kann mir hier keiner weiter helfen. Der Grund für das war, dass man einen genauen Wert für die Datenmenge bekommt.
Sa No schrieb: > Ich hab mein Problem hier klar erläutert, aber anscheinend kann mir hier > keiner weiter helfen. Ein Geisterfahrer? Hunderte!!!
Sa No schrieb: > Ich hab mein Problem hier klar erläutert, aber anscheinend kann mir hier > keiner weiter helfen. Das seh ich nicht so. Nach all diesen Posts haben einige vielleicht eine Ahnung was dein Problem sein könnte.
Also ich habe diesen Thread heute Morgen zufällig beim Frühstücken gefunden. Bis jetzt hat er mir ungemein den Tag versüßt^^ Das ist Aneinandervorbeireden babylonischen Ausmaßes. Weiter so!
Karl heinz Buchegger schrieb: >> Ich hab mein Problem hier klar erläutert, aber anscheinend kann mir hier >> keiner weiter helfen. > > Das seh ich nicht so. > Nach all diesen Posts haben einige vielleicht eine Ahnung was dein > Problem sein könnte. Du schreibst jetzt 100x: Ich soll als Moderator nicht eskalieren! ]:-)
Olli R. schrieb: > Karl heinz Buchegger schrieb: > >>> Ich hab mein Problem hier klar erläutert, aber anscheinend kann mir hier >>> keiner weiter helfen. >> >> Das seh ich nicht so. >> Nach all diesen Posts haben einige vielleicht eine Ahnung was dein >> Problem sein könnte. > > Du schreibst jetzt 100x: > > Ich soll als Moderator nicht eskalieren!
1 | #include <stdio.h> |
2 | |
3 | int main() |
4 | {
|
5 | int i; |
6 | |
7 | for( i = 0; i < 100; ++i ) |
8 | printf( "Ich soll als Moderator nicht eskalieren!\n" ); |
9 | }
|
Ist es so recht?
Karl heinz Buchegger schrieb: >> Ich soll als Moderator nicht eskalieren! > >
1 | > #include <stdio.h> |
2 | >
|
3 | > int main() |
4 | > { |
5 | > int i; |
6 | >
|
7 | > for( i = 0; i < 100; ++i ) |
8 | > printf( "Ich soll als Moderator nicht eskalieren!\n" ); |
9 | > } |
10 | >
|
> > Ist es so recht? Nicht anderes habe ich erwartet und etwas anderes haette mich auch enttaeuscht :-) Olli
@Sa No
>>>Naja... wenn man sich bei einer Sache vertippt, z.B. 4 Byte = 8 bit,
dann wird man hier als blöd dargestellt.
4Byte = 8bit ist nicht vertippt, das ist grob fahrlässig!!!!
und als blöd stellt dich hier auch keiner hin.
Die Jungs langweilen sich, keine Herausforderung, keiner weiß so ganz
genau wo dein Problem liegt.
Tip. ne kleine Skizze(als png, gif), n bisschen hübsch zurechtgemacht,
1-2 rote Pfeilchen, die Hindergründe erzählen(Randbedingungen)
und das kann DIR eben keiner abnehmen bzw. erraten
deswegen die Bloßstellungen.
Ich würd mal so anfangen und das Problem im größeren Zusammenhang schildern: Was ist die eigentliche Aufgabenstellung?
Karl heinz Buchegger schrieb:
> Ist es so recht?
Nein. Das gibt eine Fehlermeldung.
Du hast main() nicht ordentlich beendet.
A. K. schrieb: > Karl heinz Buchegger schrieb: > >> Ist es so recht? > > Nein. Das gibt einen Fehlermeldung. Du hast main() nicht ordentlich > beendet. Huch. Wo soll da was sein? (Wenn du auf return anspielst: main() ist die grosse Ausnahme. Auch wenn main() einen int retourniert, braucht man den return nicht selber schreiben. Der Compiler muss sich dann ein return 0; dazudenken. Find ich auch unlogisch, ist aber so. Und zwar nur bei main!)
Sa No schrieb: > ich würde gerne mal wissen, ob man direkt sagen kann, wieviele Variablen > in einem Schreibzyklus geschrieben werden. > > Kann man dazu auch einen Test machen, um dies genau raus zu finden? Viele Threadersteller scheitern hier daran, dass sie ihr Problem nicht vernünftig (technisch) beschreiben können. Oftmals mutet das an, als ob ein Laie in einem Apothekerforum fragt "Ich würde gerne mal wissen, welche möglichen Medikamentwechselwirkungen es mit Aprikosen gibt. Kann man dazu einen Test machen um rauszufinden, ob das mit würfelförmigen Aprikosen bei runden Tabletten anders wäre?" Andere wiederum scheitern daran, dass sie versuchen, ihr Problem stark vereinfacht darzustellen, dabei aber vergessen, dass sie hier nicht bei heise.de oder einem ähnlichen *e**e*forum sind. Warum ist es denn so schwer, eine Beschreibung der Fragestellung zu liefern, in der das Grundproblem/die Aufgabe geschildert wird, anstatt eine abstrakte Frage zu stellen, anhand derer es nur nach mühevollem Nachfragen erkennbar ist, dass sich der Fragesteller längst auf dem Holzweg befindet? Olli
Gute Frage Olli. Ich habe noch ganz andere Fragen, wenn ich lese, für was dieser Prozessor so eingesetzt werden kann: "automotive applications" ... "will be implemented in next generation braking, steering and chassis control applications" Meine Frage wäre also, in welches Auto kommt dieses Projekt. Ich kaufe mir dann lieber ein anderes...
Dann probiere ich es noch mal. Die eigentliche Aufgabe ist, dass aus einem Steuergerät Daten aufgenommen werden soll. Auf dem Steuergerät befindet sich ein Mikro (TMS 570). Dieser Mikro verarbeitet Signale, die von Sensoren kommen. Diese Signale werden in Daten umgewandelt (bzw. mit diesen Daten werden die Variablen eines Porgramms gefüttert). Das Porgramm kenn ich selber nicht. Sollte auch nicht notwendig sein. Diese Daten die sich im RAM des Mikro befinden sollen auf eine externe Einheit gespeichert werden. Das ist die Grundlegende Aufgabe. Damit man nicht den kompletten RAM-Inhalt rausdumpen muss, der bei diesem Mikro 192kByte sind, soll nur die Änderung des RAMs, der sich alle 5ms ändert, rausgedumpt werden. Dafür wurde ein Test gemacht, indem gemessen wurde, wie oft die CPU aufs RAM zugreift. Dafür hat man dann einen ungefähren Wert für die Datenmenge. Also, wenn man das maximale rausholt was geht, dann hätte man z.B. bei einem 32 bit RISC Prozessor 4 byte oder 32 bit wären. Damit das komplett realisiert werden kann, müssen diese Änderungen alle 5ms rausgedumpt werden. Wichtig ist dazu zu sagen, dass bei den nächsten Mikro eine RTP (RAM TRACE PORT) Schnittstelle vorhanden ist. Diese erkennt alle Änderungen im RAM und kann diese mit 100Mbit/s pro PIN rausdumpen. Nur zur Zeit hat der momentane Mikro diese Schnittstelle nicht. Meine Frage war es jetzt nun, ob man die Datenmenge, die sich im RAM ändert noch genauer bestimmen kann. Da die andere Messung ungenau ist.
Sa No schrieb: > Meine Frage war es jetzt nun, ob man die Datenmenge, die sich im RAM > ändert noch genauer bestimmen kann. Da die andere Messung ungenau ist. Ganz einfach: RAM alle 5ms dumpen, Aenderungen diffen und das Ganze auf Sekunden normieren, schon hast Du die Aenderungsrate in kB/s. Aber wie willst Du eigentlich das controllerinterne RAM dumpen, wenn Du das Programm nicht kennst und es daher nicht modifizieren kannst? Was ist das fuer eine konkrete Anwendung, Automotive oder Luft- und Raumfahrt? Olli
Einfach gesagt, aber wenn ich den gesamten RAM raus dumpe, dann hätte ich pro sekunde bei 192 kByte RAM 38,4 Mbyte/s. Das war schonmal meine erste Idee, um die komplette aufgabe zu lösen. Also nur den kompletten RAM raus zu dumpen. Dabei hätte man zuviele unnötige Daten. Die Differenz zu bilden wäre aber so nicht schlecht, um es genau zu bekommen. Wie realisiert man das am besten physikalisch? Ja dafür müsste ich mich mit dem Programm auseinander setzten. Hätte gedacht, dass es auch noch eine andere Möglichkeit gibt. Ist für Automotiv
Sa No schrieb:
> Ist für Automotiv
Ohauerha.
Nochmal: Wie willst Du eigentlich das controllerinterne RAM dumpen, sei
es im Stueck oder seitenweise, wenn Du das auf dem Controller laufende
Programm nicht kennst und es daher nicht modifizieren kannst?
Das wird von einer anderen Person gemacht. Ich soll nur dafür sorgen, dass man es machen kann. Ich soll die physikalische Schnittstelle zwischen Steuergerät und externem Speicher zu Verfügung stellen
Um die "Differenz" zu bilden, musst Du aber irgendwo ein Abbild des alten Speicherzustandes ablegen und den aktuellen Speicherzustand damit vergleichen - und das bei jedem "Dump"-Zyklus. Nur so kannst Du herausfinden, wohin überall der Prozessor im RAM geschrieben hat. Mir scheint das ein reichlich fragwürdiges Unterfangen zu sein. Da Du nicht weiter darauf eingegangen bist, was für ein Prozessor/Controller das genau ist, können wir auch nicht herausfinden, ob da nun externes RAM oder internes RAM ist. Wäre es externes RAM, ließe sich mit einem Logikanalysator o.ä. "mithören". Was Du auch noch nicht verraten hast: Wozu soll das eigentlich gut sein? Geht es um "reverse engineering" eines auf diesem Prozessor/Controller laufenden Programmes?
Der Grund dafür ist eigentlich nur, dass man weiß welche Variablen sich im Programm ändern. Einen anderen Grund gibt es nicht. Ob das wirklich sinnvoll ist, das dürft ihr mich nicht fragen. Es handelt sich genau um den TMS570PSFD62. Dieser ist allerdings noch nicht auf dem Markt. Also der hat diese besagte RTP Schnittstelle.
wie willst du Variablen im Speicher erkennen? Man man nicht weiss was für ein Programm darauf läuft kann man dort nicht viel rauslesen. Wenn z.b. eine Speicherverwaltung mit malloc/free verwendet wird, dann steht die Variabel jedes mal an einer andere Stelle im Speicher. Auch wirst du ständig Änderrung am Stack feststellen woram man auch nichts erkennen kann. Wenn jetzt sogar noch Variablen überhaupt nicht im Speicher sonder noch im Register stehen dann ist es eh aus. Man eventuell sollte man versuchen das Programm zu Disassemblieren, das führt dann mit genügend zeit auf jedem Fall zu erfolg.
Ihr seid zu bequem, den Programmierer der Software zu fragen, wieviel Daten sich ändern ? Der kann doch auch gleich eine Schnittstelle zum Export der Daten einbauen... Alles könnte so easy sein, wenn es denn Kommunikation gäbe.
Rufus t. Firefly schrieb: > Um die "Differenz" zu bilden, musst Du aber irgendwo ein Abbild des > alten Speicherzustandes ablegen und den aktuellen Speicherzustand damit > vergleichen - und das bei jedem "Dump"-Zyklus. Nur so kannst Du > herausfinden, wohin überall der Prozessor im RAM geschrieben hat. Das hatte ich ihm ja schon vorgeschlagen, allerdings hapert es da dann an der Datenrate (37.5MB/s) > Mir scheint das ein reichlich fragwürdiges Unterfangen zu sein. Angeblich geht es um internes RAM. Bei externem waere das ja einfach. > Was Du auch noch nicht verraten hast: Wozu soll das eigentlich gut sein? > Geht es um "reverse engineering" eines auf diesem Prozessor/Controller > laufenden Programmes? Das Programm schreibt sein Kollege, und sie sprechen nicht miteinander.
> > Da Du nicht weiter darauf eingegangen bist, was für ein > > Prozessor/Controller das genau ist, können wir auch nicht herausfinden, > > Doch, hat er geschrieben: TMS570. Jetzt hat er es geschrieben: > Es handelt sich genau um den TMS570PSFD62. Die Angabe "TMS570" alleine ist genauso spezifisch wie "AVR" oder "PIC".
Sa No schrieb: > Das wird von einer anderen Person gemacht. Ich soll nur dafür sorgen, > dass man es machen kann. > > Ich soll die physikalische Schnittstelle zwischen Steuergerät und > externem Speicher zu Verfügung stellen Interessante Arbeitsweise. Wahrscheinlich geht's dabei um ABS oder Airbags. Eine derartige Arbeitsweise ist mir persoenlich bekannt, von der NASA. Dort vergluehen dann Raumfaehren, weil die Ingenieure nicht miteinander reden.
Sa No schrieb: > Das wird von einer anderen Person gemacht. Ich soll nur dafür sorgen, > dass man es machen kann. > > Ich soll die physikalische Schnittstelle zwischen Steuergerät und > externem Speicher zu Verfügung stellen Womit wir wieder bei der Grundproblematik waeren. Haettest Du das gleich gesagt, haette man Dir hier mitgeteilt, dass der Ansatz insgesamt fuer /dev/null ist und man haette sich die Diskussion hier erspart.
Rufus t. Firefly schrieb: > Um die "Differenz" zu bilden, musst Du aber irgendwo ein Abbild des > alten Speicherzustandes ablegen und den aktuellen Speicherzustand damit > vergleichen - und das bei jedem "Dump"-Zyklus. Nur so kannst Du > herausfinden, wohin überall der Prozessor im RAM geschrieben hat. Nein. Wenn es sich um eine trace Schnittstelle handelt, dann werden u.a. Speicherzugriffe protokolliert. Nach einem initialen Dump braucht man nur noch die folgenden Schreibzugriffe auszuwerten. > Wäre es externes RAM, ließe sich mit einem Logikanalysator o.ä. "mithören". So ähnlich funktioniert eine Trace Schnittstelle ja auch. Etwas cleverer vielleicht -- und funktioniert auch mit on-chip RAM. @Sa No > Meine Frage war es jetzt nun, ob man die Datenmenge, die sich im RAM > ändert noch genauer bestimmen kann. Da die andere Messung ungenau ist. Ich hab' zwar gerade vergessen, was "die andere Messung" war, aber der ARM Cortex-R4 Kern, der vermutlich in Deinem Controller steckt, hat sogenannte Performance Monitoring Register. Die könntest Du mal nach "explicit memory writes" befragen. Daraus kannst Du Dir möglicherweise eine genügend genaue Änderungsrate ermitteln. Bei weiteren Fragen, einfach mal melden. Gruß Marcus http://www.doulos.com/arm/
Marcus Harnisch schrieb: > @Sa No > Ich hab' zwar gerade vergessen, was "die andere Messung" war, aber der > ARM Cortex-R4 Kern, der vermutlich in Deinem Controller steckt, hat > sogenannte Performance Monitoring Register. Die könntest Du mal nach > "explicit memory writes" befragen. Daraus kannst Du Dir möglicherweise > eine genügend genaue Änderungsrate ermitteln. Zu viele Messages -- ich verliere den Überblick! Kann man diesen Forensoftwareentwicklern mal erklären wie man ordentliches Threading implementiert? <abschweif/>Ich wünschte die Leute würden sich wieder auf das Usenet besinnen. Ich habe gerade gesehen, dass Du die PMU ja schon befragt hast. Wie man daraus die Datenrate berechnet hat Dir auch schon jemand erklärt. Ist eben der worst case. -- Marcus http://www.doulos.com/arm/
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.