Vom PIC zum AVR

[Uwe Hercksen]

Holger Klabunde schrieb:

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.

Hallo,

die Gefährlichkeiten eines Pointers scheinen Dir nicht klar zu sein.
In Sprachen die keinen Pointer haben und alle Feldgrenzen auf Einhaltung
überprüfen kann man nicht einen Absturz provozieren indem man an einer
Adresse schreibt wo man nichts verloren hat.

Bye

 

[MaWin]

Bernd Maier <gagalus@directbox.com> schrieb im Beitrag <2ge53uF1oepoU1@uni-berlin.de>...

Vielleicht magst du ja mal ein Buch über Software Engineering lesen...

Ich liebe diese Buecher.

Schon frueher kam mir der Inhalt immer etwas unpraktikabel vor.
Und vor allem so gaenzlich aus dem Nichts gesaugt.

War ja auch kein Wunder, da die Autoren meistens noch gar kein
grosses, kommerziell erfolgreiches Produkt geschrieben hatten,
sondern nach ihrem ersten gescheiterten Kleinprojekt gleich der
Meinung waren, ihre Unkenntnis in ein Buch schreiben zu muessen.

Die haben ihre Theorie nur aus Univorlesungen gesaugt. Die von
Theoretikern gehalten wurden, die ihrerseits noch nie ein echtes
Programm geschrieben hatten.

Wie erhellend war es, als man im Internet endlich mal die originalen
Sourcen von wirklichen zu ihrer Zeit kommerziell herausragend
erfolgreichen Programmen, wie CP/M, GEM oder **** finden konnte.

Strafen diese source codes doch all den Software Engineering Buechern
Luegen. Und zeigt das doch, das man nicht alles glauben sollte, was
irgendwelche Deppen zu Papier bringen.
--
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.

 

[Georg Acher]

In article <2ge53uF1oepoU1@uni-berlin.de>,
"Bernd Maier" <gagalus@directbox.com> writes:

|> 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.

Habe ich da gerade Java gehört? Write once, crash everywhere... Die meisten
Darstellungsprobleme und Crashes habe ich bislang mit Java gehabt, auch bei SW,
die das passende JRE (zB. für Solaris) gleich mitliefert. Es ist dabei egal, ob
das Konzept selbst sowas nicht zulässt, aber wenn man zum Ausführen von
Hello-World allein schon über 50 Klassen und mehrere MB Sourcecode braucht,
MÜSSEN da einfach mehr Fehler drin sein. Es fängt bei ClassNotFound an (brauche
ich jetzt zum Glücklichwerden 1.1.18, 1.2, 1.3 oder 1.4?) und geht bis zu
NullPointerExceptions. Diverse Programme laufen nur mit dem 1.2er JIT (sunwjit)
und nicht mit HotSpot, andere haben Probleme mit dem Redraw und den Fonts.

Ne, also wenn ich was plattformunabhängiges will, nehme ich Perl

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

 

[Bernd Maier]

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

Vielleicht magst du ja mal ein Buch über Software Engineering lesen...

Ich liebe diese Buecher.

Schon frueher kam mir der Inhalt immer etwas unpraktikabel vor.

Ja, genau. Und weil es mehr Arbeit macht und mehr kostet verzichten viele
darauf und gehen zum "Cowboy Coding" über. Und wenn sie damit die Klappe
fallen, müssen sie weinen.

Und vor allem so gaenzlich aus dem Nichts gesaugt.

War ja auch kein Wunder, da die Autoren meistens noch gar kein
grosses, kommerziell erfolgreiches Produkt geschrieben hatten,
sondern nach ihrem ersten gescheiterten Kleinprojekt gleich der
Meinung waren, ihre Unkenntnis in ein Buch schreiben zu muessen.

Wer solche Bücher kauft ist doch selbst Schuld.

Wie erhellend war es, als man im Internet endlich mal die originalen
Sourcen von wirklichen zu ihrer Zeit kommerziell herausragend
erfolgreichen Programmen, wie CP/M, GEM oder **** finden konnte.

Strafen diese source codes doch all den Software Engineering Buechern
Luegen. Und zeigt das doch, das man nicht alles glauben sollte, was
irgendwelche Deppen zu Papier bringen.

Einige erfolgreiche Projekte, die ohne SE-Techniken ausgekommen sind,
widerlegen doch nicht alle SE-Konzepte. Übrigens stammen die meisten dieser
Konzepte durchaus aus der Praxis. Das sind z.T. so triviale Dinge wie
Cross-Inspection, die die Qualität aber ungemein steigern. Sowas wird z.B.
am Linux-Kernel mit Erfolg praktiziert.

