Hallo, ich habe eine eignen kleine Firmware für einen DMX betriebenen LED-Scheinwerfer geschrieben. Dabei gibt es 2 verschiedene Arten von Betriebsmodi. 1. Die einfachen steuern einen Wert(sichtbar durch den PWM-RGB-LED-Pegel) direkt an und spiegeln so den eingestellten DMX-Wert 1:1 wieder. 2. Die minimal komplexeren (nehmen wir als Bsp. Strobo oder Pulse) erhalten ebenfalls einen DMX-Wert, welcher jedoch nur als Maßeinheit der Periode dient. Daraufhin wird durch einen interrupt/counter intern der Modus gefahren, bis ein geänderter DMX-Wert anliegt. Der ungewollte Effekt, der nun bei 2. auftritt, ist dass aufgrund der minimal unterschielichen Quarze der 16 Scheinwerfer ein syncrones Strobo oder Pulsen ziemlich schnell auseinanderdriftet. Die Problematik liegt nun im Verständniss der Interaktion einzelner Interrupts untereinander mittels globaler Variablen. Lösungsansatz/konkretes Bsp: Was alle MCs ja gemein haben ist der DMX-Bus. Daher wäre ein Ansatz diesen zur Taktbestimmung für alle MCs zu nutzen. Da dieser Interrupt jedoch mit 250000 kBaud bei 8Mhz MCU-Takt schnell an seine Grenzen stößt, möchte ich nicht die komplette "Pulse-Routine" da mit zu hängen. Also müsste ich dort nur einen Counter zählen lassen (z.B. immer wenn DMX-Adresse 1 erkannt wurde) und damit mein Timing in der anderen Interrupt-Routine "messen". Die Logik sagt mir jedoch, dass ich so etwas wie "if(counterFromDMX == 10)" in keinem anderen Interrupt abfragen darf, als in jenem in dem ich diesen auch incrementiere, da ich sonst bei viel Pech häufig die "10" überspringe (weil die ISR des DMX-Auswertens häufiger "reinspringt" als jene vom Pulse) Ich bin mir nicht ganz sicher, ob ich die Problematik gut in Worte fassen konnte!? Falls doch, kennt ihr eine Lösung für dieses? Gr4üße Oekel
@D a v i d K. (oekel) >2. Die minimal komplexeren (nehmen wir als Bsp. Strobo oder Pulse) >erhalten ebenfalls einen DMX-Wert, welcher jedoch nur als Maßeinheit der >Periode dient. Daraufhin wird durch einen interrupt/counter intern der >Modus gefahren, bis ein geänderter DMX-Wert anliegt. Hmm. >Der ungewollte Effekt, der nun bei 2. auftritt, ist dass aufgrund der >minimal unterschielichen Quarze der 16 Scheinwerfer ein syncrones Strobo >oder Pulsen ziemlich schnell auseinanderdriftet. Dann hast du aber sehr komische Quarze. Die haben um die 100ppm Toleranz. Über welche Zeiten reden wir denn hier? Zum Vergleich 100pm heißt, dass ein 1 Hz Takt in 1 / 100ppm = 10.000s um genau 1s verschoben ist. Wenn man aber nur 1x pro Sekunde synchronisiert, ist es nur 1/10.000tel oder 100us. >Die Problematik liegt nun im Verständniss der Interaktion einzelner >Interrupts untereinander mittels globaler Variablen. Du hast eher ein Softwareproblem. >Was alle MCs ja gemein haben ist der DMX-Bus. Daher wäre ein Ansatz >diesen zur Taktbestimmung für alle MCs zu nutzen. Logisch. Nutze den periodischen Break zum Synchronisieren. >Da dieser Interrupt jedoch mit 250000 kBaud bei 8Mhz MCU-Takt schnell an >seine Grenzen stößt, Meisten stoßen eher die Programierer an Grenzen und nicht die Hardware, nur dass man der Hardware die Schuld in die Schuhe schiebt ;-) >möchte ich nicht die komplette "Pulse-Routine" da mit zu hängen. Weil sie wahrscheinlich arg blockierend geschrieben ist. Am besten noch mit Delays, nicht wahr? >Also müsste ich dort nur einen Counter zählen lassen (z.B. immer wenn >DMX-Adresse 1 erkannt wurde) und damit mein Timing in der anderen >Interrupt-Routine "messen". Nö. Man setzt einen Zähler mittels Timer auf. Der wird beim BREAK synchronisiert. Der Rest hängt dann an diesem Zähler/ISR. Damit bekommt man SEHR genau Sachen hin. Und wenn man weiß wie, dreht die CPU nebenbei noch Däumchen. >Die Logik sagt mir jedoch, dass ich so etwas wie "if(counterFromDMX == >10)" in keinem anderen Interrupt abfragen darf, als in jenem in dem ich >diesen auch incrementiere, da ich sonst bei viel Pech häufig die "10" >überspringe (weil die ISR des DMX-Auswertens häufiger "reinspringt" als >jene vom Pulse) Dann ist dein Konzept falsch. >Ich bin mir nicht ganz sicher, ob ich die Problematik gut in Worte >fassen konnte!? Es geht so. >Falls doch, kennt ihr eine Lösung für dieses? Das Zauberwort lautet nichtblockierende Programmierung, siehe Multitasking. Mal zum Vergleich. DMX512 läuft mit 250kBaud, 8N2. Pro Byte hat man bei 16 MHz CPU-Takt 704 Takte. Eine mittelmäßige ISR braucht vielleicht 150 Takte, bleiben ~450 bzw. ~80% für anderen Kram. Mehr als ausreichend.
Falk Brunner schrieb: >>Die Problematik liegt nun im Verständniss der Interaktion einzelner >>Interrupts untereinander mittels globaler Variablen. > > Du hast eher ein Softwareproblem. Ja, das sehe ich ein. > > Weil sie wahrscheinlich arg blockierend geschrieben ist. Am besten noch > mit Delays, nicht wahr? Nein!! In meiner ganzen Firmware arbeite ich nirgends mit solchen(außer in der Init). > Nö. Man setzt einen Zähler mittels Timer auf. Der wird beim BREAK > synchronisiert. Der Rest hängt dann an diesem Zähler/ISR. Damit bekommt > man SEHR genau Sachen hin. Und wenn man weiß wie, dreht die CPU nebenbei > noch Däumchen. So denke ist auch, es kann sogar sehr gut sein, dass meine CPU noch lange nicht ausgelastet ist und "nebenbei" Däumchen dreht. Da ich jedoch keinen objektiven Messwert fürs Däumchendrehen habe, bin ich bislang davon ausgegangen, dass ich das Limit errreicht habe, wenn der Lichteffekt ins Stocken gerät (z.B. Strobo mit sehr hoher Frequenz und ganz leichten Aussetzern) Kann natürlich auch an einem schlechtem stück Programmcode liegen, den ich bisher nicht ermitteln konnte. :( >>Die Logik sagt mir jedoch, dass ich so etwas wie "if(counterFromDMX == >>10)" in keinem anderen Interrupt abfragen darf, als in jenem in dem ich >>diesen auch incrementiere, da ich sonst bei viel Pech häufig die "10" >>überspringe (weil die ISR des DMX-Auswertens häufiger "reinspringt" als >>jene vom Pulse) > > Dann ist dein Konzept falsch. Kannst du das genauer erläutern? ISRs melden doch eine Event an (z.B. RS232oder ein Counterüberlauf) Die Abarbeitung der Events läuft meines Wissens dann nach FIFO (wie auch sonst?) Nun ist es doch nicht unwahrscheinlich, dass der ISR der RS232 Schnittstelle 2x oder häufiger aufgerufen wird als einer der ISRs die durch nen Counterüberlauf generiert werden. Ergo ist der "counterFromDMX", welcher im RS232 inkrementiert wird doch nicht transparent für andere ISRs. (Bsp: 0..1..2..3.....5..6........9) > Das Zauberwort lautet nichtblockierende Programmierung, siehe > Multitasking. Gelesen und als "schon gewusst" abgehakt. Grüße Oekel
Es wieder holt sich ständig. Ist ein Gerät über längere Zeit an, so läuft es weg. Ob das jetzt, in einer Sekunde oder nach 5 Tagen der Fall ist, ist dann egal, wenn der Fall: "5 Tage" vorkommen kann. Schon das synchrone Einschalten geht für gewöhnlich in die Hose. Die menschlichen Augen sind erstaunlich schnell und können zeitliche Unterschiede weit unter einer Zehntel Sekunde "sehen". Sollen also mehrere Mikroprozessoren synchron laufen, so musst Du explizit dafür Sorge tragen dass sie es auch tun. Vor allem lass' dich von den ppms nicht täuschen, es gibt deren zwei, bei einem Quarz. Einer sagt Dir wie viel er daneben liegen darf und der andere sagt etwas über seine Wanderlust aus. Geh' mal davon aus, dass die beiden schon sehr viel von einem gewissen Herren Murphy gehört haben und sich nicht gegenseitig aufheben.
@ D a v i d K. (oekel) >So denke ist auch, es kann sogar sehr gut sein, dass meine CPU noch >lange nicht ausgelastet ist und "nebenbei" Däumchen dreht. Da ich jedoch >keinen objektiven Messwert fürs Däumchendrehen habe, bin ich bislang >davon ausgegangen, dass ich das Limit errreicht habe, wenn der >Lichteffekt ins Stocken gerät (z.B. Strobo mit sehr hoher Frequenz und >ganz leichten Aussetzern) Das muss man messen. Z.B. mit einem Testpin, das man vor einem Programmblock einschaltet und danach wieder aus. Mit dem Multimeter kann man den Mittelwert messen, welcher die mittlere Auslastung angibt. Mit dem Oszi sieht man Maximalwerte der Pulsreite. >Kann natürlich auch an einem schlechtem stück Programmcode liegen, den >ich bisher nicht ermitteln konnte. :( Das ist meistens die Ursache. >Kannst du das genauer erläutern? ISRs melden doch eine Event an (z.B. >RS232oder ein Counterüberlauf) Die Abarbeitung der Events läuft meines >Wissens dann nach FIFO (wie auch sonst?) Im Prinzip ja. >Nun ist es doch nicht unwahrscheinlich, dass der ISR der RS232 >Schnittstelle 2x oder häufiger aufgerufen wird als einer der ISRs die >durch nen Counterüberlauf generiert werden. Kann man so allgemein nicht sagen. Poste Qelltext als Anhang. >Ergo ist der "counterFromDMX", welcher im RS232 inkrementiert wird doch >nicht transparent für andere ISRs. (Bsp: 0..1..2..3.....5..6........9) Kenn ich deine Quelltext? Eher nicht. Siehe Netiquette. >> Das Zauberwort lautet nichtblockierende Programmierung, siehe >> Multitasking. >Gelesen und als "schon gewusst" abgehakt. Auch als "schon erfolgreich angewendet"? Wie es der Zufall will, habe ich auch gerade ein kleines DMX-Projekt am laufen. Ein DMX-Recorder. Und er ist schon recht weit vorangeschritten, eigentlich (tm) kann man wiedergeben und aufnehmen. Bei maximaler DMX-Kanalzahl und Wiederholfrequenz sind das ~22kB/s. Die werden über eine SD-Karte gelesen bzw. dort drauf gespeichert, über einen FIFO im externen SRAM (ATmega64 mit 64kB XMEM). Und weißt du was, die MITTLERE Prozessorauslaustung liegt bei ca. 15% (CPU Takt 16 MHz). Ein anderes Projekt vor einigen Monaten war ein DMX-Empfänger der, 24x 10 Bit PWM-Kanäle in Software erzeugt. Gemessen habe ich dort nicht direkt, aber die MITTLERE Auslastung ist ähnlich, nur in Spitzenzeiten kommt man an ca. 95% ran, wenn PWM und DMX sich überschneiden. Beitrag "Re: DMX Steuerung 24 Kanal" Also, ich meine zu wissen, was man mit so einem AVR und DMX alles machen kann.
Falk Brunner schrieb: > @ D a v i d K. (oekel) > dem Oszi sieht man Maximalwerte der Pulsreite. Besitze ich leider nicht. > Kann man so allgemein nicht sagen. Poste Qelltext als Anhang. Ich habe vor die Arbeit der ersten 40 Chip-Kopien bezahlen zu lassen, bevor ich es als OpenSource frei gebe. Ich habe auch schon einige Interessenten, dessen google-Fähigkeit ich nicht unterschätzen möchte. Außerdem ist der Code bislang noch recht dürftig dokumentiert. >>Ergo ist der "counterFromDMX", welcher im RS232 inkrementiert wird doch >>nicht transparent für andere ISRs. (Bsp: 0..1..2..3.....5..6........9) > > Kenn ich deine Quelltext? Eher nicht. Siehe Netiquette. "counterFromDMX" ist ausgedacht und existiert nirgends außer hier im Forum. (Sollte nur ein Bsp. sein). Stoße ich sonst noch wo an die Netiquette? (ist mir schon wichtig) >>> Das Zauberwort lautet nichtblockierende Programmierung, siehe >>> Multitasking. > >>Gelesen und als "schon gewusst" abgehakt. > > Auch als "schon erfolgreich angewendet"? QED? > > Wie es der Zufall will, habe ich auch gerade ein kleines DMX-Projekt am > laufen. Ein DMX-Recorder. [...]. MITTLERE > Prozessorauslaustung liegt bei ca. 15% (CPU Takt 16 MHz).[...] > Also, ich meine zu wissen, was man mit so einem AVR und DMX alles machen > kann. Das macht Hoffnung, dass es bei mir ähnlich werden könnte. PWMs sind alle 3 HW. Wenn man es also in der Entwurftheorie betrachtet, dreht die CPU wirklich dauerhaft Däumchen. Ein Codereview lässt mich zu ähnlicher Folgerung kommen. Praxistest mit dem Pin steht noch an. Grüße Oekel
GANZ vergessen: Ich arbeite mit dem internen Quarz, da der "Umbau" später bei Fremden PlugNPlay der PIC-MCU werden soll.
D a v i d K. schrieb: > GANZ vergessen: Ich arbeite mit dem internen Quarz, da der "Umbau" > später bei Fremden PlugNPlay der PIC-MCU werden soll. Internes Quarz - das gibt es? Oder ist das eher ein RC-Oszillator?
Markus schrieb: > Internes Quarz - das gibt es? Oder ist das eher ein RC-Oszillator? Nein und Ja ;) -->RC-Oszillator
@ D a v i d K. (oekel) >Ich habe vor die Arbeit der ersten 40 Chip-Kopien bezahlen zu lassen, >bevor ich es als OpenSource frei gebe. Ich habe auch schon einige >Interessenten, dessen google-Fähigkeit ich nicht unterschätzen möchte. >Außerdem ist der Code bislang noch recht dürftig dokumentiert. Gut, aber dann leg mal wenigstens ein paar Zahlen auf den Tisch. Über welche Zeiten reden wir denn? 1ms? Welche Sequenzen sollen wie lange erzeugt werden? >Das macht Hoffnung, dass es bei mir ähnlich werden könnte. PWMs sind >alle 3 HW. Wenn man es also in der Entwurftheorie betrachtet, dreht die >CPU wirklich dauerhaft Däumchen. Ein Codereview lässt mich zu ähnlicher >Folgerung kommen. >GANZ vergessen: Ich arbeite mit dem internen Quarz, da der "Umbau" >später bei Fremden PlugNPlay der PIC-MCU werden soll. Es gibt keinen internen Quarz, nur internen RC-Oszillator. Dass damit DMX512 stabil läuft ist eher Glückssache, auch mit Kalibrierung. Ich würde mal schnell auf einen ECHTEN Quarz bzw. Quarzoszillator wechseln! Und wenn es nur zum Testen sein sollte. Einen RC-Oszillator bekommt man auf dem Labortisch vielleicht auf 0,5% stabil, macht 360% Phasendrift in 200s ~3,5 min Ein 0815 Quarz hat weniger als 100ppm, macht 360% Phasendrift in 10.000s ~ 3h.
Vielleicht noch mal ein einfacher Ansatz für eine Synchronisation, auch mit RC Osziallator. 1.) na nutzt einen Timer im CTC-Modus als Zeitbasis. Bei 8 MHz CPU Takt kommt man z.B. mit Timer 1 und Teilfaktor 8000 Takte auf 1 kHz, damit kann man sehr gut per Software Zeitsteuerungen ableiten und noch viele DInge mehr. 2.) Im UART RX Interrupt setzt man bei jedem erkannten BREAK den Timer für CTC auf 4000, also die Mitte. War der Timer etwas zu schnell, wird er ein wenig zurück gesetzt. War er etwas zu langsam, wird er vor gestellt. Damit wird die Zeitbasis bei jedem Break synchronisiert. Tyisch läuft DMX ja so mit 10-100 Hz, sprich alle 10-100ms wird synchronsisiert. In der Zeit darf der lokale Oszillator maximal um 1/2 ms weggelaufen sein. Das sind 0,5-5% Toleranz. Das wird eng mit einem RC-Oszillator, vor allem wenn die Temperatur mal etwas mehr schwankt.
DMX ohne Quarz oder Resonator halte ich für puren Leichtsinn. Man vergibt sich erheblich an Zuverlässigkeit ohne merkbare Kosteneinsparung. Mit Quarz würde auch eine Synchronisierung alle Minute dicke ausreichen, ein Gleichlauf auf 10µs genau wäre kein Problem.
@ Peter Dannegger (peda) >DMX ohne Quarz oder Resonator halte ich für puren Leichtsinn. Man >vergibt sich erheblich an Zuverlässigkeit ohne merkbare >Kosteneinsparung. Eben. Die 20 Cent machen keinen arm, die Probleme ohne Quarz dagegen VIEL Stress. >Mit Quarz würde auch eine Synchronisierung alle Minute dicke ausreichen, >ein Gleichlauf auf 10µs genau wäre kein Problem. Warum einfach, wenn es auch umständlich geht? :-0
Falk Brunner schrieb: > Warum einfach, wenn es auch umständlich geht? :-0 Die Argumente Pro-Quarz leuchten mir schon ein und ich habe auch jede Menge passende Quarze+22pF hier liegen. Das Problem ist nur die Weitergabe. Der typische LJ (es sollen sich jetzt nicht die auf den Schlipps getreten fühlen, die mehr auf dem Kasten haben) macht sein Ding am Pult und ist zudem max in der Lage die Lampe zu wechseln. Genauso einfach ist (zum Glück) der Wechsel des gesockelten PIC in diesen Scheinwerfern. Fordere ich ihn nun noch zum Ausbau der Platine und zum verlöten der 3 Bauteile auf, wird er schon argwöhnisch. (So meine spezielle Erfahrung) Sicher kann ich in meinen eigenen den Quarz einbauen und testen, doch dann fahre ich noch eine weitere Schiene. Lieber wäre mir aus diesem Grunde der "umständliche" Weg mit der Gewissheit, dass es PlugNPlay bleibt. Mit kontreten Zahlen kann ich nicht dienen, da ich noch mich selbst etwas schwer tue mit der Größe der Variable. Mein Pulse setzt direkt auf dem Masterdimer auf, der mit uint8_t, also 255 Werten arbeitet. Gewollt ist eine Kennlinie, die nun diese 255 Schritte in 0,5-6sec dimmt. Also von 0 auf 255 (sowie dessen Invertierung). Ergo alle 31250-375000 Takte, wenn ich mich nicht verrechnet habe. Grüße Oekel PS: Strobo wäre natürlich um einiges schneller, doch die Erfahrung beim Testen hat gezeigt, dass ein asynchroner Strobo gar nicht so schlecht ist. Die empfundenen Zeiten halbieren sich beim Phasenversatz um 180°. Ähnliches will man ja sogar, wenn auf einer Bühne ein rand()-Srobe über 20 Scheinwerfer läuft. Vielleicht korrigiere ich dies, wenn ich den Pulse im Griff habe ;)
@ D a v i d K. (oekel) >und ist zudem max in der Lage die Lampe zu wechseln. Genauso einfach ist >(zum Glück) der Wechsel des gesockelten PIC in diesen Scheinwerfern. >Fordere ich ihn nun noch zum Ausbau der Platine und zum verlöten der 3 >Bauteile auf, wird er schon argwöhnisch. (So meine spezielle Erfahrung) Sicher. Aber dennoch würde ich über eine Lösung MIT Quarz(oszillator) nachdenken. - Adpterplatine mit PIC + Quarz, wird auf den Sochel gesteckt - SMD-Quarzoszillator mit 7x5 oder kleineren Gehäuse aud den PIC kleben und am Takteingang anschließen, kann ebenfall als Single Chip gewechselt werden. >Sicher kann ich in meinen eigenen den Quarz einbauen und testen, doch >dann fahre ich noch eine weitere Schiene. Lieber wäre mir aus diesem >Grunde der "umständliche" Weg mit der Gewissheit, dass es PlugNPlay >bleibt. >Mit kontreten Zahlen kann ich nicht dienen, da ich noch mich selbst >etwas schwer tue mit der Größe der Variable. Mein Pulse setzt direkt auf >dem Masterdimer auf, der mit uint8_t, also 255 Werten arbeitet. >Gewollt ist eine Kennlinie, die nun diese 255 Schritte in 0,5-6sec >dimmt. >Also von 0 auf 255 (sowie dessen Invertierung). >Ergo alle 31250-375000 Takte, wenn ich mich nicht verrechnet habe. Welche Takte? Dein PIC läuft mit 8 MHz. >PS: Strobo wäre natürlich um einiges schneller, doch die Erfahrung beim >Testen hat gezeigt, dass ein asynchroner Strobo gar nicht so schlecht >ist. Die empfundenen Zeiten halbieren sich beim Phasenversatz um 180°. >Ähnliches will man ja sogar, wenn auf einer Bühne ein rand()-Srobe über >20 Scheinwerfer läuft. Der ist aber definiert vom Master gesteuert und nicht durch schlechte Zeitgeber als Nebeneffekt.
Angehängte Dateien:
-
20130625_140152.jpg
160 KB
Falk Brunner schrieb: > - Adpterplatine mit PIC + Quarz, wird auf den Sochel gesteckt Wir sprechen hier jedoch noch von Low-Budget Scheinwerfern. Die kosten gerade Mal 30€/Stück. Meine Aufwertung mit alternativer Firmware muss also in einem sehr kleinen Rahmen bleiben. Sicher habe ist bereits festgestellt, dass diese/meine Platine noch in einigen teureren Versionen verbaut wurde und ich später die Kompatibilitätsliste einfach erweitern kann. (Dann auch vielleicht mit einem Adapter für 2-3 Euro extra) Doch noch muss es wirklich günstig bleiben. Kleines Bsp.: (siehe Anhang) Habe die DIP9 mit einem DIP4 erweitert, damit ich mit 2^9 zumindest die 511 DMX-Kanäle erreiche. (Bei der original FW ist bereits bei 2^6 schluss :( Für den Umbau habe ich 12min/Stück gebraucht. Für meine eigene Sammlung sicherlich ok, als genereller Umbau jedoch zu "teuer". Da bräuchte ich einen Jemanden, der mir dass in 2min macht ;) (Anhand des schiefen DIP8, an den ich meinen 4er geklebt habe, sieht man schon in welcher Qualitätsstufe das ganze spielt) Fällt beim original nicht so ins Auge, wie nun, wo der erweiterte Schlitz drinn ist; Das Loch ist auf 1/10mm sauber ausgesägt und rechtwinklich. Dennoch wirkt es optisch nicht sehr hübst....) >>Ähnliches will man ja sogar, wenn auf einer Bühne ein rand()-Srobe über >>20 Scheinwerfer läuft. > > Der ist aber definiert vom Master gesteuert und nicht durch schlechte > Zeitgeber als Nebeneffekt. Klar, dafür habe ich ja auch eine andere Funktion. Wollte nur zum Ausdruck bringen, dass es dort nicht stört. Langfristig aber auch behoben werden soll. Grüße Oekel
@ D a v i d K. (oekel) >Wir sprechen hier jedoch noch von Low-Budget Scheinwerfern. Die kosten >gerade Mal 30€/Stück. Meine Aufwertung mit alternativer Firmware muss >also in einem sehr kleinen Rahmen bleiben. Also lohnt sich die ganze Sache kommerziell keine Sekunde, denn bei derartig niedrigen Preisen liegen die Gewinnmargen irgendwo bei 1 Euro oder so. Und wenn man nicht 10000 Stück im Jahr oder mehr verkauft, ist es ökonomischer Unsinn. >genereller Umbau jedoch zu "teuer". Da bräuchte ich einen Jemanden, der >mir dass in 2min macht ;) Merkst du was? Mit den Chinesen zu konkurrieren ist eher sinnlos.
Falk Brunner schrieb: > Merkst du was? Mit den Chinesen zu konkurrieren ist eher sinnlos. Ich glaube an der Stelle reden wir aneinander vorbei. zu 90% mache den Kram natürlich für mich selber und weil es dieser Dimension (Sowohl Preis als auch Baugröße einfach nichts vergleichbares gibt). Die restlichen 10% sind Anfragen von Freunden und sehr entfernte Bekannte über 10 Ecken. Freunde bekommen diese natürlich kostenlos, alle anderen möchte ich soweit "ausbeuten", dass ich den Programmieradapter wieder raus bekomme ;) Also bereichern möchte ich mich daran wirklich nicht. Ein weiterer Punkt, warum ich den Quelltext noch nicht veröffentlichen möchte ist, dass mir einfach zu viel in Foren wie diesem hier kopiert wird. Habe ich auch nichts dagegen, nur wenn es mein Code ist soll er doch zumindest aufgeräumt und gut leserlich erscheinen. In diesem Sinne "Back to Topic", fall dies noch möglich ist, denn ich habe immer noch nicht recht verstanden, wie die Sync des CTC mit 4000 funktionieren soll. Ist CTC denn überhaupt überschreibbar. Dachte diesen könnte man max resetten. Oder reden wir hier nicht über einen Systemcounter? Grüße Oekel
@ D a v i d K. (oekel) >habe immer noch nicht recht verstanden, wie die Sync des CTC mit 4000 >funktionieren soll. Ist CTC denn überhaupt überschreibbar. Der Timer ist immer beschreibbar. > Dachte diesen könnte man max resetten. Nein. > Oder reden wir hier nicht über einen Systemcounter? Doch. Timer1 z.B.
Falk Brunner schrieb: > Der Timer ist immer beschreibbar. > Doch. Timer1 z.B. Danke, dem war ich mir nicht bewusst. Das schafft natürlich völlig neue Möglichkeiten ;) Grüße Oekel
D a v i d K. schrieb: > Ist CTC denn überhaupt überschreibbar. Wenns um konkrete Register geht, müßte man erstmal den konkreten PIC wissen. Auch für die Drift des RC-Oszillators ist der genaue Typ wichtig.
@ D a v i d K. (oekel) >> Der Timer ist immer beschreibbar. >> Doch. Timer1 z.B. >Danke, dem war ich mir nicht bewusst. Das schafft natürlich völlig neue >Möglichkeiten ;) Ahhhh, du hast ja einen PIC! ICh war gedanklich beim AVR! Möglicherweise ist der PIC aber sehr ähnlich. Genaues weiß das Datenblatt deines Vertrauens.
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.