Hallo Freunde Im thread zum Thema C oder ASM für µC habe ich erstmals über Haskell etwas gelesen und bin gleich ins Internet gegangen um mich zu informieren. Dabei sind einige Fragen bei mir aufgekommen, die ich gerne, hoffentlich positiv, beantwortet haben möchte, um damit Programme zu schreiben die auf meiner LPCXpresso1769 mit einem ARM Cortex M3 laufen. Ich habe dort eine auf Eclipse basierende IDE, früher von Code Red, jetzt im Eigentum von NXP. Habe ich es richtig verstanden, dass Haskell Programme in eine IDE basierend auf Eclipse eingebunden werden kann, so das die so modifiziete Tool Chain den Ablauffähigen Code erzeugt? Wenn ja, wie läuft dieses dann mit dem Debugger, usw.?
Habe es bisher nicht ausprobiert aber ich befürchte du wirst auf so beschränkter Hardware keinen Spaß mit Haskell haben. Alleine das automatische Speichermanagement wird schon ziemlich viel RAM schlucken. Wenn du etwas sinnvolles zum laufen bekommst würde mich das aber sicher interessieren.
Muss sein: https://xkcd.com/1312/ ;-) Aber ernsthaft, grade im Embedded Umgeld macht Haskell (oder genauer die gesamte Funktionale Programmierung) doch wenigsten Sinn. Gerade dort hat man doch traditionell ein Konstrukt aus globalen Variablen (und wenn es nur die SFR's) und programme welche auf Events warten und diese Variablen dann verändern. Genau dieses Umfeld ist doch das Gegenteil für was Haskell entwickelt wurde. gruß cyblord
:
Bearbeitet durch User
Erstmals Danke für eure Antworten. Ich versuche mir einen Überblick zu erhalten, da ich auch als Consultant im Industriebereich tätig bin und Haskell und ähnliche neue Sprachen genannt werden. @cyblord: Grundsätzlich hast du recht, aber... :) Mit Industrie 4.0, mit IoT, IIoT, usw., also mit der Verknüpfung von Internet und klassichen embedded Funktionen einerseits, entsteht immer mehr das Bedürfnis neben der klassischen „Embedded” Aufgaben um Sensoren und Aktoren, Funktionalität die durch die Interaktion mit der Cloud erfoderlich werden zu handhaben. Andererseits werden Implementationen von µC für den „Embedded” Bereich immer extremer Pad-limited, wodurch in den Cores immer mehr Platz frei bleibt, welcher sinnvoll gefüllt werden muss. Einer der trends, wie bei den ARM Cortex M4 zusehen, ist es mehrere Kerne , DSP usw. zu integrieren und wie auch bei TI zu sehen ist, jede Menge Software schon ab Werk in µC fest zu verankern. Mit der weiteren Miniaturisierung wird sich diese Herausforderung noch steigern und so werden Ausstattungsmöglichkeiten wahr, die man früher nie erwartet hätte. Auch fordert die steigende Komplexität der Software und die trotzdem eher kürzer werdenden Entwicklungszeiträume die Anbieter heraus für ihre Kunden Möglichkeiten zu schaffen, auch hier eine Beschleunigung zu erreichen. Es ist meine persönliche Überzeugung, resultierend daraus, das die ARM Cortex M* µC von diversen Herstellern es immer schwerer haben Alleinstellungsmerkmale zu schaffen, die Kunden zu ihren Produkten führen, welche die entwicklung pushen werden. Habe heute gerade von der neuen Familie Controllerboards von ST für ihre STF3 Controller gelesen. Es wird immer billiger und gleichzeitig werden die Lösungen immer mächtiger, die es Kunden ermöglichen in eine bestimmte produktfamilie einzusteigen. Auch sehen wir das die Anbieter, auch was die IDEs angeht und damit verbunden die Entwicklungswerkzeuge angeht, immer stärker diese Zielsetzung haben einem Kunden den Einstieg zu erleichtern und die Entwicklungszeitverkürzung weiter zu treiben. Bei NXP sind das z. B. die LPCXpresso* und die Übernahme von Code Red und der IDE. Ziehen wir dann unter diesem Gesichtspunkt noch die vereinheitlichte API für die Peripheriefunktonen, CMSIS, dann bietet es sich an eben auch die Lösung komplexerer Aufgaben für Zielsysteme in einen µC zu integrieren. Wiederhole, nur meine persönliche Spekulation, weshalb ich eben neue Sprache im Auge behalte.
Hellmut Kohlsdorf schrieb: > da ich auch als Consultant im Industriebereich tätig bin Merkt man gar nicht ;-) Na mal ehrlich, ist das ernst gemeint? Dein Beitrag ist ein einziges Bullshit-Bingo, wobei man bei "Industrie 4.0" bereits aufhören kann zu lesen. Keine deiner Ausführungen hat irgendwas mit Haskell zu tun.
:
Bearbeitet durch User
cyblord ---- schrieb: > Na mal ehrlich, ist das ernst gemeint? Dein Beitrag ist ein einziges > Bullshit-Bingo, wobei man bei "Industrie 4.0" bereits aufhören kann zu > lesen. Jepp, ich hatte den Fehler gemacht bis zur Hälfte weiterzulesen. So ein Buzzword Geleiere hab ich selten gelesen. Da ist ein neuer Power Point Held am Firmament erschienen.
Hellmut Kohlsdorf schrieb: > Erstmals Danke für eure Antworten. Ich versuche mir einen Überblick zu > erhalten, da ich auch als Consultant im Industriebereich tätig bin und > Haskell und ähnliche neue Sprachen genannt werden. Du bist sehr weit davon entfernt zu verstehen, was Haskell ist und wofür man diese Sprache sinnvoll einsetzen kann.
Ich kann nur zustimmen dass ich von Haskell keine Ahnung habe und deshalb Nachfrage. Wer sich nicht mit möglichen Randgebieten der eigenen Expertise beschäftigt, wird Randgebiete die in sein Gebiet einfluss nehmen nicht wahrnehmen. Mangelnde Lebenserfahrung wiederum erklärt eure Reaktion, da kann ich nur schmunzeln!
Hellmut Kohlsdorf schrieb: > Mangelnde Lebenserfahrung wiederum erklärt eure > Reaktion, da kann ich nur schmunzeln! 1.) Woher weißt du etwas über "unsere" Lebenserfahrung? 2.) Ein Minimum an Fachwissen erklärt bestens die Reaktionen auf deinen Post. 3.) Seit wann kann man damit die absonderung von 100% Bullshit rechtfertigen? Da können "wir" nur schmunzeln, Herr Consulter. Und jetzt wieder ab an die PowerPoint Präsi und nochn paar Buzzwords googlen. Das macht Eindruck beim Chef und ob den Fachleuten dabei das Frühstück wieder hoch kommt, kann dir ja egal sein, nicht wahr?
:
Bearbeitet durch User
Man kann auch einfach "haskell cortex m3" googlen und sich die ersten drei Links anschauen. Offenbar wird der Sourcecode mit jhc bzw. ajhc erst von Haskell nach C übersetzt. Das war mir so noch nicht bekannt. Wenn ich mal zuviel Zeit habe, schaue ich mir das näher an ;)
Es ist schon lustig anzusehen - man denkt, man hat es mit einem guten Thread zu tun und nach ein paar Beiträgen entpuppt sich der TE wieder nur als Troll. Aber Freitag ist noch nicht, oder? Wenn doch, kommt gleich die Frage, ob denn auch Java mit einem Monster-Framework auf jedem ATtiny läuft.....
wir wissen nicht was TO genau im Sinn hat. Embedded alleine ... sagt nicht viel. Wenn's um ein Framework geht, wo am Ende optimierter C-Code rauskommt, da spricht überhaupt nichts gegen Haskell. Siehe lava http://raintown.org/lava/ für FPGA Entwicklung.
Schade, das jemand so unsachlich wie cyblord sachliche Beiträge mit seinem emotionalen und aggressiven Ton abschreckt. War für mich interessant das zu tun was Mark empfiehlt und das mal zu googeln. Immerhin sieht man wie in einem Youtube Film ein in Haskell geschriebenes Programm auf einen Cortex M3 heruntergeladen und ausgeführt wird. Jede neue Sprache hat eine spezielle Zielsetzung und ich hatte bisher noch nie von Haskell gehört. Ich hätte früher auch nie geglaubt, dass Skript Sprachen eine Zukunft im Embedded Bereich hätten. Ja, die Zukunft ist eben voller Überraschungen. Aber der Trend bei dem Core eines µC durch sinnvolle Zusätze sinnvoll zu nutzen ist eine Tatsache, die auch ein nettes YouTube Video von NXP zum Thema Cortex M4 dokumentiert. Dort wird eben Ausssagen genau in die von mir geäußerte Richtung zum Thema Pad limited Design gesprochen! Vor vielen Jahren, ich war damals bei Motorola Semiconductor beschäftigt, wurde uns technisch begründet vorhergesagt, dass die Zukunft Multi-Core Lösungen im Prozessorbereich bringen würde. Wenn wir die Prozessoren im PC-Bereich betrachten, so kam das auch so und die gleichen Begründungen aus der Sicht des Halbleiter-Herstellers zeigen sich heute in den Multi-Core Prozessoren mobiler Einheiten. Jetzt, und der Cortex M4 war hier einer der Vorreiter, zeigt sich das auch im Embedded Bereich. TI mit seinen µC varianten mit integrierter Software für Motorsteuerungen ist ein weiteres Beispiel.
>TE wieder nur als Troll.
Hm. Das sehe ich eigentlich nicht so.
Hellmut hat eine (für mich) technisch interessant Diskussion begonnen.
Und cyblord hat ihn dann in seinem 2. und 3. Post persönlich angeriffen.
Wenn ich mit Kollegen zusammen bin und es kommt jemand hinzu der das
gleiche wie Hellmut sagt, dann würde ich NIE vor allen Leuten äußern:
"Na mal ehrlich, ist das ernst gemeint? Deine Aussage ist ein einziges
Bullshit-Bingo, wobei man bei "Industrie 4.0" bereits aufhören kann, zu
zu hören."
Ich versteh nicht, warum man das dann in einem Forum macht.
Almalma schrieb: >>TE wieder nur als Troll. > Hm. Das sehe ich eigentlich nicht so. > Hellmut hat eine (für mich) technisch interessant Diskussion begonnen. > Und cyblord hat ihn dann in seinem 2. und 3. Post persönlich angeriffen. > > Wenn ich mit Kollegen zusammen bin und es kommt jemand hinzu der das > gleiche wie Hellmut sagt, dann würde ich NIE vor allen Leuten äußern: In meinem Kulturkreis würden wir IHN an den Marterpfahl binden und mit Meerschweinchen-Köteln bewerfen bis er blutet. :oD OMG inzwischen verteidige ich schon Cyblord. Aber wo er Recht hat, hat er Recht. Manchmal ist er zu sensibel, aber im Grunde sind seine Beiträge immer lesenswert.
Almalma schrieb: > Wenn ich mit Kollegen zusammen bin und es kommt jemand hinzu der das > gleiche wie Hellmut sagt, dann würde ich NIE vor allen Leuten äußern: Jetzt mal ehrlich: Ich hätte es vielleicht nicht gesagt, aber doch gedacht. Die Anonymität von Internetforen verführen dazu eher zu schreiben, was man denkt. Aber vom Inhalt her gebe ich cyblord recht: Sehr viel heiße Luft und nichts dahinter. Genau so stellt ein Techniker sich doch den typischen Consultant vor: Grauer Anzug, Krawatte, PowerPoint. Und dann kommt eine halbe Stunde solch ein Geschwafel, Marketing-Speech. Sorry, es ist halt so. Hellmuth kann es auch positiv sehen: Nicht jeder kann das. Verkaufen ist eine Kunst. Die guten Verkäufer erkennen, mit welcher "Sprache" sie beim Kunden punkten. Den Chef mit Marketing-Speech zulabern, aber dann bei den Technikern knallharte Fakten präsentieren können, auch bei technischen Nachfragen Wissen parat haben UND DEN SCHWAFELMODUS ABSTELLEN KÖNNEN. Hellmuth sollte wissen, dass er hier halt bei den Technikern ist.
Tja, als ehemaliger FAE in der Halbleiterindustrie, ich bin ja unter Technikern da wisst ihr ja was das bedeutet, da kann man nur schmunzeln.
Hellmut Kohlsdorf schrieb: > War für mich > interessant das zu tun was Mark empfiehlt und das mal zu googeln. Erstaunlich dass du da nicht selber drauf gekommen bist. > Immerhin sieht man wie in einem Youtube Film ein in Haskell > geschriebenes Programm auf einen Cortex M3 heruntergeladen und > ausgeführt wird. WOW. Wer informiert die Medien? Das gibt ne Sondersendung. > Aber der Trend bei dem Core eines µC > durch sinnvolle Zusätze sinnvoll zu nutzen ist eine Tatsache, die auch > ein nettes YouTube Video von NXP zum Thema Cortex M4 dokumentiert. Das ist eine Selbstverständlichkeit. Nur kann man darunter alles und nichts verstehen. > Vor vielen Jahren, ich war damals bei Motorola Semiconductor > beschäftigt, wurde uns technisch begründet vorhergesagt, dass die > Zukunft Multi-Core Lösungen im Prozessorbereich bringen würde. Das war jedem klar dass die Takrate nicht unendlich erhöht werden kann, aber Moores Law weiter gilt. Und das hießt dann nunmal dass trotzdem immer mehr Chipfläche zur Verfügung steht und man diese dann mit zusätzlichen Cores füllt. > Wenn wir > die Prozessoren im PC-Bereich betrachten, so kam das auch so und die > gleichen Begründungen aus der Sicht des Halbleiter-Herstellers zeigen > sich heute in den Multi-Core Prozessoren mobiler Einheiten. Alles schön und gut, Microcontroller (und dabei meine ich nicht MiniComputer welche in Handys zum Einsatz kommen, da ist es ja schon so) werden evt. zunehmend auch MultiCore werden. Vielleicht. Weil hier ist bei der Taktrate noch gut Luft nach oben. Und solange das so ist, lohnt Multicore selten, weil das Aufteilen von Aufgaben auf mehrere Kerne viel schwieriger und ineffizienter ist, als einfach den Takt hochzudrehen. Und auch nicht immer klappt. Schneller klappt dagegen immer. ABER, was hat das Geschwurbel mit Haskell zu tun? Wo ist der Zusammenhang? Ich kann, vor allem mit geeigneten Compilern, fast jede Sprache auf einen Controller bringen, auf einen dicken Cortex allemal. Das was du sagst ist völlig richtig, völlig nutzlos und hat keinerlei Nährwert und geht schon gar nicht um den Threadtitel. Genau das ist das Problem. Du weißt gar nicht was du eigentlich sagen willst. gruß cyblord
:
Bearbeitet durch User
Für Haskell auf Embedded-Systemen ist es 10 Jahre zu früh. Generell wird sich Haskell nicht durchsetzen, außer in Nischen, würde ich wetten. Haskell ist sehr mächtig, die meisten hier können gar nicht begreifen, was echte, funktionale Programmierung bedeutet. Das alte Dilemma: Der Horizont des eigenen Denkens wird durch die eigene Sprache begrenzt. Darüber hinaus, um funktional programmieren zu können, benötigt man eine belastbare mathematische und informationstheoretische Bildung. Der Trend beim "Programmieren für die Masse" geht aber gerade zu möglichst geringen Einstiegshürden und möglichst einfache Umgebungen. Darum auch der Erfolg von Script-Sprachen. Möglichst jeder soll irgendwie programmieren können. Der Preisdruck ist riesig. Das steht im direkten Widerspruch zu funktionaler Programmierung. Der Trend ist doch, dass sich viele Programmiersprachen einen funktionalen Hauch geben in dem sie Funktionen als First-Class-Objekte einführen mit ein bisschen Lambda-Funktionen und eine Brise Currying gewürzt und das als Raketen-Technologie verkaufen. Wie war das noch mit Map & Reduce von Google? Ganze Bücher wurden gefüllt und die Newsticker und Blogs waren voll damit. Das ist in etwa so, als ob es Bücher die Dualzahlen als Weltneuheit verkaufen. Absolute, uralte Basics der funktionalen Programmierung und sonst nichts. Dass Hellmut Kohlsdorf keine Ahnung von Haskell und/oder funktionaler Programmierung hat, macht nichts. Da ist er Teil einer sehr großen Gesellschaft.
cyblord ---- schrieb: > Na mal ehrlich, ist das ernst gemeint? Dein Beitrag ist ein einziges > Bullshit-Bingo, wobei man bei "Industrie 4.0" bereits aufhören kann zu > lesen. Ja, das war cyblord's ZWEITER Beitrag, nachdem er zuerst ganz sachlich geantwortet hatte. K"onnte daran liegen, dass er als einer von wenigen mehr in Haskell gemacht hat als [1..] in den Interpreter einzugeben und zu staunen. Beim Wort Consultant geht mir auch der Hut hoch, vor allem wenn man's nicht f"ur sich behalten kann. Aber an diesem Beispiel erkennt man sehr sch"on was einen Consultant ausmacht: er kennt "Apfel und Birnen und meint die seien dasselbe. Aus "Apfeln kann man Most machen und daraus Schnaps. Dann h"ort er von Kartoffeln (Erd"apfel!). Also folgert er aus seiner Erfahrung dass Kartoffeln - wie Birnen auch - dasselbe sind wie "Apfel und daraus kann man Schnaps machen. Und wenn's dann tats"achlich funktioniert, sehen alle in ihm den Vision"ar, der das unm"ogliche schaffte. Dann st"ort auch gar nicht mehr, dass er zu keinem Zeitpunkt irgendwas kapiert hat und der Erfolg auf einem Irrtum beruht. Der Depp, der die Umwandlung von St"arke in Zucker hinbekommen hat, tja, der war ja bloss die ausf"uhrende Hand, nicht wahr? Dem hat ja der "Uberblick gefehlt.
Wie gesagt, ich gehe nur auf sachliche Aussagen ein. Haskell-Programmierer hat einen wertvollen Beitrag geleistet, danke.
Hellmut Kohlsdorf schrieb: > Wie gesagt, ich gehe nur auf sachliche Aussagen ein. Na dann bring doch selber auch mal so einen sachlichen Beitrag und nicht immer nur Satire. Außerdem bin ich auf deinen Beitrag sachlich eingegangen, aber da scheint nicht genug dahinter zu sein, als dass du auf Entgegnungen auch intelligent reagieren kannst. Somit bleibt dir wohl nur die jetzt gezeigte Reaktion als Option übrig.
Haskell auf dem µC lohnt sich -- für die Personalabteilung. Überleg mal, wer sich auf eine Stellenanzeige "Haskell-Programmierer(in) für Embedded gesucht" meldet, und welche Flut an HTML-Skript-Kiddies sich als "Javascript-Programmierer(in) für Embedded" sieht... Ob der Kerl nachher wirklich Haskell schreiben darf ist dann nebensächlich. Wo wir schon bei den Exoten sind: Hat jemand schon Prolog auf AVR portiert?
Hellmut Kohlsdorf schrieb: > Tja, als ehemaliger FAE in der Halbleiterindustrie FAE? soll das ein Fachinformatiker Anwendungsentwicklung sein? Der Ausbildungsberuf? Ich hatte da schon welche, die waren gut und andere, die haben sich hoffentlich auch als Powerpointbildchen-Schubser verdingt.
Udo Schmitt schrieb: > Hellmut Kohlsdorf schrieb: >> Tja, als ehemaliger FAE in der Halbleiterindustrie > > FAE? soll das ein Fachinformatiker Anwendungsentwicklung sein? Der > Ausbildungsberuf? Wikipedia spuckt dazu noch aus: > Field Application Engineer, englisch für Servicetechniker Beides an sich keine wirkliche Referenz um sch da besonders hervorzutun. Darum wohl Consulter. Da muss man nichts können, nur den Eindruck erwecken.
:
Bearbeitet durch User
Hellmut Kohlsdorf schrieb: > Dabei sind einige Fragen bei mir aufgekommen, die ich > gerne, hoffentlich positiv, beantwortet haben möchte, um damit Programme > zu schreiben die auf meiner LPCXpresso1769 mit einem ARM Cortex M3 > laufen. Ist das für Bastelprojekte von zu Hause gedacht oder für Projekte, welche die reale Welt bekommt? Für "reale Projekte" kann ich Dir nur ans Herz legen, bereits verbreitete Technologien und Tools zu verwenden. Um in einem Projekt schnell voranzukommen, brauchts heutzutage meist ein kleines Betriebssystem wie z.B. FreeRTOS oder was vergleichbares. Damit sind dann aber bereits die Programmiersprache und meist auch die anwendbaren Tools vorgegeben oder eingeschränkt. Exotische Programmiersprachen wie Haskell sind zwar zweifelsohne interessant oder gar in technischer Hinsicht überlegen, aber es wird einem niemand die Einarbeitungszeit bezahlen, man wird keine Kollegen finden, die solche Projekte warten können/wollen und man bekommt bei Problemen auch kaum Hilfe, sei es von Foren oder gar kommerziellen Anbietern.
:
Bearbeitet durch User
Für einen Troll ist die Sprache zu gestelzt. So redet keiner, der was weiß.
Johnny B. schrieb: > Exotische Programmiersprachen wie Haskell sind zwar zweifelsohne > interessant oder gar in technischer Hinsicht überlegen, aber es wird > einem niemand die Einarbeitungszeit bezahlen, man wird keine Kollegen > finden, die solche Projekte warten können/wollen und man bekommt bei > Problemen auch kaum Hilfe, sei es von Foren oder gar kommerziellen > Anbietern. Genau so sieht's aus. Wenn eine Firma will, dass die Entwickler alle Haskell können, dann muss sie eben entsprechende Schulungen durchführen.
Als ehemaliger "Field Applikation Engineer" bei einem Garagenunternehmen wie National Semiconductor und späterer Laborleiter bewundere ich immer wieder den Mut einzelner ihre Kompetenz und Professionalität so ungefiltert darzustellen! Eine der Dinge die ich früh gelernt habe ist keine Angst zu haben auch eventuell dumme Fragen zu stellen. Bekannter Weise gibt es ja keine dummen Fragen, sondern nur entsprechende Antworten. Der kürzeste Weg etwas in Erfahrung zu bringen, wenn eine erste Google Suche und eine Überprüfung der Beiträge hier im Forum nichts bringt, ist selber eine Frage zu stellen. Ich habe in einem anderen Thread in einem anderen Forum von dieser Programmiersprache gehört und möchte eigentlich wissen, für welche Aufgaben sie geeigneter ist. Aber macht euch keine Gedanken über eure freundlichen Beiträge. Diese sagen mehr über den Autor als über mich aus!
Hellmut Kohlsdorf schrieb: > Als ehemaliger "Field Applikation Engineer" bei einem Garagenunternehmen > wie National Semiconductor und späterer Laborleiter bewundere ich immer > wieder den Mut einzelner ihre Kompetenz und Professionalität so > ungefiltert darzustellen! lol nur echt mit dem 'K' in der Mitte :OD) > Eine der Dinge die ich früh gelernt habe ist keine Angst zu haben auch > eventuell dumme Fragen zu stellen. Das Du keine 'Angst' hast in diesem Sinne glaube ich Dir sofort. Wäre ich ein unhöflicher Mensch würde ich jetzt an dieser Stelle über das Wirken und Empfinden von Psychopathen referieren und ihren Mangel an Schamgefühl. Bekannter Weise gibt es ja keine > dummen Fragen, sondern nur entsprechende Antworten. > Der kürzeste Weg etwas in Erfahrung zu bringen, wenn eine erste Google > Suche und eine Überprüfung der Beiträge hier im Forum nichts bringt, ist > selber eine Frage zu stellen. Inzwischen darf (Sic! ;o) man sich anscheinend dann auch für hyperintelligent halten, nur weil man rudimentäre Suchfunktionen nicht bedienen kann. > Aber macht euch keine Gedanken über eure freundlichen Beiträge. Diese > sagen mehr über den Autor als über mich aus! Joo Brother, ebenso...
Haskell? Und sowas für embedded Systeme? Nun, eine Sprachen, die so unendlich offen ist wie Haskell für Dinge die noch garnicht definiert sind und die erst noch kommen müssen, mag für das "Sich ausdrücken können" von Mathematikern durchaus brauchbar sein, aber sowas hat im Embedded Bereich wohl keine Daseinsberechtigung. In den Gefilden, wo wir uns im täglichen Leben so herumschlagen, ist es viel wichtiger, auf Interrupts und gesetzte oder gelöschte Bits in irgendwelchen Registern zu REAGIEREN und die diversen Register der Hardware dann in passender Weise zu beschreiben oder sonstige Aktionen zu zelebrieren. Das ist alles imperativ und somit überhaupt kein Gegenstand einer völlig nicht-imperativen Programmiersprache. Also: Nö, kein Haskell, sowas ist hier nicht. Und nochwas an unseren Konsultanten: Hellmut Kohlsdorf schrieb: > Hallo Freunde.. Ja, ebenfalls Hallo. Allerdings wirken deine Zeilen hier in diesem Forum sehr befremdlich. Stellenweise sind sie sogar sachlich derart falsch, daß es mich nicht wundert, daß hier mit faulen Eiern nach dir geworfen wird. Kleines Beispiel: Chipgrößen. Sowas wie Cortex M0+ wurde erdacht, um noch mehr Chipgröße zu SPAREN - auf deutsch: kleinere Chips, dafür mehr davon auf dem Wafer, ergo mehr IC's, ergo niedrigerer Preis. Das ist ne ganz andere Dimension als "Industrie 4.0, mit IoT, IIoT, usw., also mit der Verknüpfung von Internet und klassichen embedded Funktionen" - blabla. Das sind nicht mal Schlagworte. Man könnte damit nicht mal bei BWLlern landen. schönen Abend, W.S.
Ich habe meine Antworten bekommen, ansonsten nochmals Anerkennung für den Mut euch so zu outen!
Hellmut Kohlsdorf schrieb: > Als ehemaliger "Field Applikation Engineer" bei einem Garagenunternehmen > wie National Semiconductor und späterer Laborleiter Und hier hats wohl nur Hauptschüler und Hilfsarbeiter in deinen Augen? FAE und Laborleiter ist jetzt nicht gerade der Hit um derart aufzutrumpfen und das zigmal betonen zu müssen. Hast du wenigstens studiert? > Ich habe meine Antworten bekommen, ansonsten nochmals Anerkennung für > den Mut euch so zu outen! Schlimm, hunderte Geisterfahrer jeden Tag auf der Straße... Aber nimms sportlich, du konntest hier mit deinem Pseudo-Techi-Gebrabbel halt nicht landen, bist aufgeflogen als Schaumschläger. Was solls. Kommt vor.
:
Bearbeitet durch User
Hi > Als ehemaliger "Field Applikation Engineer" bei einem Garagenunternehmen > wie National Semiconductor und späterer Laborleiter In größere Firmen wird meist nach dem Peter-Prinzip (http://de.wikipedia.org/wiki/Peter-Prinzip) befördert. MfG Spess
Hatte schon bei einigen Projekten mit FAEs zusammengearbeitet. Microchip, TI, Linear. Sie waren oft Feuerwehr, Produktberater, Schnittstelle zu den Halbleiterentwicklern oder halfen bei der Entwicklung von hardwarenaher Software. Das ist bestimmt die letzte Stelle, die eine Halbleiterunternehmen mit einer Pappnase besetzt. So wie ich das aus Udo's und cyblord's Antwort entnehme: >FAE? soll das ein Fachinformatiker Anwendungsentwicklung sein? Der >Ausbildungsberuf? >Wikipedia spuckt dazu noch aus: >> Field Application Engineer, englisch für Servicetechniker Haben die zwei wohl echt bei Wikipedia nachschauen müssen. Als Elektronikentwickler? Oder seid Ihr noch Schüler/Studenten ? Bei Bauer sucht Frau muss man sich weniger fremdschämen.
Hellmut Kohlsdorf schrieb: > Laborleiter Was ist denn ein Laborleiter in der Elektronik? Ich kenne den Begriff nur von den Chemieunternehmen.
Um noch ein Bisschen zum Ursprungsthema beizutragen (ob's dem TE hilft, kann ich nicht beurteilen): W.S. schrieb: > In den Gefilden, wo wir uns im täglichen Leben so herumschlagen, ist es > viel wichtiger, auf Interrupts und gesetzte oder gelöschte Bits in > irgendwelchen Registern zu REAGIEREN und die diversen Register der > Hardware dann in passender Weise zu beschreiben oder sonstige Aktionen > zu zelebrieren. Das ist alles imperativ und somit überhaupt kein > Gegenstand einer völlig nicht-imperativen Programmiersprache. Reaktive Anwendungen lassen sich nicht nur in imperativen Sprachen schreiben. Das beste Beispiel dafür sind Hardwarebeschreibungssprachen wie Verilog und VHDL, mit denen deklarativ Anwendungen mit stark ausgeprägter Reaktivität realisiert werden. Im Bereich der funktionalen Programmierung gibt es das Paradigma des "Functional Reactive Programming" (FRP), das rein deklarativ die Verarbeitung sowohl zeitkontinuierlich veränderlicher Signale als auch zeitdiskreter Ereignisse ermöglicht: http://en.wikipedia.org/wiki/Functional_reactive_programming Natürlich ist FRP auch in Haskell möglich (und das sogar ziemlich elegant, obwohl Haskell deutlich älter als FDRP ist): http://www.haskell.org/haskellwiki/Functional_Reactive_Programming Entsprechende Bibliotheken sind hier aufgelistet (teils allgemeiner Art, teils auf bestimmte Anwendungstypen zugeschnitten): http://hackage.haskell.org/packages/#cat:FRP Von dieser Seite steht der Verwendung von Haskell auf Embedded-Systemen also wenig im Weg. Ein Problem beim Einsatz auf einem LPCXpresso1769 würde ich eher hier sehen: haskell schrieb: > Habe es bisher nicht ausprobiert aber ich befürchte du wirst auf so > beschränkter Hardware keinen Spaß mit Haskell haben. Alleine das > automatische Speichermanagement wird schon ziemlich viel RAM schlucken. 64 kiB RAM sind schon etwas arg wenig. Das Haskell seine Vorteile erst bei komplexeren Anwendungen ausspielt, sollte man für einen sinnvollen Einsatz eine Hardware wählen, die auch in der Lage ist, nichttriviale Java- oder .Net-Programme auszuführen. Für die einfachen Dinge ist nach wie vor C die richtige Wahl. Ein weiteres Problem: Embedded-Softwareentwickler haben meist eine sehr hardwareorientierte Denkweise, und das ist auch gut so. Das bedeutet aber auch, dass diese Leute während der Programmierung stets die Schritt-für-Schritt-Ausführungweise des Mikroprozessors vor Augen haben, die eben von den imperativen, nber icht von den deklarativen Programmierparadigmen abgebildet wird. Möglicherweise sind deswegen Entwickler digitaler Schaltungen, die auch HDLs wie VHDL oder Verilog beherrschen, in Wirklichkeit die "besseren" Embedded-Programmierer, wenn es um den Einsatz von FRP geht. Das Ganze ist auf jeden Fall ein interessantes Thema, und ich bin sehr gespannt, für wieviele Jahrzehnte Mikrocontroller für Steuerungsaufgaben weiterhin in C programmiert werden. Einige werden es aber sicher noch sein, und wirklich schlecht ist C ja auch wieder nicht, auch wenn hier immer wieder ein paar Forenteilnehmer wie die Rohrspatzen darüber schelten ;-)
@Almalma: Danke für deinen Beitrag, brauchst dich nicht fremdschämen, eher den Mut der beiden an einer so öffentlichen Stelle sich so zu outen! @Tim: Meine Spezialität waren Graphikprozessoren und als wir bei NSC, die haben damals mit der Serie 32000 den ersten 32 Bit Prozessor auf den Markt gebracht, für bestimmte Anwendungsfelder Labore eingerichtet haben, haben mein Team und ich mit einem Prozessor, genannt NS32CG16 an einer Implementation eines Minitel Terminals für Alcatel gearbeitet. In einem gewissen Sinne war der NS32CG16 ein ganz früher µC. Er hatte einen Hardwarebeschleuniger für die Implementation der Datenübertragung. Der Highlight damals war die Vorstellung dieses Projektes bei ATT in Indianapolis, die berühmten Bell Labs. Solche Kompetenz und ein so effektives Management habe ich nie wieder in meinem Berufsleben erlebt. @Yalu: Auf solche kompetenten und Informativen Beiträge habe ich gehofft und freue mich sie zu erhalten. Danke. Wie gesagt, ich habe von Haskell keine Ahnung und werde es zwar auf meinem Radarschirm behalten, aber ohne jede Priorität. Die nur tangential hier angesprochenen Auswirkungen der Halbleitertechnologie, die für die Zukunft, z. B. aus nicht nur den genannten Bereichen resultierende steigende Software-Komplexität und der Wettbewerbsdruck der Anbieter von ARM Cortex M* basierenden Produkten werde ich hier nicht weiter diskutieren. Ich denke US Foren sind da geeigneter.
Hellmut Kohlsdorf schrieb: > @Almalma: Danke für deinen Beitrag, brauchst dich nicht fremdschämen, > eher den Mut der beiden an einer so öffentlichen Stelle sich so zu > outen! Wechsel mal die Platte. Immer der gleiche sinnfreie Psalm. Gilt das als Schick oder besonders intelligent in deinen Kreisen? Das Problem ist, du kannst hier noch und nöcher deine angebliche Kompetenz durch angebliche extrem wichtige Positionen betonen (was du ja auch ausgiebig tust). Nur, man kann ja lesen was du so schreibst und da schimmert keine Kompetenz durch (außer zum labern). D.h. was glauben wir nun? Das was du vorgibst zu sein oder das was wir von dir lesen? Hmm.. Bestes Zitat zu deinen Ausfürungen: > So redet keiner, der was weiß. Das bringts auf den Punkt. Aber sowas von.
Ich finde es sehr wichtig, die theoretische Nutzbarkeit der noch so albernsten Vorstellung zu untersuchen. Ich würde sogar soweit gehen, dem ARM Cortex als zu schwach zu bezeichnen, da eine gedachte PHP-Interpretation, die in Haskell geschrieben wurde, JavaScript ausführt, das simple Rechenoperationen ausführt – etwa die Addition, Subtraktion oder Multiplikation zweier vom Benutzer eingegebener Zahlen. Damit belegt man anschaulich, dass Turing-vollständige Sprachen ineinander umgeformt werden können, selbst wenn sie verschiedenen Programmierparadigmen entstammen. Ob man nun aber eine Tastenentprellung oder blinkende LEDs mit einem ARM-Prozessor der mit Haskell beschickt wird besser hinbekommt, ist eine Definition von »besser«. Wer eine gewisse Summe Geld zur Verfügung hat, die deutlich größer ist, als das Problem erfordert, der kann natürlich auch einen Teil der Mittel in Eiscreme oder eben Haskell-ARMs investieren. Wer dagegen das Problem elegant zu lösen versteht, d.h. so, dass nichts weggelassen werden kann, zeigt, dass nicht nur ein Problem existiert, sondern es auch verstanden wurde. Beim gesamten Gesprächsfaden kann ich kein zu lösendes Problem finden und die Eleganz beschränkt sich auf Expertenduelle…
Boris Ohnsorg schrieb: > Beim gesamten Gesprächsfaden kann ich kein zu lösendes Problem finden Genau. Wenn man diskutieren will, welche Programmiersprache zur Lösung geeignet ist, so muss man zuerst einmal die Aufgabe konkret benennen.
:
Bearbeitet durch User
Mark Brandis schrieb: > Genau. Wenn man diskutieren will, welche Programmiersprache zur Lösung > geeignet ist, so muss man zuerst einmal die Aufgabe konkret benennen. Hat er doch: Hellmut Kohlsdorf schrieb: > Industrie 4.0, mit IoT, IIoT, usw., ;) Oliver
@Oliver: Der Bezug auf die hier genannten Anwendungsfelder diente nur als Beispiele, das Embedded Systeme immer mehr mit Aufgaben konfrontiert sein werden, die nicht nur die Hardware Nähe haben, die bisher ihre Aufgaben bestimmte. Also auf Haskell bezogen, gar keine Rolle spielen oder Spielen müssen, da ich ja von Haskell nichts wusste! Also hat meine Frage zu Haskell nichts mit einer konkreten Aufgabe zu tun, sondern nur was Haskell ist und wofür es sich wird eignen können. Wenn man also die Beiträge von Mark Brandis und Oliver heranzieht, was wäre denn eine Aufgabe bei der eine Programmiersprache wie Haskell in Frage käme und um wie viel mächtiger müsste ein µC sein und wie viel Ressourcen müsste er haben, im Vergleich z. B. zu einem LPC1769. Die Mächtigkeit der µC steigt ja enorm, gerade wenn ich die Beiträge im Internet zur Programmierung von µC mit mehreren Kernen lese, scheint die Art der Nutzbarkeit mehrerer Kerne noch ein aktuelles Problem zu sein. Wenn ich mich wieder auf das YouTube Video von NXP zu ihrem ARM Cortex M4, eine Kombination aus M0 und M3 Kern beziehe, gibt es da ja interessante Ansätze!
Hellmut Kohlsdorf schrieb: > Also hat meine Frage zu Haskell nichts mit einer konkreten Aufgabe zu > tun, sondern nur was Haskell ist und wofür es sich wird eignen können. Also noch mal in aller Ruhe: Haskell scheint mir eine Sprache zu sein, die primär dazu gedacht ist, sich mathematisch-technisch ausdrücken zu können, also als Rüstzeug für Mathematiker und Informatiker im gegenseitigen wissenschaftlichen Disput zu dienen. Früher hatten sich die Gelehrten aus aller Welt per Latein verständigt, heutzutage per Englisch - und vielleicht in besonderen Fällen eben auch mal in Haskell... Die Verwendung von Haskell zum Füllen des controllerinternen Flashroms zwecks Programmierung dieser Hardwareteile dürfte eher überhaupt nicht bei der Fassung der Sprache vorgesehen worden zu sein - und ob man sowas trotzdem hinkriegen kann, ist fraglich. Obendrein kommt zumindest MIR die Frage hoch: WOZU BLOSS? Wo ist der den Einsatz begründende Nutzen? Ich sehe nur gewaltigen Overhead, aber keinen Nutzen. Und nochwas: Yalu X. schrieb: > Reaktive Anwendungen lassen sich nicht nur in imperativen Sprachen > schreiben. Das beste Beispiel dafür sind Hardwarebeschreibungssprachen > wie Verilog und VHDL, mit denen deklarativ Anwendungen mit stark > ausgeprägter Reaktivität realisiert werden. Mei Liaber, das geht nach hinten los - und dies aus zwei Gründen. Zum einen sehe ich sowohl VHDL als auch Verilog durchaus als imperative Sprachen, denn sämtliche Logik wird durch Zuweisungen, also imperativ geschrieben, im Prinzip etwa so: Lasse X sein gleich A or B and C xor D... eben durch Zuweisung. (jetzt mal nicht an meiner basiclike Formulierung mosern..) Zum anderen gibt es gerade in VHDL eine riesige Menge von Ausdrucksmöglichkeiten (in denen sich unsereiner immer wieder verheddert), die grundsätzlich NICHT synthesefähig sind und demzufolge niemals dazu gedacht waren, in irgendein Stück Silizium gegossen zu werden. Das alles sind eben keine akzeptablen Argumente, um zu behaupten, daß derartige Sprachentwicklungen in der Zukunft für das Beleben von Mikrocontrollern eine wichtige Rolle spielen könnten. Kommen wir zum auf's Wesentliche von mir stark gekürzten Ausgangspunkt: "(ich)..habe..über Haskell..gelesen.. (und möchte)..damit Programme schreiben (für) LPCXpresso1769 mit Cortex M3" Klare Antwort an den TO: Laß den Versuch lieber bleiben und mach was Praktischeres und Nützlicheres, z.B. weiterbildende Beiträge für dieses Forum verfassen. Ich hätte da so einige Vorschläge, z.B. die Lernbetty stark modernisiert auf ein STM32F4xx-Discovery-Board umsetzen, oder ne Sammlung von USB-VCP-Treibern für alles, was irgendwie "ARM" heißt - aber mit vereinheitlichter Schnittstelle zum benutzenden Programm hin, oder ein wirklich kleines, aber gut skalierbares GDI für alles, was Grafik-LCD heißt, oder..oder.. Das wäre mal was Nützliches für all diejenigen, die hier im Forum nach Hilfe rufen. W.S.
W.S. schrieb: > Yalu X. schrieb: >> Reaktive Anwendungen lassen sich nicht nur in imperativen Sprachen >> schreiben. Das beste Beispiel dafür sind Hardwarebeschreibungssprachen >> wie Verilog und VHDL, mit denen deklarativ Anwendungen mit stark >> ausgeprägter Reaktivität realisiert werden. > > Mei Liaber, das geht nach hinten los - und dies aus zwei Gründen. > Zum einen sehe ich sowohl VHDL als auch Verilog durchaus als imperative > Sprachen, denn sämtliche Logik wird durch Zuweisungen, also imperativ > geschrieben, im Prinzip etwa so: > Lasse X sein gleich A or B and C xor D... eben durch Zuweisung. (jetzt > mal nicht an meiner basiclike Formulierung mosern..) Nein, das ist nicht imperativ und erst recht keine Zuweisung. Wäre diese der Fall, dann könntest du in der nächsten Zeile bspw.
1 | Lasse X sein gleich A and B |
schreiben, um X einen neuen Wert zuzuweisen. Aber genau das geht in einer HDL nicht, da ein Signal nicht gleichzeitig das Resultat zweier unterschiedlicher logischer Verknüpfungen andere Signale sein kann. In einer realen Schaltung käme dies einem Kurzschluss gleich, da in X zwei Ausgänge von Logikgattern zusammenstoßen. Es gibt zwar in VHDL und Verilog auch imperative Konstrukte, aber das sind genau die, die hinterher > NICHT synthesefähig sind und demzufolge niemals dazu gedacht waren, in > irgendein Stück Silizium gegossen zu werden. Der Teil der HDLs, der für ihren ursprünglichen Zweck, nämlich die Beschreibung der Hardware vorgesehen ist, ist jedenfalls rein deklarativ. W.S. schrieb: > Kommen wir zum auf's Wesentliche von mir stark gekürzten Ausgangspunkt: > "(ich)..habe..über Haskell..gelesen.. (und möchte)..damit Programme > schreiben (für) LPCXpresso1769 mit Cortex M3" > > Klare Antwort an den TO: Laß den Versuch lieber bleiben Ja, darin sind wir uns einig :)
Whow, hier steige ich schon aus! Das ist mir zu hoch! Aber es ist sicher lesenswert und über hier auftauchende Begriffe und ihre Bedeutung zu erkunden werde ich so manche zeit spendieren, rein aus privaten Gründen! es gibt eben wirklich Fachleute in diesem Forum.
Hellmut Kohlsdorf schrieb: > Whow, hier steige ich schon aus! Das ist normal, yalus Beiträge muss man immer 3 bis 5 mal lesen, bis man sie kapiert. ;-)
Haskell ist ja wohl ein Witz. Ich programmiere meine Controller in German: http://esolangs.org/wiki/German
ass schrieb: > http://esolangs.org/wiki/German >BEER becomes a 1 in binary and SCHNITZEL becomes a 0. Wie einfallslos
ass schrieb: > Haskell ist ja wohl ein Witz. Ich programmiere meine Controller in > German: > > http://esolangs.org/wiki/German Ein besserer Witz ist, dass Du deinen Benutzernamen klein schreibst. Ist das Englisch?? Hihihi...
Hellmut Kohlsdorf schrieb: > Der Bezug auf die hier genannten Anwendungsfelder diente nur > als Beispiele, das Embedded Systeme immer mehr mit Aufgaben konfrontiert > sein werden, die nicht nur die Hardware Nähe haben, die bisher ihre > Aufgaben bestimmte. Ach je, da gibt es noch so ein paar Schlagworte, die seit einger Zeit durch die Bullshit-Bingo-Listen geistern, und die zumindest vom Wunschdenken her in den dahinterstehnden Stückzahlen das bißchen Insdustriegedöns um Größenordnungen übertreffen: Das eine sind Wearables, das andere ist das "Internet der Dinge". Letzteres geistert schon so lange, daß es dafür soagr schon eine deutsche Bezeichnung gibt. Internet der Dinge basiert ja nun auch igendwie darauf, das alles mit jedem und überhaupt irgendwie vernetzt ist. Wenn der Kühlschrank online beim Lebensmittelhändler ordern kann (und das wird er garantiert ganz ohne Haskell tun), sollte so ein bischen Industrie 4.0 auch noch hinzubekommen sein. Oliver
@hkohlsdorf: das Thema ist valide, siehe hier [[https://www.embedded.com/electronics-blogs/say-what-/4460422/Achieving-memory-safety-without-compromise]. Auf Github wurden die Haskell Libraries und der UAV Flight Controller (PX4, STM32F4) aus dem Projekt veröffentlicht.
Ocaml, F#, selbst Go ist für cortex m4 zu schwer. Die notwenige runtime Umgebung wird nicht reinpassen. Und ohne garbage collector ist es nicht mehrdas gleiche. Davon abgesehen, gibt es in auch HDL Ansatz mit Haskell. Siehe lava
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.