Vom PIC zum AVR

[Bernd Maier]

Moin,

ich wollte mal nen AVR ausprobieren, bin aber PICmäßig vorbelastet...

Was ist denn "anders" und welche Fehler sollte ich nicht machen?

Haben alle AVRs interne Pullups?
"Self-Programming" (für Bootloader) können aber nur einige wenige?

MfG,
Bernd

 

[Markus Kaufmann]

Bernd Maier wrote:

Haben alle AVRs interne Pullups?

Ja.

"Self-Programming" (für Bootloader) können aber nur einige wenige?

Vereinfacht gesagt: Alle neueren Modelle, die mindestens 8KB Flash
haben. Eine Übersicht gibts hier (zweitletzte Spalte):
http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC

Markus

 

[Simone Winkler]

Hallo!

Etwas, das zu beachten ist, weil ich auch drauf reingefallen bin: ;-)

AVRs haben Fuses, mit denen man Dinge wie den Oszillator einstellt. Man
stellt aber auch andere Dinge ein, z.B. Art der Programmierung, etc.
Man sollte da keinen Fehler machen, denn wenn man z.B. den Oszillator falsch
einstellt und seriell programmiert, wird das nicht mehr funktionieren, weil
man zum Programmieren den Takt braucht und der dann ja nicht mehr da ist,
weil er falsch eingestellt wurde.
Das ganze ist dann auch noch ein wenig knifflig, da bei einer Fuse '0'
programmiert bedeutet, '1' dagegen unprogrammiert.

Vielleicht ist es besser, nicht PonyProg zum Programmieren des AVRs zu
benutzen.

Als Umgebung ist das WinAVR ganz nett - es ist eine Sammlung von
nicht-kostenpflichtigen Programmen inkl. C compiler (avr-gcc).

LG,
Simone

"Bernd Maier" <gagalus@directbox.com> schrieb im Newsbeitrag
news:2g7m9iF5cau4U1@uni-berlin.de...

Moin,

ich wollte mal nen AVR ausprobieren, bin aber PICmäßig vorbelastet...

Was ist denn "anders" und welche Fehler sollte ich nicht machen?

Haben alle AVRs interne Pullups?
"Self-Programming" (für Bootloader) können aber nur einige wenige?

MfG,
Bernd

 

[Manfred Walker]

"Bernd Maier" <gagalus@directbox.com> schrieb im Newsbeitrag
news:2g7m9iF5cau4U1@uni-berlin.de...

Moin,

ich wollte mal nen AVR ausprobieren, bin aber PICmäßig vorbelastet...

Was ist denn "anders" und welche Fehler sollte ich nicht machen?

Haben alle AVRs interne Pullups?
"Self-Programming" (für Bootloader) können aber nur einige wenige?

Das genialste an den AVRs ist (neben der hohen Geschwingkeit...),
meiner Meinung nach, der BASCOM-AVR Basic-Compiler,
den man kostenlos downloaden und benutzen darf.
Zwar kann die freie Version nur max. 2 K Code erzeugen, der Code
ist aber schnell und effizient - das reicht also für kleine Projekte.
Das Programm hat auch einen eingebauten Simulator, mit dem man
den Code auf Basicebene testen kann.

Auch wenn du der Meinung bist, dass man einen Mikrokontroller
in ASM programmieren sollte - tu dir einen Gefallen und teste
den BASCOM-Compiler !

 

[Bernd Maier]

"Manfred Walker" schrieb:

Auch wenn du der Meinung bist, dass man einen Mikrokontroller
in ASM programmieren sollte - tu dir einen Gefallen und teste
den BASCOM-Compiler !

Nö, ich bin der Meinung, dass man C benutzen möchte (ausser, man muss
gewisse Ausfall-Sicherheitsstandards erfüllen, dann ist C natürlich
"verboten"). Ansonsten trifft man in kritischen Bereichen tatsächlich oft
Pascal und BASIC an.
Aber wenn ich meinen Code jetzt in BASIC mache, wird die Migration auf
andere ľCs unmöglich.

Also falls ich wirklich auf AVRs umsteige, dann nur wegen der Verfügbarkeit
eines freien C-Compilers - da siehts bei den PICs nämlich nicht gut aus.
Ansonsten komme ich mit den PIC18 sehr gut klar.

MfG,
Bernd

 

[Andreas Auer]

Hi

Manfred Walker wrote:

