Forum: Mikrocontroller und Digitale Elektronik Kleiner ARM (16bit reicht): womit anfangen?


von Christoph Söllner (Gast)


Lesenswert?

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

von Robert Teufel (Gast)


Lesenswert?

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

von smartie (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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

von mmerten (Gast)


Lesenswert?

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.

von Christoph Söllner (Gast)


Lesenswert?

@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

von Stefan Kleinwort (Gast)


Lesenswert?

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

von mmerten (Gast)


Lesenswert?

@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 ;)

von Christoph Söllner (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

@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

von Mathias (Gast)


Lesenswert?

Ich benutze auch den Keil.. zweifelsohne der beste compiler bzw. ide die
ich kenne.. gibt auch eine demoversion dafür..

von Christoph Söllner (Gast)


Lesenswert?

@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

von Olaf (Gast)


Lesenswert?

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

von mmerten (Gast)


Lesenswert?

@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 ;)

von Christoph Söllner (Gast)


Lesenswert?

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.

von hans dieter (Gast)


Lesenswert?

Mal ne frage am Rande: Mit welcher Programmiersprache hast du angefangen
zu programmieren - generell PC, MAC, µC ...?

von Christoph Söllner (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

@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

von gerhard (Gast)


Lesenswert?

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

von moin (Gast)


Lesenswert?

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

von Christoph Söllner (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.