Hilfe beim reverse engineering: Wer kennt diese 1Wire-Form?

Der chaotische Hauptfaden

Moderatoren: Sven, Heaterman, TDI, Finger

Hilfe beim reverse engineering: Wer kennt diese 1Wire-Form?

Beitragvon Bumbum » Fr 13. Okt 2017, 15:31

Hallo,

ich habe ein etwas seltsames 1-Wire Daten-Protokoll, dass ich so noch nie gesehen habe. Es handelt sich um ein Bus-System mit ca. 8V DC Versorgungsspannung auf die noch ein Daten-Signal moduliert ist. Meine Messungen schauen aber so seltsam aus, dass ich fast an einen Messfehler glaube. Wird vielleicht jemand von euch daraus schlau, oder hat so etwas schon einmal gesehen:

Messungen.jpg


Es scheint sich im Grund um ein 1MHz-Signal zu handeln, das gepulst wird. Ich bin mir aber nicht ganz sicher:

Messungen.jpg


Hier dann ein typischer Block dieses 1MHz-Signals:

Messungen.jpg


Ich habe diesen aber auch schon mit anderen Längen gesehen. In gefühlt 90% der Fälle sieht er aber so aus.

Mein Problem: Ich kann da nicht mal den Ansatz eines Bits erkennen. Wie bereits geschrieben würde ich mich über Tipps freuen um welches Format es sich dabei handelt. Ich bin auch für Tipps dankbar, wie ich das Signal besser messen könnte.

Viele Grüße,
Andreas
Dateianhänge
Messung12.jpg
Messung11.jpg
Bumbum
 
Beiträge: 58
Registriert: Mi 22. Apr 2015, 19:04

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Bastelbruder » Fr 13. Okt 2017, 18:49

Im KFZ gibts inzwischen einen ganzen Haufen Sensoren die mit bloß 2 Drähten, manchmal sogar mehrere parallelgeschaltet, an einem Bus hängen.
5-8-11 V sind normale Pegel, das "Steuergerät" spricht mit Spannung, der Sensor antwortet mit Strom.
Bastelbruder
 
Beiträge: 3842
Registriert: Mi 14. Aug 2013, 18:28
Wohnort: drunt' am Neckar - km142,7

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon shaun » So 15. Okt 2017, 01:02

Das ist nicht nur im KFZ verbreitet. Der M-Bus, mit dem man Zähler ausliest, arbeitet auch so: 36V log. 1, wird vom Master auf 24V für log. 0 abgesenkt.
Der Zähler antwortet, indem er auf seinen Ruhestrom von nominell 1,5mA mindestens 10mA draufmoduliert für eine log. 0.
Allerdingd natürlich viel gemächlicher, 2400 bit/s sind ein üblicher Wert und auch klar erkennbar, weil an RS232 Datenformat angelehnt.
shaun
 
Beiträge: 2186
Registriert: Mo 12. Aug 2013, 20:37

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon shaun » So 15. Okt 2017, 01:03

D.h. neben der Spannung auch mal den Strom aus dem Bus messen. Was für ein hochgeheimes System ist es denn?
Black box reverse engineering muss man ja weder sich selbst noch den Mitratenden antun.
shaun
 
Beiträge: 2186
Registriert: Mo 12. Aug 2013, 20:37

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon xoexlepox » So 15. Okt 2017, 09:26

Wird vielleicht jemand von euch daraus schlau, oder hat so etwas schon einmal gesehen

Nee, sorry, ich kenne nur meinen eigenen "Datentrommelbus", bei dem auf 5V (Versorgung) noch 200mV Daten mit 9k6 liegen :( Aber deine Bilder sind ein sehr anschauliches Beispiel dafür, welch lustige und verschiedene Signalformen ein Digitalscope anzeigen kann, wenn die Ablenkzeiten nicht zum Signal passen ;)
Benutzeravatar
xoexlepox
 
Beiträge: 4089
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Bumbum » So 15. Okt 2017, 10:23

Hallo Leute,

das mit der Strom-Übertragung glaube ich weniger. Denn es ist kein hochgeheimes System. Es handelt sich um das Shimano DI2-Protokoll für die elektronische Schaltung. Man hat Servos an den Umwerfern und betätigt diese mit mit Tastern.

Ich möchte eine automatik mit eigenen Tasten realisieren. Es gibt Leute, die haben dazu die Bedienelemente geschlachtet und brücken die Tasten darin mit Transitoren. Aber die sind erstens richtig teuer und zweitens muss das doch auch einfacher gehen. :D