Das genialste an den AVRs ist (neben der hohen Geschwingkeit...),
meiner Meinung nach, der BASCOM-AVR Basic-Compiler,
den man kostenlos downloaden und benutzen darf.
Zwar kann die freie Version nur max. 2 K Code erzeugen, der Code
ist aber schnell und effizient - das reicht also für kleine Projekte.
Das Programm hat auch einen eingebauten Simulator, mit dem man
den Code auf Basicebene testen kann.

Auch wenn du der Meinung bist, dass man einen Mikrokontroller
in ASM programmieren sollte - tu dir einen Gefallen und teste
den BASCOM-Compiler !

Also, wenn man der Programmiersprache C mächtig ist, dann sollte man auf
Basic auf jedenfall verzichten. Vor kurzem bekam ich auch mal eine
kleine Statistik geschickt, bezüglich der Geschwindigkeit des Codes, der
mit BASCOM-AVR erstellt wurde. Die Ergebnisse waren nicht sehr berauschend.

Ergebnisse des Tests:
Bei nem Test des SPI Interface mit BASCOM dauerte das Senden von 64kByte
Daten ~6 Sekunden -> was ca. 10kByte/s ausmacht.
I2C hat da noch schlechter abgeschnitten:
I2C 64 Kbyte lesen: sagenhafte 45 sekunden, was dann etwa 1400 bytes/sekunde

Soviel zu BASCOM!!

mfg
Andreas
--

Andreas Auer aauer1 (at) sbox.tugraz.at
Student of Telematics http://home.pages.at/aauer1
Graz University of Technology

 

[Holger Klabunde]

Hallo Bernd,

Nö, ich bin der Meinung, dass man C benutzen möchte (ausser, man muss
gewisse Ausfall-Sicherheitsstandards erfüllen, dann ist C natürlich
"verboten").

das mußt du mir aber mal ausführlicher erklären warum C keine
Sicherheitsstandards erfüllt !? Code ist besser lesbar und auf
jeden Fall leichter zu pflegen als ASM. ASM einfügen aber auch kein Problem.

Also falls ich wirklich auf AVRs umsteige, dann nur wegen der Verfügbarkeit
eines freien C-Compilers - da siehts bei den PICs nämlich nicht gut aus.
Ansonsten komme ich mit den PIC18 sehr gut klar.

Ich mache sehr viel mit PIC's. Was dabei aber immer nervt ist das Code- und
RAM-Banking. Das gibt es bei AVR's einfach nicht. Bei ATMega32 kann man sich
mit AVR-GCC mal eben so ein zusammenhängendes 1kB RAM Array reservieren.

Deshalb liebe ich die AVR's oder besser
ATMegas. Mit AVR's sollte man nichts mehr machen. Wird einer nach dem anderen
abgekündigt. Nimm gleich einen ATMega oder ATiny.

Leider sind die Atmel Viecher manchmal nicht so leicht zu bekommen. Auf die
letzten ATMega8 habe ich 3 Monate warten müssen. Bei PIC's ist mir sowas noch
nicht passiert. Die Verfügbarkeit scheint besser zu sein.

Ansonsten bin ich vom ehemals PIC-User schon fast komplett auf Atmel umgestiegen.
Es macht einfach mehr Spaß sich um RAM-Banking nicht mehr kümmern zu müssen.
Auch wenn behauptet wird das es das bei PIC18 nicht mehr gibt habe ich bis heute noch nicht
herausgefunden wie man den C18 Compiler von Mchip dazu überredet ohne RAM-Banking zu
arbeiten bzw. 512Byte RAM am Stück für ein zusammenhängendes Byte Array zu bekommen.

PIC benutze ich nur noch in Sonderfällen weil z.B. bei PWM feinere Abstufungen drin sind,
oder wenn es ein Chip in DIP18 oder kleiner sein soll.

Gruß
Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm

 

[Bernd Maier]

"Holger Klabunde" schrieb:

Nö, ich bin der Meinung, dass man C benutzen möchte (ausser, man muss
gewisse Ausfall-Sicherheitsstandards erfüllen, dann ist C natürlich
"verboten").

das mußt du mir aber mal ausführlicher erklären warum C keine
Sicherheitsstandards erfüllt !? Code ist besser lesbar und auf
jeden Fall leichter zu pflegen als ASM. ASM einfügen aber auch kein
Problem.

