Hallo miteinander! Mein Ziel ist es 3 Drehzahlsensoren über 3 Atmega8 gleichzeitig auszulesen und die Daten an einen 4. Atmega32 zu schicken. Es handelt sich hierbei um eine Drehzahlregelung und deshalb müssen die 3 Drehzahlwerte möglichst schnell nacheinander beim Atmega32 eintreffen und weiterverarbeitet werden. Ich habe mir verschiedene Bussysteme angeschaut (I2C, CAN, RS232) weiß aber nicht welcher am sinnvollsten für mein Problem ist? Das ganze sollte möglichst einfach zu implementieren sein und eine hohe Übertragungsrate ( <20µs für das Schicken einer Drehzal) haben, deshalb hab ich an die UART Schnittstelle gedacht. Kann man über die UART Schnittstelle mehr als 2 Controller verbinden? Wie lange dauert eine einzelne Datenübertragung bei UART bzw. I2C (was ist schneller)? Grüße
@Holger Brenner >Mein Ziel ist es 3 Drehzahlsensoren über 3 Atmega8 gleichzeitig >auszulesen und die Daten an einen 4. Atmega32 zu schicken. >Kann man über die UART Schnittstelle mehr als 2 Controller verbinden? Nicht direkt, dazu müsstest du einen BUS ala RS485 realisieren. Die Frage ist auch, wie weit sind die 4 uC räumlich getrennt. >Wie lange dauert eine einzelne Datenübertragung bei UART bzw. I2C (was >ist schneller)? Schon mal die Datenblätter angeschaut? Ein UART läuft mit Standardfrequenzen mit bis zu 115200 Bit/s. Macht also ~86us/Byte. Für diese Anwendung kann man jedoch auch mit nichtstandardisierten Frequenzen arbeiten, bei 16 MHz Takt kommt man da auf 2 Mbit/s, macht also 5us/Byte. @ Obelix >> (was ist schneller)? >Das kommt auf die Geschwindigkeit an. Geanu! Und Apfelmus ist Mus aus Äpfeln. MfG Falk
Nur so als Anregung: Ein "Fahrraddyn." erzeugt eine Spg. Reicht so ein System? Dann wäre es ggf. nur mit einem uC machbar: weil 3->1 macht es langsamer Die Tacho#s am rad (per Magnet) könnte man so ähnlich auch verwenden. Gruß c.
Selbstverständlich kann man in diesem Fall Uart auch ohne rs485 und halbduplex verwenden, tx von mega32 an rx von allen mega8 und rx von mega32 an tx aller mega88 .
@Falk: Die Controller kann ich wenn's sein muss auf eine Platine packen. Die Kabel zu den Drehzahlensoren sind 50 cm lang. Deiner Meinung nach ist also die Verbindung über UART nicht möglich. Kannst du mir ein Bisschen mehr über RS485 erzählen (Links / C-Code). Wo ist der Unterschied zu RS323. Die Pins am Controller sind die gleichen (RXD TXD) und Periferie Bausteine brauch ich auch nicht, oder? Ist ein Bussystem mit RS485 schwiereig zum Laufen zu kriegen? Fällt bei diesen Übertragungsraten der I2C komplett weg? @Christian: Das System steht fest: 3 Drehzahlsensoren mit 7200 Impulsen pro Umdrehung.
>Mein Ziel ist es 3 Drehzahlsensoren über 3 Atmega8 gleichzeitig >auszulesen und die Daten an einen 4. Atmega32 zu schicken. Um welche Drehzahlen/Frequenzen handelt es sich? Könnte man das vielleicht sogar mit einem einzigen Controller hinbekommen? Sonst könnte man vermutlich ein dreikanaliges SPI aufbauen: Ein Chip-Select- und ein Clock-Signal, das alle drei Sklaven bekommen und dann noch jeweils eine Datenleitung vom Sklaven zum Master.
@capellone: Ich werd es mal ausprobieren. Wie kann ich unterscheiden von welchem der 3 Atmega8 die Information gekommen ist? Adressen vergeben, oder irgendwelche identifizierungs-Zeichen mitschicken? Kannst du mir ein Beispiel geben?
@ ein Troll: daran habe ich natürlich zuerst auch gedacht. Wäre am einfachsten und schönsten. Die Frequenzen sind bei langsamen Drehgeschwindigkeiten -> 0 (bei Stillstand) also je langsamer desto länger sind die Impulse und bis zu 72kHz bei 3000 U/min. Da ich die Frequenz mit dem Input Capture Pin auslese ergibt sich je nach Frequenz eine unterschiedliche Zeitdauer für die Messung und das macht Probleme bei der Regelung (konstante Abtastzeit). Aber wenn du eine andere Möglichkeit parat hast ich bin für jenden Vorschlag dankbar!
@capellone >Selbstverständlich kann man in diesem Fall Uart auch ohne rs485 und >halbduplex verwenden, tx von mega32 an rx von allen mega8 und rx von >mega32 an tx aller mega88 . Ach so, den Uart jeweils deaktivieren und das Pin auf Tristate. Stimmt. Ist aber dann auch ein Bussystem, nur halt mit TTL-Pegel. @Holger Brenner >Deiner Meinung nach ist also die Verbindung über UART nicht möglich. ??? Hab ich das gesagt? Sie ist schon möglich, wen man ein paar Kleinigkeiten beachtet. >Kannst du mir ein Bisschen mehr über RS485 erzählen (Links / C-Code). Wen die Controller auf einer Platine sitzen brauchst du kein RS485. Das ist nur bei langen Übertragungsstrcken notwenig. >Wo ist der Unterschied zu RS323. Die Pins am Controller sind die Die elektrischen Pegel sind anders. Ausserdem isr RS232 nur single ended (1 Leitung / Signal + gemeinsame Masse), während RS485 differentiell ist (zwei Leitungen pro Signal + Masse). >gleichen (RXD TXD) und Periferie Bausteine brauch ich auch nicht, oder? >Ist ein Bussystem mit RS485 schwiereig zum Laufen zu kriegen? Kommt auf deinen Kenntnisstand an. >Fällt bei diesen Übertragungsraten der I2C komplett weg? Kann man nciht pauschal sagen. I2C geht im "Normalfall" bis 400 kbit/s, spezielle High-Speed Modi machen 3,2 Mbit/s. Da würde ich dann aber lieber SPI nehmen. >Das System steht fest: 3 Drehzahlsensoren mit 7200 Impulsen pro >Umdrehung. Ach so, dann sollen quasi die drei uC die Pulsfreqenz messen und daraus die Drehzahl berechnen. Kann man so machen. Wenn die Controler auf einer Platine sitzen kannst du auch SPI oder ähnliches machen. Auch eine Mischung aus UART und SPI wäre denkbar (Per Chip select einen der drei Controller auswählen, dieser schicht dann per UART die gemessene Drehzahl) >Wie kann ich unterscheiden von welchem der 3 Atmega8 die Information >gekommen ist? Ganz einfach, über die drei Select Leitungen die dein Mega32 bedient. MFG Falk
Wie genau muss das sein ? Ggf. reicht eine "PWM": Je Umdrehung 1 Impuls + Tiefpass = Mittelwert Max. Umdrehung == max. Spannung => Nachteil langsame Erkennung der Freqänderung (TP-Verhalten) Wenn die drei Umdreh. zusammenhängen: 3 Timer + fester takt. Starten nach jeder Umdrehung neu + samplen des letzt Wertes, bevor eine Umdrehung neu anfängt. Zählerstand einlesen + ggf. Pegelsetzen für neuen wert + das Zwischenspeichern ggf. im mehreren FF, um die Änderung zu erkennen. Summa: Oszi (vom AT..32) Zähler + Reset (je Umlauf) Speicher (bei Reset) einlesen vom AT..32 Grus c
Du kannst rs232 nehmen, und mit einem & glied verbinden. Dann einen pin "request-pin" an jeden mega8 und fertig Deine Daten empfängst du dann über die HW UART des M32
@Falk: Der Vorschlag klingt gut. Du meinst z.B also folgendes: 3 Pins am Atmega32 wählen den jeweiligen Atmega8 aus indem der 32er einen von den drei Pins high setzt und der dann am 8er abgefragt wird und nur dann sendet, die zwei anderen Pins sind low also senden die zwei anderen Atmega8 nichts. Vielen Dank für den Gedankenanstoss.
>Mein Ziel ist es 3 Drehzahlsensoren über 3 Atmega8 gleichzeitig >auszulesen und die Daten an einen 4. Atmega32 zu schicken. Aha. Und aus welchem Grund willst Du diese Aufgabe nicht mit einem Controller bewerkstelligen?
@AVRFan >>Mein Ziel ist es 3 Drehzahlsensoren über 3 Atmega8 gleichzeitig >>auszulesen und die Daten an einen 4. Atmega32 zu schicken. >Aha. Und aus welchem Grund willst Du diese Aufgabe nicht mit *einem* >Controller bewerkstelligen? Vermutlich deshalb. >daran habe ich natürlich zuerst auch gedacht. Wäre am einfachsten und >schönsten. Die Frequenzen sind bei langsamen Drehgeschwindigkeiten -> 0 >(bei Stillstand) also je langsamer desto länger sind die Impulse und bis >zu 72kHz bei 3000 U/min. Das braucht min. 3 Timer zum Zählen + 1 Timer für die Zeitmessung. Und auch 3 Input Capture gibs in den AVRs leider nicht (die ganz grossen haben 2, einge 4?) Mfg Falk
Mit etwas logik gehts auch mit einem ICP Alle drei Siganle per Oder Gatter auf ICP und über 3 Pins dann im interupt abfragen welches die Quelle war, udn in 3 Variablen dann die Zeiten speichern...
@Läubi Mail@laeubi.de >Mit etwas logik gehts auch mit einem ICP >Alle drei Siganle per Oder Gatter auf ICP und über 3 Pins dann im >interupt abfragen welches die Quelle war, udn in 3 Variablen dann die >Zeiten speichern... Klassischer Anfängerfehler! Die drei Sensoren laufen ganz sicher NICHT synchron, da ist jede beliebige Phasenlage/Timing möglich, dementspechend können sich Pulse zu ultrakurzen Spikes überlagen. -> Nix mit Messung MFG Falk
@Falk: Genau das ist das Problem.(Hab schon über nen Multiplexer auf den ICP nachgedacht, funktioniert aber auch nicht bei unterschiedlicher Frequenz). Ich hab mir schon einige Gedanken, das Problem mit einem Controller zu lösen gemacht, bin aber auf nichts wirklich sauberes, einfaches, schnelles und genaues gekommen, deshalb die Lösung mir den 3 kleinen Atmegas. Klingt auf's erste zwar kompliziert ist aber doch die sinnvollest Alternative. @Christian: Das mit PWM und glätten und dann als AD Wert einlesen hab ich auch überlegt. Das ganze wird dann aber so ungenau dass es für eine Regelung nicht mehr taugt.
@Holger Brenner >Klingt auf's erste zwar kompliziert ist aber doch die sinnvollest >Alternative. Ich hätte nen kleinen CPLD genommen ;-) >Das mit PWM und glätten und dann als AD Wert einlesen hab ich auch >überlegt. >Das ganze wird dann aber so ungenau dass es für eine Regelung nicht mehr >taugt. Eben. Ist auch reichlich sinnfrei, einen Messwert, welcher schon digital vorliegt, (Rechtecksignal mit einer Freqenz proportional zur Drehzahl) in analog zu wandeln und dann wieder zu digitalisieren. MfG Falk
Wäre schlichtes Multiplexen eine Möglichkeit? Die drei Sensoren an die Eingänge eines 3-zu-1-Multiplexers. Dessen Ausgang an den µC, der jeden Sensor einzeln über Steuerleitungen auswählen kann. Auswertung mit einem Timer und einem ICP. Die drei Sensoren werden reihum alle 166 ms (Beispielwert) selektiert und die Drehzahl berechnet. Ergibt eine Refreshrate von immerhin noch 2 Aktualisierungen pro Sekunde für jeden Sensor. Schneller kann man auf nem Display eh nix ablesen.
PWM: Regelung: wenn es nicht schnell sein muss: die Impulse zählen + reset: bei so 10 Sek, sollte die Toleranz nicht so groß sein? => wie konst. läuft das ganze ? Regelung: Totzeitsystem, wegen verschiedener Zeiten der Auswertung? + einen TP kann man per ADU ausmessen, das machts etwas schneller. + mehrere TPs parallel: dann den optimalen nehmen, das kann der/die uCs auswählen: aber medrere ADU-eingänge! => eh nicht nutzbar, wegen Taktrate hoch == ADU schlechter bei 4 AT... warum nicht einen ARM (lpc.... ) Nur so C.
Wenn es um das reine Verbinden von vier AVR geht (1 Master 3 Slave) Dann ist eine 8 Bit parallel Anbindung mit separaten CS Leitungen mit sicherheit am schnellsten (82C55 oder ein paar latches). Die M8 schreiben permanent in den Ausgabeport, und der M32 holt sich die Daten nach eigenem Gusto von jeweiligen Slave ab. Nachteil sind die vielen Leitungen. Weiterhinn sollten alle AVR mit der gleichen Taktbasis laufen (Quarzoscilator). Als schnellste serielle Lösung wäre SPI zu nennen. Braucht lediglich 32 Slavetakte für ein Byte. Das wären dann 2µs für die Übertragung (pro Slave) und weiterer 125-250ns für den Slave select. Hier gilt das gleiche mit der Taktbasis. Am modulartsten und flexibelsten ist TWI bus. Nur ist der mit lediglich ca. 400kHz (im Vergleich zu den 4MHz bei SPI) sehr viel langsamer. Ab gemächlichsten ist UART mit 115kBaud. Hat aber je nach übertragungstechnik die größte Reichweite. Das Slaveselect Protokoll muß jedoch komplett in Software gemacht werden. Wenn man also alle fünf vergleicht: 8Bit par (bei 16 MHz) 42,6 Mbit/s (3 Master Takte/8bit) 11 Leitungen (8*Data + 3*CS) SPI (bei 16 MHz) 4Mbit/s (4 Slavetakte/bit) 5 Leitungen (1*MISO + 1*SCK + 3*CS) (MOSI wird nicht benötigt) TWI (bei 400kHz) 160kBit/s (Start+Adresse+Ack+Daten+Nack+Stop=20 Takte/8bit) 2 Leitungen (SCL+SDA) UART (bei 115,2 kBaud ohne Parity) 92,16kbit/s (1Startbit+8Datenbit+1Stopbit=10Bit/8Bit) 2-4 Leitungen (TX+RX oder RX + 3*CS) Diese ganzen Beispiele sind natürlich ohne Kontroll-Overhead. Durch diesen werden die Netto raten nochmal sinken. cu Hauke
Ein bißchen sehr kompliziert, was ihr da plant... Du hast 3 Motoren mit Drehzahlgeber, jeder generiert 7200 Impulse pro Drehung (warum so viel? Wie genau soll denn das geregelt werden) das legst du auf je einen Interrupt und bei jeder steigenden Flanke erhöst du den jeweils einen Zähler. Mit konstanter Abtastzeit werden jeweils die Zähler ausgelesen und zurückgesetzt. Die ausgelesenen Werte werden in Drehzahlen umgewandelt. Die konstante Abtastzeit mußt du entsprechend deiner Anforderung bestimmen. Oder du nimmst den die Drehzahlimpulse als externen Takt des jeweiligen Counters.
@Wolfram >Du hast 3 Motoren mit Drehzahlgeber, jeder generiert 7200 Impulse pro >Drehung >(warum so viel? Wie genau soll denn das geregelt werden) >das legst du auf je einen Interrupt und bei jeder steigenden Flanke >erhöst du den jeweils einen Zähler. Mit konstanter Abtastzeit werden Thread gelesen oder nur überflogen? 72 kHz Pulsfreqeunz sind nicht ganz ohne. Mit einem Interrupt pro Puls wird das gar nichts. Jaja, die Timer können das auch alleine zählen, nur haben die meisten AVRs keine 4 Timer, nur die ganz Grossen. MfG Falk
Danke für die schnellen Antworten. Ich werd das jetzt mal umsetzen und sag Bescheid wenn's funktioniert.
Ich glaube, Du hast Dir über Kosten-Nutzen noch keine abschließenden Gedanken gemacht. Mit welcher Häufigkeit soll denn die Regelschleife auf dem 32er berechnet werden? 1000 mal pro Sekunde? Schafft er das? Dann würde es reichen, wenn alle drei 8er in 1ms gelesen werden. Wenn mein Taschenrechner nicht lügt, hast Du Frequenzen bis 360Khz zu verarbeiten (7200 Impulse bei max. 50 Umdrehungen/s). Da wird ein Mega8 schon warm. Die Meßwerte noch 'nebenbei' schnell auszugeben, wird ihm schwerfallen. Und wie hoch aufgelöst sollen denn die Drehzahlen verarbeitet werden? 4-stellig, 5-stellig? Bei 16MHz Takt und 1ms Meßzeit bekommt man eine Auflösung von 1/16000, was guten vier Stellen entspricht. Ich würde auf jeden Fall die Eingangsfrequenz reduzieren (360kHz ist zu viel) und, wenn eine hohe Leistung gefordert ist, jede Regelung in einem separaten 8er/16er/32er ablaufen lassen. Diese können dann von einem 4. µP kontrolliert bzw. gesteuert werden. Nur so als Idee.
@Profibauer: Ich hab mir die Drehzahlsensoren grad mal genauer angeschaut. Die machen 720 Impulse pro Umdrehung auf jeder Spur. Da ich auch noch die Drehrichtung (2.Spur)erkennen muss ist die Auflösung 1440 Impulse pro Umdrehung * 50 Umdrehungen pro Sekunde = 72kHz (13,8 µs zwischen zwei Impulsen). Wenn ich mit einer Baudrate von 2Mbps arbeite und die Zahlen die ich versicken will zwischen 1 (U/min) und 3000 (U/min) liegen, könnte das nicht klappen? P.S: Meine Abtastfrequenz liegt bei 4kHz und sollte auch nicht weniger werden, da gleichzeitig PWM Frequenz, sonst bekomm ich zu hohe Stromspitzen. Gruss Holger
@Holger Brenner >Ich hab mir die Drehzahlsensoren grad mal genauer angeschaut. Die machen >720 Impulse pro Umdrehung auf jeder Spur. Da ich auch noch die Waren es nciht gestern 7200 Pulse/umdrehung? Faktor 10 ? >Drehrichtung (2.Spur)erkennen muss ist die Auflösung 1440 Impulse pro >Umdrehung * 50 Umdrehungen pro Sekunde = 72kHz (13,8 µs zwischen zwei >Impulsen). >Wenn ich mit einer Baudrate von 2Mbps arbeite und die Zahlen die ich >versicken will zwischen 1 (U/min) und 3000 (U/min) liegen, könnte das >nicht klappen? Sicher, aber du willst und musst ja wohl kaum im 13 us Raster deine Frequenz messen. Denn die Äuflösung wäre dann selbst bei 16 MHz Controllertakt auf ca. 13*16 = 208 Zähler begrenzt. Naja ~0,5%. >P.S: Meine Abtastfrequenz liegt bei 4kHz und sollte auch nicht weniger >werden, da gleichzeitig PWM Frequenz, sonst bekomm ich zu hohe >Stromspitzen. Dann läuft deine Regelung wohl auch mit 4 kHz Abtastfrequenz?! Sprich du musst auch nur mit 4 kHz (250us) deine Freqeunz messen. Das passt schon. (wobei ich das mit nem CPLD gelöst hätte, schliesslich ist es nur 3x Quadraturdecoder + Vorwärts/Rückwärts Zähler). MfG Falk
Sind die Drehzahlsensoren dir vorgegeben? Es erschließt sich mir nicht warum du so viele Impulse brauchst. Du hast 50 Umdrehungen /s Warum benötigst du so eine hohe Auflösung? Deine Abtastfrequenz hat nichts mit deiner PWM frequenz zu tun. Die können unabhängig laufen. Nur um das mal reeller zu betrachten 50 Umdrehungen /s = 1 Umdrehung / 20ms Bei 4 kHz Abtastfrequenz hat sich deine Welle gerade mal um 4,5 Grad /Sample gedreht!!! Was willst du machen? Willst du das sich da was mit konstanter Drehzahl dreht oder willst du positionieren?
@Wolfram >Es erschließt sich mir nicht warum du so viele Impulse brauchst. >Du hast 50 Umdrehungen /s Warum benötigst du so eine hohe Auflösung? Und was ist bei niedrigen Drehzahlen? >50 Umdrehungen /s = 1 Umdrehung / 20ms >Bei 4 kHz Abtastfrequenz hat sich deine Welle gerade mal um 4,5 Grad Vielleicht eine Präzisionsregleung für CNC Maschinen? MfG Falk
Wie genau muss was wann sein ? Bei der hohen Anzahl von Impulsen pro Umdrehung ist (eine ADU messung ggf. doch machbar) Ansonsten würde ich ggf. eine Teiler hinter den Impulsgeber setzen, Motto: weniger Impulse, weniger Probleme beim uC Wie gesagt: Genauigkeit = ? Drehzahlbereich = ? brauchst Du 0,1 Umdreh/min o.s. ?
@Holger Da sieht man mal wieder was Nullen alles so anstellen können ;-) Wäre es nicht einfacher, jeden Motor mit einem separaten µP anzusteuern und zu regeln? Dann gäbe es keine Engpässe bei der Datenübertragung und (vermutlich) beim zur Zeit geplanten zentralen 32er Prozessor. Bei 4kHz Abtastrate würde sich eine Auflösung von 1/4000 ergeben (16MHz µP). Zweckmäßigerweise würde man die Impulse an ICP anlegen und alle 250µs die Anzahl und die genaue Zeit dazu auswerten - synchron zur PWM. Dies muß per Interrupt erfolgen und wird bei 72kHz und geschickter Programmierung etwa 25% Prozessorleistung 'fressen'. Für die Regelung bliebe genug Luft. Der Hauptprozessor steuert über UART (am besten Multiprozessorprotokoll, 62,5kBd) die drei µPs. So würde ich es angehen. Ach so. Es ist natürlich elegant die Drehrichtung automatisch zu erkennen, aber ist diese denn dem Motortreiber nicht schon vorgegeben und damit konstant?
@Profibauer >Da sieht man mal wieder was Nullen alles so anstellen können ;-) Ein Null kann bestehende Probleme verzehnfachen. ;-) >Wäre es nicht einfacher, jeden Motor mit einem separaten µP anzusteuern >und zu regeln? Dann gäbe es keine Engpässe bei der Datenübertragung und Warum sollte es für ein paar Byte Engpässe geben? >Bei 4kHz Abtastrate würde sich eine Auflösung von 1/4000 ergeben (16MHz >µP). Zweckmäßigerweise würde man die Impulse an ICP anlegen und alle >250µs die Anzahl und die genaue Zeit dazu auswerten - synchron zur PWM. Wenn das mal keine Irrtum ist. Es sind wie ich es verstanden haben Quadraturencoder. Wenn die mit 72 kHz Pulse generieren muss man mit min. 100 kHz abtasten. ggf. noch schneller. Damit ist ein AVR vollauf beschäftigt. Ich sag nur CPLD - Ole! ;-) >Der Hauptprozessor steuert über UART (am besten Multiprozessorprotokoll, >62,5kBd) die drei µPs. So würde ich es angehen. Irgenwie sehe ich gerade Kanonen und Spatzen vor meinem geistigen Auge. MFg Falk
>Irgenwie sehe ich gerade Kanonen und Spatzen vor meinem geistigen Auge. Das liegt an Deinem Spiegel! >Wenn die mit 72 kHz Pulse generieren muss man mit min. 100 kHz abtasten. >ggf. noch schneller. Darum habe ich ICP gesagt. Muß man nur begreifen können. Die Impulse selber könnte man auch mit einem weiteren Zähler (TCNT-Eingang) messen. Sonst wie gesagt per Interrupt. Die Prozessorbelastung habe ich genannt.
@Profibauer >>Irgenwie sehe ich gerade Kanonen und Spatzen vor meinem geistigen Auge. >Das liegt an Deinem Spiegel! Spiegel? Blutalkoholspiegel? ;-) >>Wenn die mit 72 kHz Pulse generieren muss man mit min. 100 kHz abtasten. >ggf. noch schneller. >Darum habe ich ICP gesagt. Muß man nur begreifen können. Aha. Und du hast auch 3x2 ICPs am AVR? Schon zwei haben die meisten NICHT. Und dass Quadraturgeber sinnvollerweise abgetastet werden hatten wir auch schon mehr als einmal SEHR lange diskutiert. Beitrag "Drehgeber auslesen" >(TCNT-Eingang) messen. Sonst wie gesagt per Interrupt. Die >Prozessorbelastung habe ich genannt. Und? Das ist deine Schätzung. Nicht mehr (und nicht weniger). MfG Falk
Die Drehzahlsensoren sind fest installiert. Wie gesagt 720 Imp/Umdrehung, da eine Schwingung ausgeregelt werden soll muss die Drehrichtung (zumindestens im unteren Drehzahlbereich)auch erfasst werden, also 2.Spur mit nochmal 720 Imp/ Umdrehung phasenversetzt. Mit dem IC Pin messe ich die Zeit zwischen zwei high Flanken und bekomm somit die Frequenz - sprich Drehzahl(hab ich schon getestet funktioniert soweit ganz gut). D.h. bei niedrigen Frequenzen (langsamen Drehzahlen ergibt sich das Problem das die Werte zu langsam aktualisert werden -> werde eine Untergrenze einführen müssen!) und bei hohen Frequenzen kommt der UART nicht mit die Daten zu verschicken (- Obergrenze einführen, müssen keine 3000 U/min sein) Ich muss das ganze ausprobieren, da mir keine bessere Lösung einfällt und je nachdem Einschränkungen für den Drehzahlbereich machen. @Falk: Von CPLD hab ich keine Ahnung und auch keine Zeit mich einzuarbeiten, ist das sowas wie ein FPGA?
@Holger Brenner >Ich muss das ganze ausprobieren, da mir keine bessere Lösung einfällt >und je nachdem Einschränkungen für den Drehzahlbereich machen. Dein Ansatz klingt erstmal ganz gut. >Von CPLD hab ich keine Ahnung und auch keine Zeit mich einzuarbeiten, >ist das sowas wie ein FPGA? Ja, das sind die kleinen Brüder der FPGAs. MFG Falk
>D.h. bei niedrigen Frequenzen (langsamen Drehzahlen ergibt sich das >Problem das die Werte zu langsam aktualisert werden -> werde eine >Untergrenze einführen müssen!) Das liegt in der Natur der Sache. Beispiel: Wenn das Rad zwei Umdrehungen pro Tag macht, dauert es von einem Zahn zum nächsten 1 min. Dann solltest Du nicht den Ehrgeiz entwickeln, die momentane Drehzahl mit einer Refreshrate von 10 Aktualisierungen pro Sekunde messen zu wollen. >und bei hohen Frequenzen kommt der UART >nicht mit die Daten zu verschicken (- Obergrenze einführen, müssen keine >3000 U/min sein) Vielleicht macht es Sinn, über die Frage nachzudenken, ob der UART die Daten unbedingt nach jedem einzelnen Zahn verschicken muss, oder ob es auch reicht, wenn die Messwerte in ein Register geschrieben werden, dessen Inhalt der UART mit einer festen, zweckmäßigen Frequenz von z. B. 20 Hz dem Mastercontroller mitteilt?
@Holger
Noch einmal.
Du nimmst einen µP und erfaßt damit die Drehzahl, regelst sie nach und
generierst ein PWM Signal für einen Motor.
Wenn das funktioniertt, versiehst Du diese Schaltung / dieses Programm
mit einer UART-Schnittstelle zur Kommunikation und steuerst diese drei
µPs über einen zentralen µP.
>auch erfasst werden, also 2.Spur mit nochmal 720 Imp/ Umdrehung phasenversetzt.
Reicht es nicht, gleichzeitig zum Impuls der 1. Spur den Pegel der 2.
Spur zu lesen, um die Drehrichtung zu erkennen?
>>(TCNT-Eingang) messen. Sonst wie gesagt per Interrupt. Die >>Prozessorbelastung habe ich genannt. >Und? Das ist deine Schätzung. Nicht mehr (und nicht weniger). Aktuell habe ich dies von Holger in der Codesammlung gefunden: Beitrag "Re: Input Capture Pin (ICP) auslesen ( Frequenz messen)" Hier wird beschrieben, wie ein AVR mit 4MHz bei einer ICP-Frequenzmessung bei 75kHz an seine Grenzen stößt. Oben hatte ich die Prozessorbelastung bei 16MHz und 72kHz auf 25% geschätzt. Bei 4MHz => 100% und bei 16MHz => 25% trifft es doch ganz gut ;-) Das zu Schätzwerten und zu Schwätzwerten. @Holger: Wie sieht Deine Lösung aus?
Die Lösung läßt noch auf sich warten, bin grad dabei den UART richtig zum laufen zu kriegen. Scheint doch komlizierter zu werden als gedacht. Sag bescheid wenn ich soweit bin.
Hallo, Wenn du doch wieder zurück zu RS232-Kommunikation willst mal ein Vorschlag. Inwieweit kennst du dich mit Bustopologien aus?? Token Ring?? Also der tx vom 32 zum rx des ersten 8er dessen tx an den Rx von nächsten, bis du wieder beim 32 angekommen bist. Dann ein microprotokoll: Der 32 sendet !xxxxxyyyyyzzzzz an den ersten 8er dieser ersetzt xxxxx durch seine Drehzahl und sendet den String weiter an den zweiten 8er dieser ersetzt dann yyyyy durch seine drehzahl usw. Wenn das ganze wieder beim 32er ankommt hast du einen String mit ! und den 3 Drehzahlen. Inwieweit das mit deiner Geschwidigkeit hinkommt, hängt davon ab mit welcher Frequenz deine µCs laufen und in welcher Sprache du schreibst. jochen http://www.rs485-hausbus.de.vu
warum zum teufel den uart??? nimm einfach spi.. der mega32 generiert dir dann 3 CS signale (je nachdem von welchem mega8 er daten will) und die mega8 messen gemütlich vor sich hin... du schreibst oben was von festen intervallen... daher nehme ich an, dass du im mega32 eigentlich nur einen timer rennen hast, der die in bestimmten intervallen dir deine stellgröße berechnet... mach doch einfach eine leitung von jedem mega8 zu deinem mega32... wenn der mega8 neue daten hat dann legt er die leitung auf high... nach dem berechnen deiner stellgrösse wartest du dann im mega32 einfach bis ein mega8 neue daten hat bzw bis die zeit abgelaufen ist und du wieder berechnen darfst... im mega 8 misst du.. wartest bis sie vom mega32 abgeholt werden stellst die leitung auf low und misst dann wenn der CS weg ist wieder weiter... die daten holst du am besten per spi ab ... der uC sollte dann das tristate-schalten von deinem dout-pin von selbst machen... einfach im datesheet nach spi-slave suchen... das sollte eigentlich deinen aufwand minimieren und nebenbei auch fix gehen :) nur wenn du meinst das übertragen soll unter 20uS pro wert sein dann willst du da mit über 10kHz regeln... schonmal nachgedacht ob da dein system mitmacht??? 73
@ Jochen S. >Inwieweit kennst du dich mit Bustopologien aus?? Token Ring?? >Also der tx vom 32 zum rx des ersten 8er dessen tx an den Rx von >nächsten, bis du wieder beim 32 angekommen bist. Dann ein Und wozu der Aufwand? 3x Chip Select tuts locker. @ Hans >warum zum teufel den uart??? >nimm einfach spi.. der mega32 generiert dir dann 3 CS signale (je >nachdem von welchem mega8 er daten will) und die mega8 messen gemütlich >vor sich hin... Das tun sie auch mit UART. OK, SPI ist schneller, aber für 3x2 Byte alle 250us tuts auch der UART locker, er muss ja nicht mit irgendwelchen Standardbautraten arbeiten. Da höchstwahrscheinlich alle 4 uC sowieso am gleichen Takt hängen einfach UBRR mit 0 beschreiben (ist glaub ich sogar der RESET Wert) und gut ist. >das sollte eigentlich deinen aufwand minimieren und nebenbei auch fix >gehen :) Ich glaub das hat er schon verstanden. UART != RS232. >nur wenn du meinst das übertragen soll unter 20uS pro wert sein dann >willst du da mit über 10kHz regeln... schonmal nachgedacht ob da dein >system mitmacht??? Mal den Tread gelesen? Es hat 4 kHz Zyklusfreqeunz. MFG Falk
Also nach längerer Pause hier meine Realisierung: Da ich genügend freie Pins zur Verfügung, habe hab ich mir die Idee von Hauke Sattler nochmal angeschaut und sie umgesetzt. Drehzahl parallel übertragen und mit Chip Select Leitungen den jeweiligen Amtega8 aussuchen. Funktioniert super und ist einfach zu realisieren. Atmega8: Die gemessene Frequenz wird in die Drehzahl umgerechnent an dann in 2 x 8bit Werte aufgeteilt. Dann werden per externem Interrupt die beiden Werte rausgeschickt (in "C" einfach mit "PORTX") und am Atmega32 wieder zusammengesetzt. Atmega32: Pro Regelschleifendurchlauf wird jeweils ein Pin high gesetzt und im daraufolgenden Durchlauf wird der 8bit Wert abgeholt (einfach mit "PINX"). Also insgesamt 6 Durchläufe à 250µs für 3 x 16bit Drehzahlwerte. Ist programmiertechnisch sehr einfach umzusetzen und Übertragungsprotokolle und Baudraten einstellen entfällt auch. Viele Grüße und Danke für die Hilfe
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.