Wird ARM der naechste "Volksprozessor"?

J

Joerg

Guest
Hallo Leute,

Ihr seid in Europa naeher am Geschehen, da in Sachen ARM vieles von
Philips kommt. ARM war bisher fuer viele Entwicklungen zu teuer, aber
nun gibt es ja LPC2101 bis 2103 fuer um die $2 in Stueckzahlen. Mit 32
Bits rechnen zu koennen waere natuerlich das Sahnehaeubchen.

Was denkt der erlauchte Kreis hier? Wird ARM die naechste 8051er Generation?

Ist der Support bei Philips akzeptabel?

Gruesse, Joerg

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

Was denkt der erlauchte Kreis hier? Wird ARM die naechste 8051er Generation?
Also eigentlich waer es mir total egal welcher Prozessor sich mal
etwas verbreitet. Es waer nur schoen wenn es ueberhaubt mal einen
Prozessor geben wuerde den man 20Jahre unveraendert von mehreren
Herstellern kaufen kann.

Aber glaubst du wirklich daran?

Olaf
 
Joerg wrote:

Was denkt der erlauchte Kreis hier? Wird ARM die naechste 8051er
Generation?
Scheint irgendwie so.
Überall wachsen ARMe. Atmel, Oki, Samsung, Intel, TI ...
Selbst Analog baut schon ARM Kerne in ADDA Wandler mit ein ;-)

Grüsse
Robert
 
Hallo Olaf,

Also eigentlich waer es mir total egal welcher Prozessor sich mal
etwas verbreitet. Es waer nur schoen wenn es ueberhaubt mal einen
Prozessor geben wuerde den man 20Jahre unveraendert von mehreren
Herstellern kaufen kann.

Aber glaubst du wirklich daran?
Beim 8051 war beziehungsweise ist es so. Das aelteste Design von mir,
dass mit 8051 arbeitet, ging Anfang der 90er in Produktion und laeuft
immer noch in Serienfertigung. Sollte der uC abgekuendigt werden, gaebe
es einige alternative Versionen. Das war damals einer der Gruende fuer
den Einsatz der 8051 Architektur.

Ok, das sind erst circa 15 Jahre, aber mich wuerde es nicht wundern,
wenn dieses Geraet auch nach 20 Jahren noch vom Band liefe. Muss es
sogar, denn mit dem Ding wird ziemlich rauh umgegangen und es gibt
laufenden Ersatzbedarf. Hin und wieder wird schon mal eins zermalmt.

Gruesse, Joerg

http://www.analogconsultants.com
 
Wird ARM die naechste 8051er Generation?
Wurde unter genau dieser Titelzeile langatmigst/kontrovers
vor 12 Monaten in englischsprachigen newsgroups "diskutiert".
Abgesehen davon, daß der 8051 stückzahlenmässig deutlich
hinter 68HCxx und PICs liegt ( 8051 er ist nur langlebig,
aber heute nichtmehr übermässig populär ), ist es die
Pseudodiskussion der frühen 90er "in-jedem-Toaster-ist-
bald-ein-x86". Dem war nicht so. ARM ist ein Speicherfresser
der von externen DRAMs träumt und damit kein besonders guter
embedded RISC.

Philips
Die ursprüngliche fab von ARM war glaube ich VLSI-Technology
die von Philips geschluckt wurden. Dürften sich also gut
mit der CPU auskennen.
Wenn man versuchen wollte hierzulande bei ebay lose ICs zu
kaufen findet man eher ARMs von Atmel.
Wenn "Volksprozessor" heissen soll "Hobbyprozessor" für die-
jenigen denen der AVR zu öde geworden ist ( Uiiii da läuft
ja kein Linux drauf ... ) dann könnte das eher der Realität
entsprechen.

MfG JRD
 
Hallo Joerg,

