Hallo, wie mein Name schon sagt, bin ich in Sachen Microelektronik ein Anfänger und würde mich bei der Programmierung als Amateur bezeichnen. Ich habe verschiedene Tutorials über die ASM-Programmierung der AVR's gelesen und wohl auch größten Teils verstanden. Meine ersten ASM-Codes habe ich vor vielen Jahren auf dem C64 geschriebe :-) Sicher eine andere Welt, aber im Wesentlichen doch sehr ähnlich. Nun zu meinem Projekt: Ich besitze ein Motorrad und möchte die Umgebungsbedingungen loggen. Im Steuergerät befindet sich noch ein alter 27c256 Eprom dessen Inhalt mir bekannt ist. Um das Steuergerät so zu belassen, wie es ist, habe ich vor den Adress- bus vom Eprom abzuhören. Das Resultat daraus ist, daß wenn bestimmte Adressen abgefragt werden, mir der Zustand des Motorrads bekannt ist. Laut Datenblatt des Prozessors liegt eine gültige Adresse immer mindestens 350ns am Adressbus an. Haltet ihr es für möglich, den Adressbus (16bit) in einem Timer-Interrupt über Eingangspins abzufragen und bei gültigen Bereichen, im Wesentlichen 512Byte, auszuwerten. Der gültige Adressbreich wird höchstens mit 200kHz angesprochen, wobei der Adressbus mit etwas mehr als 3MHz betrieben wird. Das bedeutet für einen AVR mit 20 MHz, er muss bei dieser Frequenz feststellen können,ob eie gültige Adresse anliegt und das innerhalb von höchstens 6 Taktzyklen. Ich vermute, daß ist etwas zu viel... Gruß, Anfänger
Du kannst mit Logik-ICs nach der bestimmten adresse filtern. Ein NOT an alle die null sein sollen, und dann alles an ein grosses AND (oder hald mehrere ANDs die zusammenlaufen). dann kommt 1 bit raus, was nur 1 ist, wenn die gewuenschte adresse anliegt, da kannst du einfach einen Interrupt drauflegen.
Wenn du gleichzeitig mit der Adresserkennungslogik noch die Daten in ein Latch übernimmst, hätte der µC alle Zeit der Welt (bis zum nächsten Zugriff auf die Adresse) um die Daten abzuholen. Dafür kommt es natürlich drauf an, wie oft zugegriffen wird.
Im Prinzip geht das - allerdings kann der AVR keine 16bit in einem Rutsch einlesen. Ob es reicht, hängt vom timing des Busses an deinem Zielsystem ab - die 200kHz sagen erst gar nichts aus. Triggere den Kram auf /CE bzw. /OE vom Eprom, dann brauchst du dich auch nicht mit den Zeiten herumschlagen.
H.joachim Seifert schrieb: > Triggere den Kram auf /CE bzw. /OE vom Eprom, dann brauchst du dich auch > nicht mit den Zeiten herumschlagen. Dann sollte man aber mal prüfen, ob diese auch nicht einfach dauerhaft auf 0 sind.
gaast schrieb: > H.joachim Seifert schrieb: >> Triggere den Kram auf /CE bzw. /OE vom Eprom, dann brauchst du dich auch >> nicht mit den Zeiten herumschlagen. > > Dann sollte man aber mal prüfen, ob diese auch nicht einfach dauerhaft > auf 0 sind. Einer von beiden vielleicht, beide aber garantiert nicht. Sonst wäre der Bus platt.
>allerdings kann der AVR keine 16bit in einem Rutsch einlesen Der Adressbus ist 16bit breit, vom Datenbus den er dann einlesen will, hat er noch nichts geschrieben. Ich vermute aber mal 8Bit, das würde in einem Rutsch gehen. >27c256 8 Bit Datenbus. > Laut Datenblatt des Prozessors liegt eine gültige Adresse immer > mindestens 350ns am Adressbus an. Mich würde es interessieren, was für ein Prozessor da drin steckt und was für ein Motorrad das ist :)
Blutiger Anfänger schrieb: > Haltet ihr es für möglich, den Adressbus (16bit) in einem > Timer-Interrupt > über Eingangspins abzufragen und bei gültigen Bereichen, im Wesentlichen > 512Byte, auszuwerten. :-)
H.joachim Seifert schrieb: >> Haltet ihr es für möglich, den Adressbus (16bit) in einem >> Timer-Interrupt >> über Eingangspins abzufragen und bei gültigen Bereichen, im Wesentlichen >> 512Byte, auszuwerten. > > :-) Hä? Du willst uns damit was sagen? Er muss den Adressbus doch gar nicht direkt abhören, da kommt eine Decoder-Logik und eventuell noch ein Latch dran, sonst packts der AVR ja auch nicht. Und die 512Byte kommen ja auch nicht auf einmal. Das 27256 ist in 8Bit Worten organisiert. Also ein 16 Bit Adressbus, der durch Logik den uC trigger, der dann 8Bit vom Datenbus holt. Achja, zum Thema wieder, so wie ich das gerade geschrieben habe geht. Habe einen Memory-Dumper/Logger für den C64 mit einem mega644p @ 25Mhz so gebaut. Mit 20Mhz kam ich nicht aus, aber das liegt wohl eher an schlechtem C-Code und zuviel Zeug was der Controller machen soll.
Was es bringen soll, weiss ich auch nicht so genau - aber lies das Eingangsposting. Er will explizit den Adressbus abhören und dort bestimmte Adressübereinstimmungen finden.
Hallo, das mit der davor gesetzten Logik habe ich mir auch schon gedacht und es wäre möglich einen sehr großen Bereich direkt im Vorfeld auszuschließen. Im Prinzip das was Noah oben bereits erwähnt hat. Für die 512Byte bleiben dann aber immer noch 10bit übrig. Der Datenbus ist mir bei dieser Anwendung völlig egal, weil ich den Inhalt ja schon kenne. Wird z.B. eine Tabelle abgefragt, so kann ich daraus bereits einige Parameter erkennen. Was diese Logik angeht, so verstehe ich das in der Theorie, aber welche Bausteine dafür geeignet sind, weiss ich nicht. Vermutlich etwas von den 74HCxxx?? Da habe ich mal beim Suchen welche gesehen, die eine Reaktion von nur 6ns haben. Vermutlich läßt sich sowas am besten mit einem FPGA oder CPLD lösen, aber davon habe ich nicht den Hauch einer Ahnung. Vielen Dank für die Antworten, Martin
Zum allgemeinen Verständnis: Über den Adressbus erkenne ich z.Bsp. Zugriffe auf die Einspritztabelle und kann daraus schon einiges erkennen. Die Tabelle ist 512Byte lang. Adresse 0b100001 0001000010 bis 0b100001 1001001011 Die ersten 6bit sind also immer gleich und können bei Abweichung sofort ausgeschlossen werden. Durch die Logik würde der AVR also schon mal in den meisten Fällen mehr Zeit bekommen. Wenn mal ein paar Adressen verloren gehen, wäre das nicht weiter tragisch. Was soll ich vor den AVR dann setzen? Gruß, Martin
HC oder F sind mitunter die schnellsten. Schau was für einer das Busmultiplexing bei dir macht und einen aus dieser Familie nimmst du (z.B. 74HC573 oder 74F374 ...). Wenn du z.B. eine 1 an einen Portpin bekommen willst, wenn 1001 anliegt, dann machst du das so: 1 0 0 1 <- soll anliegen A3 A2 A1 A0 <- Adressleitungen | | |--- & --| | * Am * liegt eine 1 an, wenn A3 und A0 auf 1 sind. für A2 und A1 nimmst du in diesem Fall dann ein NAND oder ein AND und einen Inverter hintendran. Die beiden Ausgänge von AND und NAND koppelst du dann nochmal mit einem AND und nur wenn beide 1 sind, dann kommt am letzten AND eine 1 raus.
Nimm für die Adressdekodierung einfach ein Cpld, dafür sind die Dinger da ;) Kostet nicht viel und die Entwicklungssoftware ist dafür kostenlos.
Hallo, @Nils, vielen Dank! Damit kann ich etwas anfangen. Und wenn man jetzt noch den Bereich "kleiner als" 0b1000010 ausklammern könnte, wäre das ein leichtes für den AVR... @Hans-georg Lehnard: Die Lösung scheiter an mir. Ich kenn mich mit CPLD's überhaupt nicht aus. Aus dem Tutorial hier weiss ich zwar auch, daß die genau das Richtige dafür wären, aber ich beherrsche das halt nicht. Vermutlich wäre es recht simpel, die richtigen Adressen sofort zu filtern und dann in einer LUT die entsprechenden Parameter sogar in Klartext auszugeben. Wie lange müsste man sich mit dem Thema ernsthaft beschäftigen, um sowas zu machen? Gruß, Martin P.S.: Der Prozessor im Steuergerät ist ein 68HC11. Das Eprom ist im "non multiplexed mode" angeschlossen. Das Datenblatt kann ich auch gerne zur Verfügung stellen.
Blutiger Anfänger schrieb: > Hallo, > > @Nils, vielen Dank! Damit kann ich etwas anfangen. Und wenn man jetzt > noch > den Bereich "kleiner als" 0b1000010 ausklammern könnte, wäre das ein > leichtes für den AVR... nicht unbedingt, denn wenn du die genaue Zugriffsadresse innerhalb dieses Adressbereichs zur Auswertung brauchst und einige 100 ... 1000 mal pro Sekunde auf die Tabelle zugegriffen wird nützt es kaum was den Adressbereich extern einzuschränken. Wenn du jetzt noch mehrere Adressbereiche brauchst, wird eine externe Logik zu deren Auswertung viel zu aufwendig. Beschreibe doch mal genauer welche Adressbereiche du überwachen musst und wie du aus der Adresse deine Parameter gewinen willst. Sascha
Hallo Martin, du hast 16Bit Adresse, 9 Bit für dein Eprom (Tabelle) und und den Rest für die Adressierung (CS) des EProms. Jetzt kannst du, wie bereits vorgeschlagen, direkt den nCS vom EProm in Verbindung mit nRD verwenden = einfaches OR oder NOR Gatter auf den Interupt Eingang deines Abhörcontrollers = 1 Interupt für jeden Zugriff. Wenn du noch wissen willst auf welche Adresse und welchen Inhalt zugeriffen wurde, wäre ein CPLD, welches die 9 Bit und die Datenleitungen wärend des Zugriffs speichert notwendig. Diese Daten (8 Bit Daten + 9 Bit Adresse) könnte dann dein Controller bei jedem Zugriff vom CPLD anfordern und auswerten. Rein kombinatorische Logik + Latch ist in VHDL nicht schwer. Und vor allen Dingen viel leichter umzulöten wie TTL-Chips ;) Gruß Hans-Georg
Hallo Sascha, Das Motorrad macht 11500U pro Minute. Also um auf der absolut sicheren Seite zu sein gehe ich von 12000 pro Minute aus. 12000 / 60 Sek. = 200 Zugriffe pro Sekunde auf die Tabelle. Das kann der AVR doch locker erkennen und zum Auswerten ist meiner Meinung nach auch jede Menge Zeit. Obwohl das eigentlich gar nicht notwendig ist, da ich die Tabelle ja bereits kenne. Parallel möchte ich ein fertiges LM1-Modul (Breitband-Lambdasonde mit Steuerung) über einen ADC auslesen und mit der gerade gültigen Adresse speichern, d.h. etwa (2Byte Adresse + 2Byte Lambda) * 200 = 800Byte/Sek. Wenn es jetzt noch möglich wäre den Bereich unterhalb der Adresse auszuwerten... Gruß, Martin
Was du machen möchtest ist mit einem Controller wahrscheinlich nicht mehr zu erreichen und mit TTL-Chips zu schwer fürs Motorrad, da reicht der Motor nicht mehr aus ;) Ein einfacher CPLD wäre das was du brauchst. Bei Pollin gibts/gabs ein einfacher Einsteigerset mit CPLD, RAM, Oszillatoren, Programmer usw alles auf einer Platine. Vielleicht findest du das ja noch auf Ebay oder so. Oder etwas ähnliches. >(2Byte Adresse + 2Byte Lambda) * 200 = 800Byte/Sek. Die Temperatur ändert sich docht nicht 200 mal pro Sekunde so drastisch. Hole die Temperatur 4 mal pro Sekunde und bilde Mittelwerte zwischen den 4 geholten Werten oder schreib die 4 einfach rein. Dann bist du bei 16Byte pro Sekunde. Achja, ich bin ja kein Moralapostel und mein Moped läuft ~50 Sachen zuviel, will dir da nix vorschreiben ;) ABER das ist ein Eingriff in die Fahrzeugelektrik und müsste man theoretisch abnehmen lassen. Nur dass du's weisst, falls noch nicht ;)
Hallo Nils, ja, den Einwand mit dem Eingriff habe ich schon viel früher erwartet :-) Das mit dem Motor lass ich nicht gelten :-) Ich kann aber alle beruhigen, denn das Motorrad wird nur noch auf dem Kringel bewegt und ist auf der Straße eigentlich auch gar nicht mehr fahrbar. ;-) Sicher gibt es viele Geräte aus dem Zubehör, die aber einfach nicht die Mapauflösung meines Motorrades 1:1 wieder geben können und sind deswegen nicht optimal. Also muss ich jetzt VHDL lernen... Gruß, Martin
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.