Attiny Programmierung

Ich weiß nicht, ob du dir den Krampf mit einem extra Arduino wirklich 
antun willst.
Soweit ich weiß, funktioniert das nur, wenn du einen Arduino in der 
Arduino IDE als Programmiergerät auswählst (nicht mit Atmel Studio).
Dann bist du immer an die Arduino IDE gebunden.

In Verbindung mit Atmel Studio hab ich gute Erfahrungen gemacht mit:

AVR ISP MKII

und dem Atmel-ICE. Besonders der ICE lohnt sich sehr, wenn man das 
ernsthaft betreiben möchte (leider etwas teuer).

Kai_25 schrieb:
> Falls es für Einsteiger einfachere Varianten gibt, würde ich mich über
> Infos, Tipps und Tricks freuen

Einen kleinen Cortex aus der STM32-Serie, die unterstützen alle 
Debugging über ST-Link V2. Bei Atmel gibts Debugging meines Wissens nach 
nur über den ICE, der wie gesagt teuer ist.

Wenn es 8-Bit sein muss, dann würde ich fast auch zu einem STM8 raten 
(läuft auch mit einem ST-Link V2). Leider ist da die 
Toolchain-Unterstützung etwas mau. Mein letzter Stand war, dass es von 
STM eine (sehr veraltete) IDE gibt. Der freie SDCC unterstützt ebenfalls 
STM8. Mir hat aber IAR am besten gefallen (in der kostenlosen Version 
codegrößenbeschränkt).

Edit: Die neueste Serie an ATtinys / ATmega lassen sich auch über das 
Pickit 4 Programmieren / Debuggen, der günstiger als ein Atmel-ICE ist: 
https://www.microchip.com/forums/m1070101.aspx
Ich weiß aber nicht, ob man sich damit auf die MPLAB X-IDE festlegt oder 
ob Atmel Studio inzwischen das Pickit 4 als Programmiergerät erkennt.

Future Product:
https://www.microchip.com/wwwproducts/en/ATTINY1624

https://en.wikipedia.org/wiki/ATtiny_microcontroller_comparison_chart

Kai_25 schrieb:
> Wie schon erwähnt möchte ich anfangen zu Programmieren, meine Frage
> direkt:
>
> Wird es mir möglich sein mit einem Arduino Uno R3
> einen ATtiny2313 zu programmieren ?

Möglich wäre das schon, nur warum willst du das? Auf dem Arduino Uno 
ist doch bereits ein Mikrocontroller drauf. Und zwar ein AVR ATMega328. 
Warum programmierst du nicht den?

Du mußt dazu auch keineswegs das Arduino-Gedöhns nutzen. Du kannst den 
auch direkt in C oder C++ oder Assembler programmieren.

Für erste Schritte in der µC-Programmierung ist es doch vollkommen 
unerheblich, ob du den ATMega328 oder den ATTiny2313 verwendest. Zumal 
die auch noch sehr ähnlich sind.

Wenn du z.B. so ein Kit verwendest kannst du damit zunächst zum lernen 
den dort enthaltenen Controller programmieren und später für eigene 
Projekte mit den neueren Controllern mit 3 Drähten eine eigene Platine 
aus dem Atmel Studio programmieren. Dazu ist nur ein Leiterzug 
durchzutrennen.

https://de.farnell.com/microchip/attiny817-xmini/entwicklungsboard-avr-mikrocontroller/dp/2674883

Max M. schrieb:
> In Verbindung mit Atmel Studio hab ich gute Erfahrungen gemacht mit:
>
> AVR ISP MKII

Dito, zumindest das Originale ist zuverlässig und beinahe unzerstörbar. 
Leider ist es EOL und unterstützt kein UPDI und damit die neuesten AVRs. 
Das sollte aber ersteinmal kein Problem darstellen.

Max M. schrieb:

> Edit: Die neueste Serie an ATtinys / ATmega lassen sich auch über das
> Pickit 4 Programmieren / Debuggen, der günstiger als ein Atmel-ICE ist:
> https://www.microchip.com/forums/m1070101.aspx
> Ich weiß aber nicht, ob man sich damit auf die MPLAB X-IDE festlegt oder
> ob Atmel Studio inzwischen das Pickit 4 als Programmiergerät erkennt.

Grundsätzlich funktioniert Atmel Studio mit Pickit 4. Es werden aber 
nicht alle Prozessoren unterstützt. Wie der Stand beim ATTiny2313 ist, 
weiß ich nicht.

Stefan ⛄ F. schrieb:
> Bevor ich mich mit diesen "neuen" AVR beschäftige, schaue ich mir lieber
> die STM32 an. Ich denke, davon habe ich langfristig mehr.

... kommt drauf an, wenn es mal um "richtig" low power oder batterie 
geräte geht sind die neuen avr's/pic's unschlagbar und wenn du dann auch 
die vielen on chip peripherie resourcen nutzt, dann must du vorallem in 
e.g. der arm welt lange danach suchen um diese nicht zu vermissen.


mt

Kai_25 schrieb:
> einen ATtiny2313 zu programmieren ?

Definitiv nicht für Anfänger geeignet. Anfänger erstellen gerne riesige 
undurchsichtige Copy&Paste Codemonster und scheuen modulare 
Programmierung, wie der Teufel das Weihwasser. Dafür sind nur 2kB Flash 
ein Witz.

Nimm einen ATmega1284, den gibt es noch als DIP.

Man nimmt kleine Mikrocontroller, um etwas kleines zu basteln. Logisch. 
Die Frage ist nur, ob man das auch tatsächlich kann. Und wenn nicht? 
Dann lieber ein fertiges Mikrocontroller-Board.
Z.B. ATmega328PB ist nur 33×18mm groß:
https://www.pololu.com/category/239/a-star-328pb-micro

Georg M. schrieb:
> Dann lieber ein fertiges Mikrocontroller-Board.
> Z.B. ATmega328PB ist nur 33×18mm groß

Gerade den ATMega328PB (mit der Betonung auf dem B am Ende) möchte man 
als Anfänger nicht verwenden. Denn er ist anders als die anderen 
ATMega328 vor ihm (die wiederum sind untereinander kompatibel).

Und was das Hauptproblem für einen Anfänger ist: praktisch alle 
Informationen die man in Foren, Wikis und Blogs findet, beziehen sich 
auf eben jene ersten Generationen des ATMega328 und führen in die Irre, 
wenn man den 328PB hat.

Axel S. schrieb:
> Gerade den ATMega328PB (mit der Betonung auf dem B am Ende) möchte man
> als Anfänger nicht verwenden.

Warum nicht, er ist doch abwärts kompatibel. Die zusätzlichen 
IO-Funktionen muß niemand benutzen.

Der einzige Nachteil ist, daß der ATmeg328PB nicht mehr den 20MHz Quarz 
unterstützt. Ich hätte ja eher erwartet, daß eine Nachfolger besser ist, 
z.B. 32MHz unterstützt.

Arduino Fanboy D. schrieb:
> Dein hingekotzter Beitrag ist bar jeglicher fachlicher Substanz.

Ich find den sehr hilfreich.

Kai_25 schrieb:
> Falls es für Einsteiger einfachere Varianten gibt, würde ich mich über
> Infos, Tipps und Tricks freuen

Kommt das nicht einer Frage nach Alternativen gleich?

Arduino Fanboy D. schrieb:
> Ob ich einen ATtiny2313 für das passende Einsteigermodell halte...?
> Eher nicht.
> Aber machbar?
> Ja!

In Assembler, aber Freude macht es nicht.
Der AT90S2313 war ja der erste verfügbare AVR, daher habe ich mich damit 
auch abgequält.
Schon float belegt 1kB Flash. printf, scanf: no way!

Menschenskinder schrieb:
> Nein. Der At90S1200 war der Erste.

Dann eben:
Der AT90S2313 war der erste verfügbare brauchbare AVR.

Peter D. schrieb:
> In Assembler, aber Freude macht es nicht.

Natürlich macht Assembler Freude und auf so einem "kleinen" brauchts zum 
Verrecken kein float! Und ein 4-zeiliges LCD-Displ. und ein paar Taster 
oder so sind mit einigen wenigen Zeilen voll eingebunden. Was will man 
mehr auf dieser Ebene?
Gruß Rainer

Axel S. schrieb:
> unerheblich, ob du den ATMega328 oder den ATTiny2313 verwendest. Zumal
> die auch noch sehr ähnlich sind.

Hmmm,
die Portierbarkeit der asm-files ist aber doch mit einem größeren 
Aufwand verbunden, möchte ich meinen
Hab ich selbst ausprobiert.
Nur ganz kurz zum Vergleich:
Portzuordnung Rs232

PD0=RXD;PD1=TXD  AtTiny2313/bzw. mit mehr RAM 4313
PD2=RXD;PD3=TXD  ATMEGA32U2

und die ganzen Interruptvektoren. etc... die der AtTiny nicht kennt.
Direkt 1:1 klappt nicht. Muss man editieren.
Nicht umsonst gehört zum Lieferumfang eines STK500 gleich ein 
ATMEGA8515.
Momentan steckt wieder ein ATiny4313-er drin.
Stefan ⛄ F. schrieb:
> Spätestens wenn ein Display dran kommt,
> nerven sie jedoch nur noch.

DCF77 Decoder-Programm mit 2x16-er LCD und RS232 und Gangreservve und...
mal gucken, was ich noch dran feilen kann.

Soo schlecht sind die kleinen Dinger auch nicht.
Aber:

c-hater schrieb:
> Fakt ist jedenfalls, dass es gerade für Anfänger nicht gerade hilfreich
> ist, einen Controller mit wenig Resourcen zu benutzen. Insofern ist es
> also auf jeden Fall sehr sinnvoll, den Mega328 statt eines Tiny2313 zum
> Einstieg zu benutzen. Denn der hat von allem mehr, mehr Pins, mehr RAM,
> mehr Flash. Damit ist die Gefahr, auf irgendwelche Resourcengrenzen zu
> stoßen deutlich geringer.

ciao
gustav

c-hater schrieb:
> fehlende
> Hardwaremultiplikation. Dann muss man sich was einfallen lassen, wie man
> die Funktionalität mit dem umsetzt, was da ist...

...wenn ich das schon höre...was willste denn multiplizieren?? 
64Bitx64Bit??? Ganz sicher nicht. Und Assemblerroutinen für eine 
Multiplikation/Division gibts wie Sand am Meer. Da stört auch nicht eine 
UART-Schnittstelle...und das LCD schon gar nicht!
Gruß Rainer

c-hater schrieb:
> Bist du besoffen? Wenn etwas stört ist es die Abwesenheit der
> Schnittstellen. Dann muss man nämlich die Funktionalität in Software
> nachbauen und stößt auch hier garnicht so selten auf die Macht der
> Echtzeit...

Jetzt schwurbel hier mal nicht wieder rum! Sondern genehmige dir 
vielleicht selbst mal einen Tomatensaft....hilft auch gegen 
Pickel...also verpickeltes Gesicht und so...
Gruß Rainer

Rainer V. schrieb:
> Natürlich macht Assembler Freude und auf so einem "kleinen" brauchts zum
> Verrecken kein float! Und ein 4-zeiliges LCD-Displ. und ein paar Taster
> oder so sind mit einigen wenigen Zeilen voll eingebunden.
> Was will man mehr auf dieser Ebene?

Vielleicht ein Problem lösen?

S. R. schrieb:
> Vielleicht ein Problem lösen?

Ja, Toll!

Ist jetzt fast wieder zu blöd...wer in Teufels Namen versucht ein 
Nasa-Programm auf einen Attiny zu "downgraden", übrigens tolles Wort! 
Kein Mensch. Kein Mensch!!!

