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.
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
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!
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
:-)
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.
...
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.
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.
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.
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
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.
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.
...
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
RCALL Init UART
2
RCALL Init Timer
3
RCALL Init_VAriablen
4
RCALL Init_Register
5
Loop_Main:
6
RCALL Read_IO
7
RCALL Debounce_IO
8
RCALL Read_UART
9
RCALL Chk_Event_1
10
RCALL Chk_Event_2
11
RCALL Chk_Event_n
12
RCALL Mode_1
13
RCALL Mode_2
14
RCALL Mode_n
15
RCALL Send_Uart
16
RCALL Write_IO
17
RJMP Loop_Main
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.
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
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.
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.
...
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 :)
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
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
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.
...
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
ta_0: sbrs P_FLAGS,PRELL ;Falls Taster nicht entprellt ist...
2
rjmp ta_0 ;...warten bis er entprellt ist...
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
wait_adc:
2
sbic ADCSRA,ADSC ;...und warten bis dieser mit der
3
Wandlung...
4
rjmp wait_adc ;...fertig ist, danach das Ergebnis...
Aber meine Programmstruktur war darauf nicht ausgerichtet, deshalb ist
es ausgeklammert.
1
; in A,MCUCR ;MCU Control Register laden...
2
; ori A,1<<SE ;...SLEEP freigeben und das...
3
; out MCUCR,A ;...MCU Control Register ueberschreiben...
4
; sleep ;...MCU schlafen legen und durch Wandlungs-
5
;...ende wieder wecken
6
in A, ADCL ;10-Bit ADC-Wert einlesen.Zuerst Low-Byte...
7
in B ,ADCH ;...danach das High-Byte
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
> ta_0: sbrs P_FLAGS,PRELL ;Falls Taster nicht entprellt ist...
2
> rjmp ta_0 ;...warten bis er entprellt ist...
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
> wait_adc:
2
> sbic ADCSRA,ADSC ;...und warten bis dieser mit der
3
> Wandlung...
4
> rjmp wait_adc ;...fertig ist, danach das Ergebnis...
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
> ; in A,MCUCR ;MCU Control Register laden...
2
> ; ori A,1<<SE ;...SLEEP freigeben und das...
3
> ; out MCUCR,A ;...MCU Control Register ueberschreiben...
4
> ; sleep ;...MCU schlafen legen und durch Wandlungs-
5
> ;...ende wieder wecken
6
> in A, ADCL ;10-Bit ADC-Wert einlesen.Zuerst
7
> Low-Byte...
8
> in B ,ADCH ;...danach das High-Byte
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 ;-)
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.
MOV Ablage_B, Reg_A ; zuletzt gültigen auch merken
35
EOR Reg_A, Reg_B ; Flanke 0-1 in Reg_A bilden
36
MOV Reg_B, Ablage_A ; letzten gültigen Status
37
AND Reg_B, Reg_A ; Neue "1" und Ändeung
38
LDS Temp_Reg, Event_To_1 ; unbearbeitete Events
39
OR Reg_B, Temp_Reg ; neue hinzufügen (0-1)
40
STS Event_To_1, Reg_B ; und wieder ablegen MOV Reg_B, Ablage_B ; jetzt noch alte "1" prüfen
41
AND Reg_B, Reg_A ; und Änderung
42
LDS Temp_Reg, Event_To_0 ; unbearbeitete Events
43
OR Reg_B, Temp_Reg ; neue hinzufügen (1-0)
44
STS Event_To_0, Reg_B ; und ablegen
45
MOV Reg_B, Ablage_A ; Flankenmerker laden
46
STS Old_In, Reg_B ; zum Schluß noch neu - alt
47
48
End_Dbnc:
49
RET
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.
...
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.
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_SteinJoachim 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
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
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.
...
Thread beobachten
Seitenaufteilung abschalten