Wird ARM der naechste "Volksprozessor"?

"Michael Krämer" <mike102de@yahoo.com> schrieb:

Gibt es eine brauchbare Hardwaredivision? Ein HC(S)12 kann z.B. 32/16
in 11 Takten.

Nein, nicht mal eine unbrauchbare. Der ARM7 hat überhaupt keinen
Click to expand...
danke für den Hinweis. Das ist ein weiterer Punkt für den HC(S)12(X).
Und sein großartiges Debuginterface.

Servus

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)
 
Rafael Deliano <Rafael_Deliano@t-online.de> wrote:

Erstens weil die Architektur langlebig und zweitens
weil sie für manuelle Programmierung geeignet ist.
Click to expand...
Interessehalber:
Was wäre deiner Meinung nach ein Assembler (uC) der nicht für manuelle
Programmierung geeignet ist?


Gruß,
Nick
--
Motor Modelle // Engine Models
http://www.motor-manufaktur.de
DIY-DRO -> YADRO <- Eigenbau-Digitalanzeige
 
Hi,

Und die schnellen 8051 Varianten von SiliconLabs (25-100MIPS) und von
Winbond (10 MIPS) sind zur Zeit auch recht beliebt für Neuentwicklungen.

Hab die dann nicht immer noch die Pferdefüße von 8Bit und min. 4Taktzyklen
pro Machinenzyklus?
Click to expand...
8 Bit reicht für viele Anwendungen völlig aus.
SiliconLabs: 1 Taktzyklus pro 1-Byte-Befehl, d.h. 100MIPS bei 100MHz
Winbond: 4 Taktzyklen pro 1-Byte-Befehl, d.h. 10 MIPS bei 40MHz

Gruss
Michael
 
"Michael Koch" <astroelectronic@t-online.de> schrieb im Newsbeitrag
news:dncmm0$nb6$01$1@news.t-online.com...
8 Bit reicht für viele Anwendungen völlig aus.
Click to expand...

Nicht fuer die heutige Generation der Skript-Kiddies.

Da muss erst ein lokaler WebServer her, auf den ein Browser
mit HTML und casacaded stylesheets zugreift, der eine XML
Quelle per SOAP uber den TCPIP-Stack vom WebServer abruft,
um durch eine 24 bit transparente Bitmap den Zustand von
einem PortPin wahlweise als rote LED oder gruene LED anzuzeigen.
Damit das schneller als 1 Hz blinkt, muss es ein 2GHz Rechner
sein, der tranportabel wird, so bald eine Plutoniumbatterie
drangeschnallt wird.
Das auf dem WebServer von Phyton-Skript aufgerufene Programm
das real den PortPin anfragt wird in Java geschrieben (weils
so schoen portabel ist), ruft ueber JNI ein C Programm auf
(weil Java keine Hardware anspechen soll), das in embeddetem
Assembler (weil das Beispiel in Assembler geschrieben wurde, der
Programmierer aber keinen Assembler kennt) auf die I/O Adresse
zugreift, nicht ohne seine Daten in verwaltetem Speicher fuer
parallele Prozesse zu halten.

Der Wahnsinn ist nicht zu stoppen.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
 
In article <dnbg37$nm9$1@online.de>, Stefan Raeder <StefanRaeder@gmx.de> wrote:
Welche Entwicklungsumgebung nutzt ihr denn für ARM7-
Mikrocontroller?
Click to expand...
GNU gcc+binutils funktioniert zumindest für die Nachfolger (wir benutzen
XScale, das sollte IIRC ARM9 sein) absolut Klasse und sollte auch die
älteren ARM7 unterstützen.

cu
Michael
--
Some people have no repect of age unless it is bottled.
 
Hallo Rafael Deliano wrote:

Auf die von der Industrie propagierte Alternative
bei exotischen CPUs/DSPs: "Sie programmieren alles
in C, den Rest macht unser Compiler" beissen nicht
alle embedded Anwender an.
Click to expand...
Das wuerde bei mir auch nicht laufen. Es gibt Situationen, da muss man
genau wissen, wieviele Taktzyklen ein Rechenvorgang dauert. D.h. es
werden sich fast immer Assemblerteile im Code finden, auch wenn der
Rahmen in C ist.