c-hater schrieb:
> c-hater

Ich glaube, wenn ich mir die Bemerkung erlauben darf, du hast noch nie 
in einem Festzelt einen auf die Nuss gekriegt...wär aber angebracht...
Gruß Rainer

c-hater schrieb:
> Du bist scheinbar zu blöd, zu begreifen, dass sowas eben ein
> "downscaling" auf einen kleinereren Controller begrenzen kann.

Der fehlende Hardware-Multiplier aber ganz sicher nicht. Arithmetik auf 
8-Bittern läuft eigentlich immer darauf hinaus, daß man die Bits 
händisch durch die Gegend schiebt. Und eine 64x64 Multiplikation braucht 
kaum mehr Code als eine 32x32. Nur mehr Zeit.

Falls das ein Problem wird, dann ist man mit einem 8-Bitter (vollkommen 
egal ob ATMega oder ATTiny) aber sowieso falsch. µC mit breiteren ALUs 
existieren ja. Auch Hardware Floating-Point Arithmetik kriegt man für 
kleines Geld. Die ganze Diskussion ist müßig.

c-hater schrieb:
> Naja, Ähnlichkeit ist relativ...

Doch, sind beide schwarz.
SCNR
Von ehajo gibt es einen günstigen und der ist auf jeden Fall mit dem 
Studio kompatibel.
Ich habe auch den ICE, aber die Atmel sourcen nicht die Controller (aus 
gutem Grund), daher ist der von ehajo oft praktisch, wenn man mal im 
Bett, Sessel oder auf der Couch programmieren will.
Für mich auch die einzige sinnvolle Alternative, weil der auch TPI kann.
Bis vor kurzem las ich, dass das Pickkit4 noch nicht so funktionieren 
soll.
Willst du auf Nummer Sicher gehen, nimm den ICE.

Axel S. schrieb:
> Der fehlende Hardware-Multiplier

Der ist bei den neueren ATtiny-Mikrocontrollern vorhanden.

... das ist ja jetzt wieder in eine "Glaubensfrage" ausgeartet, nach dem 
besseren Chip, nach der besseren Programmiermethode, sogar Assembler 
wurde wieder ins Spiel gebracht.

Die Frage war, ob man einen ATtiny2313 über einen Arduino flashen kann.

Stephan hat es gesagt:

Ja das geht.

Stimmt bedingt, denn:

Er ist flashbar, aber die neueren Versionen von Atmel Studio wollen 
einen originalen Programmer sehen (leider).

Das heißt:

Der TO kann mit dem Studio Code für den ATtiny erzeugen, aber das 
Flashen geht aus dem Studio heraus nur mit Aufruf externer Programme 
(und ist umständlich).

Ich persönlich verwende zum Programmieren das Betriebssystem Linux und 
einfache Texteditore, die in der Lage sind, ein Makefile aufzurufen.

Das ist unter Windows nicht so ganz einfach, hier muß man die binutils 
(eben für make) installieren.

Für den TO würde das bedeuten, er erstellt Code mit dem Studio und in 
der Eingabezeile muß er diesen Code händisch in seinen Controller 
schieben (hier ist es schlicht egal, ob er einen ATtiny oder ATmega 
verwendet, für den Arduino UNO gibt es ISP Programme die eben in der 
Lage sind, alle AVR zu flashen, die mit dem ISP Protokoll geflasht 
werden können. Die neueren haben ein anderes Interface).

Für den Fall, dass er den Arduino als Programmer verwenden will, sollte 
er sich ein AVRDUDE installieren, oder den Suchpfad (wenn er Arduino 
Framework installiert hat) um den Pfad erweitern, in dem das 
Arduino-Framework den AVRDUDE abgelegt hat.

Prinzipiell ist ein Arduino UNO nichts anderes als ein einfacher 
ATmega328, der auf der Platine eine USB2UART Brücke mit drauf hat (im 
vom TO verlinkten Artikel ist das ein CH340G - Chinaware halt).

Desweiteren hat der UNO einen Bootloader installiert, der die Daten von 
der USB2UART Brücke entgegen nimmt (und somit einen externen Programmer 
unnötig macht).

Dieses Teil ist absolut auch ausserhalb von Arduino flashbar:

avrdude -c arduino -p atmega328p -P comx -b 115200 -B1 -V -U 
flash:w:meinprogramm.hex

Anmerkung: comx bezeichnet hier den Anschluss der virtuellen seriellen 
Schnittstelle, die Windows dem Arduino zuweist.

Wie Stephan oben besschrieben hat, kann über das Arduino-Framework aus 
den Beispielprogrammen der Arduino zum Programmer gemacht werden. Jedoch 
gibt es für den ATmega328p bessere Programme (eines habe ich hier 
angefügt).

Mit:

avrdude -c arduino -p atmega328p -P comx -b 115200 -B1 -V -U 
flash:w:avrstk500v2.hex

wird der Arduino zum STK500v2 Programmer.

Ein Uppload mittels des Arduino-Programmers erfolgt dann mit:

avrdude -c stk500v2 -p atmega328p -P comx -b 115200 -B1 -V -U 
flash:w:mytinyprogram.hex

Ein kleines "Problem" hierbei besteht darin, dass Avrdude beim Start den 
Arduino resetet und der Arduino als Programmer nicht sofort antwortet, 
weil nach einem Reset des Arduino dieser erst in sein Bootloaderprogramm 
springt.

Avrdude wird also warten, zeigt als erstes einen Timeout an und beim 
zweiten Versuch (nach dem die Bootloaderwartezeit des Arduino abgelaufen 
ist) wird der Flashvorgang gestartet.

Dieses Verhalten kann man abstellen, in dem man den Arduino um eine 2 
polige Jumeperreihe erweitert und diese an der Leiste bei Reset und 3,3V 
einlötet.

Steckt man nun auf diese Reihe einen Kurzschlussjumper, wird ein Reset 
des Arduino unterbunden und das Flasherprogramm startet unverzüglich 
(soll der Arduino mit einem anderen Programm als der STK500v2 Firmware 
geflasht werden, ist der Jumper zu entfernen).

Vielleicht sollte der TO auch über die Anschaffung eines USBasp oder das 
ISP-Shield nachdenken:

https://www.ebay.de/itm/AVR-ISP-Shield-Burning-Burn-Bootloader-Programmer-for-Arduino-UNO-R3/262793641460?hash=item3d2fb8bdf4:g:p6sAAOSwL~hbNZGn

Hier kann über ein 6 pol. ISP Kabel jeder AVR programmiert werden (oder 
man bestückt die 10 pol. Pfostenreihe für ein 10 pol. Kabel).

Prinzipiell würde ich dem TO aber empfehlen, einmal über Linux (vllt. 
auch nur eine LIVE Distribution) nachzudenken und dort eben den AVR-GCC 
und den AVRDUDE zu installieren, sowie einen Texteditor nach Wahl (GEANY 
eignet sich hervorragend).

Aber wie gessagt: 1000 Wege führen nach rom.

Hallo,
Ralph S. schrieb:
> Prinzipiell würde ich dem TO aber empfehlen, einmal über Linux (vllt.
> auch nur eine LIVE Distribution) nachzudenken und dort eben den AVR-GCC
> und den AVRDUDE zu installieren, sowie einen Texteditor nach Wahl (GEANY
> eignet sich hervorragend).

Das alles geht genau so gut unter Windows (genau diese Konfiguration 
verwende ich unter Win10), dafür muss man sich nicht noch zusätzlich in 
ein neues Betriebssystem einarbeiten.

rhf

Roland F. schrieb:
> Das alles geht genau so gut unter Windows (genau diese Konfiguration
> verwende ich unter Win10), dafür muss man sich nicht noch zusätzlich in
> ein neues Betriebssystem einarbeiten.

Ich habe nicht gesagt, dass das nicht funktioniert (ich hatte ja auch 
geschrieben, was man da alles machen muss).

Die Installation unter Win ist etwas schwieriger (okay nicht richtig 
schwierig), aber bis alles läuft ist es ein kleiner Weg dahin (und nicht 
so einfach wie: Atmel Studio installieren und fertig).

Unter Linux ist das wirklich einfacher das ans Laufen zu bekommen.

Auch wirklich "einarbeiten" in ein neues Betriebssystem ist nicht so arg 
(um damit einen Controller programmieren zu können).

Was man hier dann wissen sollte ist wenn man bpsw. auf der Konsole 
arbeitet:

- Bedienung des Midnight Commanders
- Wissen, was Verzeichnisse sind (kein Spaß jetzt, einige Auszubildende 
haben das Anfangs nicht drauf).
- Wissen, dass Verzeichnisse und Unterverzeichnisse mit einem / und 
nicht mit einem \ getrennt sind.

Das reicht dann schon für den Anfang.

In der Ausbildung wird das in einer VM gestartet und bisher hatte keiner 
nennenswerte Probleme damit (allerdings bekommen die das fertige System 
aufgesetzt)

Das verwendete Live-Linux ist Porteus.

Okay, jetzt bin ich auch vom originalen Threadthema abgewichen... Sorry

Hallo,
Ralph S. schrieb:
> (allerdings bekommen die das fertige System aufgesetzt)

Pfuscher :-))

> Okay, jetzt bin ich auch vom originalen Threadthema abgewichen... Sorry

Macht nix.

rhf

Ralph S. schrieb:
> Aber wie gessagt: 1000 Wege führen nach rom.

... und der TO ist wahrscheinlich schon längst auf dem Weg in irgendeine 
Wüste oder weil ihm das zu viel wird, hat er das Häkeln oder stricken 
angefangen.
Er ist auf jeden Fall nicht mehr hier.

F. F. schrieb:
> Er ist auf jeden Fall nicht mehr hier.

Ich hoffe, er trinkt jetzt irgendwo ein Bier...

F. F. schrieb:
> hat er das Häkeln oder stricken angefangen.

...macht auch Spaß. Beruhigt ungemein, wenn man krank ist und geistig 
gerade nix auf die Reihe kriegt.

Ralph S. schrieb:
> Unter Linux ist das wirklich einfacher das ans Laufen zu bekommen.
>
> Auch wirklich "einarbeiten" in ein neues Betriebssystem ist nicht so arg
> (um damit einen Controller programmieren zu können).

Ein Ami fragt zwei Leute um Hilfe, komplizierte Sache.
Der eine ist Deutscher, spricht leidlich Englisch, hat etwas Ahnung.
Der Andere ist Chinese, kennt sich super aus, spricht aber fast kein 
Englisch.
Der Deutsche:" Also, ich versuche es mal..."
Der Chinese:" Lern erstmal Chinesisch, dann kann ich das super 
erklären!"

Um einen T2313 über Arduino zu programmieren mit Linux anfangen? So ein 
Unsinn habe ich selten gelesen.

Gruß,
Norbert

Roland F. schrieb:
> Ralph S. schrieb:
>> (allerdings bekommen die das fertige System aufgesetzt)
>
> Pfuscher :-))

... Boah ey ...  :-))

F. F. schrieb:
> ... und der TO ist wahrscheinlich schon längst auf dem Weg in irgendeine
> Wüste oder weil ihm das zu viel wird, hat er das Häkeln oder stricken
> angefangen.
> Er ist auf jeden Fall nicht mehr hier.

Wie so oft... leider

Norbert S. schrieb:
> Um einen T2313 über Arduino zu programmieren mit Linux anfangen? So ein
> Unsinn habe ich selten gelesen.

Aha !!!

Vielleicht sollte man dann gleich sagen: um Mikrocontroller zu 
programmieren ist Linux Unsinn?

