PIC oder Atmel? Aller Anfang ist schwer...

[flicflac]

Fertisch...

So, hab mir mal mein Übungsboard zusammengebastelt. Schön ist was anderes, aber für meine Zwecke sollte es reichen.

Ich habe den als Eingängen vorgesehenen Ports A-C extertne Pull-up's gegönnt. Wenn ich sie nicht brauche werden sie einfach gebrückt. Ich probiere es erstmal mit den internen. Am Port C kann jedes Bit per Jumper als Eingang oder Ausgang verwendet werden. Rechts unten mit dem blauen Draht hab ich AREF rausgezogen. Ich werde es zwar nicht brauchen, aber besser man hat als man hätte.
Hmm, naja... die Richtung der Bit ist falschrum (Eifer des Gefechts), aber... Nobody is perfect. Ich werde es jedenfalls nicht neu löten, vielleicht trickse ich mit dem Kabel.

So, nun warte ich mal auf die Lieferung von Pollin...

flic

 

[Gordon]

@tsinger

hast du im Ponyprog die Schnittstelle richtig eingestellt und die Calibration durchgeführt. Wenn als Meldung kommt Calibration OK sollte es auch funktionieren.

@flicflac

sieht doch schon gut aus. Zum probieren reicht das allemal.

Da ich nicht weiß wie euer Stand bei der Programmierung ist hier noch ein Tip. Im Quelltext muß der Prozessor mit folgender Zeile definiert werden: .include "tn24def.inc" für den Tiny2313 "2313def.inc" und für den Mega8 "m8def.inc" die anderen µC entsprechend. In dieser Datei stehen die ganzen Registernamen, Ramgröße usw. drin. Es kann zu Fehlermeldungen kommen wenn die Datei nicht eingebunden ist. Der Punkt vor dem include darf auch nicht vergessen werden.

 

[Hammy]

@tsinger

hast du im Ponyprog die Schnittstelle richtig eingestellt und die Calibration durchgeführt. Wenn als Meldung kommt Calibration OK sollte es auch funktionieren.

Sicher. Was stellst 'n Du ein: "SI Prog API" oder "SI Prog I/O"? Bei mir funktioniert beides nicht. Ist das eigentlich gut, dass auf dem Anschluss 8 des Sub-D-Steckers, welcher beim Anschluss ans Board direkt mit einem Pin des Prozessors verbunden wird, 12V anliegen (die Miso-Leitung im Schaltplan)?

 

[ptlbahn]

12V an Miso? Der Pin verträgt nur 5V!
Der einzige Pin der 12V vertragen könnte ist der Pin Reset!
Und das auch nur für die Parallele Hochvoltprogramierung! Ich habe nur vor dem Spannungsregler höhere Spannungen wie 7V, am Prozessor selbst ist bei mir immer und überall max 5V!
Ich habe ein Adapterkabel vom Parallelport an die Anschlüsse MISO, MOSI und Clock sowie reset und masse verbinden, und dann noch 3,5-5,0V aus einer Batterie oder einem Netzteil die +Ub und Masse des zu Programierenden Prozessors versorgen!
Wo hast du denn den Prozessoe wie angeschlossen?
Doch wohl hoffendlich nicht am Seriallen COM-port des PC ohne Pegelwandler? (Handelsüblich oder eigenbau!)
Der Com-Port ist ein Port der mit 12V arbeitet, da muß dann ein Pegelwandler (zB. Max232) zwischen geschaltet werden, um ihn mit dem Com-Port des Atmel (Rxd und Txd) zu verbinden!
Habe ebend erst gesehen, das du in deinem Text einen Link zu einer Dokumentation des Testbordes versteckt hast. Und dort ist nur ein Anschluß über Com geplant.
Ich habe mit solchen Bords noch nix gemacht, aber eigendlich müßte es Funktionieren! Könnte es sein, das du eine Zinnbrücke zu einem anderen Pin hast, oder das du statz einem 1:1-Kabel ein Null-Modemkabel angeschlossen hast?
Stimmen die 5V Betriebsspannung am Ausgand des Spannungsreglers?
Ausserdem sollte der Spannungsregler 7805 eine Schtzdiode zwischen Ausgangaspannung und eingangsspannung erhalten.
Grund:
Ist am Ausgang ein Kondensator der die Spannung länger hoch hält wie am Eingang, so wird der Regler "Rückwärts" belastet, was diesen zerstören kann. Daher soll eine einfache Diode dann den Eingangselko aus dem Ausgangselko hoch ziehen.
Also eine Diode mit Katode am Eingangselko und anode am Ausgangselko, also für den Normalbetrieb in Sperrichtung.
Ohne diese diode habe ich schon diverse 78xx und 79xx (Negativregler) zerschossen. Seit ich die Diode drin habe passiert das kaum noch.

 

