Genauigkeit Pulsein/Pulseout

[ikarus_177]

Hi,

ich habe vor, ein Bussystem zu entwerfen, das die zu sendenden Daten in Impulse einer bestimmten Länge zerlegt und danach über einen bestimmten Port ausgibt (Pulseout). Der zweite µC soll dieses Signal über einen Eingansport und dem Pulsein - Befehl erkennen und abspeichern. Die Leitungslänge in meinem Fall beträgt ca. 40 cm.

Wie genau sind nun diese beiden Befehle in Bascom, ich meine ob sie ein Signal von Hausnummer 1µS wirklich als 1µS erkennen und nicht als irgend etwas anderes.

Kann man das Ganze dann auch in Assembler gestalten?


Dankende Grüße
ikarus_177

[Dirk]

Hallo ikarus_177,

wenn du es ganz genau brauchst, must du in der mcs.lib Anpassungen machen.

Öffne die Lib im Windows-Editor (nicht in Bascoms Editor) und suche nach PULSE_IN oder PULSE_OUT. Damit findest du die Routinen dazu.

In Pulseout gelten die 1us nur für 4 MHz. Bei anderen Quarzfrequenzen sind das nicht genau 1us. Das kann man aber in der Lib anpassen.

In Pulsein kann man die 10us-Einheiten ebenfalls in der Lib an die Quarzfrequenz anpassen, wenn man es genau braucht.

Gruß Dirk

[Besserwessi]

Natürlich kann man die Programmierung auch in Assembler machen. Die Länge des zu sendenden Pulses sollte Zyklusgenau hinzukriegen sein. Beim Messen des Pulses kann man am ICP Eingang auch eine Zyklusgenaue Messung hinkriegen. Die Pulslänge muß aber eine Mindestlänge von etwa 10-20 Zyklen haben. Die Einschränkung wird bei Bascom eher noch stärker sein.

[ikarus_177]

Also könnte man tatächlich ein Bussystem aufbauen, das die Daten durch die Länge des Impulses sendet?

Gespannte Grüße
ikarus_177

[MeckPommER]

Können könnte man das vielleicht, aber wenn du wirklich komplexere Verschaltungen mehrerer Controller im Sinn hast, würde ich davon abraten.
Einmal hast du einen hohen Aufwand, um die Daten zeitlich zu kodieren und zu dekodieren, wobei ich prinzipiell nur Daten auf einem solchen Bus übertragen würde, bei denen es nicht auf Genauigkeit ankommt. Audiodaten könnte man z.B. problemlos übertragen.

Dadurch, das die Pulse eine bestimmte Mindestlänge haben müssen, wird es aber auch nicht sonderlich schnell. Da gibt es andere Bussysteme, die schneller sind und schon auf den Megas hardwareseitig vorhanden sind.

Hauptnachteil ist aber das Problem der Nachverfolgbarkeit aus meiner Sicht. Wenn du eine Schaltung hast, bei der irgendwann plötzlich was in der Kommunikation der Controller etwas nicht mehr hinhaut, kommst du ohne Oszilloskop dann nur schwer weiter.

Weiteres Problem ist das Timing. Du hast keine konstante Geschwindigkeit auf deinen Datenwegen, da einige Informationen länger brauchen als andere. Das kann manchmal von Nachteil sein.

Frage ist auch, wieviele unterschiedliche Zustände du durch die Länge des Impulses übertragen möchtest. Sind es mehr als 3-4 Bit, kommst du irgendwann auf sehr lange Impulse, die diese Übertragungsart nicht mehr lohnend erscheinen lassen.

Aber interessant und in einigen Spezialfällen vielleicht sinnvoll einsetzbar ist diese Übertragungsart schon :-)

Gruß MeckPommER

[ikarus_177]

Gut, dann werde ich wohl auf die parallele Alternative umsteigen müssen. Ich war dieser Methode bisher etwas abgeneigt, was die benötigte Zahl der I/O's angeht.

Hat vielleicht schon jemand Erfahrung mit dieser Art von Kommunikation? Da brauche ich ja bis auf die Leitungen (no na) keine weiteren Bauteile, oder?

Viele Grüße
ikarus_177

[Besserwessi]

Ein Bus mit verschienden Pulslängen wird z.B. bei den Temperatursensoren und ähnlichem von Dallas eingesetzt. Da geht sogar noch die Spannungsversorgung über die Selben Leitungen. Das extrem ist wohl eine Speicher in Knopfzellenform.

Man muß aber auch nicht gleich von 1 Leitung gleich auf parallel umsteigen. Schon I2C (oder TWI beim AVR) ist deutlich Leistungsfähiger als die Einfache codierung über Pulslängen.

[ikarus_177]

Hi,

jaaaa, sicher wäre I2C eine Alternative. Allerdings ist mir diese Art von Datenbus etwas unsympatisch, was die Programmierung anbelangt ;-)

Außerdem denke ich, dass man mit einem parallelen Kommunikationssystem mehr Freiheiten in der Programmierung und im Protokoll hat, beim I2C ist ja schon alles durch die Routinen in Bascom vorgegeben. Und mal etwas neues auszuprobieren kann sicher nicht schaden.

Ich würde also einen 8 Bit (= 1 Byte) Port für das Senden der Daten verwenden und einen zweiten für das Empfangen derselben. die Ports aller Controller würden dann einfach parallel verbunden werden. Muss ich da noch irgendwelche Bauteile zwischenschalten oder funktioniert es auch ohne?

Viele Grüße
ikarus_177

[MeckPommER]