Gruesse, Joerg

http://www.analogconsultants.com
 
Hallo Manfred,

Nicht fuer die heutige Generation der Skript-Kiddies.
Click to expand...
ROFL!

Allerdings sind die Kids auch schon mit anderen simplen Dingen
ueberfordert. Was ein verpasster Interrupt erkannt wird, wissen die
offenbar auch nicht. Gestern ist zum x-ten mal die Tastatur des Laptop
eingefroren. Also wieder Batterie raus, Einschaltknopf ein paar Sekunden
halten etc.

Die Tastatur dieses Newsgroup Rechners gab auch auf, aber das lag nicht
an der Software. Sie mochte wohl doch kein Celebration Ale ...

Nach ordentlicher Reiningung aller Einzelteile mit Wasser tut sie nun
wieder.

Gruesse, Joerg

http://www.analogconsultants.com
 
Hallo Michael,

Nicht, daß mich jemand falsch versteht. Ich finde das ok, aber: you
get what you pay for. Anders ausgedrückt: there is no such thing as a
free lunch. Wer einen HW-Dividierer, schnelle Multiplikation und mehr
Register haben will, der wird halt auch etwas mehr Geld anlegen
müssen.
Click to expand...
Oder die ganze Chose eben wie gehabt analog erledigen, wenn moeglich.
Manchmal war es schon fast traurig. Faelle, fuer die ganz klar ein uC
praedestiniert gewesen waere, entwickelte ich meist analog. Fuer zwei
Dollars bekommt man locker hundert Bauteile inklusive Bestueckung, aber
ein uC mit Multiplier oder Divider haette mindestens das Doppelte
gekostet. Waere TI nicht so hochpreisig in den Markt gestartet, haetten
sie beim letzten Geraet einen Design-Win verzeichnet. Nun haben sie den
430F2013, doch er kam zu spaet.

Gruesse, Joerg

http://www.analogconsultants.com
 
Joerg <notthisjoergsch@removethispacbell.net> schrieb:

[...]

praedestiniert gewesen waere, entwickelte ich meist analog. Fuer zwei
Dollars bekommt man locker hundert Bauteile inklusive Bestueckung, aber
Click to expand...
für 1,5ct/Bauteil mußt Du aber schon einen gut ausgelasteten
Chip-Shooter haben?

Servus

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)
 
"Oliver Betz" <OBetz@despammed.com> schrieb im Newsbeitrag
news:439ba694.1456760180@z1.oliverbetz.de...
für 1,5ct/Bauteil mußt Du aber schon einen gut ausgelasteten
Chip-Shooter haben?
Click to expand...
Bei 35ct/Stunde chinesischem Stundenlohn? Wozu?
Eher die Leute zu schnellerer Arbeit antreiben,
dann geht's auch fuer 0.5ct.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
 
Joerg <notthisjoergsch@removethispacbell.net> wrote:

genau wissen, wieviele Taktzyklen ein Rechenvorgang dauert. D.h. es
werden sich fast immer Assemblerteile im Code finden, auch wenn der
Rahmen in C ist.
Click to expand...
Korrekt! Zum Beispiel habe ich letzte Tage eine DDS fuer den R8C
programmiert wo mich schon interessiert hat wie lange die
Phasenaddition und die Ausgabe an den DA dauert.

Ich programmiere heutzutage vielleicht noch 2-5% in Assembler, aber
das ist dann auch zwingend notwendig.

BTW: Ich hatte das erst in C gemacht. Wisst ihr was der Compiler aus
einem

do {
blabla
} while(1);

macht?

Der hat wirklich eine 1 in ein Register geladen und dann
verglichen. Argh!



Olaf
 
Olaf Kaluza schrieb:

Der hat wirklich eine 1 in ein Register geladen und dann
verglichen. Argh!
Click to expand...
Ist das beim R8C nicht so wie beim M16C, dass nur die Kaufversion des
Compiler den Code optimiert? Vermutlich ist die Erkennung von "while
(1)" auch so eine Optimierung.