Der Arduino wäre in diesem Falle einfach nur ein Stück Hardware, ein 
Developmentboard und mehr nicht. Das Arduino Board würde einfach nur 
verwendet werden, weil es vorhanden ist.

Unter Linux hast du noch die Möglichkeit (und zwar so richtig gut), das 
Zusammenspiel von Compiler, Linker und Linkerscript zu zeigen und zu 
erklären und deine Software so anzupassen wie du das möchtest. Hierbei 
entwickelt sich ein Verständnis, das man dann gut gebrauchen kann, wenn 
man eine IDE (unter welchem System auch immer) einrichtet.

Das geht zwar unter Windows auch, aber eben nicht so gut.

Unter Windows ist es immer das gleiche: Ich klatsche gigabyteweise eine 
IDE auf die Platte die so ziemlich alle Controller einer Familie 
unterstützen oder eben ein irres Paket namens Atmel Studio (auch kein 
Speichersparexperte) um einen kleinen 2 kByte großen Controller zu 
programmieren?

Ich mag hier absolut keinen Glaubenskrieg um Windows und Linux anfangen, 
Tatsache jedoch ist, dass die Unterwiesenen, die ausnahmslos alle zuvor 
kein Linux in den Händen hatten (weil privat alle Gamer sind) für 
Mikrocontrollerprogrammierung dann das Linux genommen hatten.

Sei es in einer VM, in einer zweiten Partition oder als bootbarer 
USB-Stick.

Im Übrigen: einige der Bastler basteln auch mit einem Raspberry Pi, den 
sie bisweilen auch mit einem AVR kombinieren.

Spätestens beim Raspberry musst du dich mit Linux auseinander setzen.

Es also als abwegig hinzustellen, ein ATtiny2313 Programm unter Linux zu 
entwickeln zu wollen? Das finde ICH dann schon etwas... sagen wir : 
merkwürdig.

Ralph S. schrieb:
> Der Arduino wäre in diesem Falle einfach nur ein Stück Hardware, ein
> Developmentboard und mehr nicht. Das Arduino Board würde einfach nur
> verwendet werden, weil es vorhanden ist.

Ohne Arduino hätte ich nach ganz kurzer Zeit alles in die Ecke geworfen.
Nicht weil ich zu blöd bin.
Es braucht alles sehr viel Zeit und die hat im Normalfall kein 
arbeitender Mensch und erst recht nicht, wenn auch noch Familie dabei 
ist.

Dazu kommt, Arduino ist auch erstmal ein günstiger Einstieg.
Makefile und so ein Zeug, das ist doch alles viel zu schwierig für den 
Anfang.
Cortex für Anfänger?
Erstmal 2000 Seiten lesen und auch noch verstehen. Arduino ist ein guter 
Einstieg.
Die Unkenrufer können in den Werbepausen ja gerne zum Fernseher hin 
gehen und von Hand umschalten.
Ich weiß, der Vergleich hinkt, aber er ist eine gute Metapher.

Moin,

Einen AVR8 mittels Arduino als STK500 mit Avrdude zu programmieren ist 
Pipifax unter Windows.
Da schreibt man sich einmal eine Batch mit den Fuses drin und fertig.
Das hat man mit Avrdude-Hilfe in nullkommanix selbst erstellt.
Wie man sein Hex oder Bin erzeugt ist dann egal.

"Gigabyteweise IDE"
Ja, natürlich geht das sparsamer. Klar, wenn man auf einem 500MHz 
Pentium III mit 8GB-Platte arbeiten will macht das Sinn.
Billige Laptops fangen inzwischen bei 500GB an, vielleicht 256GB, dann 
aber SSD. Da sind 1-2GB natürlich ganz schlimm.
Bascom ist aber z.B. auch erheblich sparsamer.

Wenn man nicht ausdrücklich alles von der Pike auf lernen will, 
interessiert

Ralph S. schrieb:
> das
> Zusammenspiel von Compiler, Linker und Linkerscript

doch längst keine Sau mehr. Zumindest im kommerziellen Bereich.
Der Bastler will vielleicht nur seinen LED-Cube zum Laufen bringen.
Da braucht keiner Linux.

Ja, für Raspi ist Linux sicherlich nützlich.
Man kann auch vorsorglich Chinesisch lernen, falls man da mal einen Job 
anfangen will. Chinesich kann nie schaden.

Gruß,
Norbert

Norbert S. schrieb:
> Da schreibt man sich einmal eine Batch mit den Fuses drin und fertig.

Viele kennen weder ne batch noch wissen sie im Anfang wo diese 
"Sicherungen" in diesem kleinen Controller sein sollen.
Mit vollen Hosen ist gut stinken.
Wenn jemand, bar jeder Ahnung, damit anfangen will, auch noch keine oder 
wenig Ahnung von Elektronik hat, dann weiß der erstmal gar nichts und 
muss 1000 Sachen auf einmal lernen.

F. F. schrieb:
> Norbert S. schrieb:
>> Da schreibt man sich einmal eine Batch mit den Fuses drin und fertig.
>
> Viele kennen weder ne batch noch wissen sie im Anfang wo diese
> "Sicherungen" in diesem kleinen Controller sein sollen.
> Mit vollen Hosen ist gut stinken.
> Wenn jemand, bar jeder Ahnung, damit anfangen will, auch noch keine oder
> wenig Ahnung von Elektronik hat, dann weiß der erstmal gar nichts und
> muss 1000 Sachen auf einmal lernen.

Wenn man keine Batch kennt soll man das also lieber mit Linux machen?

Ja dann eben komplett über das Atmel Studio!
Da steht dann wenigstens was die Fuses bedeuten.
Wenn es dazu nicht reicht muss man es eben bei Arduino belassen.

Mit Linux und dem Kram zufuß wird das garantiert nicht einfacher.
Letztere Tips kommen immer von Leuten, die eine Konsole und Tastatur als 
das einzig Wahre empfinden und für die eine Maus schon dekadent ist.

Gruß,
Norbert

Ne, auf keinen Fall mit Linux. Und klar mit dem Studio.
Ich schrieb ja, als "Einstieg".

Ralph S. schrieb:
> Das geht zwar unter Windows auch, aber eben nicht so gut.

Unter Windows ist es erst recht popeleinfach.
Du mußt nur den WINAVR von 2010 installieren, da ist alles drin, auch 
die Binutils.
Du kannst dann wählen, ob Du Make benutzen willst oder eine Batch. In 
der Batch übergibst Du dem AVR-GCC *.c, dann compiliert und linkt er 
alle C-Files im aktuellen Verzeichnis.

https://sourceforge.net/projects/winavr/files/WinAVR/20100110/

F. F. schrieb:
> Ohne Arduino hätte ich nach ganz kurzer Zeit alles in die Ecke geworfen.
> Nicht weil ich zu blöd bin.

Genau dafür ist Arduino gut geeignet...

Wer bei Arduino-Framework stehen bleibt ist selbst schuld.

F. F. schrieb:
> Dazu kommt, Arduino ist auch erstmal ein günstiger Einstieg.

Absolut richtig !

F. F. schrieb:
> Erstmal 2000 Seiten lesen und auch noch verstehen. Arduino ist ein guter
> Einstieg.

Das Datenblatt eines ATmega328 (habe ich gerade nachgesehen) hat 294 
Seiten, ich glaube nicht, dass du diese gelesen hast (was besser wäre).

Keiner verlangt, dass man ein Datenblatt am Stück liest. Das Datenblatt 
ist dafür da, um für ein Problem das man hat, genau dort nachzulesen wie 
man es lösen kann.

Norbert S. schrieb:
> Da schreibt man sich einmal eine Batch mit den Fuses drin und fertig.

Batch-Files habe ich vor 20 Jahren gemacht und ist gelinde gesagt bei 
weitem nicht so flexibel wie das ein Makefile ist.

Norbert S. schrieb:
> Billige Laptops fangen inzwischen bei 500GB an, vielleicht 256GB, dann

Speicher alleine ist es nicht, in meinem Rechner werkelt ein Ryzen 5 der 
normalerweise ausreichend schnell ist. 2 Festplatten, auf einer Linux 
(mit dem der Rechner normalerweise gestartet wird) auf der anderen 
(noch) ein Win7 (auch mit einem Atmel-Studio).

Alleine die Startzeit bis das einsatzfähig ist... fürchterlich. Dazu 
kommt 1000 Klicks bis ich das eingestellt habe, was mein Projekt so 
benötigt. Für Bibliotheken die hinzugelinkt werden sollen suche ich 
immer in den Menüs bis ich den Punkt habe.

Norbert S. schrieb:
> Ralph S. schrieb:
>> das
>> Zusammenspiel von Compiler, Linker und Linkerscript
>
> doch längst keine Sau mehr. Zumindest im kommerziellen Bereich.

Mann, Mann, Mann..... GERADE im kommerziellen Bereich interessiert 
dieses Zusammenspiel gewaltig. Natürlich muß das keine 
Editor-Compiler-Linker Kombination sein, wenn du aber nicht weißt wie 
das ineinandergreift wirst du niemals effizient etwas erstellen, egal 
mit welcher IDE / Toolchain auch immer.

Wer diese Zusammenhänge versteht programmiert JEDEN Controller egal 
welcher Familie ... und richtet sich auch seine Umgebung selbst ein.

Norbert S. schrieb:
> Letztere Tips kommen immer von Leuten, die eine Konsole und Tastatur als
> das einzig Wahre empfinden und für die eine Maus schon dekadent ist.

Meine Güte... ich arbeite zwar super gerne auf der Konsole und habe mir 
dafür extra den Editor aus FreePascal extrahiert (damit ich wie anno 
dubak mit Borland C / C++) werkeln kann, aber dort kommt auch eine Mouse 
zum Einsatz. Wenn das Projekt eine gewisse Größe hat ist es Geany (und 
das unter Linux UND Windows).

Aber in allen Fällen mit MAKE

Norbert S. schrieb:
> Ja, für Raspi ist Linux sicherlich nützlich.

Das ist dort nicht nützlich, das ist dort zwingend notwendig (es sei 
denn du möchtest den Raspi Bare Metall programmieren - was ich bezweifle 
- denn das ist dann wirklich harter Tobak).

Peter D. schrieb:
> Du mußt nur den WINAVR von 2010 installieren, da ist alles drin, auch
> die Binutils.

Mensch Peter... du empfiehlst wirklich eine 10 Jahre alte Toolchain 
(meines Wissens wird dort sogar noch die alte Notation der 
Interrupt-Service-Routinen verwendet)...

So, und jetzt "schieße" ich mal etwas zurück:

Diejenigen, die so gänzlich Betriebsblind sind, nicht über den 
Tellerrand hinausschauen sind diejenigen, die als alleinige Gottheit 
Windows ansehen und als super Entwicklungssystem Arduino.

DAS sind meistens die, die nicht wissen wovon sie reden. Die verwenden 
Batch-Files zum Erstellen einer Toolchain weil sie meistens zu faul 
sind, sich in die Makefiles einzuarbeiten.

Unglaublich... wie engstirnig manche sein können (oder "Angst" haben). 
Bevor sie sich etwas ansehen oder ausprobieren wird schlicht gesagt: Zu 
umständlich, zu schwierig oder braucht man nicht.

Um mal zu demonstrieren wie "einfach" etwas mit einem Makefile gemacht 
werden kann (egal ob unter Windows oder unter Linux):

Datei makefile.mk ist der "funktionale" Teil eines Makefiles, der vom 
regulären Makefile eingebunden wird. Dieser Teil muss nicht zwingend 
"verstanden" werden um in reinem C ein AVR Programm zu schreiben. Es 
unterstützt Programmer für: usbasp, usbtiny, stk500v2, arduino, avrisp 
und sogar das alte ponyser. Für 95% aller meiner Fälle reicht dieser 
funktionale Teil aus (mal im Anhang hier gepostet).