Das mit den beiden 8-Bit Bussen (schreibt man die Mehrzahl überhaupt so?) mache ich so bei Marvin. Funktioniert auch ganz prima, braucht allerdings auch zwei komplette Ports. Mache dir lieber gleich Gedanken darüber, wie du das Timing machst, also z.B. wie du eine Folge von 3 Null-Bytes übertragen würdest, damit die auch richtig ankommen.
Von der Beschaltung her kannst du den Master-Ausgang direkt auf die Eingänge der Slaves legen. Von den Slaves zurück zum Master muss jeder Slave mit Dioden beschaltet werden, damit ein sendender Slave keinen Kurzschluß zu den anderen Slaves, deren Ausgangspins auf log. 0 liegen erzeugt.
Wenn du größere Controller mit mehr Ports hast, ist zu überlegen, ob du für die Kommunikation auch Extra-Signalleitungen verwendest. Da du alles per Hand machst, stehen dir ja alle Möglichkeiten offen.

Gruß und viel Erfolg
MeckPommER

[ikarus_177]

@MeckPommER: die Anode der Diode muss also dann an den Port angeschlossen werden?

Aber ich versteh' das nicht ganz, wieso dass das einen Kurzen machen soll?

Viele Grüße
ikarus_177

[MeckPommER]

Wenn du alle Ausgänge der Slaves jeweils zusammenschaltest und an einem Portpin liegt eine logische 1 an, bedeutet das, das hier der µC 5V anlegt. An einem Slave, der grade nichts zu sendet hat, ist die Leitung nicht offen, sondern dieser µC legt hier GND an. Somit gibt es einen Kurzschluss zwischen den beiden Pins.

Anode an den Port ist richtig :-) Somit kommen die 5V Signale des sendenden Slaves nicht bis zum Port des ruhenden Slaves ... sondern nur zum Eingangsport des Masters.

Noch ratsam sind Pulldowns auf beiden Ports, die dir Störungen dämpfen.

Gruß MeckPommER

[ikarus_177]

Ok, danke sehr für die Hilfe.

Also für jeden der 8 Sende und für jeden Empfangsports einen eigenen Pullup-Widerstand?


Viele Grüße
ikarus_177

[MeckPommER]

Nö, auf dem Bus (wieviele Controller sollen denn da bei dir eigentlich ran?) an jeden der 8 Sende- und Empfangsleitungen einen PullDOWN-Widerstand.

Gruß MeckPommER

[ikarus_177]

uuups, verlesen ;-)

naja, ich dachte so um die 15 Controller. Eine Beschränkung gibts ja eigentlich nur wegen der begrenzten Anzahl an Adressen, die den Slaves zugeteilt werden, oder?

Grüße
ikarus_177

[MeckPommER]

Bei zunehmender Leitungslänge gibt es auch Schwierigkeiten mit dem Bus.

Was die Adressen angeht, so habe ich die Adressenvergabe nicht an die Controller gebunden, sondern an Funktionseinheiten (nenne ich einfach Geräte) wobei auf einem Controller mehrere Funktionseinheiten sitzen können.

Wenn ich einfachste Aufgaben habe - hier mal ne LED an, dort ein Schalter abfragen, etc. dann wäre es ja sinnlos, für jede Aufgabe einen eigenen Controller zu verwenden.
Softwaremäßig sind diese zwei Funktionen getrennte Blöcke auf einem Controller mit unterschiedlichen Gerätenummern. Das hat auch den Vorteil, das ich auf dem Bus leichter sehen kann wo Fehler auftreten, da ich nicht nur den Controller sondern auch die Funktion sehe, die Mist baut.

Aber das waren nur meine Überlegungen und mögen auch irgendwo ihre Nachteile haben. Oma sagte schon: wer in die Fußstapfen eines anderen tritt, kann diesen niemals überholen ;-)

Was sollen die Controller (und welche) denn jeweils für Aufgaben übernehmen?

Gruß MeckPommER

[Bluesmash]

Wie schnell soll eigentlich die Kommunikation sein? am einfachsten machst du die kommunikation über uart master/slave oder noch besser über I2C... da brauchst du jeweils nur 2 ports am uC und ersparst dir die aufwändige verkabelung.

gruss bluesmash

[MeckPommER]

@Bluesmash: die Verkabelung ist aufwändiger, da hast du recht. In Punkto Geschwindigkeit, Flexibilität und Nachverfolgbarkeit halte ich die parallele Methode allerdings nicht für schlecht.

Gruß MeckPommER

[ikarus_177]

Das Ganze ist für mein Langzeitprojekt gedacht (https://www.roboternetz.de/phpBB2/viewtopic.php?t=41523).

Also ein Master, Sensorcontroller, Spannungsüberwachung, IK, vllt. noch eine SD-Karte, später noch ein Display.

Aber die Überlegung mit den verschiedenen Gerätenummern auf einem Controller ist nicht von schlechten Eltern.


Grüße
ikarus_177

[Bluesmash]

Für Schlecht halte ich sie auch nicht, mir währe einfach die verkabelung und die vielen belegten ports zu aufwändig...
Ich habe mir gerade ne I2C Kommunikation mit mehreren Controlleren gebaut, und bin sehr zufrieden damit. auch wird durch I2C schon viel abgenommen, Adressierung/Auswertung. was ich am besten finde an IC2 ist, dass der Controller nur einen "Interrupt" generiert wenn er adressiert wurde (durch die I2C Hardware im Controller). solange andere Adressen angesprochen werden leidet die performance nicht da er nicht die ganze zeit die daten auswerten muss.

gruss Bluesmash

[MeckPommER]

I2C hat sicherlich viele Vorteile. Ich brauchte auf meinem Bot allerdings einen schnelleren Bus und hatte genug Ports zur Verfügung. Bei anderen Sachen werde ich mich sicherlich auch mal ordentlich in I2C zur Kommunikation zwischen den Controllern "reinknien".

Gruß MeckPommER