Unterschiede Z80, 8051 und 6502/6510
Torsten Junker
Im Rahmen meines Informatikstudiums werde ich demnächst 8051-
Controller zu programmieren lernen, zumindest ansatzweise. Früher habe
ich mal auf einem 6510 (Commodore C64) Assembler programmiert und
einen Z80 habe ich auch mal in Maschinensprache während meiner
Schulzeit programmiert (man googlele mal nach "LC80").
Jetzt frage ich mich, welche Vor- oder Nachteile bzw. Unterschiede die
einzelnen Prozessoren intern haben, welche werden wofür eingsetzt? Mir
geht es dabei um die Programmierung (Assembler, Maschinensprache),
nicht um die externe Anbindung von Peripherie oder Hardware (IO,
etc.). Kurzum: Gibt es irgendwo eine kompakte Übersicht mit den
Unterschieden von Z80 und 8051 (und vielleicht auch noch 6502/6510)?
Hier in de.sci.electronics schrieb mal jemand, dass man für Lernzwecke
besser einen 8051 nutzt, weil der im Vergleich zu einem Z80 nicht so
viel externe Peripherie benötigt, aber wer einen angeblich einen
vollständigen Z80 (mit gesamter Peripherie) sein eigen nennt wird
jeden 8051 wegschmeißen. Warum?
Was spricht eigentlich gegen Simulatoren für Z80 und 8051, um die
Programmierung zu lernen?
Bei einigen Controllern mit 16-Bit-Adressbus wurde Bankswitching
eingeführt, um mehr als 64 kByte adressieren zu können. Mir ist sehr
wohl klar was Bankswitching ist, nur verstehe ich nicht den Sinn
weshalb ich einem Programm plötzlich den Programmspeicher (RAM)
wegschalte um mehr Platz für was anderes zu haben. Wo ist mein
Denkfehler? Oder wird einfach nur ein Teil des gesamten Speichers
statt des ganzen Speichers umgeblendet?
Gibt es außer dem Aufwand der externen Hardware-Anbindung (eine CPU
kann ja allein gar nichts) noch andere relevante Unterschiede zwischen
Microprozessoren und Microcontrollern?
Gruß Torsten
Dieter Wiedmann
> Kurzum: Gibt es irgendwo eine kompakte Übersicht mit den
> Unterschieden von Z80 und 8051 (und vielleicht auch noch 6502/6510)?
Damals (TM) gabs immer wieder solche Schwanzvergleiche, du wirst
wohl ins Archiv deiner Unibibo schauen müssen, die entsprechenden
Zeitschriften sind locker 25 Jahre alt.
> Hier in de.sci.electronics schrieb mal jemand, dass man für Lernzwecke
> besser einen 8051 nutzt, weil der im Vergleich zu einem Z80 nicht so
> viel externe Peripherie benötigt, aber wer einen angeblich einen
> vollständigen Z80 (mit gesamter Peripherie) sein eigen nennt wird
> jeden 8051 wegschmeißen. Warum?
Von Neumann vs Harvard, und natürlich einen umfangreicheren Befehlssatz.
> Was spricht eigentlich gegen Simulatoren für Z80 und 8051, um die
> Programmierung zu lernen?
Du sollst den Lötkolben und das Zinn ehren! Ansonsten spricht nix
dagegen.
> Bei einigen Controllern mit 16-Bit-Adressbus wurde Bankswitching
> eingeführt, um mehr als 64 kByte adressieren zu können. Mir ist sehr
> wohl klar was Bankswitching ist, nur verstehe ich nicht den Sinn
> weshalb ich einem Programm plötzlich den Programmspeicher (RAM)
> wegschalte um mehr Platz für was anderes zu haben. Wo ist mein
> Denkfehler? Oder wird einfach nur ein Teil des gesamten Speichers
> statt des ganzen Speichers umgeblendet?
Letzteres.
> Gibt es außer dem Aufwand der externen Hardware-Anbindung (eine CPU
> kann ja allein gar nichts) noch andere relevante Unterschiede zwischen
> Microprozessoren und Microcontrollern?
Nicht prinzipiell.
Gruß Dieter
Holger Bruns
> Hallo!
>
> Im Rahmen meines Informatikstudiums werde ich demnächst 8051-
> Controller zu programmieren lernen, zumindest ansatzweise. Früher habe
> ich mal auf einem 6510 (Commodore C64) Assembler programmiert und
> einen Z80 habe ich auch mal in Maschinensprache während meiner
> Schulzeit programmiert (man googlele mal nach "LC80").
Ich wundere mich, wieso man sich im Informatikstudium mit 30 Jahre alten
Prozessoren beschäftigt? Wieso nix aktuelles? Wieso Homecomputerzeugs?
> Jetzt frage ich mich, welche Vor- oder Nachteile bzw. Unterschiede die
> einzelnen Prozessoren intern haben, welche werden wofür eingsetzt? Mir
> geht es dabei um die Programmierung (Assembler, Maschinensprache),
> nicht um die externe Anbindung von Peripherie oder Hardware (IO,
> etc.). Kurzum: Gibt es irgendwo eine kompakte Übersicht mit den
> Unterschieden von Z80 und 8051 (und vielleicht auch noch 6502/6510)?
Das fragt man sich als Informatikstudemt im Jahre 2007?
> Hier in de.sci.electronics schrieb mal jemand, dass man für Lernzwecke
> besser einen 8051 nutzt, weil der im Vergleich zu einem Z80 nicht so
> viel externe Peripherie benötigt, aber wer einen angeblich einen
> vollständigen Z80 (mit gesamter Peripherie) sein eigen nennt wird
> jeden 8051 wegschmeißen. Warum?
Was ist denn das für eine seltsame Frage? Ich meine, wenn du Informatik
betreibst, hast du doch ganz andere Fragestellungen als die
Computerfreaks aus dem Jahre 1980?
> Was spricht eigentlich gegen Simulatoren für Z80 und 8051, um die
> Programmierung zu lernen?
Es gibt Simulatoren und Emulatoren ohne Ende. Hier ein Einstieg:
http://www.8bit-museum.de/
> Bei einigen Controllern mit 16-Bit-Adressbus wurde Bankswitching
> eingeführt, um mehr als 64 kByte adressieren zu können. Mir ist sehr
> wohl klar was Bankswitching ist, nur verstehe ich nicht den Sinn
> weshalb ich einem Programm plötzlich den Programmspeicher (RAM)
> wegschalte um mehr Platz für was anderes zu haben. Wo ist mein
> Denkfehler? Oder wird einfach nur ein Teil des gesamten Speichers
> statt des ganzen Speichers umgeblendet?
Ja, man kann mit digitaler Logik den Adressbus eines Prozessors so
decodieren, daß sich alle möglichen Ideen für ein Bankswitching
ralisieren lasen.
> Gibt es außer dem Aufwand der externen Hardware-Anbindung (eine CPU
> kann ja allein gar nichts) noch andere relevante Unterschiede zwischen
> Microprozessoren und Microcontrollern?
Das fragst du einfach mal deinen Prof, würde ich sagen. Hmm, grübel...an
der Uni Bremen wurden vor rund 17 Jahren oder so die NDR-Bastelcomputer
mit dem 68000 aus den Abstellkammern entfernt und ins Recycling gegeben.
Und ihr werdet sogar am 6502 ausgebildet? Damit kann man doch null
machen, zumal das Ding auch noch schweinelangsam ist. Du kannst auf dem
Ding ja noch nicht einmal Linux zum Laufen bringen? Wenn es auch nur um
einen Roboter für "Jugend forscht" ginge, in der Liga für die
Grundschule, da haben sie schon "Lego Mindstorm" am Ball. Und wenn die
Älteren zu Werke schreiten, zum Beispiel für den Robocup, sieht das
unter Umständen so aus: http://www.robocup.tugraz.at/documents/me03.pdf
Ich sag das mal so: Nostalgie finde ich gut, den 6502 ebenso, auch den
Z80, aber modern finde ich die Dinger nicht. Zumal du heute einen
kompletten 6502-Rechner in ein FPGA schreiben kannst, und der rennt dann
mit ein paar hundert Megahertz Taktrate. Aber für das, was der 6502
kann, ist ein Microcntroller von Atmel und Konsorten sicher die bessere
Wahl, zumal es dafür auch Tools gibt, die du nicht in den Museen
zusammensuchen mußt.
Viele Grüße, Holger
Wolfgang Allinger
On 02 Oct 07 at group /de/sci/electronics in article
<vornahme....@gmx.de> (Torsten Junker) wrote:
>Hallo!
>
>Im Rahmen meines Informatikstudiums werde ich demnächst 8051-
>Controller zu programmieren lernen, zumindest ansatzweise. Früher habe
>ich mal auf einem 6510 (Commodore C64) Assembler programmiert und
>einen Z80 habe ich auch mal in Maschinensprache während meiner
>Schulzeit programmiert (man googlele mal nach "LC80").
>
>Jetzt frage ich mich, welche Vor- oder Nachteile bzw. Unterschiede die
>einzelnen Prozessoren intern haben, welche werden wofür eingsetzt? Mir
>geht es dabei um die Programmierung (Assembler, Maschinensprache),
>nicht um die externe Anbindung von Peripherie oder Hardware (IO,
>etc.). Kurzum: Gibt es irgendwo eine kompakte Übersicht mit den
>Unterschieden von Z80 und 8051 (und vielleicht auch noch 6502/6510)?
>
>Hier in de.sci.electronics schrieb mal jemand, dass man für Lernzwecke
>besser einen 8051 nutzt, weil der im Vergleich zu einem Z80 nicht so
>viel externe Peripherie benötigt, aber wer einen angeblich einen
>vollständigen Z80 (mit gesamter Peripherie) sein eigen nennt wird
>jeden 8051 wegschmeißen. Warum?
Der Z80 ist ein uComputer und der 8051 ein uController. Der 8051 hat
soviel im IC, dass er (die neueren jedenfalls) bzw. nur mit externen ROM
schon Aufgaben erfüllen kann. Er hat ziemlich viel Periferi an Bord, die
man bei einem Z80 extern dazustricken muss SIO, PIO, CTC...
Wenn du das aber alles hast, ist der Z80 besser zu programmieren.
Der 8051 hat schon ein paar üble Besonderheiten.
>Was spricht eigentlich gegen Simulatoren für Z80 und 8051, um die
>Programmierung zu lernen?
Nicht, wenn Du gute findest, die mit den Hardware Besonderheiten zurecht
kommen :-)
>Bei einigen Controllern mit 16-Bit-Adressbus wurde Bankswitching
>eingeführt, um mehr als 64 kByte adressieren zu können. Mir ist sehr
>wohl klar was Bankswitching ist, nur verstehe ich nicht den Sinn
>weshalb ich einem Programm plötzlich den Programmspeicher (RAM)
>wegschalte um mehr Platz für was anderes zu haben. Wo ist mein
>Denkfehler? Oder wird einfach nur ein Teil des gesamten Speichers
>statt des ganzen Speichers umgeblendet?
z.B. 4 Bänke a 16kB, für Z80, also nur Teile werden umgeschaltet:
Bank 0 muss als (E)PROM immer drinbleiben, wegen der IR-Vectoren und
Reset...
Bank 1 wird wohl auch noch von den Standard routinen benutzt, auch die
IRSR sind da gut aufgehoben, also auch PROM
Bank 2 als RAM
Bank 3 als 16k Fenster in das Riesen PROM/RAM oder was weiss ich.
Wenn man das sauber programmiert, geht es ganz gut. Die Betonung liegt
auf SAUBER, damit schließe ich C aus :-) BTDT unter Forth.
Saludos Wolfgang
>
>Gibt es außer dem Aufwand der externen Hardware-Anbindung (eine CPU
>kann ja allein gar nichts) noch andere relevante Unterschiede zwischen
>Microprozessoren und Microcontrollern?
>
>Gruß Torsten
--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
Wolfgang Allinger Paraguay reply Adresse gesetzt !
VoIP 02173 / 99 39 209 ca. 15h00..21h00 MEZ SKYPE:wolfgang.allinger
Wolfgang Allinger
On 03 Oct 07 at group /de/sci/electronics in article
<hbr...@gmx.de> (Holger Bruns) wrote:
>Torsten Junker wrote:
>> Hier in de.sci.electronics schrieb mal jemand, dass man für
>> Lernzwecke besser einen 8051 nutzt, weil der im Vergleich zu einem
>> Z80 nicht so viel externe Peripherie benötigt, aber wer einen
>> angeblich einen vollständigen Z80 (mit gesamter Peripherie) sein
>> eigen nennt wird jeden 8051 wegschmeißen. Warum?
>Ich sag das mal so: Nostalgie finde ich gut, den 6502 ebenso, auch den
>Z80, aber modern finde ich die Dinger nicht. Zumal du heute einen
>kompletten 6502-Rechner in ein FPGA schreiben kannst, und der rennt
>dann mit ein paar hundert Megahertz Taktrate. Aber für das, was der
>6502 kann, ist ein Microcntroller von Atmel und Konsorten sicher die
>bessere Wahl, zumal es dafür auch Tools gibt, die du nicht in den
>Museen zusammensuchen mußt.
Aber die alten Dinger haben den Vorteil, dass sie relativ übersichtlich
und leicht zu begreifen sind und man sie komplett verstehen kann. Von
einem Renntwiedum ähem Pentium kann ich das (für mich) nicht mehr
behaupten.
Saludos Wolfgang
Heiko Rossmann
> On 03 Oct 07 at group /de/sci/electronics in article
> <hbr...@gmx.de> (Holger Bruns) wrote:
>
>> Torsten Junker wrote:
>
>>> Hier in de.sci.electronics schrieb mal jemand, dass man für
>>> Lernzwecke besser einen 8051 nutzt, weil der im Vergleich zu einem
>>> Z80 nicht so viel externe Peripherie benötigt, aber wer einen
>>> angeblich einen vollständigen Z80 (mit gesamter Peripherie) sein
>>> eigen nennt wird jeden 8051 wegschmeißen. Warum?
>
>> Ich sag das mal so: Nostalgie finde ich gut, den 6502 ebenso, auch den
>> Z80, aber modern finde ich die Dinger nicht. Zumal du heute einen
>> kompletten 6502-Rechner in ein FPGA schreiben kannst, und der rennt
>> dann mit ein paar hundert Megahertz Taktrate. Aber für das, was der
>> 6502 kann, ist ein Microcntroller von Atmel und Konsorten sicher die
>> bessere Wahl, zumal es dafür auch Tools gibt, die du nicht in den
>> Museen zusammensuchen mußt.
>
> Aber die alten Dinger haben den Vorteil, dass sie relativ übersichtlich
> und leicht zu begreifen sind und man sie komplett verstehen kann. Von
> einem Renntwiedum ähem Pentium kann ich das (für mich) nicht mehr
> behaupten.
Wobei aktuelle Mikrocontroller ebenfalls relativ leicht begreifbar sein
können (je nach Architektur und Dokumentation *g*) Vielleicht aber auch
zu leicht für ein Informatikstudium ;) oder nicht allgemein genug...
MfG, Heiko
...der mal kurz nacheinander begonnen hat, AVR und Z80 (Taschenrechner)
in Assembler zu programmieren und mit dem AVR _wesentlich_ besser
zurecht kam...
Joerg
>>
>> Im Rahmen meines Informatikstudiums werde ich demnächst 8051-
>> Controller zu programmieren lernen, zumindest ansatzweise. Früher habe
>> ich mal auf einem 6510 (Commodore C64) Assembler programmiert und
>> einen Z80 habe ich auch mal in Maschinensprache während meiner
>> Schulzeit programmiert (man googlele mal nach "LC80").
>
>
> Ich wundere mich, wieso man sich im Informatikstudium mit 30 Jahre alten
> Prozessoren beschäftigt? Wieso nix aktuelles? Wieso Homecomputerzeugs?
>
Wir hatten um 1980 an der Uni noch mit Roehren gelernt, ist eben alles
ein bischen aelter.
Aber, und das sei besonders Torsten gesagt: Der 8051 wird hier in USA
und auch Asien haufenweise in neue Designs gesetzt. Wie es in Europa
steht, weiss ich nicht. Der Hauptgrund fuer diesen Dauerlauf a la
VW-Kaefer ist die Tatsache, dass es ihn von mehreren Herstellern gibt.
Das ist m.W. bei allen anderen uC nicht der Fall. Riesenvorteil, bei
meinen Design haeufig sogar Bedingung. Ausserdem findet man erfahrene
Programmierer dafuer beinahe in jeder Kleinstadt.
Wenn ich so hier im Haus rumsehe, wuesste ich bis auf den
Wohnzimmerthermostaten kein installiertes Geraet, was nicht mit einer
Art 8051 arbeitet.
>> Jetzt frage ich mich, welche Vor- oder Nachteile bzw. Unterschiede die
>> einzelnen Prozessoren intern haben, welche werden wofür eingsetzt? Mir
>> geht es dabei um die Programmierung (Assembler, Maschinensprache),
>> nicht um die externe Anbindung von Peripherie oder Hardware (IO,
>> etc.). Kurzum: Gibt es irgendwo eine kompakte Übersicht mit den
>> Unterschieden von Z80 und 8051 (und vielleicht auch noch 6502/6510)?
>
>
> Das fragt man sich als Informatikstudemt im Jahre 2007?
>
>> Hier in de.sci.electronics schrieb mal jemand, dass man für Lernzwecke
>> besser einen 8051 nutzt, weil der im Vergleich zu einem Z80 nicht so
>> viel externe Peripherie benötigt, aber wer einen angeblich einen
>> vollständigen Z80 (mit gesamter Peripherie) sein eigen nennt wird
>> jeden 8051 wegschmeißen. Warum?
>
>
> Was ist denn das für eine seltsame Frage? Ich meine, wenn du Informatik
> betreibst, hast du doch ganz andere Fragestellungen als die
> Computerfreaks aus dem Jahre 1980?
>
Torsten macht das schon ganz richtig. Praktische Erfahrung unter Einsatz
des Loetkolbens ist durch nichts zu ersetzen. Ausser durch noch mehr Loeten.
>> Was spricht eigentlich gegen Simulatoren für Z80 und 8051, um die
>> Programmierung zu lernen?
>
>
> Es gibt Simulatoren und Emulatoren ohne Ende. Hier ein Einstieg:
> http://www.8bit-museum.de/
>
Lieber den Loetrich einschalten und loslegen. Bringt mehr Wissen.
>> Bei einigen Controllern mit 16-Bit-Adressbus wurde Bankswitching
>> eingeführt, um mehr als 64 kByte adressieren zu können. Mir ist sehr
>> wohl klar was Bankswitching ist, nur verstehe ich nicht den Sinn
>> weshalb ich einem Programm plötzlich den Programmspeicher (RAM)
>> wegschalte um mehr Platz für was anderes zu haben. Wo ist mein
>> Denkfehler? Oder wird einfach nur ein Teil des gesamten Speichers
>> statt des ganzen Speichers umgeblendet?
>
>
> Ja, man kann mit digitaler Logik den Adressbus eines Prozessors so
> decodieren, daß sich alle möglichen Ideen für ein Bankswitching
> ralisieren lasen.
>
Der gewiefte Programmierer kommt mit dem vorhandenen Speicherplatz
(meist so gerade eben) aus :-)
[...]
--
Gruesse, Joerg
M.Randelzhofer
>> Jetzt frage ich mich, welche Vor- oder Nachteile bzw. Unterschiede die
>> einzelnen Prozessoren intern haben, welche werden wofür eingsetzt? Mir
>> geht es dabei um die Programmierung (Assembler, Maschinensprache),
>> nicht um die externe Anbindung von Peripherie oder Hardware (IO,
>> etc.). Kurzum: Gibt es irgendwo eine kompakte Übersicht mit den
>> Unterschieden von Z80 und 8051 (und vielleicht auch noch 6502/6510)?
>
> Das fragt man sich als Informatikstudemt im Jahre 2007?
>
Wenn man sich mit Computerarchitektur beschäftigen will, sind die besagten
chips aus dem letzten Jahrtausend interessante Vertreter gewisser einfacher
Architekturen, mit denen man noch begreifen kann wie ein Computer
hardwareseitig funktioniert. (Ausserdem relativ leicht in einem FPGA zu
implementieren)
Besonderheiten aller Chips (Z80,6502,8051)
- Akkumulatorbasierte Architektur
- 8bit 64k Adressraum
- CISC mit microprogramm
- kein bzw. primitives pipelining
- gab es alle nicht dei ALDI
Besonderheiten Z80:
- von Neumann Architektur
- reine CPU
- DRAM support
- Takt 2,4,6,8 MHz, ca. 3MHz/Mips
- Upgrade zu Intel 8080
- microcode für "komplexere" Befehle
- wenig "orthogonaler" Befehlssatz, d.h. viel Adressierungsarten immer mit
bestimmten Befehlen verknüpft
- Marktrenner '70-er und Anfang '80er Jahre
Besonderheiten 6502:
- von Neumann Architektur
- reine CPU
- primitives pipelining aus 2 Stufen: instruction fetch - rest, daher viel
mips pro megahertz Takt
- Takt 1,2 MHz, ca. 1MHz/Mips
- microcode für "komplexere" Befehle
- "orthogonaler" Befehlssatz, d.h. viel Adressierungsarten mit allen
Befehlen verknüpft
- Marktrenner '70-er und Anfang '80er Jahre; war in den 70-ern billigste CPU
Besonderheiten 8051:
- Havard Architektur, 64k Code, 64k Daten, auch extern
- Mikrocontroller bestehend aus CPU, Memory, I/O
- Viele Bitmanipulationsbefehle, ausserdem gibts sogar multiply und divide
- komplexes internes Registerfile, kleiner Stack, Registerbankswitching
- Takt 12 MHz, ca. 12MHz/Mips, neuere bis 100MHz
- VERMUTUNG: microcode für alle Befehle, eventuell bitserielle ALU wegen
mindestens 12 Takte für jeden SCHEISS
- Marktrenner bis heute, z.B. viele USB Controller
Eine moderne 8-core CPU ist vielleicht die billigste Anschaffung im Jahr
2007 (z.B ALDI), aber erklär mal einem Anfänger in ein paar Sätzen wie du
die z.B in Assembler programmierst ?
MIKE
--
www.oho-elektronik.de
OHO-Elektronik
Michael Randelzhofer
FPGA und CPLD Mini Module
Klein aber oho !
Kontakt:
Tel: 08131 339230
m...@oho-elektronik.de
Usst.ID: DE130097310
Holger Bruns
>> Was ist denn das für eine seltsame Frage? Ich meine, wenn du
>> Informatik betreibst, hast du doch ganz andere Fragestellungen als die
>> Computerfreaks aus dem Jahre 1980?
>>
>
> Torsten macht das schon ganz richtig. Praktische Erfahrung unter Einsatz
> des Loetkolbens ist durch nichts zu ersetzen. Ausser durch noch mehr
> Loeten.
Torsten macht aber Informatik und keine Elektrotechnik. Die
Anforderungen an den Informatiker sind andere als an den Ingenieur, der
natürlich auch löten kann. Wäre der Löter heute noch die erste Geige,
hätten wir immer noch keine grafischen Oberflächen wie KDE oder Windows,
zum Beispiel, sondern Lochstreifen und Drucker. Informatiker bauen dir
Algorithmen, Informatiker rechnen dir die Effizienz deiner Software
nach, Informatiker entwickeln dir Systeme für die fehlerfreie
Implementierung der Software und die Systemsintegration - automatisiert
und zuverläasig vom UML zum Zielcode für dein System unter Einbeziehung
harscher Sicherheitsauflagen, das macht dir nicht die Tante Ersa.
>
>>> Was spricht eigentlich gegen Simulatoren für Z80 und 8051, um die
>>> Programmierung zu lernen?
>>
>>
>>
>> Es gibt Simulatoren und Emulatoren ohne Ende. Hier ein Einstieg:
>> http://www.8bit-museum.de/
>>
>
> Lieber den Loetrich einschalten und loslegen. Bringt mehr Wissen.
Wie gesagt, es kommt auf die Disziplin drauf an.
>>> Bei einigen Controllern mit 16-Bit-Adressbus wurde Bankswitching
>>> eingeführt, um mehr als 64 kByte adressieren zu können. Mir ist sehr
>>> wohl klar was Bankswitching ist, nur verstehe ich nicht den Sinn
>>> weshalb ich einem Programm plötzlich den Programmspeicher (RAM)
>>> wegschalte um mehr Platz für was anderes zu haben. Wo ist mein
>>> Denkfehler? Oder wird einfach nur ein Teil des gesamten Speichers
>>> statt des ganzen Speichers umgeblendet?
>>
>>
>>
>> Ja, man kann mit digitaler Logik den Adressbus eines Prozessors so
>> decodieren, daß sich alle möglichen Ideen für ein Bankswitching
>> ralisieren lasen.
>>
>
> Der gewiefte Programmierer kommt mit dem vorhandenen Speicherplatz
> (meist so gerade eben) aus :-)
Mag sein. Aber Informatik ist eben nicht einfach Programmierung.
Grüße, Holger
Olaf Kaluza
>Ich wundere mich, wieso man sich im Informatikstudium mit 30 Jahre alten
>Prozessoren beschäftigt? Wieso nix aktuelles? Wieso Homecomputerzeugs?
Es ist vollkommen belanglos womit du dich beschaeftigst. Man kann von
einem Ing erwarten das er sich innerhalb kurzer Zeit in jedem
Prozessor einarbeiten kann. Was du aber lernen musst das ist der
grundsaetzliche Umgang. (Was sind Zeiger, Parameteruebergabe,
Algorythmen, usw)
Waer ich Prof wuerde ich mit Absicht etwas sehr exotisches waehlen
damit nicht die Leute die einen bestimmten Prozessor schon kennen
einen Vorteil haben. Ausserdem braeuchte ich dann bei Google nur mal
schnell nach TMS9900 zu suchen um die Pappenheimer rauszufinden die
verzweifelt was zum abschreiben suchen. :-]
Olaf
Rafael Deliano
> Unterschieden von Z80 und 8051 (und vielleicht auch noch 6502/6510)?
Es gibt in Heft 2 von www.embeddedFORTH.de eine historische Auflistung:
http://www.embeddedforth.de/temp/hist.pdf
Die ist aber fast 10 Jahre alt, einige Angaben was es noch gibt
stimmen schon nichtmehr.
a) Viele der Eigentümlichkeiten der Befehlssätze erklären sich daraus,
daß die Architektur kompatibel auf Vorgänger aufsetzen muß wie
in dem Artikel dargestellt. Am Schlimmsten wohl 68HC12:
sourcekompatibel zum 68HC11 der binärkompatibel zum 6800 war.
b) der Controller (8051 ) muß den Bus nicht herausgeführt haben kann
also Harvard sein. Das bringt Geschwindigkeitsvorteile ( vgl AVR ).
Die klassische 8 Bit CPU ( Z80 , 6502 ) ist von Neumann.
Von Neumann auf Controller gibts immer noch ( 68HC08 ) hat
kleine Kostenvorteile auf Chip, hat kleine Vorteile für
Programmierer: man kann auch Code im RAM ausführen. Ist aber
eher langsam.
c) Klassische 8 Bit CPUs sind historisch, praktisch kein Produktions-
volumen mehr.
8 Bit Controller haben weiterhin sehr breite
Anwendung. Einige Versionen wie den 68HC12 gibts optional mit
herausgeführtem Bus, aber das ist heute eher Ausnahmefall.
16/32 Controller wie M16 oder ARM7 gibts häufiger mit externem
Bus.
> Was spricht eigentlich gegen Simulatoren ... , um die
> Programmierung zu lernen?
Solange man keine Anbindung an die Hardware benötigt: kein Problem.
Die meisten grafischen Entwicklungsumgebungen haben wohl einen
integriert.
Wenn man Anbindung an realen Chip will um echte externe Hardware
zu testen: hat Motorola/Freescale recht hübsch über BDM gelöst.
Gibts für 68HC12 und neuere 68HCS08.
MfG JRD
Michael Linnemann
>>Bei einigen Controllern mit 16-Bit-Adressbus wurde Bankswitching
>>eingeführt, um mehr als 64 kByte adressieren zu können. Mir ist sehr
>>wohl klar was Bankswitching ist, nur verstehe ich nicht den Sinn weshalb
>>ich einem Programm plötzlich den Programmspeicher (RAM) wegschalte um
>>mehr Platz für was anderes zu haben. Wo ist mein Denkfehler? Oder wird
>>einfach nur ein Teil des gesamten Speichers statt des ganzen Speichers
>>umgeblendet?
> z.B. 4 Bänke a 16kB, für Z80, also nur Teile werden umgeschaltet: Bank 0
> muss als (E)PROM immer drinbleiben, wegen der IR-Vectoren und Reset...
> Bank 1 wird wohl auch noch von den Standard routinen benutzt, auch die
> IRSR sind da gut aufgehoben, also auch PROM Bank 2 als RAM
> Bank 3 als 16k Fenster in das Riesen PROM/RAM oder was weiss ich.
Es gab auch Systeme, bei denen die kompletten 64k umgeschaltet werden
konnten (oder sollten - ich habs nie ausprobiert), z.B. die
CBM610/710. Prozessor war IIRC ein 6509, ein 6502-Ableger, bei dem
über irgendwelche Zeropage-Register ein paar Portleitungen geschaltet
werden konnten.
Für die Bankumschaltung war natürlich erforderlich, dass die entsprechende
Funktion sowohl in der Ausgangs- wie in der Zielbank an den gleichen
Adressen existierte, damit der Programmfluss beim Übergang in des
Paralleluniversum wie gewünscht weiterging. Die erwähnten CBMs hatten
passende Funktionen im ROM. K.A., ob die jemals genutzt wurden, eine
Textverarbeitung passte damals in 8kBytes. In dem freien Speicher (dem,
der von den 8k noch übrig war) war der "Treiber" für die 1541-Floppy :-)
Gruß
Michael
Holger Bruns
> Es ist vollkommen belanglos womit du dich beschaeftigst. Man kann von
> einem Ing erwarten das er sich innerhalb kurzer Zeit in jedem
> Prozessor einarbeiten kann. Was du aber lernen musst das ist der
> grundsaetzliche Umgang. (Was sind Zeiger, Parameteruebergabe,
> Algorythmen, usw)
Algorithmen und Programmierung, 1. Semester:
- Ein Algorithmus ist eine terminierende Folge von Anweisungen.
- Zeiger sind Adressen von Speicherzellen.
- Parameter werden als Zeichenkette oder Pointer übergeben.
> Waer ich Prof wuerde ich mit Absicht etwas sehr exotisches waehlen
> damit nicht die Leute die einen bestimmten Prozessor schon kennen
> einen Vorteil haben.
Wer pfiffig ist, kann sich sehr schnell in eine andere
Programmiersprache als "Pascal für den Apple II" reindenken.
> Ausserdem braeuchte ich dann bei Google nur mal
> schnell nach TMS9900 zu suchen um die Pappenheimer rauszufinden die
> verzweifelt was zum abschreiben suchen. :-]
Nun ja, ich beschäftige mich rein hobbymäßig mit einem uralten
Motorola-DSP, nämlich dem 96002 und dessen Bedehlasatz. Cooles Teil,
aber natürlich nicht mehr modern. Und nur dann eine Architektur nach
John von Neumann, wenn man Programmspeicher und Datenspeicher
zusammenlegt. :-)
Grüße, Holger
Wolfgang Puffe
> Im Rahmen meines Informatikstudiums werde ich demnächst 8051-
> Controller zu programmieren lernen, zumindest ansatzweise. Früher habe
> ich mal auf einem 6510 (Commodore C64) Assembler programmiert und
> einen Z80 habe ich auch mal in Maschinensprache während meiner
> Schulzeit programmiert (man googlele mal nach "LC80").
Oh ja, auf dem guten alten LC80 habe ich auch in Maschienencode
(in Hex, nichts in Assembler oder so) programmieren gelernt.
Das gute stück liegt noch einsatzbereit hier und darf einmal pro
Jahr sein Begrüßungslied "Popkorn" (von Hot Butter?) tüteln.
W.
He...@famkoplien.de
wrote:
> Hallo!
>
> Im Rahmen meines Informatikstudiums werde ich demnächst 8051-
> Controller zu programmieren lernen, zumindest ansatzweise. Früher habe
[...]
Nur eine Frage am Rande, welche Uni ist das?
Gruß
Henry
--
----------------------------------------------------------------------
snail mail : Henry Koplien \|/
From the Center of Nowhere o(O O)o
---- eMail : He...@FamKoplien.de ---------------ooOo---(_)---oOoo-------
Torsten Junker
On 3 Okt., 10:49, He...@FamKoplien.de wrote:
>
> Nur eine Frage am Rande, welche Uni ist das?
Eine kleine Fachhochschule, die zwar einen guten Ruf im Bereich
Wirtschaftswissenschaften hat, aber oft auch der NC-Prellbock ist. Zu
deutsch: Wer wo anders wegen NC oder Überfüllung keinen Studienplatz
findet kommt hier her (und verschwindet oft auch wieder recht schnell,
etwa wenn Studienabbrecher an der "Heimat"hochschule Plätze frei
machen). Wir sind in diesem Jahrgang keine 20 Studenten in Informatik,
um die 30 in Wirtschaftsinformatik, Medieninformatik um die 70. Ob
diese Zahlen für mich gut (individuelle Betreuung) oder schlecht
(Spekulation: "Wahrscheinlich ist diese Hochschule nicht so gut wenn
da niemand Informatik studieren will!") ist weiß ich noch nicht. Ich
studiere hier weil ich für die Strecke Haustür - Hörsaal nur wenige
Minuten zu Fuß brauche, aonsonsten hätte ich mir wahrscheinlich auch
was anderes gesucht.
Gruß Torsten
Joachim Riehn
> Gibt es außer dem Aufwand der externen Hardware-Anbindung
> noch andere relevante Unterschiede zwischen
> Microprozessoren und Microcontrollern?
Bei den Mikrokontrollern kommt fast alles auf das timing an im
Bereich Milli-Sekunden und Mikro-Sekunden, nicht so sehr auf
den Datenfluss pro Sekunde. Bei den Interrupts musst du
also extra auf die Parameter-Uebergabe und die Sicherung
von Registern achten. Dies erfordert schon eine eigene
Konzentration. Du willst anscheinend in Assembler
programmieren.
> Im Rahmen meines Informatikstudiums werde ich demnächst 8051-
> Controller zu programmieren lernen, zumindest ansatzweise. Früher habe
> ich mal ... Assembler programmiert ...
> Jetzt frage ich mich, welche Vor- oder Nachteile bzw. Unterschiede die
> einzelnen Prozessoren intern haben, welche werden wofür eingsetzt?
Die 8051-er haben eigene Bitregister im RAM, die man auch gut
manipulieren kann. Im Assembler kann man damit uebersichtlich
programmieren. Ueberhaupt ist der Befehlssatz bei den 8051-ern
der uebersichtlichste, darauf kommt es bei dir wahrscheinlich
an. Die Haushaltsdisziplin bei den Kontrollern (nur wenig RAM!)
ist halt anders als bei den PC's.
Ansonsten darf man sehr wohl die Frage stellen, was das ausgedehnte
Assembler-Programmieren an Effektivitaet bringt. Hardwarenah kann
man auch in FORTH oder C programmieren, ich weiss, darueber gab
es schon Glaubenskriege in dieser Newsgroup.
Viel Erfolg, Joachim Riehn
Torsten Junker
>
> Du willst anscheinend in Assembler
> programmieren.
Wollen ist relativ. Im Rahmen der Vorlesung/ Übungen möchte ich mich
schon etwas tiefer damit beschäftigen als es die Prüfung vorsieht,
aber langfristig glaube ich nicht dass ich mit Microcontrollern viel
zu tun haben werde. Eigentlich will ich mal schauen inwieweit sich
6510-Assemblerprogrammierung und Z80-Maschinenspracheprogrammierung
vom 8051 unterscheiden, mehr so aus Neugierde.
> Ansonsten darf man sehr wohl die Frage stellen,
Man darf auch fragen ob der Himmel grün ist.
> was das ausgedehnte
> Assembler-Programmieren an Effektivitaet bringt. Hardwarenah kann
> man auch in FORTH oder C programmieren, ich weiss, darueber gab
> es schon Glaubenskriege in dieser Newsgroup.
Ich würde es an der Portierbarkeit festmachen und mich dann auch für
etwas entscheiden, was nicht Maschinensprache/ Assembler ist, aber
andererseits sieht man ja wie gut sich 8051-Ausartungen in der
industriellen Welt verankert haben und wie sie nachgefragt werden. Und
ja, Assembler und Maschinensprache issn geiles Zeugs!
Nur dem Interesse halber: Wo bekommt man eigentlich 8051-
Entwicklerboards für Lehrzwecke (also so was wie den LC80) und was
kostet so was? Also so ein Ding mit Netzteilanschluss, LC-Display und
Hex-Tastatur.
Torsten
Joachim Riehn
> On 3 Okt., 12:13, m...@private.net (Joachim Riehn) wrote:
>> Ansonsten darf man sehr wohl die Frage stellen,
>
> Man darf auch fragen ob der Himmel grün ist.
>
>> was das ausgedehnte
>> Assembler-Programmieren an Effektivitaet bringt.
Ich habe nicht gegen dich polemisiert, eher gegen die
Hochschuldidaktik, die dahinter steht.
Ich finde es schon lehrreich, zu verfolgen, was ein
guter Compiler aus dem Code in der Maschinensprache macht.
> Nur dem Interesse halber: Wo bekommt man eigentlich 8051-
> Entwicklerboards für Lehrzwecke
Hier gibt es ein paar Hinweise: http://www.c51.de
Gruss, Joachim Riehn
Holger Bruns
> Ich finde es schon lehrreich, zu verfolgen, was ein
> guter Compiler aus dem Code in der Maschinensprache macht.
Naja, manchmal ist es sogar lehrreich, sich einen Compiler selbst zu
schreiben. Hab ich mal gemacht.
Viele Grüße, Holger
Ruediger Klenner
"Rafael Deliano" schrieb
> Solange man keine Anbindung an die Hardware benötigt: kein Problem.
> Die meisten grafischen Entwicklungsumgebungen haben wohl einen
> integriert.
Wenn schon 8 bit (Z80) und Nichtcontroller, dann wäre da
HAM (Win/Linux) als wirklich vollständige Entwicklungsumgebung für
den Gameboy Advance, der selbst ja sowohl einen ARM7 wie wg. Abwärts-
kompostivität einen Z80-Clone enthält sowie bekanntermassen noch
weitere nette Hardware mehr, Graphik, Sound, SIO nach Art des
TWI und zumindest der GB color IR-Schnittstelle u.s.w.
zu nennen.
Also, warum selbst löten?
Simulator klar, aber auch Handwareanbindung gibts in HAM inklusive.
Über ein selbst zu bastelndes Linkkabel Druckerport<->GB-SIO
geht das, passendes Bootprogramm enthält der Advance schon von
Haus aus.
Also installieren, Kabel löten, loslegen! Evtll. auch erstmal ohne
Kabellöten...
Empfehlenswert, ein knapp 500 Seiten dünnes GBA-Tutorial nach
Installation von HAM sofort einmal pratkisch durchschnabbeln zum
Einstieg, auch um sich mit der vorhandenen Hardware vertraut zu
machen:
http://theharbourfamily.com/jonathan/?page_id=89
Der Appetit kommt bekanntlich beim Essen...
Doku zu den Spieljungens findet sich im Netz inzwischen zuhauf, zum
Einstieg sei genannt:
http://www.dwheeler.com/gba/index.html
Jedenfalls muss man sich nicht unbedingt ein Z80-System selbst
zusammenlöten, wenn's via ibäh doch so schöne Komplettdinger
incl. netter Graphikhardware (Blitter, Spritehandling,
Hardwarealphablending und wassesnichtallesgibt und vieles mehr)
für Appel&Ei gibt.
Tastatur am Kleinstrechner wär schön? Gut, ein Keyboard ist rein
mechanisch ein bischen gross für das kleine Ding, aber ein
chatboard anbinden über die serielle Schnittstelle geht
problemlos bzw. findet sich schon im Netz... (Standardkeyboard
geht natürlich auch, aber dann wird es weniger transportabel).
Auswahlmöglichkeiten zuhauf: Es sind gleich mehrere vollständige
Entwicklungsumgebungen in Netz vorhanden (das genannte HAM z.B.) zum
Assemblern, ARM und Z80-ähnlich, C-en und ein Pascal hab ich auch
mal irgendwo gesehen. Gameboyhardware ist im Netz inzwischen
auch sehr gut dokumentiert; nach etwas Leseübung kann man sofort
loslegen und Graphik und Sound mit Leben füllen bzw. eigene Projekte
verfolgen...
Weiterhin: Daten- und Adressbus sind vollständig, Systembus teilweise
nach aussen geführt für eigene (Speicher, I/O, CPLD oder sonstwas-)
Spielereien... was braucht das junge studentische Bastlerherz mehr?
Muss ja nicht gleich n GBDO werden, ein Datalogger a la ELV z.B. lässt
sich locker selbst entwickeln/basteln und mit wesentlich besserer
Software als genanntes Beispiel ausstatten, z.B. Datenausgabe via
IRDA (der gameboy color hat IR-Schnittstelle) wär problemlos
möglich oder auch über die serielle Schnittstelle.
Momentan wird das Buch von M. Mühlhaus: "Messen und Steuern mit dem
Gameboy" (Franzis) für ein Fragezeichen exkl. Versand. verscherbelt.
Auch wenn man das Buch dem Anfänger nur bedingt empfehlen kann, weil
so viele Flüchtigkeitsfehler bis hin zu groben sprachlichen Falsch-
heiten enthalten sind, lässt sich damit, cum grano salis konsumiert,
doch etwas anfangen: Datenloggerprojekt findet sich in dem Buch,
incl. Soft- und Hardware (als Anregung, kann man besser machen).
Sonstige Anregungen kann man sich bei Tante Google zuhauf aufzählen
lassen, http://marc.rawer.de/Gameboy/ wär ein Beispiel.
Stefan Brörring
> Entwicklerboards für Lehrzwecke (also so was wie den LC80) und was
> kostet so was? Also so ein Ding mit Netzteilanschluss, LC-Display und
> Hex-Tastatur.
Braucht man nicht.
Moderne 8031 Derivate, z.B. mit Flash von Atmel AT89F51 o.ä. sind per
ICSP programmierbar. LCD-Display läßt sich über wenige Leitungen
anschließen. Für den Prozessor selbst reicht Stromversorgung,
Resetbeschaltung, eventuell Quarz
Das ganze läßt sich leicht auf einer Lochrasterplatte aufbauen.
Ansonsten einfach selber eine Platine machen. Für sowas reicht eine
einseitige Platine.
Dasselbe gilt für viele AVR Prozessoren, z.B. ATmega16, 8535 usw.
Hex-Tastatur braucht man nicht, wenn man einen PC als Entwicklungssystem
verwendet und entweder auf ein Monitorprogramm verzichtet, oder die
Bedienung über Uart mit dem PC macht.
Es gibt aber auch Experimentierboards zu kaufen. Ich glaube, bei Pollin
gabs mal was für < 20,- €.
Gruß
Stefan DF9BI
Joerg
>>> Was ist denn das für eine seltsame Frage? Ich meine, wenn du
>>> Informatik betreibst, hast du doch ganz andere Fragestellungen als
>>> die Computerfreaks aus dem Jahre 1980?
>>>
>>
>> Torsten macht das schon ganz richtig. Praktische Erfahrung unter
>> Einsatz des Loetkolbens ist durch nichts zu ersetzen. Ausser durch
>> noch mehr Loeten.
>
>
> Torsten macht aber Informatik und keine Elektrotechnik. Die
> Anforderungen an den Informatiker sind andere als an den Ingenieur, der
> natürlich auch löten kann. Wäre der Löter heute noch die erste Geige,
> hätten wir immer noch keine grafischen Oberflächen wie KDE oder Windows,
> zum Beispiel, sondern Lochstreifen und Drucker. Informatiker bauen dir
> Algorithmen, Informatiker rechnen dir die Effizienz deiner Software
> nach, Informatiker entwickeln dir Systeme für die fehlerfreie
> Implementierung der Software und die Systemsintegration - automatisiert
> und zuverläasig vom UML zum Zielcode für dein System unter Einbeziehung
> harscher Sicherheitsauflagen, das macht dir nicht die Tante Ersa.
>
Schon klar, meine Schwester hatte das studiert. Doch wir sollten keine
Schmalspurwissenschaftler erziehen. Ist bei mir aehnlich, habe zum
Beispiel im Studium Festigkeitslehre und anderes bei den Maschinenbauern
mitgemacht. Die Klausur haette ich allerdings nicht mitschreiben duerfen
(hatte peinlicherweise bestanden und dann ordentlich was auf die Muetze
bekommen). Und heute? Na, sehen wir mal eben auf den Schreibtisch hier,
was fuer heute anliegt. Re-Design einer elektronisch gesteuerten
Pumpenanlage, haufenweise Ventile, Motoren, Mischung von Substanzen etc.
Auch nicht gerade Hochfrequenztechnik, muss aber trotzdem bis Ende der
Woche fertig sein. Naechste Woche kommt ein chemisches Analysegeraet und
ein Review einer Bahntechnikgeschichte, die Woche danach Lichtfaserkram.
Und so weiter.
Im uebrigen waere die Welt fuer mich schoener und praktischer, wenn wir
kein Windows haetten 8-D
>>
>>>> Was spricht eigentlich gegen Simulatoren für Z80 und 8051, um die
>>>> Programmierung zu lernen?
>>>
>>>
>>>
>>>
>>> Es gibt Simulatoren und Emulatoren ohne Ende. Hier ein Einstieg:
>>> http://www.8bit-museum.de/
>>>
>>
>> Lieber den Loetrich einschalten und loslegen. Bringt mehr Wissen.
>
>
> Wie gesagt, es kommt auf die Disziplin drauf an.
>
Etwas mit eigenen Haenden geschaffen zu haben, diese Erfahrung ist durch
nichts zu ersetzen.
>>>> Bei einigen Controllern mit 16-Bit-Adressbus wurde Bankswitching
>>>> eingeführt, um mehr als 64 kByte adressieren zu können. Mir ist sehr
>>>> wohl klar was Bankswitching ist, nur verstehe ich nicht den Sinn
>>>> weshalb ich einem Programm plötzlich den Programmspeicher (RAM)
>>>> wegschalte um mehr Platz für was anderes zu haben. Wo ist mein
>>>> Denkfehler? Oder wird einfach nur ein Teil des gesamten Speichers
>>>> statt des ganzen Speichers umgeblendet?
>>>
>>>
>>>
>>>
>>> Ja, man kann mit digitaler Logik den Adressbus eines Prozessors so
>>> decodieren, daß sich alle möglichen Ideen für ein Bankswitching
>>> ralisieren lasen.
>>>
>>
>> Der gewiefte Programmierer kommt mit dem vorhandenen Speicherplatz
>> (meist so gerade eben) aus :-)
>
>
> Mag sein. Aber Informatik ist eben nicht einfach Programmierung.
>
Ist es aber "auch". Und selbst wenn es nicht so waere, man muss ueber
den Tellerrand gucken. Ein Leben lang eine Schmalspurkarriere mit
garantierten Pensionsanspruechen hinlegen zu koennen, das war mal vor
Jahrzehnten moeglich, aber nicht mehr heute.
Rainer Buchty
alli...@brain.net (Wolfgang Allinger) writes:
|> Aber die alten Dinger haben den Vorteil, dass sie relativ übersichtlich
|> und leicht zu begreifen sind und man sie komplett verstehen kann.
Das ist ein Atmel AVR aber auch. Sogar leichter, weil der Befehlssatz
sauber aufgebaut ist und man eben *nicht* eine Unterscheidung z.B. in
Akku und Indexregister hat.
8051 kann ich insofern noch verstehen, als daß die Architektur heute
leider ja immer noch aktiv lebt -- gleiches gilt für PIC. 6502 hingegen
scheint weitgehend ausgestorben zu sein, auch wenn WDC damit scheinbar
immer noch Geld verdient.
Allerdings finde ich es durchaus sinnvoll, wenn sich Informatikstudenten
von heute auch mal wieder Gedanken um Ressourcenbeschränkung machen, denn
die letzten Jahrzehnte wurde ja eher die Denke eingetrichtert, daß man
aus allem erst mal ein sauberes Objektmodell ableitet, der Compiler richtet's
dann schon -- und wenn es zu langsam ist und zu viel Speicher braucht,
warten wir auf die nächste Generation von Intel-Prozessoren und Preisverfall
im Speicherbereich...
Rainer
Henning Paul
>> Mag sein. Aber Informatik ist eben nicht einfach Programmierung.
>
> Ist es aber "auch".
Nein, "computer science" ist Programmierung. Informatik ist die Lehre
der Informationsverarbeitung.
Gruß
Henning
--
henning paul home: http://home.arcor.de/henning.paul
PM: henni...@gmx.de , ICQ: 111044613
Rainer Buchty
Gab es bei ALDI in Form des "Aldi-C64" mit Schrumpfplatine...
Zum Rest:
[Z80]
|> - Takt 2,4,6,8 MHz, ca. 3MHz/Mips
Bei minimal 4 Takzyklen pro Befehl halte ich die MIPS-Aussage für etwas
optimistisch. Der Z80 brauchte pro Befehl 1-6 sogenannter Maschinenzyklen,
wobei ein M-Zyklus zwischen 3 und 6 Taktzyklen lang war; Minimum waren
IIRC die besagten 4 Taktzyklen für die einfachsten Befehle.
[6502]
|> - primitives pipelining aus 2 Stufen: instruction fetch - rest, daher viel
|> mips pro megahertz Takt
Kein Pipelining, sonst wär's ja überlappend gewesen. War es aber nicht.
Stattdessen grundsätzlich 2 Taktzyklen oder mehr pro Befehl, wobei der
zweite Zyklus ggf. für die Tonne war und gar nichts zum Befehl selbst
beitrug.
Da ein Befehl mindestens 2, maximal 7 (für gewisse "illegal opcodes" bis
zu 8) Zyklen benötigte, war da auch nicht viel mit "vielen MIPS"; da der
durchschnittliche Befehl indes so zwischen 2 und 4 Taktzyklen benötigte,
stand er aber im Vergleich ganz ordentlich da.
Als Faustregel seinerzeit galt, daß ein 3.5MHz-Z80 ungefähr so schnell
war wie ein 1MHz-6502.
[6502]
|> - Takt 1,2 MHz, ca. 1MHz/Mips
Die MIPS-Angabe halte ich für sehr gewagt, schon allein ein Programm
aus lauter NOPs erzielt bei 1MHz nur 0,5MIPS...
[6502]
|> - microcode für "komplexere" Befehle
Stimmt so nicht. *Alle* Befehle wurden zwar über eine Matrix dekodiert,
das eigentliche Design war aber hardwired.
Mikroprogramm würde bedeuten, daß jeder Makrobefehl seinen Zeiger in
ein Mikroprogrammfeld hätte, welches dann auf der eigentlichen Maschine
abgearbeitet würde. Gibbet hier nicht. Der Dekoder treibt direkt den
internen Zustandsautomaten, Register-File, ALU und I/O.
[8051]
|> - Takt 12 MHz, ca. 12MHz/Mips, neuere bis 100MHz
|> - VERMUTUNG: microcode für alle Befehle, eventuell bitserielle ALU wegen
|> mindestens 12 Takte für jeden SCHEISS
Also: Der ursprüngliche 8051 unterschied zwischen Taktzyklus und
Maschinenzyklus. Aus den 12MHz, die Du reingesteckt hast, kamen somit
effektiv 0.5-1MIPS raus (manche Befehle brauchen 2 Maschinenzyklen), in
denen die einzelnen Schritte für einen Befehl abgearbeitet wurden.
Aber 12MHz klang schön viel...
Da die Architektur aus den mittleren 1970ern stammt, bezweifle ich
allerdings stark, daß sie mikroprogrammiert ist. Im Gegenteil, das starre
Korsett von 12-24 Schritten pro Befehl klingt mir eher nach durchtickerndem
Zustandsautomat (fn(x) oder NOP pro Taktschritt), d.h. noch rudimentärer
als beim 6502, weil der zugrundeliegende Zustandsautomat letztendlich
zu einem Bandwurm ausgewalzt wurde.
Auf die Schnelle habe ich jedoch keinen Beleg oder Widerspruch hierzu
gefunden.
Rainer
Rainer Buchty
Henning Paul <henni...@gmx.de> writes:
|> Joerg schrieb:
|>
|> >> Mag sein. Aber Informatik ist eben nicht einfach Programmierung.
|> >
|> > Ist es aber "auch".
|>
|> Nein, "computer science" ist Programmierung. Informatik ist die Lehre
|> der Informationsverarbeitung.
Ich würde über diese Begrifflichkeiten nicht streiten, denn die Unterscheidung
zwischen "computer engineering", "computer science" und "informatics" wurde
im Deutschen nie in dieser Form gemacht und auch die Rückübersetzung der
deutschen "Informatik" tut sich hinreichend schwer.
Zu Zeiten, als die "Informatik" sich als eigener Wissenschaftszweig an den
Unis etablierte -- und hier je nach Hochschule entweder der Mathematik oder
der Elektrotechnik entsprang -- , war sie eine bunte Mischung. Und ist sie
doch letztendlich bis heute, drum unterscheiden wir hierzulande eben zwischen
"technischer", "praktischer" und "theoretischer" Informatik.
Aber: Wo willst Du z.B. Mikroarchitektur, zweifelsohne ein Gebiet der
technischen Informatik, ansiedeln? Ist das nun "engineering", weil man
letztendlich an der Architektur bastelt, ist es "informatics", weil die
sinnvolle Konstruktion von beispielsweise Prädiktoren mehr beinhaltet,
als Programmieren und Rechnerarchitektur -- oder ist es doch ganz allgemein
"computer science"?
Rainer
Wolfgang Allinger
On 03 Oct 07 at group /de/sci/electronics in article
>Nur dem Interesse halber: Wo bekommt man eigentlich 8051-
>Entwicklerboards für Lehrzwecke (also so was wie den LC80) und was
>kostet so was? Also so ein Ding mit Netzteilanschluss, LC-Display und
>Hex-Tastatur.
Sieh Dir mal silabs (ex cygnal) F3xx Familie an. z.B. F310. Da kostet(e)
die komplette Entwicklungsumgebung 99$ incl. Target-Board, ein weiteres
TB 50$. Bloss eine Anzeige ist nicht dran, aber ansonsten kannste recht
viel damit machen. Serielle Schnittstelle und Flash-Loader samt debugger
sind durchaus brauchbar.
Joerg
Nun, einen Arbeitgeber interessiert das alles nicht. Der hat diese und
jene Projekte durchzuziehen und der Kandidat muss geeignet sein, das
alles mehr oder weniger in Alleinregie durchzuziehen. Schmalspur ist
nicht, die Leute erwarten Generalisten. Mich hat auch nie jemand
gefragt, was ich denn ganz speziell fuer ein Ingenieur bin. Weil das gar
nicht so wichtig ist.
Die stellen einen Software Manager oder Ingenieur ein und ob der nun CS,
Informatiker oder sonstwie heisst, das juckt keinen. Der muss eben nur
termingerecht die neue Super-Gizmo V3.4 am 15.Dezember abliefern.
Wolfgang Allinger
On 03 Oct 07 at group /de/sci/electronics in article
>In article <5mga4hF...@mid.individual.net>,
> "M.Randelzhofer" <techs...@gmx.de> writes:
>[8051]
|>> - Takt 12 MHz, ca. 12MHz/Mips, neuere bis 100MHz
|>> - VERMUTUNG: microcode für alle Befehle, eventuell bitserielle ALU
|>> wegen mindestens 12 Takte für jeden SCHEISS
>Also: Der ursprüngliche 8051 unterschied zwischen Taktzyklus und
>Maschinenzyklus. Aus den 12MHz, die Du reingesteckt hast, kamen somit
>effektiv 0.5-1MIPS raus (manche Befehle brauchen 2 Maschinenzyklen),
>in denen die einzelnen Schritte für einen Befehl abgearbeitet wurden.
>
>Aber 12MHz klang schön viel...
Er war trotzdem für 1978 recht flott und hatte viel Periferi an Bord.
>Da die Architektur aus den mittleren 1970ern stammt, bezweifle ich
>allerdings stark, daß sie mikroprogrammiert ist.
Ich bin mir ziemlich sicher, dass sie Mikrocode hatten. s.u.
>Im Gegenteil, das starre Korsett von 12-24 Schritten pro Befehl klingt
>mir eher nach durchtickerndem Zustandsautomat (fn(x) oder NOP pro
>Taktschritt), d.h. noch rudimentärer als beim 6502, weil der
>zugrundeliegende Zustandsautomat letztendlich zu einem Bandwurm
>ausgewalzt wurde.
>
>Auf die Schnelle habe ich jedoch keinen Beleg oder Widerspruch hierzu
>gefunden.
BTDT
es gab 8031 und Z80, die man durch Spikes auf der VCC bzw. Reset so
durcheinanderbringen konnte, dass sie vergessen haben, was sie sind.
Sah lustig auf dem Logicanalysator aus, wenn der Z80 keine DMA Zyklen
mehr machte, dafür nur noch OPCfetches... Beim 8051 hab ich vergessen,
was der bei Spikes veranstalten konnte. War aber auch ekelig.
Mein Kollege hatte auch mal einen Z80, bei dem der Tauschregistersatz
nicht funzte. Den hat er jahrelang wie einen Augapfel gehütet und immer
in den Tester geschoben, wenn ein Vertreter seinen Tester mal wieder
übern grünen Tee lobte. Das gab bedröppelte Gesichter :-)
Wolfgang Allinger
On 03 Oct 07 at group /de/sci/electronics in article
>Nun, einen Arbeitgeber interessiert das alles nicht. Der hat diese und
>jene Projekte durchzuziehen und der Kandidat muss geeignet sein, das
>alles mehr oder weniger in Alleinregie durchzuziehen. Schmalspur ist
>nicht, die Leute erwarten Generalisten. Mich hat auch nie jemand
>gefragt, was ich denn ganz speziell fuer ein Ingenieur bin. Weil das
>gar nicht so wichtig ist.
>
>Die stellen einen Software Manager oder Ingenieur ein und ob der nun
>CS, Informatiker oder sonstwie heisst, das juckt keinen. Der muss eben
>nur termingerecht die neue Super-Gizmo V3.4 am 15.Dezember abliefern.
Jau, und alles, nachdem die Specs am 14.12. zuletzt komplett
umgeschmissen wurden :-)
Thorsten Oesterlein
Hallo!
> Algorithmen und Programmierung, 1. Semester:
>
> - Parameter werden als Zeichenkette oder Pointer übergeben.
Lernt man das echt so?
> Grüße, Holger
Liebe Grüße,
Thorsten
Joerg
> |> Aber die alten Dinger haben den Vorteil, dass sie relativ übersichtlich
> |> und leicht zu begreifen sind und man sie komplett verstehen kann.
>
> Das ist ein Atmel AVR aber auch. Sogar leichter, weil der Befehlssatz
> sauber aufgebaut ist und man eben *nicht* eine Unterscheidung z.B. in
> Akku und Indexregister hat.
>
> 8051 kann ich insofern noch verstehen, als daß die Architektur heute
> leider ja immer noch aktiv lebt -- gleiches gilt für PIC. 6502 hingegen
> scheint weitgehend ausgestorben zu sein, auch wenn WDC damit scheinbar
> immer noch Geld verdient.
>
Der 8051 lebt deshalb noch, weil er 2nd Sources hat. Ein anderer uC kann
das nur erreichen, wenn man auch bei ihm 2nd Sources zulaesst. Sehe ich
allerdings nicht kommen, also werden wir den 8051 vermutlich auch in 10
Jahren noch in neuen Designs finden. Nicht nur bei mir ...
> Allerdings finde ich es durchaus sinnvoll, wenn sich Informatikstudenten
> von heute auch mal wieder Gedanken um Ressourcenbeschränkung machen, denn
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Amen!
> die letzten Jahrzehnte wurde ja eher die Denke eingetrichtert, daß man
> aus allem erst mal ein sauberes Objektmodell ableitet, der Compiler richtet's
> dann schon -- und wenn es zu langsam ist und zu viel Speicher braucht,
> warten wir auf die nächste Generation von Intel-Prozessoren und Preisverfall
> im Speicherbereich...
>
Wobei die Festplatten bei diesem Werteverfall nicht mithalten und die
Kisten deshalb immer lahmer werden, egal wieviel an Silizium drinsteckt.
Bis dato hat noch kein "moderner" Computer die Effizienz der DOS Zeiten
erreicht. Mich erschrickt manchmal, wie schnell DOS Programme auf so
einem 2GHz Intel Prozessor abduesen. Klick ... Mist, geht wohl nicht
mehr ... Huch, wo kommt denn dieser Ergebnis File her?
Olaf Kaluza
>Der 8051 lebt deshalb noch, weil er 2nd Sources hat. Ein anderer uC kann
>das nur erreichen, wenn man auch bei ihm 2nd Sources zulaesst.
Ich weiss nicht ob das noch so gilt. Es ist natuerlich richtig wenn
man in Assembler programmiert. Aber wer macht das heute noch?
Sobald ich in C schreibe ist mir der drunterliegende Prozessor
ziemlich egal. Ich hab schon jede Menge Sachen zwischen 68332, AVR und
R8C/M16C umgezogen ohne da ein Problem zu haben.
Du musst dich dann ja nur um die andere Hardware im Prozessor
kuemmern. Ich weiss es gibt MCS51 die auch da sehr kompatibel sind,
aber das gilt eigentlich nur wenn du das Dingen in seiner
Standardkonfiguration verwendet.
Ansonsten scheinen die ARM-Derivate ja eine aehnliche Verbreitung zu
finden, aber da ist es auch nicht 1:1 kompatible.
Olaf
Joerg
>
> >Der 8051 lebt deshalb noch, weil er 2nd Sources hat. Ein anderer uC kann
> >das nur erreichen, wenn man auch bei ihm 2nd Sources zulaesst.
>
> Ich weiss nicht ob das noch so gilt. Es ist natuerlich richtig wenn
> man in Assembler programmiert. Aber wer macht das heute noch?
> Sobald ich in C schreibe ist mir der drunterliegende Prozessor
> ziemlich egal. Ich hab schon jede Menge Sachen zwischen 68332, AVR und
> R8C/M16C umgezogen ohne da ein Problem zu haben.
>
Das nutzt nur dem Einkaeufer nichts, wenn ihm die Haendler der Reihe
nach mitteilen, dass der gewuenschte Controller bis mindestens
Weihnachten nicht lieferbar ist.
Wenn Du dann jedesmal ein neues Layout machen musst, kannst Du Dir
manchen Urlaub trotz gebuchtem Flug von der Backe putzen. BTDT. Alle
nach Fehmarn geduest, ich nicht. Und es war nicht mal mein Design
gewesen. Grmpf.
> Du musst dich dann ja nur um die andere Hardware im Prozessor
> kuemmern. Ich weiss es gibt MCS51 die auch da sehr kompatibel sind,
> aber das gilt eigentlich nur wenn du das Dingen in seiner
> Standardkonfiguration verwendet.
>
> Ansonsten scheinen die ARM-Derivate ja eine aehnliche Verbreitung zu
> finden, aber da ist es auch nicht 1:1 kompatible.
>
Nicht 1:1 kompatibel = Nutzt nichts bei "Allocation".
Holger Bruns
>> - Parameter werden als Zeichenkette oder Pointer übergeben.
>
>Lernt man das echt so?
Ob man das so lernt, weiß ich nicht. Aber "call by value" gleich
Zeichenkette (auch mit der Länge eins) und "call by reference" würde ich
meinen, lernt man so.
Grüße, Holger
Joerg
>
>>Wenn Du dann jedesmal ein neues Layout machen musst, kannst Du Dir
>>manchen Urlaub trotz gebuchtem Flug von der Backe putzen. BTDT. Alle
>>nach Fehmarn geduest, ich nicht.
>
>
>
> Ihr fliegt nach Fehmarn in den Urlaub? Boah.
>
In dem Fall nicht, die Leute sind von Solingen dahin gefahren. Der
Entwicklungsleiter und ich wollten auf unseren Rennraedern raufduesen.
Wurde nichts draus :-(
> Gruß,
> U. (der vor vielen Jahren noch das Vergnügen hatte, Chuck Peddle, den
> Entwickler des 6502, persönlich kennenzulernen. Ein pfiffiger Mensch.)
Er hat auch am Commodore PET mitgewerkelt. Der erste Computer, den ich
hautnah erleben durfte. Sehr huebsches Geraet, nur die EMV hatten sie
vergeigt, denn nach so einem Vorfall lernte ich die Kiste kennen.
Vollabsturz, war einiges abgebrutzelt, nachdem ich ein neu entwickeltes
Zuendschaltgeraet testete. Mit Abblock-Cs hatten sie es noch nicht so.
Das war so schlimm, dass der Programmierer an diesem Tag wieder anfing
zu rauchen :-(
Rainer Buchty
Joerg <notthis...@removethispacbell.net> writes:
|> Wobei die Festplatten bei diesem Werteverfall nicht mithalten und die
|> Kisten deshalb immer lahmer werden, egal wieviel an Silizium drinsteckt.
|> Bis dato hat noch kein "moderner" Computer die Effizienz der DOS Zeiten
|> erreicht. Mich erschrickt manchmal, wie schnell DOS Programme auf so
|> einem 2GHz Intel Prozessor abduesen. Klick ... Mist, geht wohl nicht
|> mehr ... Huch, wo kommt denn dieser Ergebnis File her?
Vor zwei Monaten oder so war ja auf Slashdot ein Vergleich zwischen
Apple IIGS und einem aktuellen Athlon-System... Verglichen wurden "usability",
"boot time" usw.
Letztendlich schnitt der Apple bei so ziemlich allem besser ab als das
Athlon-System, denn selbiges faßte sich auch nicht schneller an, war noch
"direkter" zu bedienen.
Lediglich gewisse "high-performance"-Anwendungen wie z.B. MP3-Encoding und
-playback gingen (natürlich) nicht.
Auch wenn der Vergleich sicherlich zu einem guten Teil humoristisch gemeint
war, zeigt er doch das, was Du oben schreibst. Von der seit damals um den
Faktor 1000 gestiegenen Taktfrequenz (4MHz 65816 vs. 4Ghz-x86), dem um
ca. den selben Faktor gestiegenen Hauptspeicher (1MB vs. 1GB), die
noch viel mehr gestiegene Festplattenkapazität merken wir heute kaum etwas.
Platten sind ab Anschaffung nach wie vor gleich zu 50% voll (was natürlich
auch daran liegt, daß wir da gleich mal unsere Daten-Altlasten draufkippen)
und vom Rest merken wir kaum was, da uns ständig neue Ideen einfallen, die
Ressourcen niederzuknüppeln.
Ich frag mich ja mittlerweile ernsthaft, wie die ein nichtmal *so* schlechtes
Schachprogramm in den 1kB eines "stock" ZX81 unterbringen konnten. Da gingen
ja bereits für die Anzeige 768 Byte für ab, da man jede Zeile bis zum Ende
belegte...
Rainer
Joerg
> |> Wobei die Festplatten bei diesem Werteverfall nicht mithalten und die
> |> Kisten deshalb immer lahmer werden, egal wieviel an Silizium drinsteckt.
> |> Bis dato hat noch kein "moderner" Computer die Effizienz der DOS Zeiten
> |> erreicht. Mich erschrickt manchmal, wie schnell DOS Programme auf so
> |> einem 2GHz Intel Prozessor abduesen. Klick ... Mist, geht wohl nicht
> |> mehr ... Huch, wo kommt denn dieser Ergebnis File her?
>
> Vor zwei Monaten oder so war ja auf Slashdot ein Vergleich zwischen
> Apple IIGS und einem aktuellen Athlon-System... Verglichen wurden "usability",
> "boot time" usw.
>
> Letztendlich schnitt der Apple bei so ziemlich allem besser ab als das
> Athlon-System, denn selbiges faßte sich auch nicht schneller an, war noch
> "direkter" zu bedienen.
>
Vor allem, wenn man sich die Prozessoren ansieht. Hatte gestern den
neuen Dell aufgemacht, zu sehen, wie ich die Floppy Laufwerke da
reinzwaenge. Der Pentium Dual-Core da drin hat die Groesse eines
Moped-Zylinderkopfes und sieht auch so aehnlich aus. Oben drauf ein
Luefter in voller Normalgroesse. Ein Monster.
> Lediglich gewisse "high-performance"-Anwendungen wie z.B. MP3-Encoding und
> -playback gingen (natürlich) nicht.
>
> Auch wenn der Vergleich sicherlich zu einem guten Teil humoristisch gemeint
> war, zeigt er doch das, was Du oben schreibst. Von der seit damals um den
> Faktor 1000 gestiegenen Taktfrequenz (4MHz 65816 vs. 4Ghz-x86), dem um
> ca. den selben Faktor gestiegenen Hauptspeicher (1MB vs. 1GB), die
> noch viel mehr gestiegene Festplattenkapazität merken wir heute kaum etwas.
>
Vor allem sind die Zugriffszeiten nicht mitgewachsen. Das koennen sie
erst, wenn die Festspeicher nicht mehr mechanisch sind.
> Platten sind ab Anschaffung nach wie vor gleich zu 50% voll (was natürlich
> auch daran liegt, daß wir da gleich mal unsere Daten-Altlasten draufkippen)
> und vom Rest merken wir kaum was, da uns ständig neue Ideen einfallen, die
> Ressourcen niederzuknüppeln.
>
> Ich frag mich ja mittlerweile ernsthaft, wie die ein nichtmal *so* schlechtes
> Schachprogramm in den 1kB eines "stock" ZX81 unterbringen konnten. Da gingen
> ja bereits für die Anzeige 768 Byte für ab, da man jede Zeile bis zum Ende
> belegte...
>
Mein Vater musste eine komplette Walzstrasse mit 2KB Kernspeicher
automatisieren, weil das der groesste Speicher war, den IBM damals
hatte. Hat funktioniert, lief ewig.
Rainer Buchty
Ulrich G. Kliegis <Ulli....@kliegis.de> writes:
|> Geniale Prozessoren aus der Zeit waren dann noch der TI990 (?) und
|> 9900 (16 bit) (mit memory-mapped Registersätzen)
Ich müßte jetzt tief in meine Bibliothek gehen, aber hatten die streng
genommen überhaupt Registersätze im eigentlichen Sinn? Das war doch die
goldene Zeit, als Speicher gerade mindestens doppelt so schnell wie die
CPU war und man deshalb auf die Idee verfiel, daß es eine eigene Register-
bank gar nicht mehr braucht und daher Mem-to-Mem gar nicht so unsinnig
war, wie das heute klingt.
|> der 1802 von RCA
Wundert mich, daß der derart untergegangen ist. IIRC gab's den mitte der
70er(!) schon mit 6.5MHz -- und radhard, drum tickt er ja (ebenfalls IIRC)
in den Voyager-Sonden.
Auch der (Signetics?) 2650 kam ja kaum im Mainstream an.
|> HardCore-Fraktion die BitSlices von AMD
Ich weiß, wo die heute noch in der Ausbildung verwendet werden. Zwar nurmehr
im Emulator, aber trotzdem :)
Rainer
Joerg
>
>>Ich frag mich ja mittlerweile ernsthaft, wie die ein nichtmal *so* schlechtes
>>Schachprogramm in den 1kB eines "stock" ZX81 unterbringen konnten. Da gingen
>>ja bereits für die Anzeige 768 Byte für ab, da man jede Zeile bis zum Ende
>>belegte...
>
>
>
> Neulich hörte ich in einem Vortrag über embedded processors das
> statement, daß ein ein-Pixel-großes Display schon ca. 800 Byte
> Speicher wegnehme. Ich habe sehr ungläubig geguckt, worauf die
> Vortragende, ansonsten eine sehr nette Bescheidwisserin, was von
> Overhead, Header-Info und blafasel sagte. Wir Grauhaarigen im Publikum
> wechselten schmunzelnde Blicke.
>
Kannst Du getrost in die Schublade "Unsinn" legen. Mache gerade ein
Review von einem uC, wo das aus unerfindlichen Gruenden nur ein Achtel
Byte pro Pixel sind. <grins>
> Gruß,
> U. (der auf seinem alten Wordstar 3.0 unter CPM genauso schnell tippen
> konnte wie auf den neueren Kisten. Allerdings kommt es mir so vor, daß
> die Tastaturscanner seit dem Übergang von Windows 3.11 auf Win98
> merkwürdig geworden sind - Schlagartig nahmen damals Fheler wie eben
> dieser zu: Buchstabenvertasuchungen, die ich auf fürheren Systemen bei
> gleichen Fingern nicth so oft, ja, praktisch nie, gehabt habe. Hier
> mal absichtlich unkorrigiert gelassen. Oder seh ich da Gespenster?)
Geht mir auch so. Unter DOS Word fast nie Tippfehler, unter Win-Does
viel mehr. Manchmal tippe ich ins nichts und die Zeichen kommen dann
erst eine Sekunde spaeter. Nervig.
Ruediger Klenner
"Joerg" schrieb:
> Kannst Du getrost in die Schublade "Unsinn" legen. Mache gerade ein
> Review von einem uC, wo das aus unerfindlichen Gruenden nur ein Achtel
> Byte pro Pixel sind. <grins>
>
vielleicht sehe ich ja den Wald vor lauter Bäumen... aber was ist
daran falsch?
Torsten Junker
On 3 Okt., 22:35, Ulrich G. Kliegis <Ulli.use...@kliegis.de> wrote:
>
> U. (der auf seinem alten Wordstar 3.0 unter CPM genauso schnell tippen
> konnte wie auf den neueren Kisten. Allerdings kommt es mir so vor, daß
> die Tastaturscanner seit dem Übergang von Windows 3.11 auf Win98
> merkwürdig geworden sind - Schlagartig nahmen damals Fheler wie eben
> dieser zu: Buchstabenvertasuchungen, die ich auf fürheren Systemen bei
> gleichen Fingern nicth so oft, ja, praktisch nie, gehabt habe. Hier
> mal absichtlich unkorrigiert gelassen. Oder seh ich da Gespenster?)
Sorry, da muss ich dich entäuschen. Das ist ein "humanischer"
Controller-Fehler, den ich bei mir auch beobachte. Beliebt bei mri
(sollte "mir" heißen) das Wörtchen "udn" statt "und" oder Wortendungen
"ugn" statt "ung". Ursache für deine Schreibfehler bist du selber mit
deinem Zwei-Hand-Schreibapparat. Der versucht abwechselnd Tasten zu
drücken statt in der richtigen Reihenfolge. Das Wort "und" würde man
im 10-Finger-System mit den Händen rechts-rechts-links schreiben.
Stattdessen macht dein Bewegungsapparat daraus ein links-rechts-links
(immer schön abwechselnd) und so wird aus einem rechts-rechts-links-
und ein rechts-links-recht-udn. Wenn du dir deine oben stehenden
falsch geschriebenen Worte anschaust wirst du den Fehler
nachvollziehen können.
Ich schreibe seit Vielen Jahren mit 10 Fingern und arbeite seit etwa
1998 bei mir an der immer gleichen Tastatur (Microsoft Natural
Keyboard, habe noch zwei da und wenn mir meine jetzige zu dreckig wird
tausche ich sie wieder gegen ein baugleiches Modell aus, so wie ich
das schon seit Jahren mache). Ich habe bei mir etwa ein knappes Jahr
lang den Fehler beobachtet (er ist mir halt auch aufgefallen). Aktiv
gesucht habe ich den Fehler seit etwa 3 Monaten und vor zwei Wochen
kam mir der erleuchtende Einblick. Aber warum meine Hände nach 15
Jahren 10-Finger-System plötzlich diesen Fehler (links-rechts-
abwechselnd) machen habe ich noch nicht herausgefunden. Für
sachdienliche Hinweise wäre ich sehr dankbar!
Gruß Torsten
Joerg
Nun ja, sie soll gesagt haben, dass ein Pixel auf einem Display 800
Bytes an Speicherplatz erfordert.
In Open Office vielleicht ....
<duck>
Joerg
Vermutlich wuerden einige Unternehmen bei Euch jetzt sagen "Seht Ihr,
haben wir doch immer gesagt, dass Ingenieure ab 40 senil werden".
Aber im Ernst. Ich habe letztens, nachdem mir das zu bunt wurde, einen
langen Module Spec mit Word 5.0 unter DOS weitergeschrieben. Auf der
gleichen Tastatur. Und siehe da, es passierte nicht mehr.
--
Gruesse, Joerg (bin ueber 40)
Torsten Junker
On 3 Okt., 16:09, buc...@atbode100.lrr.in.tum.de (Rainer Buchty)
wrote:
>
> Allerdings finde ich es durchaus sinnvoll, wenn sich Informatikstudenten
> von heute auch mal wieder Gedanken um Ressourcenbeschränkung machen, denn
> die letzten Jahrzehnte wurde ja eher die Denke eingetrichtert, daß man
> aus allem erst mal ein sauberes Objektmodell ableitet, der Compiler richtet's
> dann schon -- ...
Ich nehme dir die Visionen nur ungern, aber die hardwarenahe und
ressourchenschonende Programmierung ist in meinem Studium an der
Fachhochschule nur der kleinste Teil im Studium, insgesamt nur 2 SWS
(1 SWS Vorlesung, 1 SWS Übungen an der Hardware). Ansonsten geht es
auch im ersten Semester mit Java voll und ganz zur Sache! Die ganzen
Fachinformatiker für Anwendungsentwicklung in meinem Studiengang, die
nach ihrer Ausbildung ins Studium wechseln, stehen alle mit Assembler/
Maschinensprache auf Kriegsfuß und freuen sich teuflisch auf Java, C++
und die ganzen Hochsprachen.
Ich verstehe übrigens bis heute noch nicht was objektorientierte
Programmierung ist, deshalb graust es mich auch vor den Java-
Vorlesungen und -Übungen. Ich kenne nur Assembler, Maschinensprache,
Turbo-Pascal und Basic. Was man nun mit "Objektorientierung" anders
macht erschließt sich meinem logisch arbeitenden und
lösungsorientierten Gehirn überhaupt nicht.
Beim Betrachten deiner E-Mail-Adresse frage ich mich da auch: Wie ist
das eigentlich an der TUM?
Gruß Torsten
Joerg
>
>>Allerdings finde ich es durchaus sinnvoll, wenn sich Informatikstudenten
>>von heute auch mal wieder Gedanken um Ressourcenbeschränkung machen, denn
>>die letzten Jahrzehnte wurde ja eher die Denke eingetrichtert, daß man
>>aus allem erst mal ein sauberes Objektmodell ableitet, der Compiler richtet's
>>dann schon -- ...
>
>
> Ich nehme dir die Visionen nur ungern, aber die hardwarenahe und
> ressourchenschonende Programmierung ist in meinem Studium an der
> Fachhochschule nur der kleinste Teil im Studium, insgesamt nur 2 SWS
> (1 SWS Vorlesung, 1 SWS Übungen an der Hardware). Ansonsten geht es
> auch im ersten Semester mit Java voll und ganz zur Sache! Die ganzen
> Fachinformatiker für Anwendungsentwicklung in meinem Studiengang, die
> nach ihrer Ausbildung ins Studium wechseln, stehen alle mit Assembler/
> Maschinensprache auf Kriegsfuß und freuen sich teuflisch auf Java, C++
> und die ganzen Hochsprachen.
>
<schauder>
Das gleiche sehe ich immer mehr bei den HW Leuten. Ich hatte diese Woche
tatsaechlich jemandem eine Stromquelle erklaeren muessen. Er hatte sie
im Schaltplan nicht als solche erkannt. Fuer uns HW Leute der alten
Schule hat das in etwa die Komplexitaet wie bei Euch Right-Shift und ADD.
> Ich verstehe übrigens bis heute noch nicht was objektorientierte
> Programmierung ist, deshalb graust es mich auch vor den Java-
> Vorlesungen und -Übungen. Ich kenne nur Assembler, Maschinensprache,
> Turbo-Pascal und Basic. Was man nun mit "Objektorientierung" anders
> macht erschließt sich meinem logisch arbeitenden und
> lösungsorientierten Gehirn überhaupt nicht.
>
Falls es troestet, meines auch nicht. Ich weiss nur, das ein Ingenieur
in Bayern dazu mal gesagt hat "Des mog I net, des is ois schlampert".
> Beim Betrachten deiner E-Mail-Adresse frage ich mich da auch: Wie ist
> das eigentlich an der TUM?
>
--
Gruesse, Joerg
Torsten Junker
On 4 Okt., 00:27, Joerg <notthisjoerg...@removethispacbell.net> wrote:
>
> Aber im Ernst. Ich habe letztens, nachdem mir das zu bunt wurde, einen
> langen Module Spec mit Word 5.0 unter DOS weitergeschrieben. Auf der
> gleichen Tastatur. Und siehe da, es passierte nicht mehr.
Ich sehe da dennoch eine psychologische Ursache, vielleicht auch
neurologisch. Ich habe das nämlich seit meiner Erkenntnis mal genauer
beobachtet und beobachte dabei sehr genau wie ich schreibe.
Auffällig sind dabei auch Finger-Preller. Da ist ein Finge rnoch
(Leerzeichen zu früh) gar nicht dran oder soll gar nicht mehr
schreiben, aber der Finger "hackt" ungefragt zu früh los. So als wenn
er durch den Impuls eines anderen Fingers an der gleichen Hand zucken
würde. Das Wort "nicht" ist rechts-rechts-links-rechts-links. Sehr oft
schreibe ich aber "nicth". Da prellt das links-t ungefragt nach dem
links-c zu schnell vor dem rechts-t. Die Preller der benachbarten
Finger beobachte ich auch wenn beim Beobachten mitten im Wort mit dem
Schreiben aufhören will.
Auch auffällig sind bei mir das Vertauschen nebeneinander liegender
Buchstaben. e-r etwa. Aus "Versand" wird dann schnell "Vresand".
Na das ist schon irgendwie alles etwas komisch.
BTW: Ich arbeite seit 1999 mit Staroffice 5.1, auch heute noch. Egal
ob am Laptop oder am stationären PC, den Fehler habe ich aber trotzdem
seit etwa einem Jahr und in dieser Zeit gab es keine Hardware- oder
Software-Änderungen.
Torsten
Ruediger Klenner
"Joerg" schrieb:
>
> Nun ja, sie soll gesagt haben, dass ein Pixel auf einem Display 800
> Bytes an Speicherplatz erfordert.
>
> In Open Office vielleicht ....
>
:)
ja, das Originalposting hab ich schon mitbekommen, wobei $Referent
(als nomina agentis hoffentlich auch pc) wohl auf Quelltextebene
argumentierte??
Da hätte ich direkt mal nachgefragt, woher diese Zahl kommt und ob
es vielleicht nicht doch eher 600 oder 267000 bytes sind :).
Immer nach Quellen fragen (machmal auch interessant, wie Manche denken)
denn einfach nur grinsen ist zuwenig in solchen Situationen IMHO. Ausser-
dem denken sich Referenten wohl eher seltenst 'irgendwas' aus, vermute
ich, d.h. 'irgendwoher' muss eine solche Angabe doch kommen?
Nein, ich verstehe nicht was an: "... Mache gerade ein
Review von einem uC, wo das aus unerfindlichen Gruenden nur ein Achtel
Byte pro Pixel sind. <grins>" falsch sein sollte.
Na, vermutlich war mein Ironiedetektor grad abgestürzt und dein uC
schreibt tatsächlich ohne irgendwelche HSync und VSyncs u.s.w in
Schieberegister? Kann ja gut sein (solange sich kein Zähler verzählt :)
Ich habe hier am Bastelplatz ein aus meinem kürzlich verstorbenen (Geist
neben Grabstein) 3.95?-Tamagochi-Clone entnommenen 16x16LCD mit
angeschraubtem PIC liegen, da kommt das vermutlich hin (oder nicht,
weiss nicht, es läuft noch nicht).
Ansonsten gelten realiter wieder ganz andere Zahlen... für grössere
LCD (incl. Graustufen/Farbe) gelten andere Zahlen.
Letztens eine 256x256x64Farben VGA in einem 9572 CPLD gemacht, der
PS-subsubset-PIC schiebt dann für jedes Pixel zur Ansteuerung drei bytes
rein.
Na ja, jedenfalls waren für alle meine bisher verbauten und verprogrammierten
Controller 8 pixel/byte nie zutreffend. Aber kanns ja geben, warum nicht, so
a la Z81 vielleicht? (Hatte nie einen, weiß jetzt nicht ob der Prozessor nicht
doch auch Syncs dazugeben musste, vemutlich doch...)
Joerg
Hier wird der ganze Summs meist teil-seriell reingeschoben. Das sind
dann fuer 16*16 tatsaechlich nur 32 Bytes. Viel mehr haben viele uC
nicht, 128 Byte RAM ist schon die Luxusklasse oberhalb 50c/Stueck. Hin
und wieder muss man kramen, wo man denn noch was hinschieben kann. Nach
dem Motto vom Stack unters Sofa ;-)
Frank Buss
> Ich verstehe übrigens bis heute noch nicht was objektorientierte
> Programmierung ist, deshalb graust es mich auch vor den Java-
> Vorlesungen und -Übungen. Ich kenne nur Assembler, Maschinensprache,
> Turbo-Pascal und Basic. Was man nun mit "Objektorientierung" anders
> macht erschließt sich meinem logisch arbeitenden und
> lösungsorientierten Gehirn überhaupt nicht.
Wenn du schon größere Programme in Basic oder Pascal geschrieben hast, dann
hast du wahrscheinlich bereits Objektorientierung angewendet. Z.B. ist das
bei einer grafischen Oberfläche üblich: Ein Fenster ist ein Objekt und du
rufst Funktionen auf diesem Objekt auf (also in Pascal: Übergibst den
Pointer auf das Fenster-Record als ersten Parameter beim Funktionsaufruf).
In C++ und Java ist nur die Schreibeweise anders: statt drawText(fenster,
x, y, text) heißt es dann fenster.drawText(x, y, text) und innerhalb der
Funktionen sind dann alle Variablenzugriffe, die nicht auf globale oder
lokale Variablen gehen, implizit Zugriffe auf Variablen des
fenster-Structs.
Gibt dann natürlich noch ein paar schöne Dinge wie Polymorphismus usw., was
man lernen muß, wann man es wie am besten einsetzt, aber es hilft viel,
sich die Implementierung mit Records und entlanghangeln an Pointern
vorzustellen. War zumindest bei mir so, der auch erst Assembler auf dem C64
programmiert hat und dann über Pascal nach C und Jave kam, in letzter Zeit
einiges in Lisp gemacht hat (http://tinyurl.com/26n74a) und schließlich ein
wenig mit Haskell gespielt hat, einer faszinierenden Sprache und meiner
Meinung nach wunderbar für die massiv parallelen Systeme der Zukunft
geeignet.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Raimund Nisius
> On 4 Okt., 00:27, Joerg <notthisjoerg...@removethispacbell.net> wrote:
> >
> > Aber im Ernst. Ich habe letztens, nachdem mir das zu bunt wurde, einen
> > langen Module Spec mit Word 5.0 unter DOS weitergeschrieben. Auf der
> > gleichen Tastatur. Und siehe da, es passierte nicht mehr.
>
> Ich sehe da dennoch eine psychologische Ursache, vielleicht auch
> neurologisch. Ich habe das nämlich seit meiner Erkenntnis mal genauer
> beobachtet und beobachte dabei sehr genau wie ich schreibe.
Vor ein paar Jahren hatte ich eine verspannte Schulter, die sogar zu
leichter Taubheit in den Fingerkuppen führte (nerv in der Schulter
eingeklemmt).
Das ging mit Massage weg. IN dieser ZEit hatte ich mit dem
VErtauschungsfehler verschärft zu kämpfen und die SHifttaste ließ ich
regelmäßig zu spät los.
Das wär doch mal ein Bastelprojekt: Erfassung der Anschlagszeiten und
Zeitpunkte der Übernahme durch das Betriebssystem. Es soll ja auch
Passworterkennungen geben, die auf den Fingerrhythmus achten.
--
Gruß, Raimund
Mein Pfotoalbum <http://www.raimund.in-berlin.de>
Mail ohne Anhang an <Reply-To:> wird gelesen. Im Impressum der Homepage
findet sich immer eine länger gültige Adresse.
Wolfgang Allinger
On 04 Oct 07 at group /de/sci/electronics in article
<usene...@raimund.in-berlin.de> (Raimund Nisius) wrote:
>Torsten Junker <vornahme....@gmx.de> wrote:
>> On 4 Okt., 00:27, Joerg <notthisjoerg...@removethispacbell.net>
>> wrote:
>>>
>>> Aber im Ernst. Ich habe letztens, nachdem mir das zu bunt wurde,
>>> einen langen Module Spec mit Word 5.0 unter DOS weitergeschrieben.
>>> Auf der gleichen Tastatur. Und siehe da, es passierte nicht mehr.
>>
>> Ich sehe da dennoch eine psychologische Ursache, vielleicht auch
>> neurologisch. Ich habe das nämlich seit meiner Erkenntnis mal
>> genauer beobachtet und beobachte dabei sehr genau wie ich schreibe.
>Vor ein paar Jahren hatte ich eine verspannte Schulter, die sogar zu
>leichter Taubheit in den Fingerkuppen führte (nerv in der Schulter
>eingeklemmt).
>Das ging mit Massage weg. IN dieser ZEit hatte ich mit dem
>VErtauschungsfehler verschärft zu kämpfen und die SHifttaste ließ ich
>regelmäßig zu spät los.
Und ich dachte, nur bei Heinz Erhardt und mir gibbet dat Problem mit der
Verbuchselung von Wegstaben. Irgendwie beruhigend.
Hmm. Zum älter werden fällt mir da gerade noch ein Witz ein:
Was ist eigentlich schlimmer?
Alzheimer oder Parkinson?
Beides gleich schlimm, ob ich mein Bier verschlabbere oder nicht mehr
weiss, wo ich es hingestellt habe.
Oder noch einen für die Chauviekasse:
Es ist schön, wenn ein Mann älter wird. Der Kreis der Frauen, die einen
interessieren, wird von Jahr zu Jahr größer. Als 18 jähriger waren mir
40 jährige echt zu alt. Heute sehe ich mir mit Genuss gut erhaltene
Exemplare gerne an.
>Das wär doch mal ein Bastelprojekt: Erfassung der Anschlagszeiten und
>Zeitpunkte der Übernahme durch das Betriebssystem. Es soll ja auch
>Passworterkennungen geben, die auf den Fingerrhythmus achten.
Da muss man wohl erst 'ne Kanne Bier schlürfen, damit die Bewegung
ruhiger wird :-) Weib! Bitte 'ne Buddel Bier, ich muss mich gleich
einloggen!
Saludos Wolfgang
--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
Wolfgang Allinger Paraguay reply Adresse gesetzt !
VoIP 02173 / 99 39 209 ca. 15h00..21h00 MEZ SKYPE:wolfgang.allinger
Rainer Buchty
Torsten Junker <vornahme....@gmx.de> writes:
|> Ich verstehe =FCbrigens bis heute noch nicht was objektorientierte
|> Programmierung ist
*grins* Also das eingängigste Beispiel für OOP ist m.E. "LPC". War
die Programmiersprache, in denen man LP-Muds ihr Leben eingehaucht hat --
und da wurde der ganze Krams wie Hierarchien, Vererbung, private vs. public
usw. angenehm deutlich.
Und wenn Du mal sehen willst, wie es aussieht, wenn man OO in natives
C kloppt, dann programmier mal eine GTK-basierte Anwendung und strick auch
das ein oder andere Widget selbst.
In dem Fall sieht man auch sehr schnell, wo die Eleganz von OO liegt und
warum man das dann auch gerne in der Sprache hätte, anstatt es zu Fuß
zu tun.
Allerdings: Es kommt auch immer auf die Anwendung und den Anwendungsbereich
an...
|> Beim Betrachten deiner E-Mail-Adresse frage ich mich da auch: Wie ist
|> das eigentlich an der TUM?
Zu meiner Zeit war OO im Infostudium noch nicht so das Thema, das kam erst
mit dem Java-Hype um 97.
Rainer
Rainer Buchty
"Ruediger Klenner" <Ruediger...@ruhr-uni-bochum.de> writes:
|> Nein, ich verstehe nicht was an: "... Mache gerade ein
|> Review von einem uC, wo das aus unerfindlichen Gruenden nur ein Achtel
|> Byte pro Pixel sind. <grins>" falsch sein sollte.
Ist doch auch nichts falsch... Ein monochromes Pixel benötigt exakt 1/8
Byte Speicherplatz.
|> Letztens eine 256x256x64Farben VGA in einem 9572 CPLD gemacht, der
|> PS-subsubset-PIC schiebt dann für jedes Pixel zur Ansteuerung drei bytes
|> rein.
Jetzt bin ich neugierig. Ich nehme an, die Ausgabe macht der CPLD und somit
folgerichtig auch auf einem eigenen Speicher.
Die 3 Bytes sind somit die Bitmap-Adresse (Spalte/Zeile) plus ein Byte
Farbwert (d.h chunky pixel, nicht bitplane)?
Würd ich (sofern Platz im Chip und öfter mal komplette Bitmaps übertragen
werden) noch ein "burst"-Register mit reintun, wo Du nur mal die Startadresse
angibst und dann für jeden übertragenen Folgepixel nur ein Byte übertragen
wird.
Und natürlich noch Colormap-Register. Denn spätestens seit dem Amiga wissen
wir, wie wunderbar einfach sich lebendige "Bewegtbilder" erstellen lassen :)
Rainer
Stefan Brröring
> 6510-Assemblerprogrammierung und Z80-Maschinenspracheprogrammierung
> vom 8051 unterscheiden, mehr so aus Neugierde.
Mal abgesehen von anderen Befehlen, Registern, anderer
Speicheraufteilung und anderer Peripherie unterscheiden sich die
üblichen Micrcontroller und -prozessoren nicht wirklich grundlegend.
Einige Unterschiede betreffen sogar nur die Schreibweise.
Bei einigen gibt es bedingte Sprünge nur relativ, bei anderen auch als
absolute Sprünge, beim Pic gibt es beingte Sprünge nur in der Form, dass
der folgende Befehl übersprungen wird oder nicht.
Bei einigen ist der Stack im externen RAM, bei einigen gibt es einen
Hardwarestack. Manche starten nach einem Reset bei 0000, andere haben
irgendwo einen Startvektor.
Wenn es SFRs gibt, haben die natürlich jeweils unterschiedliche Funktionen.
Wenn man aber zwei oder drei Controllerfamilien kennt, sollte es nicht
schwer fallen, sich in eine beliebige andere einzuarbeiten.
Und Z80, 6510 und 8051 kommen (fast) aus derselben Generation.
Kennt jemand eigentlich ein gutes Buch zum Thema ATmega, das ich meinen
Azubis in die Hand drücken kann?
Ich hatte damals den Zaks : "Programmierung des Z80".
Sowas scheint es aber heute nicht mehr zu geben.
Gruß
Stefan DF9BI
Ruediger Klenner
"Rainer Buchty" schrieb
> Rüdiger schrieb:
> |> Letztens eine 256x256x64Farben VGA in einem 9572 CPLD gemacht, der
> |> PS-subsubset-PIC schiebt dann für jedes Pixel zur Ansteuerung drei bytes
> |> rein.
>
> Jetzt bin ich neugierig. Ich nehme an, die Ausgabe macht der CPLD und somit
> folgerichtig auch auf einem eigenen Speicher.
>
> Die 3 Bytes sind somit die Bitmap-Adresse (Spalte/Zeile) plus ein Byte
> Farbwert (d.h chunky pixel, nicht bitplane)?
Ja, genau so. Hatte was Ähnliches mal im Netz als Anregung gefunden und
dann den CPLD im Wesentlichen einfach aus einer Hersteller-AN übernommen.
Kleines Bildchen von meinem Teil: http://TinyURL.com/2rtusd
> Würd ich (sofern Platz im Chip und öfter mal komplette Bitmaps übertragen
> werden) noch ein "burst"-Register mit reintun, wo Du nur mal die Startadresse
> angibst und dann für jeden übertragenen Folgepixel nur ein Byte übertragen
> wird.
Wär ne Idee.
Es ist/war aber nur als generelle Ausgabemöglichkeit für meine uC-Projekte
gedacht: uC von Projekt übergibt bitseriell (nicht unbedingt über die
RS232 auf der Karte, geht zwar auch, reicht aber clk, data) Text/Anweisungen
an den uC auf Graka, der dann wiederum alles Notwendige (Charaktergen und
PS-subset für einfache Grafik) enthält und über den CPLD in SRAM schreibt.
Muss also für den Zweck nicht schnell sein, auch nicht bunt, es sollte nur
den Schlepptop ersparen; bisher hatte ich debugging/testen vor Ort per
Statusmeldungen über RS232 gemacht (oder in einfachen Fällen Blinkcodes).
Setzt dann natürlich PC voraus, der nicht immer gleich aufzutreiben ist...
Inzwischen bin ich von der Minigrakarte wieder weg, man müsste ja vor Ort
auch immer nen Monitor auftreiben ist mir aufgefallen *g* oder mit-
nehmen, keine wirkliche Erleichterung im Vergleich zum bisherigen
Verfahren... :\
Momentan denke ich über ein kleines Modul für Gameboy nach das einen Max232
und Eprom mit Terminalprog für GB enthält, würde dann den gleichen Zweck er-
füllen und lässt sich leicht überall mitnehmen.
>
> Und natürlich noch Colormap-Register. Denn spätestens seit dem Amiga wissen
> wir, wie wunderbar einfach sich lebendige "Bewegtbilder" erstellen lassen :)
>
Der 9572 ist mit dem, was momentan drin ist, ziemlich ausgereizt. Zwar
wäre der 95144 pinkompatibel, ich mache aber nichts mehr an diesem Teil.
Frank Buss
> Ja, genau so. Hatte was Ähnliches mal im Netz als Anregung gefunden und
> dann den CPLD im Wesentlichen einfach aus einer Hersteller-AN übernommen.
>
> Kleines Bildchen von meinem Teil: http://TinyURL.com/2rtusd
Sieht ja nett aus. Woher hast du die 3D-Modelle für Stecker, die
gedrechselten Sockel usw.? Ich habe hier Cinema4D und wäre schön, wenn ich
die Schaltung, die ich gerade baue, vorher einfach mal so von der Anordnung
her ausprobieren könnte (ist mechanisch etwas komplexer).
Ruediger Klenner
"Frank Buss" schrieb:
> Ruediger Klenner wrote:
>
> > Ja, genau so. Hatte was Ähnliches mal im Netz als Anregung gefunden und
> > dann den CPLD im Wesentlichen einfach aus einer Hersteller-AN übernommen.
> >
> > Kleines Bildchen von meinem Teil: http://TinyURL.com/2rtusd
>
> Sieht ja nett aus. Woher hast du die 3D-Modelle für Stecker, die
> gedrechselten Sockel usw.? Ich habe hier Cinema4D und wäre schön, wenn ich
> die Schaltung, die ich gerade baue, vorher einfach mal so von der Anordnung
> her ausprobieren könnte (ist mechanisch etwas komplexer).
>
Ich hatte dafür Eagle3D von Matthias Weißer benutzt: http://www.matwei.de/
Joerg
>>
>>Jetzt bin ich neugierig. Ich nehme an, die Ausgabe macht der CPLD und somit
>>folgerichtig auch auf einem eigenen Speicher.
>>
>>Die 3 Bytes sind somit die Bitmap-Adresse (Spalte/Zeile) plus ein Byte
>>Farbwert (d.h chunky pixel, nicht bitplane)?
>
>
> Ja, genau so. Hatte was Ähnliches mal im Netz als Anregung gefunden und
> dann den CPLD im Wesentlichen einfach aus einer Hersteller-AN übernommen.
>
> Kleines Bildchen von meinem Teil: http://TinyURL.com/2rtusd
>
Sieht aber nach "virtuell geloetet" aus. Frage: Mit welcher SW hast Du
das Bild erstellt? Sieht sehr huebsch und ordentlich aus.
[...]
Heiko Nocon
>Informatiker entwickeln dir Systeme für die fehlerfreie
>Implementierung der Software
Wobei hier natürlich die Betonung auf "entwickeln" gelegt werden sollte.
Meines Wissens haben die Informatiker selbst bewiesen, daß es
fehlerfreie Software nicht geben kann, sondern man sich diesem
Idealzustand nur asymptotisch annähern kann.
Also wäre "fehlerarm" der korrekte Begriff gewesen.
Heiko Nocon
>Was spricht eigentlich gegen Simulatoren für Z80 und 8051, um die
>Programmierung zu lernen?
Rein garnichts. Daran wird es wohl auch liegen, daß es für alle
genannten Prozessorfamilien Simulatoren gibt...
Heiko Nocon
>Das ist ein Atmel AVR aber auch. Sogar leichter, weil der Befehlssatz
>sauber aufgebaut ist und man eben *nicht* eine Unterscheidung z.B. in
>Akku und Indexregister hat.
Naja, ich arbeite gern und viel mit AVRs, aber in diesem Sinne "sauber"
ist der Befehlssatz natürlich keinesfalls. R0..R15 können viele
Operationen nicht, die R16..R31 können. Die zweite Gruppe ist nochmal
geteilt. R16..R23 können einige Operationen nicht, die R24..R31 können.
Dazu kommen dann noch diverse Sonderfunktionen quer über die Gruppen.
Für Multiplikation ist nur R0,R1 brauchbar, als Indexregister nur
R26..R31, als Register für indirekte Sprünge und obendrein blöderweise
auch noch als einziges Zugriffsregister für den PM nur R30,R31. Und das
dann ab ATMega128 auch noch aufgepäppelt durch ein zusätzliches Register
im IO-Bereich (wie auch der SP im IO-Bereich liegt)
Also nö. "Sauber" in deinem Sinne ist da eher sowas wie der 68000. Nur
zwei Registergruppen, außer Addressierung nahezu alle Operationen in
beiden Gruppen möglich. Nur eine einzige Ausnahme für Sonderfunktion
(A7=SP). Auch nicht 100% perfekt, aber immerhin sehr viel näher am Ideal
als die AVRs.
Frank Buss
> Ich hatte dafür Eagle3D von Matthias Weißer benutzt: http://www.matwei.de/
Klappt wunderbar, habe gerade mal meine Test-Verstärkerschaltung damit
gerendert:
http://www.frank-buss.de/receiver/3d.png
Werde demnächst wohl noch ein paar Bauteile dazu beitragen, ich kenne mich
ja ein wenig mit povray aus:
http://www.frank-buss.de/puzzle/desert.jpg
http://www.frank-buss.de/puzzle/desert.pov.txt
Frank Buss
> Meines Wissens haben die Informatiker selbst bewiesen, daß es
> fehlerfreie Software nicht geben kann, sondern man sich diesem
> Idealzustand nur asymptotisch annähern kann.
Also das wäre mir neu, hast du da Quellen zu?
Matthias Weingart
> Das w„r doch mal ein Bastelprojekt: Erfassung der Anschlagszeiten und
> Zeitpunkte der šbernahme durch das Betriebssystem. Es soll ja auch
> Passworterkennungen geben, die auf den Fingerrhythmus achten.
Machen bei uns hier Forscher in der Neurologie. Du machst so nen Test
(so schnell wie möglich mit bestimmten Fingern bstimmte Tasten drücken)
und sie sagen dir, ob du ein verkappter Linkshänder bist oder sonstwie
neurologisch auffällig.
M.
--
Bitte auf mwn...@pentax.boerde.de antworten.
Thorsten Oesterlein
Hallo!
>>> - Parameter werden als Zeichenkette oder Pointer übergeben.
>> Lernt man das echt so?
>
> Ob man das so lernt, weiß ich nicht. Aber "call by value" gleich
> Zeichenkette (auch mit der Länge eins) und "call by reference" würde ich
> meinen, lernt man so.
In welcher Programmiersprache? ;-)
Strings sind das klassische Beispiel für "call by reference". Der
klassische String ist ein Pointer auf den Beginn der Zeichenkette und damit
eine Referenz.Mir fällt jetzt auch nicht ein wo das anders wäre. Selbst in
OOP werden nur die entsprechenden Objekte referenziert - ausser man will es
explizit anders.
> Grüße, Holger
Liebe Grüße,
Thorsten
Ruediger Klenner
> Ruediger Klenner wrote:
>
> > Ich hatte dafür Eagle3D von Matthias Weißer benutzt: http://www.matwei.de/
>
> Klappt wunderbar, habe gerade mal meine Test-Verstärkerschaltung damit
> gerendert:
>
> http://www.frank-buss.de/receiver/3d.png
Breitbandverstärker mit zwei BC547 *g*? Riecht nach Kascode?
>
> Werde demnächst wohl noch ein paar Bauteile dazu beitragen, ich kenne mich
> ja ein wenig mit povray aus:
>
ja, fehlt noch Einiges.
Matthias liest hier glaub' regelmäßig mit, ich weiss aber nicht ob er
Eagle3D noch wartet...
Frank Buss
>> http://www.frank-buss.de/receiver/3d.png
>
> Breitbandverstärker mit zwei BC547 *g*? Riecht nach Kascode?
Hier siehst du den Rest der Schaltung, mit FFT (und da ist doch was bei
77,5 kHz :-)
http://www.frank-buss.de/receiver/
Kommt ursprünglich hier her:
"Breitband" nur in dem Sinne, daß es alles von 0 bis ein paar MHz
verstärkt. Wollte eigentlich einen DCF77 Empfänger per nachgeschaltetem
digitalen Filter bauen, aber der Störabstand ist so schlecht, daß man wohl
einen ziemlich hochauflösenden A/D-Wandler brauchen würde.
Franz Glaser
>
> Vor ein paar Jahren hatte ich eine verspannte Schulter, die sogar zu
> leichter Taubheit in den Fingerkuppen führte (nerv in der Schulter
> eingeklemmt).
> Das ging mit Massage weg. IN dieser ZEit hatte ich mit dem
> VErtauschungsfehler verschärft zu kämpfen und die SHifttaste ließ ich
> regelmäßig zu spät los.
>
> Das wär doch mal ein Bastelprojekt: Erfassung der Anschlagszeiten und
> Zeitpunkte der Übernahme durch das Betriebssystem. Es soll ja auch
> Passworterkennungen geben, die auf den Fingerrhythmus achten.
Bist du sicher, daß das nichts mit der Kompensation des Motorola -
Byteswap - Syndroms zu tun hat?
Der innere Schweinehund hat die Dominanz der Intel-Architektur nur
widerwillig akzeptiert.
<dukc>
--
"5 Köpfe denken in 1 h produktiver als 1 Kopf in 5 h".
Das sagen die 4 Köpfe mehrheitlich, die sich nach der
1-h-Besprechung mit dem 5-h-Einzeldenker selber
auch für Produktive halten.
Ruediger Klenner
"Ulrich G. Kliegis" schrieb:
> "Ruediger Klenner" wrote:
>
>
> >Momentan denke ich über ein kleines Modul für Gameboy
>
>
Ab gameboy advance noch zusätzlich, wie bereits weiter oben erwähnt,
mit ARM7/THUMB.
(Im Modulschacht ist ein kleiner Schalter, die Cartridges sind mechanisch
codiert so dass (hoffentlich) immer "die richtige" CPU anläuft :)
Krallenwetzer
<rundo...@gmx.at> wrote:
>Strings sind das klassische Beispiel für "call by reference". Der
>klassische String ist ein Pointer auf den Beginn der Zeichenkette und damit
>eine Referenz
Es sind natürlich alles Zeichenketten, mit denen du da hantierst. Nur
ist die eine ein Array [0..n] of char, die andere ein Pointer, also
eine Folge von Zeichen, die eine Adresse bedeuten, oder eine Variable
vom Typ Integer, also ene Folge von Zeichen, die eine Zahl im Format
des Zweierkomplements darstellt, und so weiter.
Raimund Nisius
> > Das wär doch mal ein Bastelprojekt: Erfassung der Anschlagszeiten und
> > Zeitpunkte der Übernahme durch das Betriebssystem. Es soll ja auch
> > Passworterkennungen geben, die auf den Fingerrhythmus achten.
>
> Bist du sicher, daß das nichts mit der Kompensation des Motorola -
> Byteswap - Syndroms zu tun hat?
>
> Der innere Schweinehund hat die Dominanz der Intel-Architektur nur
> widerwillig akzeptiert.
Die charakteristischen Fehler begannen bei einem Powermac, steigerte
sich beim iBook und besteht derzeit bei einem Intel Macbook.
> <dukc>
Besser so.
--
Gruß, Raimund
Mein Pfotoalbum <http://www.raimund.in-berlin.de>
Mail ohne Anhang an <Reply-To:> wird gelesen. Im Impressum der Homepage
findet sich immer eine länger gültige Adresse.
Raimund Nisius
> > Das w≥r doch mal ein Bastelprojekt: Erfassung der Anschlagszeiten und
> > Zeitpunkte der ˚bernahme durch das Betriebssystem. Es soll ja auch
> > Passworterkennungen geben, die auf den Fingerrhythmus achten.
>
> Machen bei uns hier Forscher in der Neurologie. Du machst so nen Test
> (so schnell wie möglich mit bestimmten Fingern bstimmte Tasten drücken)
> und sie sagen dir, ob du ein verkappter Linkshänder bist oder sonstwie
> neurologisch auffällig.
Ich alte das für ne Alterserscheinung. Verkappter Linkshänder bin ich
eher nicht.
Stefan Brröring
>>Azubis in die Hand drücken kann?
>>Ich hatte damals den Zaks : "Programmierung des Z80".
>
>
Ja, bei mir auch,
aber nicht mehr das Buch, das ich mir in den 80ern gekauft habe.
Das hatte einen riesen Brandfleck von einem unachtsam abgelegten
Lötkolben auf dem Titelblatt und ist irgendwie verloren geganen.
Hab mir inzwischen für die Azubis einen "neuen" über Ebay besorgt. Da
wir aber nicht mehr mit Z80 arbeiten ist das etwas blöd, wenn die dann
mit AVR oder PIC arbeiten sollen.
Gruß
Stefan DF9BI
fritz.schoerghuber
> Kennt jemand eigentlich ein gutes Buch zum Thema ATmega, das ich meinen
> Azubis in die Hand drücken kann?
http://www.rowalt.de/mc/avr/avrbuch/index.htm
Hab' ich selbst, kanns empfehlen.
Fuer weitere Fragen sup...@rowalt.de
hth
fritz.schoerghuber
Henning Paul
> Stefan Brröring schrieb:
>
>> Kennt jemand eigentlich ein gutes Buch zum Thema ATmega, das ich
>> meinen Azubis in die Hand drücken kann?
>
> http://www.rowalt.de/mc/avr/avrbuch/index.htm
Basic... *schüttel*
Gruß
Henning
Peter Heitzer
>> Nur dem Interesse halber: Wo bekommt man eigentlich 8051-
>> Entwicklerboards für Lehrzwecke (also so was wie den LC80) und was
>> kostet so was? Also so ein Ding mit Netzteilanschluss, LC-Display und
>> Hex-Tastatur.
>Braucht man nicht.
>Moderne 8031 Derivate, z.B. mit Flash von Atmel AT89F51 o.ä. sind per
>ICSP programmierbar. LCD-Display läßt sich über wenige Leitungen
>anschließen. Für den Prozessor selbst reicht Stromversorgung,
>Resetbeschaltung, eventuell Quarz
>Das ganze läßt sich leicht auf einer Lochrasterplatte aufbauen.
>Ansonsten einfach selber eine Platine machen. Für sowas reicht eine
>einseitige Platine.
Von alten ISA MFM/RLL Controllern von Adaptec kann man mit etwas Geschick
den darauf verbauten 8031 nebst Latch und EPROM-Fassung herunterschneiden.
Lediglich einen Quarzoszillator muß man noch hinzufügen bzw. einen Quarz an
die Beine des uC löten. Ich kann mal ein paar Bilder davon machen und ins
Web stellen.
Als Monitorprogramm empfehle ich Paulmon (www.pjrc.com/tech/8051/paulmon2.html).
fritz.schoerghuber
>
> Basic... *schüttel*
>
IBTD. Schon 'mal diesen Dialekt angesehen?
IMHO ist der schon naeher an C als an Basic.
YMMV aber fuer meine Aufgaben mit den AVRs
reicht's locker.
Im Buch kommen Assembler und C keinesfalls
zu kurz, die wichtigsten Routinen/Beispiele
werden auch in Assembler/C gelistet.
hand
fritz.schoerghuber
Joachim Riehn
> .... Ich kenne nur Assembler, Maschinensprache,
> Turbo-Pascal und Basic.
Du kannst dir das aeltere Buch von Andreas Roth ("Mikrokontroller
Kochbuch") anschauen, es wird dich sicherlich interessieren.
Nochmal zu deiner urspruenglichen Fragestellung. Die Mikrokontroller
arbeiten in der Praxis anders als die Mikroprozessoren. Bei
den Kontrollern werden die meiste Zeit eine Handvoll oder mehrere
Handvoll Interrupt-Routinen abgearbeitet. Das Hauptprogramm
ist bei den kleinen Kontrollern eher bescheiden.
Bei jedem Interrupt muessen einige, moeglichst wenige
(wegen des timings!), Register gerettet werden. Meistens
befindet man sich vom Hauptprogramm her in einigen
Zaehlschleifen. Der 8051er macht das ganz gut, da er
ganze Zaehl-Register-Baenke mit einem einzigen
Befehl umschalten kann. Dazu kommen die erwaehnten
Bit-Manipulationen. Das sind einige der Gruende, warum
die 8051er heute noch so weit verbreitet sind.
Rechnen kann der 8051er schlecht. Fuer Gleitkomma-Rechnung
muss man schon ganze Unterprogramme schreiben. Das koennen
die anderen (Z80 etc.) besser. Das war in Home-Computer
Zeiten ein Unterschied, aber heute?
Mit Gruss, Joachim Riehn
Holger Bruns
> Henning Paul schrieb:
>
>>
>> Basic... *schüttel*
>>
>
> IBTD. Schon 'mal diesen Dialekt angesehen?
Basic ist eine Sorte von Programmiersprachen, die aus der Not heraus
geboren wurden, kleine 8-Bit-Rechner mit wenig Aufwand so einfach wie
möglich programmierbar zu machen. Basic kennt viele sinnvolle Konzepte
aus anderen Programmiersprachen nicht; zum Beispiel schon mal keine
lokalen Variablen und keine Schleifen wie "repeat ... until" und
"do...while". War in den 80ern des letzten Jahrhunderts schon tot.
Holger
Rainer Buchty
Henning Paul <henni...@gmx.de> writes:
|> Basic... *schüttel*
Ganz ehrlich: Mir isses lieber, wenn jemand in BASIC programmieren kann
als wenn er's gar nicht kann.
Ich denke, es hat auch einen Grund, wieso heute vergleichsweise wenige
wirklich mit dem Programmieren anfangen. BASIC hatte man recht kurzer
Zeit drauf -- und wenn es nicht gerade Commodore-BASIC war, konnte man
damit sogar dem Rechner recht bequem Grafik und Sound entlocken und kam
somit schnell zu einem Erfolgserlebnis.
Vielleicht ist deshalb Microsofts VisualBASIC so erfolgreich. Jeder kann,
wenn er mag -- und im Gegensatz zu C fliegt der Anfängercode einem nicht
sofort um die Ohren.
Daß BASIC fürs Leben versaut, daran glaube ich nicht. Schließlich kann
man kann auch in C viel unschönes treiben, was garantiert *kein* schöner
Programmierstil ist.
Rainer
Rainer Buchty
Holger Bruns <hbr...@gmx.de> writes:
|> Basic ist eine Sorte von Programmiersprachen, die aus der Not heraus
|> geboren wurden, kleine 8-Bit-Rechner mit wenig Aufwand so einfach wie
|> möglich programmierbar zu machen.
Ne, is klar. 1963, als BASIC aus der Taufe gehoben wurde, hatte man genau
das im Sinn.
Einfachheit, ja. Aber Du läßt das klingen, als wäre es etwa schlechtes.
|> Basic kennt viele sinnvolle Konzepte
|> aus anderen Programmiersprachen nicht; zum Beispiel schon mal keine
|> lokalen Variablen und keine Schleifen wie "repeat ... until" und
|> "do...while".
Ah, es spricht der Erfahrene, der einen halben BASIC-Dialekt gesehen hat
und somit auf alle anderen schließt. Was, bitte, ist denn "das" BASIC?
Die Zeit ist seit Dartmouth BASIC durchaus weitergelaufen...
Oder kommt jetzt als nächstes "BASIC ohne Zeilennummern ist nicht BASIC"?
|> War in den 80ern des letzten Jahrhunderts schon tot.
So tot, daß es heute noch eingesetzt wird -- von jeder erfahrenen
Sekretärin, die sich VBA-Skripte zusammenstoppelt. Was für die Einfachheit
und Attraktivität der Sprache insbesondere für Nicht-Programmierer spricht.
Auch möchte ich nicht wissen, wieviel heute noch im Windows-Umfeld mit
VisualBASIC zusammengestoppelt wird. Eben *weil* es einfach und schnell
geht.
Rainer
Joachim Gaßler
news:5mmafoF...@mid.individual.net...
> [...]
> Basic ist eine Sorte von Programmiersprachen, die aus der Not heraus
> geboren wurden, kleine 8-Bit-Rechner mit wenig Aufwand so einfach wie
> möglich programmierbar zu machen. Basic kennt viele sinnvolle Konzepte aus
> anderen Programmiersprachen nicht; zum Beispiel schon mal keine lokalen
> Variablen und keine Schleifen wie "repeat ... until" und "do...while". War
> in den 80ern des letzten Jahrhunderts schon tot.
Naja ... 1964 entwickelt, hatte es mit den 8-Bittern, die von Mitte der 70er
bis Mitte der 80er ihr "goldenes Zeitalter" hatten, noch nichts am Hut. 1980
gab es schon Basic-Dialekte mit do..while und repeat..until. Habe das 1981
selbst mal auf einer Triumph-Adler Alpha 80 (oder war es doch eine P1?)
ausprobieren dürfen.
Aber ich gebe dir insofern recht, als daß viele Homecomputer-Basic-Dialekte
soweit kastriert waren, daß ihr Sprachumfang nur noch peinlich war
(teilweise fehlende GOSUB/RETURN-Implementierung, kein DATA/READ/RESTORE,
keine Matrixoperationen etc...), und das alles, um mit einer Handvoll
Kilobytes Speicher auszukommen.
Nichtsdestotroz haben viele der heutigen IT-Verantwortlichen in Unternehmen
ihre ersten Programmiererfahrungen mit Basic gemacht.
Joachim
Martin Wenk
> Azubis in die Hand drücken kann?
Hallo Stefan,
ich kann das Buch "Mikrocomputertechnik mit Controllern der Atmel
AVR-RISC-Familie" von Günter Schmitt wärmstens empfehlen.
Der erste Teil dreht sich die Assemblerprogrammierung mit sehr
guter Hardwarebeschreibung, der zweite Teil um C. Didaktisch
sehr gelungen.
Martin
--
DL9CK
fritz.schoerghuber
OK, ich entnehme daraus, dass Du den im Buch angesprochenen
Basic-Dialekt "Bascom" nicht kennst/angesehen hast. Genau
die von Dir angesprochenen Beispiele sind da naemlich expli-
zit enthalten. Schau's Dir selbst an:
http://www.mcselec.com/index.php?option=com_content&task=view&id=14&Itemid=41
Du solltest Deine Meinung ueberdenken...
hand
fritz.schoerghuber
Franz Glaser
> Basic ist eine Sorte von Programmiersprachen, die aus der Not heraus
> geboren wurden, kleine 8-Bit-Rechner mit wenig Aufwand so einfach wie
> möglich programmierbar zu machen. Basic kennt viele sinnvolle Konzepte
> aus anderen Programmiersprachen nicht; zum Beispiel schon mal keine
> lokalen Variablen und keine Schleifen wie "repeat ... until" und
> "do...while". War in den 80ern des letzten Jahrhunderts schon tot.
>
Das weiß doch JEDER(tm), daß BASIC (es gehört groß geschrieben)
nur eine Pauperversion von FORTRAN ist, während hingegen Pascal
(kleingeschrieben) die Weiterentwicklung ("ETH Zürich", schon die
ersten zwei Buchstaben deuten auf die Evolution hin) von ALGOL
ist.
BASIC kann den Subroutinen keine Parameter mitgehen und hat keine
lokalen Variablen, das ist ja 'zezzlich! Da ist ja nicht einmal
eine absturzgefährdete Rekursion möglich. Nichtmal!
Allein damit wären schon 3,3% von "alles" gesagt. Hände wech von
BASIC.
Zeterum zenseo: ich empfehle FORTH.
MfG
Stefan Brröring
> Basic-Dialekt "Bascom" nicht kennst/angesehen hast. Genau
> die von Dir angesprochenen Beispiele sind da naemlich expli-
> zit enthalten. Schau's Dir selbst an:
Also ich habe Anfang der 80er Basic programmiert. Zuerst Basic auf dem
TRS-80, später auf dem PC. Das nannte sich damals GW-Basic und war im
Prinzip nicht schlecht.
Irgendwann gabs dann Turbo-Pascal und damit war Basic dann für mich
gestorben.
Die weitere Entwicklung bei Basic habe ich dann nur am Rande
mitbekommen. Da gabs z.B. den grauenhaften Versuch von Microsoft bei VBA
alles einzudeutschen.
Die ganzen Sachen mit Basic ohne Zeilennummern und was es da noch so gab
war doch alles nur bei Pascal und C abgekuckt. Ich hab mich da immer
gefragt, warum dann nicht gleich Pascal oder C?
Dass Basic bei bestimmten Fehlern nicht rummeckert ist dabei kein
Argument für Basic, weil man z.B. durch die automatische
Variablendeklaration eklige Fehler bekommt, die man z.B. in Pascal wegen
der restriktiven Deklarationsvorschriften praktisch nicht kennt.
Ich bin momentan recht gut zufrieden mit WINAVR.
Und Basic, ganz gleich welcher Dialekt, ist für mich, obwohl ich selber
lange damit gearbeitet habe, einfach eine Pfuschersprache.
Trotzdem denke ich, dass Bascom für den Einstieg gar nicht schlecht ist.
Man sollte da aber dann nicht stehen bleiben...
Gruß
Stefan DF9BI
Uwe Hercksen
Holger Bruns schrieb:
> möglich programmierbar zu machen. Basic kennt viele sinnvolle Konzepte
> aus anderen Programmiersprachen nicht; zum Beispiel schon mal keine
> lokalen Variablen und keine Schleifen wie "repeat ... until" und
> "do...while". War in den 80ern des letzten Jahrhunderts schon tot.
Hallo,
und Du kennst allerdings auch aktuelle Basic Versionen nicht...
Bye
Henning Paul
>> OK, ich entnehme daraus, dass Du den im Buch angesprochenen
>> Basic-Dialekt "Bascom" nicht kennst/angesehen hast. Genau
>> die von Dir angesprochenen Beispiele sind da naemlich expli-
>> zit enthalten. Schau's Dir selbst an:
>
> Also ich habe Anfang der 80er Basic programmiert. Zuerst Basic auf dem
> TRS-80, später auf dem PC. Das nannte sich damals GW-Basic und war im
> Prinzip nicht schlecht.
>
> Irgendwann gabs dann Turbo-Pascal und damit war Basic dann für mich
> gestorben.
So ähnlich war's bei mir auch. Ich bin dann allerdings noch zu C
weitergegangen und habe da mein Zuhause gefunden.
Gruß
Henning
Lutz Schulze
> So ähnlich war's bei mir auch. Ich bin dann allerdings noch zu C
> weitergegangen und habe da mein Zuhause gefunden.
Und ich hänge seitdem dazwischen ;-)
Mit C für Microcontroller und Linux, mit Delphi (Pascal) für Windows.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für Sensoren