[Gordon]

wenn da irgendwo 12V anliegen ist das mit Sicherheit falsch. Die einzige Möglichkeit, die ich kenne, in der 12V benötigt werden ist die Hochvoltprogrammierung. Da liegen dann die 12V am Resetpin an. Ehrlich gesagt kenn ich mich mit dem Pollinbord nicht so aus. Schreib doch mal genau wie du was verbunden hast, dann schau ich mir mal den Schaltplan von dem Pollinbord an.

 

[Hammy]

Fehler gefunden: falsches Kabel (obwohl entsprechende Stecker). Nun funktioniert das Lesen und Schreiben. Übrigends, der geschundene Prozessor hat's überlebt.

 

[tt-mocki]

Ausgangsbelastung Atmel

Hi Leute,

ich lese hier schon 'n ganze Weile mit, weil ich auch so langsam anfange mich mit den µC's von Atmel zu beschäftigen.
Dazu mal 'ne Frage an die Praktiker: kann der Controller ein Reed-Relais mit 5V/500Ohm Eingangsseitig treiben (und davon dann 16 Stück) oder ist es doch besser noch Treiber davor zu setzen.
Der Grund für meine Überlegungen steckt im Motorweichenfred: http://www.tt-board.de/forum/showpost.php?p=295925&postcount=45. Ich bin zwar eher ein Freund der elektronischen Lösungen von uller oder ateshci aber will die Relaisvariante auch nicht aus den Augen verlieren.

 

[ptlbahn]

Gratuliere @ Tsinger! Damit dürftest du die 1. große Hürde geschaft haben!

@TT-Mocki
5V/500 ohm macht meiner rechnung nach 10 mA. Da nicht alle 16 gleichzeitig angezogen sein sollen, dürfte es funktionieren. Aber nimm die mit den Freilaufdioden, oder baue sie selbst ein!
Meines wissens schafft ein Port max 20mA und der schaltkreis insgesammt ca. 100 mA.
Allerdings ist ein Treiber ULN2804 (8 Treiber) auch nicht sonderlich teuer!

 

[tt-mocki]

jepp, max. 8 sind gleichzeitig ansteuerbar. Werd aber sicherheitshalber mal beim Treiber bleiben (2x 0,41€ sind ja zu verkraften). Wie sieht's aus bzgl. "normalen" und Reed-Relais, Last sind die Hoffmänner für die Weichen?

 

[E-Fan]

...kann der Controller ein Reed-Relais mit 5V/500Ohm Eingangsseitig treiben (und davon dann 16 Stück)...

Nimm lieber einen zusätzlichen Treiber wie ptlbahn es schon andeutete.
Erstens sind sie billiger als nen µC, zweitens ist alles nötige eingebaut (bei den ULN sind Freilaufdioden vorhanden), drittens vertragen sie mehr Leistung und viertens erspart es Ärger wenn man nicht auf passt und einen I/O von nem µC zerschießt.

 

[Hammy]

