Druckbare Version
Die Performance der AVRs kann einen schon umhauen, positiv betrachtet.
Natürlich kann das dazu verleiten das man sich bei der Programmopti-
mierung nicht mehr so viel Mühe geben braucht. Das ist ideal für solch
eine Programmierschlampe, die ich selber bin. Das Erfolgserlebnis und
die Lust, wieder zum Lötkolben zu greifen, ist eben grösser. VG Micha
Hallo!
@ Richard
Dann ist meine Vorgehenweise eine Negation deiner. Ich kann es zwar nicht Berechnen, aber dank meinem Vorgehen habe ich mir bisher seeehr viel Zeit für unnötige Tätigkeiten gesparrt. Leider habe ich es irgendwann bei mir ausprobiert und festgestellt, dass was ich langsam mache, wird als beste Lösung doch schneller fertig. ;)
@ peterfido
BASCOM ist sicher ein Dialekt vom BASIC und alle Register werden nur für den Interpreter/Compiler bekannt. Ich kann mir noch erinnern, dass ich früher auf einem PC sogar ASM Programme, wenn es um Idee und Funktionalität geht, mit QBASIC getestet habe, bevor ich mit ASM angefangen habe. Ich bin fast sicher, dass es auch beim BASCOM funktionieren wird. ;)
@ stefan_Z
Ich habe mir bisher noch nie Sorgen über Morgen gemacht. ;)
Ich versuche mich nur, wie gewöhnt, am besten informieren über das, was ich vor habe.
@ hardware.bas
Wie Du, bin ich auch, geborener Hardwar-ler und für mich bleibt die Software nur als unvermeindbares "Bauteil" um meine Hardware ins "Leben" zu bringen. Wahrscheinlich als Software-ler hätte ich mich nie im Leben wirklich wahnsinnig freuen können, weil angeblich nix reales sich bewegen würde. ;)
MfG
Q-Basic war Interpretersprache.
Turbo Basic auf Q-Basic aufbauend wurde kompiliert .
Gento
Ja, jeder hat so seinen eigenen Stil. Während man Testschaltungen oftmals
schnell zusammenstrickt, um Diese zu testen, werden sie dann natürlich
final richtig zusammengebaut. Mit der Software "sollte" es ähnlich sein und
Puristen halten sich daran. Bei mir ist es so, dass ich zum Schluss lediglich
einige Variablen selbsterklärend benenne, da ich keinen Bock auf
Kommentare habe. Bin eben ein "unordendlicher Gotobenutzer".
Ansonsten kann ich Richards Ausführungen gegenüber PICtur nur
beipflichten; BASCOM ist so einfach, dass man sich nicht in die
Hintergründe reindenken muss. Einfach runterladen, installieren,
druffwecke ... und läuft!!! Die Qualitäten als ASM-Profi können trotzdem
weiter gepflegt werden ... das eine schliesst doch das andere nicht aus.
VG Micha
Na ja, diese "geniale pfuscher Qualität" lag auch am Job. Im Notdienst mit nen Kombi hast Du nicht die Möglichkeit 30 Tonnen Material mit zu schleppen. Da muss man dann Nachts um 04:00 500 km von zu Hause auch schon einmal Improvisieren können und aus Sch...Rosinen basteln. :-) Dazu gibt es Unmengen an Alarmsysteme, für alle komplette UnterlagenZitat:
Zitat von hardware.bas
mit schleppen würden noch einen 30 Tonner erfordern.:-( Mann sollte also die Grundlagen beherrschen um sich helfen zu können.
Gruß Richard
Hallo!
@ Gento
Vielen Dank für prezise Erinnerung ! Mich hat es, ehrlich gesagt, nie interessiert. :)
@ hardware.bas
Irgendwann werde ich es sicher probieren. Ich muss mich nur an die 338 mögliche Fehlermeldungen vom BASCOM gewöhnen, die ich für mich als ausreichend finde. ;)
Weil ich schon immer Programablaufdiagram (PAD) angewendet habe, ist für mich unterschiedliche Geschwindigkeit der Ausführung normal. Eigentlich seit ich ZX-80 habe (mein erster im Bedienungsanleitung als PC genanter Computer mit 1 kB RAM und 4kB ROM), habe ich parallel mit BASIC, ASM, bzw. gemischt programmiert, je nach dem was gefragt war: schnell erstellt oder schnell laufen. Beim PIC's und AVR's werde ich es, wegen unterschiedlichen ASM Mnemonics, aber nicht mischen, lieber wechsle ich den µC. :)
@ alle
Ich möchte mir für Entwicklung der Programme auch ein Tiny 84V-10 PU mit 12 I/O's kaufen um 2*16 LCD "Monitor" zu haben, weil ich so gewöhnt bin. Danach sollte das fehlerfreie Program ohne Display und dazugehörigen Befehlen auf kleinstem Tiny mit 6 I/O's laufen, oder ? ;)
MfG
....Die meisten Programme sind aber auch gar nicht Zeitkreitisch.......
ha...ha...und ob sin die meisten zeitkritisch....
Die Unterschiede zwischen einem Tiny44/84 und einem Tiny45 sind für das Programm sonst relativ gering. Bei den IO Ports sollte man meist einen abziehen - den Reset Pin wird man für die Programmierung per ISP reservieren müssen.
Etwas aufpassen muss man welche IO Ports die haben. Der Tiny45 hat z.B. PB0...PB4 als nutzbare IO Ports. Der Tiny84 aber PB0..PB2 und PA0...PA7. Auch können die HW funktionen wie Timer auf anderen PINS liegen. Ganz ohne Änderungen geht also nicht immer.
Hallo Besserwessi!
Besten Dank für deine ausführliche und für mich verstädliche Antwort. :)
Die evtl. nötige neue Zuweisung der I/O's ist mir vom Anfang klar. Ich möchte das Display immer an PA0 ... PA5 anschliessen und die PA6 als PB4 und PA7 als PB5 für meine einfache Steuerung nutzen. Dafür werde ich doch einfachen Bord basteln müssen, weil ich nicht im Dunklen arbeiten mag.
Ich habe schon Datenblätter von ATTiny's durchgeflogen und verstehe noch nicht ganz, wie man zwischen Comparator und ADC bei angeblich gleichen MUX im BASCOM umschalten kann. ;)
MfG
Wie das mit MUX für den Komparator unter BASCOM geht weiss ich nicht. In ASM bzw. C setzt man den MUX beim ADC für den passenden Kanal, schaltet den ADC dann aber nicht an und stellt beim Komperator ein, das da der MUX benutzt werden soll. Wenn es ganz schlimm kommt macht man das in BSCOM halt auch mal von Hand mit direktem Zugriff auf die Register. Konstante Werte in Register Schreiben geht in BASCOM gut, das schafft der Compiler noch fast optimal.