Was denkt der erlauchte Kreis hier?
Wird ARM die naechste 8051er Generation?
Ich denke schon das ARM sich einen guten Markanteil erobern kann. Es
scheint zur Zeit eine regelrechte Artenexplosion zu geben. Auch die
Tools sind schon da und auch weitest gehendst ausgereift, der GCC kann
seit vielen Jahren mit ARM umgehen.

ARM scheint den ARM7-Core zur Zeit im Sonderangebot (Räumungsverkauf um
Platz für ARM9 und ARM11) zu haben so das die Lizenzgebühren
offensichtlich so niedrig sind das man daraus 2$-Chips machen kann. Das
Segment der ganz kleinen (wie ATtiny oder PIC12) wird ARM wohl nicht
allzu bald erobern aber überall dort wo etwas mehr RAM, viele IO-Pins
oder einfach nur CPU-Power gefragt sind hat ARM eine gut Chance.

Ein weiterer Vorteil ist der Upgrade-Path nach oben (ARM9 und ARM11).
Der Code läuft unverändert (die neueren Cores sind abwärtskompatibel)
und der GCC kann die auch schon. Wenn der kleine ARM7-ľC mit 50MHz nicht
mehr reicht dann tuts bestimmt ein ARM11 mit 500MHz (der ist mehr als 10
mal so schnell).


Mit 32 Bits rechnen zu koennen waere natuerlich das Sahnehaeubchen.
In Projekten wo sich das lohnt ist der ARM auf jeden Fall einen Blick
wert. Aber auch der Adressraum ist 32Bit breit und das bringt einfach
viele Vorzüge, wenn ich mich an das Banking auf den PIC zurück erinnere
dann ist der ARM eine echte Erleuchtung.


Ist der Support bei Philips akzeptabel ?
Mach dort auf keinen Fall den Fehler auf einen Hersteller einzugewöhnen.
Der CPU-Kern ist bei allen gleich nur die Peripherie ist
unterschiedlich, so das es ungeahnt leicht sein könnte sich für jedes
neue Projekt den passenden ľC, von verschiedenen Herstellern, rauszusuchen.
Ansonsten gibts einige Foren im Netz, bei Yahoo sogar eins speziell für
die LPC2xxx-Family. Die Fangemeinde wächst.
Aber wie andere schon schrieben, die Auswahl ist groß.

Ich persönlich werde mir die LPC2xxx-Family von Philips und die
AT91SAM7xxx-Family von Atmel als Arbeitspferd holen.


Grüße
Erik
 
Joerg wrote:
Hallo Leute,

Ihr seid in Europa naeher am Geschehen, da in Sachen ARM vieles von
Philips kommt. ARM war bisher fuer viele Entwicklungen zu teuer, aber
nun gibt es ja LPC2101 bis 2103 fuer um die $2 in Stueckzahlen. Mit 32
Bits rechnen zu koennen waere natuerlich das Sahnehaeubchen.
Die $2 für die LPCs ist die logische Antwort auf das Erscheinen der
SAM7-Familie von Atmel. Die scheinen die ARM7-Preise ja richtig gemein
zu drücken.

Ich denke schon, dass der ARM7 der neue "VolksMC" wird. Es gibt gute und
kostenlose Entwicklungswerkzeuge und MCs mit dem ARM7TDMI Kern gibt es
ja schon seit Jahren von allen möglichen Herstellern.

Gerade die SAM7 in der kleinen Gehäusebauform (der kleinste ist TQFP48)
und der supergenialen Peripherie werden sich durchsetzen. Atmel hat's
halt drauf :)

--
Mfg
Thomas Pototschnig
www.oxed.de
 
Beim 8051 war beziehungsweise ist es so. Das aelteste Design von mir, dass
mit 8051 arbeitet, ging Anfang der 90er in Produktion und laeuft immer
noch in Serienfertigung. Sollte der uC abgekuendigt werden, gaebe es
einige alternative Versionen. Das war damals einer der Gruende fuer den
Einsatz der 8051 Architektur.
Und die schnellen 8051 Varianten von SiliconLabs (25-100MIPS) und von
Winbond (10 MIPS) sind zur Zeit auch recht beliebt für Neuentwicklungen.

