Hallo Gemeinde, ich habe hier ein Projekt und finde im Moment leider im Netz noch hier eine Antwort auf meine Fragen, evtl suche ich aber auch falsch, oder die verwendeten Teile sind einfach schon zu alt. Ich habe vor mir eine fertige Platine, welche 2 Steppermotoren über 2 ULN2803 Darlington ansteuert, von daher kann ich die Gegebenheiten nicht ändern. Die Stepper sind unipolar, 5 Adrig und wie gesagt alles schon fix und fertig auf einer "kommerziellen" Platine. Die Frequenz des Quarz ist 16.000. Es fehlt ein 40Pin 8051/8052 Prozessor, welches dem ganzen Leben einhaucht. Den will ich nun programmieren. Ich habe ein kleines Testprogramm geschrieben welches mal einen der Motoren antreibt. über einen 10-fach DIPschalter, der gerade zum testen eingebaut wurde kann man im Moment die Geschwindigkeit umschalten. Der Motor dreht, Voll- und Halbschritt, CW und CCW - kein Problem. Wenn der Motor "schnell" und "mittelschnell" dreht, ist eigentlich alles ok, nur wenn ich die Geschwindigkeit drossel das er ca. 3u/min macht, ruckelt der Motor. Also er dreht schon noch, aber halt Schritt für Schritt für Schritt. Da der Motor eine Spiegelscheibe für eine Lichtprojektion antreibt, sieht man leider das "ruckeln". Ich weiß das man von halbschritt noch in Viertelschritten oder Achtelschritt antreiben kann, mit einem KontrollerIC, also choppen, aber geht denn das in der Konstellation mit einem 8052er uC + ULN2803, der hat kein PWM, und ich kann leider an der Platine nix ändern. Würde das funktionieren, wenn man die Frequenz rausfindet, und dann quasi den Port an/aus macht, so das man doch Viertelschritt machen kann ? Ist das überhaupt mit dem Darlington machbar ? Was ich auch nicht verstehe, es sind immer 2 Input Ports am Darlington parallel verbunden, dafür reichen meine Kenntnisse nicht, wozu das , mehr Leistung ? Leider habe ich auch noch nie die Platine mit der original Cpu in Aktion gesehen, sonst könnte ich wenigstens sehen, wie langsam es beim Original überhaupt geht. Mein Ziel ist es wenn möglich , so langsam wie möglich, so ruckelfrei wie möglich zu fahren ohne Änderung der Hardware nur reine Software. Bin für jeden Hinweis dankbar. Gruß Andre
Hi, Schrittmotoren sind halt Schrittmotoren. Also Schritt => Ruckeln. Mit deiner Hardware kenne ich mich nicht aus aber der Weg die Schrittanzahl zu erhöhen beziehungsweise den Schrittwinkel zu verringern klingt erstmal nach "The Way to go". Ich könnte mir noch ein Mechanisches Dämpfungsystem vorstellen um das Bewegungsverhalten zu glätten.
Da mußt Du halt die PWM in Software selbst machen. Da Du es lansam willst, sollte das auf dem 8051 kein Problem sein. Stichwort: Timer-Interrupt. > es sind immer 2 Input Ports am Darlington parallel verbunden Alter Trick wenn die 500mA/Kanal des 2803 nicht reichen. Einfache Lösung, aber nicht unbedingt gut.
Andre Thomas schrieb: > Was ich auch nicht verstehe, es sind immer 2 Input Ports am Darlington > parallel verbunden, dafür reichen meine Kenntnisse nicht, wozu das , > mehr Leistung ? Ja. Andre Thomas schrieb: > Würde das funktionieren, wenn man die Frequenz rausfindet, und dann > quasi den Port an/aus macht, so das man doch Viertelschritt machen kann > ? Ist das überhaupt mit dem Darlington machbar ? Nein. Auch Mikroschritt führt nicht zu vollkommen rundem Lauf (dagegen geht das Rastmoment des Schrittmotors, nur variable reluctance Motoren ohne Rastmoment laufen bei Mikroschritt sauber, aber du hast Hybridmotore mit Permanentmagnet). Es ist halt der falsche Antrieb.
Andre Thomas schrieb: > geht denn das in der Konstellation mit einem 8052er uC + ULN2803, Nein, das geht nicht direkt. Ein 8051 kann den ULN28xx nicht ansteuern. Seine '1'-Pegel sind zu 'weak'. Entweder nimmst Du zusätzlich Pullup-Widerstände mit der Konsequenz, daß beim Einschalten alle Ausgänge aktiv sind, schaltest einen Puffer dazwischen oder nimmst einfach einen pinkompatiblen AVR.
m.n. schrieb: > Entweder nimmst Du zusätzlich Pullup-Widerstände mit der Konsequenz, daß > beim Einschalten alle Ausgänge aktiv sind Die Pullups gibt es, da ist eine Widerstandsleiste an den Leitungen zw uC und Darlington. Ich denke das es im Original auch so war. Ich brauche im Übrigen keinen perfekten runden Lauf, also wenn man es mit 3 uMin schafft, im 16tel Schritt, wäre das Ergebnis gabsolut akzeptabel. Nur wenn es so ruckelt wie jetzt im Halbschritt ist es noch zu unsauber. Das heisst ich könnte mit den Pullups einen Microschritt (8tel/16tel) doch realisieren ?
Hallo MaWin, > Auch Mikroschritt führt nicht zu vollkommen rundem Lauf (dagegen geht > das Rastmoment des Schrittmotors, nur variable reluctance Motoren ohne > Rastmoment laufen bei Mikroschritt sauber, aber du hast Hybridmotore mit > Permanentmagnet). > > Es ist halt der falsche Antrieb. Da stimme ich dir nur bedingt zu. Wenn die Motoren bipolar wären oder wenigstens 6 Adern hätten, könnte man sehr wohl mit einer vernünftigen Ansteuerung einen sehr viel ruhigeren Lauf erzielen. So wird das aber nichts. Aber da der OP die Elektronik ohnehin nicht ändern will, bleiben nur mechanische Maßnahmen. Also Motor nicht ohne Last betreiben, Lastmasse möglichst schwingungsarm ankoppeln, ggf. zusätzliche Dämper verwenden. Und unbedingt Halbschritt statt Vollschritt verwenden. Falls möglich, problematische Drehzahlbereiche vollständig vermeiden oder schnell durchfahren. Mit freundlichen Grüßen Thorsten Ostermann
Thorsten Ostermann schrieb: > Aber da der OP die Elektronik ohnehin nicht ändern will, bleiben nur > mechanische Maßnahmen Ja, leider. Also "kann" und "will". Die Schaltung muss so bleiben wie sie ist, das ist leider Teil des Projekts. Der Chip muss quasi vom einen ins andere Gerät ohne Platinenumbau bzw Änderungen am original-Layout. Leider kenne ich wie schon erwähnt nicht das Original, es kann sein, dass der Hersteller sich gar nicht auf sowas wie langsames drehen eingelassen hat und wie Thorsten Ostermann sagt, den problematischen Bereich gar nicht zulässt. Ich für meinen Teil, muss eben das Projekt so gut wie möglich ausführen. Ich habe alle Funktionen des Originals nachgebildet, plus noch ein paar Goodies mehr, wenn ich nun noch langsames Drehen ohne allzu starkes Ruckeln ( 16er statt 1/2 Auflösung ) hinbekomme, dann ists perfekt. Nochmal zurück: m.n. schrieb: > Nein, das geht nicht direkt. Ein 8051 kann den ULN28xx nicht ansteuern. > Seine '1'-Pegel sind zu 'weak'. > Entweder nimmst Du zusätzlich Pullup-Widerstände Das wäre vorhanden! das heisst hier kann ich den "Softwarehebel" ansetzen mit einer Erfolgsaussicht ? m.n. schrieb: > daß > beim Einschalten alle Ausgänge aktiv sind, Das ist ok, ich schalte die beim init wieder aus, würde ja nur den Motor kurz "blockieren" wenn alle an sind - dann ausschalten und in "Nullstellung" bringen kommt dann eh. m.n. schrieb: > schaltest einen Puffer > dazwischen oder nimmst einfach einen pinkompatiblen AVR. Puffer , nein. Wäre eine Änderung im Layout der Platine. Pinkompatibler AVR, ok , aber ist das nicht auch "nur" ein 8051 Klon, mit den gleichen Features, oder hat kann der PWM auf 8 Pin? Sorry, da reicht wiedereinmal meine Erfahrung nicht aus. Ich bekomme heute abend den abgerauchten originalchip, mal sehen was es ist. Laut Aussage ist es ein Atmel AT89C51, also ein 8051 uC.
Hallo Andre, > Ich für meinen Teil, muss eben das Projekt so gut wie möglich ausführen. > Ich habe alle Funktionen des Originals nachgebildet, plus noch ein paar > Goodies mehr, wenn ich nun noch langsames Drehen ohne allzu starkes > Ruckeln ( 16er statt 1/2 Auflösung ) hinbekomme, dann ists perfekt. Mikroschritt ohne Stromregelung wird nicht gehen. Ich habe das zumindest noch nie gesehen. Dafür müsste ja auch die Versorgungsspannung deutlich höher sein als die Motornennspannung, und dann wären wir wieder bei den nicht gewünschten Änderungen an der Schaltung. Mit freundlichen Grüßen Thorsten Ostermann
Thorsten Ostermann schrieb: > Dafür müsste ja auch die Versorgungsspannung deutlich > höher sein als die Motornennspannung, Tja, ich vermute auch, da die ganze Platine mit 5V versorgt wird, wird das nix. Die Motoren haben eine Nennspannung von 5V. Mehr kann ich leider auch nicht dazu sagen. Es gibt zwar noch Lampenbauteile mit 24V auf der Platine, aber da führt nix in die Stromkreise der Steuerung, ausser ein Schaltkreis mit nem Triac zum an/ausmachen der Hauptlampe über den 8051.
Andre Thomas schrieb: > Pinkompatibler AVR, ok , aber ist das nicht auch "nur" ein 8051 Klon, > mit den gleichen Features, oder hat kann der PWM auf 8 Pin? Sorry, da > reicht wiedereinmal meine Erfahrung nicht aus. Ein erster AVR war der AT90S8515, der Atmel einen leichteren Einstieg als 8051-Ersatz ermöglichte - bei mir zumindest ;-). Der pinkompatible Nachfoger ist der ATmega8515, der mit 16 MHz laufen kann und mindestens 10 x schneller ist als ein original 8051. Mit der höheren Leistung könnte man PWM per Software realisieren. Ein größerer Typ wäre der ATmega162, der mehr RAM, Flash, Timer +++ hat.
Habe gestern die abgebrannte original CPU bekommen... Es ist ein Atmel 89c51 - somit ist die Idee das es an der "neuen" schwächeren 89C52 CPU liegen könnte auch dahin. Sollte jemand doch noch einen Tipp haben, wie man mit der Kombination 8052 / ULN2803 / Unipolarer 5-adriger Stepper und Pullup widerständen auf den Ports mehr wie Halbschritte hinbekommt, bitte hier posten. Grüße Andre
Wie sehr abgebrannt ist die? Vielleicht kann man das Programm doch auslesen.
Also so abgebrannt, das in meinem Testboard immer andere LED´s an sind, bei jedem boot und die in der Platine gar nichts mehr macht. Vom Auslesen von CPU´s habe ich mal gar keine Ahnung.
Andre Thomas schrieb: > Sollte jemand doch noch einen Tipp haben, wie man mit der Kombination > 8052 / ULN2803 / Unipolarer 5-adriger Stepper und Pullup widerständen > auf den Ports mehr wie Halbschritte hinbekommt, bitte hier posten. Man könnte jeden Strang eines Motors per PWM steuern und damit bei langsamen Drehzahlen ein 'Überblenden' erreichen. Ein lineares 'Überblenden' wird wohl nicht funktionieren. Daher müßte man die sinnvolle Abstufung experimentell ermitteln. Voraussetzung dafür wären, einen AVR zu nehmen und die PWM-Routine am besten in Assembler auszuführen. Alles machbar, aber auch für Dich?
m.n. schrieb: > Voraussetzung dafür wären, einen AVR zu nehmen und die PWM-Routine am > besten in Assembler auszuführen. Gibt doch 8051 DIP40 mit Hardware PWM: http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en549557 Es ginge aber doch auch, eine kleine Adapterplatine zu machen und einen ARM SOIC zu nehmen, da geht Hardware PWM auch ohne Assembler.
Lothar schrieb: > Gibt doch 8051 DIP40 mit Hardware PWM: > > http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en549557 AVRs haben auch PWM, aber nicht 8-fach und zudem nicht an den notwendigen Pins. Lothar schrieb: > Es ginge aber doch auch, eine kleine Adapterplatine zu machen und einen > ARM SOIC zu nehmen, da geht Hardware PWM auch ohne Assembler. Hast Du denn nicht gelesen, was die ganze Zeit immer wieder betont wurde: die Hardware soll nicht verändert werden! Wenn doch, könnte man vernünftige Mikroschritt-Treiber mit brauchbaren Motoren nehmen, koste es, was es wolle.
Das Projekt sieht keine Änderung der Hardware vor. Die Platine ist auch tausendmal so hergestellt worden. Da ich den defekten iC vor mir habe und es ein 8051 ist, ist der jetzt verwendete 8052 schon besser. Jetzt gibt es 2 Möglichkeiten: die Hersteller waren hammerharte cracks, die es irgendwie mit der Hardware geschafft haben, dass sich der Motor ruckelfreier dreht, oder die haben es erst gar nicht versucht. Da der quartz sich nun auch noch als 8mhz herausstellt und nicht wie gedacht 16, wird's langsam klar, dass das leider mit dem langsamen drehen nichts wird. Die Motoren sind dazu dann auch noch "billig". Ich weiß jetzt auch noch , dass das Gerät den Spitznamen "racer" hat, was mich noch mehr davon überzeugt , dass es wohl nicht geht. Leider habe ich auch keinen Vergleich mit einer funktionierenden Version, interessieren würde es mich aber schon. Gruß Andre
>> Es ginge aber doch auch, eine kleine Adapterplatine zu machen und einen >> ARM SOIC zu nehmen, da geht Hardware PWM auch ohne Assembler. > > Hast Du denn nicht gelesen, was die ganze Zeit immer wieder betont > wurde: die Hardware soll nicht verändert werden! Ich meinte selbstverständlich eine Adapterplatine in den DIP40 Sockel. Es gibt auch ARM DIP aber nicht pinkompatibel zu 8051. ARM mit 8 Hardware PWM gibt es auch.
Ich bins wieder, das Projekt hat super funktioniert, jedoch nur bis die DMX Adresse von 1 auf 15 geändert wurde. Der Fehler liegt meiner Meinung nach am Programmierer ( also mir ), da ich kein Assembler aus dem FF behersche, ich bin eben nur in C soweit , das ich mir Programme schnitzen kann. Ich habe den Fehler, dass wenn ich die Startadresse auf DMX-Kanal 15 gehe, die Werte von Kanal 22 eingelesen werden. Und der 2. Kanal den ich noch brauche ist dann zw 23 und 24, klingt komisch, is aber so. Wenn beide Kanäle auf unterschiedliche Werte gestellt werden, nimmt er mal den , mal den ... Ich habe jetzt schon eine switch Schleife drin, die quasi solange DMX Empfang da ist, alles andere abschaltet , so das der 8052 Zeit hätte. Erst wenn das letzte Byte empfangen wird, wird alles andere wieder abgerufen, bis das nächste Datenpaket kommt. Ich habe dann mal Hennes DMX Code genommen, damit wurde es aber noch schlimmer. Also Empfang war da , nur noch weiter hinten in den Kanälen. Es scheint, als ob C, DMX und 8Mhz nicht zusammenpassen. Ich benutze KEIL uVision 4, es ist ein STC 8052 mit 8Mhz. Kann ich noch irgendwas am Compiler einstellen, das es mehr optimiert wird ? Ich habe testweise einen 16Mhz Quarz rein, damit gehts, aber die Hardware soll eigentlich so bleiben wie sie ist. Wenn nichts hilft muss es eben so sein. Hier mal der Empfangscode
1 | void serial0 (void) interrupt 4 |
2 | {
|
3 | static int rx_count; // signed!!! |
4 | static bit dmx_valid; // Startbit |
5 | static bit dmx_break; // Break |
6 | static unsigned char temp ; |
7 | |
8 | |
9 | temp = SBUF; |
10 | RI = 0; // Interrupt Flag |
11 | |
12 | |
13 | if (RB8 == 1){ |
14 | // Brauchbare Daten empfangen
|
15 | if (dmx_break == 1){ |
16 | if (dmx_valid == 0){ // 1. Byte nach break |
17 | if (temp == 0x00){ // Freigabe |
18 | dmx_valid = 1; |
19 | }
|
20 | else { // kein Startbit |
21 | dmx_break = 0; |
22 | }
|
23 | }
|
24 | else{ |
25 | rx_count++; |
26 | if (rx_count == CHANNELS){ // alle Kanäle empfangen? |
27 | dmx_break = 0; |
28 | step=0; // Pause |
29 | }
|
30 | else if (rx_count >= 0){ // Startadresse erreicht? |
31 | dmx_data[rx_count] = temp; |
32 | }
|
33 | }
|
34 | }
|
35 | }
|
36 | else{ |
37 | dmx_valid = 0; |
38 | dmx_break = 1; |
39 | rx_count = -addr; |
40 | }
|
41 | |
42 | |
43 | }
|
Bin für jeden Tipp dankbar. Gruß Andre
@Andre Thomas (andret) >Sollte jemand doch noch einen Tipp haben, wie man mit der Kombination >8052 / ULN2803 / Unipolarer 5-adriger Stepper und Pullup widerständen >auf den Ports mehr wie Halbschritte hinbekommt, bitte hier posten. Wurde doch schon genannt, mit Soft-PWM. Ich weiß nicht, wieviel CPU-Power so ein 8051 von Atmel wirklich hat, der originale 8051 hat einen /12 geteilten Maschinentakt, das wäre eine Katastrophe. Ich tippe mal dass der von Atmel bei /2 oder schlimmstenfalls /4 arbeitet. Einen DMX-Empfänger + 24 PWM Kanäle mit 100 Hz auf einem AVR gibt es hier. Beitrag "Re: DMX Steuerung 24 Kanal" Ob allerdings 100 Hz PWM für einen Schrittmotor reicht, glaube ich nicht, da braucht man eher 1-5 kHz. Muss man halt mal testen.
:
Bearbeitet durch User
Falk Brunner schrieb: > Ich weiß nicht, wieviel > CPU-Power so ein 8051 von Atmel wirklich hat, der originale 8051 hat > einen /12 geteilten Maschinentakt, das wäre eine Katastrophe. Ich tippe > mal dass der von Atmel bei /2 oder schlimmstenfalls /4 arbeitet. Es ist so schlimm: 1/12 Quarzfrequenz!
@ Route 66 (route_66)
>Es ist so schlimm: 1/12 Quarzfrequenz!
Damit läuft das Ding auf 666 kHz Maschinentakt. Damit DMX zu empfangen
ist wahrscheinlich bestenfalls mit Assembler möglich, zumindest für die
UART RX ISR. Und auch dann wird die CPU ordentlich ausgelastet sein. PWM
per Software darf man da getrost vergessen.
Ergo. Man MUSS an der Hardware was ändern. Wenigstens eine andere CPU,
besser ein Miniboard, wo auch gleich passende PWMs in Hardware mit
rauskommen.
Frage: Wer baut und vor allem wer KAUFT im Jahr 2015 noch so eine CPU?
Wenn es wenigstens ein moderner Single Cylce oder /2 Kern wäre, dann
könnte man es noch verstehen.
Es sind laut Datenblatt bei meiner verwendeten CPU /6 (8052) @Falk: Das ist eine Restauration, dabei ist wichtig, so nahe am Original zu bleiben. Es ist auch so, dass es mehrere geben wird, und wenn man nun anfängt alles umzubauen geht es in die falsche Richtung. Und es geht auch ein bisschen um den Ehrgeiz und Spass. Ich frage mich wie der Hersteller das geschafft hat, DMX bis Kanal 510 zuverlässig zu empfangen und dabei noch 2 Stepper zu drehen, und auch noch so, dass die Stepperposition dabei benutzt wird. Ich habe jetzt alles am laufen, nur eben mit dem Problem, das selbst wenn alles aus ist, DMX zuverlässig empfangen wird, aber mit diesem Kanal-versatz. Der wird nach hinten raus auch immer schlimmer, bei Adresse 100 ist man 30 Kanäle daneben. Also es wird empfangen und das auch immer gleich (schlecht). Mit dem ansteigenden Versatz. Ich frage mich aber gerade ob denn nicht evtl der sn75176 oder der Quarz was hat. Denn wie gesagt, ich schalte alles ab, also während des Empfangs gibt es im Superloop nix zu tun ausser einer if-Abfrage , if pause==1 dann nix, bzw warte auf Interrupt 4, wenn alles in der ISR erledigt wurde ( alle Kanäle empfangen, wird serieller Interrupt abgeschalten und die Motoren bedient, sind die 1nen Schritt in die Richtung wo sie hinsollen, wird serieller Interrupt wieder freigegeben und es geht von vorne los. Jedoch halt - schlecht. Wenn ich nun sagen kann, in Assembler gehts 50% schneller, dann wäre es ein Versuch wert, aber ich denke und da kann ich mich auch täuschen, das es max 10% sind. Das wird aber evtl nicht reichen.
:
Bearbeitet durch User
Andre Thomas schrieb: > es ist ein STC 8052 mit 8Mhz. Hallo! Habe gerade erst gelesen, dass es kein Atmel sondern ein TI ist. Der läuft standardmäßig mit 1/6 Quarz als Maschinentakt, kann aber auch auf 1/12 umgestellt werden für Kompatibilität. (standardmäßig: hängt vom core ab)
:
Bearbeitet durch User
@ Andre Thomas (andret) >Es sind laut Datenblatt bei meiner verwendeten CPU /6 (8052) Das rettet dich nicht. >Das ist eine Restauration, Das erklärt einiges ;-) > dabei ist wichtig, so nahe am Original zu >bleiben. Dann brauchst du auch keinen supersanften Rundlauf bei niedrigen Geschwindigkeiten. Denn das konnte das Original auch nicht. > Es ist auch so, dass es mehrere geben wird, und wenn man nun >anfängt alles umzubauen geht es in die falsche Richtung. Und es geht >auch ein bisschen um den Ehrgeiz und Spass. Ich frage mich wie der >Hersteller das geschafft hat, DMX bis Kanal 510 zuverlässig zu empfangen >und dabei noch 2 Stepper zu drehen, und auch noch so, dass die >Stepperposition dabei benutzt wird. In Assembler. Und mit Tricks. > Ich habe jetzt alles am laufen, nur >eben mit dem Problem, das selbst wenn alles aus ist, DMX zuverlässig >empfangen wird, Das glaube ich mal spontan nicht. Du GLAUBST dass das so ist. Du musst es aber NACHWEISEN. Dazu kann man einen Pin nutzen und immer am Start der ISR einschalten und am Ende ausschalten. Schau dir das auf dem Oszi an. Es wird dir nicht gefallen. Ich vermute, deine CPU verschluckt Interrupts, weil sie überlastet ist. DMX ist kein Kindergeburtstag mehr, die ISR Rate von ~25kHz muss die CPU erstmal schlucken. Und das bei 1,2MHz Maschinentakt! Das sind läppische 48 Takte / Byte! Hmmm. Jetzt wo ich drüber nachdenke. Wahrscheinlich läuft das OHNE Interrpts besser und performanter, wenn man das Ganze in einer Schleife per Polling betreibt und den Rest per Statemachine immer mal wieder bearbeitet. So wie bei Multitasking. >Ich frage mich aber gerade ob denn nicht evtl der sn75176 oder der Quarz >was hat. Nimm ein Oszi und schau nach. Ich glaube es eher nicht. > Denn wie gesagt, ich schalte alles ab, also während des >Empfangs gibt es im Superloop nix zu tun ausser einer if-Abfrage , if >pause==1 dann nix, bzw warte auf Interrupt 4, wenn alles in der ISR >erledigt wurde ( alle Kanäle empfangen, wird serieller Interrupt >abgeschalten und die Motoren bedient, Ob das so ein gutes Konzept ist? >Wenn ich nun sagen kann, in Assembler gehts 50% schneller, Dann NIMM Assembler! Hier ist einer der wenigen Fälle, wo er WIRKLICH SINNVOLL und NOTWENDIG ist! Zumal das Programm nicht sonderlich komplex ist, das kriegt man in ASM ohne Mühe hin. > dann wäre es >ein Versuch wert, aber ich denke und da kann ich mich auch täuschen, das >es max 10% sind. Das wird aber evtl nicht reichen. Mach die Messung mit dem Oszi wie oben beschrieben. Teste deinen C Code systematisch, sprich, gib die DMX-Daten mit steigender Adresse auf einen 8 Bit Port aus und schau, ob die Stabil abliegen oder wackeln. Wenn ja, ist den CPU überlastet.
Der ATMega8515/8535 ist bis auf den Reset Pin 100% pinkompatibel zum 8052, man muss also den Reset Pin 9 hochbiegen, hat dann aber die RISC CPU mit 6MHz und deutlich mehr Luft nach oben, was die Rechenleistung anbelangt. Ich habe das selber schon bei einem DMX LED Matrix Beamer gemacht, bei dem die Winbond 8051 abgeraucht war.
Falk Brunner schrieb: >>Es sind laut Datenblatt bei meiner verwendeten CPU /6 (8052) > > Das rettet dich nicht. Mist ... Falk Brunner schrieb: > Denn das konnte das Original auch nicht. Das weiß ich eben nicht, aber sagen wir mal 2 u/min waren sicher nicht drin. So langsam/schnell wie er jetzt dreht im Halbschritt ist ok. Falk Brunner schrieb: >> Ich habe jetzt alles am laufen, nur >>eben mit dem Problem, das selbst wenn alles aus ist, DMX zuverlässig >>empfangen wird, > > Das glaube ich mal spontan nicht. Du GLAUBST dass das so ist. Das ist "verschrieben", ich wollte schreiben DMX UNzuverlässig ist... und ja ich denke auch das es sich irgendwo verschluckt... sonst wären ja die 2 aufeinander folgenden Kanäle nicht um 1 von einander entfernt, d.h. er bekommt das Signal nicht zuverlässig aufeinanderfolgend. Falk Brunner schrieb: > Dann NIMM Assembler! Hier ist einer der wenigen Fälle, wo er WIRKLICH > SINNVOLL und NOTWENDIG ist! Zumal das Programm nicht sonderlich komplex > ist, das kriegt man in ASM ohne Mühe hin. Da meinte ich, dass ich es tatsächlich nicht weiß ob der Leistungszuwachs mit Assembler so groß ist, dass es geht. Und es wäre schön wenn ich das so mühelos könnte, aber Assembler ist so fremd für mich. Ich weiß nicht ob ich besser als mein Compiler bin. Falk Brunner schrieb: > Ob das so ein gutes Konzept ist? Mir ist diesmal nichts besseres eingefallen, es geht immer gleich schlecht, mit Interrupt, mit Timer fürs DMX, mit seriellem Interrupt und Timer für die Motoren, es ist immer das gleiche Ergebnis mit marginalen Verbesserungen. Ich dachte anfangs das der Superloop zu voll ist, bin von 40 Cycles ausgegangen, eine if(bit==1)-Schleife verbraucht keine 40, von daher dieser Ansatz. Bin natürlich für Vorschläge immer offen. Ein Oszi steht mir leider noch nicht zur Verfügung, aber ich glaub da ich viel in der Richtung noch machen werde, wird früher oder später einer hier neben mir stehen. Jetzt aber leider noch nicht. Gruß Andre
Andre Thomas schrieb: > Falk Brunner schrieb: >>>Es sind laut Datenblatt bei meiner verwendeten CPU /6 (8052) >> >> Das rettet dich nicht. > > Mist ... Gabs da nicht mal von Dallas den DS80C320, einen kompatiblen aber wesentlichen schnelleren 8052? Der konnte nicht nur einen höheren Takt, sondern teilte auch nicht so stark runter. Das müßte jetzt bei Maxim sein. MfG Klaus
UND LÄUFT JETZT WIE ES SOLL !!!! Andre Thomas schrieb: > Falk Brunner schrieb: >>>Es sind laut Datenblatt bei meiner verwendeten CPU /6 (8052) >> >> Das rettet dich nicht. > > Mist ... OHH DOCH ! Falk, das hat mich tatsächlich gerettet. Ich war nur so blöd im Programmer noch Kompatibilität 12T zu fahren - Einmal umgeschalten auf 6T + PCON wieder auf 0 und schwupps , das Ding geht bis Kanal 510 jetzt ... so wie es soll. Oh Gott sei dank, mal wieder ums Assembler gekommmen. Grüße Andre
Klaus schrieb: > Gabs da nicht mal von Dallas den DS80C320, einen kompatiblen aber > wesentlichen schnelleren 8052? Der konnte nicht nur einen höheren Takt, > sondern teilte auch nicht so stark runter. Das müßte jetzt bei Maxim > sein. Der hat zwar Quarz/4 Arbeitstakt, aber keinen internen Programmspeicher!
:
Bearbeitet durch User
Andre Thomas schrieb: > Falk, das hat mich tatsächlich gerettet. Ich war nur so blöd im > Programmer noch Kompatibilität 12T zu fahren - Einmal umgeschalten auf > 6T + PCON wieder auf 0 und schwupps , das Ding geht bis Kanal 510 jetzt > ... so wie es soll. > > Oh Gott sei dank, mal wieder ums Assembler gekommmen. Das hat mit Assembler nichts zu tun, Deine Baudrate war falsch, das ist alles. Finds auch lustig, daß hier gedacht wird, bei popeligen 3U/min ginge einem 8051 gleich die Puste aus. Da muß man wirklich sehr wenig Ahnung vom 8051 haben. Der Befelssatz ist super optimiert, damals haben die Leute noch wirklich mitgedacht.
:
Bearbeitet durch User
@ Peter Dannegger (peda) >Finds auch lustig, daß hier gedacht wird, bei popeligen 3U/min ginge >einem 8051 gleich die Puste aus. Lesen und Verstehen. Die 3U/min sind NICHT das Problem, sondern das Ruckeln bei dieser niedrigen Geschwindigkeit, welches durch Halb/Vollschrittbetrieb entsteht. Einen Mikroschrittbetrieb rein in Software kriegt man da kaum hin, bestenfalls mit Tricks > Da muß man wirklich sehr wenig Ahnung >vom 8051 haben. Der Befelssatz ist super optimiert, damals haben die >Leute noch wirklich mitgedacht. Aber bei einem Takteiler von /12 oder /6 ist man nicht wirklich auf der Höhe der Zeit. Selbst der uralte 6811 machte nur /4
Falk Brunner schrieb: > Einen Mikroschrittbetrieb rein in > Software kriegt man da kaum hin, bestenfalls mit Tricks Unterschätze mal den 8051 nicht. Andre Thomas schrieb: > Ich bins wieder, > das Projekt hat super funktioniert Wird also in Software sein, vermutlich im Timerinterrupt. Andre Thomas schrieb: > Die Frequenz des Quarz > ist 16.000. Andre Thomas schrieb: > es ist ein STC 8052 mit 8Mhz. Wenn man den Quarz ändert, ist klar, daß sich auch die Baudrate ändert. Daher muß man auf XTAL/6 setzen, damit es wieder stimmt. Man hätte aber auch den Baudratengenerator auf den anderen Wert setzen können.
Falk Brunner schrieb: > Aber bei einem Takteiler von /12 oder /6 ist man nicht wirklich auf der > Höhe der Zeit. Das stimmt. Aber ich muss die damaligen Entwickler auch loben, die hatten mehr Tricks und Kniffe auf Lager wie ich. Peter Dannegger schrieb: > Das hat mit Assembler nichts zu tun, Deine Baudrate war falsch, das ist > alles. Nein, die Baudrate war immer richtig 250.000 für DMX, die Cpu hatte einfach nur keine Zeit noch viel anders zu tun, als zu empfangen. Das hat sehr wohl mit Assembler zu tun, wenn ich nun nicht die Möglichkeit gehabt hätte, den Maschinenzyklus auf 6T hochzuschrauben, dank 2 Kernen (laut Hersteller-Datenblatt) sondern mit den originalen 12T eines Atmel 89C51 (und natürlich PCON=0x80, um die Richtige Baudrate zu haben), dann wäre ich wohl zu Assembler übergegangen, und hätte mächtig tricksen müssen um das aus einem 89C51 rauszuholen, so wie es der Hersteller damals gemacht hat. Glücklicherweise bin ich nochmal drumrumgekommen, da mich das Tage/Wochen gekostet hätte, da mir Assembler einfach nicht in Fleisch und Blut liegt. Falk Brunner schrieb: > Die 3U/min sind NICHT das Problem, sondern das > Ruckeln bei dieser niedrigen Geschwindigkeit Ganz genau so isses, das Ding dreh ich auch mit 1U/h, aber nicht sanft. Leider gibt es keinerlei Unterlagen oder ein Vergleichsgerät um mal zu sehen wie langsam es vom Hersteller aus ging. Könnte sein, dass die das einfach nicht implementiert hatten, könnte sein, dass die aber sich auch gesagt haben, es geht nicht anderst, Kunde soll damit zufrieden sein. Zu Beginn dieses Threats dachte ich noch das es mit SOFT-PWM oder rein mit Software besser geht als mit Halbschritt. Da die CPU aber mit seriellem Empfang schon gut ausgelastet ist, ist mir keine Möglichkeit bekannt wie man nun es doch hinbekommen kann, ohne zusätzlichen MotorIC. Es laufen ja auch noch andere Funktionen im Programm, die auch noch Rechenzeit brauchen, jetzt noch einen schnellen Interrupt dazu würde niemals gehen. Grüße Andre PS: Ich habe nun nochmal die Empfangsroutine von Henne genommen, die läuft bei hohen Adressierungen besser als meine andere. (Falls das hier mal jemand liest, der ähnliche Probleme hat.)
Kannst ja mal den Code als Anhang reinstellen, da ist bestimmt noch Optimierungspotential. Hast Du mal nen Link zum Datenblatt, ich finde keinen STC 8052.
Bei 8MHZ / 12 bleibt wirklich kaum Zeit zwischen 2 UART-Bytes (~26 Zyklen). Man könnte aber auch die AT89LP51 Serie nehmen, die teilt XTAL/1. http://www.digikey.de/product-detail/de/AT89LP51-20PU/AT89LP51-20PU-ND/2774081 Mit 20MHz Quarz sind dann 800 Zyklen Zeit.
:
Bearbeitet durch User
Peter Dannegger schrieb: > Kannst ja mal den Code als Anhang reinstellen, da ist bestimmt noch > Optimierungspotential. > > Hast Du mal nen Link zum Datenblatt, ich finde keinen STC 8052. Hier mal der Link zum Datenblatt: http://www.stcmicro.com/datasheet/STC89C51RC-RD-en.pdf Und gerne poste ich den Quelltext, bin über jede Optimierung froh. Und bin gerne bereit was dazuzulernen. Super. Hier isser im Anhang. Gruß Andre Huch das geht nicht im Anhang.
:
Bearbeitet durch User
Hier der Quelltext in C im Anhang. Bitte beachten, ich habe gerade gesehen, Zeile 292
1 | m2_gobo_shaker(gobo,(2)) ; //dmx_data[0]%10 |
sollte
1 | m2_gobo_shaker(gobo,(1)) ; //dmx_data[0]%10 |
heissen, bin da noch am debuggen gewesen. Dafür entschuldige ich mich. Und, ja die doppelte Klammer ist unnütz, zeigt mir aber das da was noch nicht ok ist.
:
Bearbeitet durch User
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.