Hallo zusammen, ich möchte an einem konkreten Assemblerprojekt lernen, wie man so etwas grundsätzlich angeht. Dazu möchte ich mein Projekt hier im Forum detailiert beschreiben und mit Euch zusammen erarbeiten wie man so etwas umsetzt. Später soll dann aus dem ganzen das Wichtigste extrahiert werden und so etwas wie eine Anleitung unter dem Motto : " Von der Idee zum fertigen Assemblerprojekt " entstehen. Ich stecke mitten in meinem Projekt fest und erkenne nun, das es irgendwie schlecht strukturiert bzw. programmiert ist. Um den ADC im Noise Reduction Mode zu versetzen muß man ihn mittels SLEEP in den Schalfmodus versetzten, dadurch kam aber irgendwie mein Blinktakt für die weiße LED durcheinander. Eine dreipin DUO-LED sollte jeweils in den drei Farben Rot, Gelb und Grün jeweils Dauerlicht sowie zwei bis drei Blinkmodi aufweisen können, der Algorithmus ist jedoch relativ kompliziert und läuft eingentlich in einer Timer ISR ab und versagt nun völlig. Auch die Tastenentprellung arbeitet unzuverlässig. Es soll ganz grob geschrieben ein Tiefentladeschutz für 12V oder 6V Bleiakkus werden, der per Tastendruck die Last einschaltet und dabei mittels einer dreipin DUO-LED den ungefähren Ladezustand des Akkus anzeigt ( 25%, 50%, 75%, 100% ). Eine aufblitzende weiße LED soll als Betriebsanzeige dienen, ausserdem soll beim Erreichen der Entladeschlußspannung ein intervallmäßiges Piepen erzeugt werden das nur bei Helligkeit aktiv wird. Ansonsten durch blinken oder blitzen der DUO-LED in Rot. Wer könnte sich von Euch vorstellen hierbei Hilfestellung zu leisten ? Dies sollte natürlich gut überlegt sein, da es sich bestimmt über einige Wochen, wenn nicht sogar Monate hinziehen wird. Ich möchte dann nicht wieder feststecken bzw. im Stich gelassen werden und somit wieder da stehen wo ich jetzt bin. Außerdem erhoffen sich bestimmt auch andere etwas davon, die auch gern wissen möchten wie man seine Ideen wohl durchdacht in Assembler umsetzt. Bernd_Stein
1. Poste Deinen Code 2. Poste Deine Schaltung Dein Vorhaben ist nicht sonderlich komplex. Ein Tiny2313 kann diese Aufgabe lösen. Dafür brauchst Du nicht einmal die Hälfte der Ressourcen des Controllers. Bernd Stein schrieb: > Es soll ganz grob geschrieben ein Tiefentladeschutz für 12V oder 6V > Bleiakkus werden, Bei all der LED-Blinkerei fehlt das Wichtigste: Das Abschaltelement.
Gast
#2523075
Ich denke das dein Projekt so ein bisschen klein und zu wenig durchdacht ist, um so große Begeisterung hervor zu rufen. Mit drei farbigen LED kannst Du fast genau 0 Aussage über den Zusatnd eines (Blei)Akkus machen ohne Temperatur, alter und Vorgeschichte hast Du auch keine brauchbaren Daten vom Akku. Ohne Lade und Entladeströme zu messen, zu rechnen etc. wird das keine auch nur in Ansätzen brauchbare Geschichte. Wieso soll sich jetzt damit jemand die Mühe machen dir das Strukturierte Vorgehen eines Projektes beizubringen, wenn schon die Eingangsbedingungen nicht stimmen? mfG Michael
Gast
#2523077
Zuerst (egal ob in Assembler (den ich durchaus bevorzuge) oder in C würde ich mir die Aufgabenstellung als Flußdigramm aufmalen. (Ich weiß daß jetzt wieder ein paar aufjaulen wg. veralteter Arbeitsweise, ist mir aber total gleichgültig) Statt Ablaufdiagramm geht es auch mit einem Statusdiagramm (Unter welchen Bedingungen wird welcher Zustand eingenommen) Erst mal einen Groben Ablauf, dann in Detail gehen. Und diese Schritte werden dann als "Dienstvorschrift" in eine für den µC verständliche Sprache gebracht. Ob nun über den Zwischenschritt C oder gleich in Assembler, für das von Die geschilderte Projekt nicht sooooo wichtig. Versuch mal mit wenigen Worten den Ablauf zu Beschreiben, wenn Du nich so ein Flußdiagramm malen möchtest. Ein schönes Wochenende!
Gast
#2523109
Hi >Dein Vorhaben ist nicht sonderlich komplex. Ein Tiny2313 kann diese >Aufgabe lösen. Dafür brauchst Du nicht einmal die Hälfte der Ressourcen >des Controllers. Bernd wahrscheinlich schon: Beitrag "ATtiny26 Balkenanzeige ( Hysterese ) mit acht Schaltschwellen (ASM)" MfG Spess
Gast
#2523225
Da bist du schon auf dem richtigen Weg. Programmcode beiseite legen und das Problem nochmal von vorne neu überdenken - damit bist du schon weiter als die Hälfte dieses Forums. Es gibt kein Kochrezept "Von der Idee zum fertigen Assemblerprojekt". Da musst du Jahre an Erfahrungen sammeln. Abschätzen ob du dich in eine Sackgasse verrannt hast oder ob sich die Detailprobleme lösen lassen. Du kannst zwar zu jedem Detailproblem das Forum fragen. "Brauche ich da wirklich den Sleep-Modus?" "Gibt es Timer, die im Sleep-Modus weiterlaufen?" Nicht aber "Wie packe ich die Sache an?" Es gibt auch Tipps zu "Denkhilfen". Manche davon passen zu deinem Stiel. Andere sind an sich gut - nur bei deiner Vorgehensweise sind sie eher hinderlich. Musst selbst ausprobieren, welche du übernehmen willst. Und falls du wirklich ein idiotensicheres Kochrezept zur Softwareentwicklung schreiben kannst, suche ich mir einen anderen Job :-)
Gast
#2523526
Bernd Stein schrieb: > ich möchte an einem konkreten Assemblerprojekt lernen, wie man so etwas > grundsätzlich angeht. Ach ja, nachdem ein übereifriger Atmel-Fan dir seinen Lieblingscontroller angeboten hat, ohne auch nur zur Kenntnis zu nehmen, daß du ja überhaupt keine Präferenz dazu genannt hast, versuche ich mal, dir meine Herangehensweise zu beschreiben: 1. Die ganz speziellen controllerabhängigen Deklarationen schreibe ich in eine separate Quelldatei, die ich dann per "include" in mein eigentliches Projekt einfüge. Meist gibt es sowas je nach Tool-Situation schon fertig, aber selbermachen ist auch nicht schlimm. 2. An den Anfang der Quelle schreibe ich mir erstmal einen umfänglichen Kommentar, wo ich mir diverse Infos zur Quelle notiere: - die Verwendung und den Sinn des Ganzen - was ich an welchen Portbeinen dran hab, ob diese In oder Out sind oder spezielle Funktion. - was für ein Quarz oder was für eine Taktfrequenz verwendet wird usw. je nach Projekt. Ist hilfreich, wenn man später mal wieder was dran tun muß. 3. Dann deklariere ich alle meine benutzten Portbits, Setupkonstanten und so weiter, Format je nach Toolchain. Das kann sehr umfänglich werden, ist aber hilfreich. Beispiel aus der PIC-Welt: ; LC-Messer nach 'AADE' ; Funktion: ein LC-Schwingkreis wird in einem Oszillator betrieben ; und seine Frequenz gemessen. Lx wird in Reihe zur eingebauten ; Induktivität Lo geschaltet und Cx parallel zum eingebauten Konden- ; sator Co. Beides reduziert die Schwingfrequenz. ; Aus der Frequenz werden Lx bzw. Cx errechnet. ; Kalibrierung: mittels eines per Relais anschaltbaren Kondensators Ck. ; Anzeige per Alpha-LCD ; einige unbenutzte Pins sind an Pfosten geführt. Deshalb mögliche ; Zusatzfunktionen: ; Thermometer ; IR-Fernsteuer-Empfänger ; einfaches Voltmeter INCLUDE P16F871.PIC ; Beschaltung: ; Port A: Thermo: BIT PortA,0 ; ADC für externes Thermometer Ana_1: BIT PortA,1 Ana_2: BIT PortA,2 Ana_3: BIT PortA,3 Count_in: BIT PortA,4 ; Frequenz vom LC-Oszillator Ana_4: BIT PortA,5 wfTrisA: EQU 111111b ; Tris: 0=Output, 1=Input wfPortA: EQU 111111b Beispiel aus der Cortex-Welt: #include "m051.h" /* die Beschaltung: Port 0 P0.0 in V/R Richtungssignal vom Drehgeber P0.1 out LE Latch Enable zum externen HF-Generator P0.2 out DATA Daten zum externen HF-Generator P0.3 out CLK Clock zum externen HF-Generator P0.4 spez SPISS1 Slave Select SPI1 an X5 P0.5 spez MOSI1 MOSI SPI1 an X5 P0.6 spez MISO1 MISO SPI1 an X5 P0.7 spez SPICLK1 Clock SPI1 an X5 */ #define p0_schmitt 0xFF // alle Pins Schmitt-Trigger #define p00 (0x000<<0) // Portpin #define p01 (0x000<<1) // Portpin #define p02 (0x000<<2) // Portpin #define p03 (0x000<<3) // Portpin #define p04 (0x100<<4) // SPISS1 #define p05 (0x100<<5) // MOSI1 #define p06 (0x100<<6) // MISO1 #define p07 (0x100<<7) // SPICLK1 #define wf_P0_MFP ((p0_schmitt<<16)|p00|p01|p02|p03|p04|p05|p06|p07) Später im Programm braucht man sich dann nicht mehr um die Einzelheiten der Einrichtung zu kümmern, beim PIC heißt das, daß man dort blind "wfTrisA" ins TrisA-Register schreibt unf "wfPortA" ins Port A Register usw. Beim 2. Beispiel geht es ähnlich: Dort landet in P0.MFP der Wert wf_P0_MFP usw. (wf_ ist meine private Abkürzung für "Wert Für ..") 4. Tja, dann kommt das RAM-Segment und dort das Deklarieren der diversen Variablen bzw. Speicherbereiche. 5. Dann kommt bei manchen uC das, was symbolisch in den Code gehört, also die Deklaration von Fuses, Idents usw. Ebenso der Preset-Inhalt vom EEPROM (sofern vorhanden) 6. und jetzt erst kommt der eigentliche Code, wobei ich eigentlich immer zuallererst die diversen Unterprogramme und erst am Schluß den Startcode und die finale Hauptschleife anordne. Reicht dir das jetzt als Anregung aus? (Bin müde....) W.S.
> Um den ADC im Noise Reduction Mode zu versetzen muß man ihn mittels > SLEEP in den Schalfmodus versetzten und dann sollte man sich auch noch Gedanken machen, was überhaupt benötigt wird. Um die Spannung eines Akkus auszumessen, brauchst du wahrlich keinen Noise Reduction Mode. Damit brauchst du auch kein Sleep und deine Blinkerei funktioniert wieder. Ansonsten ist das meiste ja schon gesagt worden: Einfach drauflos programmieren geht meistens schief. Was sich jetzt allerdings schlimmer anhört als es eigentlich ist. Denn was du dabei lernst ist, wie dein Projekt nicht oder nicht vernünftig umgesetzt werden kann. Und das ist dann auch schon etwas. Die erkannten Problemstellen führen dann in der nächsten Version dazu, dass man sie so nicht wieder macht. Dafür macht man andere. Erst mal durchdenken, Aufbau in etwa festlegen, d.h. die Grundidee des Programmes skizzieren. W.S. hat etwas sehr gutes eingebracht: benötigte Resourcen identifzieren und benennen. Und keine Scheu haben, ein Projekt mal in den Sand zu setzen. Das passiert allen. Und da wieder ganz besonders am Anfang seiner Karriere. Mit der Zeit kennt man dann seine Pappenheimer, weiß was gut funktioniert und was nicht. Erfahrung kann man eben nicht kaufen und auch nicht lernen. Erfahrung muss man sammeln.
Tja, warum aber überhaupt Assemblerprogrammierung? Ja, man sollte mal drüberschauen. Und in speziellen Fällen auch mal ganz genau. Aber sich da richtig reinknieen? Macht keinen Sinn. Beim nächsten Prozessor ist wieder alles ganz anders. Lerneffekt geht dann gegen 0. Was man auf einem Z80 oder 8051 gelernt hat, nutzt einem auf einem AVR oder PIC nicht viel. Und bei einem 32bitter ist es meiner Meinung nach eh so gut wie unmöglich (ausser man will mit grossem Aufwand das Gegenteil beweisen, natürlich geht es) Meine Meinung: Versuche das Problem möglichst exakt in einem Struktogramm darzustellen, die eigentliche Programmierung dann in einer Hochsprache deiner Wahl. Wozu soll man sich mit Adressen rumschlagen? Das kann ein Compiler besser. Wozu soll man wissen, wie eine 64/64 Division tatsächlich ausgeführt wird? Es reicht, wenn das richtige Ergebnis herauskommt. Die Algorithmen dafür sind bekannt, kann man nachlesen, wenn man will. In der Praxis ist es dann so, dass man letzlich doch auch in Assembler fertige libs dafür hernimmt. Also auch weit entfernt ist vom tatsächlichen Verständnis des Ablaufs auf Assemblerebene. Operanden rein, Ergebnis raus. Ist auch gut so, spart enorm Zeit.
Tja, Bernd, 6 Antworten, 6 verschiedene Meinungen. Es wird nicht einfach werden, Jemanden zu finden, der Dich an die Hand nimmt und mit Dir Dein (etwas unklar formuliertes) Konzept öffentlich erarbeitet und Schritt für Schritt in ein fertiges Programm bzw. Gerät umsetzt. Jeder hat irgendwie seinen eigenen Stil, es wird immer wieder vorkommen, dass Andere "bessere Ideen" haben, wodurch man sich recht leicht verzettelt. Du musst also für Dich Deinen eigenen Stil finden. Ich gehe meist so an eine Aufgabe ran: Analyse der benötigten Ressourcen. Also Auflistung (mit Papier und Bleistift) der benötigten Portpins (auch mit Sonderfunktionen), sowie der benötigten internen Perepheriemodule (ADC, Timer, UART, ...). Danach wähle ich dann (noch nicht endgültig) den Controller aus. Analyse der intern benötigte Takte mit dem Ziel, gemeinsame Vielfache für mehrere Aufgaben zu finden. Wenn ich z.B. Tasten entprellen muss, dann brauche ich einen Takt um die 30 bis 200 Hz. Ist noch ein handbetätigter Drehgeber im Spiel, brauche ich noch einen Takt von etwa 1 kHz. Wird Blinkerei gebraucht, so braucht es einen Takt, der zum Herunterzählen der Blinkzeiten taugt, wobei die Zahlenwerte der Blinkzeiten möglichst in ein Byte passen sollten, um 8-bittig arbeiten zu können. Soll noch eine "Uhr" mit rein, oder Verzögerungen, die im Sekundentakt einstellbar sein sollen, dann braucht es auch noch einen Sekundentakt. Ich versuche dann, aus all diesen Takten ein gemeinsames Vielfaches zu ermitteln, aus dem mit nur einer ISR durch geeignete Nachteiler alle Takte abgeleitet werden können. Bei mir ist dann oft auch noch Impulsmessung und/oder Impulserzeugung mit dabei (Servoimpulse oder DCC), die bei dieser Betrachtung berücksichtigt werden müssen. Aufteilung der Aufgaben in "kleinere Häppchen". Hier geht es darum, die zu erledigten Aufgaben so zu organisieren, dass sie quasi gleichzeitig abgearbeitet werden können. Ein Blinker kann also nicht mit "LED ein, warten, LED aus, warten" realisiert werden, weil während des Wartens halt nix Anderes gemacht werden kann. Der Blinker muss dann also als Zusatandsautomat (state machine) laufen, wobei die Mainloop bzw. ein Job davon in "jeder Runde" nur einen Schritt ausführt und sich dann anderen Aufgaben zuwendet. Bei der Aufteilung der Aufgaben auch darauf achten, dass öfter benötigte Dinge in Unterprogramme ausgelagert werden. Es gibt Leute, die so ziemlich alles in Unterprogramme bzw. Funktionen packen, weil es der Lesbarkeit dient, manch einer legt aber nur das in Unterprogramme, was von mehreren Stellen des Programms aus aufgerufen werden muss. Das Optimum liegt da irgendwo zwischen beiden Extremen, in einer öffentlichen Diskussion wird es also immer jemanden geben, der das im konkreten Fall anders sieht. Nun wird das Programmkonzept skizziert. Dabei bekommt jede ISR, die Init, die Mainloop, sowie alle Zustandsautomaten einen separaten Programmablaufplan (auf Papier), wobei auch gleich noch der Entwurf einer Variablenliste angelegt wird, die später überarbeitet wird, wobei entschieden wird, was ins SRAM muss und was in welchen Registern gehalten werden kann. Dabei werden auch nochmal die benötigten Ressourcen (RAM, Flash, EEP) geschätzt und ggf. die Auswahl des Controllers korrigiert. All die bisherigen Schritte erfolgten mit Bleistift auf Papier, der PC wurde nur zum Beschaffen von Informationen (z.B. Datenblatt) genutzt. Dann lege ich ein neues Projekt an, beginne mit einem Kommentar, wozu das Programm dienen soll, kopiere mir aus einer (selbst erstellten) Textdatei oder dem Datenblatt die Interrupt-Sprungtabelle (incl. I/O-Include-Datei) in den Quelltext, schreibe dann Konstantenzuweisungen, SRAM-Reservierungen und Registerdefinitionen, kopiere dann aus anderen Projekten Standardroutinen wie z.B. Tastenentprellung zusammen und schreibe dann die einzelnen ISRs, Unterprogramme und Mainloop-Jobs, wobei ich meist mit den hardwarenächsten UPs beginne. Ein UP ist also meist fertig, ehe ich die Routinen schreibe, die es aufrufen. Das ermöglicht Test-Assemblierung (kombiniert mit Speicherung) zum Erkennen von Tippfehlern. Und so wird dann nach und nach eine Funktionalität nach der anderen eingebaut und gelegentlich auch getestet, Dazu gibt es dann gelegentlich Debug-Code, der nach Funktionstest auskommentiert oder gelöscht wird. Ein generelles Konzept zum Erstellen eines Projektes wird es nicht geben, da jedes Projekt anders ist und bei der Vorarbeit andere Kriterien berücksichtigt werden müssen. Ehe Du Dein eigenes Projekt durchziehst, solltest Du also ruhig mal schaun, wie die Programme anderer Leute aussehen, also wie Andere ihre Programme strukturieren. Und dabei ruhig im Kopf mal CPU spielen und das Programm im "Trockentrainig" (im Kopf) abarbeiten. Dabei erkennt man oftmals, warum das so geschrieben ist und es gibt einen Aha-Effekt (die effektivste Form des Lernens). Bernd Stein schrieb: > Um den ADC im > Noise Reduction Mode zu versetzen muß man ihn mittels SLEEP in den > Schalfmodus versetzten, dadurch kam aber irgendwie mein Blinktakt für > die weiße LED durcheinander. Ja Kunststück, der Sleep-Mode der ADC-Rauschunterdrückung schaltet ja auch den Takt für die Timer ab. Kann man aber im Datenblatt nachlesen... ;-)) Diesen Sleep-Modus habe ich übrigens noch nicht gebraucht, nichtmal bei einem Voltmeter (Tiny24, LCD 10x1), das Gleich- und Wechselspannung ohne Umschalten misst. ...
Hannes Lux schrieb: > 6 Antworten, 6 verschiedene Meinungen. Sorry, inzwischen sind es (ohne mich) ja schon 8... ...
Gast
#2523591
Gute Idee, leider ist die Fragestellung etwas zu allgemein, als dass man groß was dazu sagen könnte. Ganz allgemein: Vom Einfachen zum Schweren, schrittweise vorgehen, kleine Schritte später zusammenpuzzeln, üben üben üben, herumprobieren, welche Arbeitsweise hilft, und regelmäßig von Profis abgucken, sonst lernt man auch nicht allzuviel. Wenn man regelmäßig was macht, ist man sehr schnell auf einem guten Level, was man bei C-Sprachtypen nicht so sagen kann, viel Abstrakta, viel Zeit... Dass man am Anfang nicht supereffizient schreibt, ist klar, Übung macht den Meister, nicht die Erwartung alleine. In einem Forum wie diesen hier, kann man übrigens sehr gut optimieren, was der eine nicht sieht, sieht der andere usw. Keine Angst vor Anfängerfehlern usw., die kennen wir alle, aber es ist gut, am Anfang die Fehler zu protokollieren.
Gast
#2523769
Dein beschriebenes Problem ist nicht sprachspezifisch. Anders ausgedrückt, die Programmiersprache ist zweitrangig. Die Empfehlungen die du hier bekommen hast sind eigentlich schon vollständig und somit sollte dir klar georden sein, dass du an einer (DEINER) Struktur feilen mußt. Google mal nach "statemachine", denke das hilft dir weiter. Die Struktur kann man hier gerne gemeinsam erarbeiten aber du solltest die Vorlage in Form eines Programmablaufplans beisteuern. Danach ist die Sache halb so wild und du erkennst selber wie man sich die Lösung erarbeitet.
Hannes Lux schrieb: > Jeder hat irgendwie seinen eigenen Stil Das kann ich nur unterstreichen. Jeder hat tatsächlich seinen eigenen Stil. Das geht soweit, dass man Programme einem bestimmten Programmierer zuordnen kann. > Analyse der benötigten Ressourcen. Also Auflistung (mit Papier und > Bleistift) Ist zb für mich ein wichtiger Punkt. Ich kann mich nicht erinnern, in den letzten 30 Jahren jemals NICHT mindstens 10 Bögen Schmierpapier neben der Tastatur liegen gehabt zu haben. Da werden Ideen skizziert, Verfahren anhand von Zahlen ausgeknobelt, Algorithmen entwickelt und durchprobiert, Problemskizzen gemacht, Teilaufgaben durchgerechnet ehe ich dann das Ergebnis mit dem vom Rechner vergleiche, etc. Mein Schmierpapier ist meisten recht voll. Nur eines findet sich dort garantiert nicht: ausgearbeiteter Code.
Gast
#2524029
Zur Fragestellung: Lese hier : http://de.wikipedia.org/wiki/Softwaretechnik und die weiterführenden Links Mal noch ein Kommentar: Wer sich freiwillig Assembler antut um Dinge zu erledigen, für die es nicht notwendig ist, nennt sich doch Masochist. Ist ungefähr so als ab man vom Hamburg nach München zu Fuß geht, weil man es kann, statt Auto, Zug, oder .... zu nehmen.
Gast
#2524160
Ralph schrieb: > Wer sich freiwillig Assembler antut um Dinge zu erledigen, für die es > nicht notwendig ist, nennt sich doch Masochist. Das sagen nur die, die es nicht können. Ich liebe Assembler. In Bits und Bytes zu denken tut kein bisschen weh. Deshalb bin ich auch kein Masochist. Grüsse
Gast
#2524179
Ganz so schlimm ist Assembler auch nicht. Das große Problem ist die recht schlechte Wartbarkeit und übersichlichkeit. Für ein kleine Problem wie ein Hallo Word, oder einfach mal ein blinken, wo man die Übersicht nicht verliert, ist ASM noch recht einfach und hat den großen Vorteil das da dann weniger Versteckte Fehler bzw. Abhängigkeiten vom Compiler usw. möglich sein. Bei einem etwas längeren Projekt würde ich ASM aber auch nicht wählen. Wenn es sein muss, dann ist vorher Planen wichtig, denn nachher ändern ist aufwendig und fehleranfällig.
Gast
#2524327
Bastler schrieb: > In Bits und Bytes zu denken tut kein bisschen weh Das kannst du in C genauso gut wie in Assembler. Aber geh dein nächstes Projekt mal mit einer Zeitvorgabe an. Und überwache mal die Zeit die du wirklich brauchst. Bei einem Hobbyprojekt mag das ja egal sein. Wenn du davon aber mal Leben willst, egal ob Selbstständig oder als Angestellter, wirst du ganz schnell merken das SOVIEL Zeit nicht vorhanden ist. Und JA wer µC programmieren will sollte Assembler können. Alleine schon um den Compileroutput lesen zu können, oder auch den Debugger sinnvoll zu verwenden. Und gelegentlich ist auch mal eine Subroutine in Assembler sinnvoll. z.B wenn man wirklich mal gaannzzz weit unten in den Registern manipulieren muss. Damit meine ich nicht einen Pin toggeln oder ähnliches. Eine Interruptroutine gehört da aber bestimmt nicht dazu. Wer da auf die Takte zählen muss, habt beim grundsätzlichen Design schon was falsch gemacht. * zu viel Logik im Interrupt * für die Aufgabe ungeeigneter µC * ....
Ralph schrieb: > Und überwache mal die Zeit die du wirklich brauchst. Das ist eine Frage der Voraussetzungen. Wer C und ASM kann, nimmt aus (Arbets-)Zeitgründen meist C. Ist nachvollziehbar, habe ich Verständnis für, werde ich keinesfalls kritisieren. Wer nur C kann, weil es ihm an der Uni widerwillig eingetrichtert wurde, der nimmt natürlich C, sucht ständig nach Fehlern aufgrund der Missverständnisse betreffs Compuler und Optimierung, versteht unterm Strich kaum was er macht, hat aber meist die große Klappe. Aber nicht Jeder kann C, denn nicht Jedem wurde es an der Uni als "Allgemeinwissen" eingetrichtert. Und wer mit irgendeinem dieser 8-Bit-Homecomputer aufgewachsen ist, der ist auch nicht mit C konfrontiert worden, sondern mit Basic und ggf. ASM. Tja, wer weder C noch Basic, noch ASM kann, und nur hobbymäßig kleine AVRs programmieren will, der ist mit ASM besser bedient, denn im Gegensatz zu C und Basic ist ASM eineindeutig. Bernd Stein hat nun das Problem, dass es ihm schwer fällt das Wesentliche vom Unwichtigen zu unterscheiden und dass er sich dadurch oft selbst im Wege steht. Er möchte aber lernen, kleine AVRs zu programmieren, um in seinen Basteleien flexibler zu werden. Da hat der gute Ralph natürlich den genialen Tipp, auf ASM zu verzichten und das mal so nebenbei mit links und 40 Fieber in C zu machen. Super... @Bernd Stein: Wie Du siehst, wird es schwer bzw. unmöglich, Dein Projekt von Anfang bis Ende hier öffentlich durchzudiskutieren, da es immer wieder Klugschwätzer gibt, die alles besser wissen, Dir aber unterm Strich auch nicht helfen, weil es Zeit kostet. Und es würde viel Zeit kosten, Dich bei dem Projekt öffentlich zu begleiten, ein Vielfaches von dem, als wenn Du mir (oder fast jedem Anderen hier) die Aufgabe genauestens beschreiben und ich (bzw. jemand Anderes) Dir das dann in ASM (oder C) programmieren würde. ...
Gast
#2524527
Hi Nun, ein paar Antworten hast du ja nun schon erhalten und so rühmlich, wie dein Vorhaben ist, hier eine Assemblerentwicklung öffentlich zu machen, wirst du nicht wirklich weiter kommen. Das liegt wie von vielen direkt auch gesagt, daran, das jeder seinen eigenen Stil entwickelt und es natürlich auch nicht lassen kann, auf Programmiersprachen der anderen Art zu verweisen. Bestenfalls wird dir geholfen, wenn du dir erklären läßt, wie andere ihren Code entwickeln und ehrlich gesagt, auch ich habe bereits Unmengen an Papier für Skizzen , Schematass und Notizen bemalt. Mittlerweile neige ich dazu, Powerpoint zu mißbrauchen, um die Struktur auch als Datei vorliegen zu haben. Trotzdem, zu einem Computer gehört auch Bleistift und Papier. In diesem Punkt bin ich mit anderen Entwicklern einig. Anders ist es beim Aufbau von Programmen. Da hat wohl jeder eine Vorstellung. Ich arbeite gern mit Variablen und Steuerbits. Andere meiden jede unnötige VAriable und nutzen lieber die vielfältig vorhandenen Register. Manch einer schreibt große Programmblöcke, ich hingegen tendiere zu Unterprogrammen, auch wenn es nicht erforderlich ist. Beispiel: Programmgerüst erstellen Stack initialisieren - danach
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
Mit einer solchen Struktur arbeite ich fast immer. Der Aufruf Read_UART erkennt an ungleichen Positionszeigern im Ringpuffer, ob zeichen eingetroffen sind. Der eigentliche Empfang wird selbstverständlich in einer Interruptroutine erledigt, die in den Ringpuffer schreibt. Durch diesen Aufbau kann ich relativ übersichtlich nun einzelne Funktionen meines Programmes mit Inhalten füllen. Aber wie gesagt, das ist mein Stil. Das ist nicht das gelbe vom Ei oder der Weisheit letzter Schluß. Wenn du es übernehmen willst, dann bitte. Wenn du eigene Ideen hast, auch kein Problem. Übrigends, so eine Vorgehensweise geht selbstverständlich auch in anderen Programmiersprachen. Gruß oldmax
C hat übrigens nicht zwangsläufig was mit Uni zu tun. Ja wir hatten es an der FH, aber nur sehr oberflächlich. Wir hatten es sogar in der schulischen Ausbildung zu ITA (Berufskolleg). Allerdings hatte ich mir zu dem Zeitpunkt C schon selbst beigebracht. Aber dafür braucht man schon ein oder zwei Bücher und ne Menge Zeit. Über ein Forum geht sowas nicht. Ansonsten stimme ich dem Grundtenor zu. Assembler: Sollte man können um Sachen nachvollziehen zu können. Bei großen Projekten, oder Projekten mit Zeitrahmen ist eine "Hochsprache" (C ist für Mikrocontroller lange nicht so "hoch" wie Java auf dem PC) besser angebracht.
Auf den Unis fangen sie heute mit Java an ... Wer's mag. Man kann C wie einen Makro-Assembler oder wie eine höhere Programmiersprache verwenden. Die Grenzen sind fließend (eine der Stärken von C). Können MUSS man beides wenn man sich mit Microcontrollern beschäftigt. Das dauert halt.
Gast
#2524641
Hi >Man kann C wie einen Makro-Assembler oder wie eine höhere >Programmiersprache >verwenden. Die Grenzen sind fließend (eine der Stärken von C). Oder man macht sich mit einem Macroassembler seine eigene 'Hochsprache'. Konstrukte wie lcd_print 'Hallo World' sind mit dem AVR-Assembler kein Problem. MfG Spess
Joachim Drechsel schrieb: > Auf den Unis fangen sie heute mit Java an ... Wer's mag. Das stimmt so nicht. Ich kenne mehrere Leute unterschiedlicher Studiengänge, die sowohl Vorlesungen über java als auch über C oder C++ dort gehört haben. Das hängt auch stark vom Studiengang ab. > Man kann C wie einen Makro-Assembler oder wie eine höhere > Programmiersprache > verwenden. Die Grenzen sind fließend (eine der Stärken von C). > Können MUSS man beides wenn man sich mit Microcontrollern beschäftigt. > > Das dauert halt. Jep
Gast
#2524681
Ich versuche bei Assemblerprogrammen meist mit include-files Strukturen in den Code zu bringen. Eine Art "main" Funktion, in welcher die include Files sind und sich der grundlegende Programmablauf befindet. Die jeweiligen Funktionen sind in den Include Dateien. So kann man schnell und unkompliziert eine Funktion ändern, ohne durch das ganze Programm zu scrollen und in der Main-Funktion hat man einen groben Überblick über das Program. Flussdiagramm malen ist sicher auch hilfreich. Ansonsten mal die grösseren Assemblerprojekte wie z.B. MenuetOS anschauen, isst zwar x86, man sieht aber trotzdem wie man ein Programm mit 10000++ Zeilen strukturiert.
unbekannter schrieb: > Ansonsten mal die grösseren Assemblerprojekte wie z.B. MenuetOS Gerade mal reingeschaut, sogar der TCP Stack in Assembler uäääh. Da hatte jemand wirklich sehr viel Langeweile.
Gast
#2524763
Hi >Gerade mal reingeschaut, sogar der TCP Stack in Assembler uäääh. Da >hatte jemand wirklich sehr viel Langeweile. Dann müssen die Ersteller der Libs die du benutzt, oder die, die den von dir benutzten Compiler programmiert haben auch Langeweile gehabt haben. Wie wäre es mal, wenn jeder Programmierer die Namen der Programmierer der benutzten Librarys in seinem Programm erwähnt und diesen dankt. MfG Spess
spess53 schrieb: > Wie wäre es mal, wenn jeder Programmierer die Namen der Programmierer > der benutzten Librarys in seinem Programm erwähnt und diesen dankt. Mach' ich doch, zwar nicht mit Libs, da ich nicht unbesehen fremde Codesammlungen verwende, sondern mit Peters Tastenentprellung. ...
Gast
#2524830
Simon K. schrieb: > unbekannter schrieb: >> Ansonsten mal die grösseren Assemblerprojekte wie z.B. MenuetOS > > Gerade mal reingeschaut, sogar der TCP Stack in Assembler uäääh. Da > hatte jemand wirklich sehr viel Langeweile. Schau mal auf der Microchip Seite da gibt es nen USB Stck in ASM :)
Gast
#2524861
Hi >Mach' ich doch, zwar nicht mit Libs, da ich nicht unbesehen fremde >Codesammlungen verwende, sondern mit Peters Tastenentprellung. Glaube ich dir unbesehen. Aber wie sieht bei der C-Fraktion aus? MfG Spess
spess53 schrieb: > Aber wie sieht bei der C-Fraktion aus? Die wollen doch das Fahrrad nicht nochmal erfinden... ...
Wenn ich fremden Code benutze, schreib ich es mit rein. Sieht aber ausser mir kaum einer - meistens geb ich gar keine Sourcen raus, will die gar keiner haben. Da kommt der beim Bestücker programmierte Chip auf die Platine und soll dort seinen Dienst tun, am besten völlig unauffällig. I.a. ist da auch eine Art Testprogramm für die Platine drin, damit der Bestücker sinnvoll testen kann. Der Kunde bekommt fertige, funktionsfähige Platinen und interessiert sich i.a. nicht für die Software. Hex-Files ja, Source nein. Gilt bei mir für ca. geschätzte 80% der Projekte. Der Vorteil für mich, den Autor mit zu erwähnen - ich finde auch nach Jahren schneller wieder, wer da "mitgewerkelt" hat und ob es evtl. Verbesserungen gibt.
Knut Ballhause schrieb: > 1. Poste Deinen Code > 2. Poste Deine Schaltung > > Dein Vorhaben ist nicht sonderlich komplex. Ein Tiny2313 kann diese > Aufgabe lösen. Dafür brauchst Du nicht einmal die Hälfte der Ressourcen > des Controllers. > Das denke ich auch möchte es mit einem ATtiny26 machen und danach mittels Migrations Appnote auf einen ATtiny426 - oder so - übertragen. Also als Übung, wie man bestehenden Code auf nachfolge Controller anpasst. zu 2. Schaltung zu posten lohnt sich nicht da variabler Testaufbau. Das Schaltelement soll mal ein N-MOSFET sein. Der kann aber erstmal eine LED sein, die ich noch nicht eingepflegt habe, da mich erstmal das Blitzen der Betriebsanzeige LED sowie die Ansteuerung der DUO-LED je nach eingelesenen ADC-Wert interessiert. Als Debug-Code dient die Ansteuerung eines LCDs mit der Ausgabe des ADC-Wertes in Hex bzw. seines Mittelwertes ( 64 Meßwerte / 64 ). Im Anhang ist mein bisheriger Kot. Bernd_Stein
Gast
#2527094
Hi Vielleicht noch ein kleiner Nachtrag. Wenn du mit einem µC arbeitest, der einen UART hat, oder du die Möglichkeit hast, eine ser.Kopplung zu einem PC aufzubauen, kannst du dir die Variablen zur Laufzeit ansehen. Ich hab mir das Tool OpenEye irgendwann mal geschrieben und es hat mir schon viele Dienste geleistet. Grad wenn der Code anfängt, etwas größer zu werden, ist mir die Anzeige der Variablen im µC sehr hilfreich gewesen. Das Programm ist hier irgendwo zum Download abgelegt. Gruß oldmax
Bernd Stein schrieb: > Das denke ich auch möchte es mit einem ATtiny26 machen und danach > mittels Migrations Appnote auf einen ATtiny426 - oder so - übertragen. Klingt gut. Es gäbe auch noch den ATTiny861, wenn der Flash nicht reichen sollte ;-) Bernd Stein schrieb: > Das Schaltelement soll mal ein N-MOSFET sein. Ich glaube, dass ein P-MOSFET besser geeignet ist, dann kann man mit gemeinsamer Masse arbeiten und auch an dieser messen. Ist aber Deine Sache. Bernd Stein schrieb: > Im Anhang ist mein bisheriger Kot. Okay, ohne mich tiefer hineingelesen zu haben, denke ich, dass das sehr viel Programm für eher wenig Funktionalität ist...
Bernd Stein schrieb: > Im Anhang ist mein bisheriger Kot. Mit solchen Konstrukten wie: ta_0: sbrs P_FLAGS,PRELL ;Falls Taster nicht entprellt ist... rjmp ta_0 ;...warten bis er entprellt ist... oder: wait_adc: sbic ADCSRA,ADSC ;...und warten bis dieser mit der Wandlung... rjmp wait_adc ;...fertig ist, danach das Ergebnis... kommst Du nicht weit. Auch Deine Warteschleife mit Timer bringt nix. Denn an diesen Stellen tritt die CPU auf der Stelle und wartet auf Ereignisse, anstatt sich wichtigeren Dingen zuzuwenden. Man nennt das auch blockierende Programmierung. Auch der Rest des Kots überzeugt mich nicht, Dir dabei zu helfen, denn Du hast Dich anscheinend schon auf diesen uneffektiven Stil eingeschossen. Wie Spess schon sagte, sehr viel Programm für sehr wenig Funktionalität. Das erinnert mich etwas an das, was man zu Homecomputer-Basic-Zeiten "Spaghetticode" nannte. Vielleicht soltest Du doch erstmal Dein Projekt beiseite legen und Programme anderer Leute analysieren. Ich denke, da findet sich auch Jemand, der Dir dabei hilft, indem er Dir konkrete Fragen zu einzelnen Codesequenzen erklärt. ...
Hannes Lux schrieb: > Wie Spess schon sagte, sehr viel Programm für sehr wenig > Funktionalität. Nö, ich war das ;-)
Knut Ballhause schrieb: > Nö, ich war das ;-) Entschuldige bitte, Knut, das sind die Anzeichen von Alzhaimer-light. Da kommst Du auch noch hin, wenn Du in's Alter kommst. Da kann mal schon mal den süddeutschen Wald (mit dem bekannten Wirtshaus) mit der halben Stadt am Tor zum anderen bekannten Wald verwechseln... Beste Grüße in die halbe Stadt mit dem schönsten Bahnhof der DB... ...
Ich denke nicht, dass das Alzheimer ist, wahrscheinlich eher Schießpulver oder Lötspritzer auf der Brille ;-) Hannes Lux schrieb: > Stadt mit dem schönsten Bahnhof der DB Hast Du Dir den angesehen?! Hätt´ste ja mal ´rumkommen können. Bier hab ich auch...
Knut Ballhause schrieb: > Hast Du Dir den angesehen?! Nein, aber in den Medien wurde darüber berichtet. > Hätt´ste ja mal ´rumkommen können. Ich war vermutlich 1988 das letzte mal regelmäßig bei Euch durchgefahren. Einen umfangreichen Stadtbummel bei Euch habe ich etwa 1978 mit meiner Tochter absolviert. Nach dem Ree hat es noch ein paarmal bis zum letzten (oder vorletzten? - fängt mit E an) Dorf rechts abseits der Straße gereicht, da wohnte ein Computerfreund. > Bier hab ich auch... Da mache ich mir schon lange nix mehr draus. Und mein Fahrzeug ist da gar nicht traurig drüber. Obwohl ich heute gar nicht mehr allzuviel unterwegs bin... Gruß vom königlichen Wässerchen... ...
Hannes Lux schrieb: > Da mache ich mir schon lange nix mehr draus. Na weil Du das Wirtshaus erwähnt hast ;-) Hannes Lux schrieb: > Nein, aber in den Medien wurde darüber berichtet. Die können viel schreiben und das machen sie ja auch. Hannes Lux schrieb: > Ich war vermutlich 1988 das letzte mal regelmäßig bei Euch > durchgefahren. Ist das endgültig?! Hmm... Hat sich einiges verändert derweil. Da wäre dann noch der Domschatz, wenn gar nichts mehr hilft... ;-)
Hannes Lux schrieb: > ... > Vielleicht soltest Du doch erstmal Dein Projekt beiseite legen und > Programme anderer Leute analysieren. Ich denke, da findet sich auch > Jemand, der Dir dabei hilft, indem er Dir konkrete Fragen zu einzelnen > Codesequenzen erklärt. > So etwas tue ich natürlich auch. Nur ist meistens die Herangehensweise nicht beschrieben, so das man sich immer nur wundert wie Die oder Der auf solche konstrukte kommen. Und die meisten wollen nicht wirklich Lehrer sein sondern Präsentatoren. Auch ich mag solche Sachen gar nicht, da mich ja gerade die Schnelligkeit von Assembler zu Commodore C64 Zeiten fasziniert hatte. Aber ich wuste ersmal keinen besseren Rat wohin ich in meinem Programm springen soll, wenn der Taster noch nicht freigegeben ist.
1 | |
2 | |
Dieses hier unten habe ich jedoch so oft in Programmen und Lehrbüchern gesehen, das ich gar nicht wirklich auf die Idee gekommen wäre es anders zu machen, wenn ich nicht mal gucken wollte was der ADC Noise Reductions Mode bringt.
1 | |
2 | |
3 | |
4 | |
Aber meine Programmstruktur war darauf nicht ausgerichtet, deshalb ist es ausgeklammert.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Dein Melodiengenerator beinhaltet schon einige Dinge die ich in meinem Projekt gebrauchen kann auch die Erklärungen hierzu sind gut. Werde Dich wohl in Zukunft mit einigen Fragen hierzu nerven, da ich deine Vorgehensweise und den Programmierstil mag. Mit Deinen Informationen zur möglichen Herangehensweise an ein Projekt in diesem Thread werde ich diesen Melodiengenerator vom Aufbau her sicher bessser verstehen und mal in die Tiefe gehen. Zudem denke ich das die OTs jetzt schon überhand nehmen, so daß ich mit den vorhanden Informationen erstmal zurecht kommen muß. Bernd_Stein
Bernd Stein schrieb: > Hannes Lux schrieb: >> ... >> Vielleicht soltest Du doch erstmal Dein Projekt beiseite legen und >> Programme anderer Leute analysieren. Ich denke, da findet sich auch >> Jemand, der Dir dabei hilft, indem er Dir konkrete Fragen zu einzelnen >> Codesequenzen erklärt. >> > So etwas tue ich natürlich auch. Nur ist meistens die Herangehensweise > nicht beschrieben, so das man sich immer nur wundert wie Die oder Der > auf solche konstrukte kommen. Und die meisten wollen nicht wirklich > Lehrer sein sondern Präsentatoren. Dir ist bewusst, wie aufwendig es sein kann, Lehrer zu spielen? Besonders dann, wenn man (wie ich) einen etwas unüblichen Stil hat und von allen Seiten deswegen kritisiert wird. Jeder weiß es besser, aber keiner ist bereit, mehr Zeit zu opfern, denn Zeit ist (für die meisten) nunmal Geld. > > Auch ich mag solche Sachen gar nicht, da mich ja gerade die > Schnelligkeit von Assembler zu Commodore C64 Zeiten fasziniert hatte. > Aber ich wuste ersmal keinen besseren Rat wohin ich in meinem Programm > springen soll, wenn der Taster noch nicht freigegeben ist. >
1 | |
2 | |
3 | |
Na zu den Prüfungen der anderen Jobs. Das geht natürlich nur, wenn Du weniger in Schleifen denkst, sondern mehr in Zuständen und Ereignissen. Ereignis: Timer hat Interrupt ausgelöst -> Nachteiler für verschiedene zeitabhängige Jobs runterzählen, z.B. Tastenentprellung (5..40 ms), Dehgeberauswertung (1 ms), Blinktaktbasis (z.B. 10 ms), ... Zustand: Nachteiler (evtl. mehrfach in der ISR vorhanden) -> Null geworden? - Wenn ja, dann auf Startwert setzen und Aktion zur Ausführung über Merker anmelden, wenn nicht, dann weiter in der ISR Zustand: Merker, Abfrage in der Mainloop -> wenn Merker gesetzt, dann zur Aktion verzweigen, diese löscht den Merker und macht einen Schritt der gewünschten Aktion, dann gehts zurück zur Mainloop. Diese Merker gelten also als Jobauftrag, der bei Erledigung entwertet werden muss. -> wenn Merker nicht gesetzt, dann weiter in der Mainloop Zustand: Blinkzähler oder Timeout, Behandlung in einem Job der Mainloop, wenn der zugehörige Merker von der ISR gesetzt wurde -> wenn Merker gesetzt, dann Merker löschen (Jobauftrag entwerten) wenn Zähler bereits 0, dann zurück wenn nicht, dann herunterzählen wird er dabei 0, dann Aktion auslösen (beim Blinker (mit einem Merker) prüfen, ob weiter geblinkt werden soll, wenn nicht, dann Ausgang ausschalten, wenn ja, toggeln des Ausgangs und Laden des Zählers mit dem Startwert Zustand: Merker, ob ein Blinker (oder was Anderes, was mehrere Operationen mit dazwischenliegenden Pausen verlangt) aktiv ist -> Aktion wiederholen, falls Merker gesetzt, Aktion abbrechen oder sauber beenden (Blinker nicht im Ein-Zustand stehen lassen, sondern ausschalten), falls Merker nicht gesetzt. Ereignis: Taste wurde von der Entprellroutine als betätigt gemeldet -> wenn nicht, dann ignorieren und weiter in der Mainloop -> wenn ja, dann Tastenbit löschen und Aktion ausführen Wichtig ist dabei, dass an keiner Stelle des Programms längere Zeit gewartet werden muss, bis eine Bedingung erfüllt ist bzw. ein Ereignis eingetroffen ist (z.B. Blinkzeit ist abgelaufen, ADC ist fertig, Taste wurde betätigt). Wenn der nächste Schritt einer (länger dauernder) Aktion noch nicht ausgeführt werden kann, dann macht man eben was Anderes. Ansonsten bleibt das Programm ja stehen, wenn ein Ereignis ausbleibt. > > > Dieses hier unten habe ich jedoch so oft in Programmen und Lehrbüchern > gesehen, das ich gar nicht wirklich auf die Idee gekommen wäre es anders > zu machen, wenn ich nicht mal gucken wollte was der ADC Noise Reductions > Mode bringt. >
1 | |
2 | |
3 | |
4 | |
5 | |
Naja, das wird wohl didaktische Gründe haben, um zu zeigen, wie es nicht optimal ist. Es liegt aber auch etwas daran, dass Hochsprachenverfechter möglichst alles in Funktionen gießen wollen. Ich halte es aber für uneffektiv, dem ADC zu sagen, was gemessen werden soll, und dann an Ort und Stelle auf das Ergebnis zu warten. Wenn mehrere Eingänge gemessen werden sollen, dann richte ich mir ein Array ein, in dem die Ergebnisse gesammelt werden und die Bitmuster für ADMUX liegen. In einer Statemachine wird dann reihum jeder Eingang ausgemessen, der Messwert gespeichert (oft dabei noch der Mittelwert über 256 Messungen berechnet) und der Adc sofort über ADMUX auf die neue Kombination von Eingang und Referenzspannung eingestellt und ihn für die nächste Wandlung einschaltet. In der Zeit, die der ADC zum Wandeln braucht, erledigt das Programm schon längst wieder andere Dinge. Triggern kann man das mit dem ADC-Complete-Interrupt, aber auch durch Abfragen des ADSC-Bits in der Mainloop. sbis adcsra,adsc ;ist der ADC fertig? - nein, weiter hüpfen... rcall/rjmp adcfertig ;ja, abarbeiten... ...nächste Ereignisprüfung... Der Noisecanceler-Mode schaltet CPU- und Timertakt aus, ist also nur benutzbar, wenn man keine Timer braucht. Natürlich kann man den Verlust von Timertakten während einer Wandlung auch berechnen und die Timer-Stillstandzeiten kompensieren, aber das ist nur ganz selten nötig, denn der ADC arbeitet auch ohne Sleep gut genug für die meisten Fälle. Es lohnt sich also nicht, diesen Aufwand zu treiben, Du hast genügend andere Probleme zu lösen. > > Aber meine Programmstruktur war darauf nicht ausgerichtet, deshalb ist > es ausgeklammert. >
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
> > Dein Melodiengenerator beinhaltet schon einige Dinge die ich in meinem > Projekt gebrauchen kann auch die Erklärungen hierzu sind gut. Werde Dich > wohl in Zukunft mit einigen Fragen hierzu nerven, da ich deine > Vorgehensweise und den Programmierstil mag. An Deinen Programmierstil passe ich mich aber nicht an. > Mit Deinen Informationen zur möglichen Herangehensweise an ein Projekt > in diesem Thread werde ich diesen Melodiengenerator vom Aufbau her > sicher bessser verstehen und mal in die Tiefe gehen. Der Melodiegenerator war doch nur eine Spielerei aus dem Jahre 2008 ohne praktischen Nutzen. Nachdem man mich belehrt hatte, dass das alles Quatsch ist und Chan da ein viel besseres Projekt hat, habe ich mich da nicht mehr drum gekümmert. > > Zudem denke ich das die OTs jetzt schon überhand nehmen, so daß ich mit > den vorhanden Informationen erstmal zurecht kommen muß. Naja, viel Hilfe kannst Du nicht erwarten, da Deine Aufgabenstellung schwer nachvollziehbar ist. Ich habe z.B. nicht begriffen, was alles an den Tiny26 angeschlossen werden soll und wie der ganze Kladderadatsch mit der Zweifarb-LED funktionieren soll. Auch habe ich noch nicht begriffen, wie die Spannungsüberwachung eingesetzt werden soll. Denn je nach Einsatz-Zweck können die Anforderungen anders sein. Mein RC-Impulsgenerator (auf meiner HP) z.B. zeigt den Akkuzustand (4 x AA NiMH) durch Blinken einer LED an und schaltet das Gerät bei Unterspannung aus. Meine Feuerwerks-Zünduhr (letzte Versionen bisher nicht veröffentlicht) zeigt die Spannung des 12V-Bleigel-Akkus nur am LCD an, schaltet aber nicht ab. Das Konzept ist also stark vom Einsatz-Zweck abhängig... > > Bernd_Stein ...
Knut Ballhause schrieb: > Ist das endgültig?! Naja, nach Bl..burg zieht mich nichts mehr, nach E..ben auch nicht mehr, und nur aus Spaß an der Freude fahre ich nicht mehr in diese Richtung. Aber irgendwie war ich zur Wendezeit kurz vor der Währungsunion nochmal da, habe im Druckerwerk zwei Centronics-Interfaces für den K6304 gekauft und als Zugabe die Drucker gleich mitbekommen. Da war Stimmung, denn ich hatte denen auch noch einen 120er Karton Negerküsse (damals eine Rarität) gesponsert... Warst Du da vielleicht auch dabei?? ...
Hannes Lux schrieb: > habe im Druckerwerk zwei Centronics-Interfaces für den K6304 gekauft > und als Zugabe die Drucker gleich mitbekommen. Da war Stimmung, denn ich > hatte denen auch noch einen 120er Karton Negerküsse (damals eine > Rarität) gesponsert... Klingt gut, wir hatten in der Tischlerbude ein Lager von Robotron, als die den Bach ´runtergingen, fielen einige Platinen ab, die großen Sachen wie 200W-Trafos und Druckwerke gingen in die Presse... Hannes Lux schrieb: > Warst Du da vielleicht auch dabei?? Nee, leider nicht. Habe Handwerk 'studiert' und später umgesattelt ;-)
Gast
#2528773
Hi Nun muß ich mich halt doch noch mal zu Wort meldem. Ich denke wie Hannes, lege aber viel mehr Information in den Variablenbereich. Die Speicherzugriffszeit nehm ich in Kauf, habe aber, und jetzt muß ich schon wieder Werbung für mein Programm machen, mit OpenEye eine bessere Kontrolle. Das Ereignisdenken hab ich von Delphi bzw. VB übernommen. Hier mal eine kleine Routine, die das Prellen von Eingängen abfängt und Eventbits setzt.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
Die hier aufgezeigte Routine ist nicht von Peter. Die hab ich erst später entdeckt. Allerdings, auch er nutzt sehr selten Speichervariablen. Mir sind sie aber sehr hilfreich, da ich die Bearbeitung von Eventbits gut mit OpenEye prüfen kann. Mag ja sein, das dadurch ein "Wasserkopf" entsteht, aber ein Zeitproblem hab ich dadurch noch nie gehabt. Allerdings sind die ausgewachensten Codes noch nicht über die 40% Marke eines Controllers gekommen. Gefüttert wird sie durch eine vorangeschaltete Routine "Read_IO", welche die Variable "New_In" füttert. Alles wird im Hauptprogramm der Reihe nach aufgerufen. Gruß oldmax
Oldmax schrieb: > Die hier aufgezeigte Routine ist nicht von Peter. Peters Routine ist an Einfachheit und Effizienz nicht zu überbieten. Sie funktioniert aber nicht nur mit Registern, sondern auch mit SRAM. Da muss man eben die Daten vorher holen und hinterher wieder sichern. Habe ich z.B. mal gemacht, als ich 40 Taster zu entprellen hatte, von denen 32 per SPI eingelesen wurden. Die SRAM-Zugriffe sind aufgrund LDD/STD und Index auch recht flott. Und Peters Routine bietet viele Ansatzpunkte für Erweiterungen wie Loslasserkennung, Kurz/Lang-Unterscheidung, usw. Auch das Auswerten der entprellten Tasten ist sehr komfortabel und übersichtlich. Man kann sie als Ereignisse sehen (Key_Press, tfl), aber auch als Zustand (Key_State, tas). Ich möchte sie nicht mehr missen. Besser, billiger und komfortabler kann man Tasten nicht entprellen. Beim Drehgeber benutze ich aber nicht Peters Routine, sondern meine eigene (mit LUT), wie auch für LCD und Ausgabeformatierungen. Und statt vieler einzelner Vergleiche benutze ich auch gern Vergleich in der Schleife mit Referenzwerten in Arrays. Für allgemeine Variablen nutze ich aber auch die Register, denn sie sind schneller und codesparender, und für unbenutzte Register gibt es nunmal kein Geld zurück. Kleine Programme kommen mit den Registern aus, bei größeren Programmen kommt viel in den SRAM. Was da wohin kommt, kommt auf den Einzelfall an. Denn bei der Planung eines Programms (mit Bleistift auf Papier!) wird auch ein Variablenplan erstellt, bei dem festgelegt wird, ob Variable in Array, einzeln adressierten SRAM-Zellen, unteren Registern oder oberen Registern gehalten werden. Bei neueren AVRs halte ich Merker auch gern mal in GPIOR0 im I/O-Bereich. ...
Noch vergessen... Oldmax schrieb: > Mir sind sie aber sehr hilfreich, da ich die > Bearbeitung von Eventbits gut mit OpenEye prüfen kann. Bei kleineren Programmen reicht mir meist eine LED zum Debuggen. Bei größeren Programmen habe ich meist sowiso ein LCD am Controller. Da meine LCD-Routine mit Bildschirmspeicher im AVR-SRAM arbeitet und das echte LCD im Millisekundentakt im Hintergrund refesht wird, kann ich sogar Debug-Infos ausgeben, die öfter/schneller eintreffen (z.B. in ISRs), als das LCD verkraften könnte. Denn damit sind LCD-Zugriffe einfache Schreibzugriffe auf ein Array, und das auch noch ohne Zeilenverschachtelung, die die wird von der im Hintergrund arbeitenden Refresh-Routine kompensiert. Da die LCD-Routine auch einige Steuerzeichen versteht und umsetzt, kann man sogar Fließtext an das LCD (also in den Bilschirmspeicher) senden. Wenn das Ding voll ist, wird von vorn begonnen... Aufgrund dieser LCD-Routinen kann ich auf den PC als Terminal gut verzichten. Und wenn es unbedingt sein müsste, dann kann ich imernoch den vorhandenen Dragon anwerfen und mit DW debuggen. Aber das ist recht selten der Fall. ...
Gast
#2529959
Hi Also, nur damit's nich mißverstanden wird.. die Tastenentprellung von mir stammt aus der Zeit, da hab ich die Danneger- Routine noch nicht gekannt... Sowas kommt halt vor, wenn man nicht immer in die Tut's schaut oder im Netz sucht. Auch in meiner kleinen Sub sind die statischen sowie KeyPress und KeyUP Ereignisse enthalten. Trotzdem, nicht mißverstehen, die von PeDa ist klar besser und effektiver. Es spricht auch nichts gegen debuggen von Programmen mit einem angebauten Display. Ich hab selten welche dran, weil bei mir der Controller nur Datensammler für den PC ist. Da ergit sich natürlich ein anderes Bild, da die Sub für einen Datenverkehr eh eingebunden ist. Bei derEntwicklung hab ich auch ständig den PC dran, also nutze ich die RS232 um auch gleich nebenbei zu prüfen. Da braucht nix umgestteckt zu werden und ie Funktionalität vom Programm ist nicht beeinträchtigt. Ich will euch OpenEye ja nicht verkaufen, das liegt zur freien Nutzung vor. Was die schnelligkeit von Variablenänderung betrifft, ähh ich bin schon etwas betagt, da kommt man sowieso nicht hinterher, wenn Änderungen im mSek. Bereich dargestellt werden....... Daher hab ich auf Tempo nicht einen so großen Wert gelegt und mich mit 100 mSek. zufrieden gegeben. Gruß oldmax
Nagut, weiter OT, aber es schadet Bernd bestimmt nicht, einiges über die "Hintergründe" zu erfahren... Oldmax schrieb: > Hi Low (oder so...) > Also, nur damit's nich mißverstanden wird.. die Tastenentprellung von > mir stammt aus der Zeit, da hab ich die Danneger- Routine noch nicht > gekannt... Neenee, das hatte ich bereits verstanden. Bevor ich Peters Routine fand, hatte ich nur eine 3x4-Matrix am AT90S1200 einzulesen, was bestens funktionierte, da ich die Abfrage (instinktiv) ins Multiplexing der dreistelligen LED-Siebensegmentanzeige integrierte. Das wäre auch nicht viel anders gegangen, da die Spalten der Matrix (durch Dioden entkoppelt) mit auf den Segmentpins der Anzeige lagen. > Sowas kommt halt vor, wenn man nicht immer in die Tut's schaut oder im > Netz sucht. Das geht mir auch so, denn da findet man leider auch zuviel, was vom Stil her nicht ins eigene Konzept passt. Und auch Vieles, was Anfänger veröffentlicht haben, weil sie es (momentan) für den Stein der Weisen gehalten haben, es bei genauer Betrachtung aber suboptimal ist. In das hiesige Tut habe ich schon lange nicht mehr geschaut, es mag sehr gut sein, um die ersten Schritte zu erlernen und die ersten Fallstricke zu überwinden, aber ab einem gewissen Punkt sollte man dann selbstständig zurecht kommen und eigene Ideen umsetzen. > Auch in meiner kleinen Sub sind die statischen sowie > KeyPress und KeyUP Ereignisse enthalten. Trotzdem, nicht mißverstehen, > die von PeDa ist klar besser und effektiver. Jou, wobei ich mich mit der zuerst (unter Bulletproof) veröffentlichten Routine begnüge und meine Erweiterungen selbst einbaue. > Es spricht auch nichts gegen debuggen von Programmen mit einem > angebauten Display. Ich hab selten welche dran, weil bei mir der > Controller nur Datensammler für den PC ist. Das ändert natürlich alles. Diese Anwendungen habe ich sogut wie nie. Meine Controler arbeiten alle autark (RC-Modellbau, Modellbahn (DCC und RC), Feuerwerkszündanlage, kleine Steuerungen, Steueranlagen im AFU-Bereich, ...). Einige (Feuerwerks-Zünduhr, RC-Lokfahrtregler für Gartenbahn, einige AFU-Geschichten) kommunizieren allerdings gelegentlich mit dem PC. Dann nutze ich natürlich auch UART. Dazu genügt mir auf der PC-Seite aber ein Terminal wie HTerm, oder ein schnell in VB6 zusammengeklopptes kleines Tool. > Da ergit sich natürlich ein > anderes Bild, da die Sub für einen Datenverkehr eh eingebunden ist. Bei > derEntwicklung hab ich auch ständig den PC dran, also nutze ich die > RS232 um auch gleich nebenbei zu prüfen. Wenn der Controller sowiso eine PC-Schnittstelle bekommt, dann nutze ich UART auch beim Debuggen. Dazu binde ich aber Teile meiner Routinen zur Ausgabeformatierung ein und lenke LCD_DATA-Zugriffe auf UART um. > Da braucht nix umgestteckt zu > werden und ie Funktionalität vom Programm ist nicht beeinträchtigt. Das geht mir auch so, ein "print r16", "print8 r9", "print16 r31,r30", "printbin r20", oder "printhex r3" temporär an der richtigen Stelle platziert, bläht das Programm auch nicht unnötig auf. > Ich > will euch OpenEye ja nicht verkaufen, das liegt zur freien Nutzung vor. Das habe ich auch so verstanden. Ich habe es aber noch nie vermisst und komme daher auch ganz gut ohne dieses Tool zurecht. Das geht jetzt nicht gegen Dich persönlich. > Was die schnelligkeit von Variablenänderung betrifft, ähh ich bin schon > etwas betagt, Na und?? - Ich habe die Sechzig auch schon lange hinter mir... > da kommt man sowieso nicht hinterher, wenn Änderungen im > mSek. Bereich dargestellt werden....... Kann man (am PC) loggen und sichern und anschließend analysieren. Wird natürlich schwierig, wenn man das ganze RAM berücksichtigt. Mit der Überwachung einer Variable (egal wo sie gehalten wird) ist das bedeutend übersichtlicher. Auf das Loggen konte ich aber bisher verzichten... > Daher hab ich auf Tempo nicht > einen so großen Wert gelegt und mich mit 100 mSek. zufrieden gegeben. Ich habe meine LCD-Routinen auch nicht auf Bildschirmspeicher umgeschrieben, damit ich das LCD unbekümmert im Interrupt zuballern kann (so schnell könnte ich ja auch gar nicht lesen), sondern um das LCD-Timing einhalten zu können, ohne den Programmablauf auszubremsen. Ich mag es nunmal nicht, wenn die CPU wegen Busywait auf der Stelle trampelt. Deshalb legt "lcd_data" die Textzeichen nur ins Array (Bildschirmspeicher), was ohne jegliche Wartezeiten abläuft (Schreib-Pointer holen, st..+, Pointer auf Array-Bereich begrenzen, Pointer sichern, Neu-Flag setzen). Das Übertragen des Inhaltes an das reale LCD erfolgt dann in einem Job der Mainloop, der vom Timer im ms-Takt angestoßen wird. Da ich meine Mainloop-Jobs meist mit rjmp aufrufe und mit rjmp mainloop verlasse, bekomme ich eine Art Priorität. Denn nach jedem Jobaufruf wird die Mainloop (die ja hauptsächlich Ereignisse prüft und davon abhängig zu Jobs verzweigt) von vorn begonnen, wodurch die vorderen Einträge bevorzugt werden. LCD-Update komt dabei ganz nach hinten. Es ist (wäre) zwar alle ms dran, es merkt aber keiner, wenn es mal verpennt wird, weil ein anderer (selten aufgerufener) Job (z.B. Berechnung) etwas länger gedauert hat. > Gruß oldmax ...
Hannes wrote > > wait_adc: > > sbic ADCSRA,ADSC ;...und warten bis dieser mit der > > Wandlung... > > rjmp wait_adc ;...fertig ist, danach das Ergebnis... > > > Naja, das wird wohl didaktische Gründe haben, um zu zeigen, wie es > nicht optimal ist. Es liegt aber auch etwas daran, dass > Hochsprachenverfechter möglichst alles in Funktionen gießen wollen. > Ich halte es aber für uneffektiv, dem ADC zu sagen, was gemessen > werden soll, und dann an Ort und Stelle auf das Ergebnis zu warten. Ich geh zwar im wesentlichen mit dir konform (das weißt du), aber ich denke hier übertreibst du. Der ADC braucht ja nicht lange. Das sind (Gedächtnis) 11 Takte, die hier gewartet werden muss. Also so schlimm finde ich das jetzt nicht. In 11 Takten kannst du nicht besonders viel anderes erledigen > In einer Statemachine wird dann reihum jeder Eingang ausgemessen, > der Messwert gespeichert (oft dabei noch der Mittelwert über 256 > Messungen berechnet) und der Adc sofort über ADMUX auf die neue > Kombination von Eingang und Referenzspannung eingestellt und ihn > für die nächste Wandlung einschaltet. In der Zeit, die der ADC zum > Wandeln braucht, erledigt das Programm schon längst wieder andere > Dinge. Diese Vorgehensweise ist vernünftig, nur einem Neuling eher schwer zu vermitteln. Aber grundsätzlich ist das ein guter Weg. > Triggern kann man das mit dem ADC-Complete-Interrupt, womit du von den 11 Takten ADC-Warten schon ein gutes Drittel aufgebraucht hast. Nimm noch Register sichern dazu und du hast deine 11 Takte schon wieder verspielt. Warteschleifen: erst mal - nein. Wobei es auch Ausnahmen für sehr kurze Schleifen gibt. Ist in einer Hochsprache auch nicht anders. Warten im kleinen µs Bereich ist schon in Ordnung. Sobalds länger wird, geht man auf einen Timer über.
Hannes Lux schrieb: >> Also, nur damit's nich mißverstanden wird.. die Tastenentprellung von >> mir stammt aus der Zeit, da hab ich die Danneger- Routine noch nicht >> gekannt... > > Neenee, das hatte ich bereits verstanden. Bevor ich Peters Routine fand, Ich glaube das geht jedem so. Meine erste Sortierroutine, damals noch in Basic auf einer PDP, will ich lieber niemandem zeigen :-) Aber: Sie hat funktioniert. Ich finde das grundsätzlich ja auch ok. Sich mal selbst im Wald zu verlaufen gehört genauso dazu, wie anderer Leute Code zu studieren und sich anzusehen, wie die bestimmte Probleme lösen. Ganz im Gegenteil: Die Analyse von fremden Code geht leichter von der Hand, wenn man selbst schon am Problem gearbeitet hat. Denn dann kennt man die kleinen versteckten Fallen die in jedem Problem stecken und achtet bei der Analyse darauf, wie andere sie umgangen haben bzw. überlegt sich, warum der Autor genau dieses Problem, an dem man selbst schier verzweifelt ist, gar nicht hat. Was einem beim Lernen nix bringt (ausser bei der PeDa Entprellung), ist Code einfach unbesehen zu übernehmen und sich daran zu erfreuen, dass er funktioniert. Das bringt einen in seiner persönlichen Entwicklung nicht weiter. Denn im Grunde ist man dann nur Zuseher und nicht Akteur.
Gast
#2530215
Hi
>In 11 Takten kannst du nicht besonders viel anderes erledigen
Es sind 13 ADC-Takte! Also CLK/ADC-Prescaler.
MfG Spess
Karl Heinz Buchegger schrieb: > Der ADC braucht ja nicht lange. Das sind > (Gedächtnis) 11 Takte, die hier gewartet werden muss. Es sind 13 ADC-Takte (nicht CPU-Takte), beim Start (was nach jedem Wechsel der Referenz oder des Eingangs sinnvoll ist) sogar 25. Aber das macht den Kohl (nicht die Birne) auch nicht fett, da hast Du schon recht. Ich finde es aber trotzdem besser, den ADC im Hintergrund klappern zu lassen, besonders dann, wenn mehrere Eingänge mit verschiedenen Referenzen gemessen werden sollen. Da zwängt sich SM und Array förmlich auf. Dass ich im Übrigen einen Großteil Deiner Einstellung teile, weißt Du ja... Karl Heinz Buchegger schrieb: > Was einem beim Lernen nix bringt (ausser bei der PeDa Entprellung), ist > Code einfach unbesehen zu übernehmen und sich daran zu erfreuen, dass er > funktioniert. Das bringt einen in seiner persönlichen Entwicklung nicht > weiter. Denn im Grunde ist man dann nur Zuseher und nicht Akteur. Völlig richtig. Nur lasse ich (für mich) die Ausnahme (Entprellung) nicht gelten. Ich nutze (in ASM und auf dem AVR) keine unverstandenen Routinen. Man kann diese Routinen übrigens viel besser und flexibler nutzen, wenn man sie versteht. Mir fällt es übrigens leichter, eine Low-Level-Routine selbst zu schreiben, als mich in den Umgang mit "gefundenen" (überladenen, da universell einsetzbar) Routinen bzw. Libs einzuarbeiten. Und ja, auch meine ersten Programmierversuche in CBM-Basic 3.5 möchte ich heute Niemandem mehr zeigen. Der Weg zum halbwegs effizienten Programmieren ist verdammt lang und steinig, zum Mais-Teer werde ich es da aber nicht mehr bringen, dazu ist die Lernkurve im Alter zu flach (Altersstarrsinn). Ich bin mir also durchaus bewusst, dass meine Programme nicht das Maß aller Dinge sind. ...
Bernd Stein schrieb: > Hallo zusammen, > > ich möchte an einem konkreten Assemblerprojekt lernen, wie man so etwas > grundsätzlich angeht. Dazu möchte ich mein Projekt hier im Forum > detailiert beschreiben und mit Euch zusammen erarbeiten wie man so etwas > umsetzt. Später soll dann aus dem ganzen das Wichtigste extrahiert > werden und so etwas wie eine Anleitung unter dem Motto : > > " Von der Idee zum fertigen Assemblerprojekt " entstehen. >... > Wie üblich gibt es ja fast alles schon in ähnlicher weise. Nur man muss es halt finden ;-} Beitrag "ATTiny10/11/12" Ich denke, da es hier auch darum geht ein Projekt in Assembler zu realisieren, das Hannes Lux mit diesem Thema durch ist. Und ich mir dort ansehen kann wie er solche Sachen früher angegangen ist. Habe es jetzt nur überflogen aber mit seinen nicht OT antworten in meinem Thread hier, kann ich sicherlich erkennen ob die Grundprinzipien zu erkennen sind. Mittlerweile ist mein hier eröffneter Thread in dieser OT-Version nicht mehr zu gebrauchen, so das ich mich wie schon mal erwähnt, wohl mit den bisherigen Informationen begnügen sollte. Bernd_Stein
Simon K. schrieb: > Joachim Drechsel schrieb: >> Auf den Unis fangen sie heute mit Java an ... Wer's mag. > Das stimmt so nicht. Ich kenne mehrere Leute unterschiedlicher > Studiengänge, die sowohl Vorlesungen über java als auch über C oder C++ > dort gehört haben. > Das hängt auch stark vom Studiengang ab. Klar. Mein VL studiert in HH Physik. Sie haben einen "kleinen Ausflug" in die Welt der Programmierung unternommen, ausgerechnet mit Java. Irgendwie werde ich das Gefühl nicht los, man wäre für's Leben versaut wenn man mit Java oder Basic anfängt. Scheint in zu sein. Egal, im XHTML-Forum bin ich auch der einzige, der in C die Sachen erstellt. PHP halte ich für zu lahm, zu unflexibel und zu unsicher. @Bernd Stein: Löse Dich von der Programmiersprache, sie ist zweitrangig. Wichtig ist, eine Idee zu haben. Die Realisation ist nur Technik und die kann man lernen. Wenn zwickt, gibt es Fachliteratur oder Foren. Hau rein !
Bernd Stein schrieb: > Bernd Stein schrieb: >> Hallo zusammen, >> >> ich möchte an einem konkreten Assemblerprojekt lernen, wie man so etwas >> grundsätzlich angeht. Dazu möchte ich mein Projekt hier im Forum >> detailiert beschreiben und mit Euch zusammen erarbeiten wie man so etwas >> umsetzt. Später soll dann aus dem ganzen das Wichtigste extrahiert >> werden und so etwas wie eine Anleitung unter dem Motto : >> >> " Von der Idee zum fertigen Assemblerprojekt " entstehen. >>... >> > Wie üblich gibt es ja fast alles schon in ähnlicher weise. > Nur man muss es halt finden ;-} Oder drauf hingewiesen werden... > > Beitrag "ATTiny10/11/12" > > Ich denke, da es hier auch darum geht ein Projekt in Assembler zu > realisieren, das Hannes Lux mit diesem Thema durch ist. Was meinst Du damit, dass ich "durch" bin? > Und ich mir dort ansehen kann wie er solche Sachen früher angegangen > ist. Habe es jetzt nur überflogen aber mit seinen nicht OT antworten in > meinem Thread hier, kann ich sicherlich erkennen ob die Grundprinzipien > zu erkennen sind. > > Mittlerweile ist mein hier eröffneter Thread in dieser OT-Version nicht > mehr zu gebrauchen, Wieso nicht? Funktioniert Dein "OT-Filter" nicht? > so das ich mich wie schon mal erwähnt, wohl mit den > bisherigen Informationen begnügen sollte. Man kann Dir nichts aufdrängen, damit würdest Du nicht glücklich werden. Du musst Deinen eigenen Stil finden. Dazu gehört erstmal, die zu lösende Aufgabe ganz präzise zu formulieren, und zwar nicht in Programmcode, sondern mittels Text, Skizzen, Ablaufplänen usw. Es ist wie mit dem Lösen von Textaufgaben in Mathe, zuerst muss mal analysiert werden, was überhaupt gemacht werden soll, erst dann lohnt es sich, nach einer Formel zu suchen und zu rechnen. > > Bernd_Stein Joachim Drechsel schrieb: > Löse Dich von der Programmiersprache, sie ist zweitrangig. Das stimmt. Deshalb mache ich es gerne in der Programmiersprache, die ich halbwegs souverän beherrsche. C ist es nicht, Basic nur auf dem PC, um kleine AVRs effizient zu programmieren, ist es mir (in Form von Bascom) zu verschwenderisch. > > Wichtig ist, eine Idee zu haben. Also das zu lösende Problem zu erkennen und mit eigenen Worten formulieren zu können, es also verstanden zu haben. > Die Realisation ist nur Technik und > die kann man lernen. Ja, das Umsetzen in die Programmiersprache ist Technik, Routine oder Fleißarbeit, gelingt aber erst, wenn man das zu lösende Problem völlig verstanden hat. > Wenn zwickt, gibt es Fachliteratur oder Foren. Genau das macht Bernd ja, nur fällt es ihm schwer, die Spreu vom Weizen zu trennen. ...
Hannes Lux schrieb: > Ja, das Umsetzen in die Programmiersprache ist Technik, Routine oder > Fleißarbeit, gelingt aber erst, wenn man das zu lösende Problem völlig > verstanden hat. Und es gibt leider viele die die Reihenfolge vergessen ;) Die Lösung eines Problems kommt immer aus dem Bauch, ich halte es für einen Irrglauben, Computer hätten etwas mit Logik zu tun. Die erste Idee ist immer unlogisch, man verfolgt sie, verwirft sie und kommt irgendwann zu einem Weg sie zu realisieren. Lernen kann man das nicht. Man nennt das auch Intuition. Ohne die geht's nicht. "Ich kann in xxx programmieren" heißt nicht, Probleme lösen zu können.
Hannes Lux schrieb: >> >> Wie üblich gibt es ja fast alles schon in ähnlicher weise. >> Nur man muss es halt finden ;-} > > Oder drauf hingewiesen werden... > In diesem Fall. Ich meinte eher im Allgemeinen. >> >> Beitrag "ATTiny10/11/12" >> >> Ich denke, da es hier auch darum geht ein Projekt in Assembler zu >> realisieren, das Hannes Lux mit diesem Thema durch ist. > > Was meinst Du damit, dass ich "durch" bin? > Nicht Du. Das Thema : " Ein Projekt in Assembler " für andere mit zu erarbeiten. Also an Projekten so intensiv mit zu arbeiten, ohne das Du es selbst gebrauchen kannst. Das hast Du doch " durch ". Ich meine das hast Du schon hinter Dir. Damit hast Du abgeschlossen usw. Das habe ich nur geschrieben, falls deine Frage doch widererwarten nicht auf lustige weise ironisch gemeint war. Bernd_Stein
Gast
#2532820
Hi >Das Thema : " Ein Projekt in Assembler " für andere mit zu erarbeiten. >Also an Projekten so intensiv mit zu arbeiten, ohne das Du es selbst >gebrauchen kannst. Das hast Du doch " durch ". Ich meine das hast Du >schon hinter Dir. Damit hast Du abgeschlossen usw. Ob Hannes abgeschlossen hat, weiß ich nicht. Aber du solltest langsam begriffen haben, das es keine universelle Anleitung für ein Softwareprojekte gibt. Oder suchst du eine Anleitung für dein Projekt. MfG Spess
Gast
#2532827
Hi Korrektur: 'Anleitung für ein Softwareprojekte gibt. Streich das 'ein'. MfG Spess
Bernd Stein schrieb: > Also an Projekten so intensiv mit zu arbeiten, ohne das Du es selbst > gebrauchen kannst. Naja, das wird mir noch öfters passieren... Allerdings habe ich es (fast) aufgegeben, mich zu vielen Standard-Themen zu äußern, wie z.B. Baudratenquarz, UART mit internem RC-Oszillator, Fusebits & Ponyprog, Text-LCD, Hausaufgabenlösungen usw... spess53 schrieb: > Ob Hannes abgeschlossen hat, weiß ich nicht. Eigentlich nicht, aber ich nehme mich und meine Erkenntnisse nicht mehr so wichtig... > Aber du solltest langsam > begriffen haben, das es keine universelle Anleitung für > Softwareprojekte gibt. Ja, die Welt ist bedeutend vielseitiger als man denkt. Ein 0815-Schema für alle Fälle funktioniert nicht. Daher ist es wichtig, die Aufgabe genau zu analysieren und mehrfach aus verschiedenen Sichtwinkeln zu betrachten, ehe man beginnt, sie zu lösen (in Programmcode umzusetzen). > Oder suchst du eine Anleitung für dein Projekt. Das glaube ich nicht, Bernd steht sich oft selbst im Weg, weil er es zweihundertprozentig machen will, ihm aber die Erfahrung fehlt, den Blich auf das Wesentliche zu richten. Er lässt sich immer von Nebensächlichkeiten ablenken. Ihm fehlen halt noch Erfahrungen, und die kann man, wie weiter oben bereits mal geschrieben wurde, nicht kaufen, auch nicht lernen, die muss man sammeln. Es gibt also Fehler, die man selbst machen muss, um daraus zu lernen. ...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.