Druckbare Version
Drehgeber an der C-Control I
Hat jemand schon mal einen Drehgeber an der C-Control 1 eingesetzt um Wegstrecke zu messen bzw. um die unterschiedlichen Geschwindigkeit der Räder auszugleichen?
Wenn ja welchen Port habt ihr genutzt?
War die C-Control schnell genug dafür?
Gruß Frank
Hallo Frank,
du könntest die zwei frequenz-ports benutzen. Bei der normalen Unit müsste man mit nem dünnem Drath den 2. abgreifen und ne masseleitung durchtrennen. Bei der M-Unit sind beide rausgeführt. Wenn du das beim Robbi anwenden willst, 22 und23 sid die frequenz-ports des MC68HC05B6. dar ich mich net mit dem robbi auskennne müstestu nachmessen, ob die auf Masse gelegt sind.
Matthias
Hi Matthias
Shit das nur der eine rausgeführt wird! Wollte eigentlich ne steckbare Lösung! Mich würde dennoch interessieren ob es schon mal jemand mit normalen Ports geschafft hat!
Gruß Frank
Man kann auch nen Zähler dranhängen, den man dann ab und zu abfragt. Man brauch dann aber mehr ports, ausser man machts seriell. auf jeden fall müsstest du das programm so gestalten, dass bevor der Zähler ans "limit" kommt, die cc ihn abfragt und resetet. Die abgefragte zahl wird dann mit der anderen verglichen und die Motoren entsprechend geregelt. Hoffentlich bringt dir diese Idee was :wink:
Matthias
Hallo Frank,
Bei CCTools gibt's bald eine Lösung
für einen oder Mehrere Zähler am I²C-Bus. (bei der CC1 am internen I²C-Bus)
(siehe Ausblicke bei CCTools, I2C-CNT8)
Es können somit bis zu 16 Zählermodule am I²C-Bus betrieben werden.
Der Zähler hat 8-Bit.
Ein Aufsummieren der Werte auf größere Bereiche sollte bei regelmäßiger
Abfrage im Programm ohne weiteres möglich sein.
Duch einen Interrupt-Ausgang muß das Zählermodul nur bei Änderung
des Zählerstands abgefragt werden.
Natürlich kann mit einem einfachen Zähler nicht die Richtung erfasst werden.
Da man aber wissen sollte, wie rum man die Motoren drehen lässt,
sollte das kein Problem sein. :-)
Wenn Du lieber einen Inkrementalgeber an die CC1 anschließen willst,
um auch die Richtung erfassen zu können:
Das ist nicht, auch nicht mir ASM, möglich.
Jedoch kann des der Controller der CC2 hardwaremäßig.
MfG André H.
Danke für eure Tips! Aber eigentlich wollte ich gerne wissen ob es mit der normalen C-Control geht - ohne extra Hardware und ohne zusätzliches abgreifen von Interrupt oder Frequenzeingang.
Einfach mit einem normalen Port. Müsste also ne Abfrageschleife sein! Aber da ja zwischenzeitlich auch Sensoren und Sensoren über i2C überwacht werden sollen, wird es wohl eng mit der Zeit.
Ist aber schon komisch - jeder weiss das man für das geradeausfahren eigentlich die Geschwindigkeit der Räder ausgleichen muss aber Lösungen hab ich bei vorgestellten Bots noch nicht oft gesehn. Oder täuscht das?
Gib trotzdem mal Info André wenn dein teil fertig ist!
Gruß Frank
Hast Du mal ein Schaltplan zu so einem Zähler?Zitat:
Zitat von Matthias
Wenn der drehgeber sich langsam dreht, kann man nen einfachen 7490 nehmen. Wenn sich das rad schnell dreht, muss man eben mit mehreren Zählern arbeiten. Schaltplan hab ich auch, weiss aber nicht, wie ich ne PDF-Datei hier einbinden kann.
Matthias
PDF kann man seid kurzem einfach als Attachement anhängen. Übrigens auch ASM, BAS, ZIP,JPG, GIF, DOC und einige andere Files!
Gruß Frank
[glow=red:05a4d4247c]Herlichen Glückwunsch zum Geburtstag![/glow:05a4d4247c]
Danke erst einmal.
EWB ist das format von meinem Simulator, dar ich aber nich glaube, dass irgendwer hier elektroniks workbench hat, habe ich die datei einfach mit PDF-Creator umgewandet. Falls ihr es nicht wisst: PDF-Creator ist ein Programm, das dem computer vorgaukelt ein Drucker zu sein. Wenn man dann unter "Drucker einrichten" PDF-Creator angibt und die Datei dann "Druckt", speichert der PC die datei als PDF ab, statt sie auszudrucken.
Matthias
Hast Du da nicht einen Denkfehler bei der Konzeption gemacht? Wozu soll den der Interupt gut sein? Wenn bei jedem neuen Impuls der gezählt wird ein Interrupt ausgelöst wird, dann könnt es der Controller genauso gut selber zählen.Zitat:
Zitat von André H.
Der Sinn des Zähler ist doch die Entlastung des Controller, daher wäre es doch wesentlich besser wenn nur beim Zählerüberlauf ein Interrupt ausgelöst würde. Oder sehe ich das falsch?
Gruß Frank
Hallo Frank,
Hier ist keinerlei Denkfehler.
Ich kenne mich mit dem I²C-Bus bestens aus. (Hardware & Software)
Man muß einfach einmal von der Denkweise, daß ein Interrupt sofort abgearbeitet werden muß, wegkommen.
Ein Interrupt ist im Bereich vom I²C-Bus nur dazu da, eine Änderung zu signalisieren.
Ein Interrupt von I²C-Bus-Bausteinen muß nie an einen Interrupt-Eingang eines Controllers.
Vielmehr muß dieser an einen normalen I/O-Port und dient nur dazu
zu signalisieren, ob sich ein I²C-Bus-Zugriff "lohnt", um unnötiges Polling zu vermeiden.
Das ist vielleich bei der CC1 nicht schlimm, da diese ohnehin langsam ist,
und man hier nicht viel mit dem I²C-Bus macht.
Aber bei der CC2 würde man dies bei komplexeren Anwendungen deutlich merken.
Meine Hardware ist nunmal in erster Linie für die CC2 entwickelt.
Daß die meiste Hardware auch mit der CC1 nutzbar ist, ist ein angenehmer Nebeneffekt. :-)
Und um das als Programmcode zu verdeutlichen:
(Kleine Testfunktion in C2.)
Viele meiner (I²C-)Erweiterungen haben Interruptausgänge.Code:byte lcnt[16];//Zwischenspeichern des letzten Zählerwerts
const AddrR[]=0x41,0x43,0x45,0x47,0x49,0x4B,0x4D,0x4F,
0x71,0x73,0x75,0x77,0x79,0x7B,0x7D,0x7F;
function getCnt(byte addr, byte IntPort) returns byte
{byte x,y;
if not ports.get(IntPort) // wenn Int-Port auf low
{
if i2c.cstart(AddrR[addr])
{
x=i2c.readlast();
i2c.stop();
y=x-lcnt[addr];
lcnt[addr]=x;
return y;
}
i2c.stop();
}
return 0;
}
Ohne diese würde der I²C-Bus schnell "überlastet" und damit langsam.
MfG André H.
Hallo André
Ich dachte der Interrupt gibt nur einen Impuls weiter, war das nicht so beim PCF?
Was nützt einem der Impuls auf einem normalen Port? Um den zu registrieren müsste ja ständig der Port überwacht werden?
Oder setzt PCF die Leitung dauerhaft auf Low? Wenn ja wie wird die zurückgesetzt?
Gruß Frank
Ich glaube bei PCF zeigt der Interrupt nur an, dass sich etwas verändert hat. Die Leitung bleibt dabei dann dauerhaft auf low bis man den Baustein wieder abgefragt hat.
Das heißt man müsste halt nur immer mal wieder schauen ob die Leitung auf Low liegt und in dem Fall den PCF abfragen...
MfG Kjion
Hi
Das könnte sein, dann würde es Sinn machen wie es Andé beschrieben hat. Allerdings würde es meiner Meinung den I2C Port als auch den Controller noch wesentlich mehr entlasten, wenn der Überlauf des Zählers einen echten Interrupt auslöst. Dies würde auch einen nahezu fehlerfreie Zählung sichern - was bei langsamen Controllern ansonsten nicht 100% sicher ist.
Gruß Frank
Hallo Frank,
Kjion hat die Funktion eines Interruptausgangs bereits richtig beschrieben.
Um einmal allgemein die Funktion von Interrupts, egal ob diese von I²C-Bus-ICs,
FIFO-Bausteinen oder was auch immer kommen, zu beschreiben:
Ein Interrupt bleibt immer solange bestehen, bis dieser zurückgesetzt wird.
Bei I²C-Bus-Portexpandern, wie den PCF8574 oder MAX7311, geschiet
das durch ein Ansprechen (Adressieren) des Bausteins.
Bei I²C-Bus-Portexpander geht die Interruptleitung auf low, sobald sich
der Pegel an mind. einem der Ports ändert.
Und, um zum Interrupt bei Überlauf zu kommen:
Was soll das für einen Sinn machen ?
1. Wenn es zu einem Überlauf kommt, ist es bei "normalen" Zählern
meist schon zu spät, und man "verliert" Impulse.
2. Da bei I2C-CNT8 der Zähler beim Abfragen nicht zurückgesetzt wird,
mach es hier noch weniger Sinn.
3. Man benötigt den Zählerwert sicher nicht nur, wenn dieser überläuft. :-)
Man muß bedenken, wenn man einen Zähler zurücksetzen würde,
welcher passiv funzt, wie der I2C-CNT8, läuft man gefahr Impulse zu verlieren, da man zum Zürücksetzen über den I²C-Bus wieder Zeit benötigen würde.
Einen Aktiven Zähler am I²C-Bus wollte ich nicht erstellen. Da hier der
benötigte PIC-Controller um einiges teuere kommen würde.
Das ding müsste schließlich auch programmiert werden, was sich natürlich
auch wieder am Preis bemerkbar macht.
Übrigens ist beim I²C-Bus die Interruptleitung so vorgesehen, daß man
mehrere Bausteine an eine Interruptleitung hängt.
Geht die Leitung auf Low, fragt man alle Bausteine ab solange der Interrupt besteht:
Bsp: 5 PCF8574:
for i=0 ... 4
{
states[i]=pcf.in(i);
if port.get(IntPort) break; //wenn Interrupt beendet, Schleife verlassen.
}
@alle
Und zum I²C-Bus selbst:
Bitte nennt den I²C-Bus bitte auch I²C-Bus.
Es ist ein Bus, kein "I²C-Port" und auch keine "I²C-Schnittstelle".
MfG André H.
Hi André,Zitat:
Zitat von André H.
der Sinn ist ganz einfach. Der Controller wird nur dann informiert wenn es höchste Zeit wird den Zähler mal zu checken, ansonsten wird er enorm entlastet dadurch.
Natürlich müsste der Überlauf auch gleichzeitig den Zähler zurücksetzen - das ist ja kein echtes Hardware Problem ;-)
Da ein echter Interrupt auslöst wird, vergehen bis zur Abfrag nu wirklich keine Zeitspannen, somit dürfte selbst der langsamste Controller keine Schritte verlieren. Und selbst wenn er tatsächlich zu spät abfragen würde, dann würde er ja automatisch die Schritte lesen die bereits vergangen sind seit dem Interrupt, denn der Zähle rhat sich ja zurück gestellt. Da der Controller ja weiss das ein Überlauf entstanden ist, kann er die Konstante addieren.
Natürlich will man nicht nur beim Überlauf Werte haben, es spricht ja auch nichts dagegen das der Controller zwischenzeitlich den Zähler abfragt. Siehst Du den Vorteil ;-)
Bei deiner Konzeption hat der Controller ne Menge Arbeit wenn er bei dem Interrupt auf einem Port (der bei jedem Minibewegung/Impuls) ankommt erst mal alle I2C Bausteine lesen muss.
Gruß Frank
Hallo Frank,
Man kann natürlich in ein Zählermodul noch dies und das an HW reinpacken,
um alle möglichen Eventualitäten zu ermöglichen.
Jedoch ging es mir bei dem Zähler nur um ein einfaches
preiswertes Modul.
Außerdem ist die Hardware (damit meine ich den Stapel Platinen) schon
länger fertig.(ca. 2 Monate) Ich war vor lauter Arbeit nur noch nicht gekommen
die nötigen Treiber (CC2) bzw. Routinen(CC1) zu schreiben.
Es bringt jetzt nichts zu schreiben, dies oder das wäre besser.
Die Interruptleitung beim I2C-CNT8 ist nunmal nicht dazu gedacht,
Interrupts auszulösen, sondern, wie gesagt, um eine Änderung zu signalisieren.
Außerdem dauert der I²C-Bus-Zugriff selbst bei der CC1 nicht länger als
das Lesen von zwei Programmbytes aus dem EEProm.
Und wenn Dein CC1-Proggie z.B. für einen Durchlauf 1sek. braucht, und Du
in dieser 1sek. einmal auf neue Impulse prüfst und ggf. abfragst, so wären
max. 255 Hz drin ohne garantiert auch nur einen Impuls zu verlieren.
Da ich aber schon lange nicht mehr mit der CC1, sondern nurnoch mit
der CC2 arbeite, ist für mich das Thema "Controllerauslastung" nicht
so wichtig.
Wie schonmal gesagt, ist meine komplette I²C-Bus-Hardware in erster
Linie für die CC2 enbtwickelt. (Hauptbreich Wäremtechnik/Hausautomatisation)
Das hab' ich nie so geschrieben.Zitat:
Bei deiner Konzeption hat der Controller ne Menge Arbeit wenn er bei dem Interrupt auf einem Port (der bei jedem Minibewegung/Impuls) ankommt erst mal alle I2C Bausteine lesen muss.
Das Beispiel, was ich gebracht habe, fragt nur solange ab, bis der
Interruptauslösende Baustein abgefragt wurde. Danach wird
die Schleife verlassen.
Gut, im schlimmsten Fall werden alle Bausteine abgefragt, aber das
ließe sich nur mit mehreren Ports für die Interruptleitungen vermeiden.
Aber ich glaub', ich weiß, wo das Problem liegt:
Viele CC1 Nutzer Emulieren völlig unnötig einen I²C-Bus an zwei
I/Os mit Basic-Routinen.
Ich halte das für völligen Unsinn und nutze bei den CC1-Routinen
für meine I²C-Bus-Erweiterungen immer den internen I²C-Bus
mit ASM-Treibern. Hier spielen I²C-Buszugriffe bei der CC1 dann
zeittechnisch eher eine untergeordnete Rolle.
Wenn bei der CC1 schon ein I²C-Bus an zwei I/Os emuliert wird, dann
bitte wenigstens mit ASM-Routinen. Alles andere wäre schwachsinn.
Ein (ASM-)Beispiel hierfür befindet sich z.B. im Buch "MSR mit CC-Basic"
MfG André H.
Hi André,
schön das Du doch indirekt zu gibst das meine Idee nicht ganz schlecht ist ;-)
Ich verstehe nicht was Du mit Aufwand meinst. Auch bei meiner Lösung bräuchte man nix weiter, vielleicht ein Gatter oder so!
Die einzigen Änderungen wären ja:
- der Überlauf müsste nur Zähler zurücksetzen (glaube da reicht ne Drahtbrücke)
- der Interrupt müsste auf echten Interrupt Eingang geführt werden (da dieser glaub eh nur auf Flanken reagiert braucht man garnichts ändern)
Wäre also wirklich nur "eine winzige Änderung für den Menschen aber ein großer Schritt für den Controller". ;-)
Aber ok, wenn Platinen nun mal fertig sind, kann man nix machen. Notfalls kann man das sogar noch mit manuell mit einer Brücke ändern - falls es jemand möchte.
Meine Methode entlastet ja auch den I2C-Port, von daher hat das auch schon Vorteil für schnelle Controller.
Hallo Frank,
>Die einzigen Änderungen wären ja:
> - der Überlauf müsste nur Zähler zurücksetzen (glaube da reicht ne Drahtbrücke)
Warum willst Du den Zähler bei einem Überlauf zurücksetzen, wenn
dieser sowieso wieder bei 0 anfängt ??
Wenn, dann müsstest Du den Interrupt mit einem I/O-Port zurücksetzen !
> - der Interrupt müsste auf echten Interrupt Eingang geführt werden (da dieser glaub eh nur auf Flanken reagiert braucht man garnichts ändern)
Müsste man schon, da der Interrupt vom PCF8574 kommt, und dieser
bei jeder Änderung der Eingänge ausgelöst wird.
Jedoch garantiere ich Dir, daß Du garantiert Impulse verlierst, wenn nur
die Überläufe erfasst werden.
Ein I²C-Bus Zugriff(Zählerabfrage) dauert hier
mit CC1 + ASM-Routine ca. 20ms
mit CC2 in C2 ca. 0,6 bis 0,7ms
C164CI mit 20MHz in ASM. ca. 0,2ms
> Meine Methode entlastet ja auch den I2C-Port, von daher hat das auch schon Vorteil für schnelle Controller.
1. Es gibt keinen "I2C-Port", sondern nur einen I²C-Bus.
2. Hab ich schonmal geschrieben, daß der I²C-Bus mit mind. 100kHz funzt ?
Das einzigste, was man machen könnte, wäre, wenn man entweder ein 9. Zählerbit einem Port zuführt und den Pegelwechsel überwacht oder
das 8. Zählerbit zusätzlich an einem Interrupt-Port zuführt.
An diesem Int-Port dürfte dann aber keine weitere Interruptquelle.
Den Int-Ausgang des PCF8574 würde man dann nichtmehr nutzen.
Ziel beim I²C-Bus ist es jedoch möglichst mit einer Interruptleitung für
die gesamte Peripherie auszukommen.
In der Robotik wird wahrscheinlich der I²C-Bus kaum verwendet, außer
höchstens einmal einen SD20 oder einen PCF8574 als Ausgangserweiterung anzuschließen.
Hier ist das Thema I²C-Bus-Interrupts sicher nicht wichtig.
Da, wie gesagt, meine Hardware für den Schwerpunkt Gebäudetechnik
entwickelt ist, ist es hier auch wichtig jede Veränderung zu erfassen.
Als Anwendungsbeispiel für das I2C-CNT8 sei hier z.B. ein Volumenstromgeber genannt, welcher Impulse höchtens mit ein paar Hz
ausgibt, wobei es jedoch z.B. bei Wärmemengenzählung wichtig ist,
die Zeitspannen etwas genauer zu erfassen, als nur bei einem Überlauf.
In der Gebäudetechnik können schnell einmal 20 bis 30 I²C-Bus-Baugruppen
an einem Bus hängen. (oder gar mehr)
(Auch eine oder mehrere RS232 am I²C-Bus, welche bei jedem empfangenen Byte einen Interrupt auslösen müssen !)
MfG André H.
Hi
Wußte nicht genau ob das so ist da du von "Aufwand" was geschrieben hattest. Na wenn es so ist, dann braust Du ja fast nix zu ändern.Zitat:
Zitat von André H.
Sorry, natürlich! Ich meinte du musst nur Überlauf auf Interrupt Eingang vom Controller führenZitat:
Zitat von André H.
Glaub ich nicht Andé. Gerade weil die C-Control so langsam ist hat man nur mit dem Überlauf die Chance genau zu zählen. Nach meiner Meinung verliert man Impule wenn man versucht ständig den Zähler bei jeder Änderung abzufragen. Ganz zu schweigen das es nicht gerade toll zu programmieren wäre, wenn der Controlle rnicht nur Räder bewegen muss und noch Sensoren abfragen usw. Mit einem Interrupt würde da alles wegfallen.Zitat:
Zitat von André H.
Natürlich hast Du recht das man immer nur den internen I2C-Bus nehmen sollte, das versteht sich.
Kleiner Versprecher!Zitat:
Zitat von André H.
Das weiss ich! Ich hab selbst schon mal den I2C Bus richtig belastet indem ich bei meinem Bot zwischen jedem Schrittmotorschritt alle möglichen Sensoren über I2C abgefragt hatte. War schon beachtlich wie schnell der läuft. Dennoch, ein paar solche belastenden Bus Anwendungen und dann wird es doch irgendwann enge!Zitat:
Zitat von André H.
Aber das sag ich doch als! ;-)Zitat:
Zitat von André H.
Genau! - Sag ja, kein Aufwand!Zitat:
Zitat von André H.
Ja im Normalfall bei deinen Anwendungen ist das ja auch alles ok. Nur beim Drehgeber finde ich das halt etwas belastend mit dauernder Abfrage, insbesondere halt bei C-Control.Zitat:
Zitat von André H.
Glaub wir sind uns nu mehr oder weniger einig ;-)
Gruß Frank