Ich schrieb auch nicht "schlechter" als ASM, sondern "schlechter" als z.B.
Pascal. C-Code ist z.T. kryptisch und schlecht lesbar, und Pointer sind
immer kritisch, z.B. weil der Progger zwei Wochen später selber nicht mehr
durchsteigt und herrenlose Pointer die übelsten Fehler verursachen. (Dafür
gibt es haufenweise empirische Belege.) Man kann im Fehlerfall keinen
definierten Zustand erreichen, wenn ein Pointer quer durch den Speicher
ballert.

(Trotzdem benutzte ich gerne C

Irgendwelche us-amerikanischen Richtlinien für Rüstungsaufträge verbieten
sogar explizit den Einsatz von C. Google weiß sicher mehr.

Für die Software von Verkehrsleitsystemen wird übrigens sehr oft
Pascal/Turbo-Vision von Borland eingesetzt.

Grüße,
Bernd

 

[Holger Klabunde]

das mußt du mir aber mal ausführlicher erklären warum C keine
Sicherheitsstandards erfüllt !? Code ist besser lesbar und auf
jeden Fall leichter zu pflegen als ASM. ASM einfügen aber auch kein
Problem.

Ich schrieb auch nicht "schlechter" als ASM, sondern "schlechter" als z.B.
Pascal. C-Code ist z.T. kryptisch und schlecht lesbar, und Pointer sind
immer kritisch, z.B. weil der Progger zwei Wochen später selber nicht mehr
durchsteigt und herrenlose Pointer die übelsten Fehler verursachen. (Dafür
gibt es haufenweise empirische Belege.) Man kann im Fehlerfall keinen
definierten Zustand erreichen, wenn ein Pointer quer durch den Speicher
ballert.

das ist aber kein Fehler von C sondern der Fehler der Programmierer.
C ist nicht kryptisch wenn man sich nicht am Wettbewerb "wie schreibe ich
ein komplettes Programm in nur einer einzigen Zeile" beteiligt.
C Codes sind genauso gut lesbar wie Pascal wenn man nicht mehrere Operationen
in einem unübersichtlichen Konstrukt programmiert. Man muß sich nur einen
guten Programmierstil zulegen. Dann kann auch ein Pascal Programmierer meinen C-Code
ohne Probleme lesen so wie ich den Pascal Code von ihm lesen kann.

Wenn ein Programmierer nach zwei Wochen nicht mehr weiß was er da
programmiert hat liegt das nur daran das er, wie es eigentlich sein sollte,
das Programm nicht mit den nötigen Kommentaren versehen hat.

Pointer geraten nur außer Kontrolle wenn der Programmierer zu faul/blöde war
die Grenzen selbst festzulegen. Bei ASM dürfte das Problem aber noch schlimmer sein !

Und auch bei Basic/Pascal muß man sich darauf verlassen das der Interpreter/Compiler wirklich alles
richtig macht. Ich habe schon oft erlebt das nicht mein Programm falsch war sondern das was der
Compiler daraus gemacht hat Damit muss jeder leben der eine Hochsprache benutzt.

Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm

 

[Manfred Glahe]

Andreas Auer <aauer1@sbox.tugraz.at> wrote in message news:<409fd2c3$0$11742$3b214f66@aconews.univie.ac.at>...

Hi

Manfred Walker wrote:
Das genialste an den AVRs ist (neben der hohen Geschwingkeit...),
meiner Meinung nach, der BASCOM-AVR Basic-Compiler,
den man kostenlos downloaden und benutzen darf.
Zwar kann die freie Version nur max. 2 K Code erzeugen, der Code
ist aber schnell und effizient - das reicht also für kleine Projekte.
Das Programm hat auch einen eingebauten Simulator, mit dem man
den Code auf Basicebene testen kann.

Auch wenn du der Meinung bist, dass man einen Mikrokontroller
in ASM programmieren sollte - tu dir einen Gefallen und teste
den BASCOM-Compiler !

Also, wenn man der Programmiersprache C mächtig ist, dann sollte man auf
Basic auf jedenfall verzichten. Vor kurzem bekam ich auch mal eine
kleine Statistik geschickt, bezüglich der Geschwindigkeit des Codes, der
mit BASCOM-AVR erstellt wurde. Die Ergebnisse waren nicht sehr berauschend.

Ergebnisse des Tests:
Bei nem Test des SPI Interface mit BASCOM dauerte das Senden von 64kByte
Daten ~6 Sekunden -> was ca. 10kByte/s ausmacht.
I2C hat da noch schlechter abgeschnitten:
I2C 64 Kbyte lesen: sagenhafte 45 sekunden, was dann etwa 1400 bytes/sekunde

Soviel zu BASCOM!!

mfg
Andreas

Hallo Bernd,

ich denke das hängt vom Einsatz des ľP ab. Mit dem PIC kannst Du in
sehr störanfälliger Umgebung (Geschaltete Stromversorgungen,
Wechselrichter, Motorsteuerungen usw.)arbeiten. Die lassen sich,
selbst von stärkeren Spannungsrückwirkungen im Störfall, nicht so
schnell aus dem Takt bringen.
Von AVR'S habe ich da schon einiges gehört, habe aber keine eigenen
Erfahrungen damit.
Das Ram Banking ist am Anfang zwar nervig, aber man gewöhnt sich dran.
Programme für den (kleinen)PIC sind in der Regel kurz und daher auch
in Assembler übersichtlich. Wer von der Hardware Seite zum PIC kommt
ist da sehr gut aufgehoben!
Noch was zu Compilern und deren assemblierte Code's. Alle mir
bekannten Compiler (einschließlich TP- Compiler) erstellen den Code
für einen 68HC811E2 ohne "INIT". Diese Vorgehensweise sorgt dafür, daß
ich meine eigenen Assemblerprogramme, währen sie in TP geschrieben,
niemals in den 2KB Speicher bekommen hätte. Diese Compiler jedenfalls
gingen mit RAM und Zeit sehr verschwenderisch um.

MfG Manfred Glahe

 

[Georg Meister]

Das genialste an den AVRs ist (neben der hohen Geschwingkeit...),
meiner Meinung nach, der BASCOM-AVR Basic-Compiler,
den man kostenlos downloaden und benutzen darf.
Zwar kann die freie Version nur max. 2 K Code erzeugen, der Code
ist aber schnell und effizient - das reicht also für kleine Projekte.
Das Programm hat auch einen eingebauten Simulator, mit dem man
den Code auf Basicebene testen kann.

Auch wenn du der Meinung bist, dass man einen Mikrokontroller
in ASM programmieren sollte - tu dir einen Gefallen und teste
den BASCOM-Compiler !

Ich hab vor einigen Jahren mit AVR und BASCOM angefangen. Nach massiven
Performanceproblemen und seltsamsten Fehlern bin ich nach kurzer Zeit auf
den CodeVisionAVR C-Compiler umgestiegen und bin bis heute sehr zufrieden
damit. Kann ich nur empfehlen und dazu auch gleich noch den JTAG-ICE,
entweder von Atmel oder zum Bruchteil des Preises als Nachbau.

Möglich, dass vielleicht die aktuelle BASCOM-Version besser funktioniert und
ich hab sogar noch die Lizenz dafür, aber ich hab einfach keine Lust, das
nochmal auszuprobieren.

Georg

 

[MaWin]

Joerg Wunsch <j@ida.interface-business.de> schrieb im Beitrag <c7q0m3$uc1$2@innocence.interface-business.de>...

Sonst würde es nicht alle 5 Minuten ein neues Sicherheitsloch in
irgendwelcher Internet-Software geben,

Gegen semantische Probleme hilft keine noch so strenge Programmiersprache,
und syntaktische Probleme (z.B. der klassische Buffer Overrun) muss man
ja nicht programmieren.
Letztlich wird aus jeder Programmiersprache Assembler-Maschinencode.

auch hätte niemand Ada erfinden müssen.

Haette auch niemand, wie der Rest der Welt, abgesehen von den

Militaers, weiss. Uebrigend findet nicht jede in Ada programmierte
Rakete ihr Ziel, auch dort gibt es Softwareprobleme.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Joerg Wunsch]