Dann braucht es eine Verzeichnisstruktur (beispielhaft):

1

  ~/avrproj

2

      |

3

      - myproj

4

      |

5

      - include

6

      |

7

      - src

8

      |

9

      makefile.mk

In ./include sind alle Header von selbstgeschriebenen (oder selbst 
kopierten) "Bibliotheken" (so man von Bibliothek in Verbindung von .c 
und .h Pärchen reden will).

In ./src sind die dazugehörenden Quellcodes

Tja und in ./myproj das Programm, das ich erstellen mag. In diesem 
Ordner legt man dann ein Makefile ab, das so aussieht:

1

###############################################################################

2

#

3

#                                 Makefile

4

#

5

#   einfaches Makefile zum "builden" von HEX-Dateien fuer Atmel (c) AVR-

6

#   Mikrocontroller.

7

#

8

#

9

#

10

#   Mai 2017,  R. Seelig

11

#

12

###############################################################################

13

14

15

PROJECT           = serial_demo

16

17

SRCS              = ../src/uart.o

18

SRCS             += ../src/my_printf.o

19

20

INCLUDE_PATHS     = -I. -I../include

21

22

23

PRINTF_FL         = 0

24

SCANF_FL          = 0

25

MATH              = 0

26

27

# fuer Compiler / Linker

28

FREQ              = 16000000ul

29

MCU               = atmega328p

30

31

# fuer AVRDUDE

32

PROGRAMMER        = usbasp

33

SERPORT           = 

34

BRATE             = 

35

DUDEOPTS          = B1

36

37

38

include ../makefile.mk

So, das wars. Im obigen Makefile wird das Programm, dass die main 
beinhaltet übersetzt (hier serial_demo.c). Dieses Programm benötigt 
zusätzlichen Quellcode, der im Ordner ../src liegt (die als Dateien 
uart.c und my_printf.c vorliegen müssen). Diese zusätzlichen Dateien 
übersetzt das Makefile in Objektfiles ( .o). Gleichzeitig linkt das 
Makefile alle beteiligten Dateien zu einem Paket zusammen...

Quintessenz:

Im Makefile den Projektnamen angeben und die benötigten Dateien... Ende.

Und auch hierfür habe ich mir einen "Makefilegenerator" geschrieben (der 
auch mit der Mouse bedient wird)... so in Anregung an das berühmte mfile 
von Jörg W.

In diesem Stile habe ich für alle die von mir benutzten Controller ein 
solches "Makefile - Template"... die da sind MCS-51, PIC16F, STM8, AVR, 
MSP430, STM32 und NXP.

Das ist so einfach, dass ich manchmal "nachsehen" muss, auf welchem 
Controller ich mich bewege (weil ich logischerweise den Bibliotheken und 
die Funktionsnamen alle gleich benannt habe).

Wo bitte ist es also schwierig, ausserhalb von Arduino etwas zu 
bewerkstelligen.

Selbst unter Linux sollte es einem Einsteiger möglich sein, 
Verzeichnisse anzulegen und sich dorthin ein paar Dinge zu kopieren.

Wie man einen AVR-GCC und einen ARM-NONE-EABI-GCC und einen SDCC 
installiert... dafür gibts nun wirklich zig Anleitungen.

--------------------------------------

Ergo haut man immer wieder drauf, wenn man nichts anderes kennt als das 
was man kann.

--------------------------------------

Aber den Spruch, dass das keine Sau mehr interessiert und schon gar 
nicht kommerziell finde ich klasse: Erzähle das bitte meinem Chef und 
dann bauen wir nur noch Geräte mit Arduino. Für den STM32 wirds 
schwierig, weil die Nucleo- und Discoveryboards nicht kommerziell 
eingesetzt werden dürfen.

--------------------------------------

Im Übrigen bin ich dabei, aus einer Porteus-Live-Distribution ein 
ISO-Image zu kreieren, das nur auf einen Stick geklatscht werden muss. 
Den Rechner hiervon booten, den Makefilegenerator benutzen und mit einem 
Editor der Wahl (hier entweder Geany oder auf der Konsole den FreeVision 
Editor - der genau so aussieht wie der Turbo Vision Ediotr von Borland C 
/ C++). Code schreiben und fertig.

Kein Installieren einer IDE, kein Installieren einer Toolchain, kein 
Durchkämpfen von 1000 Menüs.

--------------------------------------

Zurück zum Thema: Hätte der TO das bei mir vorliegende System, würde er 
einen ATtiny2313 über ein Arduino-Board in 5 Minuten programmieren (und 
ich schreibe hier extra nicht Arduino, weil ich hier die Software nicht 
meine).

Im übrigen habe ich auch noch ein Flasherprogramm für AVR das sich 
TUIDUDE nennt und das genau so aussieht, wie die "Oberfläche" für mein 
Flashershield in

https://www.mikrocontroller.net/attachment/376277/flashershield_with_pic16f676.png

Natürlich wieder ein Konsolenprogramm, aber unterm Strich ist es 
vollkommen Wurst, ob ich mit der Mouse grafische Buttons oder 
Textmodebuttons klicke solange der Effekt der gleiche ist.

Schönen Gruß,
JJ

PS: an Stefan. Ich glaube ich werde mal zählen, wie oft du hier Werbung 
für dein "Buch" machst. Ich habe es gelesen, ich habe es sogar meinen 
Lehrlingen gezeigt. Das habe ich gemacht, weil ich wissen wollte, ob 
jemand, der am Anfang steht damit etwas anfangen kann.

Ralph S. schrieb:
> Keiner verlangt, dass man ein Datenblatt am Stück liest. Das Datenblatt
> ist dafür da, um für ein Problem das man hat, genau dort nachzulesen wie
> man es lösen kann.

Jaein. Man muss aber schon recht viel Hintergrundwissen haben, um aus so 
einem Datenblatt die relevanten Informationen rauspicken zu können.

Mal so ein Datenblatt komplett gelesen zu haben ist dabei äußerst 
hilfreich. Und da sind kleinere Controller wesentlich nützlicher als die 
großen Maschinen.

Ralph S. schrieb:
>>> das Zusammenspiel von Compiler, Linker und Linkerscript
>> doch längst keine Sau mehr. Zumindest im kommerziellen Bereich.
>
> Mann, Mann, Mann..... GERADE im kommerziellen Bereich interessiert
> dieses Zusammenspiel gewaltig.

Jaein. Hängt von der Umgebung ab. Das Gradle-Buildsystem ist z.B. so 
dermaßen komplex, dass in der Android-Welt eigentlich niemand etwas 
anderes benutzt als die von Google vorgegebene Android Studio-Umgebung. 
Leider.

Und an CMake stört mich halt in erster Linie, dass es nicht so flexibel 
einsetzbar ist wie klassische Makefiles - aber dafür ist es portabler 
und weniger Arkanmagie. (Und ja, ich schreibe auch viele Makefiles von 
Hand.)

Ralph S. schrieb:
> F. F. schrieb:
>> Erstmal 2000 Seiten lesen und auch noch verstehen. Arduino ist ein guter
>> Einstieg.
>
> Das Datenblatt eines ATmega328 (habe ich gerade nachgesehen) hat 294
> Seiten, ich glaube nicht, dass du diese gelesen hast (was besser wäre).

Ralph, lesen ist wohl nicht deine Stärke?
Zitieren garantiert nicht!
Außerdem, wieso willst du mich hier anpissen?

Ich bin nicht der TO und ich schrieb zum Einstieg. Vielleicht liest du 
vielleicht einmal ein paar Beiträge von mir. Zum Beispiel über ATTiny10.

F. F. schrieb:
> Ralph, lesen ist wohl nicht deine Stärke?

Na... wer will denn hier die "2000" Seiten Doku nicht lesen?

Ich hab die gelesen und wahrscheinlich noch ein paar Seiten mehr.

F. F. schrieb:
> Zitieren garantiert nicht!

Eigentlich doch, und manchmal sollten die Leute GENAU lesen. Das einzige 
was ich zu dir geschrieben habe war

Ralph S. schrieb:
> F. F. schrieb:
>> Ohne Arduino hätte ich nach ganz kurzer Zeit alles in die Ecke geworfen.
>> Nicht weil ich zu blöd bin.
>
> Genau dafür ist Arduino gut geeignet...
>
> Wer bei Arduino-Framework stehen bleibt ist selbst schuld.
>
> F. F. schrieb:
>> Dazu kommt, Arduino ist auch erstmal ein günstiger Einstieg.
>
> Absolut richtig !
>
> F. F. schrieb:
>> Erstmal 2000 Seiten lesen und auch noch verstehen. Arduino ist ein guter
>> Einstieg.
>
> Das Datenblatt eines ATmega328 (habe ich gerade nachgesehen) hat 294
> Seiten, ich glaube nicht, dass du diese gelesen hast (was besser wäre).

Hier gebe ich dir 2 mal Recht (was dann wohl sicher kein anpissen ist) 
und was die Sache mit dem Lesen betrifft: Du schreibst es so, dass man 
den Arduino als Einstieg nehmen soll und sich so das Lesen ersparen 
kann... das kann man nicht (und ich kann das auch nicht mehr hören... 
ohne Lesen erarbeitet man sich ein gefährliches Halbwissen).

F. F. schrieb:
> Ralph, lesen ist wohl nicht deine Stärke?
> Zitieren garantiert nicht!

Wer "pisst" hier jetzt wen an?

F. F. schrieb:
> Vielleicht liest du
> vielleicht einmal ein paar Beiträge von mir. Zum Beispiel über ATTiny10.

Warum sollte ich, der ATtiny10 interessiert mich nicht (und habe den nur 
einmal im Einsatz gehabt). Ohne deine Beiträge zu kennen: Bist du (ohne 
Ironie) so der Experte für AVR - ATtiny und deren effizienten 
Programmierung? Wenn ja, warum erachtest du es dann als notwendig auf 
deine Verdienste hinzuweisen?

Ralph S. schrieb:
> Batch-Files habe ich vor 20 Jahren gemacht und ist gelinde gesagt bei
> weitem nicht so flexibel wie das ein Makefile ist.

Das Gegenteil ist der Fall, die Möglichkeiten eines Make sind gegenüber 
einer Batch stark eingeschränkt. Z.B. kann ein Make keine Wildcards 
expandieren, Umgebungsvariablen setzen und manipulieren usw. Z.B. bilde 
ich mit Variablen aus der Versionsnummer Defines für den Compiler 
(String und int) und Filenamen für den Programmer (Hex-File).
Sucht man für bestimmte Aktionen in einer Batch Hilfe, findet man auch 
schnell dazu passende Antworten mit Google, z.B. bei Stackoverflow.
https://stackoverflow.com/questions/2591758/batch-script-loop

Für Make habe ich noch keine brauchbare Dokumentation gefunden, die über 
den Urschleim hinaus geht.

Ralph S. schrieb:
> Mensch Peter... du empfiehlst wirklich eine 10 Jahre alte Toolchain

Ein Compiler verschleißt nicht. Neuere Versionen mögen besser 
optimieren, aber das spielt nur selten eine Rolle.
Wenn Du eine Installation kennst, die ähnlich einfach, wie der WINAVR 
geht, dann nenne sie einfach.

Ralph S. schrieb:
> (meines Wissens wird dort sogar noch die alte Notation der
> Interrupt-Service-Routinen verwendet)...

Dann ist Dein Wissen falsch.

Stefan ⛄ F. schrieb:
> Den Umgang mit make und avrdude lernt man nicht in 5 Minuten. Gebe den
> Anfängern die nötige Zeit, du hattest sie auch damals.

