Mit Timer2 müsstest du noch besser wegkommen, da Timer2 interruptmäßig noch vor Timer1 (der ja schon vor Timer0 kommt) behandelt wird. Da sind nur noch RESET und die externen Interrupts davor.
Wenn du die externen Interrupts abschaltest, dürften die glaube gar nicht erst berücksichtigt werden und wenn kein Reset ansteht, Word sofort geschaut, ob bei Timer2 was los ist.
ich habe das gerade mal ausprobiert und bekomme die selben schlechten Differenzen wie bei Timer0...
Ich vermute, es liegt an den 8 Bit, die Timer2 zur Verfügung hat. Beim Timer1 kann ich komplett auf Overflow-Interrupts verzichten, da ich 2000 Zählschritte in eine Periode stecken kann. Beim Timer0/2 müssen hier die Overflows gezählt werden und dann nachher die Pulsweite berechnet werden. Ich gehe davon aus, dass die Interrupt-Behandlung einfach zu viel Zeit kostet...
Ich probiere das in Bälde mal mit externem Quarz (dadurch ist dann die doppelte F_CPU möglich), da bis jetzt noch alles über den internen Oszillator läuft. Vielleicht ändert das ja etwas an den Interrupt-Zeiten.
Die Interruptlaufzeiten müssen natürlich mit berücksichtigt werden. Wenn das aber mit dem Timer1 in einem Rutsch geht, würde ich natürlich dabei bleiben. 5us sind aber noch zu viel, damit bekommt man nicht mal ein 8bit-Signal sicher generiert.
in der letzten Zeit hat sich einiges getan. Die Platinen von Sven sehen klasse aus und ich bin gespannt auf die kleinere Version, die kommen wird (dann basierend auf einem Tiny44/84 mit Platinengröße 8 x 8mm)
Für die "große" Version soll bald ein Prototyp entstehen. Dafür benötige ich allerdings noch konkrete Ideen/Vorschläge, welche Funktionen realisiert werden sollen.
Gerade bei der Servo-Steuerung sind Anwendungsbeispiele hilfreich (sowas wie: der Anhänger soll ein Tieflader sein, dessen Rampe/Schwanenhals über einen Kippschalter angesteuert wird: Stellung 1 Servo läuft langsam nach oben; Stellung 0 Servo läuft langsam nach unten)
Hierzu wollte ich euch nochmal fragen, in welchen Fällen die direkte Übertragung von Servosignalen (Pulsgenau) notwendig ist und wann eine "Abschätzung" im Sinne von links/neutral/rechts ausreicht.
das Servosignal kann ich ja auch selbst generieren. Ich kann ohne Probleme sagen, ob der Knüppel ausgelenkt ist (und wenn ja in welche Richtung) und kann daraufhin ein Ausgangssignal erzeugen. Man betreibt den Kipper ja eigentlich auch nur mit nahezu Vollausschlag, also ist eine feine Regelung meist ja nicht nötig oder?
Du musst erstmal festlegen, wieviel Signale übertragen werden sollen. Und dann, in welcher Auflösung, sprich als Schalter (1 Bit), drei (also dann vier) Positionen (2 Bit) oder volles Signal (10 Bit). Theoretisch könnte man das System ja so aufbauen, dass Du den Sender programmieren kannst. Beim Einschalten wird dann ein paar Sekunden lang die Konfiguration an den Empfänger gesendet (mit CRC?) und dann schaltet der Empfänger in den normalen Betriebsmodus und erwartet die Daten entsprechend der Konfiguration.
Das könnte dann so aussehen: 1. Empfänger ein und wartet. 2. Sender ein, schickt die Konfiguration: 4 Kanäle - Schalter, Schalter, drei Positionen, volles Signal. 3. Empfänger konfiguriert sich dementsprechend...
Und jetzt merke ich, dass das eigentlich Käse ist. Denn das müsste ja umgekehrt sein, der Empfänger muss ja wissen, welche Funktionen er hat und die Daten vom Sender anfordern... also brauchst Du eigentlich einen Rückkanal. Den hast Du leider nicht, also musst Du immer alle möglichen Signale voll schicken, damit die Zugmaschine mit verschiedenen Anhängern umgehen kann...
das hast Du richtig erkannt: Da der Sender nicht wissen kann, was gerade dran hängt ist auch die Überlegung bezüglich Schalt- oder Prop-Kanal ziemlich hinfällig. Die Frage ist wohl eher, wie viele Propkanäle auf einem Slave (z.B. Hänger) maximal gebraucht werden. Zusätzlich kann man dann noch ein paar Kanäle für Schalter mit 3 Stellungen übertragen. Und natürlich noch die Informationen zur Beleuchtung, also Rücklicht, Bremslicht, Blinker x 2, Rückfahrscheinwerfer...
@Steffen
Die Idee mit dem langsam laufen Servo gefällt mir sehr gut, aber da sehe ich auch ein ganz großes Problem: Die Konfiguration. Bei mir habe ich dieses Problem bisher so gelöst, dass jedes Fahrzeug ein speziell angepasstes Programm bekommt in dem solche Feinheiten wie LED-Dimmer und (Servo-)Geschwindigkeiten konfiguriert sind. Diese Daten werden dann beim Programmstart in die entsprechenden Variablen geladen. Prinzipiell kann man diese Daten auch aus dem EEPROM laden, aber wie bekommt man die Konfiguration da hin? Hier werden wir noch eine Lösung suchen müssen, denn das Ganze über den Sender einzustellen wäre extrem aufwendig.
Denkbar wäre z.B. ein Microcontroller mit USB/UART Schnittstelle und einer IR-Sendediode. Über ein PC-Programm könnte man dann die Einstellungen für die Slave-Elektronik konfigurieren und dann das Datenpaket über die IR-LED auf den Slave schreiben.
Nun, hier noch meine Wunschliste bezüglich der zu übertragenden Daten: 3 x Prop-Kanal mit 10 Bit................ 30 Bit 1 x Schaltkanal mit 3 Stellungen ....... 2 Bit 8 x LED-Kanal ............................... 8 Bit Macht insgesamt 40 Bits an Daten, oder eben 5 Bytes. Mit den Timings aus Post 1
Zitat von SteffKe im Beitrag #1Hallo Leute, Folgendes Timing liegt zugrunde: Funktion (high-Zeit in us/ low-Zeit in us) Init (400/100) kennzeichnet den Beginn einer Übertragung Reinit (500/100) kennzeichnet den Beginn des nächsten Datenbytes High-Data (200/100) Daten-Bit 1 Low-Data (100/200) Daten-Bit 0 Complete (600/100) kennzeichnet das Ende einer Übertragung
die Sache mit der Konfiguration ist gut. Ich werde mal an einem Vorschlag arbeiten. Das Problem ist, dass es zwei Versionen der Platine gibt: eine Platine mit 8x8mm und eine mit 13x11mm. Da der kleine Controller keine UART-Schnittstelle hat und ich das System auf jeden Fall tauschbar haben möchte, wird die Übertragung und somit die Konfiguration per UART denke ich ausscheiden. Auch wenn das eine sehr leicht zu konfigurierende Möglichkeit gewesen wäre.
Nochmal kurz zum Verständnis: Wenn man davon ausgeht, dass immer das selbe Protokoll geschickt wird (also so wie Michael z.B. schreibt: 3 x 10Bit Servo, 1-2 3-Stufen-Schalter, 6-8 Schalt-Zustände), dann liegt es am Empfänger, was er mit den Daten macht.
Der Empfänger kann dann sagen: Ok, ich verzögere jetzt jede Veränderung im Servosignal X oder ich nutze das Servosignal X für den Regler Y. Ein anderer Empfänger lässt zum Beispiel das Servosignal ganz außer Acht und hört nur auf die Daten der Schaltzustandsbits.
Aber die Konfiguration kann ja auch über mein Protokjoll erfolgen, wenn man einfach die Daten anders setzt: z.B. wenn der Empfänger eine bestimmte Datensequenz empfängt, dann geht er in den Config-Mode usw. Die Einstellungen könnten dann über die Zustandsbytes erfolgen, z.B. über die Schaltkanäle in Verbindung mit den Pro-Kanälen... Ich sehe schon, da wartet noch einiges an Arbeit ;)
wie gesagt, das Problem wird eher sein, verschiedene Anhänger mit einem Sender zu koppeln. Konfigurationen vom Sender an den Empfänger zu schicken ist bestimmt möglich. Aber das muss auf jeden Fall aktiv vom Sender ausgehen. Ohne Rückkanal keine Automatik.
Je nach dem, was übertragen werden kann, kann man sich halt viele Dinge vorstellen. Ein einfacher Anhänger / Auflieger hat dann nur Rücklicht, Bremslicht und Blinker. Ein PKW-Transporter hätte zusätzlich das ausfahren der Ladeschienen und das Heben / Senken der oberen Ebene, also zwei Motoren (müssen ja keine variable Gescwhindigkeit haben, wären dann also nur Schalter mit drei Positionen) Und im "schlimmsten" Fall wäre das doch ein zweiter LKW, der den Anhänger mitschiebt...
Wenn Du nochmal die Daten zusammen fassen könntest, die Du übertragen kannst, wäre das sicherlich hilfreich.
Zitat von SteffKe im Beitrag #114Aber die Konfiguration kann ja auch über mein Protokjoll erfolgen, wenn man einfach die Daten anders setzt: z.B. wenn der Empfänger eine bestimmte Datensequenz empfängt, dann geht er in den Config-Mode usw. Die Einstellungen könnten dann über die Zustandsbytes erfolgen, z.B. über die Schaltkanäle in Verbindung mit den Pro-Kanälen... Ich sehe schon, da wartet noch einiges an Arbeit ;)
Genau das ist mein Plan: Der PC sendet über einen USB-Seriell Wandler an einen Microcontroller mit UART, der dann die Daten in das IR-Protokoll übersetzt und sendet. Im Slave-Controller muss dann ein Function-Mapping implementiert sein, so dass man die PINs je nach Konfiguration entsprechend ansteuern kann. Im Prinzip so etwas wie ESU bei ihren Lokpilot-Decodern implementiert hat. Das Ganze habe ich schon Mal für die Modellbahn programmiert, und eine abgespeckte Version des Programms läuft auf meiner PKW-Elektronik. Am Aufwendigsten ist die Umsetzung des Function-Mappings und die Zuordnung zu den Funktionsausgängen. Hier muss man vorher etwas Zeit in ein Konzept investieren, dann wird der Rest viel einfacher.
Im Prinzip könnte ich das alles jetzt hier erläutern, aber wenn ich mir ansehe wie lange ich schon überlege was ich in dieser Mail schreiben soll... da schaue ich wohl besser am nächsten Sonntag nach Sinsheim. Spielen, fachsimpeln...
Du hattest ja im Messen-Teil erwähnt, dass Du am Sonntag nach Sinsheim willst, oder Steffen?
ein dickes Lob an alle, die diesen Thread am laufen halten und ihr wissen dazu beisteuern. Ich verstehe bei den meisten Dingen hier nur Bahnhof und überlasse das denken/programmieren/... lieber denen, die sich damit auskennen. Bin sehr gespannt, was dabei rauskommt. Macht weiter so!!!
@ Michael, du kommst nach Sinsheim!? Freut mich!!!
da ich der Meinung bin, über das große Thema Konfiguration etc. mal lieber zuerst drüber zu reden, bevor hier der Thread voller unverständlicher Erklärungen zuklebt, möchte ich mal einen anderen Fortschritt "verkünden":
Da die große Platine Platz für einen Quarz bietet und auf der anderen Seite noch ein anderer Controller verwendet wird, habe ich mich heute Abend an die Software gewagt, die sich wesentlich von der des kleineren Controllers unterscheidet.
Die maximale CPU-Frequenz beträgt 20MHz, was finde ich sehr gut und auch absolut ausreichend ist. Deswegen habe ich mich umso mehr erstmal an die RC-Auswertung gemacht und festgestellt: schon mit 16MHz (mehr habe ich (noch) nicht daheim rumfahren) werden nur noch kleine Abweichungen um 1us erkennbar, was durch eine Steigerung um 4 MHz später noch geringer ausfallen wird.
Ja, das war es schon ^^ man muss auch mal kleinere Schritte vorangehen, die großen führen da bei mir zu oft zu Beinbrüchen und blauen Flecken ;)
Oh, das klingt fein. Wie viele Kanäle wertest du denn dabei aus? Das Hauptproblem bleibt ja die Abtastung mehrerer Kanäle. Die Übertragung ist dann ja schon Kikifax.
ich kann jetzt eigentlich alle (!) Kanäle us-genau auswerten. Bis jetzt werte ich allerdings nur 3 Kanäle aus, deren Werte auch genau übertragen werden. Da ich jetzt auch das Protokoll konvertiert habe und es auch gemeinsam mit der Impuls-Auswertung einwandfrei funktioniert, muss ich jetzt die Werte in das Daten-Array schreiben, was schwerer ist, als gedacht, da ich ja 10 Bit-Werte in zwei Bytes unterbringen muss. Aber das bisschen Bit-Manipulation klappt sicherlich auch noch.
Die jetzige Software erlaubt es, ohne große Veränderungen ein oder mehrere Servo-Übertragungen zu deaktivieren, sodass die Kanäle frei bleiben, um zum Beispiel aus einem Knüppel einen 3-Pos-Schalter zu machen. Hier kommt es dann letztenendes auf das jeweilige Modell bzw. dessen Fahrer an, der eigene Wünsche hat.
Zum Bleistift: Statt drei Kanäle pulsgenau zu übertragen soll ein Übertragungskanal still gelegt werden, dafür ein Knüppel als 3-Pos-Schalter ausgewertet werden. Ist dieser in Neutralstellung, wird im LED-/Schalter-Byte 0-0 übertragen, bei Linksausschlag 1-0 und bei Rechtsausschlag 0-1. Im Empfänger kann das dann zum Beispiel für ein Servo-Output verwendet werden, der dann den Regler einer Rampensteuerung versorgt.
Wie gesagt, den Ideen bleiben keine Grenzen gesetzt.
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Mikromodell-Chat
0
Offline