Michael
 
Hallo,

ARM ist ein Speicherfresser der von externen DRAMs
träumt und damit kein besonders guter embedded RISC.
Speicherschoner sind richtige 32Bit-CPUs noch nie gewesen. Wer glaubt er könne sein Program vom ATmega32 auf nen LPC2103 portieren
(beide 32kByte Flash) der irrt sich da gewaltig, die 32Bit fordern gnadenlos ihren Tribut.
In dieser Hinsicht frage ich mich auch welches Zielsegment Philips mit den neuen LPC2101/LPC2102/LPC2103 (8k/16k/32k Flash)
ansteuert. Projekte die bisher mit einem ATmega8 gut ausgekommen sind werden wohl auch weiterhin mit der Atmel-CPU besser fahren,
auch ich werde die kleinen AVRs nicht wegschmeißen. Bei Projekten wo der ATmega128 schon eng wird hat Philips tatsächlich
interessante Alternativen parat, aber eben nicht die LPC210x. Aber auch Atmel scheint diesen Zug nicht verpassen zu wollen, wobei
ich dort aber den Eindruck habe das die alt bekannte AVR-Peripherie einfach übernommen wurde. So hat Philips nur 32Bit breite Timer
wogen bei der AT91SAM7xxx-Family von Atmel noch vieles im alten 16 (oder gar 8) Bit-Gewand daher kommt. Auch die UARTs machen bei
Philips einen besseren Eindruck (echte 16C550 mit je 2 echten FIFOs). Dafür hat Atmel mit der Peripherie einfach etwas mehr
Erfahrung was einem beim Vergleich der Errarter-Sheets deutlich auffällt.


Wenn "Volksprozessor" heissen soll "Hobbyprozessor" ....
Für die Hobbyleute soll sogar ein LPC2103 in PLCC44 rauskommen, na das kann was werden.
Hoffentlich bringt Philips auch den Support für die X-Tausend "5 Stück pro Jahr"-Bastler zu stande.


Grüße
Erik
 
Was denkt der erlauchte Kreis hier? Wird ARM die naechste 8051er Generation?
Hallo Joerg,

die Frage eignet sich wieder für einen Glaubenskrieg ŕ la "welcher
Texteditor ist der beste?". Deshalb erstmal ein Disclaimer: hier kommt
meine ganz persönliche und subjektive Meinung (und die müsste
vielleicht sogar hier und da revidiert werden, weil ich seit ungefähr
8 Jahren fast nichts mehr mit dem ARM7 gemacht habe).

Es gibt verschiedene ARM Architekturen, aber ich glaube jeder bezieht
sich hier auf den ARM7, genauer den ARM7TDMI. Es gibt m.E. so einiges
an dieser Architektur zu kritisieren(*), genau so wie beim 8051.
Insofern ist der Vergleich ziemlich treffend. Aber auch bei der
vorherrschenden PC-Architektur hat sich ja schon vor langer Zeit
gezeigt, daß sich nicht unbedingt das beste durchsetzt. Die meisten
Architektur-Schwachpunkte brauchen denjenigen, der in einer höheren
Programmiersprache entwickelt, nicht zu interessieren (das war beim
8051 deutlich anders. Mein letztes Design damit habe ich 1988 gemacht
und weil man ihn in Assembler programmieren musste, habe ich mir damals
geschworen, diese verkorkste Architektur nie wieder anzufassen).

Was hat der ARM7 auf der Habenseite?
- breite und preisgünstige Verfügbarkeit von Bauteilen
- preiswerte und gute Entwicklungstools
- Verfügbarkeit von Softwarebibliotheken insbesondere für alles was
Telekommunikation heißt
- moderate Rechenleistung
- verfügbar als Core für eigene ASICs, sogar für FPGAs