Ein Anfänger bekommt alle Zeit der Welt, darum geht es doch gar nicht. 
Es geht auch nicht darum ob du Windows oder Linux verwendest. Das 
gleiche gilt für Batchfiles vs. Makefile.

Es geht darum zu sehen, dass dieses selbst heute noch notwendig ist und 
der Gebrauch hiervon notwendig ist.

Es geht darum, dass selbst die Arduino Software (wie viele andere IDE's 
auch) sich Kommandozeilentools wie AVR-GCC und AVRDUDE bedienen. In 
unflexibleren Programmen sind diese im Entwicklungsprogramm integriert.

Es geht darum, das Zusammenspiel der Toolchain zu verstehen. Dieses 
Verständnis nicht haben zu wollen oder zu glauben dass man das 
heutzutage nicht mehr braucht ist abwegig.

Für diejenigen, die einfache Dinge schnell lösen mögen ist das in 
Ordnung (das meine ich ohne Ironie), aber zu behaupten dass man das 
heutzutage nicht mehr braucht ist xyz.

Das ist das gleiche, als ob ich behaupten würde niemand müsse heutzutage 
mehr wissen wie ein Benzinmotor funktioniert, ich kann ja schließlich 
Auto fahren. Für denjenigen, der nur Auto fahren möchte ist das 
sicherlich richtig (aber irgendjemand hat ihm den Automotor konstruiert 
und gebaut).

Wenn ich in einer Schaltung einen Mikrocontroller einsetzen möchte, dann 
baue und konstruiere etwas.

Darüber, wie am einfachsten einem Anfänger etwas beizubringen ist, 
streiten sich die Götter (okay, die Experten) und oft muß man etwas 
vorsetzen, dass sich erst mit dem Gebrauch im Laufe der Zeit erschließt.

Welches der didaktisch richtige Weg ist, auch darüber streiten sich die 
Götter.

Ein Beispiel:

In deinem Buch beschreibst du extrem viel über einfachste Elektronik (in 
einer Sprache wie ich sie für Kinder verwende). Je nach gewünschter 
Zielgruppe ist das sicherlich auch richtig. Selbst hier könnte man 
fachlich noch etwas früher einsteigen und das Thema reicht alleine 
hierfür für mehr als ein Buch, oder es wird zumindest ein sehr dickes 
Buch.

Nach diesen Erläuterungen gehst du in eine gigantische IDE. Das ist 
okay, wenn man damit arbeitet oder arbeiten will.

Danach programmierst du eine Bluepill und machst dann etwas wie:

init_io(),

was ich als sehr richtig empfinde. Jedoch schreibst du nirgendwo zu 
beginn, für was diese Funktion gut ist (und vor allem wie extrem wichtig 
die für deine Erläuterungen ist).

Danach folgen bei dir quer Beet Programmbeispiele, was auch okay ist, 
aaaaaaaaber bei den Erklärungen wird es haarig.

Irgendwo schreibst du etwas übers maskieren, aber nirgendwo, etwas 
darüber, dass diese für ein gezieltes Setzen und Löschen von Bits sind 
und dass für das Setzen eines Bits eine ODER Maske und das Löschen eine 
UND Maske verwendet wird und warum das so ist.

Außerdem setzt du komplett die digitale Logik vorraus, was dann nicht 
mehr zu der Zielgruppe er einfachsten Anfänger passt.

Danach verwendest du (logsicherweise) die Register um mit dem Baustein 
etwas anfangen zu können, aber nirgendwo steht beschrieben, was Register 
eigentlich sind.

Du schreibst bspw. so etwas:

Befehl zum Einschalten der roten LED lautet:
WRITE_REG(GPIOC->BSRR,GPIO_BSRR_BR13);

Aus dieser Zeile wird keinem (zumindest keinem Anfänger klar) was mit 
dem Register passiert und was die Zeile macht. Wer dieses Wissens-Level 
hat braucht bspw. eine Eingangserklärungen nicht.

Der Erfolg des ARDUINO liegt u.a. darin begründet, dass solche 
Hardwaredinge im Stile von

pinMode(pinnr, OUTPU)
digitalWrite(pin, value)

gemacht wird (was einem Anfänger verständlich ist): Pin als Ausgang 
definieren und diesem Pin einen High- oder Lowlevel geben.

Ich würde somit bspw. einem Anfänger das init_io() geben, damit das 
System läuft und in einzubindenden Headerfiles Makros ablegen die dann 
etwas ähnliches wie Arduino machen, bspw.

PA5_INIT_OUTPUT
PA5_SET
PA5_CLR

Aber es gibt kein richtiger oder besser. Es dreht sich schlicht darum, 
welchen Anspruch der zu Unterweisende hat. Wenn er nur ein paar Pins 
wackeln lassen will, ist Arduino oder in Makros abgelegte 
Registerbeschreibungen der richtige Weg. Wenn er wissen will wie etwas 
funktioniert, ist der "Register Weg" der richtige.

AAAAABER: nichts ist obsolet, auch viele der Vorgehensweisen nicht, die 
man schon seit über 30 Jahren so macht.

Und nein, ich will dein Buch nicht kritisieren, ich finde es gut, wenn 
sich jemand die Mühe macht, einem Anfänger etwas erklären zu wollen.

Dewegen gilt meine Kritik hier NICHT dir.

Ich finde es aber nicht gut, wenn man einem Anfänger sagt: das brauchst 
du nicht zu wissen, das ist heute obsolet.

Ich erinnere mich noch sehr gut daran, wie ein Anfänger (der gerade 
einmal einen Arduino programmiert hat) die Frage stellt, wie er aus 
einer alten 386 CPU ein Board basteln kann. Das könne ja nicht so 
schwierig sein (und weiß noch nicht einmal den Unterschied einer CPU zu 
einer MCU).

Angesichts dessen, was heutige PC's können müsse es doch wohl lächerlich 
einfach sein, daraus etwas aufbauen zu können.

Demnach waren also alle Ingeneure der 80er und 90er Jahre also 
lächerlich, weil sie mit so etwas einfachem wie einem 386er heftige 
Entwicklungszeiten hatten.

Mit den Jahren habe ich immer größeren Respekt vor den Leistungen der 
"Alten" bekommen, bspw. eines Bresenham, eines Turing oder ganz alt, 
eines Carl Friedrich Gauß (dessen Wochentagsberechnungsformel noch 
allgegenwärtig ist).

Obsolet sind diese Dinge lange nicht.

Es soll, im Sinne der Zeit, immer einfach und schnell sein.

------------------------------------

Zurück zum Thema: wie man einem Anfänger also etwas erklärt ist 
ungeklärt. Einzig alte Dinge für obsolet zu erklären (nur weil sie alt 
sind) ist falsch. Alte Dinge erklären sehr oft Zusammenhänge

Ich hoffe sehr, dass sich einige Forumsteilnehmer nicht "angepisst" 
fühlen, das liegt nicht in meiner Absicht.

Ich werde selbst nur dann "pissen", wenn ich selbst angepisst werde. 
Jeder, mich natürlich eingeschlossen, hat das Recht etwas nicht zu 
wissen und zu fragen. Wenn man das allerdings tut, und fragt, dann 
sollte man sich Antworten auch anhören.

Ralph

PS: ich ärgere mich, dass ich mich ärgere.... und ich ärgere mich, weil 
ich soviel schreibe

Stefan ⛄ F. schrieb:
> Ralph S. schrieb:
>> Batch-Files habe ich vor 20 Jahren gemacht und ist gelinde gesagt bei
>> weitem nicht so flexibel wie das ein Makefile ist.
>
> Das bezweifle ich.

Das Wort "flexibel" ist etwas unglücklich gewählt.

> Beim Makefile kannst du nur das machen, was in make vorgesehen war.
> Batch Files (ich gehe mal davon aus, dass du konkret welche für CMD.EXE
> oder Bash meinst) können hingegen prinzipiell alles, was die
> Kommandozeile des Betriebssystems hergibt. Das ist definitiv mehr, als
> was make kann

Nein. Von einem Makefile aus kannst du natürlich ebenfalls alles, was 
du auf der Kommandozeile kannst. Du hast noch nie ein Makefile genauer 
angesehen oder gar eins geschrieben, stimmts?

Der Vorteil von make gegenüber Batch-Files ist, daß make Abhängigkeiten 
prüft und so nach einer Änderung an einem oder wenigen Source-Files nur 
die Teile neu übersetzen muß, die davon betroffen sind. Make kann auch 
Parallelität (mehrere Compiler-Jobs laufen gleichzeitig).

Es sind diese beiden Punkte, die für mich make bei weitem überlegen 
machen. Der typische Entwickler-Zyklus "edit - build - test" muß dadurch 
nämlich deutlich weniger Zeit in "build" vertrödeln.


Peter D. schrieb:
> die Möglichkeiten eines Make sind gegenüber
> einer Batch stark eingeschränkt. Z.B. kann ein Make keine Wildcards
> expandieren, Umgebungsvariablen setzen und manipulieren usw.

Vielleicht wenn du irgendeine uralte oder halbherzige (Microsoft?) 
make-Implementierung betrachtest. GNU make kann all das. Und mehr.

Andererseits würde ich - wenn das Entwicklungssystem Windows sein müßte 
- statt make eher einen der designierten Nachfolger einsetzen. Z.B. ant. 
Das ist Java und damit portabel. GNU Software auf Windows ist ein 
Krampf. Die POSIX Infrastruktur von Windows ist so mangelhaft, daß man 
praktisch das ganze Userland mitbringen muß.

Axel S. schrieb:
> Von einem Makefile aus kannst du natürlich ebenfalls alles, was
> du auf der Kommandozeile kannst.

Das Problem dürfte sein, daß dann Make für jedes Kommando eine Instanz 
der CMD.EXE startet. D.h. geänderte Umgebungsvariablen sind nach dem 
Aufruf wieder ungültig.
Wie kann man in einem Make auf Umgebungsvariablen zugreifen, z.B. einem 
Define übergeben, vergleichen, setzen oder damit rechnen?
Wie programmiert man Schleifen oder expandiert Platzhalter im Make?

Axel S. schrieb:
> Du hast noch nie ein Makefile genauer
> angesehen oder gar eins geschrieben, stimmts?

Anbei mal eine Batch, die ein Makefile erzeugt und dann ausführt.
Das ist für den Jenkins build server.

Ralph S. schrieb:
> Es geht darum, das Zusammenspiel der Toolchain zu verstehen. Dieses
> Verständnis nicht haben zu wollen oder zu glauben dass man das
> heutzutage nicht mehr braucht ist abwegig.

Das hängt von der Umgebung ab. Wenn man C/C++ auf Mikrocontrollern 
macht, dann ist es nützlich (aber nicht notwendig), davon zu wissen. Der 
Peter'sche "installiere WinAVR und drücke auf Play"-Weg funktioniert 
aber auch. Es muss nur klar sein, dass man sich damit auf eine bestimmte 
Umgebung festlegt. In den meisten Fällen ist das aber entweder egal oder 
sowieso der Fall.

Mehr machen wir mit Android Studio auch nicht. Die Umgebung ist von 
außen vorgegeben und davon abzuweichen ist mir viel Arbeit und hohen 
Maintenance-Kosten verbunden. Das gilt auch für die meisten 
Web-Umgebungen wie z.B. Node.

Wenn man "ambitionierter Anfänger" ist, dann stolpert man da irgendwann 
von alleine drüber und muss dann die Entscheidung treffen, da Zeit zu 
investieren. Und wenn man es nicht tut, dann bricht auch keine Welt 
zusammen.

