"Lebensberechtigung" von PIC-ľC

[Wolfgang Draxinger]

Rainer Buchty wrote:

...
Assemblerprogrammierung zu nicht minder schweren Fällen von
explosiver Gehirnpest führen.

<schmunzel> Besser hätte ich das wohl auch nicht ausdrßcken
kĂśnnen </schmunzel>

|> Ich bevorzuge CPUs mit einer sauber durchdachten
|> Architektur, also RISC und da kommen eigentlich nur die AVR
|> und die diversen Vertreter der MC68xxx in dieser
|> Leistungsklasse in Frage.

68k ist genausowenig RISC wie die 680x-Derivate. Aber dafür in
der Tat schön durchdacht.

RISC bezog sich auf den AVR; RISC Kern, CISC Befehlssatz.
Übrigens interessant in diesem Zusammenhang: Bis zum 486 waren
die Intel CPUs CISC, mit dem Pentium wurde ein Befehlsdekoder
mit einer semi-RISC(*) Pipeline eingefĂźhrt. Erst der P2 hat dann
wirklich das Konzept "voll durchgezogen". Man kann also sagen,
dass sich RISC auf breiter Front durchgesetzt hat, als es immer
noch zänkereien zwischen den Programmiererfraktionen gab, was
wohl das bessere Konzept sei (das war so so gegen 1996 bis
1999).

|> ähm, warum hat sich die x86 Architektur eigentlich
|> durchgesetzt?

snip

<blauaeugigmode>
Du hast so eben mein Weltbild erschĂźttert, dass es immer das
bessere Konzept ist, dass sich durchsetzt (Evolution: Survival
of the fittest). Im Markt gilt demnach pseudo-Evolution:
Survival of the Strongest, seufz...
</blauaeugigmode>

Wolfgang

 

[Matthias Weingart]

Marco Budde <mb-news-a@linuxhaven.de> wrote in
news:cc8reb$4cd$1@ovid.linuxhaven.local:

Das Problem hast Du nicht nur beim PIC. Ich frage mich z.B. auch,
warum Firmen wie TI oder Cypress 8051 uC mit USB-Core
herausbringen, wo der uC noch nicht einmal genug Power hat, um den
Datenstrom unter Volllast (immerhin bis zu 480 MBit/s) zu
verarbeiten.

Da braucht man die CPU auch nur zum Steuern des Datenstromes.
Die eigentlichen Daten fliessen automatisch über den Parallelport mit
Handshake Leitungen in die Serial Interface Engine. Wenn man das per
Software machen wollte, reicht bei 480MBit/s noch nicht mal ein P4.
(Ganz abgesehn davon, das es z.Z. nichtmal die Hostcontroller schaffen,
die 480MBit/s voll auszunutzen).

M.
--
Bitte auf mwnews2@pentax.boerde.de antworten.

 

[Dieter Wiedmann]

Rainer Buchty schrieb:

Immerhin handelt es sich hier um den m.W. ältesten Microcontroller; der
Urvater GI1650 ist von 1975 und damit sogar noch älter als MCS48/MCS51

TMS1000 nicht vergessen (AFAIR: 01/75), irgendwo müsste ich sogar noch
das Entwicklerhandbuch haben.


Gruß Dieter

 

[MaWin]

Wolfgang Draxinger <wdraxinger@darkstargames.de> schrieb im Beitrag <cc8s72$42c$1@svr7.m-online.net>...

Man kann also sagen, dass sich RISC auf breiter Front durchgesetzt hat

Marketinggeschwaetz.

Der minimale RISC hat naemlich genau EINEN Befehl.
Das reicht absolut fuer allgemeine Universalcomputer.

Also ist kein angeblicher RISC ein wirklicher RISC.

Viele RISC haben mehr unterschiedliche Befehle, das aeltere CISC.
Frueher galten naemlich 50 Befehle oder so als voellig ausreichend.
Die heutige Instuktionsvielfaltschwemme wie im Pentium ist lediglich
historisch begruendet, sie muessen halt 8086/286 emulieren, ihren
eigenen Befehlssatz mitschleppen, dutzende Erweiterungen fuer
Graphik, Speicherverwaltung und Co. kamen dazu, komplette 16,
32 und 64 Bit Befehlssaetze werden parallel gefuehrt etc. pp.