MfG,
Bernd

 

[Bernd Maier]

"Georg Acher" <acher@in.tum.de> schrieb:

|> 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.

Habe ich da gerade Java gehört? Write once, crash everywhere...
[...]
Es fängt bei ClassNotFound an (brauche
ich jetzt zum Glücklichwerden 1.1.18, 1.2, 1.3 oder 1.4?) und geht
bis zu NullPointerExceptions.

Nee, mit "hartem Crash" meine ich Fehler, die dein OS instabil machen.
Klassischerweise also zum Anhalten bringen, Kernel Panic oder BSODs
auslösen.

Sowas ist in Java wegen der Garbage Collection und mit der Sandbox nur
schwer hinzubekommen. Konzepte wie Pointer in C erleichtern dieses aber
ungemein.

MfG,
Bernd

 

[Georg Acher]

In article <2geootF1vsatU2@uni-berlin.de>,
"Bernd Maier" <gagalus@directbox.com> writes:

|> Nee, mit "hartem Crash" meine ich Fehler, die dein OS instabil machen.
|> Klassischerweise also zum Anhalten bringen, Kernel Panic oder BSODs
|> auslösen.

Sowas ist aber auch unter C (im Userspace) recht schwer zu schaffen.

|> Sowas ist in Java wegen der Garbage Collection und mit der Sandbox nur
|> schwer hinzubekommen. Konzepte wie Pointer in C erleichtern dieses aber
|> ungemein.

Naja, mit Java geht's deswegen nicht, weil es kaum ein Betriebssystem gibt, das
in Java geschrieben ist... Und die wenigen Versuche, die tatsächlich existieren,
brauchen dann leider auch wieder Erweiterungsbefehle in der JVM, um Pointer
nachzumachen. Irgendwann muss man mit der Hardware reden, und die versteht keine
Referenzen und Konstantenpools.

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

 

[Axel Schwenke]

"Bernd Maier" <gagalus@directbox.com> wrote:

Nee, mit "hartem Crash" meine ich Fehler, die dein OS instabil machen.
Klassischerweise also zum Anhalten bringen, Kernel Panic oder BSODs
auslösen.

Mit einem richtigen OS passiert sowas gar nicht. Schlimmstenfalls
crasht das Programm, aber nicht das Betriebssystem. Das ist deswegen
so, weil richtige Betriebssysteme die Programme auch in eine Art
Sandbox sperren.

Sowas ist in Java wegen der Garbage Collection und mit der Sandbox nur
schwer hinzubekommen.

Stimmt. Ganze Klassen von Fehlern schließt Java per Design aus.
Allerdings sind die Designer IMHO an manchen Stellen zu weit gegangen.
Ohne Flinte kann man sich zwar nicht mehr in den Fuß schießen, man kann
aber auch nichts anderes mehr erlegen.

Speziell im Embedded-Bereich (wo der Thread ja angefangen hat) ist
natürlich der Bloat von Java allein schon ein Ausschlußkriterium.


XL
--
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau

 

[Bernd Maier]

"Axel Schwenke" <schwenke@jobpilot.de> schrieb:

Speziell im Embedded-Bereich (wo der Thread ja angefangen hat) ist
natürlich der Bloat von Java allein schon ein Ausschlußkriterium.

Ja, stimmt. Obwohl Maxim ja seit längerem versucht, (Pseudo-)Java in
Embedded-Systemen zu etablieren. Und für PICs hab ich auch schon irgendwas
javaartiges gelesen...

MfG,
Bernd

 

[MaWin]

Bernd Maier <gagalus@directbox.com> schrieb im Beitrag <2geootF1vsatU2@uni-berlin.de>...

Nee, mit "hartem Crash" meine ich Fehler, die dein OS instabil machen.

Dann war es ein Scheiss OS (zumindest seit dem es MMUs gibt).

Es gibt KEINEN, aber auch gar KEINEN Grund, warum eine
Applikation das OS killen sollte. Das OS kann ALLES unternehmen,
damit ihm das nicht passiert, z.B. Parameter checken, Traps
installieren, etc.
Ein gutes OS laesst sogar die Applikation nach einem getrappten Fehler
()z.B. ignoriertes read/write auf nicht zu ihm gehoerenden Speicher oder
IO) weiterlaufen.

Konzepte wie Pointer in C erleichtern dieses aber ungemein.