Da man am Lenker einen "Hub" hat, an den man beliebige Bedienelelemente anschließen kann und die Anschlüsse des Hub stumpf gebrückt sind ist die Idee mit der Stromübertragung vermutlich falsch. Es muss etwas Spannungsgesteuertes sein.

Der Spannungshub um die 8V Versorgungsspannung ist übrigens nur ca. +/-0,5V

Ich weiß auch, dass es ein Display zur Schaltung gibt (das ich nicht habe), auf dem man den Akku-Stand ablesen kann. Es heißt also, dass alle Teilnehmer am Bus senden und lesen können. Und wie bereits geschrieben durch einen weiteren oder größeren Hub einfach erweitert werden kann.

Viele Grüße,
Andreas
Bumbum
 
Beiträge: 58
Registriert: Mi 22. Apr 2015, 19:04

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Bastelbruder » So 15. Okt 2017, 10:38

Ich gehe mal davon aus, daß das Megahertz bloß die Trägerfrequenz ist und man sich die Bursts ansehen muß.
Weil heute jeder Hanswurst Mikrokontrolleure verbauen kann, ist jedes etablierte Protokoll denkbar. Und es ist zu vermuten daß nichts Neues erfunden wurde.
Ein kleiner (nicht die Funktion unterbindender) Widerstand in Reihe zum Bus kann helfen, die Quellen diverser Signale anhand ihrer Amplitude zu unterscheiden.
Bastelbruder
 
Beiträge: 3842
Registriert: Mi 14. Aug 2013, 18:28
Wohnort: drunt' am Neckar - km142,7

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon video6 » So 15. Okt 2017, 10:40

Am Fahrrad elektrische Schaltung ??
Mann kann es auch auf die Spitze treiben.
Meine Meinung.
5 Gang Nabebschaltung ist schon super.
Benutzeravatar
video6
 
Beiträge: 1399
Registriert: Mi 23. Sep 2015, 09:18

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon xoexlepox » So 15. Okt 2017, 12:23

Ich gehe mal davon aus, daß das Megahertz bloß die Trägerfrequenz ist und man sich die Bursts ansehen muß.

Dabei stellt sich noch die Frage, ob in den einzelnen Bursts "Information vorhanden ist", oder ob die Abfolge der Bursts die zu übertragenden Daten kodiert. Das "Geklapper" am Anfang des Bursts im letzten Bild könnte sowohl ein "Einschwingvorgang" als auch eine Art "Phasencodierung" sein. Läßt sich das vorletzte Oszillogramm "aufzoomen", um darin ggf. Phasensprünge zu entdecken? Die Triggerung auf einen "Anfangsburst" könnte ziemlich eklig werden...
Benutzeravatar
xoexlepox
 
Beiträge: 4089
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon sysconsol » So 15. Okt 2017, 12:41

Technical Details of the Di2 CANBUS protocol and signaling - carltonbale.com hat geschrieben:I reversed engineered the signal going to the RD. Since I did not have a special tap connector, I could only look at the actual signals in open loop (RD wire disconnected) on the wire going to the RD using an oscilloscope. First, I found that shift up and down are multiplexed on the same wire. A shift down would generate a positive 100 msec clean 8 volt pulse (varies between 50 msec to 500 msec depending on how long you hold the shifter). On the same wire, a shift up would generate a series of 2 msec pulses that would last the same time of a shift down pulse. Therefore, the RD has enough intelligence to discriminate between the 2 types of pulses. When you hold the button on junction A, a 140 msec pulse is generated. But since my RD wire was disconnected, the RD would not go in adjust mode.
sysconsol
 
Beiträge: 812
Registriert: Fr 8. Jul 2016, 17:22

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Bumbum » Mo 16. Okt 2017, 07:59

Hallo,

@sysconsol: Vielen Dank, ich weiß, dass sich die "Hacker" seit Jahren die Zähne am Protokol ausbeisen und habe schon sehr viel über die Versuche gelesen das Protkol zu knacken. Das Zitat kenne ich schon, so sieht es bei mir aber leider nicht aus. Ich weiß, dass es unterschiedliche Versionen der DI2 gibt, je nach alter. Manche übertragen auch per Funk, dann heißt das Protokoll ANT oder ANT+. Ich habe die neueste Kabelgebundene. Vermutlich wird da richtig kommuniziert, anstatt "hoch" und "runter" mit unterschiedlichen Signallängen zu modulieren.