Ralph S. schrieb:
> Ich finde es aber nicht gut, wenn man einem Anfänger sagt: das brauchst
> du nicht zu wissen, das ist heute obsolet.

Die arkane Wissenschaft von HMA, EMS und XMS sowie die Beschränkungen 
des Real Mode unter DOS mit den Besonderheiten verschiedener 
DOS-Extender ist... obsolet. Muss man nicht mehr wissen, sofern man 
nicht digitale Archäologie betreibt.

Peter D. schrieb:
> Wie kann man in einem Make auf Umgebungsvariablen zugreifen, z.B. einem
> Define übergeben, vergleichen, setzen oder damit rechnen?

Man kann mit $(VARIABLE) auf Umgebungsvariablen zugreifen. Das folgende 
Makefile gibt ":0.0" aus, wenn man "make" aufruft (unter Linux):

1

all:

2

        echo $(DISPLAY)

Umgebungsvariablen kann man schon setzen, man muss nur auf den richtigen 
Kontext achten. Der typische Weg ist, dass man z.B. sowas macht:

1

VER = "1.0"

2

SETTING=true

3

4

out.o: out.c

5

  ZEUGS=$(SETTING) $(CC) -DVER=$(VER) -c -o $@ $<

Das führt bei mir sowas aus:

1

  ZEUGS=true cc -DVER="1.0" -c -o out.o out.c

Das heißt, die Compiler-Instanz bekommt "ZEUGS=true" als 
Umgebungsvariable zugewiesen und die Versionsnummer wird per Define im 
Code bekanntgegeben. Wenn man die Variable nicht im Makefile definiert, 
wird die Umgebungsvariable benutzt, und wenn es die auch nicht gibt, ist 
das Ergebnis leer.

Peter D. schrieb:
> Wie programmiert man Schleifen oder expandiert Platzhalter im Make?

Hängt davon ab, was du eigentlich machen willst. Make kann über Listen 
iterieren. Platzhalter heißen im normalen Sprachgebrauch "Variablen" und 
werden wie alle anderen Variablen expandiert.

Sinnvollerweise listet man in einem Makefile alle zu erzeugenden Objekte 
auf, und schreibt für jedes Binary, aus welchen Objekten es erzeugt 
werden muss.

Beschäftige dich mal ein kleines bisschen tiefer damit, du könntest 
erstaunt sein. :-)

@svenska

Volle Zustimmung

@stephan

Stefan ⛄ F. schrieb:
> Mit ist nicht klar, worauf die dich da beziehst.
> Musst du aber nicht weiter erklären, wir können das gerne einfach offen
> lassen.

Können wir gerne offen lassen, weil nicht wirklich relevant. Das 
"obsolet" bezog sich definitiv nicht auf dich und ich hätte meine 
Antworten in meinem Post strikter trennen sollen.

DIR hatte ich das obsolet nicht unterstellt gehabt, du gehst ja auch 
einen anderen Weg (aus meienr Sicht der Dinge den richtigen): Weg von 
komplett vorgefertigtem hin zu eigenen Entwicklungen (auch wenn man 
hierbei das Rad öfters neu erfindet).

Dir ist postiv "anzuheften", dass du dich um wirklich jeden Anfänger 
bemühst und antworten gibst (sehr positiv)... und das auch mit einer 
großen Geduld.

Von daher zu obigen: können wir offen lassen!

Vllt. zu deinen "Büchern": Das größte Problem beim Schreiben eines 
Scriptes oder Buches ist es, dieses zu strukturieren (und das Problem 
habe ich auch). Prinzipiell sollte es (wie beim Programmieren) ein 
"Top-Down" Entwurf sein, das heißt: es gibt in Stichpunkten die Inhalte 
die der Text vermitteln soll, in einer so gut wie möglich gegliederten 
Ablauffolge.

Danach werden dann diese Stichpunkte mit "Text gefüllt" (ähnlich wie bei 
einem Programm, bei dem in einem Menü erst einmal alle Punkte aufgeführt 
sind, die das Programm beherschen soll. Ers anschließend werden die 
Menüpunkte mit Leben gefüllt).

Zu deinen Büchern: Vielleicht wäre es ratsam, wenn du die Elektronik 
unterteilst in: Elektronikperipherie (also OHNE Erklärungen zu 
Mikrocontroller, die du dort allerdings einsetzen kannst), bei denen du 
Strom, Spannung, Widerstand, Leuchtdioden, Kondensatoren etc. erklärst.

Dann einen Teil mit Digitalelektronik (auch noch ohne Mikrocontroller) 
bei der du die digitale Logik erklärst und vlt. noch Zähler, 
Schieberegister und dergleichen (um dann bei den Mikrocontrollern darauf 
zu verweisen, was ein interner Timer/Counter macht).

Und dann eben einen Teil, der sich mit Mikrocontrollern beschäftigt, 
erst einmal von einer Familie losgelöst (und so hoch abstrahiert wie es 
nur geht, ähnlich wie es Arduino macht) um dann auf die speziellen 
Eigenheiten des Controllers einzugehen?

Jaaaaaaa, ich weiß: abartig viel zu schreiben (und ich weiß es deshalb, 
weil ich seit 2 oder 3 Jahren versuche so etwas zu schreiben und es dann 
immer wieder verwerfe. Die Themen von Elektronik, Mikrocontroller und 
Programmierung sind einfach abartig vielschichtig).

Deshalb eben auch keine negative Kritik von mir an dir (smile, außer 
dass ich in bald jedem Thread wo du "mitmachst" den Verweiss auf deine 
Bücher lesen kann).

Es gibt so abartig viele Texte im Internet mit unterschiedlichen 
Qualitätsstufen und das schlimme daran ist, dass es oft auch (NICHT 
DEINE MEINE) in wirklich schlechten Texten (und teilweise auch 
fehlerhaften Texten) dann doch etwas gutes darin steht.

Die Kunst ist es (und für einen Anfänger schwierig zu erkennen), was gut 
und was nicht gut ist.

Peter D. schrieb:
> Axel S. schrieb:
>> Von einem Makefile aus kannst du natürlich ebenfalls alles, was
>> du auf der Kommandozeile kannst.
>
> Das Problem dürfte sein, daß dann Make für jedes Kommando eine Instanz
> der CMD.EXE startet. D.h. geänderte Umgebungsvariablen sind nach dem
> Aufruf wieder ungültig.

Nicht sicher ob ich dich richtig verstehe. Aber es scheint so, als 
möchtest du ein dynamisches Environment, das aufgerufene Programme auch 
verändern können?

> Wie kann man in einem Make auf Umgebungsvariablen zugreifen, z.B. einem
> Define übergeben, vergleichen, setzen oder damit rechnen?

Ein Makefile hat seine eigenen Variablen. Umgebungsvariablen aus dem 
Environment, das make gestartet hat, werden automatisch zu 
make-Variablen. Diese Variablen und alle make-Variablen, die man mit 
"export" markiert, werden in Environments exportiert, die make für Jobs 
erzeugt [1]

Ansonsten würde man das, was ich oben "dynamisches Environment" genannt 
habe, eher mit make-Variablen machen, die sich im Fortschritt des 
Build-Prozesses ändern.

> Wie programmiert man Schleifen oder expandiert Platzhalter im Make?

Schleifen braucht man in make typischerweise nicht. Überhaupt ist make 
eine deklarative Programmiersprache, keine imperative wie eine Shell. In 
make sagst du einfach, welche Build-Artefakte du erzeugt haben willst 
und make findet selber heraus, wie das zu tun ist (mit Regeln). Aber 
wenn es unbedingt sein muß, kannst du natürlich ein for Statement in 
einer Subshell ausführen lassen.

Zum Thema Variablenexpansion gibt es gleich mehrere Nodes in der Doku. 
Inclusive solcher Schmankerl wie [2]


[1] https://www.gnu.org/software/make/manual/html_node/Environment.html
[2] 
https://www.gnu.org/software/make/manual/html_node/Substitution-Refs.html

Ralph S. schrieb:
> Vielleicht wäre es ratsam, wenn du die Elektronik unterteilst in:
> Elektronikperipherie... Digitalelektronik... Mikrocontrollern

Nein. Ein Anfänger, der ein Board programmieren und eine LED blinken 
lassen will, möchte vorher kein ganzes Buch lesen müssen. Auch keine 
drei Kapitel. In der Zeit hat er auf Netflix schon eine neue Serie 
angefangen. :-)

Ich habe in die Bücher jetzt nicht reingeschaut, aber das didaktisch 
sauber zu trennen funktioniert für Kinder nur sehr eingeschränkt. Das 
kann man machen, wenn man einen Kurs über einen bestimmten Zeitraum 
leitet, aber auch dann verliert man Teilnehmer.

Ralph S. schrieb:
> Hier gebe ich dir 2 mal Recht (was dann wohl sicher kein anpissen ist)
> und was die Sache mit dem Lesen betrifft: Du schreibst es so, dass man
> den Arduino als Einstieg nehmen soll und sich so das Lesen ersparen
> kann...

Bist du eigentlich nur doof?
Das mit den 2000 Seiten war auf den Vorschlag Cortex zu nehmen bezogen.

Smile, okay... und wie war das nochmal mit dem "anpissen"?

... und manchmal... wenn man sich angefahren fühlt., dann ...

Im Übrigen würde ich niemanden den ich nicht kenne die Intelligenz 
absprechen. Die Frage also, ob ich doof bin laß ich jetzt mal 
unbeantwortet.

Stefan ⛄ F. schrieb:
> Seit der Veröffentlichung hat kein
> einziger Leser diesen Punkt moniert oder nachgefragt.

... das ist das schwächste argument zu dem thema, das du finden und 
nennen kannst. ich denke, das brauchst es nicht!

meinungen/kritik anderer sollten nur denkanstöße für dich sein, ob du 
sie teilst oder nicht ist dir belassen und braucht keine rechtfertigung.

ich kenne deine seite und beiträge recht gut und ziehe den hut, weil die 
energie/effort und das herzblut für unser thema verdient anerkennung.

hier immer darauf hinzuweisen, finde ich auch nicht kritikwürdig und 
recht ok. weil in dem meer an infos und mist braucht es leuchttürme 
besonders für anfänger.

sicher würde ich einiges anders machen, aber warum solltest du das 
bedenken deine bücher finde ich nützlich - bleib deiner denke treu.

Ralph S. schrieb:
> Vllt. zu deinen "Büchern": Das größte Problem beim Schreiben eines
> Scriptes oder Buches ist es, dieses zu strukturieren (und das Problem
> habe ich auch). Prinzipiell sollte es (wie beim Programmieren) ein
> "Top-Down" Entwurf sein, das heißt: es gibt in Stichpunkten die Inhalte
> die der Text vermitteln soll, in einer so gut wie möglich gegliederten
> Ablauffolge.

da spricht deutlich ein halbblinder aus dir oder technojünger. wenn das 
die glücksformel für erfolgreiches schreiben wäre würden wir dich alle 
kennen und beneiden. nur so ist es nicht.

UND programmieren ist auch (eher) ein chaotischer/iterativer process, 
top-down kochbuchrezepte sind längst alle im schredder!
man denke nur an den diametral unterschiedlichen sw entwicklungsprocess 
von  microsoft und linux.

beispiel, ich kenne nur 3-5 "gute" bücher zu c-programmierung, 2-3 davon 
(moderne c-programmierung,schellong; 21st century c, klemens) fanden 
andere häufig scheisse.


mt

Moin,

So, was macht unser TO Kai_25 nun?
Wenn er sich nicht gerade schon beim Töpferkurs angemeldet hat...