Daraus ergibt sich, daß er für "Allerweltsaufgaben" sehr gut geeignet
ist. Für höhere Anforderungen wird man dann auf andere Architekturen,
z.B. MIPS Risc, PPC, V850 oder auch ARM9/10/11 zurückgreifen, denn der
ARM7 kann beileibe nicht alle Aufgaben erschlagen. Warum es aber immer
noch Leute gibt, die neue Designs mit 16-Bit Architekturen entwickeln,
ist mir nicht wirklich klar (ok, existierender Code, Tools u.s.w). Aber
es ist wirklich an der Zeit, diese alten Zöpfe abzuschneiden. An den
Kosten kann es nicht liegen, denn 32-bitter sind heute oft günstiger
als 16-bitter. Manchmal habe ich das Gefühl, daß zumindest manche
Designer Angst vor Neuem haben.

Also als abschließende Bewertung und Antwort auf Deine Frage: ja, er
könnte es werden!

Michael

(*) Meine ganz subjektive Kritikpunkte am ARM7TDMI sind: Im ARM Mode
nur 16 General Purpose Register und alle Befehle sind 32-bit breit. Das
kostet Codesize. Im Thumb Mode (IIRC) nur 8 Register und ein ziemlich
eingeschränkter Befehlssatz. Das ständige Umschalten zwischen den
Modi kostet Codesize und Performance. Alle Interrupts werden auf nur
zwei Interrupt-Vektoren umgeleitet und die CPU muß dann feststellen,
wo der Interrupt herkam (wahrscheinlich gibt es inzwischen vernünftige
Interrupt Controller, die diesen Nachteil beheben). 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. Ein ganz nettes Feature ist die bedingte
Ausführung von Befehlen. Ob das allerdings jemand nutzt, kann ich
nicht sagen.
 
Hallo Joerg,

Joerg <notthisjoergsch@removethispacbell.net> wrote:
Was denkt der erlauchte Kreis hier? Wird ARM die naechste 8051er Generation?
Nicht ganz so de facto standard wie der 8051 mit zahlreichen
Second Sources (Pin und Funktionskompatibel), aber ich sehe
diese Vorteile:

- Kern ist bei allen gleich -> Toolchain bei der Entwicklung
ist dann ueberall einsetzbar, dito Know-How.
- Open-Source OSse (ecos) verfuegbar.
- Leistungsfaehige Peripherie On-Chip, z.B. 100 MBit Ethernet,
CAN, USB. Dabei ist dann nur noch ein Transceiver zusaetzlich
notwendig. Und die Rechenleistung ist ausreichend, um Daten
in Wirespeed zu verarbeiten und uebertragen.

Ich sehe den Einsatz fuer mich hauptsaechlich dort, wo bisher
noch ein Controller mit externem DRAM + Flash notwendig war
(evtl. auch noch BGA), da reicht jetzt einer mit internem Flash
und SRAM, im PQFP-Gehaeuse mit jeder Menge eingesparter externer
Peripherie.

Ist der Support bei Philips akzeptabel?
K.a. ich hatte mit denen noch nicht zu tun, eine Supportanfrage
bei Atmel wegen dem On-Chip Ethernet-Controller dauerte eine
Woche, wurde aber gut beantwortet, dabei ist das Produkt noch
nicht am Markt.


cu,

Steffen
 
Hallo,

ich äußere mal ein paar Anmerkungen zu Deiner Kritik am ARM7-Core :


Im ARM Mode nur 16 General Purpose Register
und alle Befehle sind 32-bit breit.
dafür auch echte Drei-Operanden-Befehle welche so manchen MOV einsparen können.


Alle Interrupts werden auf nur zwei Interrupt-Vektoren
umgeleitet und die CPU muß dann feststellen, wo der
Interrupt herkam (wahrscheinlich gibt es inzwischen
vernünftige Interrupt Controller, die diesen Nachteil beheben).
Der Interruptcontroller der Philips LPC2xxx-Reihe behebt diesen Nachteil tatsächlich recht gut, sowas hab ich mir für x86 immer
gewünscht. Andere Hersteller bieten ähnliches.