Kurios ist, dass das Testprogramm von Pollin auf meinem ATmega8-16 funktioniert, obwohl es für einen ATmega16 geschrieben ist - der ATmega8 unterstützt z.B. keinen JMP-, sondern nur den RJMP-Befehl; das Pollin-Testprogramm beginnt aber mit einem JMP-Befehl. Mein eigenes Progrämmchen (mir RJMP-Befehl), obwohl richtig laufend im Simulator, will auf dem ATmega8 nicht.

 

[ptlbahn]

Das ein Program für den Mega 16 auf dem Mega 8 läuft ist kein wunder, solange nicht auf teile zugegriffen wird, die im mega 8 nicht vorhanden sind. Der Mega16 ist ja (abgesehen von zusätzlichen Ports und anderen Zusatzbaugruppen) komplet mit dem mega8 Identisch, und selbst wenn du dein Programm im bereich der Interuptvektoren schreibst stört das nicht, solange keiner der Interups ausgelost wird.
Eventuell könnte noch der Stack probleme machen, wenn der RAM beim Mega8 kleiner währe, ist er aber nicht.
Und der Mega8 hat laut datenblatt ebenfals jmp im befehlssatz.
Das allerdings ein Program mit jmp-befehlen sich nicht problemlos in Rjmp-Befehle ändern läßt liegt an der Sprungweite.
Beim R-JMP stehen für die entfernung weniger Bits zur verfügung wie beim jmp. Und wenn jetzt die Entfernung zur Absoluten adresse größer ist wie die maximale Reichweite eines R-Jamps kann das nicht mehr klappen.

Ebend noch mal nach gelesen:
Dein eigenes Programm läuft nur in der Simulation, aber nicht im Chip.
Hast du da einen Ret/Reti-befel drin der auf den Stack zu greift?
Hast du dann auch das Ende des RAM in den SP (Stackpointer) eingetragen? Wenn nicht landet jeder Ret/reti auf adresse 0000, was das Programm neu startet.

 

[Hammy]

Und der Mega8 hat laut datenblatt ebenfals jmp im befehlssatz.

