Mein erstes fertiggestellt Projekt. Hier einige Bilder und auch ein kleines Video. Programmiert wurde in Bascom und verwendet wurden 3 Atmega8. Freue mich auf Feedback und Fragen.
Moving Head (fertiges Projekt)
- Ersteller UltimateProjects
- Erstellt am
Hallo!
Ein schönes Projekt und deine Projektpräsentation mit Bildern und Video ist echt gut. Beim Video blendest du die Texte etwas kurz ein, beim ersten mal anschauen bekommt man nicht alles mit, da man ja auch auf das Gerät konzentriert ist
Besonders für unsere Bascom-Anwender wäre es sicher interessant, wie du Software und Hardware gelöst hast. Mich interessiert nun, warum du drei ATmega8 verwendet hast, wegen Anzahl der PWM-Kanäle?
Dirk
DankeHallo!
Ein schönes Projekt und deine Projektpräsentation mit Bildern und Video ist echt gut. Beim Video blendest du die Texte etwas kurz ein, beim ersten mal anschauen bekommt man nicht alles mit, da man ja auch auf das Gerät konzentriert ist
Besonders für unsere Bascom-Anwender wäre es sicher interessant, wie du Software und Hardware gelöst hast. Mich interessiert nun, warum du drei ATmega8 verwendet hast, wegen Anzahl der PWM-Kanäle?
Dirk
Erstens bin ich noch nicht so erfahren mit µC (war mein erstes Projekt mit einem µC), deshalb fand ich die Herausforderung, die gesamte Software auf ein µC zu schreiben, zu schwer und zweitens hatte ich zu wenig PWM-Kanäle bzw. Counter. Deshalb habe ich die Software geteilt und jeden µC eine Aufgabe übergeben: 3 Schaltungen + jeweilige Software für Displaysteuerung, LED-Steuerung und Motorsteuerung, die untereinander verbunden sind(parallel).
TommyB
Team Bitschubse
Ist wirklich gut geworden!
Sowohl das Projekt alsauch das Video. Und sowas gleich als erstes µC Projekt? Respekt!
p.s.: Willkommen hier im Forum
Sowohl das Projekt alsauch das Video. Und sowas gleich als erstes µC Projekt? Respekt!
p.s.: Willkommen hier im Forum
Hallo und Willkommen im Forum!
Was Deine Präsentation betrifft, kann ich mich Dirk und Thomas nur anschliessen.
Zum Programm- und Schaltungskonzept hast Du ja nichts weiter veröffentlicht. Da das ganze schon recht komplex zu sein scheint, wäre 'ne Darstellung mit Funktionsblöcken angebracht.
Warum Du das ausgerechnet 3 Mega8 aufhalst, erschließt sich mir zB auch nicht.
Ich sehe 2 (Schritt- ?) Motoren, ein Alphanumerisches Display und eine "Drei-Farb-Lampe" (Die sind doch alle synchron, oder?).
Ich hätte auch mehrere Controller für die unterschiedlichen Funktionen eingesetzt, die dann über einen geeigneten Bus o.ä. kommunizieren (TWI, SPI, UART (Entenmarsch) etc).
Für die "Lampe" hätte ich mir einen kleinen Controller rausgesucht, der 3 PWM-Ausgänge an einem Timer bietet, und den verwendeten "Bus" kann.
Bei den Motoren (wennst denn Stepper sind) hätte ich entsprechende Treiber-ICs eingesetzt (L6208, den klassischen L298/L297, ...), der Controller müßte dann also nur noch die Richtungs- und Schrittimpulse ausgeben. Wesentliche Aufgabe wäre dann, mit entsprechenden Beschleunigungs- und Bremsrampen mit einer vorgegebenen Geschwindigkeit 'ne vorgegebene Winkelposition anzufahren (eventuell also ein PWM-Ausgang, oder alles in Software).
Einen Master-Controller, der den Motoren und der "Lampe" sagt, was sie machen sollen, und Display/Taster/Mikrofon versorgt/auswertet.
Als Bus dann wie gesagt eventuell TWI, der Master sendet dann Telegramme wie "MotorX, PositionY, TempoZ" oder "LampeA, Farbe1, Farbe2, Farbe3".
Kann man natürlich mit weiteren Extras würzen, zB daß der Lampencontroller bei einem Farbwechsel scharf umschalten oder sanft faden kann, oder daß er mit einer vorgegebenen Frequenz blinken/faden kann (ggf für jede Farbe einzeln).
Auf die Art und Weise könnte das ganze bequem erweitert werden, die einzelnen Controller sind aber trotzdem überschaubar/einfacher implementierbar.
Und nun den Bogen zurück zu den gewählten Mega8:
Der bietet 2 PWM an 'nem 16Bit-Timer, und einen PWM an 'nem 8Bit-Timer. Alle 3 PWMs liegen auf den SPI-Beinen, was beim In-System-Programmieren zu berücksichtigen wäre.
Er besitzt zur Kommunikation einen UART, einen SPI und einen TWI.
Wäre meine Herangehensweise gewesen - Du hast das ja bereits fertig. Gibst Du uns trotzdem noch ein paar Einblicke ins Programm- und Schaltungskonzept?
Was Deine Präsentation betrifft, kann ich mich Dirk und Thomas nur anschliessen.
Zum Programm- und Schaltungskonzept hast Du ja nichts weiter veröffentlicht. Da das ganze schon recht komplex zu sein scheint, wäre 'ne Darstellung mit Funktionsblöcken angebracht.
Warum Du das ausgerechnet 3 Mega8 aufhalst, erschließt sich mir zB auch nicht.
Ich sehe 2 (Schritt- ?) Motoren, ein Alphanumerisches Display und eine "Drei-Farb-Lampe" (Die sind doch alle synchron, oder?).
Ich hätte auch mehrere Controller für die unterschiedlichen Funktionen eingesetzt, die dann über einen geeigneten Bus o.ä. kommunizieren (TWI, SPI, UART (Entenmarsch) etc).
Für die "Lampe" hätte ich mir einen kleinen Controller rausgesucht, der 3 PWM-Ausgänge an einem Timer bietet, und den verwendeten "Bus" kann.
Bei den Motoren (wennst denn Stepper sind) hätte ich entsprechende Treiber-ICs eingesetzt (L6208, den klassischen L298/L297, ...), der Controller müßte dann also nur noch die Richtungs- und Schrittimpulse ausgeben. Wesentliche Aufgabe wäre dann, mit entsprechenden Beschleunigungs- und Bremsrampen mit einer vorgegebenen Geschwindigkeit 'ne vorgegebene Winkelposition anzufahren (eventuell also ein PWM-Ausgang, oder alles in Software).
Einen Master-Controller, der den Motoren und der "Lampe" sagt, was sie machen sollen, und Display/Taster/Mikrofon versorgt/auswertet.
Als Bus dann wie gesagt eventuell TWI, der Master sendet dann Telegramme wie "MotorX, PositionY, TempoZ" oder "LampeA, Farbe1, Farbe2, Farbe3".
Kann man natürlich mit weiteren Extras würzen, zB daß der Lampencontroller bei einem Farbwechsel scharf umschalten oder sanft faden kann, oder daß er mit einer vorgegebenen Frequenz blinken/faden kann (ggf für jede Farbe einzeln).
Auf die Art und Weise könnte das ganze bequem erweitert werden, die einzelnen Controller sind aber trotzdem überschaubar/einfacher implementierbar.
Und nun den Bogen zurück zu den gewählten Mega8:
Der bietet 2 PWM an 'nem 16Bit-Timer, und einen PWM an 'nem 8Bit-Timer. Alle 3 PWMs liegen auf den SPI-Beinen, was beim In-System-Programmieren zu berücksichtigen wäre.
Er besitzt zur Kommunikation einen UART, einen SPI und einen TWI.
Wäre meine Herangehensweise gewesen - Du hast das ja bereits fertig. Gibst Du uns trotzdem noch ein paar Einblicke ins Programm- und Schaltungskonzept?
Zuletzt bearbeitet:
Natürlich wäre das auch eine Lösung, wahrscheinlich auch die bessere und sie wäre auch professioneller. Da ich aber noch nicht so viel Erfahrung im Gebiet µC bzw. allgemein im Gebiet Programmieren habe, war es für mich die 'einfachste' Lösung. Meine Idee war es also, um die Komplexität der Software zu reduzieren, das Programm auf 3 µC aufzuteilen. Bei dem Display (2 x 16 Zeichen) kann man verschiedenen Moduse, LED-Helligkeit, Motorgeschwindikheit und weitere Einstellungen vornehmen. Der dafür zuständige µC gibt dann parallel die 'Ergebnisse' als digitale Signale an die zwei anderen µC weiter.
Hier ein Foto der Displayplatine :
Die RGB LEDs werden mittels PWM angesteuert. Das bedeutet, dass ich dort bereits alle Counter und PWM- Kanäle eines µC benötige. Auf den 'LED-µC' habe ich also die gesamten Moduse programmiert (fade, mit Musik, Standalone,...).
LED-Platine:
Und die Musik-Platine:
Die LED-Schaltung arbeitet unabhängig von der Motorschaltung, außer wenn das ganze musikgesteuert ist.
Die Motorschaltung arbeit mit 2 L6208 und die Motoren arbeiten auch mit Beschleunigungs- und Bremsrampen.
Diese Software unterscheidet die verschiedenen Moduse nicht, außer den Musik-Modus und die Motorgeschwindigkeit.
Motorplatine:
Hier ein Foto der Displayplatine :
Die RGB LEDs werden mittels PWM angesteuert. Das bedeutet, dass ich dort bereits alle Counter und PWM- Kanäle eines µC benötige. Auf den 'LED-µC' habe ich also die gesamten Moduse programmiert (fade, mit Musik, Standalone,...).
LED-Platine:
Und die Musik-Platine:
Die LED-Schaltung arbeitet unabhängig von der Motorschaltung, außer wenn das ganze musikgesteuert ist.
Die Motorschaltung arbeit mit 2 L6208 und die Motoren arbeiten auch mit Beschleunigungs- und Bremsrampen.
Diese Software unterscheidet die verschiedenen Moduse nicht, außer den Musik-Modus und die Motorgeschwindigkeit.
Motorplatine:
Wie gesagt, das wäre mein Konzept gewesen - Du hast halt Deins umgesetzt (und sicherlich ordentlich Erfahrung gesammelt).
Man könnte auch darüber nachdenken, die einzelnen Objekte (Lampe, Motor) auf ein System wie DMX auszulegen, aber mit sowas hab ich mich auch noch nicht beschäftigt.
Da an die PWM-Frequenz ja keine Anforderungen gestellt werden, kann man das auch in Software realisieren - Dino hatte das mit seinem Zauberstab AFAIR so gemacht (sehr lesenswerter Thread)
Man könnte auch darüber nachdenken, die einzelnen Objekte (Lampe, Motor) auf ein System wie DMX auszulegen, aber mit sowas hab ich mich auch noch nicht beschäftigt.
Da an die PWM-Frequenz ja keine Anforderungen gestellt werden, kann man das auch in Software realisieren - Dino hatte das mit seinem Zauberstab AFAIR so gemacht (sehr lesenswerter Thread)
Hi,
nettes Projekt. Ich hatte jetzt beim Titel "Moving Head" an einen mit DMX-Eingang gedacht
Naja. Ist also eher einer mit eigenen Programmen die dann ablaufen (frei oder musikgesteuert).
Trotzdem schon recht mächtiges Projekt für den Anfang. Das ganze mechanische muß ja auch soweit passen.
Im ersten Moment hätte ich jetzt gedacht ...
1. Mega8 : Display, Bedienelemente, DMX
2. Mega8 : Motorsteuerung
3. Mega8 : Restkram (LEDs, ...)
wobei man das bischen PWM auch noch auf den ersten oder zweiten hätte packen können.
Aber schon nicht schlecht. Respekt.
Gruß
Dino
nettes Projekt. Ich hatte jetzt beim Titel "Moving Head" an einen mit DMX-Eingang gedacht
Naja. Ist also eher einer mit eigenen Programmen die dann ablaufen (frei oder musikgesteuert).
Trotzdem schon recht mächtiges Projekt für den Anfang. Das ganze mechanische muß ja auch soweit passen.
Im ersten Moment hätte ich jetzt gedacht ...
1. Mega8 : Display, Bedienelemente, DMX
2. Mega8 : Motorsteuerung
3. Mega8 : Restkram (LEDs, ...)
wobei man das bischen PWM auch noch auf den ersten oder zweiten hätte packen können.
Aber schon nicht schlecht. Respekt.
Gruß
Dino
Im Prinzip wäre das ähnlich meinem Vorschlag. Bei mir wäre es dann auf 'ne DMX-Lampe und'n DMX-2-Achs-Motor rausgelaufen, und auf'n DMX-Sender (ob der nun Standalone oder als Brücke zwischen PC und dem Rest läuft...).
Ich habe das DMX-Protokoll so verstanden:
Die 88µs entsprechen 2Bytes mit "8N2"@250kBaud, da alle Bits 0 sind ist das ein "falsch übertragenes/empfangenes" Byte. Ich hab mich da jetzt noch nicht reingekniet - aber eventuell kkönnte man die beiden Bytes trotzdem Empfangen, wobei der UART dann einen "Frame Error" signalisiert (wäre für die Slaves das Signal, das ein neues Telegramm folgt).
Diese "falschen Bytes" kann man mit der UART-Hardware selbst nicht senden, also in Software 88µs Low halten, dann High setzen. Dann den UART aufschalten (ist im Idle high), und dann (wenn insgesamt die 8µs rum sind) das Start- und die Kanalbytes als "normale" UART-Bytes senden.
Letztendlich hat man also 512 Kanäle ("Adressen"), mit jeweils einem Byte (also Auflösung 256).
Das Durchschleifen der Bytes (inklusive Break und Mark) entsricht einer Parallelschaltung bzw einem Bus, an dem alle Empfänger abzweigen.
(Elektrisch muß das Signal ab einer gewissen Länge/Empfängerzahl sicher "aufgefrischt" werden, ggf auch wegen Reflektionen terminiert.).
Wenn ein Empfänger mehrere Bytes (mehr als 256 Zustände) braucht, muß er halt auf mehrere Adressen reagieren. Wenn man die Lampe also als 3x8Bit RGB auslegt, wären das 3 Kanäle (Adressen), wenn man die Motoren als 2x8Bit X/Y auslegt, wären das 2 Adressen.
Klar kann man das in einen hinreichend potenten Controller implementieren (der dann eben auf die 5 Adressen reagiert), aber wenn man Lampe und Motor(en) auf getrennten (ggf kleineren) Controllern realisiert, ist der Code überschaubarer, und ausserdem kann man zB. den Code der Lampe direkt in weitere Controller flashen, die dann quasi als "fester Kopf" leuchten könnten. Oder den Motor-Code auf irgendwelche anderen beweglichen Objekte. Dem Controller müssen dann nur die jeweiligen Adressen zugeordnet werden. Ließe sich also schön erweitern
Hmm... 250kBaud sind natürlich schon 'ne Hausnummer... ein Byte (8+3Bits) entspräche ca 350 Takten@8MHz Controllertakt - sollte man also straff programmieren.
Ob's in Bascom da was fertiges gibt, weiß ich nicht - unter Assembler sollte das sicher machbar sein...
Sind natürlich alles nur Ideen - generell gilt: je gründlicher man am Anfang ein Konzept konstruiert, umso einfacher hat man es später bei der Implementierung und Wartung/Erweiterung/Wiederverwertung des Codes. Insbesondere, wenn man das Ganze in sinnige einzelne Module zerlegt hat, die Eigenständig lauffähig sind.
Daumenhoch.
LotadaC
Ich habe das DMX-Protokoll so verstanden:
- Ein Telegramm beginnt mit "Break" (88µs Low) und "Mark after Break" (mindestens 8µs High).
- Es folgt ein Startbyte mit dem Wert "0", übertragen mit "8N2"@250kBaud
- Danach kommen (bis zu) 512 Bytes ("8N2"@250kBaud), die jetzt einfach den 512 Kanälen entsprechen.
Die 88µs entsprechen 2Bytes mit "8N2"@250kBaud, da alle Bits 0 sind ist das ein "falsch übertragenes/empfangenes" Byte. Ich hab mich da jetzt noch nicht reingekniet - aber eventuell kkönnte man die beiden Bytes trotzdem Empfangen, wobei der UART dann einen "Frame Error" signalisiert (wäre für die Slaves das Signal, das ein neues Telegramm folgt).
Diese "falschen Bytes" kann man mit der UART-Hardware selbst nicht senden, also in Software 88µs Low halten, dann High setzen. Dann den UART aufschalten (ist im Idle high), und dann (wenn insgesamt die 8µs rum sind) das Start- und die Kanalbytes als "normale" UART-Bytes senden.
Letztendlich hat man also 512 Kanäle ("Adressen"), mit jeweils einem Byte (also Auflösung 256).
Das Durchschleifen der Bytes (inklusive Break und Mark) entsricht einer Parallelschaltung bzw einem Bus, an dem alle Empfänger abzweigen.
(Elektrisch muß das Signal ab einer gewissen Länge/Empfängerzahl sicher "aufgefrischt" werden, ggf auch wegen Reflektionen terminiert.).
Wenn ein Empfänger mehrere Bytes (mehr als 256 Zustände) braucht, muß er halt auf mehrere Adressen reagieren. Wenn man die Lampe also als 3x8Bit RGB auslegt, wären das 3 Kanäle (Adressen), wenn man die Motoren als 2x8Bit X/Y auslegt, wären das 2 Adressen.
Klar kann man das in einen hinreichend potenten Controller implementieren (der dann eben auf die 5 Adressen reagiert), aber wenn man Lampe und Motor(en) auf getrennten (ggf kleineren) Controllern realisiert, ist der Code überschaubarer, und ausserdem kann man zB. den Code der Lampe direkt in weitere Controller flashen, die dann quasi als "fester Kopf" leuchten könnten. Oder den Motor-Code auf irgendwelche anderen beweglichen Objekte. Dem Controller müssen dann nur die jeweiligen Adressen zugeordnet werden. Ließe sich also schön erweitern
Hmm... 250kBaud sind natürlich schon 'ne Hausnummer... ein Byte (8+3Bits) entspräche ca 350 Takten@8MHz Controllertakt - sollte man also straff programmieren.
Ob's in Bascom da was fertiges gibt, weiß ich nicht - unter Assembler sollte das sicher machbar sein...
Sind natürlich alles nur Ideen - generell gilt: je gründlicher man am Anfang ein Konzept konstruiert, umso einfacher hat man es später bei der Implementierung und Wartung/Erweiterung/Wiederverwertung des Codes. Insbesondere, wenn man das Ganze in sinnige einzelne Module zerlegt hat, die Eigenständig lauffähig sind.
Daumenhoch.
LotadaC
Hi LotadaC,
soweit ist das Protokoll richtig interpretiert.
Diese 88µs Break werden allerdings sinnigerweise über einen Timer erkannt der bei jedem Byte zurückgesetzt wird. Bei dem Break läuft er dann über und setzt die Startadresse wieder auf 0. So habe ich es damals mal in einem Programm gesehen. Da hing ein Interrupt-Pin parallel mit am UART-Eingang dran.
Gruß
Dino
soweit ist das Protokoll richtig interpretiert.
Diese 88µs Break werden allerdings sinnigerweise über einen Timer erkannt der bei jedem Byte zurückgesetzt wird. Bei dem Break läuft er dann über und setzt die Startadresse wieder auf 0. So habe ich es damals mal in einem Programm gesehen. Da hing ein Interrupt-Pin parallel mit am UART-Eingang dran.
Gruß
Dino
Hmm...
Müßte sich nicht auch was mit PCINT und UART an demselben Pin machen lassen? Mal Datenblätter durchforsten...
Edit: Der Mega48/88/168 hat z.B. 'n PCINT auf dem RxD. So wie ich die Overriding Signals for Alternate Functions verstehe, sollten sich UART-Recieve und PCINT gleichzeitig nutzen lassen/nicht in die Quere kommen. Der ist zwar nicht auf fallende Flanken konfigurierbar sondern triggert bei jeder Flanke, aber bei jedem Startbit würde er sicher auslösen, also mindestens einmal pro Byte.
Hat irgendjemand Zeit/Lust/Hardware, das mal zu testen? (also ob der PCINT am RXD triggert)
Müßte sich nicht auch was mit PCINT und UART an demselben Pin machen lassen? Mal Datenblätter durchforsten...
Edit: Der Mega48/88/168 hat z.B. 'n PCINT auf dem RxD. So wie ich die Overriding Signals for Alternate Functions verstehe, sollten sich UART-Recieve und PCINT gleichzeitig nutzen lassen/nicht in die Quere kommen. Der ist zwar nicht auf fallende Flanken konfigurierbar sondern triggert bei jeder Flanke, aber bei jedem Startbit würde er sicher auslösen, also mindestens einmal pro Byte.
Hat irgendjemand Zeit/Lust/Hardware, das mal zu testen? (also ob der PCINT am RXD triggert)
Zuletzt bearbeitet:
CodeBox Assembler
/* * UartPcint.asm * * Created: 22.08.2015 21:20:00 * Author: LotadaC * * Test zur gleichzeitigen Verwendung des RxD als PCINT * * D0=RxD=PCINT16-Pin (PCINT 2 Register) * D1=TxD=Echo * D2 toggelt in der PCINT2-ISR */ .org 0x0000 rjmp reset ;*****PCINT2-ISR***** .org PCI2addr sbi PIND, PIND2 ;toggle D2 reti ;*******RxD-ISR****** .org URXCaddr lds R16, UDR0 sts UDR0, R16 ;Echo Data Reti ;******Init********** reset: ;**D2** sbi DDRD, DDD2 ;D2 ist Ausgang (erstmal "Low") ;**UART0** ldi R16, 51 sts UBRR0L, R16 ;9600Baud ldi R16, (1<<RXCIE0)|(1<<RXEN0)|(1<<TXEN0) sts UCSR0B, R16 ;Rx und Tx aktiviert, Rx-IRQ scharf, 8N1 ;**PCINT** ldi R16, (1<<PCINT16) sts PCMSK2, R16 ;D0 löst PCINT 2 aus ldi R16, (1<<PCIE2) sts PCICR, R16 ;PCINT-2-IRQ scharf sei ;Interrupts scharf loop: rjmp loop ;dudeldidum