@xoexlepox: Was genau möchtst du näher sehen? Den Anfang oder das Ende? Dein Hinweis ( welch lustige und verschiedene Signalformen ein Digitalscope anzeigen kann, wenn die Ablenkzeiten nicht zum Signal passen) liegt mir auch im Hinterkopf. Wie bereits eingangs erwähnt vermute ich eventuell einen Messfehler. Ich habe allerdings nicht wirklich eine Ahnung wie ich das teure Oszi bedienen soll. Es steht mir lediglich zur Verfügung. Hat jemand einen Tipp, wie ich vorgehen sollte, um ein plausibles Signal auf dem Oszi zu messen?

Viele Grüße,
Andreas
Bumbum
 
Beiträge: 58
Registriert: Mi 22. Apr 2015, 19:04

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon xoexlepox » Mo 16. Okt 2017, 09:48

Was genau möchtst du näher sehen? Den Anfang oder das Ende?

Den kompletten Burst aus dem vorletzten Bild, aber mit der Zeitauflösung des letzten Bildes. Möglicherweise unterstützt das verwendete Scope einen Modus, der es ermöglicht, ein einmal aufgezeichnetes Signal "stückweise" mit einer gedehnten Darstellung zu betrachten, ohne eine erneute Messung zu starten ("Pan" und "Zoom"?). Mir geht es darum, ob die 1MHz-Schwingung über den gesamten Burst so "sauber" weiterläuft, wie am Anfang zu sehen ist, oder ob es im weiteren Verlauf Phasenänderungen (fehlende Halbwellen, Umpolungen, ...) gibt.
Benutzeravatar
xoexlepox
 
Beiträge: 4089
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Bumbum » Mo 16. Okt 2017, 15:14

Hallo xoexplox,

eine Aufnahme im hohen Zeitbereich (500ns/div) habe ich nicht gefunden. Vielleicht weiß ich aber auch nur nicht, wie man das Oszi bedient. Es handelt sich um ein Tektronix TDS-2024B.

Ich habe die Messung aber im 5µs/div Bereich gemacht und dann rein gezoomt. Da die Einschwingung zu sehen ist, denke ich, dass es ausreichend ist. Es sind sonst keine weiteren "Phasen-Schweinereien" zu sehen:

Messungen2.jpg


Ich habe das Signal "durchgescrollt". Es ist ein langes 1MHz-Signal.

Ich denke der nächste Schritt könnte sein eine Schaltung zu entwickeln, die mir eine digitale 1 liefert, wenn das 1MHz-Signal anliegt und eine 0 wenn nicht. Dann könnte ich mit einem µC die Impuls- und Pausen-Zeiten erfassen und schauen, ob man daraus etwas brauchbares lesen kann.

Leider fällt mir keine Idee ein, wie ich eine solche Erkennungs-Schaltung umsetzen könnte. (Noch dazu, wie Sie heißt). Der µC-Teil würde mir wieder keine Probleme bereiten.

Ist das der richtige Weg? Wer kann mir bei einer solchen Schaltung helfen?

Viele Grüße,
Andreas
Bumbum
 
Beiträge: 58
Registriert: Mi 22. Apr 2015, 19:04

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Bastelbruder » Mo 16. Okt 2017, 16:15

Das Megahertz IST ein Träger, der mittels zweier Resonanzkreise zum Sinus geformt wird. Der Einschwingvorgang der ersten drei Perioden ist so nicht beabsichtigt, das stört aber auch nicht. Die 90° Phasendrehung des "Bandfilters" ist eindeutig zu erkennen.
Der zweite Resonanzkreis könnte bereits einer der Empfänger sein.

Die Bilder mit 500 µs und langsamer sind leider durch Aliasing total verfälscht, da läßt sich nichts sinnvolles rauslesen.

Nochmal: Wenn man in die Busleitung einen Widerstand einfügt, (vielleicht auch 2 Schottkydioden antiparallel und eine Drossel), dann sollte der Bus noch laufen, aber es läßt sich an Hand der unterschiedlichen Amplitude die Quelle der Signale erkennen.

