[Rumgucker]

Zitat:Original geschrieben von voltwide
Wir reden doch vom Hobby, nicht von der Arbeit. Da kann man sich die Kriegsschauplätze aussuchen.

Ne. Wenn ich was erreichen will ist es doch gleich, ob im kommerziellen oder privaten Bereich. Jedes Projekt hat doch immer unvorhergesehene Probleme und Engpässe, Die eigentliche Projekterstellung macht von der Gesamtarbeit stets nur einen kleinen Teil aus.

Egal, ob ich Fliesen im Badezimmer verlege oder feinste Software mach.

Aus dieser Unberechenbarkeit macht man mittlerweile sogar ne richtige Kultur. Stichwort "agile Softwareentwicklung" Mit einem darauf eingeschworenen Team kann man Welten bewegen.

[voltwide]

Zitat:Original geschrieben von Rumgucker

Zitat:Original geschrieben von voltwide
Wir reden doch vom Hobby, nicht von der Arbeit. Da kann man sich die Kriegsschauplätze aussuchen.

Ne. Wenn ich was erreichen will ist es doch gleich, ob im kommerziellen oder privaten Bereich. Jedes Projekt hat doch immer unvorhergesehene Probleme und Engpässe, Die eigentliche Projekterstellung macht von der Gesamtarbeit stets nur einen kleinen Teil aus.

Egal, ob ich Fliesen im Badezimmer verlege oder feinste Software mach.

Aus dieser Unberechenbarkeit macht man mittlerweile sogar ne richtige Kultur. Stichwort "agile Softwareentwicklung" Mit einem darauf eingeschworenen Team kann man Welten bewegen.

ich gebe Dir da teilweise recht. Es liegt aber auch an einem selbst, wie tief man in die unliebsamen Nebenschauplätze einsteigt.

[Rumgucker]

Ich sprach nicht von "unliebsamen" Nebenkriegsschauplätzen. Ganz oft stellt sich ja heraus, dass gerade dort die größten Innovationen entstehen. Man muss sich auf ein Projekt mit all seinen Facetten einlassen. Dazu gehört ggfls. auch das Lernen von Eclipse.

[voltwide]

Zitat:Original geschrieben von Rumgucker

Ich sprach nicht von "unliebsamen" Nebenkriegsschauplätzen. Ganz oft stellt sich ja heraus, dass gerade dort die größten Innovationen entstehen. Man muss sich auf ein Projekt mit all seinen Facetten einlassen. Dazu gehört ggfls. auch das Lernen von Eclipse.

Das ist Deine Meinung. Für mich ist Eclipse ein Werkzeug, und damit nur ein Nebenschauplatz. Und ich bevorzuge nun mal griffige Werkzeuge, die ich nicht erst entgraten und zurechtfeilen muss

[Black_Chicken]

Zitat:Original geschrieben von voltwide

Zitat:Original geschrieben von Rumgucker

Ich kämpf IMMER auf Nebenkriegsschauplätzen.. egal in welchem Projekt.

Wir reden doch vom Hobby, nicht von der Arbeit. Da kann man sich die Kriegsschauplätze aussuchen.

Hallo Voltwide,

genau so sehe ich das auch!

Ich verfolge dein Thema übrigens mit großem interesse, leider kann ich wenig konstruktives dazu beitragen.

Cheers!

[voltwide]

So, die AVR-Firmware läuft erstmal, alle Baustellen sind abgebaut.
Es läuft der Tote-Mann-Modus, d.h. Abschalten im Batteriebetrieb nach längerer Tonpause.
Und der Attiny übernimmt auch die Batterieladung in Form einer hysteretischen Zweipunktregelung.
Mit Code::Blocks komme ich gut klar, einige Schwächen des Editors sind durchaus zu verschmerzen.
Als nächstes muss ich mir mal wieder die Layouts vorknöpfen.

[voltwide]

Hier der aktuelle Quelltext
https://stromrichter.org/d-amp/content/i...20120219.c
sind immer noch irgendwelche tabulatoren drin

[Rumgucker]

Du machst ja jetzt doch keinen WDT-Reset. Aber es sieht klasse aus. Bestens kommentiert und strukturiert. Richtig mit Liebe gemacht. Vollstes Lob

[voltwide]

Zitat:Original geschrieben von Rumgucker

Du machst ja jetzt doch keinen WDT-Reset. Aber es sieht klasse aus. Bestens kommentiert und strukturiert. Richtig mit Liebe gemacht. Vollstes Lob

Den Reset wollte ich auch nicht haben.
Ansonsten bedankt sich Seine Induktivität artig für das gespendete Lob

[Rumgucker]

Dein Programm macht so richtig schön deutlich, dass man diese lütten Dinger eigentlich gar nicht richtig programmiert, sondern letztlich überwiegend und in Schritten konfiguriert.

[voltwide]

Zitat:Original geschrieben von Rumgucker

Dein Programm macht so richtig schön deutlich, dass man diese lütten Dinger eigentlich gar nicht richtig programmiert, sondern letztlich überwiegend und in Schritten konfiguriert.

Ja, im wesentlichen Bitknipserei. Irgendwie noch recht verwandt mit Assemblerprogrammierung (wo ich auch meine Wurzeln habe).

[Rumgucker]

