Welche Programmiersprachen benutzt ihr ?

c

genauer benutz ich den gcc compiler (winavr) zusammen mit dem avr 
studio.

Die Programmiersprache ist (erstmal) völlig egal (es gibt aber wohl kein 
Delphi für AVR...).
Wichtig ist es, sich mit dem Datenblatt des Controllers auseinander zu 
setzen, sich auch mal die Tutorien anzugucken
(C: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
AVR-Assembler: http://www.mikrocontroller.net/articles/AVR-Tutorial)
und wenn man sich z.B. für Bascom (Basic-Dialekt für AVR) entschieden 
hat, sich dessen Handbuch genauer anguckt, BEVOR man hier Fragen stellt.
Dann ist es natürlich auch wichtig, erstmal zu gucken, ob nicht jemand 
anders schon das gleiche Problem hatte (Suchfunktion des Forums/Google).

>Ist Basic langsamer wie beispielsweise C; Funktionsumfang ?
Vielleicht nicht langsamer, teilweise aber wesentlich 
resourcenunfreundlicher, sofern man die vorgegebenen Funktionen benutzt.

Ich habe zuerst mal angefangen, mich mit Assembler durch die 
Datenblätter zu wühlen. Mittlerweile bin ich bei C gelandet und denke, 
dass mir der Einstieg über Assembler geholfen hat. Ich hatte vorher noch 
keine Erfahrung mit C, lediglich ein wenig Delphi. Mit ANSI C kommt man 
aber ziemlich schnell zurecht, wenn man schon mal eine andere 
Programmiersprache benutzt hat.
Viel langwieriger meiner Meinung nach ist das Erlernen der Vorgänge im 
µC. Wenn man hardware-Funktionen benutzen will (und nicht eventuelle 
library-Funktionen des Compilers nutzt), muss man sowieso einzelne 
Register bearbeiten. Und das geht wiederrum genauso schnell in 
assembler.
Für die ersten kleinen "Hallo Welt"-Programme ist assembler also gar 
nicht verkehrt.
Ich habe aber auch schnell gemerkt, dass man in assembler schon sehr 
strukturiert und geplant vorgehen muss, damit man nicht sofort den 
Überblick über den eigenen Code verliert. Eine höhere Sprache wie C oder 
Pascal erleichtert so eine Strukturierung wie ich finde erheblich. 
Datenblätter lesen und verstehen ist aber für hardwarenahe 
Programmierung auch in Hochsprachen unerlässlich.
Ein anderes Thema ist die Verfügbarkeit. Einen Assembler bekommst du 
sicher zu jeder Architektur kostenlos. C gibt es für AVR mit dem gcc, 
alles andere kostet Geld oder ist in einer kostenlosen Version in der 
Codegröße oder Nutzungsdauer beschränkt. Zu nennen wäre da aber noch 
BASCOM für Basic oder AVRco Pascal. Vielleicht willst du auch gar nicht 
bei AVR bleiben. Für Microchip PIC gibt es beispielsweise auch schöne 
Compiler, allerdings auch fast alle kostenpflichtig. Mit anderen 
Architekturen hatte ich noch nicht zu tun.
Einen C-Compiler wirst du aber so gut wie für jeden Controller auf dem 
Markt finden. Wenn du vielleicht mal professionell mit den Dingern 
arbeiten willst, führt wohl kein Weg an C vorbei.

Danke für die wirklich ausführliche Antwort "jmoney".
Vieleich mögen sich noch weitere zu dem Thema äußern.

grüße
Torsten

C weil's für mich einfach am bequemsten ist. Besonders, weil ich als 
Hobbyloge nicht auf einen µC fixiert bin. Mal mache ich was mit AVR, mal 
mit ARM, mal mit R8C. Ich bin nicht mehr so fit, um jedes Mal im Kopp 
auf den passenden Assembler Instruction Set umzuschalten. Ich bin froh, 
wenn ich das mit den Spezialregistern schaffe. Vor Assembler schrecke 
ich nicht grundsätzlich zurück, beschränke mich aber darauf beim 
Debuggen. Die handvoll Befehle kann ich in dann nachschlagen.

C und wenn nötig assembler implementieren. grade bei zeitkritischen 
funktionen.

C gibt es für --jeden-- Microcontroller. Bei jeder anderen Sprache 
kannst Du Glück, aber auch Pech haben.

In Assembler will ich heute kein komplettes Projekt mehr machen müssen. 
Assembler ist ok zum Kennenlernen des Processors und um KLEINE 
zeitkritische Programmteile effizient zu programmieren. In einem großen 
Projekt verlierst Du aber schnell den Überblick. Es gibt viele 
assembler-typische Bugs, die man sich mit den Hochsprachen spart.


Viele Grüße, Stefan

Ich habe mich für die Pic's von Microchip entschieden.

Da ich auf eine Hochsprache nicht verzichten wollte,habe ich mich auf
die Suche nach einer Programmiersprache für diese Controller gemacht.

Eine visuelle Programmierspache:
http://www.parsic.de/
Ein Tip für diejenigen,die keine Hochsprache erlernen möchten.
Das Preis-Leistungs-Verhältnis ist gut
Der Programmierer sollte eine Billig-Version für den 16F84 herausgeben.

Basic:
http://www.pic-basic.de/
Eine Programmierspache von der,hoffentlich noch eine Menge zu erwarten
ist,derzeit,im Vergleich zu anderen Produkten, leider ein noch zu
schwaches Preis-Leistung-Verhältnis(wenig unterstützte Controller).
Der Programmierer sollte eine Billig-Version für den 16F84 herausgeben.

Basic:
http://www.il-online.de/il_indx1.htm
Dieses Basic ist sehr leistunsfähig,leider liefen meine Applicationen in
der Demoversion nicht auf dem 16F84.(wie angegeben). Die schwefällige
Kommunikation mit dem Hesteller bei Problemlösungen hat zum NEIN, bei
diesem Produkt geführt.
'********************************************************************
Das theoretisch beste Basic für Pic's wäre(meiner Meinung nach):
http://www.mikroelektronika.co.yu/german/compilers.htm
Leider habe ich mit einer Testversion die einfachsten Dinge nicht zum
laufen bekommen,der Support war gleich 0,vielleicht hat ja schon einmal
jemand positive Erfahrungen gemacht ?
Wenn funktionsfähig, 1.ste Wahl.
Erste Wahl,weil Debugger integriert.
**********************************************************************
Die Entscheidung fiel auf:
 http://www.picbasic.org/proton_lite.php
Ein leicht zu verstehendes Produkt,ein an die alte Basic Stamp
angelehnter
Befehssatz.
Ein Support in Punkto Programmierung war bisher nicht nötig.
Nachteil:
Ich habe eine Version,bei der, bei Defekt des Rechners,eine neue
Registration notwendig wird,das kann dann z.B. eine Woche dauern,bis man
wieder arbeitsfähig ist.
**********************************************************************
Sicher gibt es weitere, unerwähnte Umgebungen,aber die obigen habe ich
ausprobiert.

mfg F.H.

*lol

F.H. wrote:

> Ich habe mich für die Pic's von Microchip entschieden.
Dannegger:
Dann solltest Du eigentlich wissen, daß PIC nicht gleich PIC ist.

Antwort: Darum steht da ja auch: Pic's von Microchip


> schwaches Preis-Leistung-Verhältnis(wenig unterstützte Controller).
> Der Programmierer sollte eine Billig-Version für den 16F84 herausgeben.

Dannegger:
Nun für Hochsprachen sind die kleinen PICs nur mit großen Bauchschmerzen
zu verwenden. Ihnen fehlen einfach zuviele wichtige Befehle.
In nem anderen Thread hatte ich ja kürzlich gezeigt, was für
schnuckelige Befehle bei anderen 8Bittern das Leben wesentlich einfacher
machen.

Antwort:
Dann schau Dir mal:
http://www.picbasic.org/proton_lite.php
an. Sehr effizienter Code,ich programmiere damit die meisten 
Durchschnittsanwendungen 10x schneller,als unsere Ing's in Assembler,nur 
in wenigen Ausnahmen kommt es vor , in Assembler programmieren zu 
müssen.

Dannegger:
Der Fokus der PIC-Hochsprachenentwickler liegt daher bei den PIC18xxx,
die anderen 8Bittern befehlsmäßig nahekommen.
Und das wird sich kaum nach abwärts hin ändern.
Antwort: Klar,Die 18er sind im kommen

Dannegger:
Bzw. ein 16F84 Compiler würde nicht billiger sondern teurer sein, da er
ja aufwendiger zu entwickeln wäre.

Blödsinn:
Antwort: Hättest Du dir die Link's angesehen,so hättest Du bemerkt,das 
SÄMLICHE oben genannten HERSTELLER,den 16F84 sowieso integriert haben.
Der 16F84 ist für kommerzielle Anwendungen viel zu teuer,somit könnte 
man eine Programmierumgebung nur für diesen Chip billig anbieten,da nur 
für Bastler interessant.

Ich gehöre zu denen, denen das Leben zu kurz fuer C ist. Alles andere 
ist gut. Zum Glück gibt's hie und einen Pascal compiler.

O.

an alle denen C zu schwer ist oder sie "zu blöd sind" kann ich nur sagen 
das wenn sie mit assembler zurecht kommen C ein leichtes für sie sein 
sollte.

wenn ich nur daran denke in assembler eine formel umzusetzen am besten 
noch mit 16 oder 32 bit auf einem z.b. avr... da würd ich mich lieber 1 
wochenende lang über ein C buch hocken.

basic ist auch nicht schlecht kann mich aber nicht dafür begeistern.

>Zum Glück gibt's hie und einen Pascal compiler.
Ich dachte, ich habe von fast allen Programmiersprachen schon mal 
gehört. Aber was ist hie?

Ich programmierer alle meine Anwendungen mit Logo. Ist zwar recht 
langsam, sieht aber schnuckelig aus, wenn das Schildkrötendreieck die 
Umrandungen von Buttons, Fenstern usw. Linie für Linie zeichnet.

>an alle denen C zu schwer ist oder sie "zu blöd sind" kann ich nur sagen
>das wenn sie mit assembler zurecht kommen C ein leichtes für sie sein
>sollte.

Es geht weniger um packen koennen, als ums wollen. Es ist mir zu blöd. 
Nur weil Kernigham & Ritchie keinen Bitset/Bitclear Befehl hatten, hat C 
immer noch keinen. Jeder Controller kann den. Und ich soll einen 
kryptischen Bandwurm deswegen hinschreiben. Nee.

P.

> Es geht weniger um packen koennen, als ums wollen. Es ist mir zu blöd.
> Nur weil Kernigham & Ritchie keinen Bitset/Bitclear Befehl hatten, hat C
> immer noch keinen. Jeder Controller kann den. Und ich soll einen
> kryptischen Bandwurm deswegen hinschreiben. Nee.

in c ganz einfach:
a |= 0x40;  // setzt bit 6
b &= ~0x02; // löscht bit 1

jeder mittelmässige c-compiler setzt das direkt in die entsprechenden 
bit-setz/clear befehle um
:-)

