Hallo liebe Programmier/C-Profis. ich schätze mal, dass ich mit meiner Frage wohl eher die Profis unter euch ansprechen werde. Es geht um folgendes. ich möchte einen Druck- und einen Beschleunigungssensor simulieren und das ganze per microController realisieren. der Ablauf soll zeitlich plausibel also immer vorhersehbar bzw beeinflussbar sein. Was hier den Einsatz eines TI (TMS320F28335) C2000 Board oder vielleicht nen AVR-basierten µC empfiehlt?! Ziel ist das ganze erstmal in C zu realisieren und dann noch in manchestercode umzuwandeln. Der Drucksensor liefert zur Zeit x einen gewissen promillewert also den Differentiellen Druckanstieg gemessen zum Vorwert (Normdruck). Während der Druckanstieg zur zeit x genau oder mehr als 100 Promille beträgt, soll der beschleunigungswert ausgegeben werden. Die zeitliche Differenz darf/soll 30ms nicht überschreiten da das Signal sonst vom auswertenden Steuergerät als unplausible aberkannt wird. Ziel ist die Grundlage in C zu schaffen um, jetzt kommts, einen Crash zu simulieren und damit dem steuergerät FeuerFrei zu ermöglichen. Hier wird dann kein Airbag gezündet sondern nur die Zündausgänge werden überwacht. Ich hoffe ich hab den Grundgedanken etwas vermitteln können und auf rege Beteiligung. MFG Roger
Was genau zu simulieren ist kam nicht genau durch. Muss es aber auch nicht. Ja man kann etwas Simulieren. Einfach die Differentialgleichung abspulen...
Quizzer11 schrieb: > Ich hoffe ich hab den Grundgedanken etwas vermitteln können und auf rege > Beteiligung. Nein. Eine universelle Beschreibungssprache des Ingenieurs ist die Formel. Schreib deinen Sachverhalt damit auf und formuliere die Frage nochmal.
Quizzer11 schrieb: > Ziel ist das ganze erstmal in C zu realisieren und dann noch in > manchestercode umzuwandeln. warum so kompliziert? reicht da nicht ein einfacher arbiträrer Signalgenerator mit 2 Kanälen? Gibts da nicht auch schon fertige Lösungen von den üblichen Verdächtigen die Prüfstande und Testequipment (Stichwort HIL) bauen? Gruß Anja
Quizzer11 schrieb: > ich möchte einen Druck- und einen > Beschleunigungssensor simulieren welche uC geeignet ist hängt davon ab wie die Daten Übertragen werden müssen. Analog? CAN, SPI, usw. ? > Ziel ist das ganze erstmal in C zu realisieren und dann noch in > manchestercode umzuwandeln. Ich verstehe nicht ganz warum man ein funktionierendes Programm in ein Signal umwandeln sollte? Umgedreht wäre ja sinnvoll, aber so?
Hallo, da sehe ich 2 Möglichkeiten: A du zeichnest die Daten eines realen Crashs auf und spielst sie deinem Gerät einfach wieder vor. B Du mietest für eine Weile eine Grossrechenanlage, programmierst die Simulation z.B. eines Audi100, lässt ihn virtuell gegen die Wand fahren und lässt dir ausgeben, welche Signale dabei beim Sensor ankommen. Die verwendest du dann zum Testen. Für eine abschliessende Beurteilung brauchst du aber Version A. Die Wirklichkeit ist immer noch der Massstab. Ich möchte jedenfalls nicht in einem Auto fahren, dessen Airbag nur bei Unfallverläufen auslöst, die du dir theoretisch ausgedacht hast, ganz abgesehen davon, dass du deine Vorstellungen ja auch erst mal in Gleichungen umsetzen müsstest. Gruss Reinhard
Reinhard Kern schrieb: > Die Wirklichkeit ist immer noch der Massstab. Ich möchte jedenfalls > nicht in einem Auto fahren, dessen Airbag nur bei Unfallverläufen > auslöst, die du dir theoretisch ausgedacht hast, ganz abgesehen davon, > dass du deine Vorstellungen ja auch erst mal in Gleichungen umsetzen > müsstest. Gute Antwort. Ich möchte ausserdem nicht davon abhängig sein, dass jemand der eine Aufgabenstellung so unverständlich beschreiben kann wie der TO, die entsprechende Simulation schreibt. Wenn schon Simulation, dann sollte das jemand sein, der auch etwas davon versteht.
Ja aber habt ihr den Original-Post überhaupt ganz gelesen, oder bloss die Worte Airbag und Simulation aufgeschnappt? Ich kann ja falsch liegen, aber ich hatte den Eindruck er will nur ein vorhandenes Steuergerät (hat er nicht selbst gebaut und will er auch nicht modifizieren und in eure neuen Autos einbauen) dazu bringen auszulösen, indem er die Sensordaten Simuliert.
Johannes G. schrieb: > dazu bringen > auszulösen, indem er die Sensordaten Simuliert. Das ist schon klar, aber wozu soll das gut sein? Wenns bloss schön knallen soll, so wie du das darstellst, da gibt es ja einfachere Möglichkeiten. Gruss Reinhard
Johannes G. schrieb: > Ich kann ja falsch liegen, aber ich hatte den Eindruck er will nur ein > vorhandenes Steuergerät (hat er nicht selbst gebaut und will er auch > nicht modifizieren und in eure neuen Autos einbauen) dazu bringen > auszulösen, indem er die Sensordaten Simuliert. Hab ich schon gelesen. Ich glaube aber auch gelesen zu haben, dass es dazu dienen soll Steuergeräte zu testen, ob sie bei entsprechenden Sensordaten auch wirklich zuverlässig auslösen. D.h. er will dem Steuergerät einen Crash vortäuschen.
Wer sagt was von knallen? Quizzer11 schrieb: > Hier wird dann kein Airbag gezündet sondern nur die Zündausgänge werden > überwacht.
Karl Heinz Buchegger schrieb: > Steuergeräte zu testen, ob sie bei entsprechenden Sensordaten auch > wirklich zuverlässig auslösen Das ist eher Spekulation. Sagt er ja so nicht. Kann aber natürlich sein...
Johannes G. schrieb: > Karl Heinz Buchegger schrieb: >> Steuergeräte zu testen, ob sie bei entsprechenden Sensordaten auch >> wirklich zuverlässig auslösen > > Das ist eher Spekulation. Das halbe Posting ist Spekulation. Natürlich. Nur, wer so unzusammenhängende Sätze schreibt und bei 30 Millisekunden Zeitvorgaben kalte Füsse bekommt, dem trau ich erst mal nicht weiter über den Weg. Meine persönliche Meinung.
Kann soetwas nicht z.B MATLAB? D.h. in SimuLink physikalisches Modell darstellen und mit Code-Generator in C übersetzen? Wenn Du denn C-Code hast, kannst Du ja abschätzen, ob es machbar ist oder nicht. Selber trial& error..
Versuch einer Interpretation > Der Drucksensor liefert zur Zeit x einen gewissen promillewert also den > Differentiellen Druckanstieg gemessen zum Vorwert (Normdruck). > Während der Druckanstieg zur zeit x genau oder mehr als 100 Promille > beträgt, soll der beschleunigungswert ausgegeben werden. Zu einem bestimmten Zeitpunkt x soll der Druckanstieg, also der Wert vom Sensor, geprüft und wenn zu diesem Zeitpunkt 100 Promille überstiegen werden, ein Beschleunigungswert ausgegeben werden. Die Ausgabe dieses Wertes muß innerhalb von 30 Millisekunden nach Eintreten des Zeitpunktes x erfolgen, sprich, seine wie auch immer gestaltete Logik (Controller, sonstiges) muß eine maximale Antwortzeit von 30 ms haben. Die Druck- und Beschleunigungswerte sind bekannt, deswegen muß kein Auto mehr gecrasht werden. Es geht wohl nur um den Test, ob das Steuergerät auslöst, wenn die definierten Druck- und Beschleunigungswerte innerhalb der definierten Reaktionszeiten vorliegen.
Uwe G. schrieb: > Versuch einer Interpretation > >> Der Drucksensor liefert zur Zeit x einen gewissen promillewert also den >> Differentiellen Druckanstieg gemessen zum Vorwert (Normdruck). >> Während der Druckanstieg zur zeit x genau oder mehr als 100 Promille >> beträgt, soll der beschleunigungswert ausgegeben werden. > > Zu einem bestimmten Zeitpunkt x soll der Druckanstieg, also der Wert vom > Sensor, geprüft und wenn zu diesem Zeitpunkt 100 Promille überstiegen > werden, ein Beschleunigungswert ausgegeben werden. Nehme ich das noch mit dazu > ich möchte einen Druck- und einen Beschleunigungssensor simulieren dann ist das ganz einfach das programmgesteuerte Nachfahren eines Druckprofils, entsprechende Unwandlung in das Signal, welches ein Drucksensor liefern würde mit zugehöriger Generierung eines Beschleunigungssensor Signales. Mit diesen Vorgaben etwas absolut Unspektakuläres und wenig komplexes.
Johannes G. schrieb: > Ja aber habt ihr den Original-Post überhaupt ganz gelesen, oder bloss > die Worte Airbag und Simulation aufgeschnappt? > > Ich kann ja falsch liegen, aber ich hatte den Eindruck er will nur ein > vorhandenes Steuergerät (hat er nicht selbst gebaut und will er auch > nicht modifizieren und in eure neuen Autos einbauen) dazu bringen > auszulösen, indem er die Sensordaten Simuliert. genau so war es gemeint. Danke Johannes. Ich war scho am zweifeln ob ich wirklich so einen Mist geschrieben habe ;) Also ich möchte mich gerne irren, aber scheint es so als ob bei einigen Profis das Wissen zu kopf steigt und das gerne in Arroganz umschlägt? Ich hatte 2009 schon mal ein Problem hier lösen wollen bin aber nach den ersten Kommentaren doch etwas stutzig geworden wie sehr doch Neulinge behandelt werden. Ich habe eine sachliche Frage gestellt und wollte hier keine Grundsatzdiskussion entfachen. Ich möchte mich jedoch gerne etwas spezieller ausdrücken. Und das ganze ohne Fachchinesisch, was offen gesagt die meisten Superingenieure nur nutzen um einfache Sachverhalte sinnlos zu verkomplizieren. genug der Schwachsinnskommentare: back to Topic: Also der drucksensor arbeitet auf dem Manchestercodeprinzip. dieser sendet aller 228µs ein 108µs langes datenpaket zu einer Länge von 13bits. 2 Startbits 8datenbits und ein Paritätsbit. Bei Zündung ein (ach ja es ist auf dem CANbus laufendes Signal) wird der Sensor initialisiert und sendet nach dem ersten zustandsinfos seine istdaten aller 228µs. Diese Daten gilt es zu simulieren und ggf zu verfälschen. Quasi wie eine Restbussimulation. Wenn der Sensor seine Werte (jetzt liegt ein Crash vor) an das Steuergerät leitet, erwartet dieses außerdem eine Erschütterung (hier kommt der Beschleunigungssensor zum tragen) und zwar in einem vordefiniereten mindestabstand. Ist der mindestabstand der Signale zu groß (radfahrer fährt gegen die Tür) soll das SG folglich nicht auslösen. ich glaube das Prozedere sollte soweit klar sein! meine Frage ist wie ich das ganze am besten realisiere oder bessere Frage. Welcher µC taugt für sowas und wie (grob) sollte so ein Code in C etwa aussehen? benötige ich ein extra Tranceiver für dieses Vorhaben oder langen die DIOs dafür aus? ich danke
Ach ja eins noch: Ich möchte um Himmels willen keine echten Airbags zünden. Von den Vollhonks gibts auf Youtube genug zu sehen. Hier geht um eine Verkabelungsprüfung ab Steuergerät. Es soll getestet werden, ab alle Aktuatoren ihren erwarteten Dienst verrichten würden (Zündausgänge), wenn es zu solch einem Ernstfall kommen würde. @ Anja. Ja die Hardware in the Loop-Prüfstände sind bekannt, aber vom Hersteller der Sensoren nicht für Externe vorgesehen. Eine Prüfstandsmiete wäre im Rahmen der Aufgabe ien Zacken zuviel.
Rechenleistung brauchst du nicht viel für die Aufgabe, viel wichtiger bei solch genauen Zeitvorgaben ist der Quarz. Nimm auf jeden Fall nen "krummen", (z.b. keine glatten "32.0 MHz") dann kannst du die Vorteiler für Timer und UART&co. sehr genau einstellen. Ob es uC gibt die Manchester von haus aus ohne externe Peripherie können weiß ich garnicht, am besten mal bei den üblichen verdächtigen nachschauen. EDIT: ich würde keinen ARM-Cortex basierten uC nehmen, die haben bei höheren Takten ein nicht mehr ganz so gut vorhersagbares Zeitverhalten wie übliche 8Bit, durch unterschiedliche Takte von Core/interne Peripherie und "langsamen" Flash und dadurch Prefetch usw.
Benjamin F. schrieb: > Rechenleistung brauchst du nicht viel für die Aufgabe, viel wichtiger > bei solch genauen Zeitvorgaben ist der Quarz. Nimm auf jeden Fall nen > "krummen", (z.b. keine glatten "32.0 MHz") dann kannst du die Vorteiler > für Timer und UART&co. sehr genau einstellen. Ein krummer Quarzwert... Irgendeiner? Oder meinst du Baudratenquarze? Dann würde zumindest die Aussage nicht völlig Falsch sein. Aber Baudratenquarze sind ein Relikt der 80&90er Jahre, moderne µC haben alle Baudratengeneratoren und auch eine PLL. Wenn dann noch weitere Anforderungen dazu kommen, wie interne CAN HArdware, dann ist die Auswahl eh eingeschränkt. Davon abgeshen lässt sich mit "glatten" Werten viel einfacher rechnen. Für PIC z.B. ist es so das man irgendwass glatt durch 4Mhz teilbares <=20Mhz nimmt und den Rest macht die Interne HArdware. Egal ob der µC dann mit 1Mhz oder mit der Maximalgeschwindigkeit (je nach Typ 48Mhz, 64MHz oder 80Mhz) laufen soll. > Ob es uC gibt die Manchester von haus aus ohne externe Peripherie können > weiß ich garnicht, am besten mal bei den üblichen verdächtigen > nachschauen. Manchester ist nun wirklich keine Hexerei. Das kann man mit jedem µC bequem hinbekommen. Die daten werden innerhalb des Programms ganz normal behandelt und in einem Array abgelegt, einzig besonders ist dann die Ausgaberoutine die nun je nach Polarität vor oder hinter jedem BIT im Array ein Bit invertierter Polarität einschiebt. Das kann entweder direkt bei der Ausgabe geschehen, oder aber man hat ein zweites Array in das die umgewandelten Daten hineinkopiert werden. (daran denken das dies dann doppelt so groß sein muss, aus jedem Nibble wird so ein Byte) Wenn der PEGEL nicht höher als die Betriebsspannung des µC sein soll (5V bzw. 3,3V, je nach Typ) reicht ein Einfacher IO. Ansonsten muss halt ein Treiber nachgeschaltet werden bzw. ein Eingang mit OC Characteristik verwendet werden der auch höhere Spannungen verträgt. Das bieten aber nur einige µC auf wenigen IOs. > EDIT: ich würde keinen ARM-Cortex basierten uC nehmen, die haben bei > höheren Takten ein nicht mehr ganz so gut vorhersagbares Zeitverhalten > wie übliche 8Bit, durch unterschiedliche Takte von Core/interne > Peripherie und "langsamen" Flash und dadurch Prefetch usw. Auch das ist so relativ irrelevant. Die Laufzeitberechnungen anhand der Taktzyklen sind nun wirklich lange obsolet. MAcht man sowieso nur bei reinen ASM Anwendugen. Heute auch nur noch dann wenn kein Timer mehr zur Verfügung steht weil bereits alle belegt sind. ISt nur bei ganz kleinen Projekten auf den kleinsten Controllern der Fall. Heute löst man sowas geschickt mit Timerinterrupts, da kann man das auf auf wenige ns genau vorgeben und beliebig skalieren. und bei 30ms die hier als vorgabe gelten ist das nun wirklich kein Hexenwerk. Wenn keine weiteren Anforderungen vorliegen könnte das sogar mit einem 8Bitter passen, aber wenn ich jetzt vor der Aufgabe stände würde mein Wahl wohl auf den PIC32MX795 fallen. Schnell genug, genug ressourcen, hat CAN Anbindung und alles was das HErz begehrt. ISt genau genommen schon reichlich überdimensioniert. Aber man hat halt reserven. Ein ARM7/Cortex M3 geht genauso. Mit DSP oder ähnlich braucht man nicht Anfangen wenn nur vordefinierte Werte simuliert werden sollen. Gruß Carsten
Carsten Sch. schrieb: > moderne µC haben > alle Baudratengeneratoren Und was genau verstehst du unter "Baudratengenerator"? Kuck mal ins Datenblatt eines at90usb wieviel Abweichung der bei welcher Einstellung erzeugt. Ob das dann ausreichend ist kann jeder selbst entscheiden. Carsten Sch. schrieb: > Manchester ist nun wirklich keine Hexerei. Das kann man mit jedem µC > bequem hinbekommen. Also zumindest bei der internen Peripherie des efm32g ist mir eine entsprechende Einstellung nicht aufgefallen. Wenn man dafür nen GPIO nimmt ist es natürlich wirklich kein Problem. edit: >und bei 30ms die >hier als vorgabe gelten ist das nun wirklich kein Hexenwerk. wie kommst du auf 30ms? ich lese da was von 228µs und 108µs. Die 30ms sind ja ein Grenzwert des vorhandenen Steuergerätes und haben nix mit dem was ich geschrieben hab zu tun.
Benjamin F. schrieb: > Carsten Sch. schrieb: >> moderne µC haben >> alle Baudratengeneratoren > > Und was genau verstehst du unter "Baudratengenerator"? Kuck mal ins > Datenblatt eines at90usb wieviel Abweichung der bei welcher Einstellung > erzeugt. > Ob das dann ausreichend ist kann jeder selbst entscheiden. AT90USB... Mal abgesehen von der Tatsache das man sich den µC nach dem Projekt aussucht und nicht auf Teufel komm raus meint alles mit einem bestimmten µC machen zu müssen ist der AT90USB ein recht gutes beispiel. Ein Blick ins Datenblatt verrät für nutzung eines 16MHz Quarzes vier mal 0% Abweichung, 6x 0,2% oder kleiner Abweichung,einmal 0,6 und einmal 0,8% Abweichung. Lediglich 115,2K mit 2,1% und 230,4K mit 3,5% fallen aus dem Rahmen. Bei 20Mhz Quarzfrequenz beträgt die maximalste Abweichung gar nur 1,4%. Mit Baudratenquarzen habe ich zwar häufiger 0,0%, aber auch hier gehenbei Bestimmten Frequenzen die Fehler bis auf 8% hoch und einige Geschwindigkeiten stehen gar nicht zur Verfügung. Davon abgesehen ist die Diskussion ob beim AT90USB Baudratenquarze in Frage kommen eh rein Theoretisch, denn der USB braucht zwingend 48MHz Systemtakt. Die kann der AVR aber nur aus gradzahligen Quarzfrequenzen ableiten. Somit fallen Baudratenquarze eh raus. Aber genau das habe ich oben schon explizit geschrieben. Und solche Einschränkungen sind nicht nur bei USB vorhanden... Es gibt noch eine reihe anderer Busse die Integriert sein können, z.B. CAN und alle haben anforderungen an die Taktquelle. Mit gradzahligen Takten kommt man immer hin, bei krummen werten gibt es oft probleme! Überhaupt ist die UART Ausgabe, sofern ein Projekt damit überhaupt arbeitet, heute bei ernsthaften Projekten meist nur ein sehr kleiner Teil der Funktionen. Und Baudratenquarze haben NUR für den UART vorteile, beim ganzen restlichen Ablauf sind die eher störend. Nicht zu vergessen ist hier, das der AT90USB hier absolut nicht das Mittel der Wahl da ja auch noch der CAN Bus gefordert ist. Von USB stand da gar nichts. Aber dies ist ja jetzt nur der AT90USB, ein kleiner 8Bitter. Schaue doch mal in die DS der 32Bitter was die dazu sagen... Beim PIC32MX kann man aus fast jeder glatten Quarzfrequenz fast alle Baudraten mit einer Abweichung von 0,0x% erzeugen, Oft ist sogar eine Abweichung von genau 0% möglich. Würde man nun einen Baudratenquarz einsetzen, würde man nun Baudratenquarze einsetzen, so hätte man für einige wenige Baudraten ganz geringe Vorteile, aber Ethernet, USB und evtl. auch CAN würden nicht mehr ordnungsgemäß laufen. Und ich glaube nicht das es bei anderen 32Bittern anders ist (ARM7 CortexM3) Etwas anderes haben wir jetzt sogar ganz aussen vor gelassen. Durch die Manchestercodierung sind sogar selbst größere Abweichungen überhaupt kein Problem. Deshalb macht man das ja. Die Daten bringen ihren Takt gleich selbst mit. Würde man einen sehr engen Toleranzrahmen anlegen könnte man auf Manchester gut und gerne verzichten! > > Carsten Sch. schrieb: >> Manchester ist nun wirklich keine Hexerei. Das kann man mit jedem µC >> bequem hinbekommen. > > Also zumindest bei der internen Peripherie des efm32g ist mir eine > entsprechende Einstellung nicht aufgefallen. Wenn man dafür nen GPIO > nimmt ist es natürlich wirklich kein Problem. JA... Einen µC der mit OnBoard Peripherie Manchester automatisch erzeugt kenne ich jetzt auch nicht. Würde mich wundern wenn es das überhaupt gibt. Der Grund dafür ist ganz einfach. Manchester wird in der Regel da eingesetzt wo die Datenübertragung nicht mehr Byteweise sondern als Mehrere Byte umfassender Burst abgewickelt wird. OFt dann noch mit speziellen SYNC und FOOTER. NAtürlich könnte man auch dafür die Ablaufsteuerung in HArdware gießen, der Aufwand und insbesondere dann die Aufwendige Konfiguration um das jetzt genau für seine eigenen Ansprüche richtig einzurichten ist aber so groß, das es sich einfach nicht lohnt udn man es gleich per Software regelt. Bei normalen UART wird ja nur immer ein einzelnes Byte übertragen, zwar teilweise sehr schnell hintereinander, aber jedes Byte hat sein eigenes START und STOP, die Zeit zwischen zwei Bytes kann -und darf- variieren. Bei Manchester ist das im allgemeinen gerade nicht gewollt. Währe das mit den Start, STOP und den variablen Zwischenzeiten beim UART nicht, dann könnte man den auch für MAnchesterausgabe verwenden. Dazu braucht man ja nur die Daten vorher entsprechend aufzubereiten. Also die Jeweils invertierten Bits einschieben, was nun wirklich kein Hexenwerk ist. > > edit: >>und bei 30ms die >>hier als vorgabe gelten ist das nun wirklich kein Hexenwerk. > > wie kommst du auf 30ms? ich lese da was von 228µs und 108µs. > > Die 30ms sind ja ein Grenzwert des vorhandenen Steuergerätes und haben > nix mit dem was ich geschrieben hab zu tun. Die 30ms sind die ZEit für die Verzögerung, ja ein Grenzwert. Eine ewigkeit für einen µC. Das es mit deinem Beitrag nichts zu tun hat ist mir schon klar. Da du daber so auf die ZEiten pochst. Die 108µs sind die gesamtdauer der Ausgabe für 13Byte. Dies läuft auf eine Bitzeit von 1,038µs heraus. Entspricht einer Halbbitzeit (Die Zeit die EIN Pegel anliegt) 519.23ns. Als UARTAusgabe währe das ein Equivalent von 1926KBaud (=1,93MegaBAUD). (Da es Manchestercodierung ist sind es "nur" Datenraten von 963 KBaud. Das erscheint mir recht hoch, ist die Zeitangabe wirklich korrekt? Andererseits ist bei den Crashsensoren Zeit ja entscheidender Faktor. Die Sicherheitsmechanismen müssen rechtzeitig ausgelöst werden damit die überhaut noch rechtzeitig "einsatzklar sind. Von der Zündung eines Airbags bis der Aufgeblasen ist vergeht ja beispielsweise schon etwas zeit. Auch müssen die Infos raus sein bevor die Sensoren bzw. die Verkabelung ggf. durch den Aufprall oder Verformung der KArosserie zerstört wird. Aber worauf ich hinaus wollte: Mit welchem Baudratenquarz meinst du könntest du diese Rate mit geringeren Fehler ausgeben als bei einer glatten Quarzfrequenz ausgeben. Das entspricht bei einer Taktfrequenz von 48Mhz gerade einmal knapp 25Takte. Das ist machbar, aber Sportlich. Daher würde ich hier schon etwas mehr Leistung spendieren. Der erwähnte PIC32 z.B. läuft mit 80Mhz, das sind immerhin schon 42Takte. (es geht aber in dieser Klasse bei den ARM noch höher, um die 100Mhz sind drin) oder man geht in die vollen mit ARM9 und 400Mhz, das ist aber definitiv unnötig Mit einem PIC32 lässt sich das aber schon ganz gut realisieren. Dazu muss man das Programm zweiteilen. Während der Ausgabe läuft wirklich nur die Ausgabe. Evtl. kann man das Biteinschieben noch mit reinbekommen, kommt auf die Realisierung an. Also wirklich nur BIT Laden, Auf Timer warten, Pegel setzen, nächstes Bit holen usw. In der REstlichen Zeit läuft dann der gesamte andere Kram. CanBuffer abfragen, Datenaufbereitung usw. Wie gesagt alles kein Hexenwerk. (Nur mit einem AT90USB wird das definitiv nichts ;-) ) Gruß Carsten
Carsten Sch. schrieb: > Die 108µs sind die gesamtdauer der > Ausgabe für 13Byte. Dies läuft auf eine Bitzeit von 1,038µs heraus. > Entspricht einer Halbbitzeit (Die Zeit die EIN Pegel anliegt) 519.23ns. > Als UARTAusgabe währe das ein Equivalent von 1926KBaud (=1,93MegaBAUD). Ich habe oben 13 Bit (nicht Byte) gelesen was aber zu den 11 erwähnten Bits (2 Start 8 Daten + 1 Parity) nicht paßt. Ich würde sowieso die Hardware die Ausgabe machen lassen. Man braucht lediglich eine SPI-Schnittstelle mit doppelter Pufferung des Senderegisters. Dann reicht z.B. ein PIC24FV32KA302 (8 bytes FIFO). Die Daten werden vor dem füttern des SPI-Registers Nibble-Weise über eine Tabelle ins RAM abgelegt. Bei niedrigen Bitraten dürfte auch ohne doppelte Pufferung über Interrupt ein nachladen des SPI-Registers möglich sein. Gruß Anja
Ok. Du möchtest also mit einem Mikrocontroller einen Drucksensor (welcher Manchestercode ausgibt) und einen Beschleunigungssensor simulieren. Heißt, dass dein Mikrocontroller Manchestercode liefern muss. Wie schickt der Beschleunigungssensor seine Daten? Analog (-> A/D-Wandler)? Beide "Sensoren" (welche eig. ein Mikrocontroller sind) schließt du an ein Steuergerät an. Das ist quasi ein selbstentwickelter HiL-Aufbau.
Hallo nochmal. jetzt kommt die Diskussion ja ganz schön ins rollen. Also es soll so wie EagleEye schon gesagt stattfinden. EagleEye schrieb: > Beide "Sensoren" (welche eig. ein Mikrocontroller sind) schließt du an > > ein Steuergerät an. So solls laufen. Laut Datenblatt des Drucksensors (Darf ich hier leider nicht einstellen, sonnst hätte ichs längst getan) ist ein A/D-Wandler verbaut, der den Druck in Digitale Daten umwandelt. Anja schrieb: > Ich habe oben 13 Bit (nicht Byte) gelesen was aber zu den 11 erwähnten > > Bits (2 Start 8 Daten + 1 Parity) nicht paßt. Da hast du recht. hab ich glatt falsch kalkuliert. Es soll natürlich so sein, dass es 1 Paritätsbit ist, ein Startbit, ein Stopbit und natürlich ZEHN! datenbits. Die Betonung ist natürlich auf BIT und nicht byte gelegen^^ Die 30ms Versatz zwischen den Signalen mal nicht als fixen Wert betrachten, hier muss im nachhinnein sowieso im Quelltext das ganze noch auf optimale Werte gesetzt werden.
Ich lese hier: Can-Bus, Airbag-Steuergrät, Mikrocontroller, Sensoren, das alles verbinden, usw. Entweder du kannst einen Mikrocontroller mit CAN-Bus so programmieren, daß der einem Airbag-Steuergerät vorgauckelt, in einem Auto zu sein, dann ist deine oben fabulierte Aufgabestellung dagegen Kinderkram, die du an einem Nachmittag runterprogrammierst. Oder aber die o.a. Aufgabe überfodert dich total, dann aber vergiß den Rest und damit das ganze Projekt... Oliver
Oliver schrieb: > Ich lese hier: > > Can-Bus, Airbag-Steuergrät, Mikrocontroller, Sensoren, das alles > verbinden, usw. > > Entweder du kannst einen Mikrocontroller mit CAN-Bus so programmieren, > daß der einem Airbag-Steuergerät vorgauckelt, in einem Auto zu sein, > dann ist deine oben fabulierte Aufgabestellung dagegen Kinderkram, die > du an einem Nachmittag runterprogrammierst. > > Oder aber die o.a. Aufgabe überfodert dich total, dann aber vergiß den > Rest und damit das ganze Projekt... > > Oliver Danke für deinen äußerst hilfreichen Kommentar oliver. You made my Day. daumenhoch
Hab mir jetzt nen Transceiver rausgesucht, mit dem ich das Signal geordnet auf den Bus bringen möchte. Er nennt sich PCA82C250 und müsste für meine Zwecke als Sicherheit dienen oder? als nicht das das Steuergerät hier nen "Babbling Idiot" vermutet. Ich würde die CAN-H/L AUS/Eingänge auf den Diagnosestecker führen (wo sowieso alle Nachrichten mitgelauscht werden können) und das eigentliche Steuergerät im Auto durch ein modifiziertes ersetzen plus eine entsprechende BreakOut-Box wo die Zündausgänge durch Ersatzwiederstände simuliert werden. Also am Ende nicht ein einziger Luftsack die Kurve kratzt ;) Was mir (das Programieren mal beiseite) noch fehlt ist das perfekte hardwarebundle zu erstellen, mit dem ich der Aufgabe herr werden kann. Würde mich freuen wenn sich da jemand, der nicht mit dem Hirn irgendwo festgefroren ist (is ja auch Arschkalt heute) mir dazu bitte helfen könnte. ich danke vielmals.
Quizzer11 schrieb: > Danke für deinen äußerst hilfreichen Kommentar oliver. Your' welcome ;) Was wird das? Praktikumsarbeit, Sudienarbeit, Hausaufgabe? Aus Spaß an der Freud alleine nimmt sich doch niemand solch einer Aufgabestellung an. Und jetzt ganz ernsthaft: Wem es dir nicht gelingt, eine Aufgabenstellung so verständlich zu formulieren, daß andere diese auch verstehen können, dann kannst du sie auch nicht lösen. Denn dann verstehst du sie selber nicht. Zu einer verständlichen Darstellung braucht es kein Fachchinesisch, es reichen kurze, einfache Sätze. Wichtig ist die Strukturierung des Problems. Probiers mal. Dann klappt das auch mit der Hilfe hier im Forum. Bei Anfragen der Art: "Ich hab keine Ahnnung, wer mach mir meine Hausaufgaben?" gibt es halt nur Schwachfug als Antwort. Kling blöd, ist aber so. Oliver
Oliver ich versteh deinen Einwand. ich habe meine Aufgabe so gut es geht schon formuliert. es geht darum in einem Fahrzeug die korekte Verdrahtung zu testen. Im gleichen Atemzug soll das bestehende System darauf geprüft werden, ob es im Ernstfall ordnungsgemß die entsprechenden Airbags (je nach Lage des Einschlagortes) auch zünden würde. Also quasi eine Zerstörungsfreie Prüfung. Ich beschäftige mich während meines Praktikums mit der Sache. Hier steht keine Hausaufgabe oder eine benotbare Arbeit hinter dem Ganzen, sondern persönliches Interesse, welches ich bei Abschluss des Praktikums der entsprechenden Abteilung vortragen möchte um ggf daraus eine spätere Studienarbeit machen zu können. Mit der Widmung dieser Aufgabenstellung (diese wurde von kollegen mal so nebenbei erwähnt aber nie zu Ende gebracht) möchte ich quasi im Vorfeld so viele Meinungen und Informationen sammeln um den Herren denen ich das vortrage keinen Mist aufzutischen.
Immer schön auf deine Quellen verweisen sonst bekommst du ganz schnell den Spitznamen "Gutenberg" ;) scnr ^^
den hab ich doch schon^^. nein das versteht sich von selbst.ich mach schon so werbung für das forum unter studis und kollegen. is auch nur nen kleines ing.büro und kein bundestag;)
Ok, noch eine Frage zum Drucksensor, dessen Ausgabe über einen intern verbauten AD-Wandler geschieht: Wie ist die bitrate des AD-Wandlers, in welchem Zeitzyklus werden diese Daten geschickt? Werden die AD-gewandelten Daten mit irgendeinem Protokoll rausgeschickt? Ansonsten ganz allgemein: Hast du mit dem Projekt schon angefangen, oder suchst du jemanden, der dir das Ganze entwickelt?! Gruß
Noch ein was: Denke daran, dass du ggf. eine PC-basierende Bedienoberfläche zum Protokollieren und Verändern von Parametern brauchst, um das Ganze auch etwas komfortabler zu machen. Da denke ich beispielsweise an ein kleines Programm, welches über den COM-Port mit deinem Mikrocontroller (UART) kommuniziert und Werte interner Variablen deines Controllers entsprechend beschreibt. So könntest du beispielsweise deinen Controller mit einem Graphen (z.B. für deinen Drucksensor: Druckanstieg in Abhängigkeit von der Zeit) komfortabel "füttern" und entsprechend deinen Wünschen variabel deinen Sensor simulieren. Gruß
Hi, was du da machen moechtest mache ich beruflich auch (Stichwort: HIL, wie oben schon genannt). Wir machen das so: * Digitale Signale (SPI, PSI, SENT, ...) machen wir komplett in einem FPGA. Die Werte die wir rausschicken kriegen wir vom HIL, Manipulationen (z.B. addiere xxx auf einen Wert, invalidiere Parity/CRC) werden komplett im FPGA gemacht, da nur dort 'Echtzeitbedingungen' herrschen * Analoge Werte werden auch im FPGA erzeugt und ueber einen DAC ausgegeben. Auch da kann der HIL vorgeben, was denn eigentlich gemacht werden soll. Umsetzung eben auch im FPGA Vorteil: Wir haben fuer die HIL-Anbindung auch einen uC, der dient aber nur als 'Datenschleuder' zwischen HIL und FPGA, muss also selbst nix rechnen. Und das FPGA kann alles in wirklich 'Echtzeit' erledigen (ein paar hundert Kilobit externe Datenrate vs. 100MHz FPGA Takt). Der HIL muss nur schnell genug sein, um z.B. einen Beschleunigungswert in akzeptabler Zeit ins FPGA zu kriegen. Wir reden da ueber Millisekunden, also reichlich Zeit... Je nach Komplexitaet werden die FPGAs halt immer groesser...
Benjamin F. schrieb: > Immer schön auf deine Quellen verweisen sonst bekommst du ganz schnell > den Spitznamen "Gutenberg" ;) > > scnr ^^ Ich bin stolz auf meinen Foren-Namen. Der andere schreibt sich mit doppel-T. Also bitte richtig schreiben ;)
Quizzer11 schrieb: > Oliver ich versteh deinen Einwand. > > ich habe meine Aufgabe so gut es geht schon formuliert. es geht darum in > einem Fahrzeug die korekte Verdrahtung zu testen. Im gleichen Atemzug > soll das bestehende System darauf geprüft werden, ob es im Ernstfall > ordnungsgemß die entsprechenden Airbags (je nach Lage des > Einschlagortes) auch zünden würde. Also quasi eine Zerstörungsfreie > Prüfung. > > Ich beschäftige mich während meines Praktikums mit der Sache. Hier steht > keine Hausaufgabe oder eine benotbare Arbeit hinter dem Ganzen, sondern > persönliches Interesse, welches ich bei Abschluss des Praktikums der > entsprechenden Abteilung vortragen möchte um ggf daraus eine spätere > Studienarbeit machen zu können. > > Mit der Widmung dieser Aufgabenstellung (diese wurde von kollegen mal so > nebenbei erwähnt aber nie zu Ende gebracht) möchte ich quasi im Vorfeld > so viele Meinungen und Informationen sammeln um den Herren denen ich das > vortrage keinen Mist aufzutischen. Mit dieser Simulation testest du jedoch nur die Endstufe. Ob die echten Sensoren funktionieren wie erwartet, prüft man damit nicht. Die "Schraubermethode" mit bremsen und gegen den Beschleunigungssensor klopfen erscheint mir da einfacher und sicherer. Da brauchte nur ein Adapterstecker der die Airbags abkoppelt und einer Auslöseüberwachung auf dem CAN-Bus. Die Airbags müssen nicht angeschlossen sein. Die Endstufe steuert betreffende Airbags immer an. Gunnar
Gunnar schrieb: > Mit dieser Simulation testest du jedoch nur die Endstufe. Ob die echten > Sensoren funktionieren wie erwartet, prüft man damit nicht. Er will die Reaktion des Systems testen. Daran ist nichts auzusetzen. Die Funktionalität der Sensoren wird er (oder jemand anders) anderweitig prüfen. Die Schraubenziehermethode hat einen erheblichen Nachteil: sie ist nicht definiert zu reproduzieren. Das ist bei derartigen Messungen aber das A und O. Max
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.