Nun, AVR-Studio sagt mir beim Compilieren mit JMP, das es diesen nicht gibt - RJMP funktioniert. Außerdem kann ich in meiner ATmega8(L)-Instruction Set Summary kein JMP entdecken, nur das RJMP. Ich habe weder ein RCALL (CALL gibt's nicht), noch PUSH/POP oder RET/RETI-Befehle benutzt.

Dein eigenes Programm läuft nur in der Simulation, aber nicht im Chip.
Hast du da einen Ret/Reti-befel drin der auf den Stack zu greift?
Hast du dann auch das Ende des RAM in den SP (Stackpointer) eingetragen? Wenn nicht landet jeder Ret/reti auf adresse 0000, was das Programm neu startet.

Dann dürfte es in der Simulation aber auch nicht laufen und müsste beim RET(I) von 0 beginnen.

Nun versuche ich, den C-Compiler von WinAVR zu besiegen. Wenn man jahrelang nur Java programmiert hat, fühlt man sich bei C (besser: den komplexen Makefile-Konstrukten) teilweise noch weiter in die Steinzeit zurückversetzt als mit Assembler. Aber das wird schon.

 

[Gordon]

@tsinger

wenn es nicht zu lang ist dann poste es doch mal, ich seh es mir dann mal an. Ansonsten kannst du mir die Datei auch per E-Mail schicken. Dann noch viel Spaß beim Programmieren.

 

[Hammy]

Erfolg! Statt PORTD muss man PIND lesen, um die Taster auszuwerten. In der Simulation spielt das keine Rolle, da kann man auch auf PORTD einfach die Bits "toggeln". Aber wenigstens merkt man sich selbst gemachte Fehler besser.

 

[E-Fan]

hmmm... wollen wir beim Thema bleiben oder den Thread in "Miniassemblerkurs für Fortgeschrittene" umbenennen oder doch eher über Vor- und Nachteile der µC aus den Häusern Microchip (PIC) oder Atmel (AVR, ARM) weiterphylosophieren?
Ganz ehrlich: Viele können mit an Sicherheit grenzender Wahrscheinlichkeit die letzten 5 Postings nicht in eine für sie geeignete Sprache übersetzen (inkl. meiner Wenigkeit) weils da mehr ums Proggen als um die Hardware geht.

 

[Hammy]

Wie jetzt? Ich dachte, Du hättest auch schon Atmels programmiert?

 

[E-Fan]

Ja sicher - aber in selbst beigebrachtem Basic.

 

[ptlbahn]

Also in meinem PDF-Dokument zum Mega8 (2486J–AVR–02/03) steht:
RJMP k Relative Jump PC ← PC + k + 1 None 2
IJMP Indirect Jump to (Z) PC ← Z None 2
JMP k Direct Jump PC ← k None 3
RCALL k Relative Subroutine Call PC ← PC + k + 1 None 3
ICALL Indirect Call to (Z) PC ← Z None 3
CALL k Direct Subroutine Call PC ← k None 4
RET Subroutine Return PC ← STACK None 4
RETI Interrupt Return PC ← STACK I 4

Allerdings nutze ich den jmp-Befehl kaum genutzt, so das es durchaus möglich ist, das da im AVR-Studio ein Fehler in der entsprechenden Datei vorliegt!

Ich benutze auch nicht die Incluid-Datei zum Prozessor, sondern so wie schon weiter oben beschrieben definiere ich mir die Ports selber, also eingangsregister (=Pin) Port A als pae, ausgangsregister als paa und das Steuerregister als pad (Port A Direktion) oder par (Port A Richtung).

Das kann ich mir wenigstens leicht merken!

@ E-Fan
Naja, wenn einer noch Infos hat, die für Pic sprechen, so würden mich diese schon interessieren, aber leider kommt (wie scheinbar immer) von der PIC-Fraktion nix weiteres Positives!
Ich wolte ja auch mal PIC´s testen, da ich aber keine vernünftigen (nachvolziehbaren) Infos zur Struktur und Befehlssätzen gefunden habe, gibt es entweder kaum PIC-Profis, oder diese wollen unter sich bleiben und verraten einfach weder Befehlssatz noch innere Struktur der PIC´s. Also werden hier halt Infos zu Atmel weiter gegeben! Und naja, in Basic mag das Programieren ja gehen, aber ich bevorzuge hier (noch) Assemble, da man hier den gerade im Kontroler doch recht knappen Speicherplatz besser verwalten kann. Hochsprachen haben immer Befehle in der übersetzung, die nur für speziele sequenzen nötig sind, und somit Speicherplatz verschwenden, oder die Rechenzeit verlängern.
zB. muß ein Sprungbefehl in hochsprachen immer noch einige Register beim Springen im Stack einlagern und hinterher wieder zurück holen. Aber wenn ich in Assembler weiß, das diese Register im Unterprogram nicht geändert werden, dann ist das halt nicht nötig, und ich spare etliche Befehle!

PS. Ich hatte auch schon mal über ein "Modellbahn-Controler-Board" nachgedacht, aber ob sich da genug user finden würden?

 

[E-Fan]

Tja dazu gibt es eben auch Hochsprachbefehle die genau diese Stackbenutzung unterbinden (in gewissen Grenzen) aber darum gehts in diesem Thread net.
Das führt zu weit und schreckt potezielle Neulinge ab weil zum Beipiel in Zeile 2 bis 9 Deines Postings nur panamachinesisches Gebrabbel mit etwas ethruskischem Dialekt verstehen. (bitte nicht persöhnlich nehmen! )
Die schalten dann ab und lesen nicht mehr mit.

Das bei Basic die Nase gerümpft wird ist mir klar, aber ich hab nunmal keine IT-Ausbildung sowie nicht die Zeit, Muße und Lust mich mit anderem zu beschäftigen.

Da kann ich gleich noch mal was zu Atmel und PIC erwähnen. Für beide µC-Familien gibts Entwicklungsumgebungen die mit Basic arbeiten. Unter anderem Bascom und FASTAVR für AVR und PIC-Basic für die PIC's. Letztgenannte IDE muss man aber erst kaufen bevor man was testen kann. Dat is doof!
Im übrigen erspart man sich durch die Verwendung von Hochsprachen einige Arbeit weil man für viele Dinge das Rad nicht neu erfinden muss (besonders wenn es um die Ansteuerung von Graphik-LCD-Displays geht. Viele Grundkonfigurationen (Abmessungen und Ansteuerungsroutinen der Displays) sind in den IDE's implementiert sodass man sich keinen Kopf mehr machen muss wie man nun was zu erledigen hat.

Die Zeiten des begrenzten Speichers sind eh vorbei.
Der Atmega256 ist mit 256kByte Flash der derzeit größte 8Bit-RISC Controller von Atmel und für das nächste Jahr ist eine 512kByte-Version angekündigt. Es gibt auch Gerüchte über eine 1Megabyte Variante.
Für µC sind solche Eckdaten gigantische Speicherausmaße

 

[Holgi]

Hallo,
dann will ich auch mal was dazu sagen, PIC lastig.
Ich hab vor einigen Jahren viel Material zu den PIC's gefunden,
sei es die schon erwähnte SPRUT Seite, die Projekte von MERG und auch zahlreiches in Foren. Das hat mich bewogen, mit den PIC's anzufangen.
Auch hab ich mir ein Basic dazu geleistet.
Man kann kleine Sachen damit viel einfacher machen, wenn es nicht auf Geschwindigkeit und Speicherverbrauch ankommt.
Dann gibt es auch einen guten Emulator, mit dem man während der Lern- / Testphase auch mal einfache zeitunkritische Sachen testen kann.
Andererseits kann ich auch nachsehen, wie der Basiccompiler das in Assembler umgesetzt hat, diese Teile zu optimieren und dann wieder als Assembler Teile in das Basic einzubauen (oder gleich mit dem Assembler weiterzumachen).

Ob ich heute mit den PIC's wieder anfangen würde weiss ich allerdings nicht. Aber ich hab im Moment nicht die Zeit und Lust mich in die AVR's einzuarbeiten und so bleib ich bei den PIC's.
Meine "Zentrale" ist eine C-Control II von Conrad, DCC Erzeugung, Handregler, Touchpadansteuerung, Zubehördecoder sind alle mit PIC's gemacht.
Einzig die Ansteuerung meines LCD-Displays macht ein AVR, das Programm hab ich aber nur wenig geändert übernommen und mit Ponyprog gebrannt.

Holger

 

[flicflac]

... Naja, wenn einer noch Infos hat, die für Pic sprechen, so würden mich diese schon interessieren, aber leider kommt (wie scheinbar immer) von der PIC-Fraktion nix weiteres Positives!
Ich wolte ja auch mal PIC´s testen, da ich aber keine vernünftigen (nachvolziehbaren) Infos zur Struktur und Befehlssätzen gefunden habe, gibt es entweder kaum PIC-Profis, oder diese wollen unter sich bleiben und verraten einfach weder Befehlssatz noch innere Struktur der PIC´s. ...

Hmm, ein bisschen "böse" ausgedrückt, finde ich. Pro PIC gab es schließlich auch.
Allerdings muss ich zugeben das sich der Thread in eine, zwar nicht gewollte, aber interessante Richtung entwickelt hat.

hmmm... wollen wir beim Thema bleiben oder den Thread in "Miniassemblerkurs für Fortgeschrittene" umbenennen oder doch eher über Vor- und Nachteile der µC aus den Häusern Microchip (PIC) oder Atmel (AVR, ARM) weiterphilosophieren?

Daran liegt es wohl, da der Ursprung des Treads entglitten ist (wie immer ) das sich PIC-Vetrtreter nicht mehr äußern.

Ich hab zwar den Thread gestartet nur ist er nicht mein Eigentum, gg. Den Thread zu splitten ist viel Arbeit für die Mod's und umbenennen verfälscht den Ursprung.
Allerdings scheint das Thema für eine nicht geringe Menge an Usern interesant zu sein. Vergleichbares hab ich bei der Suche jedenfalls nicht gefunden.
Ein Umbenennen in "PIC oder Atmel, Programmieren für Einsteiger" wäre eine Lösung. Bleibt beim Thema und wenn die Beiträge nicht (zu sehr) abgleiten , Betonung auf Einsteiger, auch im Sinne des Ursprungs. Wenn es zu speziell wird schau ich als Anfänger genauso doof aus der Wäsche wie in den einschlägigen Foren zum Thema. Eine Thread zwecks Erfahrungsaustausch in "höheren Sphären" zu eröffen steht ja jedem frei. Allerdings fehlen dann den Anfängern wieder die helfenen Hinweise der Erfahrenen... ein Teufelskreis.

@E-Fan
Was Basic angeht ist doch nix schlechtes dabei, vor Allem wenn der Befehlssatz eigentlich den kompletten Teil der Programmierung erschlägt. Ich hab auch mal mit C64-Basic angefangen, dann kam an der FH (vor vielen Jahren) Fortran dazu. Das noch mit dem berümt-berüchtigten Editor "vi" unter Unix. Um der Sache noch eins drauf zu setzen wurden wir ab 3. Semester noch mit Cobol bestraft. Aber das einzuschätzen obliegt wieder den Insidern...
Mein Abschlussprojekt habe ich in Borland C 3.1 geschrieben, 8255 mit Multplexer und externer Signalverarbeitung, aber gewisse Zyklen wurden auch unter BC3.1 mit Assembler erschlagen. Ich schweife ab...

Wäre ganz interessant wenn sich der Thread so ein bisschen als Hilfe für µC-Einsteiger entwickeln würde, Programmiersprache egal, nur eben nicht so kryptisch please!

flic

Ähh, P. hat ne Mail geschickt das meine Bestellung unterwegs ist. Im Löten bin ich schnell, also ab Mittwoch viele Fragen.... So als Vorwarnung, Wetter ist eh Sche...

 

[ptlbahn]

Naja, ich sehe mich ja auch noch als Einsteiger, und eine IT-Ausbildung habe ich nie gehabt!
Allerdings habe ich mich mitte/ende der 80er schon mit der Z80-Familie beschäftigt, und das ist vieleicht auch ein Grund, warum ich bei Atmel gelandet bin.
Sollten meine Beiträge zu Kryptisch werden, dann holt mich wieder "runter"! Ich will hier niemanden vergraulen! Allerdings fände ich es schön, wenn auch irgendwer mal einer einen solchen Einstieg für Pic (hier oder in einem Paralleltrade) verfassen würde.
Vieleicht komme ich ja dann auch noch zu den PIC.
Ich habe schon überlegt, ob ich nicht meinen Blockbaustein mit Tiny15 mal zur Diskusion stellen sollte (dann aber in einem anderen Trade).
Vielleicht könnten ja auch die Mods ein unterforum "µC" oder ähnlich hier einrichten, wo alles zu dem Thema zusammen gefast werden könnte. Dann taucht das hier nicht zwischen anderen beiträgen ins Nirvana ab, und der nächste Einsteiger fängt von vorn an.

 

[Hammy]

Vielleicht ist es ja wieder unpassend, aber meint Ihr, dass ich den winzigen Servo ES-05 von Conrad direkt anschließen kann oder sind schreckliche Störungen auf der Betriebsspannungsleitung zu erwarten? Sind die 3 Leitungen so, wie man es vermuten kann: braun/schwarz...Masse, rot...+5V, gelb/orange...Steuerung? Hab bei Conrad nix dazu gefunden.

Naja, ich sehe mich ja auch noch als Einsteiger, und eine IT-Ausbildung habe ich nie gehabt!

Das braucht man auch nicht. Richtige Freaks fangen ja eh' schon zu Jugendzeiten an, wenn die Ausbildung noch in der Ferne ist.

Allerdings habe ich mich mitte/ende der 80er schon mit der Z80-Familie beschäftigt, und das ist vieleicht auch ein Grund, warum ich bei Atmel gelandet bin.

Ich weiß nicht genau, warum ich Atmel den PICs vorziehe. Vielleicht weil es (scheinbar?) mehr kostenfreie Software gibt, mit der man erste Erfahrungen sammeln kann? Der Atmel-Assembler, den ich detailliert erst vor ein paar Tagen angeschaut habe, erinnert mich auch stark an meine UB8830/8840-Erfahrungen vor 15 Jahren. Über PIC kann ich dagegen eigentlich gar nichts sagen.

 

[Gordon]

Ich benutze auch nicht die Incluid-Datei zum Prozessor, sondern so wie schon weiter oben beschrieben definiere ich mir die Ports selber, also eingangsregister (=Pin) Port A als pae, ausgangsregister als paa und das Steuerregister als pad (Port A Direktion) oder par (Port A Richtung).

Das kann ich mir wenigstens leicht merken!

Den Tip auf die include Dateien zu verzichten halte ich für gefährlich. Gerade als Anfänger sollte man sich an die Definitionen des Herstellers halten. In den include Dateien werden ja nicht nur die Ports definiert sondern auch sämtliche anderen Register und zum Beispiel auch das Ramende. Um den Stack (Stapelspeicher) anzulegen brauchst du dann nur den Stackpointer (Stapelzeiger) mit dem Ramende laden und brauchst nicht im Datenblatt nachsehen. Außerdem erschließt sich mir nicht wirklich was an pae einfacher sein soll als porta. Die Gefahr ist auch wenn du dich an deine Bezeichnungen gewöhnt hast fällt es dir schwer andere Programme zu lesen, und auch im Datenblatt wirst du Schwierigkeiten bekommen da auch dort die Festlegungen des Herstellers verwendet werden. Also Anfänger nutzt die include Dateien, sie vereinfachen die Arbeit. Es ist nur eine Zeile im Code und das fertige Programm wird damit nicht ein Byte größer.

Das bei Basic die Nase gerümpft wird ist mir klar, aber ich hab nunmal keine IT-Ausbildung sowie nicht die Zeit, Muße und Lust mich mit anderem zu beschäftigen.

Im übrigen erspart man sich durch die Verwendung von Hochsprachen einige Arbeit weil man für viele Dinge das Rad nicht neu erfinden muss (besonders wenn es um die Ansteuerung von Graphik-LCD-Displays geht. Viele Grundkonfigurationen (Abmessungen und Ansteuerungsroutinen der Displays) sind in den IDE's implementiert sodass man sich keinen Kopf mehr machen muss wie man nun was zu erledigen hat.

Wenn du mit Basic glücklich wirst ist das ja in Ordnung. Ich habe übrigens auch keine IT-Ausbildung und nur eine Lehre als Elektromechaniker absolviert (zu einer Zeit als wir noch Röhren im Unterricht behandelt haben). Wenn man das Prinzip des Assemblers einmal verstanden hat ist es gar nicht so schwer. Ich muss auch gelegentlich nachsehen welche Befehle es für bestimmte sachen gibt, aber man versteht den Aufbau der µC besser. Ich würde auch nie versuchen einen PID Regler in Assembler zu programmieren, dafür gibt es ja die Hochsprachen, aber die eigentlichen Steueraufgaben lassen sich sehr gut in Assembler programmieren. Im übrigen brauchst du auch bei Assembler nicht jedes mal das Fahrrad neu erfinden. Wenn du dein Programm gut strukturierst und Funktionen gleich so programmierst das sie universell sind spricht nichts dagegen sie in anderen Programmen wieder zu verwenden. Die DCC Routine habe ich auch nur einmal entwickelt und nutze sie in allen folgenden Programmen. Viel anders macht es Basic auch nicht. Die Funktion wird einmal programmiert und dann vom Programm als Basicfunktion verwendet.