Hallo,

ich programmiere AVR mit Bascom.

a.6 = 1    'setzt das Bit 6 der Variablen a
b.1 = 0    'löscht das Bit 1 der Variablen b

Kommt meiner Denkweise näher als die Schreibweise von Guro in C.
Was jetzt Bascom daraus macht muss ich nicht wissen , da meine
Anwendungen bisher nicht Zeitkritisch sind.

Es gibt 2 Ansätze bits zu setzen

a |= 0x40;  // setzt bit 6
a |= 1 << 6;  // setzt bit 6

Wobei der zweite Weg eine Namensgebung erlaubt.

a |= 1 << TxEn;  // setzt bit 6

Wobei man natuerlich wissen muss, dass TxEn am PortA klebt.

Viel einfacher, auch aus dokumentierender Sicht ist doch

TxEn[@PortA,6]:bit;

TxEn:=1;  TxEn:=0;

Ganze Generationen von C Programmiern werden verarscht mit komplizierter 
Schreibweise weil irgendwelche Komitees von alten Sesselklebern, von 
denen natuerlich keiner mehr programmiert, keine Lust haben das zu 
aendern. Das haette man schon vor 20 Jahren aendern koennen.

P.

Die Güte einer Programmiersprache kann man übrigens auch daran messen, 
wielange es in 2,4,6 Jahren dauert eine Aenderung zu machen.