CU Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP-Key-ID: 0x6DA025CA
 
Christian Zietz <newsgroup@chzsoft.com.ar> wrote:

Ist das beim R8C nicht so wie beim M16C, dass nur die Kaufversion des
Compiler den Code optimiert? Vermutlich ist die Erkennung von "while
(1)" auch so eine Optimierung.
Click to expand...
Also soweit ich weiss ist die Umsonstversion nur auf 64kb Codegroesse
beschraenkt. Ich hatte aber auch garnicht mit diversen Optimierungen
rumgespielt. So gesehen mag das PRoblem ja auch bei mir
liegen. Allerdings will man ja auch nicht unbedingt Compiler haben die
beim uebersetzen je nach Tagesform und Restcode eine andere
Entscheidung ueber den erzeugten Code treffen. Jedenfalls nicht wenn
die Ausfuehrungszeit von Bedeutung ist.

Mir ist dann eingefallen das auch C ja noch den goto Befehl kennt und
ich hab den das erstemal seit 10 Jahren benutzt. :-] Das ergibt dann
einen einfachen Sprungbefehl.

BTW: Es ist da sehr schoen das der Debugger von Renesas gleichzeitig
Source und Code anzeigen kann. Da gehen einen so manches Licht
wesentlich frueher auf als wenn man sich muehevoll durch extra
Listnings arbeitet.

Olaf
 
"Olaf Kaluza" schrieb
BTW: Ich hatte das erst in C gemacht. Wisst ihr was der Compiler aus
einem

do {
blabla
} while(1);

macht?

Der hat wirklich eine 1 in ein Register geladen und dann
verglichen. Argh!
Click to expand...
Hallo Olaf,

das hast du ihm doch auch gesagt oder ;-))

Das erinnert mich an ein altes Programm mit Matritzen Berechnungen, das ein
Kollege (Mathematiker) geschrieben hatte.
Wir hatten anschließend die "Performance" getestet und egal mit wieviel
Schleifen wir das Programm aufgerufen hatten,
es brauchte quasi keine Zeit. Nach der Analyse des Asembler codes stellte
sich heraus, dass der Compiler optimiert hatte
und die ganze Berechnungen durch eine Konstante ersetzt hatte. Das lustige
war, er hatte recht.

Gruß
Hans-Georg
 
"Joerg" <notthisjoergsch@removethispacbell.net> schrieb im Newsbeitrag
news:G02mf.37082$D13.4020@newssvr11.news.prodigy.com...
Hallo Michael,

... Eine Multiplikation
braucht bis zu vier Takte, weil der eingebaute Multiplizierer nur 8x32
bit kann. Damit scheidet der ARM7 für etwas anspruchsvollere
Signalverarbeitung aus. ...


Das ist allerdings ein Nachteil. Die Multiplikation dauert allerdings auch
bei R8C oder den teuren MSP430 Versionen mit HW Muliplier 5-8 Takte (fuer
16*16).

Einen Haken bei vielen Arm sehe ich in der Spannungsversorgung. Die wollen
meist zwei Spannungen und das auch noch fein geregelt. R8C und dergleichen
sind da besser, wenn man den Takt nicht voll ausnutzt. Sie duerfen mit 5V
laufen und man kann einfach eine Batterie dran haengen, zum Beispiel drei
AA Zellen. Bis hinunter zu etwa 3V ist noch alles in Butter. Aus diesem
Grund koennte LPC fuer den gerade vorliegenden Fall das Design-in
verlieren, denn das macht den Kostenvorteil zunichte.

Gruesse, Joerg

http://www.analogconsultants.com
Click to expand...
 
"Joerg" schrieb
. Eine Multiplikation
braucht bis zu vier Takte, weil der eingebaute Multiplizierer nur 8x32
bit kann. Damit scheidet der ARM7 für etwas anspruchsvollere
Signalverarbeitung aus. ...


Das ist allerdings ein Nachteil. Die Multiplikation dauert allerdings auch
bei R8C oder den teuren MSP430 Versionen mit HW Muliplier 5-8 Takte (fuer
16*16).