Ich könnte mir auch vorstellen daß jede Sendung mit einer relativ langen Präambel beginnt, um beispielsweise bei drahtloser Übertragung den nur sporadisch horchenden Empfänger zu starten und seine ALC einzustellen. Dann sind vielleicht ganz am Ende des Burst ein paar bits versteckt.
1 MHz geht auf die am Fahrrad üblichen Entfernungen problemlos mit 25mm-Ferritstäbchen zu übertragen. Mit 500 kHz arbeiteten diverse drahtlose Fahrradtachos lange bevor Käpt'n Blauzahn publik wurde...
Bastelbruder
 
Beiträge: 3842
Registriert: Mi 14. Aug 2013, 18:28
Wohnort: drunt' am Neckar - km142,7

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon xoexlepox » Mo 16. Okt 2017, 16:31

Es sind sonst keine weiteren "Phasen-Schweinereien" zu sehen

Ok, dann steckt die Information wohl in dem Abstand und der Länge der 1MHz-Pakete.

Ist das der richtige Weg?

Zumindest ist es der gleiche Weg, den ich auch verfolgen würde (falls hier nicht jemand einen besseren Vorschlag hat). Die notwendige Schaltung wird einem Mittelwellenradio recht ähnlich sein, aber es geht sicher auch etwas einfacher ;) Wie war das mit den Pegeln? Etwa 1Vss Impulspakete auf ca. 8V? Impulslängen von 100µs bis ein paar ms?

Für eine Analyse des Protokolls wäre es (wie Bastelbruder beschrieb) natürlich auch wichtig, welches Teil die Daten sendet, und welches sie empfängt.
Benutzeravatar
xoexlepox
 
Beiträge: 4089
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Bastelbruder » Mo 16. Okt 2017, 16:45

Bei 1 Vss läßt sich das Signal ohne Verstärkung im Empfänger-Schwingkreis auf CMOS-Logikpegel bringen. Lediglich ein "Drahtlos"-Empfänger bräuchte etwas mehr Aufwand.

Und dann ist da noch die Frage, ob die Kommunikation einseitig "Tu das!" stattfindet oder ob die Befehlsausführung auch zurückgemeldet wird. Zumindest kann der Controller doch erkennen wer an seiner Leine hängt. Oder habe ich das mit dem HUB falsch verstanden?

Vielleicht lohnt es sich, das Protokoll des Dallas-Eindraht-Bus zu Gemüte zu führen. "Low" entspricht hier vielleicht dem 1 MHz-Signal
Bastelbruder
 
Beiträge: 3842
Registriert: Mi 14. Aug 2013, 18:28
Wohnort: drunt' am Neckar - km142,7

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Bumbum » Mo 16. Okt 2017, 18:24

Hallo,

ich bin mir sicher, dass der gemessene Datenstrom vom Taster kommt. Wenn ich nichts drücke ist nämlich ruhe auf dem Bus (8V DC). Wenn ich eine Taste drücke (hoch oder runter schalten) kommt das Diagramm.

Ab und zu kommt doch ein anderes gezappel, dass ist dann vermutlich vom Akku oder einer anderen Komponente die aktuelle Status-Meldung.

Das aufmodilierte Signal ist ca. 1Vss.

Mir würde es schon reichen zumindest mal ein Bit zu erkennen.

Viele Grüße,
Andreas
Bumbum
 
Beiträge: 58
Registriert: Mi 22. Apr 2015, 19:04

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon sysconsol » Di 17. Okt 2017, 09:08

Ob da manchmal ein (SDR-)Empfänger mit Wasserfalldiagramm hilfreich ist?

1MHz - das liegt im Bereich "Mittelwelle".
Ein passender Empfänger mit dem Audioausgang an den PC geklemmt und eine Software, die aus dem Audiosignal ein Wasserfalldiagramm zaubert...

Damit erkennt man nicht, wer gerade sendet.
Aber zumindest erhält man ersteinmal ein Bild vom Geschehen.
Manchmal hilft das beim Nachdenken.
sysconsol
 
Beiträge: 812
Registriert: Fr 8. Jul 2016, 17:22

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon xoexlepox » Do 19. Okt 2017, 08:30

Mir würde es schon reichen zumindest mal ein Bit zu erkennen.

Dann versuche es mal mit dieser Schaltung.
Bild
Mit ein paar Logikchips ginge das zwar wahrscheinlich etwas einfacher, dafür sollte diese Schaltung auch mit 3.3V noch laufen. Die Schaltflanken sind nicht so optimal, und einige Bauteilwerte optimierungsbedürftig, aber laut Simulation sollte das Ding ein "TTL-Signal" aus den 1MHz-Impulsen machen.
Benutzeravatar
xoexlepox
 