P.

Für ich las Hobby-MikrocontrollerBastler C. Sollte es irgendwann mal für 
Hobbyisten bezahlbare Mikros mit richtig viel SRAM geben, wäre C++ das 
Mittel meiner Wahl, aber bis dahin halt C. Aktuelle 
Pascal-Implementierungen kenne ich nicht, die, die ich kennengelernt 
habe, waren zur hardwarenahen Programmierung ungeeignet.

Ich habe während meiner Studienzeit einiges im Bereich NC-Steurungen 
programmiert. In Pascal, C, C++, und immer wieder Assembler. Erste 
Programmiererfahrungen gabs zur Schulzeit in Basic. Mit allen Spachen 
kann man problemlos völlig strukturlose, schwer zu lesende und gar nicht 
zu wartende Programme schreiben. Saubere Programmstrukturen, definierte 
Schnittstellen, wiederverwendbare Module bekommt man auch mit allen hin, 
allerdings erfordert das mit Assembler höchste Disziplin, und mit Basic 
geht es schlicht und einfach gar nicht. Vielleicht ja mit Visual Basic 
auf dem PC, das kenne ich nicht.

Ich erfasse ein paar Daten an meiner Heizung mit einer C-Control, und 
jedes mal, wenn ich da wieder Basic anwerfen muß, bekomme ich fast 
Schreikrämpfe. Für 20-zeilige Miniprogramme, quick and dirty, ist das 
prima, für mehr aber nicht.


