Guten Tag, ich befasse mich seit längerem mit der Programmierung, nun möchte ich gerne das Programmieren von Mikrocontrollern erlernen... Ich habe mich etwas in die Materie eingelesen jedoch finde ich keine 100% Antwort auf meine Frage - aus diesem Grund versuche ich es hier mit dem Beitrag. Wie schon erwähnt möchte ich anfangen zu Programmieren, meine Frage direkt: Wird es mir möglich sein mit einem Arduino Uno R3 https://www.ebay.de/itm/UNO-R3-Starter-Set-Kit-USB-Kabel-Header-Arduino-komp-Board-Atmel-ATmeg/253051629463?hash=item3aeb0d6f97:g:DQYAAOSwaIpb4sK7 einen ATtiny2313 zu programmieren ? Den Code dafür würde ich gerne in Atmel Studio 7 schreiben. Falls es für Einsteiger einfachere Varianten gibt, würde ich mich über Infos, Tipps und Tricks freuen Mit freundlichen Grüßen Kai
Ein Arduino-Board kann zu einem ISP-Programmer umfunktioniert werden. Da muss man nur richtige Software drauf installieren. Ob es mit Atmel Studio geht, weiß ich nicht.
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.
:
Bearbeitet durch User
Future Product: https://www.microchip.com/wwwproducts/en/ATTINY1624 https://en.wikipedia.org/wiki/ATtiny_microcontroller_comparison_chart
Kai_25 schrieb: > Falls es für Einsteiger einfachere Varianten gibt, würde ich mich über > Infos, Tipps und Tricks freuen Also das mit dem Arduino UNO und dem ISP Sketch geht auf jeden Fall. Siehe https://create.arduino.cc/projecthub/arjun/programming-attiny85-with-arduino-uno-afb829 Der Arduino UNO ist danach kompatibel zum Atmel stk500 Version 1, das müsste vom Atmel Studio unterstützt sein. Beim alten AVR Studio geht es auf jeden Fall. Etwas einfacher ist offensichtlich die Benutzung eines handelsüblichen ISP Programmieradapter (Achtung: nicht alle sind Atmel Studio kompatibel). Dann hast du eine Baustelle weniger. Zwei Baustellen gleichzeitig können im Fehlerfall sehr nervig werden. Du kannst natürlich auch auf die Atmel Studio Kompatibilität scheißen und deinen Programmieradapter mit einer anderen Software (z.B. avrdude) benutzen. Dann ist es aber nicht mehr so einfach wie möglich. Hier hast du einen Startpunkt um dich einzulesen: http://stefanfrings.de/avr_hello_world/index.html http://stefanfrings.de/mikrocontroller_buch/index.html
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.
Axel S. schrieb: > 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. Naja, Ähnlichkeit ist relativ... 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. Downscaling einer fertigen Lösung auf einen kleineren Controller kann man dann immer noch machen. Das ist dann schon nicht mehr ganz "Anfängerwerk".
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
c-hater schrieb: > Downscaling einer fertigen Lösung auf einen kleineren Controller kann > man dann immer noch machen. Das ist dann schon nicht mehr ganz > "Anfängerwerk". Vielleicht ist er gerade so weit, das Downscaling zu versuchen. Wenn man das generell ablehnt, macht man es nie.
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.
A. M. schrieb: > AVR ISP MKII > zumindest das Originale ist zuverlässig und beinahe unzerstörbar. Das entspricht auch meiner Erfahrung. Ich würde gerne einen gebrauchten originalen Atmel ISP mkII nehmen, wenn ich nicht schon einen hätte. > unterstützt kein UPDI und damit die neuesten AVRs. > Das sollte aber ersteinmal kein Problem darstellen. Sehe ich auch so. Bevor ich mich mit diesen "neuen" AVR beschäftige, schaue ich mir lieber die STM32 an. Ich denke, davon habe ich langfristig mehr. Für mich endet die 8bit Welt bei den klassischen AVR Mikrocontrollern mit ISP Interface und Debug Wire.
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.
Kai_25 schrieb: > Wird es mir möglich sein mit einem Arduino Uno R3 > Ebay-Artikel Nr. 253051629463 > > einen ATtiny2313 zu programmieren ? Gibt "bessere" ISP Adapter. Aber verwendbar: Ja. > Den Code dafür würde ich gerne in Atmel Studio 7 schreiben. Ja. Kai_25 schrieb: > Falls es für Einsteiger einfachere Varianten gibt, würde ich mich über > Infos, Tipps und Tricks freuen "Einfacher"? Nimm den UNO und die Arduino IDE. Entwickle damit deine Anwendung, und wenn fertig, dann gesundschrumpfen und auf den Tiny spielen. Natürlich kommen sie jetzt wieder aus den Büschen und rufen: Arduino Framework, viel zu fett, zu langsam. Kann sein ... Muss man aber nicht verwenden, auch mit der Arduino IDE nicht. C, C++ und Assembler sind nutzbar. Wenn man es geschickt anstellt, kann man die Programme unverändert ins Atmel Studio übernehmen. -- Ob ich einen ATtiny2313 für das passende Einsteigermodell halte...? Eher nicht. Aber machbar? Ja!
Leute, hier hat niemand darum gebeten, einen Mikrocontroller zu empfehlen! Es hat auch niemand danach gefragt, ob das Arduino Framework empfehlenswert ist. Diese Diskussionen hatten wir oft genug, jeder kann danach googeln, wenn er will. Der TO hatte Fragen konkret zum ATtiny2313 ohne Arduino mit Atmel Studio, konzentriert euch bitte darauf.
Stefan ⛄ F. schrieb: > Leute, hier hat niemand darum gebeten, einen Mikrocontroller zu > empfehlen! > Es hat auch niemand danach gefragt, ob das Arduino Framework > empfehlenswert ist. > > Diese Diskussionen hatten wir oft genug, jeder kann danach googeln, wenn > er will. > > Der TO hatte Fragen konkret zum ATtiny2313 ohne Arduino mit Atmel > Studio, konzentriert euch bitte darauf. +10 Wahre Worte -gelassen ausgesprochen. Ja, einen Arduino Uno kann man (mit dem entsprechenden Programm drauf) als ISP-Programmer im AVR-Studio benutzen. Er wird dann als STK500 Version 1 erkannt.
Stefan ⛄ F. schrieb: > konzentriert Na? Heute wieder Stress im Betrieb gehabt? Woran ich das merke? Wenn du genau das Gegenteil von dem tust, was du von anderen einforderst. Dein hingekotzter Beitrag ist bar jeglicher fachlicher Substanz. Konzentriere dich mal bitte ein bisschen aufs Thema.
Möchtegern-erfolgreich Möchtegern-klug Stefan ⛄ F. schrieb: > Leute, hier hat niemand darum gebeten, einen Mikrocontroller zu > empfehlen! > Diese Diskussionen hatten wir oft genug, jeder kann danach googeln, wenn > er will. Möchtegern-Mod In dem Ausmass, in dem Du hier das Forum mit Deinen Posts zuschwallst, stünde es Dir gut zu Gesicht, anderen Postern und den üblichen kreativen Beitrags-Erweiterungen/-Abweichungen entsprechende Toleranz entgegenzubringen. Arduino Fanboy D. schrieb: > Heute wieder Stress im Betrieb gehabt In welchem Betrieb? Das Wort "Betrieb" würde einen Arbeitsplatz voraussetzen. Zu den Zeiten in der er schreibt, würde er entweder seine von einer Firma bezahlte Arbeitskraft missbrauchen oder er ist selbstständig. Letzteres darf nach seiner allgemeinen Selbstdarstellung stark bezweifelt werden.
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?
Max M. schrieb: > Kommt das nicht einer Frage nach Alternativen gleich? Ja doch, kann man so interpretieren.
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!
Peter D. schrieb: > Schon float belegt 1kB Flash. printf, scanf: no way! Stimmt. Das kann man als sportliche Herausforderung betrachten. Für einfache Timerschaltungen (geblinke, Lüfter am Klo, etc) sind die kleinen ATtinies durchaus Ok. Spätestens wenn ein Display dran kommt, nerven sie jedoch nur noch.
Peter D. schrieb: > Der AT90S2313 war ja der erste verfügbare AVR, daher habe ich mich damit > auch abgequält. Nein. Der At90S1200 war der Erste.
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
:
Bearbeitet durch User
Karl B. schrieb: > die Portierbarkeit der asm-files ist aber doch mit einem größeren > Aufwand verbunden, möchte ich meinen Kommt drauf' an, wie gut sie geschrieben sind... Was die Symbole (egal ob Vektoren, SFIO-Register oder Bits darin) angeht, ist der Aufwand exakt so groß wie etwa in C oder was auch sonst immer für einer Sprache. Leider hat Atmel mit einer teilweise schon abstrus anmutenden "Benamsungspolitik" für sehr viel, eigentlich unnötige Arbeit gesorgt. Aber das trifft alle Programmiersprachen gleichermaßen... Auch die Anpassungen an Unterschiede bei Details der Peripheriefunktionalität macht exakt genausoviel Arbeit wie etwa in C. Andere Sachen kann man mehr oder weniger leicht durch sinnvolle Macros erschlagen, z.B. das Thema MMIO vs. In/Out für den Zugriff auf SFIO-Register. Man muss sie halt nur einmal schreiben und immer konsequent verwenden. Richtig Arbeit macht eigentlich meist nur, wenn irgendwelche Hardwarefunktionalität auf dem kleinen Teil schlicht nicht verfügbar ist. Fehlende USART, fehlende Timer oder nicht zuletzt: fehlende Hardwaremultiplikation. Dann muss man sich was einfallen lassen, wie man die Funktionalität mit dem umsetzt, was da ist...
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
Rainer V. schrieb: > ...wenn ich das schon höre...was willste denn multiplizieren?? > 64Bitx64Bit??? Ganz sicher nicht. Warum nicht? Hängt schlicht von der Anwendung ab, was die halt machen soll. Du bist scheinbar zu blöd, zu begreifen, dass sowas eben ein "downscaling" auf einen kleinereren Controller begrenzen kann. > Und Assemblerroutinen für eine > Multiplikation/Division gibts wie Sand am Meer. Klar. Die Frage ist dann halt bloß: ist die Sache dann auch noch schnell genug... > Da stört auch nicht eine > UART-Schnittstelle...und das LCD schon gar nicht! 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...
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: > Jetzt schwurbel hier mal nicht wieder rum! Sondern genehmige dir > vielleicht selbst mal einen Tomatensaft....hilft auch gegen > Pickel...also verpickeltes Gesicht und so... Also besoffen. Ausschlafen hilft. Man darf dann bloß nicht gleich wieder damit anfangen, womit man aufgehört hat...
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?
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.
Angehängte Dateien:
-
arduino_ausschnitt.jpg
88 KB
... 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
:
Bearbeitet durch User
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: > Cortex für Anfänger? > Erstmal 2000 Seiten lesen und auch noch verstehen. Für ARM Controller gibt es definitiv viel zu lesen. Für den Anfang empfehle ich etwas kürzeres: http://stefanfrings.de/mikrocontroller_buch2/index.html Man muss nur wenige Seiten lesen, um anfangen zu können. Meine Anleitung soll dabei helfen, die richtigen Seiten zu finden.
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.
>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). Ist es nicht: https://github.com/rsta2/circle
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.)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 bezweifle ich. 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 - man muss es nur hin schreiben. Ja, das bedeutet mehr Aufwand, deswegen hat man sinnvollerweise das spezifischere make erfunden. Ralph S. schrieb: > Hätte der TO das bei mir vorliegende System, würde er > einen ATtiny2313 über ein Arduino-Board in 5 Minuten programmieren Den Umgang mit make und avrdude lernt man nicht in 5 Minuten. Gebe den Anfängern die nötige Zeit, du hattest sie schließlich auch. Ralph S. schrieb: > Ich glaube ich werde mal zählen, wie oft du hier Werbung > für dein "Buch" machst. Mach ruhig, wenn Dir das irgendeinen Nutzen bringt. "Das Buch" habe ich geschrieben, um die immer wiederkehrenden Anfängerfragen aus diesem Forum zu beantworten. Anstatt jedes mal lange Romane zu schreiben, kann ich nun bequem auf das Buch verweisen. So ist das entstanden und das ist weiterhin der einzige Grund für dessen Existenz. Gleiches gilt für Teile meiner Homepage, auch die eben so oft verweise.
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ß.
Ralph S. schrieb: > In deinem Buch beschreibst du ... Immerhin ist jetzt klar, welches der Bücher du meinst. Ich freue mich über konstruktive Kritik, deswegen auch Dir ein Dankeschön für deine Mühe, das alles aufzuschreiben. Möglicherweise hast du sowohl die Zielgruppe als auch den Sinn des Büchleins missverstanden. Das ist kein Lehrbuch, sondern ein Schnupperkurs für Teenager. Damit sollen die Kids ausprobieren können, was es bedeutet, Mikrocontroller zu programmieren. Danach können sie entscheiden, ob sie das weiter vertiefen wollen oder nicht. Deinen Hinweiss bezüglich fehlender Erklärungen für die GPIO Register kann ich nicht nachvollziehen. Seit der Veröffentlichung hat kein einziger Leser diesen Punkt moniert oder nachgefragt. Die Erklärungen sind ja auch drin. "obsolet": Das Wort kommt weder in dem Büchlein noch in irgendeinem der obigen Beiträge vor. Mit ist nicht klar, worauf die dich da beziehst. Musst du aber nicht weiter erklären, wir können das gerne einfach offen lassen.
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.
:
Bearbeitet durch User
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. :-)
:
Bearbeitet durch User
@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
Schmunzeln muss, da habe ich was aufgemacht: Der TO wollte doch "nur" einen ATtiny2313 über einen Arduino flashen... (ich weiß: ich bin schuld, mea culpa, mea maxima culpa)
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.
Ich wurde schon mehrfach gefragt, ob ich die Bücher nicht Youtube Video präsentieren könnte. meine Meinung dazu: Man muss nicht alles machen, nur weil es machbar ist. Wer nicht einmal dieses kleine 99 seitige Büchlein lesen will, für den ist Elektronik ohnehin das falsche Hobby.
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.
Norbert S. schrieb: > 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 Guten Abend, Ja die Arbeit hat es mir nicht erlaubt vorher mal zu antworten... und die ganzen Diskussionen hier erstmal lesen und verstehen.... Der Töpferkurs ist es nicht geworden da es mit dem UNO, dem Tiny2313 und einem Entwicklungsbord alles so geklappt hat wie ich es mir vorgestellt habe. Für mich als Anfänger war das UNO optimal. Der 2313 reicht für meine Nöten vollkommen aus! Also würde das Arduino Bord jedem Anfänger empfehlen.
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
F. F. schrieb: > Stefan mag da was zusammen gefasst haben ..., aber um die > vielen Seiten Datenblatt kommt man trotzdem irgendwann nicht rum. Genau. Deswegen bin ich ebenfalls nicht von der Idee überzeugt, mit derartig komplexen Mikrocontrollern anzufangen. Ich habe nichts gegen 32bit, aber die Taktversorgung, der NVIC und die Peripherie sind schon erheblich komplexer, als herkömmliche 8bit Mikrocontroller. Ich habe das Fach vom Grund auf gelernt. Erst ein bisschen Elektronik als Hobby (mit Baukästen von Philips und Lehrbüchern von Jean Pütz), dann eine Ausbildung zum Kommunikationselektroniker, dann viele Jahre Berufserfahrung mit Programmierung und steigender Komplexität. Ich bin da ganz langsam herein gewachsen. Mein erster Computer war ein geliehener C64, den konnte ich vom ersten Tag an in Assembler programmieren, weil ich mich Monate vorher schon mit seinem Schaltplan und Datenblättern auseinander gesetzt hatte. Für meinen ersten eigenen 286er PC baute ich Steckkarten, weil ich schon lange vorher wusste, wie der ISA Bus funktioniert. 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. Nein, ich denke heute muss man das Pferd von hinten aufzäumen. Man lernt Autofahren, indem man sich hinein setzt und los fährt. Was unter der Haube passiert, interessiert anfangs kaum. Vermutlich muss man so auch den Umgang mit Mikrocontrollern und Programmierung erlernen. Erst einfach loslegen und später die Grundlagen nur so weit lernen, wie es unbedingt nötig ist. Um alles zu verstehen, reicht die Zeit nicht. Das Problem dabei: Wer sagt dir, was du wissen musst? Zum Beispiel dieses Forum hier. Aber das ist nur etwas für geduldige Leute, die den groben Tonfall ertragen können und sich nicht entmutigen lassen, wenn die vielen Köche unterschiedliche Rezepte empfehlen. Elektronik Entwicklung ist in seiner gesamten Vielfalt erheblich komplexer, als beispielsweise der Job eines Maurers oder Malers. Vielleicht sogar komplexer als Medizin, da sich unsere "Patienten" fortlaufend weiter entwickeln. By the way, dämmert es hoffentlich bald mehr Arbeitgebern, dass viele alte erfahrene Arbeitnehmer mehr wert sind, als man ihnen derzeit eingesteht.
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.
F. F. schrieb: > Heute kannst du vieles für wenig Geld kaufen, was es zu unserer Zeit > kaum gab oder teuer war. 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. Erinnerst du dich noch an die Preise für die ersten CMOS Operationsverstärker? Ich glaube das war knapp unter 10 DM - das wäre nach heutigem Maßstab mindestens 20€. Wahnsinn! Dafür waren Gehäuse, Stecker, Schalter, Kabel (alles, was man von Außen sieht) gefühlt viel billiger, als heute.
SCSI Controller für über 1000 DM. Als angeblich eine Fabrik abgebrannt war, habe ich für 32MB RAM 1600 DM ausgegeben.
:
Bearbeitet durch User
F. F. schrieb: > Als angeblich eine Fabrik abgebrannt war, habe ich für 32MB RAM 1600 DM > ausgegeben. Das habe ich miterlebt, ich konnte mir jahrelang keine neuen RAM Module leisten. Stattdessen hatte ich Riser Karten, womit man 16 alte RAM Module in vier Steckplätze einsetzen konnte. Dafür musste man allerdings die Zugriffsgeschwindigkeit herab setzen. Ach ja, das waren noch Zeiten, als man für jedes Megabyte knausern musste.
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.
Ralph S. schrieb: > 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. Wahre Worte -angesichts des Stusses, den Du hier oft zum Besten gibst.
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
:
Bearbeitet durch User
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
Beitrag #6103939 wurde von einem Moderator gelöscht.
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...
>Häufig hab ich das Gefühl, speziell bei STM32, dass ich einen alten DOS >Rechner programmiere... Tatsächlich? Ich nicht, die DOS Rechner waren deutlich reaktionsschneller.
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.