TriFailSave

    • Offizieller Beitrag

    Ich finde die Platine trotzdem noch sehr kompakt.
    Ist das Programm in Assembler oder in C geschrieben, weil Dir der Speicherplatz ausgegangen ist?

    • Offizieller Beitrag
    Zitat

    Ich finde die Platine trotzdem noch sehr kompakt.


    Ähm.. das mit dem war auch nicht ernst gemeint, sollte ne scherzhafte Anspeilung auf deinen 150gr-12V-24V Wandler sein.

    Zitat

    Ist das Programm in Assembler oder in C geschrieben, weil Dir der Speicherplatz ausgegangen ist?


    Weder noch. In Pascal natürlich.

    • Offizieller Beitrag
    Zitat

    sollte ne scherzhafte Anspeilung auf deinen 150gr-12V-24V Wandler sein.


    hehe... k, ist jetzt angekommen :jeah: . Naja, robuste Technik hat halt manchmal seinen (Gewichts-)preis.

    Zitat

    In Pascal natürlich.


    Oha... für die Atmel-Freaks gibts Pascal-Compiler? Bin beeindruckt. Ich weis, dass es für die 8051-Derivate mal eine sauteuren Pascal-Compiler gegeben hat, aber nachdem die ganze Welt auf C umgeswitched ist, ist der Pascaler dann irgendwann von der Bildfläche verschwunden.
    Haste schon mal verglichen, wie gut der Compiler da im Vergleich zum Assembler "Mehr-Code" vermeidet? => Würde mich nur so am Rande interessieren, weil meine Kollegen für den TI (MSP430-Serie) auch ewig herumgedoktert haben, um eine "gute" Einstellung zu finden, damit der Compiler nicht zu viel zusätzlichen (umständlichen) Code produziert. => Darum mal die persönliche Neugierde, ob das der Pascaler besser kann.

    • Offizieller Beitrag

    Ich glaub nicht, dass der Pascal-Compiler (http://www.e-lab.de ) viel mehr Code produziert als C. Habs aber nicht verglichen. Ich mag einfach kein C, in Pascal ist der Quellcode einfach schöner lesbar.
    Ich hab auch nur die kostenlose Version, in der Profi-Version gibts noch einen Optimizer, der nochmal 20-30% bringen soll.
    Wer heutzutage noch in Assember programmiert, versteh ich nicht. Wenn die Rechenleistung nicht reicht, nimmt man eben für 4,5 cent/St. mehr nen größeren µC. Und bei Controllern mit Pipeline kommt bei Assembler eher was schlechteres raus, als mit nem guten Compiler.
    Für PICs ist dieser Pascal-Compiler übrigens komplet frei, kannst es ja mal ausprobieren.

    • Offizieller Beitrag

    Wow, danke für den Tipp und Link. Sieht im ersten Augenblick ganz gut aus. (Laut der dortigen Info muss es sich noch um ein älteres Exemplar handeln, denn der Verkaufspreis der Vollversion ist noch in DM angegeben). Einen Versuch wird's mal wert sein. Im Vergleich zu dem von mir aktuell benutzten C-Compiler von HT-Soft, sind offensichtlich keine bitspezifischen bzw. registerspezifischen Bibliothekswörter vorhanden. Macht zwar auch nichts, weil ich mir die, wie in guten alten Assemblerzeiten dann selbst definiere. Die Frage ist nur, ob der Pascaler dann auch die neueren Prozessoren handeln kann. Wie gesagt, einen Tests wirds geben, weil ich doch meine Wurzeln (... früher: Modula2...) nicht ganz ablegen möchte.

    Zitat

    Ich mag einfach kein C, in Pascal ist der Quellcode einfach schöner lesbar.


    Man kann C so schreiben, dass es nur noch der Entwickler selbst versteht. Aber wenn man üblicherweise mit Modula2 oder VisualBasic herumkratzt und diesen Stil dann bei C verwendet, sieht ein C-Programm fast wie ein Pascal-Programm aus. Die geschweiften Klammern stören dann noch, aber ansonsten... Man muss halt etwas Disziplin an den Tag legen und "wollen". Obwohl es schon eine gewisse Überwindung kostet, bei einer Compare-Funktion zwei Istgleichzeichen hintereinander zu schreiben. *würg*
    Schlimm ist: Wenn man in einem Industrielabor arbeitet, muss man mit den Wölfen heulen... und da wird halt in C geheult.

    Zitat

    Ich glaub nicht, dass der Pascal-Compiler (http://www.e-lab.de ) viel mehr Code produziert als C.


    Ich denke das auch nicht. Die Frage zielte mehr darauf ab, wie groß die Unterschiede zwischen dem hier generiertem Assemblercode und einem vom User selbst erstelltem Assemblerprogramm ist. Du hast schon 20-30% erwähnt. Schlimm ist, wenn bei Projektende ein paar Bytes Programmspeicher fehlen und der Prozessor auf der Platine eingelötet ist etc.... Macht immer Unmut. Also lieber ein paar Bytes wieder schinden.

    Zitat

    nimmt man eben für 4,5 cent/St. mehr nen größeren µC.


    Da versuchen wir unsere Kaufleute auch immer davon zu überzeugen. Bevor ein Entwickler sich wochenlang verkrampft, um den Code in einen kleinen Prozessor zu quetschen, sollte man eine größere Version nehmen. Da solltest Du die Leute mit den roten Stiften hören..... Ein Entwickler läuft ja unter "Sodakosten" (er ist ja "so da" ). Hauptsache in der Serie ein paar Cent an Bauteilkosten gespart, auch wenn im Monat nur ein paar Geräte verkauft werden. ;(

    • Offizieller Beitrag
    Zitat

    Zitat:Ich mag einfach kein C, in Pascal ist der Quellcode einfach schöner lesbar.


    Man kann C so schreiben, dass es nur noch der Entwickler selbst versteht. Aber wenn man üblicherweise mit Modula2 oder VisualBasic herumkratzt und diesen Stil dann bei C verwendet, sieht ein C-Programm fast wie ein Pascal-Programm aus. Die geschweiften Klammern stören dann noch, aber ansonsten... Man muss halt etwas Disziplin an den Tag legen und "wollen". Obwohl es schon eine gewisse Überwindung kostet, bei einer Compare-Funktion zwei Istgleichzeichen hintereinander zu schreiben. *würg*
    Schlimm ist: Wenn man in einem Industrielabor arbeitet, muss man mit den Wölfen heulen... und da wird halt in C geheult.

    Disziplin und Flexibilität sind die Schlüsselwörter, dann läßt sich in jeder Hochsprache anständig programmieren, ausser in Java, das ist nämlich von sich aus unanständig...

    Und ja, im der harten Realität wird nur in C programmiert. Aber das Schlimmste ist der Vormarsch von Java im uC Bereich... :nönö:

    Zitat

    Schlimm ist, wenn bei Projektende ein paar Bytes Programmspeicher fehlen und der Prozessor auf der Platine eingelötet ist etc....

    Genau deswegen lötet mein einen Prozessor nicht ein...

    Zitat

    Zitat:Ich glaub nicht, dass der Pascal-Compiler (http://www.e-lab.de ) viel mehr Code produziert als C.


    Ich denke das auch nicht. Die Frage zielte mehr darauf ab, wie groß die Unterschiede zwischen dem hier generiertem Assemblercode und einem vom User selbst erstelltem Assemblerprogramm ist. Du hast schon 20-30% erwähnt. Schlimm ist, wenn bei Projektende ein paar Bytes Programmspeicher fehlen und der Prozessor auf der Platine eingelötet ist etc.... Macht immer Unmut. Also lieber ein paar Bytes wieder schinden.

    Das können wir ja gerne mal vergleichen. Ich programmiere gezwungenermaßen alles in C...

    • Offizieller Beitrag

    So, die Software für die neuste Version ist fertig und funktioniert ganz prima. Die Erkennung der schlechten Funkverbindun geht sehr zuverlässig, wenn ich die Antenne aus meiner Funke ganz rausschraube (also nicht eingefahren, sondern ganz weg), dass lößt der Failsave [U]immer[U] zwischen 50-60cm Entfernung aus, und geht erst wieder an wenn ich nächer als 30 komme. Das mach die Hysterese.
    Der Fehler zwischen der Failsaveposition und der Programmierten (das war ja das Problem bei der ersten Version ) ist jetzt viel kleiner als des Empfängerrauschen selbst, und damit vernachlässigbar.
    Ich hab übrigens tatsächlich den großen Atmel bis aufs Limit ausgereizt. Der digitale Filter zur Signalmittelung musste ziemlich komplex werden, damits so funktioniert.

    Werde am Wochenende mal eine Kurzanleitung dazu schreiben.

    • Offizieller Beitrag

    Die platzersparniss ist ganz erheblich, weil die Sockel ja auch die ganze andere Seite unter dem IC blockieren würden. Und da ha ich jetzt schön Schutzdoden und RC-Filter platzieren können. Außerdem geht der IC nicht kaputt, und wenn doch, geht auslöten mit nem Heißluftfön ganz gut (sonst ist da ja nicht mehr viel auf dem Platinchen).

    • Offizieller Beitrag
    Zitat

    Außerdem geht der IC nicht kaputt,

    Fremdeinwirkung, Spannungsspitzen, die tiny2313 Odysee... Alles schon da gewesen...

    Zitat

    geht auslöten mit nem Heißluftfön ganz gut (sonst ist da ja nicht mehr viel auf dem Platinchen).

    Heißluftfön der Marke Baumarkt ist wohl eher nicht angebracht da bei der kleinen Platinenfläche alle Bauteile ausgelötet werden...

    • Offizieller Beitrag

    / Unwichtigkeitsmodus: Ein
    Kurze Anmerkung bezüglich der Pinbelegung, nachdem ich gerade die Anleitung grob gelesen habe:
    Bei meiner Lieferung von WES letzte Woche war ein roter Beipackzettel drin, dass man auf die Pinbelegung der Servos und der Spannungsversorgung aufpassen soll, weil das bei den Empfängern mittlerweile fast jeder Hersteller anders macht. Stimmt. Die WES-Belegung hat im Vergleich zum Robbe genau +5V und Masse vertauscht.
    Auch in diesem Fall möchte ich noch mal auf die Pinbelegungen hinweisen, bei denen die Anschlusskabel u.U. umgelötet werden müssen.
    /Unwichtigkeitsmodus: Aus

    Beeindruckt hat mich in der Schaltung bzw. Programmierung, dass man das Fail-Save-Signal selbst definieren kann. Also nicht nur alles "aus".

    • Offizieller Beitrag

    Hab die Anleitung schon mal durchgestöbert und ein paar Fragen dazu:

    Die Failsafe-Positionen werden für alle Kanäle gleichzeitig eingestellt ,richtig?

    Ich kann damit 4 Eingangskanäle überwachen auch wenn ich z.B. nur einen Ausgang benutze, richtig?

    könnte ich irgendwie, z.B. mit einem Schalter an der FB die FS-Stellung auslösen ? hat mir bei dem MS-Failsafe immer ein sicheres Gefühl gegeben zu wissen daß beim Aufdrehen der Flasche der Schalter für das Magnetventil in einer sicheren Stellung ist.
    Ich befürchte aber das würde einen mächtigen Programmieraufwand erfordern, oder?

    Gruß Dirk