Der urspruengliche 8086 war genial, denn Intel kannte bereits das
Ziel 286 (abgekupfert von irgendeinen Burroughs 7000 Grossrechner),
und die 'Einfachvariante' mit damals vertraeglicher Technik war
sehr elegant.
Wegen eines klitzekleinen Implementationsfehlers im 286 (fehlendes
dirty bit) waren Anwendungen mit virtuellem Speicher dort aber zu
uneffektiv, was zum extrem kranken 386 fuehrte.
Die seit Burroughs bekannte Segmentierung ist zwar ein Schimpfwort,
aber fuer moderne Betriebssysteme unerlaesslich, wie man daran
erkennt das 68000-basierende System das ohne jeden Hardwaresschutz
durch Zuweisung von speziellen Funktionen an allgemeine Register mehr
schlecht als recht emulieren.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
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.

 

[Dieter Wiedmann]

Kurt Harders schrieb:

Poweruser? Ziemlich unscharfer Begriff, wohl von Schlipsträgern
erdacht.

Poweruser ist der Benutzer eines Systems, der die Grenzen des Systems
nicht kennt und dennoch versucht zu überschreiten. Er zeichnet sich
durch die Unfähigkeit aus, eine dem Problem angemessene Lösung zu
finden.

Also ein Politiker.


Gruß Dieter

 

[Rainer Buchty]

In article <cc8oh3$2o0$1@svr7.m-online.net>,
Wolfgang Draxinger <wdraxinger@darkstargames.de> writes:
|> Ähm nein, aber ich habe 1991 einen Sack alter PICs geschenkt
|> bekommen und mir gefallen die Dinger heute genausowenig, wie sie
|> es damals getan haben, tut mir leid.

Immerhin handelt es sich hier um den m.W. ältesten Microcontroller; der
Urvater GI1650 ist von 1975 und damit sogar noch älter als MCS48/MCS51
von Intel, welche bei Assemblerprogrammierung zu nicht minder schweren
Fällen von explosiver Gehirnpest führen.

|> Ich bevorzuge CPUs mit einer sauber durchdachten Architektur,
|> also RISC und da kommen eigentlich nur die AVR und die diversen
|> Vertreter der MC68xxx in dieser Leistungsklasse in Frage.

68k ist genausowenig RISC wie die 680x-Derivate. Aber dafür in der Tat schön
durchdacht.

|> ähm, warum hat sich die x86 Architektur eigentlich durchgesetzt?

Weil Motorola nie im Bürosegment vertreten war -- und die Homecomputer-
hersteller mit zu "geschlossenen" Systemen schließlich an die Wand fuhren.

Streng genommen ist IBM schuld: Die haben vergessen, das PC-BIOS unter
besonderen Schutz zu stellen, so daß den Fernost-Klonern Tür und Tor geöffnet
wurden. Als es dann endlich vernünftige Sound- und Grafikkarten gab, war
"der PC" schließlich auch für den Heimanwender tauglich und sogar attraktiver,
weil die Innovationszyklen weit kürzer waren als bei den eher starren
Heimcomputersystemen.

Als Nebeneffekt wurde übrigens Microsoft allmächtig und Bill Gates der reichste
Mann der Welt...

Rainer

 

[Georg Acher]

In article <01c461c5$34975100$0100007f@amdk6-300>,
"MaWin" <me@privacy.net> writes:
|> Wolfgang Draxinger <wdraxinger@darkstargames.de> schrieb im Beitrag <cc8s72$42c$1@svr7.m-online.net>...
|>
|> > Man kann also sagen, dass sich RISC auf breiter Front durchgesetzt hat
|>
|> Marketinggeschwaetz.
|>
|> Der minimale RISC hat naemlich genau EINEN Befehl.
|> Das reicht absolut fuer allgemeine Universalcomputer.
|>
|> Also ist kein angeblicher RISC ein wirklicher RISC.
|>
|> Viele RISC haben mehr unterschiedliche Befehle, das aeltere CISC.

