Hallo Forum, vorab: Wusste nicht genau wohin mit dem Thread, falls er hier falsch ist bitte verschieben. Also, kurze Einleitung: Ich bin noch in der Schule und mache dieses Jahr mein Abi. Ich mache schon lange Hobbymäßig was mit µCs, genauer gesagt mit AVRs. Bei den AVRs habe ich schon sehr viele verschiedene Modelle benutzt, vom tiny26, 48, 85, über den mega16, 328 bis hin zum 2560 (nicht Arduino oÄ sondern "bare metal"), ich würde also sagen, dass ich mich damit gut auskenne. AVR-asm kann ich auf jeden Fall lesen und auch ein bisschen schreiben (kleineres Zeug halt), aber eigentlich bin ich bei C zuhause. Imho behersche ich das auch ganz gut. Beruflich möchte ich auch etwas mit µCs zu tun haben, da mir das viel Spaß macht. Deswegen meine Fragen: 1) kann man mit AVR wirklich was anfangen? Man hört immer wieder das die AVRs nur im Hobby-Bereich zu finden sind, aber das kann ich mir nicht vorstellen (würde sich für Atmel auch kaum rechnen). 2) Bei meinem Praktikum haben wir auf PICs programmiert, wie sieht denn da die Verbeitung verglichen mit den AVRs aus (bezogen auf Beruf, nicht aufs Hobby)? 3) ARM ist ja grad voll in Mode und verdrängt langsam verschiedene Chip-Familien (ich denke zwar nicht dass die 8bitter verschwinden, aber es werden wohl weniger werden). Bestimmt wäre es sinnvoll sich mal mit ARM zu beschäftigen. Nur mit was? Es gibt ja verschiedene Hersteller die die IP-cores einbauen und verkaufen, an wen soll man sich da halten? Konkret: Ist es besser bei einem Atmel-µC zu bleiben oder ist der Umstieg auf eine STM32 nicht schwerer? Kurz gesagt: was genau sollte ich mir anschauen? Danke, N.G.
:
Verschoben durch User
krasser typ, in der schule und schon plan vom hardwarenaher Programmierung. würde mich auch interessieren, wo der Trend so liegt. da, wo ich arbeite (Werkstudent), wurde damals mit atmegas programmiert und nutzen diese heute noch. der Trend scheint aber doch eher zum teil auf raspberry pi und arduinos zu gehen, je nachdem, da hardware schon preisgünstig fertig ist. sonst würde ich sagen hängts von der Firma ab, was der Ingenieur dort damals gewählt hat.
:
Bearbeitet durch User
N. G. schrieb: > Kurz gesagt: was genau sollte ich mir anschauen? Genau das, was dir Spaß bereitet. Controller werden immer kurzlebiger, neue Familien erscheinen immer schneller. Warum sich also festlegen? An der Methodik, damit umzugehen und sich einzuarbeiten, ändert sich wenig.
Microchip ist IMO etwa doppelt so verbreitet wie Atmels µCs, aber auch Atmels µCs findet man in der Industrie reichlich. Und ob es jetzt ein ARM oder doch ein 8-bit µC wird hängt schlicht von der Anwendung ab. Schau dir am besten mal so verschiedene Prozessoren an und entscheide, welcher dir am besten gefällt. Wenn du später im Job einen anderen Prozessor hast ist das auch nicht schlimm da im Grunde die Herangehensweise bei allen Prozessoren gleich ist oder zumindest ähnlich.
Im Grunde ist es völlig egal mit welchen µC du dein Handwerk lernst. An der Programmiersprache und der Methodik ändert sich nicht viel. PIC's denke ich sind etwas mehr verbreitet. Und auch der MSP430 von TI ist durchaus häufig zu finden. Das beste Datenblatt hat allerdings meiner Meinung nach der Atmel. ARM-µC lohnen sich wirklich nur wenn man viel Rechenleistung braucht. im Grunde ändert sich an der Programmiertechnik selbst nicht viel. Registerzugriffe sind etwas anders und die ISR läuft anders ab. Ich habe dazu mal den Arduino DUE ausprobiert. Der hat eine ARM-Architektur und man hat gleich ein fertiges Testboard ohne großer rumbasteln. (habe den DUE natürlich auch baremetal programmiert und nicht mit der Arduino IDE)
Was für eine "Marke" Du benutzt ist relativ egal. Kennt man ein paar, macht einem ein Wechsel auch nicht viel aus(zumindest wenn man eine Hochsprache wie C/C++ benutzt). Gestern Atmel, heute TI, morgen Infineon. Schau dir verschiedene Hersteller mit ihren unterschiedlichen Architekturen und Perepherien an. Eigene dir an, wie man gut strukturiert und dadurch effektiv Programmiert. Wie man zeitkritische Dinge in die Peripherie auslagern kann und somit den Core entlastet. Spezialisiere Dich. z.B. in Richtung FPGA und Softcores für die ganz zeitkritischen Dinge. Oder in Richtung Embedded Linux. Der ganze Wearabels Markt ist ja auch schwer am kommen. Wenn du Richtung hardwarenaher Programmierung gehen willst (ganz unten), dann beschäftigte dich mit Elektrotechnik. Nichts ist so schlimm als ein Informatiker der keine Ahnung von Physik hat oder mit Speicher und Laufzeit um sich wirft. Schau dir Coding Rules an und versuche sie die so früh wie möglich anzueignen.
@ N. G. (Firma: KdS) (newgeneration) >1) kann man mit AVR wirklich was anfangen? Ja. Zum Grundlagen lernen sowieso, aber auch im echten Leben. Nicht immer muss es ein P4 Quadcore sein. > Man hört immer wieder das die >AVRs nur im Hobby-Bereich zu finden sind, aber das kann ich mir nicht >vorstellen (würde sich für Atmel auch kaum rechnen). Eben! >2) Bei meinem Praktikum haben wir auf PICs programmiert, wie sieht denn >da die Verbeitung verglichen mit den AVRs aus (bezogen auf Beruf, nicht >aufs Hobby)? Ähnlich, ist ein großer Hersteller! >>es werden wohl weniger werden). Bestimmt wäre es sinnvoll sich mal mit >ARM zu beschäftigen. Nur mit was? Was dir gefällt und was weit verbreitet ist, denn dazu gibt es viele Infromationen und Projekte. Exoten sind nur was für Exzentriker ;-) >Konkret: Ist es besser bei einem Atmel-µC zu bleiben oder ist der >Umstieg auf eine STM32 nicht schwerer? Ist Jacke wie Hose. >Kurz gesagt: was genau sollte ich mir anschauen? Was dir Spaß macht. In deiner Situation willst die die Grundprinzipien lernen, das geht mit fast jedem System. Muss ja nicht der Bo8 sein ;-) https://www.mikrocontroller.net/articles/8bit-CPU:_bo8 Logischerweise sollte man eher zeitgemäße CPUs anschauen, (klassische)8051 oder 68HC11 sind out.
@ Frank (Gast) >Spezialisiere Dich. Als Schüler? Nöö! Das hat noch VIEL Zeit. >z.B. in Richtung FPGA und Softcores für die ganz zeitkritischen Dinge. Quark. Softcores sind nette akademische Spielereien. >dann beschäftigte dich mit Elektrotechnik. Nichts ist so schlimm als ein >Informatiker Nicht ist so schlimm wie ein Elektroniker, der keine Ahnung von Grammatik hat ;-) > der keine Ahnung von Physik hat oder mit Speicher und >Laufzeit um sich wirft. Gibt's doch heute im Übermaß. Raspberry Pi zum LED-Blinken! >Schau dir Coding Rules an und versuche sie die so früh wie möglich >anzueignen. Gute Idee. Strukturierte Programmierung auf Mikrocontrollern
:
Bearbeitet durch Moderator
Lerne C und C++. Dann ist der Prozessor darunter fast egal. Nur wenn man mal wirklich SPI macht, muss man sich um die Register kümmern. Ansonsten interessiert der Prozessor und die Bitbreite kaum. Mit C habe ich schon ein Dutzend verschiedener Prozessoren programmiert. Wichtiger sind nachher die Algorithmen und Datenstrukturen.
also, was schon sinn machen würde, wäre dma (direct memory access) auf nen Controller zocken und linux gut kennen, shell und so.
:
Bearbeitet durch User
N. G. schrieb: > Kurz gesagt: was genau sollte ich mir anschauen? Alles. Verschiedene Architekturen sind nützlich, um zu sehen, wie gewisse Dinge anderswo gemacht werden. Das erweitert den Horizont ganz erheblich. FPGAs und Leiterplattendesign gehört auch dazu, und natürlich auch die Analogtechnik, die langsam aus dem Fokus gerät, aber das Fundament des ganzen bildet. Wichtig ist, dass Du lernst zu lernen. Du kannst jetzt nicht absehen, was gerade aktuell ist, wenn Du fertig bist. Konkrete Produktkenntnisse werden dann ohnehin überholt sein. Ob Du jetzt AVR oder PIC, MIPS oder ARM kennst, ist für später egal. Ich habe Anfang der 80'er mit Z80 angefangen. Bis ich den kapiert hatte, hat es ein halbes Jahr gebraucht. Den 6502 konnte ich dann in 6 Wochen, wobei "konnte" dann hieß, im Kopf zu assemblieren und Hexbytes einzutippen. Soundkarten gabs damals nicht im Laden zu kaufen, man musste sie sich selber bauen. Viel viel wichtiger ist für Dich die Schule. Insbesondere Mathe. Ein Ingenieurs-Studium ist zu mindestens 70% Mathe, bei Naturwissenschaften wird es ähnlich aussehen. Solltest Du damit irgendwelche Schwierigkeiten haben, wäre das extrem ungünstig. Wobei es jetzt egal ist, ob Du jetzt eine 1 oder 3 hast (das kann auch am Lehrer liegen). Wichtig ist, dass Du ein Verständnis für die Sachen entwickelst und nicht einfach auswendig lernst. Denn erst das Diplom bzw Master ist für Dich die Eintrittskarte ins Berufsleben, zusammen mit einem vorzeigbaren Abitur. fchk PS: So sahen Rechner aus meiner Anfangszeit aus: http://www.oldcomputers.net/kim1.html
:
Bearbeitet durch User
Danke schon mal an alle für eure Beiträge!!! Leider kann ich aufgrund der hohe Anzahl nicht auf jeden einzelnen eingehen. Mehrfach kam die Methodik vor, und ihr hab auf jeden Fall recht. Die Herangehensweise ist beim Design sehr wichtig (sowohl von der software also auch von der hardware-Seite her). Strukturierte Programmierung und wiederverwendbare Software fällt auch in dieses Gebiet. Ich habe mir schon überlegt ob ich mir FPGAs mal anschauen soll, habe aber aufgrund der teureren Entwicklungsboards und der schwereren Ansteuerung davon abgesehen. Leiterplatten kann ich designen (natürlich keine Profimäßigen und erst recht kein HF oÄ) und davon (manchmal) sogar Schaltpläne zeichnen ;) Das mit der Schule stimmt natürlich auch, ich würde jedoch von mir sagen, dass ich den Stoff relativ leicht kapiere, nur ich habe das Problem dass man grob als "Faulheit" bezeichnen kann. Insgesamt haben mir eure Antworten schon jetzt sehr geholfen, ein großes DANKE dafür
Es spielt überhaupt keine Rolle welchen. Wichtig ist daß Du imstande bist zu analysieren wie Dir die Komponenten eines (beliebigen) Controllers bei einer bestimmten Problemstellung von Nutzen sein können (und daß Du dann auch imstande bist das so umzusetzen), daß Du auch mal auf kreative Lösungen kommst um nicht möglich geglaubtes auf unterdimensionierter Hardware dennoch möglich zu machen, daß Du die üblichen gängigen Entwurfsmuster für bare metal embedded Software schonmal gesehen und angewendet hast, daß Du die Sprache C aus dem ff beherrschst (wirklich!) in all ihren Facetten und mit all den Werkzeugen (Compiler, Linker, Buildscripte, etc umgehen kannst), daß Du jederzeit und auch unter Zeitdruck ordentlich strukturierten, modularen, lesbaren und wiederverwendbaren Code abliefern kannst. Welche µC Du bisher verwendet hast spielt keine Rolle, die wesentlichen Methodiken und Fertigkeiten die Du Dir angeeignet hast sind herstellerunabhängig. Mathematik und Physik sollten Dir nicht fremd sein und gute Elektronik-Kenntnisse (auch analog) samt zugehöriger Erfahrung und Intuition sollten ebenfalls selbstverständlich sein. Wenn Dich das alles nicht schreckt und Du all das da oben (und noch viel mehr) schon hundert mal gemacht hast (und zwar weil Du es wolltest, nicht weil man Dich gezwungen hat), und sei es auch nur mit nem AVR-Tiny und sonst nichts, ganz egal, wenn Du das drauf hast dann kannst Du bereits 99.9% Deiner Mitbewerber mit links in die Tasche stecken.
Stefan schrieb: > M-µC lohnen sich wirklich nur wenn man viel Rechenleistung braucht. im > Grunde ändert sich an der Programmiertechnik selbst nicht viel. > Registerzugriffe sind etwas anders und die ISR läuft anders ab. > Ich habe dazu mal den Arduino DUE ausprobiert. Unsinn hoch 10. Natürlich ändert sich nicht viel, wenn man der Hardware eh nicht nahme kommt, weil man Arduino verwendet. Es lohnt sich schon, den STM32 mal näher anzugucken. Er ist einfach um Welten Komplexer und Leistungsfähiger als deine 8 Bitter. Er hat viel mehr Peripherie. Und der Assembler ist viel viel komplexer. Sicher gibt es in der Industrie auch AVR und PIC, aber halt nur für simpelste Sachen. Da lässt sich dann auch kein Geld mit verdienen, da es jeder Student kann ;-).
Hi, Vorab: Du bist schon mal gar nicht so auf dem verkehrten Weg... Aber im Detail: Das es für eine spätere berufliche Laufbahn im Bereich der Hardwarenahen Softwareentwicklung wichtig ist nicht nur die reine Programmierung zu behrrschen sondern auch Mathe, für wirkliche Hardwarenähe Elektrotechnik und als wichtigstes von allem -Lernmethoden an sich- wurde ja schon mehrmals (richtigereweise) geschrieben. Daher will ich nur auf eine Ausgangsfrage eingehen... AVR und (8bit) PIC werden in der Industrie durchaus Zahlreich eingesetzt. (24 & 32 Bit Pic natürlich auch, aber die sind ja nicht mit AVR vergleichbar...) Es kommt halt mmer darauf an welches Problem man lösen möchte. Die allermeisten µc werden immer noch für Anwendungen eingesetzt wo sie von der möglichen maximalen Rechenleistung gnadenlos unterfordert sind. Da sind Dinge wie geringe Stromaufnahme, Preis, Verfügbarkeit, Lebensdauer der Produktlinie und nicht zuletzt der Stromverbrauch(viele laufen deshalb nur auf einem Bruchteil der Maximalfrequenz) viel wichtiger als die Maximale Rechenleistung. ARM werden in der Industrie schon sehr lange Zeit ebenfalls eingesetzt. In den etwas Leistungsstärkeren Anwendungsgebieten stellen diese als Familie betrachtet sicher mittlerweile den Löwenanteil. Allerdings sind auch hier durchaus andere Podukte ahlreich anzutreffen, (Mips wie die PIC32 MX/MZ oder auch diverse Renesas Controller...)auf die einzelnen Hersteller gesehen hält sich das dann wieder eher die Waage. Nur in Bastelerkreisen ist die große Verbreitung der ARM ein noch recht junges Phänomen das durch das Aufkommen der stark subventionierten Einstiegstools entfacht wurde. Wissen über alle drei Familien ist sicher nicht Schädlich nach dem heutigen Stand. Was in ein paar JAhren aber sein wird, da kann man nur spekulieren. Für jemanden der aber recht früh schon drei verschiedene Architekturen kennengelernt hat, für den sollte es aber auch kein Problem sein sich schnell in weitere dann aktuelle Architekturen einzuarbeiten. Dann hat man gelernt mit Datenblättern, AppNotes, ggf. IDEs von verschiedenen HErstellern umzugehen, weiß dann wo so üblicherweise die Unterschiede liegen und was bei allen ähnlich ist. Kurz gesagt: Man findet sofort die Dinge die man anders behandeln muss und kann den REst wie gewohnt bearbeiten. Erst recht wenn sowieso 99% der heute erstellten embedded Programmzeilen in C oder C++ geschrieben werden. (Für Hardwarenahe Anwendungen C, für sehr komplexe Anwednugnen auch immer mehr C++) Neben den 8 Bittern also auch einen 32 Bitter kennenzulernen macht also schon Sinn, WENN du bereits wirklich Fit auf einem 8 Bitter bist (in deinem Fall AVR). Sollte jemand dort aber auch noch auf Anfängerniveau herumgondeln sollte er allerdings lieber erst einmal eine Familie richtig Lernen bevor er mit der nächsten Anfängt! Wenn es ARM sein soll (Alternativ könnte man auch die 32Bit Microchip MIPS nehmen, selbe Klasse, andere Rasse. ISt eine reine Frage des Geschmacks, der evtl. bereits vorhandenen Tools und der Verfügbarkeit) ist das durchaus OK. Da die ARM Familien innerhalb einer Generation vom Kern ja alle praktisch gleich sind und sich nur die Peripherie von Hersteller zu Hersteller unterscheidet würde ich mich einfach für den Hersteller entscheiden wo die Verfügbarkeit von Bausteinen und Günstigen Einsteigertools UND Einsteigergerechten Dokumentation / Hilfe im Netz am größten ist. Da wird man dann wohl schnell bei NXP oder evtl. noch wahrschenlicher bei STM landen. Aber im im Grunde ist das völlig egal... ALs "armer Schüler" der wirklich auch viel aufbauen will könnte ggf. noch TI wegen ihrer immer noch großzügigen Samplepolitik interessant sein. (Vorrausgesetzt man hat eine Emailadresse der Schule...- Freemailer akzeptieren die seit kurzem wegen zu viel Missbrauch nicht mehr). Allerdings sind die Anfangskosten hier IMHO etwas höher. ICh hoffe das hilft dir erst einmal ein wenig weiter... Gruß Carsten P.S.: Zu den "Programmiersprachen" > AVR-asm kann ich auf jeden Fall lesen und auch ein bisschen schreiben > (kleineres Zeug halt), aber eigentlich bin ich bei C zuhause. Imho > behersche ich das auch ganz gut. DAS ist für jemanden der heute Einsteigt GENAU die Konstellation die ich empfehlen würde. Der absolute Löwenanteil der Embedded SW wird in C geschrieben. Ein langsam größer werdender Teil in C++. Perfektes ASM braucht man nur noch in echten Ausnahmefällen. ABER: In grenzfällen Zeitkritischer oder Platzsparender Programmierung kann das Hintergrundwissen wie der Prozessor den Code nachher tatsächlich abarbeiten wird durchaus sehr viel Potential bringen. Ich meine damit nicht einmal das man diese Teile dann wirklich in ASM schreiben muss, sondern das man durch das Hintergrundwissen den C-Code schon so gestalten kann das er sich möglichst optimal für die gewünschte Optimierung umsetzen lässt. (Erst wenn alle Stricke reissen legt man dann selbst in ASM Hand an, ist aber mittlerweile nur noch sehr selten nötig) Wobei dies aber immer noch nur ein "nice to have" ist... Wo aber ASM Kentnisse dann tatsächlich über erfolg oder Misserfolg entscheiden können ist das Debugging komplexer Fehlfunktionen, besonders wenn diese Fehlfunktionen nicht auf Fehlerhaften C Code sondern auf einem bis dahin unbekannten Compiler oder gar Controllerbug beruhen. Wenn man dann nicht die Möglichkeit hat sich die bersetzung der Problematischen Stelle anzusehen und zu verstehen oder den Code auf ASM ebene an dieser Stelle durchzusteppen wird man solche Fehler niemals eindeutig identifizieren können! Daher ist der WEG perfekt Lesen und schreiben zu können, ASM aber immernoch zumindest verstehen zu können, genau der richtige! Wenn man dann ein oder besser zwei (sgrundverschiedene, z.B. PIC und AVR) ASM Codes gut lesen kann wird man sich auch hier schnell in einem neuen Dialekt gut einarbeitenkönnen. Jetzt aber zum Zweiten mal und damit endgültig für heute ;-) Gruß Carsten
:
Bearbeitet durch User
In der Industrie ist meist alles etwas "größer", z.B. anstatt eines 2x16 Zeichen LCD Displays gleich ein TFT mit 1024 Pixl und Vollfarben usw. da die Kunden nunmal so was wollen was alles technisch so klicki Bunt aus sieht. Das ist auch der Hauptgrund warum immer mehr größere/schnellere µC eingesetzt werden müssen. Als Vorbereitung für den Beruf wäre es nicht schlecht wenn Du einen µC mit einem Cortex-Mx Kern (z.B. STM32 oder LPX17xx) auch mal programmierst. Dass Du Dich mit der Debug Schnittstelle (SWD) auseinandersetzt und damit ein wenig bastelst. Auch die Debugger-Ausgabe über SWD nutzt. Unabhängig vom µC: Schlussendlich ist es wichtig dass Du weißt wie die Peripherie Module funktionieren und was man für Möglichkeiten hast. - UART - SPI - I2C - CAN - USB - DMA - Timer - Portfunktionen - AD-Wandler - Spezial-Module wie Memory-Controller, CRC, Battrierefunktionen Auch ist es wichtig zu wissen wie die Protokolle funktionieren und was die jeweiligen Protokolle für elektrische Eigenschaften haben. (UART, SPI, I2C, CAN, USB) (Baudraten, Übertragungsbandbreite, Übertragungslängen, usw) Diese Anschlüsse und Kommunikationsmethoden braucht man immer - zwar nicht für jedes Projekt. Neuerdings braucht man in der Automobilindustrie sogar Kenntnisse über den neuen 2-Draht Ethernetbus - Aber das lernt man besser wenn man in einer richtigen Firme anfängt. Und ja, es gibt sicher noch 1000 andere Punkte die man als HW-/SW- Entwickler beachten darf. Und noch etwas, für evt. Deine Richtung: SW-Entwickler sind eher Mangelware als HW-Designer.
Markus M. schrieb: > In der Industrie ist meist alles etwas "größer", z.B. anstatt eines 2x16 > Zeichen LCD Displays gleich ein TFT mit 1024 Pixl und Vollfarben usw. da > die Kunden nunmal so was wollen was alles technisch so klicki Bunt aus > sieht. Das ist nicht immer eine Entscheidung des Kunden. Große Firma baut eine Gerätesteuerung, für die Steuerung wird ein PC benötigt, der hochgefahren werden muß und diverse Schnittstellenkarten anspricht. Wird das Gerät eingeschalten, dauert es mehrere Minuten, bis es betriebsbereit ist. Wird es ausgeschalten, muß erst das Programm beendet und der Rechner heruntergefahren werden. Wenn man da Wartung macht und das Gerät zwecks stromlos Schalten mehrmals hoch- und runterfahren muß, wird man wahnsinnig. Meine Lösung für selbes Problem: Multicontroller-System mit einem Master und beliebigen Slaves, ATmegas. Das Gerät ist 3 Sekunden nach Einschalten betriebsbereit - weil die Leistungsnetzteile verzögert zugeschalten werden - und kann jederzeit ohne Probleme ausgeschalten werden. KISS!
@Markus Müller (mmvisual) >Und noch etwas, für evt. Deine Richtung: SW-Entwickler sind eher >Mangelware als HW-Designer. Wirklich? Mein Eindruck ist eher anders herum!
Markus M. schrieb: > In der Industrie ist meist alles etwas "größer", z.B. anstatt eines 2x16 > Zeichen LCD Displays gleich ein TFT mit 1024 Pixl und Vollfarben usw. da > die Kunden nunmal so was wollen was alles technisch so klicki Bunt aus > sieht. Sagen wir mal so: In einigen Fällen ist es das, wo von das MArketing GLAUBT das der Kunde das will und niemand bei der richtungsweisenden Erstbesprechung deutlich genug wiederspricht. Danach liegt der Kurs fest und es wird umgesetzt. (Im Nichttechnischen Bereich liegen die damit ja auch nicht so verkehrt, im technischen Bereich aber führt das durchaus öftermal zu Unverständnis bei der Zielgruppe) In anderen Fällen ist das natürlich auch eine Folge davon das man so einfach einen (Industrie-) PC von der Stange kaufen kann und nur noch die Anwendungssoftware, für die man Leistungsreserven Satt hat, schreiben muss, wo man sonst gleich für HArdware und Software inkl. evtl. Betriebssystem) voll selbst verantwortlich ist. Bei überschaubaren Stückzahlen ist das schon ein riesger Zeit und Geldvorteil! Das MArketing hat dann die Aufgabe aus dem aufwendigen und LAngsam startenden System ein KlickiBunti Feature in der WErbung zu machen. Wobei es natürlich auch eine ganze Reihe von Fällen gibt wo es schon eine Erleichterung für den Anwender darstellt. Fast überall wo viele verschiedene Werte erfasst und auch direkt am Gerät zumindest grob ausgewertet werden ist das schon eine Erleichterung. ABER was man nicht glauben darf: Das dieser Industrie-C mit seinem Windows oder Linux (Beziehungsweise leistungsfähige ARM/MIPS) dann immer die einzige Komponente ist wo eigene Software drauf läuft. Häufig ist diese Komponennte gerade nur das relativ unkritische Frontend für die Visualisierung. Die tatsächliche Datenerfassung und erst recht irgendwelche Zeitkritischen Regelungen laufen in ganz anderen Teilen der HArdware wo dann wieder 8, 16 oder 32 Bit Microcontroller mit hochspezieller Software, wenn nicht sogar FPGA (in extermfällen) teilweise unter hohen Anforderungen ihren Dienst versehen. Gerade in den unscheinbaren Dingen steckt dabei die meiste Arbeit und das eigentliche know how der Firma. (wäre es anders würden die Firmen ja auch nicht so leichtfertig mit den tollen Multimedia-Frontends herumwerfen die dann Plötzlich auch in das einfachste Produkt hineinmüssen. Wenn dort wirklich oft die meiste Arbeit drinstecken würde, dann wäre das schlicht und einfach viel zu teuer!) Wobei ich natürich nicht sagen will das es keine "Anwendungssoftware" gibt die nicht auch ernormes Hintergrundwissen und know How erfordert. Davon gibt es sogar sehr sehr viel. Aber gerade im Industriebereich sind es im Klicki-Bunti teil der Steuerung meist nicht die fordernsten Aufgaben. Da wird nur visualisiert und Benutzereingaben angenommen. (gibt natürlich auch Ausnahmen!) Der Rest läuft in einer Art Multicontrollersystem ab wo jeder Controller seine eigene hochspezielle Aufgabe hat für die er mit seiner ganz eigenen Firmware ausgestattet ist. Ganz ohne OS, Grafik un Soundeffekten. Manchmal (aber wirklich selten) sogar noch in ASM Programmiert... Gruß carsten
Falk B. schrieb: > @Markus Müller (mmvisual) > >>Und noch etwas, für evt. Deine Richtung: SW-Entwickler sind eher >>Mangelware als HW-Designer. > > Wirklich? Mein Eindruck ist eher anders herum! Dein Eindruck ist richtig! Programmierer sind deutlich leichter zu finden.
Ob 2x16 LCD, oder 64x128 LCD, oder Embeddded PC bestimmt schlussendlich der Markt. Ein Industrie PC bringt gewisse Kosten mit sich. zB 800E. Plus die Speisung dazu, plus die Kuehlung, plus die Einbaugroesse. Wenn der Markt das hergibt, gut. Wenn dann ein Konkurrent auf Jammern der Kunden etwas fuer 500 Euro bringt, weiss man der Embedded PC muss raus.
Viel wichtiger als die Wahl der CPU finde ich das systematische Herangehen an die Aufgabe, d.h. das Aufstellen eines Pflichtenheftes und dann des Programmablaufplanes, sowie die Unterteilung der Funktionen in sinnvolle kleine Module. Wer gleich in den Editor schreibt "int main()", der hat schon verloren, der ist kein Programmierer, sondern ein Frickler. Das Programm muß erst vom Konzept her schon fertig sein, ehe man den Editor anschmeißt und dann einfach nur noch das Konzept Zeile für Zeile in Code umsetzt. Idealer Weise hat man den Programmablaufplan schon gedanklich durchgespielt, ob er die Funktionen richtig umsetzt und keine logischen Fehler enthält. Der Programmablaufplan kennt immer nur die Eingangssignale und nicht die Gedanken des Programmierers, um Entscheidungen zu treffen. Systematisches Herangehen läßt sich durch nichts ersetzen.
@ Peter Dannegger (peda) >Viel wichtiger als die Wahl der CPU finde ich das systematische >Herangehen an die Aufgabe, d.h. das Aufstellen eines Pflichtenheftes und >dann des Programmablaufplanes, sowie die Unterteilung der Funktionen in >sinnvolle kleine Module. Kann man nicht stark genug betonen! Gilt auch für Hardware, logisch. >Idealer Weise hat man den Programmablaufplan schon gedanklich >durchgespielt, ob er die Funktionen richtig umsetzt und keine logischen >Fehler enthält. Das halte ich für ein wenig zu hoch gegriffen. Solche Fehler findet man bei reinen gedanklichen Durchspielen eher nicht, von Offensichtlichkeiten mal abgesehen. >Der Programmablaufplan kennt immer nur die Eingangssignale und nicht die >Gedanken des Programmierers, um Entscheidungen zu treffen. Das ist aber ein voller Widerspruch zu dem vorherigen Satz ;-) Was du hier meinst ist ein Simultor bzw. ein Tool zum Softwareengineering, das Strukturen abbilden kann. >Systematisches Herangehen läßt sich durch nichts ersetzen. GENAU!!!!!!!!!!
Peter D. schrieb: > Wer gleich in den Editor schreibt "int main()", der hat schon verloren, > der ist kein Programmierer, sondern ein Frickler. Danke, dann bin ich eben ein Frickler. :-)) Gerade wenn's um kleine Controlleraufgaben geht, fange ich gern mal damit an, einfach erstmal ein bisschen lauffähige Software zu haben, die „keepalive“-LED vielleicht. Von da dann Stück für Stück weitere Dinge hinzusetzen und in Betrieb nehmen. Wenn sich am Ende rausstellt, dass nochmal was am Konzept geändert werden muss, finde ich das nicht schlimm: es gibt jetzt schon ausreichend viele, in sich in ihrer Funktion bestätigte Komponenten. Es fällt dann nicht allzu schwer, diese Komponenten beispielsweise in eine große state machine reinzusetzen, statt der ursprünglichen sehr simpel gehaltenen Hauptschleife. Letztlich muss da jeder seinen Weg finden, wie er effektiv ist. Ich gehöre halt nicht zu den Leuten, die dafür erstmal wochenlang nur Papier (oder Festplatten :) vollschreiben mögen, bis sie sich theoretisch sicher sind, dass das Konzept jetzt steht – um dann in der Praxis doch nur festzustellen, dass man dieses oder jenes nicht bedacht hatte. Ansonsten volle Zustimmung zum dem schon gesagten: einfach das machen, was einem Spaß macht. N. G. schrieb: > Konkret: Ist es besser bei einem Atmel-µC zu bleiben oder ist der > Umstieg auf eine STM32 nicht schwerer? Beides wird ähnlich schwer oder leicht sein. Falls du ARMs von Atmel ausprobieren willst, nimm dir möglichst was von den neueren, keine alten SAM3/4. Deren Peripherals sind einfach nur überalterte Dinosaurier, die irgendjemand vergessen hat, rechtzeitig aussterben zu lassen. ;-) Die neueren SAMD (Cortex-M0+) und Varianten davon sind in dieser Hinsicht um einiges angenehmer, und falls du schon mal was mit Xmegas gemacht hast (deren Peripherie ja auch einiges komplexer war als bei den älteren AVRs), dann wird dir da manches recht ähnlich vorkommen. Ein STM32F10x wiederum ist da auch nicht grundlegend anders organisiert. Was schon erwähnt wurde: Atmel hat mit die besten Datenblätter, es ist so ziemlich alles in einem drin, vom Pinout über die Beschreibung der Peripherie mit ihren Registern bis zu den elektrischen Parametern. Nur für die Core Peripherals (also das, was von ARM selbst kommt) verweisen sie mittlerweile auf ARM (bei SAM3/4 waren die auch noch im Datenblatt beschrieben). Bei einem STM32 muss man sich da schon mal drei oder vier Dokumente angucken, um das alles zusammen zu haben.
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.