Vermutlich freut er sich schon an den blinkenden LEDs des 2313, den er 
mit Atmel Studio 7 (er ist wie die Meisten hundertfacher 
Byte-Milliardär, wenn nicht Billionär und sein Rechner ist nicht 14 
Jahre alt) über den als STK500 geflashten Uno programmiert.
Ein paar hängengebliebene oder aufgeschnappte Brocken C, paar Beispiele 
angesehen, kleines Tutorial zum Studio und den Grundlagen der AVR und 
schon hat es geblinkt.
Kurz hier reingesehen schüttelt er jetzt mit dem Kopf und fragt sich, 
was mit Euch denn los ist...

Gruß,
Norbert

Ralph S. schrieb:
> Die Frage also, ob ich doof bin laß ich jetzt mal unbeantwortet.

Ralph, du fängst an mich in den Mittelpunkt deiner "Beratung" zu 
stellen, als wäre ich der TO,l.
Dann zitierst du einen völlig falschen Bezug.
Du unterstellst mir quasi den Anfänger und schreibst über meine 
Beiträge, als könnte ich nicht bis drei zählen.
Konzentriere dich lieber statt dessen auf eigentlichen Inhalt dieses 
Threads.
Klar hat der TO auch nach einer Alternative gefragt.

Und natürlich habe ich auch schon Cortex gemacht, aber nicht meine 
Baustelle. Deshalb finde ich es auch keine gute Idee für einen Anfänger.
Stefan mag da was zusammen gefasst haben und vermutlich ist es gut, aber 
um die vielen Seiten Datenblatt kommt man trotzdem irgendwann nicht rum.
Ralph, lies bitte wenigstens alle Beiträge in diesem Thread von mir und 
deren Bezug, danach wirst du verstehen was du alles falsch gemacht hast.
Andernfalls lass mich aus deinen Bezügen zum Thema einfach raus.
Ich fasse es aber gerne noch einmal in wenigen Worten für dich zusammen: 
Programmer von Atmel, wenn es günstiger sein soll, von eHajo.
Arduino ist ein guter Einstieg,was gleibedeutend damit ist, dass man 
natürlich sich irgendwann einmal mit irgendeinem Controller richtig 
auseinander setzen sollte.
Cortex ist in meinen Augen für einen Anfänger viel zu heftig, wenn er 
das als Hobby betreiben will.
So, das war die Zusammenfassung extra für dich.

Moin,

Sehr schön!

Aber so ganz ohne Linux?
Das muss doch eine Qual gewesen sein.
Vermutlich hast Du auch keine Ahnung von den ganzen Dingen, die bei 
"Mach mal!" im Hintergrund passiert sind.
Sehr bedauernswert.
Diesem Thread zufolge hast Du alles falsch gemacht.
Schade.

Wer Ironie findet, darf sie behalten, wer sich angepisst fühlt, darf 
sich angepisst fühlen.

Gruß,
Norbert

Hallo,
Norbert S. schrieb:
> Aber so ganz ohne Linux?
> Das muss doch eine Qual gewesen sein.
> Vermutlich hast Du auch keine Ahnung von den ganzen Dingen, die bei
> "Mach mal!" im Hintergrund passiert sind.
> Sehr bedauernswert.
> Diesem Thread zufolge hast Du alles falsch gemacht.
> Schade.

:-)))

rhf

Stefan ⛄ F. schrieb:
> Ich kann aber niemandem empfehlen, heute auf die gleiche Art zu lernen.
> Wenn wir immer wieder bei Edison und Bell anfangen, reicht unser Leben
> bald nicht mehr aus, die ganzen komplexen Erfindungen der Elektronik
> nachzuvollziehen. Wir sind ja jetzt schon soweit, dass ich dafür
> wenigstens 10 Jahre veranschlagen würde. Wer will denn schon 10 Jahre
> lernen, bevor er damit Spaß haben kann oder eine Familie versorgen kann?
> Bei mir ging das nur so gerade eben, weil ich schon in der Grundschule
> damit anfing.

Genau das ist der Punkt den ich immer meine.
Stefan, du bist da auch beruflich drinnen gewesen.
Sicher, viele andere auch. Aber heute will nicht unbedingt jeder das 
beruflich machen und fängt auch erst als Erwachsener an und nicht schon 
in der Kindheit.
Bei uns wurde oft aus der Not eine Tugend.
Heute kannst du vieles für wenig Geld kaufen, was es zu unserer Zeit 
kaum gab oder teuer war. Also mussten wir viel selbst machen.
Wenn es nach der Meinung einiger Hardliner hier ginge, dann müsste jeder 
der einen PC bei der Arbeit benutzt, diesen zusammen bauen können und 
selbstverständlich das Betriebssystem selbst in Assembler programmiert 
haben.
Die meisten Leute fahren Autos, aber ich würde nie verlangen, dass sie 
dieses auch in Gänze reparieren können.

SCSI Controller für über 1000 DM.
Als angeblich eine Fabrik abgebrannt war, habe ich für 32MB RAM 1600 DM 
ausgegeben.

Stefan ⛄ F. schrieb:
> Allerdings. Wenn ich daran denke, wie viel mein erster selbst gebauter
> Mikrocomputer mit CPU, RAM und ROM-Simulator gekostet hatte, wird mir
> heute noch schlecht.

mir nicht, damals war mehr Geld,
ein Wechseldrive mit 44 MB & 40 MB Platte 4000,-DM dafür ist man mal 
eben zur Atari Messe nach DD "gejettet" + Hotel und mit Frau.

heute ein Festplatte für 4000,- undenkbar, jeder RAMchip x14_2K x16_1M 
für 50,- ebenfalls kaum noch vorstellbar.

Mein erster richtiger PC PET2001 1979 2000,-DM mit 8K Ram und Kassette, 
nachfolgend pro Floppy Drive als apple NACHBAU! 600,-DM

Ist heute ja alles billiger, nur Geld ist weniger, Nebenkosten höher.

... und warum gibts hier -keine Ironie- keine Untergruppe "Geschichte 
und Nostalgie"?

Mein erster Rechner war ein Sinclair ZX81... Platine mußte selbst 
bestückt werden... für 499 DM... Danach hatte ich was proprietäres dass 
sich Vtech 200 nannte Z80 CPU 32 k RAM (kein Lernspielcomputer), einen 
Schneider CPC6128 (CP/M), Amstrad PC 1512 (MS-DOS)... und dann 1989 
meinen letzten am Stück gekauften Computer von Vobis 386DX25 für 3700 
DM.

Apollo M. schrieb:
> da spricht deutlich ein halbblinder aus dir oder technojünger.

Eigentlich wollte ich mir verkneifen darauf zu antworten. Seit 30 Jahren 
bin ich jetzt u.a. auch Ausbilder für Elektroniker (aktuell EGS) und 
Physiklaborant. Halbblind bin ich nicht und ein Technojünger schon gar 
nicht (mehr)... Ohne weiteres Statement dazu... Ach so, ja.... im 
Prüfungsausschuss für beide Berufe bin ich auch noch... Die armen 
Lehrlinge.

Ralph S. schrieb:
> Geschichte
> und Nostalgie

Wäre wirklich ganz interessant und lustig zu lesen wie jeder so zur 
Elektronik und Mikrocontrollern gekommen ist.

aber es läuft immer wieder aufs gleiche Hinaus. Weil sich die Wege 
ähneln.

Alleine schon die Bausteine die es gab. Einer meiner Berufsschullehrer 
wollte mir den Transistor anhand einer Röhre erklären.

Heute erkläre ich eine Pentode anhand eines MOS-FET (das passt deshalb 
besser, weil beide spannungsgesteuert sind).

Aber: weil es eben zu jeder Zeit Bauteile gegeben hat, die in die Zeit 
gehören haben viele auch ähnliche Wege.

Lustig und spannend finde ich das dennoch. Alleine wenn man sich an alte 
Dinge erinnert.

Wie oben gesehen kann man sich denken: Das erste "richtige" 
Betriebssystem hieß CP/M.

Programmiert hat man, wie sehr viele anfänglich, mit BASIC um dann 
festzustellen (zumindest damals): der Hit ist das nicht.

Zeitkritische Dinge hat man mit Assembler gemacht, aber traumhaft ist 
anderst.

Und dann gab es, für die damalige Zeit, die Offenbarung, die da hieß:

BORLAND

Und mit Borland das Turbo Pascal (meine erste Version war 2). Aus der 
damaligen Sicht haben alle geunkt, dass die Art und Weise wie Turbo 
Pascal realisiert ist, so nicht gemacht gehört:

Keine Trennung der Toolchain, das Hauptprogramm ist mit dem Compiler in 
einem Programm vereint. Der Compiler selbst komplett in Maschinensprache 
geschrieben (und nicht wie bisher üblich nur einen Kern und danach 
übersetzt die Programmiersprache quasi sich selbst).

Dafür aber extrem Resourcensparend und es war möglich dieses mit auf der 
selben Diskette zu halten auf dem sich auch das Betriebssystem befand.

Turbo Pascal hatte einen umwerfenden Erfolg und auf PC's schickte es 
sich an, DIE Programmiersprache für PC's zu werden.

Außerhalb von den PC's hat man davon geträumt, irgendwie eigene 
computergesteuerte Geräte zu bauen, aber man schäute sich auch, ein 
ganzes Rechnersystem aus 8085 oder Z80 zu bauen.

Und dann kam Völkner Electronic.... und hat irgendwas mit einer Menge 
i8048 im Angebot. Was war das für ein Scheiß: keine Infos. Also 
Bibliothek gehen und das große dicke fette Intel Datenblatt Buch gucken 
(und später dann auch kaufen). Okay, bestand aus 2 Büchern und hatte 
prinzipiell für MCS-48, MCS-51 und MCS-166 (16 Bit etwas).

War mühselig. Und Völkner hatte noch etwas (was nicht so tolle war wie 
es sich herausstellte): Einen EPROM-Emulator (der mehr schlecht als 
recht ging und der für C64 war... den ich nicht hatte). Also hatte ich 
mir einen EPROM-Emulator gebaut, der mittels Schieberegistern ein RAM 
beschrieb und dessen Anschlüsse von 74LS245 Treibern geblockt waren. Ein 
Controllersystem das einen externen ROM brauchte konnte von diesem 
Emulator versorgt werden.

Also schrieb ich einen ersten rudimentären Assembler für 80C48 mit 
integriertem Zeilenedior der gerade einmal so auf einem Schneider CPC 
lief.

So war das... danach kamen die üblichen verdächtigen: MCS-51, PIC16 (na 
ja), AVR, STM32...

Aber daneben war eher Hifi das Thema und mehr als ich in Computer 
investiert habe, habe ich in die Steroanlage investiert. Damals mußte 
man UNBEDINGT ein Moving Coil System im Plattenspieler haben ... und hat 
sich dafür einen Vor-Vorverstärker gebaut und eine Endstufe in Class A 
(die dann irgendwann einmal von einer Technics Endstufe Class A) 
abgelöst wurde.

Damals hat man Transistoren im Stile von BDX66C und BDX67C geliebt 
(Darlington-Transistoren im TO-3 Gehäuse), aber richtig teuer.

Preiswerter wurde es mit Leistungstransistoren ohne Darlington: BD245 
und BD246

Grundsätzlich hat man die Nase darüber gerümpft, wenn irgendwo 
Integrierte Bausteine verwendet wurden. Und dann kam die Zeit, an dem 
Operationsverstärker "gut" wurden.

Wenn man sich dann daran erinnert, weiß man noch, wie ehrfürchtig man 
vor einem OP-07 war (der damals abartige teuer war), oder lächelte, weil 
es Glühbirnchen im LED-Gehäuse gab, deren Glas blau gefärbt war, weil es 
blaue  LED's einfach nicht gab.