Beiträge: 4089
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Bumbum » Fr 20. Okt 2017, 17:58

Hallo,

ich wollte mich schon die ganze Zeit noch mal melden, aber die Woche war irgendwie voll... Ich habe nur 1 oder 2 Stunden an diesem Projekt weiter machen können.

Der mit dem Mittelwellenempfänger wurde mehrfach genannt, das sollte ich im Hinterkopf behalten.

Allerdings habe ich mir überlegt, dass ein simpler Komperator, der ein re-triggerbares Monoflop startet genau mein Problem lösen müsste. Mit diesem Signal kann ich dann einfach das Impuls-/Pausen-Verhältnis auf dem Oszi darstellen bzw. mit einem weiteren µC auswerten.

Ich habe etwas gegrübelt, ob das mit einem Atmega168 zu lösen ist, der hier noch rumliegt. Eigentlich ist alles drin, Komperator mit eingebauter Konstantspannung und genügend Timer. Der µC läuft mit bis zu 20MHz und dank RISC-Architektur dachte ich mir, dass fast 20 Befehle ausreichen sollten um sowohl einen 1MHz-Takt per IRQ-PWM zu erzeugen und gleichzeitig über den Komperator noch das Monoflop in Software zu steuern und realisieren.

Bis jetzt bin ich daran aber gescheitert. Das generierte 1MHz-Signal braucht ja noch einen Enable, den ich über INT0 einlesen wollte und damit die PWM-Ein- und Ausschalten wollte. (je 1 Port-Wert ändern)

Und der onboard-analog-Komperator hat seinen Ausgang leider nicht direkt auf einen Pin geführt. Über einen IRQ ist das dann zu langsam. Man kann aber den Ausgang auch mit dem Input Capture des Timer1 verknüpfen. Diese Funktion ist neu für mich, ich habe mich da erst mal im Datenblatt eingelesen. Aber irgendwie braucht alles dann doch zuviel Zeit, bzw. mehr als die 20 Befehle, die ich habe...

Ich vermute, dass ich das noch mal optimiert in Assembler programmieren muss. Der AVRGCC verballert bei den IRQs wahrscheinlich zu viel Zeit mit PUSH & POP, was gar nicht benötigt wird bei einem so einfachen Programm.

Aber vielen Dank @xoexlepox. Diese Schaltung werde ich dann als nächstes probieren, sollte ich auch mit einem Assembler-Programm auf meinem Atmega das Timing nicht hinbekommen.

Viele Grüße,
Andreas
Bumbum
 
Beiträge: 58
Registriert: Mi 22. Apr 2015, 19:04

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon xoexlepox » Fr 20. Okt 2017, 19:27

Der µC läuft mit bis zu 20MHz und dank RISC-Architektur dachte ich mir, dass fast 20 Befehle ausreichen sollten um sowohl einen 1MHz-Takt per IRQ-PWM zu erzeugen und gleichzeitig über den Komperator noch das Monoflop in Software zu steuern und realisieren.

Das könnte m.E. auch in Assembler ziemlich knapp werden ;) Ich müsste im Datenblatt nachlesen, wie das beim Atmel läuft, aber die von mir oft verwendeten PICs brauchen vier Takte, um eine Instruktion auszuführen. Und für den Sprung in eine Interrupt-Funktion würde ich auch mal so zwei/drei Instruktionstakte rechen...
Benutzeravatar
xoexlepox
 
Beiträge: 4089
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Christian Knüll » Fr 20. Okt 2017, 21:35

Hallo,

mit einem AVR wäre ggf. eine "Replay Attacke" möglich wenn das Signal immer dasselbe ist und du es in voller Länge aufgezeichnet bekommst und es in den Flash-Speicher des AVR passt.
Zum aufzeichnen hat der AVR nicht genug "bumms" - zum abspielen reicht es knapp:

Code: Alles auswählen
ldi ZH high(Abspieladresse*2)     
ldi ZL low(Abspieladresse*2)

Abspielschleife:
  LPM r16,Z+                                  ;3 Takte um ein Byte des Datenstroms aus dem Flashspeicher zu holen
  out PortA,r16                               ;1 Takt zum ausgeben auf einem Ausgangspin
  cpi ZH,high(Ende Abspieladresse*2)       ;1 Takt zum prüfen ob Ende des Datenstroms erreicht
                                              ;(ZL kann man sich sparen wenn man das Ende des Datenstroms auf ein Segmentende legt)
