Guten Tag/Abend allerseits, Ich bin gerade dabei mir meinen ersten Mikrocontroller zu kaufen bzw. zu suchen. Habe bisher ein wenig mit dem Arduino Uno rumgeklimpert. Sprich die Basics abgearbeitet "Blink" etc. Hatte eigentlich den Mega ins Auge gefasst, aber ich möchte mich langfristig ein wenig spezialisieren (Quasi Hobby und Job koppeln) und bin mir nicht sicher, ob Arduino überhaupt die richtige Plattform ist. Ich suche eine Plattform, die bezahlbar ist und auch in der Industrie angewendet wird. Kann mir da jemand mal Schützenhilfe leisten? Danke, Gruß Mike
Schon gelesen: Mit was in die Mikrokontrollerwelt einsteigen? Fing vor ein paar Tagen an. Ist sehr interessant zu lesen.
Wenn du dich zukunfts-/professionell orientieren willst, schau dir lieber etwas "moderneres" wie ARM an; die Wahrscheinlichkeit, in der Industrie darüber zu stolpern, ist vermutlich höher als bei 8bit-Zeug wie AVR. Schau z.B. die STM32 an, mit den STM32 Discovery Boards gibts dazu auch einen günstigen Einstieg.
Arduino Hardware: Ja! Am besten aus China, weil billig. z.B. UNO. Arduino Software - Nein Danke! Besser: AVR-Studio, kostenlos! oder BASCOM-Demo, damit habe ich angefangen. z.B. Programmer USBasp mit 6-poligem Kabel für Arduino UNO, oder das Eval-Board von pollin.
:
Bearbeitet durch User
AVR Studio ist in C? Arduino läuft ja über Processing. Ich lese mir den genannten Thread mal durch. Danke für die schnellen Antworten!
Habe den UNO noch zuhause und bis dato nur mit der Arduino-Software gearbeitet. Kenne C nicht. Habe bis dato nur ein wenig mit Java gearbeitet, aber vermute mal, dass auch zu C hier Schnittmengen vorhanden sind. Womit arbeiten denn die Profis in der Industrie? Läuft da auch alles überwiegend mit C?
D. V. schrieb: > oder BASCOM-Demo, damit habe ich angefangen. BASCOM? Damit ist man in der Industrie ganz bestimmt willkommen :D Mike R. schrieb: > AVR Studio ist in C? C und C++. > Arduino läuft ja über Processing. Und das ist C++, mit einer vordefinierten Library. Mike R. schrieb: > Kenne C nicht. Habe bis dato nur ein wenig mit Java gearbeitet, aber > vermute mal, dass auch zu C hier Schnittmengen vorhanden sind. Nur teilweise die Syntax, die Hintergründe insbesondere zum Speichermanagement sind grundverschieden. > Womit arbeiten denn die Profis in der Industrie? Läuft da auch alles > überwiegend mit C? Das meiste vermutlich C, einiges an C++, C#, Java, Assembler.
Dr. Sommer schrieb: > BASCOM? Damit ist man in der Industrie ganz bestimmt willkommen :D mit BASCOM nicht, aber wenn man später einen eigenen Pascal-Compiler entwickelt hat, schon. Gugst du lex & yacc. Möchte das Forum aber nicht überfordern, weil zu viele Newcomer, vor allem jetzt nach Weihnachten auftauchen :-)
D. V. schrieb: > mit BASCOM nicht, aber wenn man später einen eigenen Pascal-Compiler > entwickelt hat, schon. Diese Logik verstehe ich jetzt nicht... Und klar, wenn man schon so irre ist es mit GCC etc. aufnehmen zu wollen dann muss es natürlich Pascal sein.
D. V. schrieb: > Gugst du lex & yacc. Möchte das Forum aber nicht > überfordern, weil zu viele Newcomer Nett das Du uns nicht überfordern willst :-) Bei lex & yacc haben hier bestimmt einige Leute Probleme, wach zu bleiben^^ Weck uns doch einfach, wenn der AST fertig ist und Du gerade versuchst Deine SSA-instructions in was ausführbares mit nur endlich vielen Registern zu verwandeln.
In Deinem Fall empfehle ich ebenfalls den STM32. Ein ARM Prozessor wird in Firmen gerne eingesetzt. Das STM32F4DISCOVERY Borad gibt es, incl Debugger, für ca. 20 EUR. Wenn Du flexibler sein willst empfehle ich ein Board von hier (30€): http://re.reworld.eu/de/produkte/s64dil-405/index.htm Das ist direkt Steckbretttauglich und hat nicht so viel zeug drauf, das man für eigene Entwicklungen nicht braucht. Dazu empfehle ich einen SEGGER J-LINK EDU, kostet ca. 50 EUR und der ist eines der besten und schnellsten Debugger und kann für nahezu alle ARM-Prozessoren (CortexMx, ARM7, ARM11, ARM15...) eingesetzt werden. Damit schaffst Du die Grundlage um im Job/Bewerbung auch gut da zu stehen. Zu Anfang reicht ein STM32F4DISCOVERY vollkommen aus, somit halten sich die Investitionen in überschaubare Grenzen. Als Entwicklungsumgebung gibt es das kostenlose Coocox. Lese mehr darüber im Artikel: STM32
:
Bearbeitet durch User
Hallo! Ich bin auch Neuling was Arduino&Co angeht (bisher nur C-Control und Excel VBA), habe da aber etwas Geniales über Kickstarter.com gefunden: Ein Arduino mit WLAN! in Chip-Größe (14x8 PINs) mit TI CC3000 WLAN-Chip, der sich außerdem jederzeit über's Web umprogrammieren lässt: http://www.SPARK.IO bzw. http://docs.spark.io Ich hab beim Kickstarter-Projekt mitgemacht, und die ersten 3 Samples liegen hier, das erste Prg. ist geschrieben. Inzwischen lässt sich das Teil auch normal ordern. Es gibt auch einen Arduino-Shield und einige andere Shields dazu, wenn man nicht selbst basteln will. EINFACH GENIAL!
Ansonsten, lese hier: Beitrag "Mit was in die Mikrokontrollerwelt einsteigen?" In dem empfehle ich dem TE allerdings einen AVR und keinen STM32 wie Dir.
Wenn du verstehen willst, bleib erst mal bei dem 8-Bittern. Die Funktionalität bei den ARMs geht auch einher mit Komplexität, die du vermutlich noch nicht überschaust, das kann schnell frustrieren. Ich weiß, jetzt kommt als nächstes wieder der Beißreflex, dass die ARMs ja kinderleicht zu programmieren sind und überhaupt viel besser und 8-Bitter sind ja eh veraltet und blah. Wenn dir tatsächlich was dran liegt, zu verstehen, was du treibst, dann nimm dir irgendeinen 8-Bit-Prozessor (ausgenommen PIC[1]) und programmiere mit Assembler. Nicht, weil du später große Projekte in Assembler schreiben wirst, sondern damit du deinen Prozessor verstehst. Der Schritt zur Hochsprache ist anschließend ein leichter. Wenn du später dann in C o.ä. programmierst, hast du im Hinterkopf immerzu eine Vorstellung davon, was deine C-Befehle tatsächlich anstellen - das ist eine Erfahrung, die nicht zu ersetzen ist[2]. Beim AVR und C beispielsweise wüsstest du sofort, warum die Schiebeoperatoren '>>' und '<<' gefährlich sein können. [1] Auch das wird wieder einen Beißreflex auslösen. Diesemal bei PIC-Jüngern. Und auch dazu stehe ich und rate jedem Einsteiger eindringlichst von PIC12/16/18 ab. Begründungen dazu in diversen Threads, ich habe keine Lust, das nochmal durchzuexerzieren weil ja doch kein Argument gut genug ist und aber, aber, aber. [2] Natürlich ist ein ARM leicht zu programmieren, es gibt ja jede Menge Funktionsbibliotheken, um die Hardware anzusteuern. Und die sollte man natürlich auch verwenden. Aber es trägt dir zum Verständnis effektiv nichts bei, wenn du immer ganz weit oben und ganz easy mit solchen Funktionen hantierst und nicht weißt, was du eigentlich mit der Hardware anstellst. Und es macht auch keinen Spaß, im Einzelfall dann durch die Funktion durch runter zur Hardware herumzustochern. Meine drei Groschen dazu..
Den Thread habe ich durch... Naja fast :) Da wird ja zwischen Arduino und AVR gesprungen. Dachte eigentlich zum Starten an sowas: http://m.ebay.de/itm?itemId=261114223399 Preislich im Rahmen und man hat jede Menge "Probleme" zu lösen. Das ganze als Basis ist doch ok oder? Vllt noch ergänzend: Ich bin Maschinenbauer. D.h., dass es mir vor allem um Mechatronik geht. Sprich wenn Sensor A den Wert X liefert soll Aktor B was weiß ich machen. Das ging mit dem Uno ganz gut und einfach, aber das ist ja kein Fleisch und kein Brot. Toll bei den Arduinos ist auch die verfügbare Hardware an Shields etc. Will aber langfristig mir meine eigene Platine basteln können, die meinen Anwendungsfall abdeckt und nicht immer das passende Shield suchen.
Assembler hatten wir damals im Grundstudium... D.h. gewisser Hintergrund ist vorhanden. Muss ich nicht nochmal haben. Viel zu aufwendig.
Sieht gut aus, damit lässt sich schön viel anstellen. Jedoch eines wirst Du noch dazu benötigen, ein JTAG-Interface: Am besten einen J-LINK EDU von Segger. Wenn es billig sein soll, dann geht auch ein J-LIN/V2 von ST. Ich habe 3 verschiedene und bin mit dem von Segger am besten zu frieden. Vor allem liefert Segger einen Super Service.
Arduino als Hardware zum schnell was probieren, oder wenn es auf die Größe nicht ankommt ein Shild selbst machen ist ganz OK. Die IDE verwende ich nicht. AVR-Studio und ein AVRISP mkII sind universell einsetzbar.
Mike R. schrieb: > Assembler hatten wir damals im Grundstudium... > D.h. gewisser Hintergrund ist vorhanden. Muss ich > nicht nochmal haben. Viel zu aufwendig. Ich dachte, du wolltest dich spezialisieren. Leute, die irgendwie abstrakt auf nem Controller rumeiern, gibts genug, da wartet niemand auf dich.
Sorry, habe ich Dir falsch geschrieben, auf das Board wird ja ein Standard Discovery Board gesteckt, das hat schon einen ST-LINK/V2 von ST mit drauf, also benötigst Du erst mal kein Segger J-LINK.
:
Bearbeitet durch User
Sven P. schrieb: > (ausgenommen PIC[1]) Dem kann ich nicht zustimmen. Ich habe mit PIC angefangen und bin gut damit zurechtgekommen. Mike R. schrieb: > Assembler hatten wir damals im Grundstudium... Welchen µC habt ihr Verwendet? Spricht etwas bei diesem zu bleiben?
Sven P. schrieb: > Mike R. schrieb: >> Assembler hatten wir damals im Grundstudium... >> D.h. gewisser Hintergrund ist vorhanden. Muss ich >> nicht nochmal haben. Viel zu aufwendig. > Ich dachte, du wolltest dich spezialisieren. > > Leute, die irgendwie abstrakt auf nem Controller rumeiern, gibts genug, > da wartet niemand auf dich. Damit wollte ich sagen, dass ich grundsätzlich weiß, was auf/in einem Controller los ist. Will mich nicht im Bereich der µC´s spezialisieren, sondern in der Anwendung dieser bei techn. Lösungen. Ich sehe häufig im Alltag mechanische Lösungen, die mit ein/zwei Sensoren/Aktoren eben günstiger zu lösen wären. Die Reise geht nun mal in diese Richtung (Mechanik durch Elektronik ersetzen) und da ist man als Maschinenbauer gut gerüstet, wenn man davon einen Plan hat. Teilweise wüsste ich mit meinem Halbwissen ja schon, wie ich manche Dinge mit einem Arduino lösen könnte. Da diese Plattform aber überwiegend an Schulen, Unis und FHs eingesetzt wird, bringt mir das mehr, wenn ich meinen Horizont bspw. mit C etc. erweitere. Und die Jungs, die bspw. mit C umgehen können, dazu noch Matlab mächtig sind und darüber hinaus noch wissen, wie man mit einem Stück Eisen umgeht, gibt´s eben nicht wie Sand am Meer. ;)
Mike R. schrieb: > Ich sehe häufig im > Alltag mechanische Lösungen, die mit ein/zwei Sensoren/Aktoren eben > günstiger zu lösen wären. Dann würde ich sagen, dass ein 8 bit Controller das ist was du suchst.
M. H. schrieb: > Sven P. schrieb: >> (ausgenommen PIC[1]) > Dem kann ich nicht zustimmen. Ich habe mit PIC angefangen und bin gut > damit zurechtgekommen. Mein Beileid dazu. Also zu PIC. Mike R. schrieb: > Damit wollte ich sagen, dass ich grundsätzlich weiß, was auf/in einem > Controller los ist. Ich bezweifle das einfach mal. Denn andernfalls würde sich die Frage nach 'deinem Ersten' schnell erübrigen. Die Umstände, die du da beschreibst, halte ich für unbedingt sinnvoll. Den Trend hast du ja schon erkannt. Ich komme allerdings nun ins Zweifeln, ob Mikrocontroller dafür der richtige Weg sind und ob du nicht besser mit einer Kleinsteuerung (kleine SPS, Easy, Logo oder sowas) besser bedient wärst. Nichtsdestotrotz würde ich mit Mikrocontrollern weitermachen. Aber erstmal als Hobby und nicht, um gleich irgendwelche praktischen Probleme zu lösen. D.h., bau dein Grundstudium aus und verstehe. Danach wirds einfacher.
Wenn Du etwas in eine Industriemaschine einsetzen willst, dann muss ich von jedem Prozessor abraten. In der Industrie sind Ausfallsicherheit und Wartbarkeit (HW-Tausch) an aller oberster Stelle. Daher überlege Dir genau was für Ziele du hast. In Industrieanlagen werden hauptsächlich (in D) Siemens-Steuerungen eingesetzt. Auch andere Hersteller wie z.B. Beckhoff oder Mitsubishi und Allen Bradley (USA) sind bekannte Hersteller. Über normierte Signale (0..10V, 4..20mA, Profinet, usw.) werden die Einzelbaugruppen zusammen geschlossen und das ganze hat dann auch entsprechend zu funktionieren. Wenn Du jetzt mit einem "Selbstbau-Board" daher kommst, mag das im Einzelfall in Deiner Firma funktionieren, aber sobald das ganze zu einem externen Kunde geht schon nicht mehr. Da tauchen gleich mal Fragen auf wie z.B. Lieferbar die nächsten 10 Jahre? Kannst Nur Du das machen oder kann das auch ein anderer Programmierer/Techniker (Abhängigkeit von nur einer Person mögen die überhaupt nicht)? Ein STM32 ist eher geeignet für HW-Entwicklung für Geräte die ein Hersteller fix fertig zusammen baut und man arbeitet in dieser Firma. Wenn man viele Jahre Erfahrung mit Elektronik Entwicklung hat und genau weiß wie man ein Gerät Stör- und Ausfallsicher herstellt, dann kann man auch sowas für einen Schaltschrank bauen - wobei diese beiden Fragen man dennoch beantworten können muss. Denn erst mal gibt es für eine Firma keinen Vorteil "Sonderbaugruppen" ein zu setzen, nur Nachteile. Wenn die Produktion steht und nicht innerhalb weniger Stunden der Fehler beseitigt ist, dann wird es unangenehm. Wenn die Produktion gar mehrere Tage steht wird es richtig ungemütlich. (Ich spreche aus Erfahrung, denn ich habe auch schon ähnliches gemacht, jedoch NUR bei Teilen die nicht relevant für eine Produktion waren, alles andere war mir zu Heiß.)
:
Bearbeitet durch User
Hubert G. schrieb: > Arduino als Hardware zum schnell was probieren, oder wenn es auf die > Größe nicht ankommt ein Shild selbst machen ist ganz OK. Die IDE > verwende ich nicht. AVR-Studio und ein AVRISP mkII sind universell > einsetzbar. Würde ich auch empfehlen. Testweise kannst Du Dir die AVR-Studio Version 4.19 einmal installieren. Ansonsten kannst Du auch reinen C-Code in den Editor der Arduino-IDE kopieren, übersetzen und ausführen lassen. Als Beispiel dafür könnte ich Dir ein Programm geben, was Frequenz und Drehzahl eines Sensors mit hoher Genauigkeit+Auflösung mißt. Es ist mit AVR-Studio geschrieben und läuft nach Umbennenung auf *.ino in der Arduino-IDE. Da es ein C-Quellcode ist, wirst Du setup() und loop() vergeblich suchen.
Auch meiner Meinung nach ist eine selbstgestrikte Mikrocontrollerlösung nicht für den Industrieeinsatz geeignet. Erst recht kein Arduino. Dafür gibt es, wie schon angedeutet, SPS Steuerungen. Ich, als Programmierer im Sondermaschinenbau, würde einen Maschinenbauer nicht ernst nehmen, wenn dieser mit solchen Bastellösungen um die Ecke kommt. Ich habe da schon Dinge gesehen, sie für sich nicht schlecht konstruiert waren, aber hinterher weggeschmissen wurden, weil der damalige Erbauer nicht mehr greifbar war. Oft werden wir auch von Firmen gerufen, die ähnliche Lösungen einsetzen und jetzt nicht mehr klarkommen. Da bleibt auch nur die Tonne. Das wirft im Nachhinein kein gutes Licht auf den Konstrukteur! Kauf dir einen Beckhoff Controller + E/A Klemmen, die kosten nicht viel, sind im Fall eines defektes leicht zu ersetzen, sind für Dauerbetrieb ausgelegt, lassen sich auch von anderen Leuten händeln usw.... Es gibt auch andere Lösungen auf dem Markt!
Mike R. schrieb: > Arduino läuft ja über Processing. Nein, s.u. m.n. schrieb: > Ansonsten kannst Du auch reinen C-Code in den Editor der Arduino-IDE > kopieren, übersetzen und ausführen lassen. Als Beispiel dafür könnte ich > Dir ein Programm geben, was Frequenz und Drehzahl eines Sensors mit > hoher Genauigkeit+Auflösung mißt. Es ist mit AVR-Studio geschrieben und > läuft nach Umbennenung auf *.ino in der Arduino-IDE. Da es ein > C-Quellcode ist, wirst Du setup() und loop() vergeblich suchen. Das ist auch nicht weiter verwunderlich. Der Arduino (also der AVR auf dem Board) wird in echtem C programmiert, übersetzt wird mit dem avr-gcc. Lediglich die IDE ist jede von Processing. Für die Visualisierung auf dem PC wird dann Processing benutzt.
ich würde dir auch einen 8bit µC empfehlen und mit Assembler anfangen ich finde dieses Hintergrundwissen sollte man haben auch wenn man später vielleicht auf eine Hochsprache umsteigt.
Da haben wir jetzt aneinander vorbei gesprochen. Die Bastellösungen sind für den privaten Gebrauch. Verwendet man SPS denn auch in mobilen Anwendungen? Mit welcher Begründung sollte ich mich nochmals mit Assemblercodes rumschlagen? Wo hilft einem das weiter? (ernst gemeinte Frage) Nochmals... Ich möchte mich hobbymäßig damit Beschäftigen, aber es soll mir auch auf professioneller Ebene etwas bringen.
Kommt jetzt jeden Tag ein neuer Thread mit "Welcher Mikrocontroller", "wie fange ich an" und alle steigen drauf ein wie die Beißer aus Walking Dead und erzählen immer die gleiche Leier...
Mike R. schrieb: > Nochmals... Ich möchte mich hobbymäßig damit Beschäftigen, aber es soll > mir auch auf professioneller Ebene etwas bringen. Dann hast Du es ja schon gefunden - das Board von EBAY.
ich habe SPS bisher nur in stationären Anlagen z.B. Autowaschanlage gesehen
:
Bearbeitet durch User
Mike R. schrieb: > Mit welcher Begründung sollte ich mich nochmals mit Assemblercodes > rumschlagen? Wo hilft einem das weiter? (ernst gemeinte Frage) Es hilft dir immer dann weiter, wenn du nicht mehr weiterkommst... Ich schreib jetzt einen Artikel dazu. Es nervt, das in jedem Thread wieder runterzubeten.
Hab mir das grad aus den Fingern gesaugt: http://www.mikrocontroller.net/articles/Benutzer:Haku/F%C3%BCr:Assembler
Nimm einen AVR und keinen PIC oder 32-Bitter. Grund: - Kostenloses rundum Sorglospaket mit Atmel Studio, also kein nerviges zusammenklemptnern einer IDE - C sowie Assembler dabei - günstige Controller - überschaubare Datenblätter - viele Beispiele im www - Simulator - Aufbaumöglichkeiten mit den SAM-Controllern (32-Bit) ohne IDE-Wechsel möglich - AVR isp mk2 für 40€
Sven P. schrieb: > Hab mir das grad aus den Fingern gesaugt: > http://www.mikrocontroller.net/articles/Benutzer:Haku/F%C3%BCr:Assembler Wenn Du jetzt den Titel so abänderst: "Warum STM32 anstatt AVR nutzen", dann würde Dein Text perfekt passen. Denn beim STM32 braucht es keinen "Read-modify-write" für die Port-Ausgabe. Da gibt es extra Setz-/Rücksetzregister und somit ist das ganze "Threadsicher" und es gibt keine komischen Effekte bei Interrupts. Das andere sind C Basics, die man einfach lernen muss.
Markus Müller schrieb: > Wenn Du jetzt den Titel so abänderst: > "Warum STM32 anstatt AVR nutzen", dann würde Dein Text perfekt passen. Super Deal. Wenn man immer nur vor Problemen davonläuft, lernt man aber nichts. Ich weiß selbst, dass andere Architekturen diese Probleme anders lösen. Aber um zu verstehen, warum man z.B. solche Setz/Rücksetz-Register in den Adressraum pinnt, muss man erstmal verstehen, was überhaupt schiefgehen kann. Und das geht hervorragend mit so nem 8-Bitter, beispielsweise. > Das andere sind C Basics, die man einfach lernen muss. Das sind keine Basics, sondern Eigenheiten der Architektur. C kennt keine Interrupts.
Jetzt nochmal für Anfänger.... Das hier: ldi r16, 0xFF out $17, r16 ldi r16, 0x01 com r16 Loop: out $18, r16 rjmp Loop ist doch Assemblercode oder nicht? Du meinst, dass ich Assembler brauche, damit ich weiß, was wo im Register passiert und ich dann durch "übersetzen" nachvollziehen kann, warum es klemmt?
Ja, zum Beispiel. Oder um zu verstehen, warum das letzte Beispiel mit PORTE/PORTF in meinem Artikel nicht funktioniert.
Man muss nicht unbedingt Assembler können oder es aktiv programmieren. Es geht eher darum, dass man die internas des Controllers im Prinzip kennt. Also eben was so im Datenblatt steht. Was Register sind, was die Bits darin so tun, wie der Speicher aussieht usw usw. Dieses Wissen erlangt man aber sehr gut, in dem man sich mit Assembler beschäftigt. Dazu gehören auch Einsichten, wie z.B. dass es einen enormen Unterschied in der Codegröße macht, ob man nun zwei Bytes multipliziert/dividiert oder 2 doubles. Aber ich würde sehr schnell auf C umsteigen und nicht großartig in Assembler entwickeln. Der Aufwand lohnt einfach nicht. Das oben genannten Wissen sollte man sich trotzdem aneignen. gruß cyblord
:
Bearbeitet durch User
Sven P. schrieb: > Hab mir das grad aus den Fingern gesaugt: > http://www.mikrocontroller.net/articles/Benutzer:H... Super! Vor allem ohne dür Anfänger zu erklären warum schmeißt du einfach um die Ohren "wie toll du bist"!
sps schrieb: > Super! Vor allem ohne dür Anfänger zu erklären warum schmeißt du einfach > um die Ohren "wie toll du bist"! Ja, das kann ich halt besonders gut. Ich habe aber auch explizit drangeschrieben, dass ich mir das schnell aus den Fingern gesaugt habe. Das impliziert m.A.n., dass ich noch daran weiterschreiben werde und die Probleme erkläre.
Sven P. schrieb: > Ja, zum Beispiel. > > Oder um zu verstehen, warum das letzte Beispiel mit PORTE/PORTF in > meinem Artikel nicht funktioniert. Wenn man erstmal C kann... Wie gesagt, haben im Bachelor damals dazu ein paar Vorlesungen und Praktika gehabt. 8 Leds nacheinander aufblinken lassen etc. Ob´s reicht weiß ich jetzt noch nicht und würde dann ggf. mich nochmal hinsetzen... Assembler ist ja nun wirklich kein Kunstwerk und die Verknüpfung zwischen Assembler und µC auch nicht. Wenn ich merke, dass das notwendig ist, kann ich ja zur Wurzel allen Übels zurückkehren.
Sven P. schrieb: > Hab mir das grad aus den Fingern gesaugt: > http://www.mikrocontroller.net/articles/Benutzer:H... Gefällt mir! Auch wenn es sicher wieder Leute gibt, die einem erklären, dass es diese oder jene Probleme auf einem anderen Controllertyp nicht oder anders geben würde, es hilft gut, einem die grundsätzlichen Probleme bei Nebenläufigkeit bewusst zu machen. Und das geht wirklich am ehesten in Assembler. Und solche Probleme existieren auf jeder Maschine. Je höher die Programmiersprache ist, desto leichter fällt man damit auf die Nase. Ein anderes Beispiel wären Additionen (z.B. bei 32-Bit-Zählern), die nicht atomic ablaufen. Die 8-Bit-AVR z.B. addieren maximal 16 Bits mit einem Befehl. Natürlich kennt ein 32-Bit-Prozessor dieses Problem nicht, dafür tritt es bei komplexeren und weniger leicht verständlichen Datenstrukturen doch wieder auf. Gut, wenn man es einmal in einfacher Umgebung verstanden hat.
Kommt drauf an in welche Richtung du später gehen willst. Industrielle Produktionsanlagen : ==> SPS und kein µC Consumer Geräte: Waschmaschinen, ..... ==> 8 Bit und 16 Bit Controller Multimedia Geräte,... ==> 32 Bit Arm in verschiedenen Ausführungen bis hin zu SOC Automobilbereich : sicherheitsrelevant ? JA: ( ABS, Motorelektronik,...) ARM µC in Lockstep Architektur zb: http://www.ti.com/ww/de/prod_mcu_hercules.html Oder Infineon MultiCore mit Lockstep Architektur NEIN: 8, 16 , oder 32 Bit µC in beliebiger Verteilung Immer wichtiger im Automobilbereich ist die Unterstützung des AUTOSAR Standards. Also da mal etwas suchen ob der bevorzugte µC dort gelistet ist. Ansonsten gibt es da noch viel mehr Bereiche zum Einsteigen, muss man halt etwas suchen. Sinn macht es erst zu entscheiden wo die eigene Entwicklung hingehen soll. Und DANACH zu wählen, was für die entsprechende Richtung der richtige Typ ist. Abgesehen davon SOOO groß sind die Unterschiede zwischen den einzelnen µC gar nicht. Jeder hat da so seine Vor und Nachteile die einiges einfacher und anderes schwieriger machen. DEN idealen µC gibt es einfach nicht. Und mal ganz ehrlich die Diskussion welcher µc einfacher zu konfigurieren ist, ist doch absoluter Unsinn. Der Weg ist immer der Gleiche. 1. Blick ins Datenblatt welche Register für diese Funktion benötigt werden. 2. Werte ermitteln die in die Register eingetragen werden. 3. Werte ins Register schreiben Da machte es GAR KEINEN UNTERSCHIED ob es ein AVR, 8051/2, ARM,...... ist. Stimmt schion es gibt Unterschiede. Die Register haben anderen Namen, andere Adressen, andere Bitbedeutungen,... Aber es steht doch alles im Datenblatt. Und ob ich jetzt einen AVR oder einen ARM das erste mal vor mir liegen hab. Ich brauch in allen Fällen die oben beschriebenen Schritte. Und bei der Sprache. C sollte sattelfest sitzen. C++ nichts unbekanntes sein. Asssembler muss man wenigstens so weit beherrschen das man mit dem Debugger arbeiten kann. In Assembler zu programmieren macht heute niemand mehr weil durch den viel höheren Aufwand die Kosten einfach zu hoch sind im Vergleich zu dem nutzen den man aus Assemblerprogrammierung ziehen könnte. In der Regel soll das Produkt ja später verkauft werden und da ist der Preis ein extrem wichtiges Kriterium.
Mike R. schrieb: > Mit welcher Begründung sollte ich mich nochmals mit Assemblercodes > rumschlagen? Wo hilft einem das weiter? (ernst gemeinte Frage) z.B. bei Zeitkritischen Sachen.
M. H. schrieb: > Mike R. schrieb: >> Mit welcher Begründung sollte ich mich nochmals mit Assemblercodes >> rumschlagen? Wo hilft einem das weiter? (ernst gemeinte Frage) > z.B. bei Zeitkritischen Sachen. Bei Fehlern im Compiler.
M. H. schrieb: > Mike R. schrieb: >> Mit welcher Begründung sollte ich mich nochmals mit Assemblercodes >> rumschlagen? Wo hilft einem das weiter? (ernst gemeinte Frage) > z.B. bei Zeitkritischen Sachen. Nein. Beim Cortex-M3 (STM32) ist ein Cyclecounter implementiert, den kann man bei einer Programm-Position auslesen und bei der zweiten wieder. Und somit kann man genau feststellen wie viele Taktzyklen der Prozessor benötigt hat. Ganz ohne Assemblerkenntnisse. Ich musste auch schon eine Analyse durchführen wie lange eine AD/Wandler Konvertierung benötigte, da das ganze mit 5µs getaktet war, denn die Main-Schleife incl anderen Interrupts musste auch noch genügend Reserve haben. Ralf schrieb: > Wenn du RAM und ROM sparen willst bei einem kleinen uC Das Problem gibt es erst gar nicht beim STM32 ;-)
:
Bearbeitet durch User
Dann schaue doch mal oben nach, was für ein Demo-Board Mike R. heraus gesucht hat, daraus kannst Du ableiten was er gerne so alles in nächster Zeit machen will (Richtung: Eierlegende Wollmilchsau). Und dann überlege nochmal welcher µC dafür besser geeignet ist.
:
Bearbeitet durch User
Markus Müller schrieb: > Und dann überlege nochmal welcher µC dafür besser geeignet ist. Wenn ich es mir genau überlege, komme ich auf einen µC von Renesas. Die diese nicht kennen, können nichts dagegen sagen, und die, die sie kennen, werden mir nicht widersprechen ;-)
Renesas, M16C, ich hatte den auch schon - und wieder in den Müll geschmissen. Nicht weil die so schlecht sind, sondern weil die schwer zu bekommen sind. Tolle Homepage, viele Typen, aber nicht/schwer für Hobbyisten zu kaufen.
Glaube ich hole mir erstmal nur das STM32F4 Discovery... Dazu hole ich mir noch ein Brotbrett und stecke ein wenig rum... 20€ sind als Fehlinvestition ggf zu verkraften. Dann kann ich ja erstmal quasi das gleiche wie mit nem Arduino machen. Á la Blink etc... Vor der IDE graust es mir ein wenig bei dieser Geschichte... -_-
Der STM32F4DISCOVERY hat je Stiftleiste 2 Reihen und ist somit nicht direkt Steckbrettauglich. Dennoch ist der nicht schlecht für den Anfang.
Hi, Ingo schrieb: > Nimm einen AVR und keinen PIC oder 32-Bitter. Grund: > - Kostenloses rundum Sorglospaket mit Atmel Studio, also kein nerviges > zusammenklemptnern einer IDE > - C sowie Assembler dabei > - günstige Controller > - überschaubare Datenblätter > - viele Beispiele im www > - Simulator > - Aufbaumöglichkeiten mit den SAM-Controllern (32-Bit) ohne IDE-Wechsel > möglich > - AVR isp mk2 für 40€ Also da schreibt ja mal wieder einer mit VOLL der Ahnung... Also ehrlich.... Ich stimme zwar so weit zu das 32Bitter in der Regel für Anfänger schwieriger sind als 8Bitter wenn es darauf ankommt wirklich alles zu überblicken - aber die für und wieder haben wir im anderen Thread schon hin und her gewälzt. Aber die begründung für keinen Pic und warum der AVR so besser als PIC ist, das ist der reinste Blödsinn - denn in ALLEN genannten Kriterien ist der PIC mindestens ebenbürtig, wenn nicht sogar deutlich vorne. > - Kostenloses rundum Sorglospaket mit Atmel Studio, also kein nerviges > zusammenklemptnern einer IDE Auch bei PIC der Fall. Sogar für Windows, Linux und Mac je eine sofort LAuffähige Version. > - C sowie Assembler dabei Dito PIC. > - günstige Controller Dito PIC, für Schüler & Studenten mit (Hoch-)Schulmailadresse sogar ~10Pics kostenlos frei Haus pro Monat möglich - Auch die teuren!-... Wenn man es nicht übertreibt... (m.W. ist derzeit nur TI ähnlich Großzügig bei NichtFirmen) > - überschaubare Datenblätter Dito PIC, wobei ich -und nicht wenige andere- die Microchip Datenblätter übersichtlicher finden. Mag aber Geschmackssache sein. > - viele Beispiele im www Dito PIC, wobei für PIC die Anzahl der Beispiele und Libs direkt von Microchip selbst mit klar geklärter Lizenzlage größer ist. KEIN Nerviges Zusammensuchen der Codeschnippsel > - Simulator Dito Pic, brauche ich aber quasi nicht DA: > - AVR isp mk2 für 40€ PicKit3 für ab 20 Euro, fast unkaputtpar, Quelloffen und MIT Debugfunktion. Bemerkung am Rande: Das PicKit2 kann sogar AVR Programmieren, ist nur leider für die ganz neuen PICs nicht mehr geeignet... Beim PIC ist überdies kein Verfusen möglich und der PK3 hat den HV Programming Mode als Standard... > - Aufbaumöglichkeiten mit den SAM-Controllern (32-Bit) ohne IDE-Wechsel > möglich Bei Pic alle aktuellen Controller mit derselben IDE und Programmer, vom kleinsten 10F200 im SOT23/5 bis zum derzeit (noch) größten µC in Serienproduktion PIC32MX795F512 mit 32Bit MIPS Kern. Dazwischen sind noch die "normalen" 16Bit PICs und die 16Bit DSPics mit DSP Funktionen. Alles dieselbe IDE und Programmer Dazu kommt dann noch das von Microchip auch heute noch alle Controller die mit 40 oder weniger Pins auskommen auch in DIP verfügbar sind, selbst 32Bitter. Auch die neuesten Versionen. Diese breite an Gehäusevarianten pro Controller bieten nur wenige. (Betrifft natürlich in erster Linie die Breadboard oder Lochrasterfraktion) Wie gesagt, ich sage nicht das die PIC für einen Anfänger jetzt tatsächlich die beste Wahl sein müssen und niemals ein AVR in Frage kommt. Aber ich sage ganz klar das die PIC Familie mindestens genauso gut geeignet ist und nur kleinigkeiten den Unterschied machen. Persöhnlich finde ich das die einen Hauch Vorsprung hat. Aber grundsätzlich kommt es immer auf die Umstände an: Machen im Bekanntenkreis schon viele was mit dem AVR so ist der AVR sicher die bessere Wahl. Genauso wie wenn man probleme mit der Englischen Sprache hat da der AVR im deutschen Sprachraum bei den Bastler weiter verbreitet ist. ISt man fachlich vorbelastet (Beispielsweise Student ET oder INF) und weiß schon das es später schnell in die Richtung Multimedia und ähnliches geht dann kann auch der direkte Einstieg mit 32Bit (Ob jetzt STM32 (ARM) oder PIC32 (MIPS) ist dabei völlig gleich) die bessere Wahl sein. Was aber einige hier absondern zeigt entweder das die wirklich überhaupt keine Ahnung haben und nur irgendwas nachplappern um "IHREN" AVR so hochzujubeln, oder sie sind derart Ignorant das die auch heute noch beim Wörtchen PIC nur an den mittlerweile 20Jahre PIC16F84 denken und diesen dann mit einem XMEGA vergleichen) (Ok, vor 20 Jahren wurde der als PIC16C84 eingeführt und hatte statt Flash einen EEPROM-Programmspeicher, 16F84 schimpft der sich erst seit 15Jahren...) Wobei ich heute aber auch sage: Wenn mit PIC anfangen, dann mit einem 18er und nicht mehr mit den 16er. Die 16er haben ganz klar Ihre Berechtigung -besonders im XLP und/oder HighVolume Bereich-, aber die 18er sind ganz klar einsteigerfreundlicher. Und zu Assembler: Es ist sicher nicht verkehrt sich zuerst ein paar Stunden mit Assembler zu beschäftigen um wirklich zu verstehen was dann später da abläuft. Auch ist es beim Debuggen sehr vorteilhaft. Aber das man ASM als Einsteiger heute noch perfekt beherrschen muss ist sicher lange vorbei. Aber ein Programm das auf Tastendruck eine LED blinken lässt zuerst in ASM zu schreiben ist sicher nicht verkehrt. Dann sollte es aber HEUTE auch erst einmal reichen und man kann mit C weitermachen... Gruß Carsten
:
Bearbeitet durch User
Mike R. schrieb: > Da wird ja zwischen Arduino und AVR gesprungen. Obwohl dieser Eintrag anscheinend öfter entsteht, geht ees eigentlich um die Frage, ob 8-Bit oder 32-Bit für Einsteiger (!) besser geeignet sind. Die Frage Arduino oder AVR ist bezüglich der Hardware nur sehr bedingt aufregend, weil der Arduino ein ATMEGA328, aka AVR, ist. Grüße Andreas
Markus Müller schrieb: > M. H. schrieb: >> Mike R. schrieb: >>> Mit welcher Begründung sollte ich mich nochmals mit Assemblercodes >>> rumschlagen? Wo hilft einem das weiter? (ernst gemeinte Frage) >> z.B. bei Zeitkritischen Sachen. > > Nein. Beim Cortex-M3 (STM32) ist ein Cyclecounter implementiert, den > kann man bei einer Programm-Position auslesen und bei der zweiten > wieder. Und somit kann man genau feststellen wie viele Taktzyklen der > Prozessor benötigt hat. Ganz ohne Assemblerkenntnisse. Ich glaube, da hast Du M.H. falsch verstanden. ASM hilft Dir hier, wenn Du z.B. extrem wenig Zeit ist in einer IRQ Routine, so dass selbst das sichern der Register zu lange dauern würde. Die Shadow Regs des M3 helfen Dir ja bei nested IRQs nur auf dem ersten Lvl, oder ? Grüße Andreas
Carsten Sch. schrieb: > Es ist sicher nicht verkehrt sich zuerst ein paar Stunden mit Assembler > zu beschäftigen um wirklich zu verstehen was dann später da abläuft. > Auch ist es beim Debuggen sehr vorteilhaft. Ich habe in der Schule ca. 1 Semerster die PIC16 Basics in ASM gelernt. Privat mache ich C auf dem PIC18, für was kleines PIC12 und ich denke darüber nach mir den PIC24 anzusehen. Wenn man mal in ASM verstanden hat, wie das mit den Registern und so läuft, ist es kein Problem das auf C zu übertragen. Der Vorteil ist, dass einem der Compiler viel abnimmt, vor allem bei Rechnungen mit >8bit, if, schleifen... Der Nachteil ist aber, dass man nicht genau weiß was der Compiler aus dem C-Code und also der µC macht. Ich bin der Meinung, dass man ein paar einfache Übungen in ASM machen sollte (werde ich beim PIC24 auch machen), dass man später dann nicht auf die Idee kommt, für irgendwas float zu verwenden, dass man in einer int mit festkomma lösen könnte und versucht wenn möglich 8bit Datentypen (bei 8bit µcs) zu verwenden. Andreas H. schrieb: > Ich glaube, da hast Du M.H. falsch verstanden. ASM hilft Dir hier, wenn > Du z.B. extrem wenig Zeit ist Ja, das meine ich. Ich habe z.B. mal eine Rechnung von ca. 20 Zyklen (C) auf 9 (ASM) optimiert.
:
Bearbeitet durch User
Carsten Sch. schrieb: > Aber ich sage ganz klar das die PIC Familie mindestens genauso gut > geeignet ist und nur kleinigkeiten den Unterschied machen. PIC16 ist die einzige mir bekannte Mikroprozessorarchitektur, für die man keine rekursiven Funktionen (oder sich gegenseitig aufrufende Funktionen oder eine Funktion, die aus Hauptprogramm- und Interrupt aufgerufen werden kann) kompilieren kann...
Sven P. schrieb: > Carsten Sch. schrieb: >> Aber ich sage ganz klar das die PIC Familie mindestens genauso gut >> geeignet ist und nur kleinigkeiten den Unterschied machen. > PIC16 ist die einzige mir bekannte Mikroprozessorarchitektur, für die > man keine rekursiven Funktionen (oder sich gegenseitig aufrufende > Funktionen oder eine Funktion, die aus Hauptprogramm- und Interrupt > aufgerufen werden kann) kompilieren kann... Das ist keine Frage der Architektur sondern eine Frage des Compilers! Und hier könnte man sich streiten ob es (im übertragenen Sinn) ein "BuG" oder "Feature" ist. Denn Rekursionen, richtig angewandt, können einen das Programmiererleben erheblich erleichtern. Das stellt wohl niemand ersnthaft in Abrede. Nur Allzuoft ergeben die aber bei der Compilierung riesige Codeabschnitte für etwas wo man iterativ mit einem (kleinen) Bruchteil auskommt. Und dann werden die Augen ganz groß wenn ein 100 Zeilen Programm plötzlich nicht mehr in den µC passt. Auf großen Systemen ist das alles kein Problem, aber gerade die PIC16 sind wie so manch andere 8Bitter auch noch eher Sparsam mit den Ressourcen. Deshalb sind Rekursionen in diesem Umfeld auch verpönt. Und der Compiler geht hier halt einen Schritt weiter und bricht da ab wo andere Compiler "nur" eine Warnung liefern. ISt also ein Beitrag um es gleich im Sinne der µC Programmierung "richtig" zu lernen und nicht den vom PC gewohnten "Was kostet die Welt" Stil auf einer Plattform mit viel weniger Ressourcen weiterzutreiben. Natürlich kann man statt zu lernen wie man C Code schreibt der auch in "Sparsamen" Maschinencode übersetzt werden kann auch einfach einen Dickeren µC nehmen. ICh vermute sogar das einige die hier so laut auf die "kleinen 8Bitter" schimpfen genau aus diesem Grund bei den 32Bittern gelandet sind und nicht weil die Anwendung es bei richtiger Umsetzung es erforderte, aber das ist nicht der Weg wie man die Probleme richtig löst. Aber wie gesagt, Rekursionen auf den kleinen Plattformen sind bei vielen eher verpönt, aber letztendlich ist es, wie so vieles, eine Frage bei der es die einzig korrekte Ansicht nicht gibt. Gruß Carsten
Mike R. schrieb: > 20€ sind als Fehlinvestition ggf zu verkraften. > > Dann kann ich ja erstmal quasi das gleiche wie mit nem Arduino machen. > Á la Blink etc... Mache es! Ob Dir aber mit einem STM32F4 bessere Ideen kommen, als mit einem ATmega328, den Du noch nicht einmal ansatzweise genutzt hast, glaube ich schlicht nicht. Es gibt auch noch ein STM32F429-DISC-Board mit TFT-Anzeige. Ein kurzes Kabel an einen Eingang, ein paar Register richtig gesetzt, und schon kann man damit TV sehen - wenn ich die Fans richtig verstanden habe.
M. H. schrieb: > Ja, das meine ich. Ich habe z.B. mal eine Rechnung von ca. 20 Zyklen (C) > auf 9 (ASM) optimiert. Naja da wird das C Programm noch lange nicht optimal gewesen sein. Kein Compiler kann aus einem "schlechten" C-Code einen optimalen Assembler-Code erzeugen. Ist der C-Code gut auf den µC optimiert, wird der Compiler einen Assembler-Code erzeugen den ein normalsterblicher Programmierer in Assembler nicht mehr optimieren kann. Ja ich weiß, es gibt Gurus die immer noch irgendwelche Details finden. Aber das sind bestimmt nicht mal 1 % aller selbsternannten Assembler Fans.
m.n. schrieb: > Mache es! > Ob Dir aber mit einem STM32F4 bessere Ideen kommen, als mit einem > ATmega328, den Du noch nicht einmal ansatzweise genutzt hast, glaube ich > schlicht nicht. Das habe ich auch nicht gesagt...
Sven P. schrieb: > PIC16 ist die einzige mir bekannte Mikroprozessorarchitektur, für die > man keine rekursiven Funktionen (oder sich gegenseitig aufrufende > Funktionen oder eine Funktion, die aus Hauptprogramm- und Interrupt > aufgerufen werden kann) kompilieren kann... Warum soll das nicht gehen ? Ich muss zugeben, dass ich auf diese Idee noch nie gekommen bin. Grüße Andreas
Auf gar keinen Fall einen Atmega AVR nehmen. Die Dinger sind nur für Bastelzwecke/Nostalgiker zu gebrauchen! Weitere Nachteile: - Sehr teure Debugger - Chips haben sehr schlechtes Preis/Leistungsverhältnis - Technologie nicht zeitgemäß usw usw... stm32 Discovery ist ein guter Einstieg.
Ralph schrieb: > M. H. schrieb: >> Ja, das meine ich. Ich habe z.B. mal eine Rechnung von ca. 20 Zyklen (C) >> auf 9 (ASM) optimiert. > > Naja da wird das C Programm noch lange nicht optimal gewesen sein. > Kein Compiler kann aus einem "schlechten" C-Code einen optimalen > Assembler-Code erzeugen. > Kannst Du da bitte mal ein Beispiel zeigen für Code, der in 20 cycle (C) durchläuft, den der Compiler (mit entsprechender Optstufe) nicht auf 9 cycle (ASM) optimiert kriegt, den man aber durch "handprogrammierten Assembler" dann doch auf 9 cycles bekommt, ohne dass man hier noch zusätzliche Informationen berücksichtigt, die der Compiler nicht kannte ? Danke Grüße Andreas
Andreas H. schrieb: > Sven P. schrieb: >> PIC16 ist die einzige mir bekannte Mikroprozessorarchitektur, für die >> man keine rekursiven Funktionen (oder sich gegenseitig aufrufende >> Funktionen oder eine Funktion, die aus Hauptprogramm- und Interrupt >> aufgerufen werden kann) kompilieren kann... > > Warum soll das nicht gehen ? > > Ich muss zugeben, dass ich auf diese Idee noch nie gekommen bin. > > Grüße > Andreas Rekursionen kann man mit dem XC8 -zumindest in der free Version- tatsächlich nicht verwenden. Da wird mit entsprechender Fehlermeldung (etwas in Richtung "rekursion Entdeckt" genau habe ich das gerade nicht im Kopf) abgebrochen. Egal ob PIC16 oder PIC18. Soweit hat er schon recht. Das liegt wohl darin begründet das der XC8 in weiten Teilen eine Weiterentwicklung des HiTech Compilers ist nur wenig vom C18 übernommen hat. Der C18 lässt Rekursionen in einem gewissen Umfang zu. Aber wie schon oben geschrieben. Bei einem der hier diskutierten 8Bitter mit Rekursionen zu Arbeiten ist einfach der Falsche Weg. Es mag Ausnahmen geben wo auch auf einem kleinen µC dieses Mittel sehr viel Sinn macht, aber diese Fälle werden wohl 99% der Hobbyisten niemals haben und dann muss man SEHR GENAU wissen was man macht. Daher finde ich das gar nicht so schlecht das wenn in der Grundeinstellung Rekursionen sofort als solche Erkannt werden und zum Abbruch führen. Eine Option trotzdem nach manueller Bestätigung zum erfolgreichen Build zu kommen wäre trotzdem wünschenswert - Für die seltenen Fälle wo es Sinn macht (Aber wie gesagt, ich weiß gerade gar nicht ob das bei der Pro Version vom XC8 nicht sogar geht) Gruß Carsten
Carsten Sch. schrieb: > Sven P. schrieb: >> Carsten Sch. schrieb: >>> Aber ich sage ganz klar das die PIC Familie mindestens genauso gut >>> geeignet ist und nur kleinigkeiten den Unterschied machen. >> PIC16 ist die einzige mir bekannte Mikroprozessorarchitektur, für die >> man keine rekursiven Funktionen (oder sich gegenseitig aufrufende >> Funktionen oder eine Funktion, die aus Hauptprogramm- und Interrupt >> aufgerufen werden kann) kompilieren kann... > > Das ist keine Frage der Architektur sondern eine Frage des Compilers! > Und hier könnte man sich streiten ob es (im übertragenen Sinn) ein "BuG" > oder "Feature" ist. Doch, es ist eine Schwäche der Architektur, die nämlich keinen von der Software nutzbaren (ausgenommen call/return) Stack bereitstellt. Und der Stack ist die übliche Methodik, um Rekursionen zu verwenden. > Denn Rekursionen, richtig angewandt, können einen das Programmiererleben > erheblich erleichtern. Das stellt wohl niemand ersnthaft in Abrede. > Nur Allzuoft ergeben die aber bei der Compilierung riesige > Codeabschnitte für etwas wo man iterativ mit einem (kleinen) Bruchteil > auskommt. Und dann werden die Augen ganz groß wenn ein 100 Zeilen > Programm plötzlich nicht mehr in den µC passt. Und wo genau führt eine Rekursion jetzt zu mehr Code? > Auf großen Systemen ist das alles kein Problem, aber gerade die PIC16 > sind wie so manch andere 8Bitter auch noch eher Sparsam mit den > Ressourcen. > Deshalb sind Rekursionen in diesem Umfeld auch verpönt. Und der Compiler > geht hier halt einen Schritt weiter und bricht da ab wo andere Compiler > "nur" eine Warnung liefern. Nö, er ist einfach nur beschränkt. Der Compiler kann ja auch nichtmal was dafür. Ich wüsste jetzt auf Anhieb auch nicht, wie ich Rekursionen mit Stackframe/Parametern ohne Stack implementieren sollte. Beispiel: Ich habe hier einen Regelalgorithmus, der mit 32 Bit rechnet. Die dazu nötigen Rechenroutinen (addieren, multiplizieren) sind natürlich etwas länger. Diese Routinen benutze ich im Hauptprogramm und in einem Interrupt. Das geht mit dem PIC ohne 'Rekursion' so schon nicht. Und nur weil der PIC zu dämlich dafür ist, sind Rekursionen noch lange nicht unsinnig auf kleinen Prozessoren. Aber gut. Alle anderen Prozessoren können Rekursionen. Also sind alle anderen Prozessoren blöd und nur der PIC hat dieses einzigartige Feature, schon klar. Die Diskussion wird mir zu dumm. Ja, so arrogant bin ich. Viel Spaß noch mit PIC.
Sven P. schrieb: > Ich habe hier einen Regelalgorithmus, der mit 32 Bit rechnet. > Die dazu nötigen Rechenroutinen (addieren, multiplizieren) sind > natürlich etwas länger. Diese Routinen benutze ich im Hauptprogramm und > in einem Interrupt. > > Das geht mit dem PIC ohne 'Rekursion' so schon nicht. Kann es sein, dass Du rekursiv und reentrant verwechselst ? Gruß Andreas
Andreas H. schrieb: > Kann es sein, dass Du rekursiv und reentrant verwechselst ? Nein, ich habs aber ungünstig zusammengeworfen, das stimmt. Beides läuft nämlich hier auf dasselbe Problem hinaus: Kein Stack. Den braucht man üblicherweise für beides: Bei der Rekursion, sofern sie sich nicht z.B. als tail-end-Rekursion zusammenziehen lässt. Und für die Eintrittsinvarianz für das lokale Stack-Frame. Man könnte für letztes natürlich z.B. zwei Frames statisch reservieren. Eines für das Hauptprogramm und eines für den Interrupt. Man könnte noch ein drittes nehmen, falls der Interrupt durch einen höherprioren unterbrochen werden kann. Ach überhaupt, man könnte das ganze RAM damit zupflastern. Und den Flash natürlich auch, weil jede dieser 'Instanzen' ja eine anders adressierende Funktion braucht.
Carsten Sch. schrieb: > Rekursionen kann man mit dem XC8 -zumindest in der free Version- > tatsächlich nicht verwenden. Da wird mit entsprechender Fehlermeldung > (etwas in Richtung "rekursion Entdeckt" genau habe ich das gerade nicht > im Kopf) abgebrochen. Egal ob PIC16 oder PIC18. Sven P. schrieb: > Beides läuft nämlich hier auf dasselbe Problem hinaus: Kein Stack. AAAAAHHHHHHHHH. Mea culpa, Gnade, Asche auf mein Haupt. Wir sind ja bei 8-Bit PICs. Da habt ihr natürlich beide recht. Die benutzen ja compiled-stacks. (Ich bin grade mit einem PIC32 am wirbeln. Da ging anscheinend die MIPS Architektur hier mit mir durch, sry ;-) Sven P. schrieb: > Man könnte für letztes natürlich z.B. zwei Frames statisch reservieren. > Eines für das Hauptprogramm und eines für den Interrupt. Aber der XC8 (nun bin ich beim 8-Bit compiler^^) macht dafür ja eine Function Duplication. Zugegeben, etwas archaisch. Aber soo schlecht finde ich hier die compiled stacks eigentlich nicht. Man findet jeden Stack overflow beim compile/link (weil Die ja statisch allocated werden). Auf einem "größeren" uP würde es mich aber auch gelegentlich stören. Gruß Andreas
Markus Müller schrieb: > @Mika R. > > Artikel: STM32 CooCox Installation > > Die Anleitung für Deine ersten Geh-Versuche. Hatte ich vorhin schon gelesen. Super Sache!
Andreas H. schrieb: > Kannst Du da bitte mal ein Beispiel zeigen für Code, der in 20 cycle (C) > durchläuft, den der Compiler (mit entsprechender Optstufe) nicht auf 9 > cycle (ASM) optimiert kriegt, den man aber durch "handprogrammierten > Assembler" dann doch auf 9 cycles bekommt, ohne dass man hier noch > zusätzliche Informationen berücksichtigt, die der Compiler nicht kannte > ? Ist natürlich jetzt schwer da ich den Ursprungscode nicht kenne von dem diese Zahlen stammen. Aber ein Beispiel das ich schon auf einem 8052 selbst hatte. Die erste Version einer Interruptroutine in C wurde durch den Compiler im Assembler zu rund 140 Takten. Durch Optimierung auf den µC. zb Welche Variable in welcher Größe in welchem Rambereich , Iram, Xram, oder auch Nutzung von Structs / Unions um 16 bit Zugriffe zu vermeiden konnte der erzeugte Assembler Code deutlich reduziert werden. Am Ende war die Interruptroutine < 40 Taktzyklen lang. Und da war auch mit manueller Assemblerprogrammierung nicht ein Taktzyklus mehr rauszuholen. Funktional waren die erste und die letzte C-Code Version identisch. Testweise beide Varianten mal für eine ARM7 TDMI compiliert. Hier war die Version 1 die schnellere, wenn auch der Abstand geringer war. Die Zahlen weiß ich allerdings nicht mehr. Im Kern ging es dabei darum 16 Bit Timerwerte zu lesen, in Arrays einzusortieren, Timer zurückzusetzen und Arrayindex Verwaltung. Die Verarbeitung der Arrays lief dann in der Mainloop und war Zeit unkritisch. Zeigen kann ich den Code hier allerdings nicht da es keine private Bastelei war. Was ich damit sagen wollte, Der Compiler kann nur dann optimalen Code erzeugen, wenn im C-Code die Eigenarten des µC berücksichtigt werden. "Generischen" C-Code muss der Compiler an den µC anpassen. Das erzeugt immer zusätzlichen Assemblercode, sprich Rom, Ram und Laufzeitbedarf. Oder anders ausgedrückt. Wer optimalen Code schreiben will, muss wissen was er wo und wie macht. In welcher Sprache das dann geschrieben wird ist völlig egal.
Ralph schrieb: > Andreas H. schrieb: >> Kannst Du da bitte mal ein Beispiel zeigen für Code, der in 20 cycle (C) >> durchläuft, den der Compiler (mit entsprechender Optstufe) nicht auf 9 >> cycle (ASM) optimiert kriegt, den man aber durch "handprogrammierten >> Assembler" dann doch auf 9 cycles bekommt, ohne dass man hier noch >> zusätzliche Informationen berücksichtigt, die der Compiler nicht kannte >> ? > > Ist natürlich jetzt schwer da ich den Ursprungscode nicht kenne von dem > diese Zahlen stammen. > > Aber ein Beispiel das ich schon auf einem 8052 selbst hatte. > Die erste Version einer Interruptroutine in C wurde durch den Compiler > im Assembler zu rund 140 Takten. > Durch Optimierung auf den µC. zb Welche Variable in welcher Größe in > welchem Rambereich , Iram, Xram, oder auch Nutzung von Structs / Unions > um 16 bit Zugriffe zu vermeiden konnte der erzeugte Assembler Code > deutlich reduziert werden. > Am Ende war die Interruptroutine < 40 Taktzyklen lang. > Und da war auch mit manueller Assemblerprogrammierung nicht ein > Taktzyklus mehr rauszuholen. Das ist das, was ich erwartet hatte. Der Compiler konnte nur besser optimieren, nachdem er zusätzliche Informationen bekommen hatte. Bei Deiner Struct/Union Optimierung fiel vermutlich auch gleich ein besseres Alignment der Daten, bzw. ein "Basepointer" mit ab. Falls Du das als "optimales C-Programm" verstehst, dann stimme ich Dir zu. Meist holen gute (!) Compiler ja schon automatisch viel mehr raus, als der Programmierer erwartet. Da macht man beim studieren des erzeugten ASM codes schon mal erstaunliche Entdeckungen, auf die man selbst noch gar nicht gekommen ist. Mangelhafte Optimierung kommt aber genauso durch fehlende Informationen zustande. Und da ist es oft "einfacher", mal kurz zu ASM zu wechseln und den Codeteil direkt selber zu implementieren. Ein "Klassiker" ist z.B. wenn DU weisst, dass in einem Parameter einer Funktion gepackte Daten enthalten sind, von denen Du in dieser Funktion nur einen Teil brauchst. Hat man ja z.B. gern, wenn man über SPI irgendein Register zurückliest. Da holt man mit etwas "Registerakrobatik" oft noch etwas raus. Ok, man muss es dann in die Doku wieder reinstecken. Aber zumindest schafft es der Code dann rechtzeitig das benötigte Ergebnis zu liefern :-) Grüße Andreas
Ich zitier mich mal selber, weil ich das grad im Nachbarthread geschrieben habe: Markus Weber schrieb: > c-hater schrieb: >> Nein, natürlich kann man auch mit ret aus einer ISR zurückkehren. Man >> muß halt nur dafür sorgen, daß vorher SREG_I bereits wieder enabled >> ist. > > Korrekt. > > Man kann auch mit RJMP zurückspringen, wenn man danach immer an einer > definierten Stelle beginnen will. Den Fall hatte ich schon. > > Und: man braucht auch gar nicht zurückspringen. Nämlich dann, wenn es > kein Hauptprogramm gibt und die Anwendung rein ereignisgesteuert läuft. > Dann nämlich schreibt man ans Ende der ISR nur ein SEI und viele NOPs, > dahinter dann zur Sicherheit ein RJMP PC. > > In dem Fall braucht man den Stackpointer nicht zu initialisieren, > natürlich sollte man dann das SRAM besser nicht verwenden – es wird > sonst lustig. > > Macht man aber nur dann, wenn man das letzte bisschen Leistung aus einem > ATtiny10 rausquetschen will. :-) Würde mich interessieren, ob es einen Compiler gibt, der solche Optimierungen durchführt. Dazu kommen noch die Interrupt-Routinen, die man direkt in die Sprungtabelle reinschreibt (ohne woanders hin zu springen). Das macht ein normaler Compiler auch eher nicht, oder? Ähm - eigentlich sind wir in diesem Thread aber off-topic...
Andreas H. schrieb: > Das ist das, was ich erwartet hatte. Der Compiler konnte nur besser > optimieren, nachdem er zusätzliche Informationen bekommen hatte. > > Bei Deiner Struct/Union Optimierung fiel vermutlich auch gleich ein > besseres Alignment der Daten, bzw. ein "Basepointer" mit ab. > > Falls Du das als "optimales C-Programm" verstehst, dann stimme ich Dir > zu. > > Meist holen gute (!) Compiler ja schon automatisch viel mehr raus, als > der Programmierer erwartet. Da macht man beim studieren des erzeugten > ASM codes schon mal erstaunliche Entdeckungen, auf die man selbst noch > gar nicht gekommen ist. Ich sehe schon, wir verstehen uns. Andreas H. schrieb: > Mangelhafte Optimierung kommt aber genauso durch fehlende Informationen > zustande. Und da ist es oft "einfacher", mal kurz zu ASM zu wechseln und > den Codeteil direkt selber zu implementieren. Da muss man seinen µC aber schon ganz gut kennen sonst gewinnt man nichts. Wenn man diese Kenntnis hat, kann man aber auch den C-Code direkt so schreiben das es passt. Andreas H. schrieb: > Ein "Klassiker" ist z.B. wenn DU weisst, dass in einem Parameter einer > Funktion gepackte Daten enthalten sind, von denen Du in dieser Funktion > nur einen Teil brauchst. > Hat man ja z.B. gern, wenn man über SPI irgendein Register zurückliest. > Da holt man mit etwas "Registerakrobatik" oft noch etwas raus. > Ok, man muss es dann in die Doku wieder reinstecken. Aber zumindest > schafft es der Code dann rechtzeitig das benötigte Ergebnis zu liefern > :-) Ja stimmt ABER es ist durchaus Potential da das es mit der nächsten SW Änderung an anderer Stelle kracht. Ändert man zb die Struktur des Parameters oder das Alignment im Ram greift diese Optimierung plötzlich an die falsche Stelle. Solange nur EIN Programmierer hier arbeitet wird es gehen, er weiß ja was wo mit welcher Struktur passiert. Solange das Programm nicht zu groß und unübersichtlich wird. Arbeite hier allerdings ein Team an der SW führt diese Weg ins Chaos und gibt schnell stunden/tage langes Fehlersuchen. zb man fügt in die Struktur einen ADC Wert hinzu der im ADC IRQ gefüllt wird, und schon gibt es in der Timer IRQ eine DivideByZero weil nun in der Struktur an der Stelle an der Vorher der Timerwert stand eine 0 steht bis der erste ADC Wert gelesen wird. Finde so ein Ding mal ohne Debugger.
Markus Müller schrieb: > Renesas, M16C, ich hatte den auch schon - und wieder in den Müll > geschmissen. Bei Renesas würde ich mir eher die aktuellen Typen ansehen, wie z.B. die RX63-Reihe: http://de.futureelectronics.com/de/technologies/development-tools/microcontroller-microprocessor/32-bit-eval-board/Seiten/4022487-YRDKRX63N.aspx?IM=0 Das ist ein µC, den man mit dem STM32F4.. vergleichen kann, und der meines Erachtens für einen Umsteiger auf 32-Bitter einfacher zu durchschauen ist. Ich empfehle, einfach mal dessen Hardware-Manual zu lesen. Auf knapp 2000 Seiten sind alle Funktionen klar dargestellt. Wenn ich hier im Forum lese, was alles aus China bestellt (oder besser zusammengeschnorrt) wird, kann man auch nicht von einem Beschaffungsproblem reden. Die RXe sind im Detail 'eleganter', was ich nicht groß ausführen möchte. Aber wenn man beispielsweise die DMA-Controller mit denen des STMs vergleicht, sind die Funktionen vielfältiger und praxistauglicher. Das merkt man allerdings erst, wenn man beide µCs kennengelernt hat und entsprechend nutzen will. Dies nur als Anmerkung zum Thema: was gibt es hinter dem Tellerrand.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.