Meine Meinung
Oliver

Hallo,

für meine Projekte war bisher Assembler die erst Wahl.
Voreingenommen, weil auch schon Z80, 6800, 6510 Assembler. ;)

Man kann auch in Basic saubere Strukturen programmieren, allerdings: ASM 
zwingt dazu mehr oder weniger schnell, wenn man seinen eigenen Kram in 4 
Wochen noch verstehen will, C zwingt auf Grund seiner Struktur dazu, bei 
Basic muß man es ganz von alleine machen, weil es eben auch völlig ohne 
geht (Spaghetti-Code eben).

Ich muß auch in Basic nicht zwingen dutzende GOTO verwenden, nur weil es 
geht.

Für meine Projekte habe ich bisher mit C meist das Problem, daß mir die 
komplexen Rechenergeschichten durch Bibliotheken bisher nicht wirklich 
fehlten.
Bit-Schubsereien sind mir da in ASM lieber.
Ich bin auch kein Freund von Universal-Bibliotheken, eher von 
Teilebaukästen. UART-Init mit den nötigen Berechnungsformeln für die 
Registerwerte kann ich in ASM genauso schnell kopieren, SendByte und 
ReceiveByte auch.
Routinen, die Register nach ASCI wandeln, auch für 16Bit-Werte liegen 
irgendwo rum usw.
Meine LCD-"Bibliothek" besteht genau aus LCD_Init, LCD_Write_Line, 
LCD_Clear_Line. Ich schreibe bis jetzt immer eine komplette Zeile, das 
hat noch nie wirklich gestört. Sollte es eine Ausnahme geben, baue ich 
mir die eben und setze sie wieder ein, wenn nötig.
Wozu soll ich aber diese Funktionen immer mit einbauen, nur weil ich sie 
in einem von hundert Fällen mal brauche?

Alles persöhliche Meinung von mir... ;)

Gruß aus Berlin
Michael

> C und wenn nötig assembler implementieren. grade bei zeitkritischen funktionen.

Dieses Argument kommt immer wieder und ich möchte gerne mal ein Beispiel 
sehen, aus meiner Sicht blödsinn.

> C gibt es für --jeden-- Microcontroller. Bei jeder anderen Sprache kannst Du 
Glück, aber auch Pech haben.

So ist es, das war auch für mich der Grund. Immer wieder einen neuen 
Assembler, nach dem 2en hatte ich die Faxen dicke.
Allerdings muß ich sagen das ich 15 Jahre lang Assembler programmiert 
habe und es zu weilen noch verwende.

> bin für C zu blöd, und mache deshalb Assembler...8051

> Ich gehöre zu denen, denen das Leben zu kurz fuer C ist.

Kann ich nachvollziehen. Die die C beherrschen verweisen auf K&R, 
genauso gut könnte man Laurel & Hardy empfehlen.
Ich kenne kein schlechteres C Buch, aber so ist es. Hat man den Einstieg 
gefunden so ist der K&R wieder zu gebrauchen.

Man muß davon ausgehen das Fachbücher von Leuten geschrieben werden die 
wissen wie es geht und genau hier liegt das Problem ;-))

> C iss mir zu kryptisch.
Das kann es sein, muß es aber nicht. Es liegt an dir.