Holger Klabunde <holger.klabunde@t-online.de> schrieb:

das mußt du mir aber mal ausführlicher erklären warum C keine
Sicherheitsstandards erfüllt !?

Sonst würde es nicht alle 5 Minuten ein neues Sicherheitsloch in
irgendwelcher Internet-Software geben, auch hätte niemand Ada erfinden
müssen.

Deshalb liebe ich die AVR's oder besser ATMegas. Mit AVR's sollte
man nichts mehr machen. Wird einer nach dem anderen
abgekündigt. Nimm gleich einen ATMega oder ATiny.

Auch ATmega und ATtiny /sind/ AVRs. Was Du meinst, sind die alten
AT90 AVRs (auch die alten ATtinys und die ATmega103/163 gehören
übrigens zur alten Garde).

Leider sind die Atmel Viecher manchmal nicht so leicht zu
bekommen. Auf die letzten ATMega8 habe ich 3 Monate warten müssen.

Das scheint aber eher ein ATmega8-Problem (besonders der DIL-Version)
zu sein als ein allgemeines ATmega-Problem. ATmega16 oder 128 gab's
IMHO allzeit genügend. Liegt vermutlich daran, daß die 8er für die
vielen gebotenen Funktionen einen recht attraktiven Preis haben.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
Kristian Köhntopp, de.comp.os.unix.misc

 