Das RISC-Konzept bezieht sich nicht nur auf die Anzahl der Befehle, auch wenn das
ganz am Anfang der nach aussen hin deutlichste Unterschied war. Ansonsten könnte
man den 8051 oder den PIC auch noch als RISC einordnen ;-) Zu RISC gehören unter
anderem viele Universalregister, Load-Store-Architektur, einheitliche
Befehlslänge, Verarbeitungspipelines und hart verdrahtete Dekodierung ohne
Mikroprogramm. Einen "echten" RISC-Prozessor möchte heute wohl auch keiner in
Assembler programmieren. Das, was heute RISC heisst, ist für Weicheier...

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Kurt Harders]

Hallo Marco,

Marco Budde <mb-news-a@linuxhaven.de> schrieb in
news:cc8reb$4cd$1@ovid.linuxhaven.local:

Nicht ganz, aber so ähnlich . Mir ist sowieso unverständlich,
warum viele Firmen heute noch Sachen in Assembler auf total
kranken Architekturen entwickeln. Was da allein die Entwicklung
kostet, dürfte sämtlich Einsparungen bei der Herstellung
übersteigern.

Was nachzurechnen sei . Aber Du wirst oft Recht haben.

Assembler ist IHMO heute total veraltet. Den Probleme sind heute
so komplex, daß selbst C schon fast nicht mehr reicht.

Alle Probleme? . Meine Weichenantriebe habe ich in Assembler
entwickelt, und würde sagen, dass es in C nur bedingt einfacher
gewesen wäre. Und um Bemerkungen zu vermeiden: ich kann C, Java,
Pascal... Also lag es wohl nicht daran

Gruss, Kurt

--
PiN - Präsenz im Netz GITmbH
Kurt Harders
http://www.pin-gmbh.com

 

[Michael Baeuerle]

Dieter Wiedmann wrote:

Thomas Pototschnig schrieb:

Allerdings hast du in einem Punkt recht. Der ATMEGA103 war nach kurzer Zeit
wieder abgekündigt. Dafür gibts zwar immer neue Varianten aber um das ändern
des Layouts kommt man dann wohl nicht.

Jepp, und *das* kostet Geld und vor allem Zeit, nix für Serie.

Wer hat da ein Layout aendern muessen? Bevor der ATmega103 abgekuendigt
wurde, gab es einige Zeit parallel den - bis heute aktuellen - ATmega128
(dieser hat eine "103-compatibility" Fuse und ist damit Software und
Pinkompatibel). Man hatte also auch Zeit den ATmega128 zu testen
waehrend man noch ATmega103 verkauft hat.

AFAIK hat Atmel bis heute nicht einen einzigen AVR abgekuendigt ohne
vorher einen Pin- und Funktionskompatiblen Ersatz (der meistens noch
billiger und besser war) herauszubringen. In den meisten Faellen war
auch die Software unveraendert nutzbar. Was sollen sie sonst tun? Atmel
stellt halt gerade auf einen 0.35um Prozess um und damit kann bzw. will
man die alten Designs offenbar nicht einfach geshrinkt weiterbauen.

BTW: Den allerersten AVR, den AT90S1200 gibt es immer noch.


Micha
--
Eine Konstruktion, die gehorsame_Elektronen(tm) benoetigt ;-/
"Gehe bis zur naechsten Ecke, warte dort 0,5s und fliege dann
weiter ..."
Oliver Bartels in de.sci.electronics

 

[Michael Baeuerle]

Marco Budde wrote:

Stammt das Design der AVRs nicht auch irgendwo aus den 70er ?

Laut Atmel:
http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=Ships500M.html

stammt es von 1997 (und waere damit wohl das juengste 8Bit Design).


Micha
--
Eine Konstruktion, die gehorsame_Elektronen(tm) benoetigt ;-/
"Gehe bis zur naechsten Ecke, warte dort 0,5s und fliege dann
weiter ..."
Oliver Bartels in de.sci.electronics

 

