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
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.
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
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!
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.
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.
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ß.)
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.
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.
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?
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
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 ;-)
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.
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... -_-
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
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.
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
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.