Was erleichten die ? Zu glauben, das das OS sich nicht um Speicherverwaltung
kuemmen muss ?
--
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.

 

[Holger Klabunde]

die Gefährlichkeiten eines Pointers scheinen Dir nicht klar zu sein.

doch natürlich. Deshalb gehe ich damit ja auch sehr vorsichtig um.

In Sprachen die keinen Pointer haben
und alle Feldgrenzen auf Einhaltung
überprüfen kann man nicht einen Absturz provozieren indem man an einer
Adresse schreibt wo man nichts verloren hat.

Eine Division durch 0 ist auch gefährlich. Sollte man deshalb Compiler
meiden mit denen man dividieren kann ? Es ist auch gefährlich wenn man
statt PORTB PORTA tippt. Das provoziert ja geradezu einen Programmfehler
bei dem der Compiler nicht meckert. Irgendwie muß man beim programmieren
eben seinen Verstand benutzen. Einen Compiler der rät was man eigentlich
programmieren wollte gibt es leider nicht.

Pointer gibts nicht nur in C:
Pascal adr:=$0800; {Beginn bei RAM Adresse 0x0800 } geht bei NiliPascal jedenfalls
Basic peek und poke glaube ich schon mal gesehen zu haben

Ein Pointer gerät doch nicht von alleine außer Kontrolle.
Irgenwer muß ihm ja gesagt haben er soll weiterzählen und in Adressen schreiben. Wenn
man nicht aufpasst wohin der Pointer zeigt (z.B. gar nichts reinschreibt )
dann ist das für mich ein NORMALER Programmierfehler wie eine Formel falsch einzutippen.

Wer Pointer nicht mag oder nicht versteht muß sie ja nicht benutzen.

Holger

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

 

[MaWin]

Bernd Maier <gagalus@directbox.com> schrieb im Beitrag <2geoosF1vsatU1@uni-berlin.de>...

Ja, genau. Und weil es mehr Arbeit macht und mehr kostet verzichten viele
darauf und gehen zum "Cowboy Coding" über. Und wenn sie damit die Klappe
fallen, müssen sie weinen.

Zeig mir mal deine grossen, kommerziell erfolgreichen Programme, oder schwaetzt du bloss ?

homepage: http://www.geocities.com/mwinterhoff/

Einige erfolgreiche Projekte, die ohne SE-Techniken ausgekommen sind,
widerlegen doch nicht alle SE-Konzepte.

Es soll sogar Programme geben, die TROTZ Verwendung von SE-Methoden lauffaehig waren.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
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.

 

[Laurent Schmalen]

On Wed, 12 May 2004 17:32:27 +0200, "Bernd Maier"
<gagalus@directbox.com> wrote:

"Axel Schwenke" <schwenke@jobpilot.de> schrieb:

Speziell im Embedded-Bereich (wo der Thread ja angefangen hat) ist
natürlich der Bloat von Java allein schon ein Ausschlußkriterium.


Ja, stimmt. Obwohl Maxim ja seit längerem versucht, (Pseudo-)Java in
Embedded-Systemen zu etablieren. Und für PICs hab ich auch schon irgendwas
javaartiges gelesen...

Bei uns an der Uni gibts sogar ein Seminar (oder Praktikum?!) was sich
"Java für eingebettete Systeme" nennt ... *schauder*

--
Laurent

 

[Bernd Maier]

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

Zeig mir mal deine grossen, kommerziell erfolgreichen Programme,

Nur gegen NDA