[Robert Rottmerhusen]

Thomas Pototschnig wrote:

im Vorfeld muss ich sagen, dass dieser Beitrag aus ständigem Ärger über
die PIC ľCs von Microchip entstanden ist.

In wie weit Ärger? Funktionieren die Dinger nicht so wie im Datenblatt
beschrieben? Ein Blick in die Erratas hilft.
Einige neuere PIC16F8xxA sollen echt Probleme haben.

Gibt es außer bestehende Designs noch irgendwelche Gründe einen PIC ľC
einzusetzen?

Ja, man kann mit mit funktionierenden PICs z.B. die PIC16F8xx ohne A
stabile, EMV-feste Designs basteln. Der Brownout-Rest funkioniert bestens
und der Watchdog wird per fuse gesetzt.
PICs sind einfach aufgebaut und in Assembler beherrschbar.
Ausserdem sind sie billich

Zum Basteln für einfache Sachen reicht meist auch noch ein AT89S2051.
Für komplexere Designs nehm ich inzwischen AVR Megas oder M16C, die dann in
C programmiert werden. Debugging von eigenen und Compilerfehlern ist dann
schon aber nicht mehr so einfach.

Grüsse
Robert

 

[Rainer Buchty]

In article <cc8s72$42c$1@svr7.m-online.net>,
Wolfgang Draxinger <wdraxinger@darkstargames.de> writes:
|> RISC bezog sich auf den AVR; RISC Kern, CISC Befehlssatz.

Ich glaube, das schlimmste Vergehen von Patterson war, den Begriff "RISC" zu
prägen. Mit spartanischem Befehlssatz hat das nämlich recht wenig zu tun.

|> Übrigens interessant in diesem Zusammenhang: Bis zum 486 waren
|> die Intel CPUs CISC, mit dem Pentium wurde ein Befehlsdekoder
|> mit einer semi-RISC(*) Pipeline eingefĂźhrt. Erst der P2 hat dann
|> wirklich das Konzept "voll durchgezogen". Man kann also sagen,
|> dass sich RISC auf breiter Front durchgesetzt hat, als es immer
|> noch zänkereien zwischen den Programmiererfraktionen gab, was
|> wohl das bessere Konzept sei (das war so so gegen 1996 bis
|> 1999).

Beim Pentium wurden erstmals Superskalartechniken angewandt (zwei ALU
Pipelines), wohingegen der P2 (oder der K6, um auch den Konkurrenten ins
Feld zu führen) dann den Schritt zu uOps machte, d.h. eine
letztendliche Emulation von IA32 in Hardware, ja.

