Eagle 7.1 Autorouter: Taugt er?

Am 06.11.2014 um 00:54 schrieb Hanno Foest:

Beim Task-Wechsel im Original-Unix V6 (c)Bell:

"You are not expected to understand this."

Oder im Betriebsystem der VAX-11 , wenn der allererste Prozess, Vater/Mutter von allem, versehentlich stirbt:

Am 06.11.2014 11:19, schrieb Gerhard Hoffmann:

Intel Lizenznehmers stand:

"Die Gefahr geht weniger von superintelligenten Maschinen, sondern eher von subintelligenten Menschen aus."

Joerg schrieb:

Dauert bei vielen Modellen vielleicht eine Stunde.

Dann hatten die Typen wohl ausgelutschte Akkus, und dann auch noch die kleine Variante.

Guido

Gerhard Hoffmann :

(via )

Das von mir genannte Beispiel? In einer respektablen Firma sind die bereits beim Design Review nicht mehr drin. In einer sehr respektablen kommen solche Kommentare gar nicht erst rein. Weil dann naemlich schonmal ein hoeherrangiger Mitarbeiter reinschaut und dessen Naseruempfen im Wiederholungsfall der Karriere nicht sehr foerderlich ist.

Gegen anstaendige Kommentare in Source Code ist nichts einzuwenden, das braucht man zum Verstaendnis. Aber keine Hackersprueche. Ausserdem ersetzen Kommentare nicht die Doku.

Das ist meist wirklich nicht mehr sinnvoll, denn bis das bei einem Compaq passierte, war auch noch alles moegliche andere runtergeritten. Das Dingen war einfach fertig. Ist ok, hat viele Jahre Dienst getan. So wie der Samsung jetzt schon sechs Jahre.

Noe, alles recht neu. Wenn der Besitzer sagt "I never really get more out of it", dann glaube ich dem das.

Am 06.11.2014 16:26 schrieb Joerg:

Derart schlampig wird in "respektablen" Firmen gearbeitet? Kommentare

Nee, sowas kommt mir nicht ins Haus.

Hanno

Du weisst wie das gemeint was. Das weggeschnippelte Beispiel. Wenn ich als Chef sowas in Code finden wuerde, gaebe es aktuellen Gespraechsbedarf.

Am 06.11.2014 16:46 schrieb Joerg:

aber dein Versuch der Kompetenzsimulation auf dem Gebiet der IT wirkt

greifbar ist. Man *kann* dann refactoren. Sollte man vielleicht auch.

Die Abwesenheit derlei Kommentare ist daher kein gutes Zeichen, sondern eher ein Symptom zu sparsamer Kommentierung - oder gar der "kosmetischen" Entfernung von Kommentaren, um Leuten wie dir zu

Der Linux-Kernel beispielsweise hat eine vergleichsweise sehr gute

kracht. Und das sicher nicht, weil alles so toll ist. Insofern sind ehrliche Kommentare sicherlich kein Symptom schlechter Programmierung.

Hanno

Was Doku auch bei Software angeht, habe ich jahrzehntelange Erfahrung in Med Tech. Dann noch einige Jahre Aerospace. Wer jemals intensiv mit FDA, FAA und aehnlichen Behoerden zu tun hatte, weiss, dass ein Beharren auf sauberem Still alles andere als laecherlich ist. Ich suche mir meine SW Contractors u.a. nach Doku-Qualitaet aus. Mit einem habe ich die Zusammenarbeit deshalb abgebrochen. Bei einem derzeitigen Projekt, wo viel SW drin, ist habe ich in dieser Hinsicht keinerlei Bedenken.

Ueberlege mal, was passiert, wenn z.B. der Steuerpruefer eine Routinekontrolle bei einer Firma macht und dann Kommentare findet wie "Ich weiss nicht so ganz warum, aber nur wenn man das so rechnet, deckt sich das mit dem Balance Sheet, also besser so belassen".

