Hi *, nachdem ich nun mit dem MegaAVR an meine Grenzen gestoßen bin, 16MHz reichen nämlich nicht aus, um DMX zu empfangen und meine ISRs zu bearbeiten, möchte ich nun mit einem ARM und einigen wenigen mehr MHz alles erschlagen. Könnt ihr mehr helfen: Ich suche einen kleinen ARM, mit C-IDE und möglichst einfachem Programmer, Hersteller egal, billig; - 1 U(S)ART - 1 IIC - mindestens 3 Timer - 50MHz - 16bit reichen, 32 wären natürlich besser ^^ - 5V (?) - >30k FLASH - >1k RAM Habt ihr da einen Vorschlag, was für eine Kiste ich da am besten hernehme und wo ich die kaufen kann? Danke, Christoph
Folgende Optionen: Von Philips: LPC2131 LPC2141 LPC2103 alle haben 32k FLash und 8k SRAM von Atmel: SAM7S32 SAM7S321 diesselben Speicher alle haben die features die du suchst ausgenommen 5V. Es gibt nur eine lahme Kruecke in 5V von ST, ein alter Automotive ARM Micro, der jetzt eine Wiederbelebung erfaehrt als General Purpose Micro. Gruss, Robert
die 3,3V sind nicht wirklich ein Problem. Die Ausgänge des AT91SAM kann man als open drain schalten und mit nem externen pullup nach 5V auch 5V Peripherie steuern, die Eingänge sind 5V tolerant.
16 oder 32 Bit nützen nur dann etwas, wenn man auch mindestens 50% der CPU-Zeit mit 16- oder 32Bit Rechnen verbraucht. Das Hauptproblem bei den AVRs sind die fehlenden Interruptprioritäten. Deshalb kommet es oft dazu, daß unwichtigere Interrutps die wichtigen Interrupts blockieren und diese verloren gehen. Und das sogar, wenn die durchschnittliche CPU-Last nur bei 10% liegt. Wichtig wäre also eher ein MC mit Interruptprioritäten, z.B. die 8051-Familie. Dabei sind diese auch sehr schnell (Silabs bis 100MIPS), was man aber wirklich fast nie braucht. Ich nehme gerne die Atmel-Typen, z.B. AT89C51ED2 (4 Interruptprioritäten). Peter
Nur 1 UART also nur 1 DMX Universe da langweilt sich doch auch ein AVR schon bei 8 MHz ;) Wenn die Leistung nicht reicht, sollte man evtl. mal seinen Programmablauf neu überdenken.
@mmerten Nun ja, das stimmt nicht. USART: 250000 Hertz (250kbps) * 10bits, dann gibts nen Interrupt ==> 16000000 / 25000 = alle durchschnittlich 640 ASM Instruktionen kommt der USART Interrupt. Jetzt benutze ich einen C-Compiler, weil das bequemer geht, der hat für 16bit-Variablen einen Haufen Makros, also viele Jumps â 4 Instruktionen Es laufen noch zwei Timer, von denen einer das wichtigste überhaupt ist, weil er die Zündspannung für die Triacs generiert; In der Usart ISR verarbeite ich 8 Kanäle. T1 steht am Anfang auf 1FF und wird runtergezählt, da ich beide Halbwellen über einen Timer erledige. Und je länger der timer läuft, desto ungenauer kommt der Interrupt. Man siehts am Oszi, dass wenn die Lampe ganz dunkel sein soll (TimerWert = 002) zittert der Zündimpuls immerhin um mindestens 500ys, was bei Glühlampen deutlichst sichtbar ist als flackern. Bei Trafolampen gehts, weil die träge sind. Trotzdem ist das so suboptimal. @peter: Gibts da ne C IDE für? außer dem AVR-Studio? möglichst mit SPI Programmer ohne JTAG? Christoph
Hi Christoph, dass der ATmega mit einem DMX-Dimmer an der Leistungsgrenze sein soll, kann ich mir nicht vorstellen. Vielleicht kannst Du Deine Interrupts noch etwas optimieren? Auch wenn Jörg Wunsch das Kreuz machen wird: versuch doch mal die Option -mint8 im Compileraufruf. Damit werden viele Berechnungen nur noch mit 8 Bit gemacht. Du solltest aber vorsichtig mit Library-Funktionen sein, die verlassen sich auf die "normale" gcc-Arbeitsweise. Aber bei einem Dimmer wirst Du wohl nicht viele Library-Aufrufe brauchen. Die fehlenden IR-Prioritäten sind sicher ein Nachteil des ATmega. Per Software lässt sich das aber ganz gut reparieren. Gruß, Stefan
@christoph Wenn schon dann richtig bei DMX512 11 Bit (1 Srart-, 8 Daten- und 2 Stop-Bits) entspricht alle 44 µs ein RX Interrupt. Im RX Interrupt muß doch nix weiter passieren als BREAK und Startcode Auswertung, sowie Abspeicherung der DMX-Daten. Die Berechnung der Zünddaten kann ja dann extern erfolgen. Diese müssen ja nur alle 10 ms berechnet werden, oder sogar nur alle 20 ms wenn ich absolut symetrische Ansteuerung haben will. Auch bei 8 Kanälen ist der AVR da bei weitem noch nicht ausgelastet ;)
Ich benutze den CVAVR, habs aber auch schon auf gcc portiert, hat nichts genützt. Selbst wenn ich die Register nicht mehr sichere und nur noch auf den General Purpose Registern arbeite, zittert der Zündimpuls grausam hin und her. Was eben die normalen Dimmer für nen Vorteil haben, ist, dass sie über DIP Schalter eine Startadresse praktisch immer an einem Port haben. Ich habe dafür 8x 16Bit Variblen, weil ich 8 völlig verschiedene (oder gleiche) Kanäle brauche. Und der USART INT kommt eben zu oft, und der Timer verliert mit steigender Zeit eben an Präzision, zumal die Timer ISR auch etwas umfangreicher ist. Ergo muss hier ein schnellerer Prozessor her... Christoph
@Christoph http://www.wickenhaeuser.de/ Die Demo geht bis 8kB. Ich selber benutze den Keil, aber der ist teuer. Beim AVR könnte Atmel die Probleme drastisch entschärfen, wenn die UART- und I2C-Interrupts beim Eintritt automatisch ihr Interrupt-Enable-Bit löschen würden, damit sie quasi simuliert mit niedrigerer Priorität laufen. Dann ergäbe sich für die anderen Interrupts nur das sei(); als zusätzliche Verzögerung, was verschmerzbar wäre. Das gleiche Problem, wie Du habe ich nämlich auch oft. Der Timer soll hochgenau mit wenig Jitter laufen, aber UART und I2C müssen auch ab und zu bedient werden. Das ist dann immer wieder ein zeitraubendes Gewurschtel, den UART-Interrupt genau zu analysieren, welche Sachen in die Main-Loop ausgelagert werden können, ohne aber Daten zu verlieren oder die Datenkonsistenz (alte/neue Daten). Peter
Ich benutze auch den Keil.. zweifelsohne der beste compiler bzw. ide die ich kenne.. gibt auch eine demoversion dafür..
@mmerten: auch nicht richtig. Erstmal kommt alle 20ms EXTINT0; Sinuskurve Start. Es läuft T0 an, um zu 3ms verzögern, da der INT immer zu früh kommt, was an der NDG-Detektion liegt. Ist T0 abgelaufen, schaltet er sich aus und T1 an. T1 läuft schnell, der INT kommt alle 1s/(0.01s*256) = 0,0000390625s oder auch 30yS, weil ich ja jedesmal prüfen muss, ob da schon ein Wert der Zündhelligkeit entspricht. Ist der Zündzähler von 1FF auf 0 runter, schaltet sich T1 aus und wartet auf den nächsten Sinus Start. Und dann nimm noch nen USART dazu, der alle 44ys kommt, und the shit hits the fan ^^ Christoph
Hm..also es tut mir ja wirklich weh das schon wieder mal schreiben zu muessen, aber schau dir mal einen R8C an. Der kommt mit 16bit Variablen klar, der hat priorisierte Interrupts und er hat jede Menge Timerkram gleich eingebaut. Natuerlich darfst du auch gerne einen Arm nehmen wenn dich das gluecklich macht, scheint mir aber stark uebertrieben. Olaf
@christoph schon mal drüber nachgedacht immer den kompletten dmx-frame (alle 512 Kanäle) zu speichern? Dann kannst du beliebige Kanäle auswerten, ebenso sind doch bei 8 Kanälen nur max. 8 Timer 1 Compare Int innerhalb von 10 ms nötig. Selbst mit 12 oder 16 Kanälen geht das mit nem AVR oder auch 8051 noch recht problemlos ;)
Ja, hab ich sogar probiert, aber dann müsste ich das ganze mit einem Array lösen und die Array-Routinen des C-Compilers sind ähnlich groß, es hatte damit sogar noch schlechter funktioniert als so wie es jetzt läuft.
Mal ne frage am Rande: Mit welcher Programmiersprache hast du angefangen zu programmieren - generell PC, MAC, µC ...?
Puh, das wäre wohl Turbo Pascal gewesen (5.0), dann Delphi, C, C++, Visual C, PHP, ASP, SQL, Python, DTML, TAL. Assembler kam mal irgendwann dazwischen, aber da ich viel Wert auf Mensch-Maschine-Schnittstellen lege, hab ich das wieder aufgegeben, weil das ein- fach zu lange dauert sonst, hauptsächlich die LCD- Routinen (man bringe mal ein float als Kommazahl aufs LCD... viel Spaß, der C-Compiler verbraucht dafür 4K Code). Ich bin ja der Ansicht, dass in Zeiten immer leistunsfähigerer MCUs Probleme der Software grundsätzlich in Hardware erschlagen wer- den können. Christoph
@Christoph "Ich bin ja der Ansicht, dass in Zeiten immer leistunsfähigerer MCUs Probleme der Software grundsätzlich in Hardware erschlagen wer- den können." Das ist ein Trugschluß ! Man kann ein Programm so schreiben, daß es ein 8Bit-8051 bei 12Mhz spielend schafft. Und man kann es aber auch so schreiben, daß sich ein 64Bit-Pentium bei 4000MHz die Zähne dran ausbeißt. Programmieren ist die Kunst, den goldenen Mittelweg zu finden, zwischen möglichst wenig Hardwareanforderungen einerseits und möglichst wenig Programmentwicklungszeit andererseits. Der Zusammenhang ist aber stark nichtlinear, d.h. eine drastische Erhöhung auf der einen Seite ergibt nur eine unwesentliche Einsparung auf der anderen. Wenn der UART-Interrupt alle 44µs kommt und Du aber einen Jitter von 500µs hast, dann liegts definitv nicht an den fehlenden Interruptprioritäten, sondern da ist etwas faul am Programmablauf. Wo ich das Problem mit den Prioritäten hatte, mußte der Jitter kleiner 8µs sein. Peter
hallo christoph, ich kann peter's aussage nur bestätigen. meiner abschätzung nach sollte das für den avr kein problem sein. ich setze einen atmega128 in eine projekte ein dalaufen folgende funktionen: uart0: 38400bd uart1: 9600bd spi-interface mit 4 slaves 20 adc-kanäle mit sehr geringer wandelzeit (100µs) und das ganze läuft ohen nennenswerte probleme. und wie auch schon erwähnt: interrupt-freigabe in der isr hilft gruss gerhard
Hallo, kann man die Probleme nicht umgehen, indem man die Aufgaben auf zwei Controller aufteilt die per SPI oder Parallel (u.ä.) miteinander kommunizieren? Vielleicht ist das ja nur eine Schnapsidee ;-) Gruß moin
Doch, das mache ich jetzt auch. Nur einen kleinen Mega8 mit den ganzen Displaytexten, der über TWI einen 20MHz getakteten tiny24 (so er denn mal lieferbar sein wird) beschickt. Dann steuert jeder tiny genau einen Kanal und gut is. Das sollte dann jitterfrei funktionieren, vor al- lem, wenn nur bei jeder Änderung Daten übertragen werden. Und dann sind Last-Teil und Steuerung dafür auf einer Platine und man kann eine Art Blade-Dimmer daraus bauen, und der kann dann auch flexibler verkabelt werden. Aber wie gesagt, ich kriege noch nirgendwo einen Tiny24 her, vielleicht gibts den erst nächstes Jahr. Christoph
Bitte 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.