Was mich generell erstaunt, ist, wie hartnäckig diese Architektur weiterverfolgt
und das schier unmögliche ermöglicht wurde. Das Programmierinterface ist
bescheiden, das Befehlsformat ein Alptraum, und trotzdem ticken die Dinger mit
aktuell 4.1GHz ... was bei Beharren auf dem ursprünglichen "bis P54C" Design
wohl kaum möglich gewesen wäre. (Wobei ich damit nun natürlich keine Diskussion
über den Unsinn von Taktrate als Leistungsmaß anzetteln möchte

|> <blauaeugigmode>
|> Du hast so eben mein Weltbild erschĂźttert, dass es immer das
|> bessere Konzept ist, dass sich durchsetzt (Evolution: Survival
|> of the fittest). Im Markt gilt demnach pseudo-Evolution:
|> Survival of the Strongest, seufz...
|> </blauaeugigmode>

....wie man auch am Beispiel VHS vs. Video2000 vs. BetaMax erkennen konnte.

Einfach mal raus mit dem Zeug, wenn es nur genügend Leute gekauft haben, wird
es ein Selbstläufer.

Rainer

 

[Marco Budde]

Kurt Harders wrote:

Was nachzurechnen sei . Aber Du wirst oft Recht haben.

Und nicht zu vergessen: die Zeit, bis man auf dem Markt ist.
Was bringt mir ein günstigerer Preis, wenn die Konkurrenz
dank z.B. C und einfach eingekauften Modulen bereits seit
einem Jahr auf dem Markt ist.

Alle Probleme? .

Viele, sieht man ja z.B. im Automotive Bereich. VW hat ja,
jedenfalls bei meinem Polo, schon Probleme eine simple Steuerung
für z.B. ein Schiebedach oder für die Fensterheber (vermutlich
via CAN) fehlerfrei zu implementieren. Oder denken wir an die
aktuellen Probleme in der Bremssoftware bei MB.

Von daher würde ich heute garnicht mehr zu Assembler greifen.
Macht einfach keinen Sinn. Eher zu C oder besser zu C++.

Auch wichtig sind dann natürlich Themen wie "Unit Tests", die
sich in Assembler auch nicht wirklich toll umsetzen lassen.

Meine Weichenantriebe habe ich in Assembler
entwickelt, und würde sagen, dass es in C nur bedingt einfacher
gewesen wäre.

Ist aber in der Regel einfacher, portierbarer und vor allem
leichter wartbar.

Und um Bemerkungen zu vermeiden: ich kann C, Java,
Pascal... Also lag es wohl nicht daran

cu, Marco

--
E-Mail: mb-news-b<ät>linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de

 

[Robert Rottmerhusen]

Marco Budde wrote:

Kurt Harders wrote:
Meine Weichenantriebe habe ich in Assembler
entwickelt, und würde sagen, dass es in C nur bedingt einfacher
gewesen wäre.

Ist aber in der Regel einfacher, portierbarer und vor allem
leichter wartbar.

Aber nur, wenn Dich der Compiler nicht ärgert ;-)

Grüsse
Robert

 

[Wolfgang Hauser]

"MaWin" <me@privacy.net> schrieb:

Der urspruengliche 8086 war genial

Hattest Du nicht erst ein paar Postings zuvor über Intel-Assembler
gelästert?

 

[Rafael Deliano]

VW hat ... schon Probleme eine simple Steuerung ...
fehlerfrei zu implementieren.
Deren Problem: da das Produkt komplex geworden

machens sies im Detail nichtmehr selbst. Sondern
erwarten daß der Zulieferer ( nachdem er vom Einkäufer
ausgequetscht wurde ) kleine schwarze Schachteln liefert
die der "System-Inginör" zum fertigen Produkt zusammen-
stöpseln kann. So einfach modular ist die Technik aber
nicht. Wenn man an der Termin- und Preisschraube dreht
wirds eher schlimmer.

Von daher würde ich heute garnicht mehr zu Assembler greifen.
Macht einfach keinen Sinn. Eher zu C oder besser zu C++.
Ich hab mir das mal bei Zulieferer ( Siemens ) kurz ansehen

können:
a) sie machen es in C, weil sie in CPUs flexibel sein
müssen ( Motorola, 166er usw.) und nur fertige
Softwaremodule aus ihrem Fundus konfigurieren wollen.
Das ist auch durch die Termine erzwungen, da die gewünschte
Vorlaufzeit <6 Monate keine echte Neuentwicklung ermöglicht.
Die Trennung von Modulen wäre einfach wenn alles in großer
Schleife läuft, aber in Multitasker kanns unübersichtlich
werden.
C eignet sich für kleine CPUs nur bedingt. Andererseits
sorgt der Kostendruck auf die Hardware dafür daß es keine
großen CPUs werden.
b) Personalkosten fressen bekanntlich shareholder-value auf.
Die Manager waren zwar selber mal durchaus kompetente
Programmierer. Aber die Leute die daselbst tatsächlich die
Fußarbeit machen sind Ingbüros, Arbeitnehmerüberlassung,
selbst die Angestellten waren oft nur seit 6 Monaten auf
dem Job. C wurde mal von/für Guru-Programmierer erfunden,
für alle anderen wäre was harmloses wie Pascal angemessener.
Vermutlich wären sie technisch mit PL/M oder FORTH besser
bedient, aber dann müssten sie selber Compiler entwickeln
und Personal schulen. AT&T ( die sonst alles in C machen )
verwendeten ehedem ( 1990 ) für manche 8051-Projekte noch
PL/M.