Ein ganz nettes Feature ist die bedingte Ausführung von Befehlen.
Ob das allerdings jemand nutzt, kann ich nicht sagen.
Die Compiler sollten das nutzen können. Ob sie das wirklich tun hab ich nicht geprüft. Auf aktuellen x86-CPUs nutze ich die
Conditional-MOVs in Assembler recht gerne.


Grüße
Erik
 
Hallo Rafael,

Wurde unter genau dieser Titelzeile langatmigst/kontrovers
vor 12 Monaten in englischsprachigen newsgroups "diskutiert".

Die hatte ich vorher ein wenig abgeklappert, aber ich wollte das mal aus
europaeischer Sicht erfahren. Ihr seid in Sachen uC (und bei Autos...)
harte Realisten.


Abgesehen davon, daß der 8051 stückzahlenmässig deutlich
hinter 68HCxx und PICs liegt ( 8051 er ist nur langlebig,
aber heute nichtmehr übermässig populär ),...

Bisher war es so, dass in jedem Geraet, was ich gewartet oder repariert
hatte, irgendeine Variante des 8051er Konzepts werkelte. Sogar in
unserem Pelletofen ist einer, der da drin wohl hoechstens zu 5%
ausgelastet ist.


... ist es die
Pseudodiskussion der frühen 90er "in-jedem-Toaster-ist-
bald-ein-x86". Dem war nicht so. ARM ist ein Speicherfresser
der von externen DRAMs träumt und damit kein besonders guter
embedded RISC.
So wie mal ein "Forschungsminister" vor etwa 30 Jahren sagte, in ein
paar Jahren gaebe es keine Fernseher mit Bildroehre mehr. Da fiel mir
echt nichts mehr ein.

Speicherfressen waere nicht so gut. Die kleinen ARM von Philips wie
LPC2101 haben davon nicht mehr als kleinere uC.

Gruesse, Joerg

http://www.analogconsultants.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
 
"Michael Krämer" <mike102de@yahoo.com> schrieb:

[Kritikpunkte am ARM7TDMI]

Interrupt Controller, die diesen Nachteil beheben). Eine Multiplikation
braucht bis zu vier Takte, weil der eingebaute Multiplizierer nur 8x32
bit kann. Damit scheidet der ARM7 für etwas anspruchsvollere
Gibt es eine brauchbare Hardwaredivision? Ein HC(S)12 kann z.B. 32/16
in 11 Takten.

Servus

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)
 
Hallo zusammen,

meine ersten Projekte basierten auf den 8051 Mikrocontrollern
80C535 und 517 von Siemens (später Infineon), das war 1990.
Ein PIC-Projekt hatte ich auch schon mal, ich fand aber damals
die Mikrocontroller nicht so schön zu programmieren (Register
und Hardwarestack), ist nun auch schon 10 Jahre her. TIs MSP430
hatte ich auch schon mal "in der Hand", habe aber noch kein
Projekt damit realisiert.

Seit etwa 8 Jahren programmiere ich die Atmel AVRs und bin
mit denen sehr zufrieden. Allerdings bin ich schon einigemale
bezüglich der Rechenleistung nahe an die Leistungsgrenzen
der Mikrocontroller gestossen. Anfang des Jahres wollte ich
mich dann mit ARM7 auseinandersetzen und legte mir ein
AT91SAM7-IAR Starterkit zu, leider habe ich bis heute (auch
aus Zeitgründen) noch keinen Einstieg in ARM7 geschafft.
Die Software des Starterkits läuft nicht mehr, da sie zeitlich
begrenzt war.

Ich denke, dass Atmel AT91SAM7xx oder Philips LPC210x
eine gute Alternative zu den AVRs (ATMega) sind, wenn man
mehr Rechenleistung benötigt.

Welche Entwicklungsumgebung nutzt ihr denn für ARM7-
Mikrocontroller?

Hat jemand mit AT91SAM7xx Erfahrungen?

