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.
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.
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