brne Abspielschleife                         ;2 Takte für den Schleifensprung


Macht 7 Takte je Zustandsänderung des Ports -> 14 Takte für eine volle Schwingung.
Für 1Mhz bei 20Mhz Controllerfrequenz noch 3 Nops einfügen... dann passt es.

Um Speicher zu sparen könnte man jetzt noch bitweise ausgeben um nicht ganze Bytes zu verschwenden.

Aus

Code: Alles auswählen
out PortA,r16


würde dann sowas wie
Code: Alles auswählen
out PortA,r16
lsr r16
8x nop

out PortA,r16
lsr r16
8x nop

usw...



Christian
Christian Knüll
 
Beiträge: 16
Registriert: So 2. Nov 2014, 19:45

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Bumbum » Sa 21. Okt 2017, 09:48

Hallo,

@xoexlepox: Der AVR ist ein RISC, der braucht für 90% der Befehle nur 1 oder 2 Takte.

@Christian Knüll: Den Controller möchte ich nur für die Signalaufbereitung und -erzeugung verwenden. Er soll einen Pin auf high setzen, wenn 1 MHz erkannt wird (retriggerbares Monoflop) und ein 1MHz-Signal auf einem anderen Pin ausgeben, wenn ich einen Freigabe-Pin setze. Da entweder gesendet oder empfangen wird, muss beides nie gleichzeitig laufen.

Alles andere werde ich dann mit einem weiteren Controller machen, da der ATmega168 bereits zeitlich ausgelastet ist. Diese Lösung gefällt mir persönlich sehr gut,da ich nicht so viel mit analog-Elektronik hantieren muss, die mir nicht so liegt. ;-)

Bei mir bahnt sich seit gestern eine dicke Erkältung an. Mal schauen, wie die Motivation die nächsten Tage ist. Aber die Assembler-Lösung möchte ich auf jeden Fall noch ausprobieren. Ich werde berichten.

Viele Grüße,
Andreas
Bumbum
 
Beiträge: 58
Registriert: Mi 22. Apr 2015, 19:04

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon topmech » Sa 21. Okt 2017, 19:46

Was mir zur Automatik am Fahrrad als Allererstes einfällt:
Tu das nicht, jedes mal, wenn du voll trittst und die Automatik schaltet, belastest du damit deine Kette unnötig.
Kannst ja ne LED 1/2 s lang leuchten lassen, bevor das Teil den nächsten Gang reinwürgt.
Zudem: kannst nicht einfach eine bestehende Schaltung (Shimano Deore aufwärts) mit einem Servo verheiraten?

Gruß
Nico

der mehr Fahrrad schraubt als fährt :)
Benutzeravatar
topmech
 
Beiträge: 895
Registriert: Sa 28. Jun 2014, 18:04
Wohnort: Memmingen

Re: Hilfe beim reverse engineering: Wer kennt diese 1Wire-Fo

Beitragvon Bumbum » Mi 25. Okt 2017, 17:07

Hallo,

ich habe mich wieder etwas mit dem Thema beschäftigt. Ich wollte meine Assembler-Lösung fast aufgeben. Das Ganze ist doch nicht so einfach, wie es aussieht. Beim Programmieren und Testen merkt man dann die ganzen Besonderheiten und Sonderfälle, die berücksichtigt werden müssen und im Endeffekt wird es ein riesiges Programm, dass viel zu viel Zeit beim Ablauf frisst

Ich habe deshalb zwischendurch in einem Moment der Frustration mal die Schaltung von xoexlepox aufgebaut. Dabei ist folgendes hübsches Werk entstanden:

1MHz_Demodulator.jpg


Leider funktioniert diese nicht. Es wird zwar eine 1 ausgegeben, wenn ein Signal anliegt und eine 0, wenn man es wegnimmt. Dabei spielt das Signal aber leider keine Rolle. Die Frequenz ist also völlig egal.

Ich muss sagen, dass ich die Kondensatoren nicht ganz in der passenden Größe da hatte. Anstatt 1nF am Eingang habe ich 10nF bestückt. Das sollte aber keine Rolle spielen. Und anstatt der 470pF habe ich 2x 220pF parallel bestückt.

Wie bereits geschrieben ist Analog-Technik nicht meine Stärke. Ich habe das ganze deshalb nicht weiter verfolgt.