Nicht in meinem Metier.

Alte und immer noch geltende Weisheit des Abteilungsleiters bei meinem ersten AG: "If you didn't document it, it didn't happen". Der mochte schloddrige Doku genausowenig wie ich. U.a. weil er wusste, was dann bei der Zulassungspruefung passieren kann.

Zielfuehrend ist es, bei solchen Effekten wie "I don't know why it only works this way" zu bohren, warum das so ist. Einen Code, bei dem der Autor nicht sicher genug ist, moechte ich nicht in einem Flugzeug oder mission-critical Medizingeraet sehen.

Ja, klar, "aber irgendwie funzt es". Oder so.

Am 06.11.2014 17:33 schrieb Joerg:

gemerkt hast, aber inzwischen nehmen dir die Leute, die sich

nicht mehr ab. Woher das wohl kommen mag?

Und deswegen steht das ja auch da - damit jemand auf diese Stelle

aussieht. Kennt wohl jeder, der schon mal mit Zertifizierungsprozessen zu tun hatte.

Projekten. Entsprechend findet man den Kram inzwischen auch in

Da nimmst du lieber das gute Windows mit den geschniegelten Kommentaren,

Hanno

Am Thu, 06 Nov 2014 07:31:22 -0800 schrieb Joerg:

Woher weiss die 'beinharte Landung', dass es nun an der Zeit ist aufzutreten? Oder hat der Laptop die reihenweise erlebt und die war also gar

Lutz

Meine Kunden tun das und fahren gut damit. Seltsamerweise bekomme ich regelmaessig Anfragen u.a. von Mitlesern dieser NG, die wissen wollen, wie man fuer eine saubere Design History sorgt.

In Code, der dann trotzdem auf die Welt losgelassen wurde. Ganz toll.

Hast Du das auch gelesen?

Zitat "Medical devices and their components must undergo a hazard analysis". Nun verrate uns mal, wie man die macht, wenn im Code Stellen sind, wo der Autor nicht so recht weiss, wann es instabil wird.

Dann Zitat "Not only must the OTS software be designed according to good principles, ...". Die FDA hat recht klare Vorstellungen, was das bedeutet. Soweit ich bis jetzt den Eindruck habe, decken die sich nicht mit Deinen Vorstellungen.

Wie ich bereits mehrfach schrieb, haben wir Windows gruendlich nachgebessert, bevor das z.B. in ein Diagnosegeraet kam, auf welches sich Kardiologen verlassen koennen muessen. In Faellen wo ich die Entscheidung traf, gab es kein Windows, sondern entweder gar kein OS oder gusseisern robustes wie QNX.

Huh? Das war reiner Zufall, so wie die meisten Verkehrserlebnisse. Ab einem gewissen Abnutzungsgrad und Alter lohnt eine Reparatur nicht.

Der hat mehr erlebt. Z.B. Gelaendefahrten der haerteren Sorte und auf meine Tasche (mit dem Laptop drin) draufknallende andere Gepaeckstuecke. Manche meiner Laptops sind nach einigen Jahren auch gebrauchsmaessig soweit abgenudelt, dass man sie fast abschreiben kann. Kuhle im Touchpad, muede werdende Leertaste, wackelnde E-Taste, und so weiter.

Ja, kenne ich, selbst schon produziert, nur habe ich eine gute Entschuldigung. :)

; Schleife, die das ROM komplett ins RAM kopiert und dann das ROM ; nach $00C00000 ummapped.

move.l #$000027Fe, d1 ; Laufvariable fuer $5000 Bytes move.l #$00000000, a0 ; 0 Ins Adressregister copy_mem: move.w (a0), (a0)+ ; Speicher kopieren dbra d1, copy_mem ; d1 runterzaehlen.

; ************** ACHTUNG ************* ; Die Reihenfolge der folgenden 2 Befehle ist wichtig, eine ; Aenderung fuehrt zur Nichtfunktion des Programmes!