Hallo Joerg,
Click to expand...

ich habe gerade einen PID-Regler für einen AT91M55xxx geschrieben,
Die floating point Arithmetik ist eher lausig ;-)) Kann auch an der
C-Bibliothek liegen.
Aber mit den 32Bit kann man sich eine eigene fix point Arithmetik selbst
bauen.

Konkret gesagt, die Fühlerwerte über eine Steinhard-Hard Gleichung in einer
100ms Regelschleife zu berechnen,
war nicht möglich, ohne den Prozessor für alles andere lahm zu legen.

Gruß

Hans-Georg
 
On Sat, 10 Dec 2005 14:37:47 +0100, Olaf Kaluza <olaf@criseis.ruhr.de>
wrote:
Also soweit ich weiss ist die Umsonstversion nur auf 64kb Codegroesse
beschraenkt. Ich hatte aber auch garnicht mit diversen Optimierungen
rumgespielt. So gesehen mag das PRoblem ja auch bei mir
liegen. Allerdings will man ja auch nicht unbedingt Compiler haben die
beim uebersetzen je nach Tagesform und Restcode eine andere
Entscheidung ueber den erzeugten Code treffen. Jedenfalls nicht wenn
die Ausfuehrungszeit von Bedeutung ist.
Click to expand...
Eine Constant Expression Evaluation zusammen mit einer
Optimierung für den Sprung ist allerdings das, was heute jeder
bessere Compiler auch ohne Datenflußanalyse beherrschen
sollte, dazu wird einfach ein Const-Flag bei den Parametern
der Ausdrücke mitgeführt. Selbst bei P-Code ist das einfach
zu realisieren.

Wenn das Teil wirklich konstante Ausdrücke nicht auflöst,
dann verstehe ich, warum die Japaner im Softwaremarkt
nicht wirklich präsent sind ...

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
 
Olaf Kaluza wrote:
BTW: Ich hatte das erst in C gemacht. Wisst ihr was der Compiler aus
einem

do {
blabla
} while(1);

macht?

Der hat wirklich eine 1 in ein Register geladen und dann
verglichen. Argh!
Click to expand...
Das ist allerdings arm. Aber probier's mal mit for(;;) {}, das wird
Gerüchten zufolge von primitiven Compilern sinnvoller umgesetzt.

--
http://www.mikrocontroller.net
http://rforum.andreas-s.net - Ruby Web Forum
 
On Sat, 10 Dec 2005, Hans-Georg Lehnard wrote:
Konkret gesagt, die Fühlerwerte über eine Steinhard-Hard Gleichung in einer
100ms Regelschleife zu berechnen,
war nicht möglich, ohne den Prozessor für alles andere lahm zu legen.
Click to expand...
Ich glaube aber eher, du meinst die Gleichung mit den zwei
"t" anstatt den "d" :)

Woran hatte der Prozessor am meisten geknabbert, an den Logarithmen?

Hattest Du versucht, das zu optimieren und direkt (via Assembler)
zu programmieren?

Hätte man es mit Lookups machen können, wenn die
Kalibrations-Koeffizienten konstant
sind und R sich nur in einem bestimmten ("vorhersehbaren")
Bereich bewegt?
Das ist natürlich nicht die flexibelste Art.

Gruß und schönes Wochenende allerseits,
Mario
 
Andreas Schwarzschrieb:
"
Olaf Kaluza wrote:
BTW: Ich hatte das erst in C gemacht. Wisst ihr was der Compiler aus
einem

do {
blabla
} while(1);

macht?

Der hat wirklich eine 1 in ein Register geladen und dann
verglichen. Argh!

Das ist allerdings arm. Aber probier's mal mit for(;;) {}, das wird
Gerüchten zufolge von primitiven Compilern sinnvoller umgesetzt.
Click to expand...
Naja arm ist es eher, wenn man mit einem Compiler nicht richtig
umgehen kann.

Einfach mal -O5 als Optimierung einschalten, dann ist das auch alles
wegoptimiert.

Irgend jemand hatte mal hier den Spruch geprägt: "Wer lesen kann ...."


Dirk
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top