Überhaupt: blaue LED's, da gabs ein Hype dazu. Extrem viele, zu Nokia 
3310 und 3410 Handy Zeiten wollten auf einmal nicht mehr die grüne 
Hintergrundbeleuchtung, sondern es sollte blau sein und deswegen wurde 
der Lötkolben angeworfen (heute wäre eher mal rot hip).

Und manche Dinge sind erhalten geblieben: der Dinosaurier unter den IC's 
: NE555 (und alle seine Ableger).

Den liebe ich bis heute (und wie das ausschaut auch die 
Berufsschullehrer für Physiklaboranten). Warum?

Weil man mit diesem so herrlich viele Aspekte der 
(Nicht-Mikrocontroller-Elektronik) erschlagen kann:

- erklären, was ein Komparator ist (der 555 hat 2 Stück intern). Daraus 
kann man auch gleich darauf hinweisen, dass ein Komparator prinzipiell 
ein Operationsverstärker im "Schalterbetrieb" ist (was ein übersteuerter 
Verstärker generell ist)

- erklären, was ein Flip-Flop ist (in diesem Fall ein SR-FF mit 2 
Resetanschlüßen)

- erklären, was ein Transistoranschluß ist, der den discharge vornimmt

- hinzukommt dann an äußerer Beschaltung noch Kondensator und Widerstand 
anhand derer man schön Ladekurve und e-Funktion aufzeigen kann. Meine 
Auszubildenden bauen deshalb einmal aus einzelnen Teilen die 
555-Funktionen nach.

Wenn sie diese Funktionen alle erklären können, können sie witzigerweise 
mit gaaaaaanz vielen Aspekten der Elektronik umgehen:

- Multimeter
- Oszilloskop
- Störungen die es im analogen Aufbau gibt zu erkennen

Ja ja ja .... die Geschichte der Elektronik, was ist Geschichte und 
vorbei (wie oben jemand geschrieben hat die Speicherverwaltung von 
MS-DOS ... Himem, EMS, bla bla bla .... das ist wirklich vorbei)...

Wann sind Mikrocontroller vorbei und alles wird per FPGA und soften 
Prozessoren gemacht?

Ralph S. schrieb:
> Heute erkläre ich eine Pentode anhand eines MOS-FET (das passt deshalb
> besser, weil beide spannungsgesteuert sind).

nur bevor mich wieder jemand als gestrigen und so:

Eine Röhre erkläre ich nur nach Aufforderung wenn jemand ualte Technik 
restaurieren will. Ansonsten gehört Röhre auch zu den Dingen, die 
obsolet sind...

Ralph S. schrieb:
> Wann sind Mikrocontroller vorbei und alles wird
> per FPGA und soften Prozessoren gemacht?

Aber dein Gedanke ist langfristig nicht absehbar, weil man sich die 
Flexibilität anderswo erkauft und das nicht unbedingt will. Deswegen 
kombiniert man lieber FPGAs und harte Prozessoren und nutzt das in die 
Compilerentwickelte geflossene Wissen. Standards sind irgendwo doch 
cool.

Gewisse Dinge (z.B. Mobilfunk-Basisstationen) werden heutzutage fast 
ausschließlich aus FPGAs gebaut, weil man damit ohne Bauchlandung 
bereits vor Verabschiedung des Standards auf dem Markt sein kann. Oder 
Systeme, wo man eigentlich keinen Prozessor braucht, ihn aber aus 
Convenience-Gründen will. VHDL und Verilog sind furchtbar.

S. R. schrieb:
> Oder
> Systeme, wo man eigentlich keinen Prozessor braucht, ihn aber aus
> Convenience-Gründen will. VHDL und Verilog sind furchtbar.

: - )

Ralph S. schrieb:
> Ansonsten gehört Röhre auch zu den Dingen, die
> obsolet sind...

sag das nicht, Röhren waren lange out als ich den Weg des RFS Techniker 
verliess um E-Technik zu studieren, als ich in einem Institut anfing kam 
kurze Zeit später ein RF Generator mit Röhre auf dem Tisch zur Reparatur 
und da war es wieder, altes Wissen ist fast nie nutzlos! (ausser mein 
gerne genommesens Beispiel 333 Issos Keilerei, habe ich nach der Schule 
nie wieder benötigt)

Ralph S. schrieb:
> Ansonsten gehört Röhre auch zu den Dingen, die
> obsolet sind...

Na,
dann hast Du wohl noch nie einen Röhrenverstärker aufgebaut.
Inclusive Chassis bohren.
Das macht richtig Spass.
Damit's nicht zu sehr in Richtung OT geht,
mach ich hier mit Schluss jetzt.

ciao
gustav

Karl B. schrieb:
> Ralph S. schrieb:
>> Ansonsten gehört Röhre auch zu den Dingen, die
>> obsolet sind...
>
> dann hast Du wohl noch nie einen Röhrenverstärker aufgebaut.
> Inclusive Chassis bohren. Das macht richtig Spass.

Das ist ein dämliches Argument. Eine Fahrt mit der Pferdekutsche macht 
auch Spaß. Trotzdem sind Pferdefuhrwerke jeglicher Art auch obsolet.

Hi,
das man für Neuentwicklungen sowas nicht mehr nimmt, braucht nicht extra 
betont zu werden.
Wenn man aber trotzdem mit Röhren experimentieren möchte, gewinnt man 
ein ganz anders Verhältnis zur Elektrik bzw. Elektronik, möchte ich 
meinen.
Der Umgang mit höheren Spannungen, Isolation etc. das ist für 
denjenigen, der an 12V Versorgungsspannung gewöhnt ist ein ganz anderes 
Erlebnis, wenn er den entsprechenden Kontakten zu nahe kommt mit den 
Fingern.;-)
Aber die Röhren reagieren nicht so extrem empfindlich auf eventuell 
fehlerhafte suboptimale Beschaltung.
Das merkte ich bei der Reparatur von Transistorbestückten NF-Verstärkern 
ganz deutlich.
Wie viele Endtransistoren nach Tausch schon beim ersten Einschalten 
wieder kaputtgingen, kann ich schon garnicht aufzählen. Und da bin ich 
mit meiner Meinung bestimmt nicht allein.
Bei Röhren-NF-Verstärkern dieser Leistungsklasse ist mir das noch nie 
passiert, dass eine Röhre direkt glühend wird an der Anode.
Da können auch Toleranzen ziemlich groß werden, ohne dass gleich etwas 
explodiert.
Jedenfalls macht es Spaß, sich mit der angeblich obsoleten Technik, wenn 
es nun nicht doch zu viel verlorene Liebesmüh ist, und der Aufwand zu 
groß im Verhältnis zu dem, was man hinterher herausholt, noch zu 
beschäftigen. Und wer will mir das verbieten.
Auch Du nicht.

ciao
gustav

Anfang der 70er habe ich als Kind meine ersten Elektronikbasteleien mit 
Röhren gemacht. Material war aus ausgeschlachteten Radios reichlich 
vorhanden, Literatur auch.

Als ich dann auf Transistoren umstieg war ich erst mal von der im 
Vergleich geringeren Verstärkung enttäuscht, ein zweistufiges Radio mit 
Lautsprecherbetrieb  war da schon schwierig.

Die Röhrenkenntnisse kamen mir Ende der 80er dann mal zunutze als ich 
ein russisches Vakkuum-Messgerät reparieren sollte.

Das Vakkuum würde über den Stromfluss gemessen, der Verstärker war mit 
eingelöteten Röhren aufgebaut.

Und auch die Generatoren für die im Betrieb vorhandenen 
Hochfrequenz-Härteanlagen waren damals mit wassergekühlten Senderöhren 
ausgerüstet.

Karl B. schrieb:
> Na,
> dann hast Du wohl noch nie einen Röhrenverstärker aufgebaut

Smile, hab ich... EL84

Wäre dann vllt. doch mal gut, einen eigenen Thread mit "Früher" 
aufzumachen...

Ralph S. schrieb:
> EL84

Ja, sollte für den Bekannten den Grundig NF10 mit EL800 reparieren.
Da kam ich auf die Idee, das mit der populäreren und preiswerteren
EL84 zu machen. Die ist halt ein Klassiker und wird es wohl auch noch 
länger in Produktion geben, ohne dass die Preise duch die Decke gehen.
http://www.tube-classics.de/TC/GermanTubeHifi/Poweramps/Grundig%20NF10/NF10De.htm

ciao
gustav

Stefan ⛄ F. schrieb:
> Ach ja, das waren noch Zeiten, als man für jedes Megabyte knausern
> musste.

Megabyte???
Du bist eindeutig zu jung.

Smile, mein CP/M Rechner hatte "gebankte" 128 kb, der Rechner davor, war 
ein Z-80 Basic Rechner mit 16 kb RAM... da hat man mit jeden 100 Bytes 
gegeizt.

Immer wieder denke ich mir: 1 GB , was für ein Wahnnsinn...

Mein Standart-PC hat 16 GB Ram... und das verrückteste ist, dass der 
diese auch braucht.

Vielleicht macht bei dieser Gigantomanie die reduzierten Resourcen eines 
Controllers deren Reiz aus?

Häufig hab ich das Gefühl, speziell bei STM32, dass ich einen alten DOS 
Rechner programmiere...

Ralph S. schrieb:
> Vielleicht macht bei dieser Gigantomanie die reduzierten Resourcen eines
> Controllers deren Reiz aus?

Tut es definitiv. Ich programmiere gerade einen Tiny10 und versuche, 
möglichst viel Funktionen da reinzuquetschen.

chris schrieb:
> Tatsächlich? Ich nicht, die DOS Rechner waren deutlich
> reaktionsschneller.

Das meinte ich zwar nicht so ganz, aber:

- ich habe mir meine eigene (Konsolen-IDE) geschrieben, die so aussieht 
(weil die FreeVision von FreePascal verwendet) wie die von Borland (das 
war absicht), kann aber mit jedem Edior logischerweise Code erzeugen

- Habe ich ein Display am Controller, habe ich Libraries geschrieben, 
die für einen Textmodus Namen wie settextcolor, settextattr, setbkcolor 
und gotoxy haben. Außerdem verwende ich printf

- Für Grafiken am Display habe ich entsprechend ähnlich Funkionsnamen

Was dann die Geschwindigkeit angeht:

Mein erster 386er war ein 386SX20 (den hätte ich behalten sollen, denn 
letztes Jahr habe ich mir "just for fun" und um einen Vergleich zu 
Controller haben zu können, einen 386SX25 PC aus Teilen von EBAY gebaut, 
und der ist teurer gekommen, als ein Ryzen 3 PC)

Auf dem habe ich den Code des Apfelmännchens mit einer Auflösung von 
480x320 mit 256 Farben laufen lassen und denselben Code auf einem 
STM32F411 mit 120 MHz.

Der STM32 war deutlich schneller.

Auch die Funktionen einer FATFS mit SPI zum Zugriff auf eine SD-Card 
haben bspw. Namen wie fopen.

Ich weiß, ich bin nostalgisch, alt und ewiggestrig (aber dafür 
"flutscht" es beim Schreiben von Programmen auf den Controllern).

chris schrieb:
> Tatsächlich? Ich nicht, die DOS Rechner waren deutlich
> reaktionsschneller.

Das liegt schlicht daran, daß man früher noch ressourcenfreundlich 
programmiert hat, während heute dem Entwicklern 32GB und 16 Kern 
Maschinen auf den Schreibtisch zur Verfügung stehen.
Man schaue sich mal den Apollo AGC an (der ist mittlerweile vollständig 
dokumentiert im Netz zu finden), was damals mit der verfügbaren 
Rechenleistung gemacht wurde.