Also bin ich wieder zurück zur µC Assembler-Lösung und habe es heute tatsächlich geschafft eine Art retriggerbares Monoflop für ein 1MHz-Signal mit nur 20MHz Takt zu bauen. Getestet habe ich zunächst mit dem Frequenzgenerator. 1MHz wird erkannt und eine saubere 1 ausgegeben. Drehe ich die Frequenz runter fängt ab ca. 700kHz der Ausgang an zu zappeln und ab ca. 550kHz ist er auf 0.

Das sollte erst mal genügen um zu schauen, ob da Bits aufmoduliert sind. Also ran ans Fahrrad gehängt und siehe da, es schaut tatsächlich aus wie ein Bitmuster, das sich fast zu wiederholen scheint, wenn man eine Taste drückt.

Leider hat es nur ca. 3x funktioniert. Aktuell kann ich mit dem Oszi nicht mal den 1MHz Träger messen, obwohl am Rad noch alles funktioniert. Irgendwo ist wohl etwas abgefallen. :shock:
Mal schauen, wann ich die Muse habe weiter zu machen.

Für alle, die es Interessiert hier mal mein Assembler-Code bisher. Mit Kommentaren immerhin schon über 200 Zeilen. :o

Code: Alles auswählen
/**
==================================================================================================================

Shimano Kommunikations-Interface
erkennt bzw. erzeugt ein 1MHz Signal

Target: ATmega168 @ 20 MHz

onboard-Komperator tastet Eingangssignal (1Vss) ab.
Bei Erkennung einer Flanke wird Input-Capture von Timer 1 getriggert
Anhand dieses Werts kann die Frequenz des Eingangssisgnals gemessen werden.
--> Wenn Wert kleiner als Periodendauer eines 1MHz-Signals, dann Ausgang setzen
Im Input-Capture-Interrupt wird Timer 1 zurückgesetzt für eine neue Zeitmessung.
Output Compare A des Timer 1 wird verwendet, um den Ausgang bei Timeout (Frequest größer als 1MHz) ebenfalls zu löschen

Timer 0 wird benutzt für Erzeugung des 1MHz-Signals



IOs:

PB0      CKOUT
PB1      out         Ausgang Erkennung
PB2      frei
PB3      MOSI
PB4      MISO
PB5      SCK

PC0      frei
PC1      frei
PC2      frei
PC3      frei
PC4      frei
PC5      frei

PD0      frei
PD1      frei
PD2      INT0      Freigabe Takt
PD3      frei
PD4      frei
PD5      out         Ausgang Takt (Output Compare 0 B)
PD6      AIN0      intern verbunden mit Bandgap-Referenz (ca. 1,1V)
PD7      AIN1      Eingangssignal zum Abtasten

==================================================================================================================
**/



.include "m168def.inc"




// Interrupts:

.org 0x000
        rjmp Init                        // Reset

.org ICP1addr                           // Timer 1, input capture
        rjmp ISR_Signal_erkannt

.org OC1Aaddr                           // Timer 1, output compare A
        rjmp ISR_Signal_timeout




// Register:

.def Temp=               r16

.def Signal_on=            r17
.def Signal_off=         r18

.def zero_value=         r19
.def timeout_value=         r20

.def Periodendauer=         r21

.def reset_Timer1_ISR=      r22






.org 0x050