MfG JRD

 

[Steffen Koepf]

Atmel
stellt halt gerade auf einen 0.35um Prozess um und damit kann bzw. will
man die alten Designs offenbar nicht einfach geshrinkt weiterbauen.

Hat sich damit eigentlich auch bei der Stromaufnahme der AVRs was getan?
Zumindest bis vor einem Jahr haben die fuer mich interessanten AVRs ein
vielfaches an Strom gefressen im Vergleich zu einem vergleichbaren PIC.
Zum Beispiel 16F876.

BTW: Den allerersten AVR, den AT90S1200 gibt es immer noch.

Ja, den will man aber nicht wirklich nehmen

cu,

Steffen

 

[Wolfgang Draxinger]

Wolfgang Hauser wrote:

"MaWin" <me@privacy.net> schrieb:

Der urspruengliche 8086 war genial

Hattest Du nicht erst ein paar Postings zuvor Ăźber
Intel-Assembler gelästert?

Ich denke, das genial bezog aich auf marktpolitische
Überlegungen. Man darf es schon als Geniestreich bezeichnen,
wenn man ein IMHO unfertiges Design auf den Markt wirft, wohl
wissend, dass die Entwickler was besseres in der Tasche haben.

BTW: Erst ab dem 386er wurde die Intelarchitektur erst wirklich
interessant, aus Programmierersicht versteht ist. Immerhin
entstand Linux ja nur deswegen, weil Linus ein wenig mit dem
386er herumexperimentierte.

Wolfgang

 

[Peter Heitzer]

horst-dieter <horst.d.winzler@web.de> wrote:
: Wolfgang Draxinger wrote:

:> Genauso wie mir die PowerPC Architektur mehr liegt als der x86
:> "Kladdererdatsch". Wenn man mal AltiVec mit SSE vergleicht...
:> ähm, warum hat sich die x86 Architektur eigentlich durchgesetzt?

: Vermutlich weil Intel die besseren Propagandisten hatte(hat?).
AFAIK weil damals(TM) Speicher noch richtig teuer war und 8088-Code
ggü. 68000-Code ca. 30% kleiner ist. Ein Befehl ist beim 68K
mindestens 16Bit groß, beim 8088 gibts auch ein Byte-Befehle.
64KB Segmente waren zu der Zeit auch kein Problem, der Ur-PC hatte ja
nur 64K insgesamt.

 

[MaWin]

Wolfgang Draxinger <wdraxinger@darkstargames.de> schrieb im Beitrag <ccbem1$2es$1@svr7.m-online.net>...

Hattest Du nicht erst ein paar Postings zuvor über Intel-Assembler
gelästert?

In welchem ?

Ich denke, das genial bezog aich auf marktpolitische Überlegungen.

Quark. Marktpolitisch war Motorola sicher besser. Kamen immer 1 Jahr spaeter mit
einem Prozessor, den den 1 Jahr aelteren Intel in Benchmarks schlug. Na Klasse,
und im naechsten Jahr, bei Intels naechstem, stand Motorolas wieder hinten dran,
ich habe aber nie eine Werbung von Intel gesehen, in denen sie die 'ueberlegene
Performance' ihrer Prozessoren hervorhoben.

Man darf es schon als Geniestreich bezeichnen, wenn man ein IMHO
unfertiges Design auf den Markt wirft, wohl wissend, dass die
Entwickler was besseres in der Tasche haben.

Quark. Das war damals halt das mit der Transistoranzahl/Chip technisch machbare

BTW: Erst ab dem 386er wurde die Intelarchitektur erst wirklich
interessant, aus Programmierersicht versteht ist.

Du meinst wegen dem ab dem 386 durch Altlasten verquasten Befehlssatz ?

Immerhin entstand Linux ja nur deswegen, weil Linus ein wenig mit dem
386er herumexperimentierte.

Quark. Weil er Tanenbaums Minix-Buch hatte.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
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.