> an alle denen C zu schwer ist oder sie "zu blöd sind" kann ich nur sagen
das wenn sie mit assembler zurecht kommen C ein leichtes für sie sein
sollte.

Siehe Kommentar "blöd". Im Prinzip stimme ich hier voll zu aber häufig 
scheint eben nur der Einstieg das Problem zu sein, ging mir auch so.
Hat man den Einstieg so wird man in C eine Eleganz entdecken die 
Assembler weit vorraus ist.

> Nur weil Kernigham & Ritchie keinen Bitset/Bitclear Befehl hatten, hat C immer 
noch keinen.

Na ja, beschäftige dich mit C für MC's und du wirst sehen das die 
Aussage falsch ist.

> C ist eine echt miese Programmiersprache, aber es ist nun mal die beste die es 
für Controller gibt.

Der gefällt mir.

Fazit: Wer MC's im profeesionellen Umfeld programmieren will kommt an C 
nicht vorbei. Wenn es Hobby ist dann ist es eh wurscht.

Ich benutze hauptsächlich als Prossesor AVR Mega Serie (Preis/Leistung)
daher finde ich Bascom und FastAVR in Verbindung mit Assembler mit
Assembler Routienen am Besten.

Dir Programmiersprache C auch zu Kryptisch.

MfG

Hauke,

habe FP sowohl in Assembler als auch in C verwendet, im Prinzip beides 
kein Problem. Aber heute schreibe ich keine Matheroutinen mehr in 
Assembler. Mein letztes Projekt dieser Art liegt 2 Jahre zurück und in 
ASM war es eine Qual.

> Zwischendurch hab ich auch mal in C programmiert, gefällt mir aber irgendwie 
nicht so richtig.

Mich würde das Irgendwie mal interessieren. Wo genau ist denn das 
Problem ?

> Bis man erst mal alle Compiler etc am laufen hat

Das ist allerdings nur eine Frage des OS sowie des Compilers. Wenn 
beides stimmt, reduziert sich alles auf anklicken einer setup.exe, und 
alles rennt. Und ein guter Compiler nimmt einem außerdem das 
Makefilegeraffel komplett ab.

Na ja, makefile ist auch keine "schwarze Kunst" ;-))

>Bei C ist es irgendwie so, wenn man drin ist, ist alles ganz einfach, aber wenn 
man versucht einzusteigen versteht man nur Bahnhof.

Das bestätigt aber das was ich weiter oben ausgeführt habe. Also, Hände 
weg von K&R ;-))

Real men only program in ASM :lol:

C ist viel einfacher/schnellen zu programmieren als asm, und viel 
einfacher zu debuggen.

"Use Interfaces" sind viel einfacher auf C als auf ASM, aber mit asm du 
kannst mehr Kraft für deines Geld bekommen.

Aber wie immer, wer wird dein Quellcode sehen ?, nur du ?, egal. Am 
Arbeitsplatz ?, besser wenn es gut dokumentiert ist, für alle.

> Für ich las Hobby-MikrocontrollerBastler C. Sollte es irgendwann mal für
> Hobbyisten bezahlbare Mikros mit richtig viel SRAM geben, wäre C++ das
> Mittel meiner Wahl...

c++ ist zwar die eierlegende wollmilchsau unter den programmiersprachen, 
aber  wenn man es so verwendet, wie's die c++ fans machen (konsequenter 
einsatz der ganzen oo-features, templates, laufzeitpolymorphie usw.), 
dann zwingst du damit den dicksten controller in die knie...
einer maschine, die ausreichend performant mittelgrosse c++ anwendungen 
ausführen kann, kannst du auch gleich eine java-vm spendieren ;-)
selbst abgespecktes embedded-c++ konnte sich bis heute nicht 
durchsetzen...

Andreas Schwarz wrote:
> Ordentlich geschriebene C-Programme sind sehr gut auf andere
> Compiler/Prozessoren portierbar (z.B. die Entprell-, RC5- und
> DCF7-Routinen von Peter).

"Ordentliche" C-Programme sind meist nicht µC-optimiert.
Interrupt-Routinen für den AVR werden wohl nicht dieselben wie beim PIC 
oder MSP430 sein. Mag sein, dass man ein c=a+b; portieren kann, aber 
wenn es um Timeraufgaben, Senden über UART oder CRC32-Check mi Hilfe der 
eingebauten Hardware, kurz, wenn es um die interne Hardware geht, ist 
C-Portierung einfach am Ende.