Bitknipserei entsteht wesentlich durch die vielfältigen Hardware-Features dieser Controllerchen.

Früher hätte man keine Watchdog gehabt und sich stattdessen mit irgendeiner Rödelloop rund um CPU-Takt-basierte Verzögerungen geholfen. Das hätte dann schon mehr nach "Programm" ausgesehen.

Heutzutage hat die Controller-CPU eigentlich nur noch Verwaltungsfunktionen. Hier mal nen AD-Wandler anschubsen, dort mal ein paar Bits umknipsen, da ein Byte in den UART-Fifo reinpatchen.

Schöne neue Welt....

------

Idee:

Alle Konfigurationsbits liegen ja eh schon ziemlich gebündelt im Adressraum, also praktisch so eine Art "Profil".

Ich könnte mir vorstellen, dass bei zukünftigen Controllern die gesamte interne Hardware mit einem Pointer auf dieses Profil zugreift.

Wenn ich diesen Pointer verbiegen könnte, so könnte ich mit einem Schlag die ganze Hardware umkonfigurieren.

Vorab würde ich dann nen Sack unterschiedlicher Profile im Speicher bevorraten und dann einfach nur hin- und herschalten, wenn ich zum Beispiel gerade in eine ISR eintrete.

Dann wären wir keine simplen Bitknipser mehr sondern "kontextsensitive Profil-Switcher"

Hört sich zumindest besser an.

[voltwide]

Gestern habe ich Papierkorb/2 an Flussdiagrammen gemalt, nämlich die Bedingungen wann nun der Amp tatsächlich eingeschaltet wird und wann die LED leuchtet. Die Prozeduren AmpOnOff und LedOnOff sind danach komplett überarbeitet. Bis eben habe ich noch debugged und ausgetestet, nun scheint tatsächlich alles wie gewünscht zu laufen. Sieht also gut aus!
https://stromrichter.org/d-amp/content/i...20120222.c

[e83cc]

Ähm Flussdiagramme, ist das nicht was für die Goto-Basic-Programmierer Ok, für ganz einfache Sachen taugt das auch, aber sowie es komplexer wird, wird schnell schwierig und unübersichtlich.

Struktogramme halte ich für besser geeignet. Es gab da mal ein Tool EasyCase, damit konnte man sowohl von Struktogramm den C-Code erstellen als auch umgekehrt.

[Rumgucker]

Flussdiagramme sind was für Könner

[e83cc]

Heißt jetzt EasyCode http://www.easycode.de/en/download.html

[Rumgucker]

Voltis Programm braucht sowas nicht. Das IST so sauber strukturiert, dass man keine weiteren Hilfen braucht. (die aktuelle Version hab ich mir allerdings noch nicht angeschaut).

[voltwide]

Zitat:Original geschrieben von e83cc

Ähm Flussdiagramme, ist das nicht was für die Goto-Basic-Programmierer Ok, für ganz einfache Sachen taugt das auch, aber sowie es komplexer wird, wird schnell schwierig und unübersichtlich.

Struktogramme halte ich für besser geeignet. Es gab da mal ein Tool EasyCase, damit konnte man sowohl von Struktogramm den C-Code erstellen als auch umgekehrt.

Flußdiagramme sind geeignet um Abläufe mit bedingten Verzweigungen darzustellen. Ob man dass nun mit Struktogrammen, Mind maps oder sonstwie macht, ist eigentlich ziemlich egal. Ob das Kind nun Goto, branch oder call heißt, ist in dieser Instanz auch nur eine formale Frage.

Und im übrigen ist diese Aufgabe nicht wirklich komplex, das Wesentliche ist auf zwei A4-Blättern mühelos darstellbar.
Aber auch da kann man sich schnell schon mal vertüddeln.

[Rumgucker]

Volti... jetzt hab ich aber doch ne kleine Kritik....

Du fragst Deine 8-Bit-langen Flags zum Beispiel mit "if (WDTirq==1) " ab. Das führt dazu, dass der Wert ganz genau stimmen muss, wozu der Speicher ganz genau mit einer Konstanten verglichen wird.

Viele Compiler machen aber wesentlich besseren Code, wenn Du schreibst "if (WDTirq) ". Dabei wird meist nur das Register mit sich selbst oderiert, um die Flags zu setzen, was ein Byte Programmspeicher spart und ggfls. auch CPU.-Zyklen halbiert.

[voltwide]

Zitat:Original geschrieben von Rumgucker

Volti... jetzt hab ich aber doch ne kleine Kritik....

Du fragst Deine 8-Bit-langen Flags zum Beispiel mit "if (WDTirq==1) " ab. Das führt dazu, dass der Wert ganz genau stimmen muss, wozu der Speicher ganz genau mit einer Konstanten verglichen wird.

Viele Compiler machen aber wesentlich besseren Code, wenn Du schreibst "if (WDTirq) ". Dabei wird meist nur das Register mit sich selbst oderiert, um die Flags zu setzen, was ein Byte Programmspeicher spart und ggfls. auch CPU.-Zyklen halbiert.

Hastu Recht, werde ich ändern. Ich habe nichts gegen Kritik, auch wenns größere ist.

man könnte vielleicht auch diese flags in ein bit-Feld packen, das ist dann schon der Feinschliff.
Erstmal bin ich froh, dass das Ganze soweit läuft.