[Michael Hofmann]

Joerg Wunsch wrote:

Holger Klabunde <holger.klabunde@t-online.de> schrieb:

das mußt du mir aber mal ausführlicher erklären warum C keine
Sicherheitsstandards erfüllt !?

Sonst würde es nicht alle 5 Minuten ein neues Sicherheitsloch in
irgendwelcher Internet-Software geben,

<gg> Der war gut. Internet-Software ist unsicher weil in C programmiert,
das muss ich mir merken. Kann ich nun extrapolieren dass Micro$oft-Zeugs
deshalb so schrottig ist, weil in C++ programmiert?

SCNR,
Michael

 

[Joerg Wunsch]

Michael Hofmann <westbound@gmx.net> schrieb:

Kann ich nun extrapolieren dass Micro$oft-Zeugs
deshalb so schrottig ist, weil in C++ programmiert?

Ja, zumindest zum Teil. (Zum anderen Teil, weil jeder dritte
Programmierer bei M$ offenbar nicht mehr weiß, was die ersten beiden
vor ihm gemacht haben, und stattdessen für dasselbe Problem das API
komplett neu zimmert.) Ist aber nicht der einzige C++-Schrott, CDE
beispielsweise fällt gut auch in diese Kategorie.

Soll ja nicht heißen, daß man nicht auch in C vernünftig programmieren
könnte, aber C unterstützt halt die Faulheit der Programmierer, hie
und da mal Fehlertests wegzulassen oder sich nicht so völlig exakt um
die Grenzen der allozierten Arrays zu kümmern...
--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
Kristian Köhntopp, de.comp.os.unix.misc

 

[Bernd Maier]

"Holger Klabunde" schrieb:

das ist aber kein Fehler von C sondern der Fehler der Programmierer.

Na sicher ist das ein Fehler der Programmierer. Aber die Eigenschaften von C
provozieren diese Probleme.

Grüße,
Bernd

 

[Holger Klabunde]

das ist aber kein Fehler von C sondern der Fehler der Programmierer.

Na sicher ist das ein Fehler der Programmierer. Aber die Eigenschaften von C
provozieren diese Probleme.

das ist der größte Schwachsinn den ich je gehört habe. Ich kann ein Programm mit Absturzgarantie
in C, Assembler, Pascal , Basic oder Fortran und was es da sonst noch gibt schreiben.
Das liegt nicht an der Hochsprache sondern am Programmierer. Wenn es
eine Sprache gibt die unübersichtlich ist und zu Fehlern neigt dann ist das Assembler.
Und ALLE Hochsprachen erzeugen im Endeffekt Assembler. Du kannst dein Programm auch in Basic
oder Pascal zum hängen bringen wenn du Schleifen programmierst deren Abbruchkriterium nie
erreicht wird. Liegt der Fehler dann bei deinem Compiler ? Nein, DUUUU hast den Mist programmiert.

Linux z.B. ist zum größten Teil in C geschrieben. Stürzt lange nicht so oft ab wie Win.
Und es soll ja Leute geben die behaupten Linux wäre ein stabiles System

Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm

 

[Markus Kaufmann]

Holger Klabunde wrote:

das ist aber kein Fehler von C sondern der Fehler der Programmierer.

Na sicher ist das ein Fehler der Programmierer. Aber die Eigenschaften von C
provozieren diese Probleme.

das ist der größte Schwachsinn den ich je gehört habe. Ich kann ein Programm mit Absturzgarantie
in C, Assembler, Pascal , Basic oder Fortran und was es da sonst noch gibt schreiben.

Von Vorsatz hat ja keiner geredet.

Das liegt nicht an der Hochsprache sondern am Programmierer. Wenn es
eine Sprache gibt die unübersichtlich ist und zu Fehlern neigt dann ist das Assembler.