move.w #%0011100000110000, CSOR1 ; RAM lesbar machen move.w #%0101100000110000, CSOR0 ; RAM lesbar machen

move.w #%1100000000000100, CSBARBT ; ROM nach $c0 mappen

(Ist ein MC683xx-basierter Microcontroller)

Vertauscht man die Zugriffe auf CSOR1 und CSOR0 schmiert das Programm ab weil es sich selbst den Speicherzugriff entzieht. Im Datenbuch stand dazu nichts sondern nur was die Bits tun, obige Reihenfolge wurde auf die harte Tour rausgefunden.

Der gesamte Code kopiert das 8Bit breite ROM ins 16Bit breite RAM und

on-the-fly von ROM nach RAM umgeschaltet.

Gerrit

Stimmt, und Du hast ja auch den Grund rausgefunden. So wie das sein soll.

Was hat denn der Hersteller dazu gesagt?

Wenn ich dabei mitreden darf, setze ich gern abgehangenere Prozessoren in kritische Designs. Da sind die Kinderkrankheiten meist durch.

Wobei ich mal ein Problem mit einem 89C51 hatte, der die im Datenblatt zugesagten 16MHz Clock nicht schaffte. Mit 15MHz ging es. Erst als der Hersteller schriftlich zusagte, dass 12MHz sicher sind, nahm ich den Chip. Sonst waere er rausgeflogen.

Es ist auch schon vorgekommen, dass sich Hersteller rausgewinselt oder eiskalt abgestritten haben. Die landeten auf der schwarzen Liste.

Hanno Foest schrieb:

hen.

das seltsame Verhalten analysieren und beseitigen wollen.

zu finden, nur mit extremem Aufwand. Und nur, wenn man die Quelltexte

Marc

So wie damals beim WD33C93B (SCSI-HBA-Chip). Dort steht im Datenblatt,

ganze Statemachine des Chips steht (u.U. den Bus blockiert)! Explizit steht letzteres aber nicht im Datenblatt, das lernt man wieder auf die harte Tour. Nachdem man es gelernt hat erscheint es dann logisch.

Die waren aber zu langsam (*) und/oder hatten zuwenig Speicher. Es hatte schon seinen Grund warum wir diese Controller benutzt haben, der am Anfang zum Testen verwendete 68HC11 erwiess sich als einfach zu limitiert.

(*) hochgetaktete 8051-Derivate gab es damals noch nicht.

Gerrit

"Mappen" hoert sich so an, dass Dein Studium noch nicht so lange her ist. Uns haetten sie bei Denglisch damals die Ohren langgezogen :-)

Heute ist es anders. Sitze gerade "gestrandet" auf einem Flughafen und bei den ganze Ansagen habe ich den Eindruck, dass kaum noch einer richtig die Landessprache spricht. "Mistah Djonns, pliss come to da geeht ajent".

Ist bei einer Studienarbeit auch nicht so wild. Das wird ja nachher nicht 1:1 in ein Medizingeraet oder aehnliches portiert.

Das passiert auch aelteren Semestern, wie mir letztes Jahr. Moderner Schaltregler Chip, da geht man natuerlich locker flockig davon aus, dass der Leading Edge Blanking hat. So wie Autos heutzutage immer Airbags haben. Hatte er aber nicht ...

Das Problem habe ich akut auch. Es wird daher mein erstes ARM-Design, mit dem neuen ADSP-CM408F. Wish me luck. Die Software macht natuerlich jemand anders, das kann ich nicht gut. Aber ich muss sicher sein, dass der Prozessor auch alle anfallenden Jobs mit genuegend Reserven packt.

Die kommen mir heute noch vor wie die spitz gemachte Kreidler Florett eines Bekannten aus den 70ern. Auf einem Pruefstand brachte die gemessene 12.5PS aufs Parket, aus 50ccm.