Gruss
Stefan
 
Hallo Joerg,

Einen Haken bei vielen Arm sehe ich in der Spannungsversorgung. Die
wollen meist zwei Spannungen und das auch noch fein geregelt.
Also wenn Du +/-10% als fein geregelt betrachtest dann ist das natürlich
ein Problem, aber sonst dürfte ein normaler "3Pinner" dafür ausreichen.
Und die IO-Spannung ist nicht ganz so kritisch wie im Datenblatt
abgegeben, da sind nach unten bestimmt mehr als 10% Möglich.

Sie duerfen mit 5V laufen und man kann einfach
eine Batterie dran haengen, zum Beispiel drei AA Zellen.
Da sehe ich eher mit den gut 4,5V Anfangsspannung ein Problem. Gibts für
sowas eigentlich einfache Spannungsbegrenzer die sich unterhalb ihrer
Nennspannung völlig transparent verhalten, am besten als einzelnes Bauteil?

Bis hinunter zu etwa 3V ist noch alles in Butter.
Das ist bei den LPC nicht anders, die IO-Spannung ist nur für die
Output-Treiber zuständig. Alles andere hängt an der Corespannung und die
dürfte so ein 3Pinner bestimmt bis etwa 2,5V Batteriespannung stabil halten.


Aus diesem Grund koennte LPC fuer den gerade vorliegenden Fall
das Design-in verlieren, denn das macht den Kostenvorteil zunichte.
Ich würde eher sagen das der LPC die Batterie zu schnell leer hat. So
ein ARMling ist was anderes als die MSP430.

So wie ich das sehe brauchst Du 4 zusätzliche Bauteile um einen LPC an 3
AA-Zellen (von max. 4,5V bis min. ca. 3V) betreiben zu können. Einen
Längsregler für die Core-Spannung und einen Diskreten Längsregler aus
einen FET, Verarmungstyp bzw. selbstleitend (weis jetzt nicht genau wie
das heist), eine Z-Diode und einen Wiederstand. Den Rest der Schaltung
kannst Du problemlos direkt an die Batterie anschließen (falls die Teile
das verkraften), zumindest hat der LPC damit keine Probleme. Die Frage
ist nur wie sich der LPC mit einer zu kleinen IO-Spannung verhält. Er
wird wohl nicht kaputt gehen und auch die gesamte innere Peripherie
fängt nicht das Spinnen an (die hängt nämlich auch an der
Core-Spannung), ich vermute mal das die Output-Treiber etwas langsamer
werden und sich die Input-Schaltschwelle vielleicht etwas nach unten
verschiebt. Mein Tipp "Versuch macht Kluch". Ich werde das auf jeden
Fall mal probieren, interessiert mich nämlich auch.


Grüße
Erik
 
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?

--
Mfg
Thomas Pototschnig
www.oxed.de
 
Speicherfressen waere nicht so gut.
Thumb ist das Eingeständnis von ARM daß
Codedichte schlecht ist. Ist keine wirkliche
Lösung sondern kaputte Krücke für C-Programmierer
die Unmengen Assembler linear ausführen wollen/müssen.
In FORTH würde Bytecode helfen: in den meisten
Anwendungen existiert viel Code der nicht zeit-
kritisch ist. Was zeitkritisch ist muß man dann
eben in Assembler machen.
Das ist der Vorteil an ARM genau wie bei x86
daß man sinnvoll in Assembler programmieren kann.
Erstens weil die Architektur langlebig und zweitens
weil sie für manuelle Programmierung geeignet ist.
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.

MfG JRD
 
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
Divisionsbefehl. Damit (und mit den vorher genannten Einschränkungen)
ist der ARM7 eigentlich nur eine halbe CPU. Dafür wird er aber
sozusagen auch zum halben Preis verschleudert und hat damit wieder
seinen Markt. Wem's halt langt...

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.

Michael
 

Welcome to EDABoard.com

Sponsor

Back
Top