Daß Assembler noch schlimmer sei hat ja auch keiner bestritten.

Und ALLE Hochsprachen erzeugen im Endeffekt Assembler. Du kannst dein Programm auch in Basic
oder Pascal zum hängen bringen wenn du Schleifen programmierst deren Abbruchkriterium nie
erreicht wird. Liegt der Fehler dann bei deinem Compiler ? Nein, DUUUU hast den Mist programmiert.

Wenn Du in C Strings mit strcpy+strcat bearbeitest und dabei den
Längencheck vergißt, dann hast Du u.U. ein Sicherheitsloch. In
Pascal oder Java nicht.

Man kommt in Pascal ohne Pointer auch deutlich weiter als in C.
Als ich mit C angefangen habe sind meine Programme jedenfalls
deutlich häufiger abgestürzt als beim Pascal-Einstieg.

Linux z.B. ist zum größten Teil in C geschrieben. Stürzt lange nicht so oft ab wie Win.
Und es soll ja Leute geben die behaupten Linux wäre ein stabiles System

Natürlich *kann* man in C auch stabile Software schreiben. Die
Behauptung hier ist ja nur, daß dies schwieriger als in anderen
Sprachen sei. Auch im professionellen Umfeld wird Software nicht
nur von Leuten mit 10 Jahren Erfahrung geschrieben. Die
Wahrscheinlichkeit daß ein C-Anfänger fehlerhaften Code schreibt
ist IMHO größer ist z.B. bei den Pascal- oder Basic-Anfängern.

Markus

 

[Hergen Lehmann]

Holger Klabunde <holger.klabunde@t-online.de> wrote:

Das liegt nicht an der Hochsprache sondern am Programmierer. Wenn es
eine Sprache gibt die unübersichtlich ist und zu Fehlern neigt dann ist das Assembler.

Einspruch, euer Ehren!

Bei überschaubaren Aufgaben im Embedded-Bereich ist Assembler IMO
immer noch das Mittel der Wahl, weil man nur damit wirklich die
100%ige Kontrolle über die Hardware und die korrekte Funktion der
Software hat.

*JEDE* Hochsprache bringt dagegen Unwägbarkeiten mit sich, weil man
sich zusätzlich von Laufzeitbibliotheken und eventuellen Compiler-
fehlern abhängig macht. Gerade Compiler für kleine Embedded-Systeme
sind da vergleichsweise anfällig, weil sich durch das kleine RAM und
nicht hochsprachenoptimierte Befehlssätze vieles nicht so umsetzen
lässt, wie sich die Väter der Sprache das gedacht hatten.

Hergen

 

[Bernd Maier]

"Holger Klabunde" <holger.klabunde@t-online.de> schrieb:

Na sicher ist das ein Fehler der Programmierer. Aber die Eigenschaften
von C
provozieren diese Probleme.

das ist der größte Schwachsinn den ich je gehört habe.

Also ich will mich jetzt nicht streiten. (gehört??? )
Vielleicht magst du ja mal ein Buch über Software Engineering lesen...

Ich kann ein Programm mit Absturzgarantie
in C, Assembler, Pascal , Basic oder Fortran und was es da sonst noch gibt
schreiben.

Es ist schwer mit Pascal, Basic oder Fortran einen harten Crah zu
povozieren, in Java so gut wie unmöglich. Mit C passiert sowas regelmäßig
aus Versehen.

Linux z.B. ist zum größten Teil in C geschrieben. Stürzt lange nicht so
oft ab wie Win.
Und es soll ja Leute geben die behaupten Linux wäre ein stabiles System

Wie gesagt, ich mag C, und auch Linux - aber wenn man sich mal die
Sicherheitsmeldungen (z.B. bei Debian.org anschaut), dann merkt man recht
schnell, dass die Sicherheit bei Linux z.T. eine Urban Legend ist. Und die
neuen Windows nehmen sich im Vergleich zu Linux nicht viel in der
Stabilität.
Ich habe gestern in einen Linux Server wieder (nach einem Monat seit dem
lezten Update!) 75MB Security Patches eingespielt, bei einer Distribution,
die seit 2 Jahren als 'Stable' eingestuft wird und kaum verändert wird. Und
dabei ist die ganze Installation gerade mal um 400MB groß.

Zum professionellen Umgang mit mit einer Technologie - sei es nun C, Linux
oder sonstwas - gehört eben auch, dass man ihre Schwächen kennt und
berücksichtigt.

MfG,
Bernd