Desweiteren verstehen einige C-Compiler für µC Bitmanipulation, welche 
sich überhaupt nicht portieren lassen, da sie nicht einmal ANSI-C sind. 
Dafür erzeugen sie sehr kompakten Code. Man braucht nur den aufgeblähten 
Code eines GCC mit dem eines Codevision AVR zu vergleichen.

Steven
betacom@my-japan.de

> Man braucht nur den aufgeblähten Code eines GCC mit dem eines Codevision
> AVR zu vergleichen.

ich verstehe auch nicht, warum GCC so einen guten ruf hat. nur weil er 
umsonst ist? eigentlich kann er den kommerziellen compilern nicht das 
wasser reichen. ich habe noch keinen GCC erlebt, der schlanken, 
schnellen code erzeugen kann...

> eigentlich kann er den kommerziellen compilern nicht das
> wasser reichen

Ach? Sehe ich anders, jedenfalls was die Qualität des vom Compiler 
erzeugten Codes angeht. Von den Herstellern kommerzieller Compiler 
angestellte Vergleiche sind wie üblich mit Vorsicht zu geniessen.

Die Nachteile liegen eher woanders:

- In der Unterstützung spezieller Features wie getrennten Adressräumen 
für Code/Daten/EEPROM und dergleichen. Damit kommt GCC nicht zurecht, 
kommerzielle Compiler hingegen schon.

- In der Library. Speziell die bei GCC/ARM oft verwendete newlib neigt 
zu einer gewissen "Grundlast". Dass es auch anders geht, beweist 
WinAVR/avr-libc. Und mit dem Compiler hat das sowieso nichts zu tun.

- Manche Anwender schwören auf Compilererweiterungen, mit denen die Bits 
von I/O-Registern angenehmer abgebildet werden können. Aber Vorsicht, 
proprietäre Falle: Umstieg dann unmöglich.

>> So falsch ist die Aussage gar nicht. C für µC ist meistens kein ANSI-C.
>> Und somit erübrigt sich auch die Feststellung, man solle ASM und
>> Hochsprachen der Portierbarkeit nicht mixen. Das ist mit C für µC
>> ohnehin schlecht machbar.

Das Thema Portierbarkeit wird auch oft falsch angegangen. Ich schreibe 
für diverse MC Typen/Hersteller und mit Ausnahme des I/O Handling sowie 
spezifische Funktionen wie Interrupts, Timer... läßt sich alles in kürze 
portieren. Der Arbeitsaufwand liegt bei ca. 20%

In ASM gehts überhaupt nicht, 100%

Was ist vorteilhafter ?

Also, gelernt habe ich inzwischen Assembler, Pascal+Delphi, C und 
Derivate,  VB etc und Clipper. Beim Atmel mag Bascom recht kompfortabel 
sein, aber spätestens beim Umstieg auf andere Prozessoren guckt man in 
die Röhre. Also kommen eigentlich nur Assembler und C in Frage. Ich 
nutze C, weil es (meiner Meinung nach, nicht schlagen) wesentlich 
übersichtlicher und einfacher ist. Assembler ist da so ein bischen 
Urschleim. Bei Controllern ist man eh Recht hardwarenah am arbeiten, im 
PC-Bereich würde ich Assembler gar nicht mehr anfassen. Allerdings halte 
ich es für nicht unwichtig, sich mit Assembler auseinanderzusetzen, 
schon allein weil man dann die Funktionsweise eines Prozessors besser 
kennenlernt.

Ich persönlich bewundere die Assembler-Programmierer. Aber ich bewundere 
auch Boxer und würde mir selber nie für Geld die Fresse polieren lassen 
;-)


Gruß
Günni

Wer ins Assembler programmieren will, na lass sie machen.

Mann kann diese Leute auch Masochisten nennen..

Allerdings in einem muss ich zustimmen.
Wer auf µC programmiern will ( muss) , kommt ohne Assembler nicht aus.

Nicht zum Programmieren, aber beim Debuggen im System geht es nicht 
ohne.

Wer seinen µC mit den Resourcen so knapp kalkuliert hat, das es auf 
einzelne Takte ankommt, hat etwas grundlegendes falsch gemacht.

Software wird IMMER größer als geplant.