Aber schau dir doch mal z.B. die Produkte von SAP an. Glaubst du wirklich,
dass man dort auf Dinge wie Code Reviews, Prototyping, Anforderungsanalysen
oder konzeptionelle UML-Entwürfe verzichten kann? (und jetzt komm mir biite
nicht mit SAP ist aber sch**sse...)
Oder schau dir eine Bank an: glaubst du, dass die irgendwelche Programme
ohne genaue Analyse auf die Produktivdaten loslassen? (jaja, die Banken sind
auch alle...

Einige erfolgreiche Projekte, die ohne SE-Techniken ausgekommen sind,
widerlegen doch nicht alle SE-Konzepte.

Es soll sogar Programme geben, die TROTZ Verwendung von SE-Methoden
lauffaehig waren.

Vielleicht reden wir nur aneinander vorbei, aber SE ist nicht besonders
esoterisch oder ideologisch geprägt...
Das sind zum größten Teil Basistechnologien:
Selbst wenn du dir ein doofes Flussdiagramm oder einen Ablaufplan aufmalst
betreibst du schon SE.

MfG,
Bernd

 

[Bernd Maier]

"Laurent Schmalen" <loron@gmx.de> schrieb:

Bei uns an der Uni gibts sogar ein Seminar (oder Praktikum?!) was sich
"Java für eingebettete Systeme" nennt ... *schauder*

Aber bitte sofort den Link her!
Gibts nen Skript davon zum downloaden?

MfG,
Bernd

 

[MaWin]

Bernd Maier <gagalus@directbox.com> schrieb im Beitrag <2gf74tF2998nU1@uni-berlin.de>...

Nur gegen NDA

Kein Problem, schick her.

Aber schau dir die Produkte von SAP oder einer Bank an.

Danke, die kenne ich. Inside-out. Die finde sogar ich uebel. Ohne das ich nun
auf Befolgung von SE-Techniken besonderen Wert legen wuerde.

aber SE ist nicht besonders esoterisch oder ideologisch geprägt...

Doch, schon, das ist ja das Problem.

Selbst wenn du dir ein doofes Flussdiagramm oder einen Ablaufplan aufmalst
betreibst du schon SE.

Kindergartenhorizont.

Wie gross meinst du ist das Flussdiagramm eines ordentlichen kommerziellen
Programms ? So gross wie ein Fussballfeld ? Welchen Ueberblick gewinne ich,
wenn mir jemand ein vollgekritzeltes Fussballfeld ausrollt ?
--
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.

 

[Matthias Weißer]

MaWin schrieb:

Wie gross meinst du ist das Flussdiagramm eines ordentlichen kommerziellen
Programms ? So gross wie ein Fussballfeld ? Welchen Ueberblick gewinne ich,
wenn mir jemand ein vollgekritzeltes Fussballfeld ausrollt ?

Du bist also der Meinung man sollte eine großes System (z.B. eine
Trägerrakte) ohne jegliche Pläne entwickeln? Einfach den Mechaniker an
die Fräßmaschine stellen und sagen: "Fräß mal eine Triebwerksglocke"
Bekommt er vielleicht auch hin. Aber wird diese Glocke auch noch bei den
üblichen Verbrennungstemperaturen stabil sein?

Man braucht Pläne um große Systeme zu erstellen. Niemand sagt das man
beim System-Entwurf einer Trägerrakete die Farbe der Tankisolierung
definieren muß. Es sollte aber im Hinblick auf die Anwendung geplant
werden ob es sich um ein ein- oder mehrstufiges Konzept mit Flüßig- oder
Feststoffantrieb wird.

SE ist nichts anderes als Pläne zu erstellen wie man ein Produkt
anschließend fertigt. In der Mechanik macht man das seit Jahrhunderten.
Und in der Software soll dieses Vorgehen sinnlos sein?

--
Matthias Weißer
matthias@matwei.de
http://www.matwei.de

 

[Bernd Maier]

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

Aber schau dir die Produkte von SAP oder einer Bank an.

Ok, wenn hier meine Zitate schon verändert werden, sollten wir die
Diskussion einfach beenden.

Danke, die kenne ich. Inside-out. Die finde sogar ich uebel. Ohne das ich
nun
auf Befolgung von SE-Techniken besonderen Wert legen wuerde.

Jaja, und deshalb macht SAP auch gute Geschäfte und hat einen recht hohen
Marktanteil. Ohja, ich weiss, jetzt kommt dein Argument, dass die
Beschaffung nur von Bekloppten und BWLern ohne Ahnung gemacht wird usw.
usw...

aber SE ist nicht besonders esoterisch oder ideologisch geprägt...

Doch, schon, das ist ja das Problem.

Ja. Das Problem dieser Konversation.

Selbst wenn du dir ein doofes Flussdiagramm oder einen Ablaufplan
aufmalst
betreibst du schon SE.

Kindergartenhorizont.

Soo, auf eine böse Bemerkung verzichte ich hier einfach.

Wie gross meinst du ist das Flussdiagramm eines ordentlichen kommerziellen
Programms ? So gross wie ein Fussballfeld ? Welchen Ueberblick gewinne
ich,
wenn mir jemand ein vollgekritzeltes Fussballfeld ausrollt ?

Ja, stimmt, du hast Recht, jetzt sehe ich es auch.

Wollen wir uns nun wieder emotional neutralen Themen zuwenden?
Wie wäre es mit "Weller vs. Ersa"?

Gute Nacht,
Bernd

 

[Hergen Lehmann]

Matthias Weißer <matthias@matwei.de> wrote:

Du bist also der Meinung man sollte eine großes System (z.B. eine
Trägerrakte) ohne jegliche Pläne entwickeln? Einfach den Mechaniker an

Die weitaus meisten Softwareprojekte haben nur einen winzigen
Bruchteil des Etats und der Entwicklungszeit im Vergleich zu einem
Raumfahrtprojekt. Du vergleichst Äpfel mit Birnen.

Btw.: Bei den Mondlande-Programmen der Amis und Russen ist so manches
wild zusammengeschustert worden, nach Plänen, die höchstens in den
Köpfen von einer Handvoll Genies existierten. Deshalb kann man diese
Trägersysteme heute auch nicht mehr nachbauen, selbst wenn man wollte.

Man braucht Pläne um große Systeme zu erstellen.

Nicht zwingend.

Gerade bei *wirklich* umfangreichen Systemen, die man nicht mehr als
Ganzes überschauen kann und bei denen die Projektleitung gar nicht
weiß, ob sie überhaupt in die richtige Richtung denkt, sind konkrete
Pläne sogar eher schädlich. Denn sie schränken die Kreaktivität der
Spezialisten massiv ein, und verhindern damit zweckmäßige Lösungen.

Wenn die Raketenentwicklung mit dem Ziel begonnen hätte, das
Sonnensystem zu erforschen, hätte vermutlich nie ein Mensch diesen
Planeten verlassen.

Wenn die Elektronik mit dem Ziel begonnen hätte, eine Maschine zu
konstruieren, die sich gleichermaßen als Schreibmaschine, als Archiv,
als Analysewerkzeug, als Kommunikationsmittel, und zur Unterhaltung
eignet und auf einen Schreibtisch paßt, hätten wir wohl heute keine
Computer.

Einfach weil beides aus damaliger Sicht nicht greifbar und damit nicht
planbar war.

bottom-up (also das Entwickeln und Kombinieren von Bausteinen mit
einem nicht oder nur vage formulierten Endziel) ist eine durchaus
anerkannte Entwicklungsphilosophie, die zwar nicht immer exakt zu dem
Ergebnis führt, was man anfangs im Sinn hatte, aber doch meist zu
etwas, das irgendwie nützlich und verkäuflich ist. Oft sogar weit
mehr, als die anfängliche Idee.

SE ist nichts anderes als Pläne zu erstellen wie man ein Produkt
anschließend fertigt. In der Mechanik macht man das seit Jahrhunderten.
Und in der Software soll dieses Vorgehen sinnlos sein?

In dem Umfang, wie es in der Mechanik üblich ist, wäre SE weder
bezahlbar, noch in vertretbarem zeitlichem Rahmen machbar, noch
sinnvoll.

Anders als bei mechanischen Produkten ist es bei Software nicht
erforderlich, der Fertigungsweg jederzeit mit identischem Ergebnis
nachvollziehen zu können.

Und ebenfalls anders als bei mechanischen Produkten steht bei Software
meist nicht ein klar umrissenes Ziel am Beginn der Planungen, sondern
ein Problem, dessen Lösung oft noch gar nicht bekannt ist.

Hergen

 

[Laurent Schmalen]

On Wed, 12 May 2004 20:04:22 +0200, "Bernd Maier"
<gagalus@directbox.com> wrote:

"Laurent Schmalen" <loron@gmx.de> schrieb:


Bei uns an der Uni gibts sogar ein Seminar (oder Praktikum?!) was sich
"Java für eingebettete Systeme" nennt ... *schauder*

Aber bitte sofort den Link her!
Gibts nen Skript davon zum downloaden?

http://www.eecs.rwth-aachen.de/Lehre/Praktika.html

3. Praktikum in der Liste.
Online-Skripte gibts bei diesem lehrstuhl leider keine, ich würd dir
ja eins besorgen, bin aber die nächsten 3 Monate zwecks Praktikum
nicht in Aachen.

--
Laurent

 

[Joerg Wunsch]

Hergen Lehmann <hlehmann.expires.010604@snafu.de> schrieb:

Die weitaus meisten Softwareprojekte haben nur einen winzigen
Bruchteil des Etats und der Entwicklungszeit im Vergleich zu einem
Raumfahrtprojekt.

Dafür funktionieren sie fast durchgehend nach der 90-90-Regel: die
ersten 90 % der projektierten Zeit werden für die ersten 90 % des
Projektes benötigt, während die restlichen 10 % des Projektes die
zweiten 90 % der Zeit brauchen.

--
Jörg Wunsch

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