Init:              ldi Temp, High(RamEnd)            // Stack initialisieren
               out SPH, Temp
               ldi Temp, Low(RamEnd)
               out SPL, Temp



               ldi Temp, 0b00000010            // Datenrichtung Port B
               out DDRB, Temp
               ldi Temp, 0b11111101            // Port B initialisieren
               out PORTB, Temp

               ldi Temp, 0b00000000            // Datenrichtung Port C
               out DDRC, Temp
               ldi Temp, 0b11111111            // Port C initialisieren
               out PORTC, Temp

               ldi Temp, 0b00100000            // Datenrichtung Port D
               out DDRD, Temp
               ldi Temp, 0b11011111            // Port D initialisieren
               out PORTD, Temp


                                          // Timer 0 konfigurieren:
               ldi Signal_on, (1<<COM0B0) | (1<<WGM01)   // Toggle des COM 0 B Pin @ OCRA
               ldi Signal_off, (1<<WGM01)         // Mode 2 (CTC) --> Timer zählt bis OCRA und setzt sich dann automatisch zurück
               out TCCR0A, Signal_off
               ldi Temp, (1<<CS00)               // Mode 2 mit prescaler 1 (Timer läuft mit FCPU)
               out   TCCR0B, Temp
               ldi Temp, 7                     // output compare auf 7 clocks (entspricht halber Periode für toggle COM 0 B @ 1MHz)
               out OCR0A, Temp


                                          // analog-Komperatur konfigurieren:
               ldi Temp, (1<<AIN1D) | (1<<AIN0D)   // digitale Eingänge an Pins AIN0 und AIN1 deaktiviern
               sts DIDR1, Temp
               ldi Temp, 0                     // Eingangssignal auf AIN1 mappen
               sts ADCSRB, Temp
               ldi Temp, (1<<ACBG) | (1<<ACIC)      // AIN0 auf Bandgap mappen und Input Capture für Timer 1 aktivieren
               out ACSR, Temp

                                                               
                                          // Timer 1 konfigurieren:
               ldi Temp, 0                     // Mode 0 (normal operation)
               sts TCCR1A, Temp
               ldi Temp, (1<<CS10)               // Mode 0 mit prescaler 1 (läuft mit FCPU)
               sts TCCR1B, Temp
               ldi Temp, 0                     // Output-Compare A festlegen (timeout)
               sts OCR1AH, Temp
               ldi Temp, 30
               sts OCR1AL, Temp
               ldi Temp, (1<<ICIE1) | (1<<OCIE1A)   // Input Capture- und Output Compare A-Interrupt aktivieren
               sts TIMSK1, Temp

                                          // vorbereitete Werte für später:
               ldi reset_Timer1_ISR, (1<<ICF1) | (1<<OCF1A)
               ldi zero_value, 0
               ldi timeout_value, 0xFF
               sts ICR1H, timeout_value
   


               sei                           // Interrupts freigeben
               


MainLoop:         

wait_for_Start:      sbis PIND, PD2                  // überspringe nächste, wenn keine Freigabe
               rjmp Start                     // Freigabe erkannt --> Start des 1MHz-Signals

               lds Periodendauer, ICR1L         // ansonsten Periodendauer einlesen:
               lds Temp, ICR1H
               tst Temp
               brne no_Signal                  // Signal abschalten, wenn High-Byte größer 0
               cpi Periodendauer, 15            // Low-Byte mit Timeout verlgeichen
                                          // carry wird bei Vergleich gesetzt, wenn Periodendauer kürzer
               brcc no_Signal                  // Signal abschalten, wenn kein carry-Flag
               sbi PORTB, PB1                  // Erkennung Signal an
               rjmp wait_for_Start

no_Signal:         cbi PORTB, PB1                  // Erkennung Signal abschalten
               rjmp wait_for_Start



Start:                                       // 1MHz Signalausgabe starten:
               cli                           // Interrupts während Ausgabe deaktivieren (nicht benötigt, entweder senden oder empfangen)
               cbi PORTB, PB1                  // Erkennung Signal löschen, falls noch aktiv

               out TCNT0, zero_value            // Timer 0 zurücksetzen
               out TCCR0A, Signal_on            // Takt-Ausgabe starten

wait_for_Stop:      sbis PIND, PD2                  // warten, solange Freigabe anliegt:
               rjmp wait_for_Stop

Stop:            out TCCR0A, Signal_off            // Takt-Ausgabe stoppen

               sts TCNT1H, zero_value            // Timer 1 zurücksetzen
               sts TCNT1L, zero_value

               sts ICR1L, timeout_value         // Input Capture-Wert auf großen Wert setzen

               out TIFR1, reset_Timer1_ISR         // eventuell anstehende Interrupts löschen
               sei                           // Interrupts wieder aktivieren
               
               rjmp wait_for_Start




ISR_Signal_erkannt:   sts TCNT1H, zero_value            // Timer 1 zurücksetzen, (timeout reset)
               sts TCNT1L, zero_value
               reti

ISR_Signal_timeout:   cbi PORTB, PB1                  // Erkennung löschen, falls noch aktiv
               sts ICR1L, timeout_value         // Input Capture-Wert auf großen Wert setzen
               reti


Viele Grüße,
Andreas
Bumbum
 
Beiträge: 58
Registriert: Mi 22. Apr 2015, 19:04

Nächste

Zurück zu Allgemeine Diskussion

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot], Chemnitzsurfer, duese, Exabot [Bot], inse, Markus, Wurstblinker und 23 Gäste

span