hallo, ich bin weder Bastler noch Elektroniker noch C-Programmierer. d.h. ich habe in diesem Umfeld 0 Erfahrungswerte . und dennoch erlaube ich mir , eine Idee zu haben , und die würde ich auch gerne umsetzen. die entscheidende , aber auch schwierigste Frage ist im Augenblick, die richtige Plattform für die Realisierung zu wählen. ich kenne mich einigermaßen aus mit betriebssystembasierten Systemen und bin sogar bis vor kurzem sogar davon ausgegangen, daß dies eine zwingende Voraussetzung für jedes System ist. :) ich würde also von Haus aus ein solches System präferieren. es steht auf der einen Seite ein Intel basiertes Industrieboard im low power Bereich oder evtl auch ein RASPI 3 , jeweils mit Windows 10 IOT - - meine Präferenz- oder einem Linux Derivat. wie spreche ich auf einem solchen Board die I/Os an, wenn es keine oder zu wenige I/Os auf einer leiste auf dem board gibt ? gibt es da irgendetwas über PCIe ? ist USB 2.0 oder ggf. 3.0 schnell genug ? und auf der anderen Seite ein Arduino, STM8 oder STM32 basiertes System , vor das, wenn es notwendig werden sollte, noch ein OS basiertes System geschaltet wir. oder als 3. Weg. die aufgeführten Microcontroller laufen in einer VM auf dem Industrieboard unter windows 10 IOT . die Microcontroller verarbeiten jeweils in Echtzeit, das ist mir bekannt, diese Welt ist mir aber eigentlich fremd . wann ist der einsatz von Microcontrollern ein MUß ? jeder Hinweis ist für mich wertvoll danke
:
Gesperrt durch Moderator
Norbert F. schrieb: > ich kenne mich einigermaßen aus mit betriebssystembasierten Systemen und > bin sogar bis vor kurzem sogar davon ausgegangen, daß dies eine > zwingende Voraussetzung für jedes System ist. :) > ich würde also von Haus aus ein solches System präferieren. Das ist auch kein Problem. Sehr vieles lässt sich z.B. mit einem Raspberry PI realisieren. Dafür gibt es auch Realtime Extensions. Alternativ: einen weiteren Mikrocontroller per Serial SPI I2C oder ähnliches anhängen. > leiste auf dem board gibt ? gibt es da irgendetwas über PCIe ? ist > USB 2.0 oder ggf. 3.0 schnell genug ? Für deine nicht weiter spezifierten Anforderungen? PCIe hat ein Raspberry PI nicht. > oder als 3. Weg. die aufgeführten Microcontroller laufen in einer VM > auf dem Industrieboard unter windows 10 IOT . Damit kriegst du definitiv kein Timing mehr hin... Fragt sich halt, was du timingmässig brauchst. Der Support von Libraries und Software dürfte auf jeden Fall mit Raspbian viel besser sein als mit Windows 10 IOT. Windows ist grundsätzlich immer mühsam in embedded Systemen... Deine Frage ist aber zu offen für eine konkrete Antwort. Kaufe dir doch einfach ein PI, und mache mal ein paar Tutorials, LED ansteuern oder so... mfg Andreas
Äh diese Frage können wir nicht beantworten ohne dein Ziel zu kennen! Norbert B. schrieb: > und dennoch erlaube ich mir , eine Idee zu haben , und die würde ich > auch gerne umsetzen. Bitte nenne diese Idee :) Wie du dir vieleicht denken kannst, haben sowohl OS-gestütze Geräte wie der Raspi eine Daseinsberechtigung, ebenso wie Mikrocontroler. Was sinnvoll ist, hängt wirklich vom Einsatzgebiet ab, denn z.B. kann man auch beides verwenden: Einen Raspberry als Host mit kleinen (vorprogrammierten Mikrocontrolern, oder in Hardware gegossenen, integrierte Schaltungen) für die Aufgaben die der Raspi nicht von Haus aus kann (z.B. analoge Signale verarbeiten und PWM Ausgänge bieten). PCIe gibt es tendenziell nicht zum Nutzen für bastleraufgaben. Für iOs ist das auch nicht nötig. Wenn dir die Pins des Raspi nicht reichen, gibt es sogenannte "Port Expander". Die gibt es in etlichen Ausführungen. Teils angesteuert über bestehende IOs oder über die Busse wie i2c oder SPI. Über letzteres kann man sogar kleine Farb-Displays ansprechen, also für iOs reicht die Geschwindigkeit alle mal. > die Microcontroller verarbeiten jeweils in Echtzeit, das ist mir > bekannt, diese Welt ist mir aber eigentlich fremd . > wann ist der einsatz von Microcontrollern ein MUß ? Oft nötig wenn Dinge exakt vorhersagbar und oder synchron laufen müssen. Z.B. feine Schrittmotoren antreiben. Außerdem wenn Analogsignale verarbeitet werden müssen. Die allermeisten gängigen Sensoren wie Entfernung, Temperatur, Luftfeuchtigkeit, Bewegung, Schwerkraft etc. gibt es bereits mit einem Digitalisierungs-Chip onboard so dass man den direkt an den Raspberry anbinden kann. Das gilt sogar für Sound-Verarbeitung, auch wenn man da mit etwas Latenz rechnen muss. Programmiert wird dann meist übrigens eher in Python als C. Bzw. du wirst mehr tutorials in Python finden. Wenn extrem kurze Reaktionszeiten gefragt sind, macht C aber sicherlich Sinn. Btw. Windows iOT würde ich als tendenziell weniger anfänegrfreundlich bezeichnen... belib lieber beim Linux, wenn du ein Raspberry verwenden willst. Oder willst du unbedingt C# oder .NET Komponenten verwenden?
:
Bearbeitet durch User
vielen dank , andreas der RASPI ist auch nicht mein präferiertes System für Windows 10 IOT. der Raspi ist schon mit seiner Bootdauer sehr gewöhnungsbedürftig für mich. in 1. Präferenz denke ich an ein Intel Z3735 basiertes Industrieboard . da gibts dann RAM satt, SATA und keinen SD Speicher mehr . habe ich noch nicht gefahren, ich gehe aber davon aus, da kriege ich eine standard rechnerperformance. was ist dann mit einer z.B. STM32 - oder ARDUINO VM ? dann hätte sich das Problem mit den Libraries ja erledigt . auf der anderen Seite habe ich hier einige Beiträge in diesem Forum gelesen, die diese Arduino Libraries als ineffizient deklarieren und die direkte eigene Programmierung bevorzugen. es geht bei der Sensorik um eine Fahrzeugsensorik. die eigentliche Motoransteuerung läuft in Echtzeit über einen STM 32. ich gehe zunächst davon aus, daß ich keine Reaktionszeit unterhalb einer Sekunde brauche . bis dann
Norbert B. schrieb: > es geht bei der Sensorik um eine Fahrzeugsensorik. die eigentliche > Motoransteuerung läuft in Echtzeit über einen STM 32. > > ich gehe zunächst davon aus, daß ich keine Reaktionszeit unterhalb einer > Sekunde brauche . > > bis dann Was für Sensoren sind das? Hoffe mal schwer dass du da nichts bastelst was später für Crashes auf der Autobahn führen kann... Des weiteren sollte dir bewusst sein dass "Industrieboards" schlicht eine deutlich höhere Einstiegshürde darstellen! Das Frustrationsrisiko ist entsprechend hoch. Ganz ohne Vorerfahrung? Da hast du eine ganz schöne lernkurve vor dir. Ob die Arduino libs inefizienter sind, drüber lässt sich sicherlich streiten, aber erneut ist der Grund wieso das so ist: Anfängerfreundlichkeit! Übrigens kann man die Bootzeit eines Raspberrys ohne Probleme unter 8 Sekunden drücken wenn keine grafische Oberfläche nötig ist!
:
Bearbeitet durch User
hallo alex, ich habe das mit dem LINUX als Empfehlung hier so schon erwartet. ich würde es eigentlich gerne vermeiden , habe zuviel zeit in meinem Leben verschwendet in meiner aktiven Zeit, allein schon dafür, irgendwann einmal auch ein bestimmtes Derivat oder eine GUI instaliert zu haben, um sich einen Eindruck zu verschaffen. und wenn ich mir heute auf der Raspberry Seite die Anzahl der Derivate ansehe, kriege ich Luftnot. und hinter keinem steht die Restlebensdauer . :) 1981 gab es die CPU 8086 . das war ein unechter 16bitter . und auf dem lief DOS 3.3 als erster stabiler DOS Version . DOS 6.22 war dann die letzte Version aus der DOS Reihe . und und ... dann gab es windows , windows for workgroups und und ... und windows gibt es heute noch und im Grunde läuft jedes DOS Programm heute noch. und es gab im laufe der Zeit jede menge UNIX Versionen . ich habe viele Jahre mit einem UNIX auf einer ALPHA und auch MIPS CPU gearbeitet . kennt das heute noch jemand ? anders als ein Entwickler, der jede neue Möglichkeit, die ihm das System neu bietet, euphorisch feiert, will ich nur meine investierte Arbeit gesichert wissen. Investitionssicherheit hat für mich die oberste Priorität und die habe ich nur auf einem System, das gesichert mitwächst. ich werde zum Teil bei der Entwicklung auf fremde Expertise zurückgreifen müssen und das möchte ich dann nicht abschreiben. danach kommt aktuell jetzt neu die Datensicherheit . und die bietet mir derzeit kein LINUX und kein ANDROID System auf einem 1PC. da sehe ich als Basis bei den Derivaten sämtlich nur Uraltkernel. ich habe intensiv recherchiert, weil ich Zweifel hatte, win 10 IOT würde den Gang des WIN Telefon OS gehen. mittlerweile bin ich davon überzeugt, daß das Produkt bei MS strategisch ist. Jetzt aber zu deiner INFO über die I/O s: habe ich das richtig verstanden, daß es , wenn ich mit I2C oder wahrscheinlich dann auch LIN oder CAN Bus aus dem Industrieboard herauskomme, daß es dann GPIO adaptionen gibt, die an den Bus gehängt werden können , sowhl digital als auch analoge ? das wäre DIE Lösung . bis dann
Norbert B. schrieb: > was ist dann mit einer z.B. STM32 - oder ARDUINO VM ? > dann hätte sich das Problem mit den Libraries ja erledigt . Ich nehme mal an, dass du mit VM eine virtuelle Maschine meinst? So etwas gibt es nicht für Mikrocontroller und macht auch keinen Sinn. Der ganze Sinn von Mikrokontrollern ist ja gerade, dass man einen Chip mit den entsprechend benötigten Hardwareschnittstellen hat um sein Vorhaben zu realisieren. Bei einer VM fällt das ja gerade weg oder wenn man die Schnittstellen tatsächlich irgendwie rausführt kann man sich auch gleich die VM sparen. Die einzigen Fälle wo sowas Sinn macht ist um sein Programm auf dem PC zu debuggen. Aber auch da wird man häufig das Problem haben, dass die extern anzusprechende Hardware nicht vorhanden ist oder auch irgendwie emuliert werden muss.
hallo alex, welche sensoren ß das sind speed sensoren, kraftsensoren, kontaktsensoren, GPS sensorik , evtl auch gyroskop , höhenmeter .... mit der autobahn gibts kein risiko .... :) nonono . es geht um eine neue Definition , ein LEV -light electric vehicle- . warum soll das Industrieboard ein höheres Frustrationsrisiko als ein ein RASPBERRY unter WIN 10 IOT haben ? das sehe ich eher umgekehrt . ich habe grosse Sorge wegen der möglichen Antwortzeiten auf dem Raspberry . das würde mich frustig machen, wenns nicht flüssig läuft. jetzt aktuell hab ich auf s einem RASPI 2. den hatte ich noch . und der braucht seine Zeit beim Booten .... und zu dir, sebastian , für den ARDUINO gibt es eine VM .
Norbert B. schrieb: > hallo alex, > ich habe das mit dem LINUX als Empfehlung hier so schon erwartet. > > ich würde es eigentlich gerne vermeiden , habe zuviel zeit in meinem > Leben verschwendet in meiner aktiven Zeit, allein schon dafür, > irgendwann einmal auch ein bestimmtes Derivat oder eine GUI instaliert > zu haben, um sich einen Eindruck zu verschaffen. > und wenn ich mir heute auf der Raspberry Seite die Anzahl der Derivate > ansehe, kriege ich Luftnot. und hinter keinem steht die Restlebensdauer > . :) > > 1981 gab es die CPU 8086 . das war ein unechter 16bitter . und auf dem > lief DOS 3.3 als erster stabiler DOS Version . DOS 6.22 war dann die > letzte Version aus der DOS Reihe . und und ... > dann gab es windows , windows for workgroups und und ... > und windows gibt es heute noch und im Grunde läuft jedes DOS Programm > heute noch. > > und es gab im laufe der Zeit jede menge UNIX Versionen . ich habe viele > Jahre mit einem UNIX auf einer ALPHA und auch MIPS CPU gearbeitet . > kennt das heute noch jemand ? > > anders als ein Entwickler, der jede neue Möglichkeit, die ihm das System > neu bietet, euphorisch feiert, will ich nur meine investierte Arbeit > gesichert wissen. Investitionssicherheit hat für mich die oberste > Priorität und die habe ich nur auf einem System, das gesichert > mitwächst. > ich werde zum Teil bei der Entwicklung auf fremde Expertise > zurückgreifen müssen und das möchte ich dann nicht abschreiben. > > danach kommt aktuell jetzt neu die Datensicherheit . und die bietet mir > derzeit kein LINUX und kein ANDROID System auf einem 1PC. > da sehe ich als Basis bei den Derivaten sämtlich nur Uraltkernel. > > ich habe intensiv recherchiert, weil ich Zweifel hatte, win 10 IOT > würde den Gang des WIN Telefon OS gehen. mittlerweile bin ich davon > überzeugt, daß das Produkt bei MS strategisch ist. > .... Der „unechte 16Bitter“ war der Intel 8088 Und zum Test Deiner Expertise: Du bis in den 80ern unter DOS gescheitert, danach unter Unix, später unter Linux Sorry, aber wenn jemand nach so vielen Jahren Erfahrung, so ein Müll zusammenschreibt...
Norbert B. schrieb: > und zu dir, sebastian , für den ARDUINO gibt es eine VM . Das ist genauso Sinnvoll wie Sex mit Kondom... Kann man machen, lohnt sich aber nicht. Ich glaube du bringst da etwas völlig durcheinander, einen Microcontroller wie einen AVR (was ja die meisten Arduino Dinger sind) kann man sicherlich emulieren und debuggen. Aber was macht das für einen Sinn? Ein Microcontroller ist dazu da um mit der Außenwelt zu interagieren, wie soll das in einer VM ablaufen? Woher soll er in einer VM wissen welcher Sensor welchen Wert liefert?! Zu deinem Vorhaben: Wenn ich da lese "Speed, Kraft, Gyro..." und dann "...unter einer Sekunde brauche ich nicht!". Eine Gyro Auswertung mit einem Herz ist absolut Absurd und fern jeglicher Realität. Solche Sensoren fragt man mit mehreren kHz ab um eine flüssige Statemachine zu habe - gerade im Automotive Bereich. Das was du brauchst ist weder ein "Industrie-Pc" noch einen Raspberry - um ein gewisses Maß an Echtzeit zu erhalten (Geplanter Zeitablauf / nicht Geschwindigkeit!) kommst du da nicht um ein Microcontroller rum. Wenn in dem Fahrzeug bereits mit STM gearbeitet wird - dann wäre dieser die erste Wahl. Mit allen anderen machst du dich nur unglücklich.
:
Bearbeitet durch User
für den "schlauen" hunsbückel ein auszug aus wikipedia : ------------------------------------------------------ The 8086[1] (also called iAPX 86 )[2] is a 16-bit microprocessor chip designed by Intel between early 1976 and mid-1978, when it was released. The Intel 8088, released in 1979, is a slightly modified chip with an external 8-bit data bus (allowing the use of cheaper and fewer supporting ICs[note 1]), and is notable as the processor used in the original IBM PC design, including the widespread version called IBM PC XT. der 8088 war meiner erinnerung nach die 1.CPU in einem PC . ich gleube nicht, daß du jemals 256kb DRAMS gesteckt hast , bei den 8088 hatten die noch 180ns zugriff , damals gab es RAM nur mit paritybit wegen der fehleranfälligkeit, also jeweils 9 stück . also halte dich lieber bedeckt, wenn sich erwachsene unterhalten. ich habe einleitend gesagt, daß ich weder löte noch programmiere. es gibt auch ganz andere projekte, die man mit nem rechner anstoßen kann. es gibt wahrscheinlich in deinem berufsleben auch jemanden, der dir die aufgaben zuteilt , dazu muß er nicht selbst löten können.
Leider muss ich Hunsbuckel Recht geben. Weiss garnicht wo ich anfangen soll, das alles zu wiederlegen was du gesagt hast! o.O Was zum henker interessiert dich die Lebensdauer des OS? Dein Argument kann ich für PCs voll und ganz verstehen - Linux wird sich da höchstwahrscheinlich nie durchsetzen - aber das gilt nicht für Embedded und für Hobbyprojekte! Solche Geräte entwickelt man und lässt sie dann tendenziell ohne Updates laufen. Problematisch ist das maximal dann wenn du nen Webserver der von außen zugreifbar ist, darauf laufen lassen willst. Des weiteren ist Linux nicht lansgamer als Windows... Wenn man nicht grad als Entwickler riesigen Mist baut, kriegt man die 0.5s Reaktionszeit auf beiden hin. Norbert B. schrieb: > habe ich das richtig verstanden, daß es , wenn ich mit I2C oder > wahrscheinlich dann auch LIN oder CAN Bus aus dem Industrieboard > herauskomme, daß es dann GPIO adaptionen gibt, die an den Bus gehängt > werden können , sowhl digital als auch analoge ? > > das wäre DIE Lösung . Das ja, aber viel Spaß dabei eine library für das Baord zu finden mit dem du die externen Chips ansprechen kannst! Sorry aber was du vor hast ist KEIN EINSTIEGSPROJEKT! Glaube du stellst dir alles viel, viel zu einfach vor und schlägst dabei auch noch die hunderttausenden Arbeitsstunden in den Wind, die andere Leute in Dinge gesteckt haben, um dir den Einstieg zu vereifnachen. Du wirst schon gut damit beschäftigt sein, auf dem Industrieboard eine LED zum Blinken zu bringen. Du kannst es "anders sehen", aber wie mir scheint fehlt dir die Erfahrung...
:
Bearbeitet durch User
hallo Rene, der Hinweis mit Gyroskop ist interessant . das war mir nicht bewußt. das kann es auch garnicht nicht, weil es nie Thema für mich war. ich denke nicht , daß ich das wissen muß . da ist aber doch sicher auch ein Mittelwert zu errechnen , denke ich. der Hintergrund beim Gyroskop ist die Idee, abhängig vom Profil die eingesetzte Kraft (Ampere) zu steuern, u.U. auch den Speed (Volt) anzupassen. - Steigungen , Ebene .... das ist erst einmal eine Idee . ob sich das so umsetzen läßt, ist vollkommen offen . der STM32 am Motor steuert isoliert den Systemkreis Motor mit der motorinternen sensorik . anfangs war ja tatsächlich ein Arduino in einem Konzept . mit dem angedachten Industrieboard und der Power dachte ich dann, mir den u.U. zu sparen, jetzt nicht an Geldwert, das ist fast nichts, aber an harter Ware.
Alex G. schrieb: > Programmiert wird dann meist übrigens eher in Python als C. Bzw. du > wirst mehr tutorials in Python finden. > Wenn extrem kurze Reaktionszeiten gefragt sind, macht C aber sicherlich > Sinn. Das sehe ich grundsätzlich genauso, möchte aber ergänzen, daß man Python in performance- und timingkritischen Bereichen prima mit C oder C++ erweitern oder andererseits auch einen Python-Interpreter in C- oder C++-Programme einbauen kann. Insbesondere möchte ich hier die Bibliothek Boost::Python erwähnen. [1] https://docs.python.org/2/extending/extending.html [2] https://docs.python.org/3/extending/building.html [3] https://docs.python.org/2/extending/embedding.html [4] https://docs.python.org/3/extending/index.html [5] http://www.boost.org/doc/libs/1_65_1/libs/python/doc/html/index.html
wo fangen eurer ansicht nach denn die zeitkritischen momente an ? 1. fangen diese schon bei der sensorik eines pedalunterstützten systems an ? 2. oder, wenn es in den scooterbereich geht ? 3. was ist dann mit einem rollstuhl ? es geht nicht um die Interna des Motors mit Positionierung etc., weichem anfahren, umschalten von sinus auf quadrat etc. da gibt es einen microcontroller.
alex, ich habe 0 erfahrung in diesem umfeld , keine frage . ich strebe allerdings auch kein Hobbyprojekt an . davon habe ich die nase voll, das sind die frusterlebnisse. immer wieder neu erlebt, wenn ich mir eine neue Forumslösung erarbeitet habe. dabei konzidiere ich dabei partiell meine ehrfurcht vor der expertise . das ergebnis jeweils war für mich selbst aber nie befriedigend . das liegt aber im einzelfall nicht an der qualität , sondern an den anderen kriterien. ich möchte eine investitionssichere innovative perspektive auf der Grundlage anerkannter STANDARDS nach dem Stand der Technik zeichnen . es ist alles bereits erfunden und da ! es muss nur jemand zusammenbringen . ich kann mir sehr sehr gut die Zielprojektion im Blick Übergangslösungen vorstellen . ich kann mir auch sehr gut eine Lösung im Team vorstellen. nicht zuletzt kann ich mir im Erfolgsfall auch eine kommerzielle Lösung vorstellen.
Norbert B. schrieb: > ich habe viele Jahre mit einem UNIX auf einer ALPHA und auch MIPS CPU > gearbeitet . > kennt das heute noch jemand ? Na klaro kennen die Leute heute noch MIPS. Sehr schöne Architektur. Hinter mir werkelt gerade eine solche MIPS-Kiste als Router und auf der läuft natürlich Linux ;) Norbert B. schrieb: > ich habe das mit dem LINUX als Empfehlung hier so schon erwartet. > > ich würde es eigentlich gerne vermeiden , habe zuviel zeit in meinem > Leben verschwendet in meiner aktiven Zeit, allein schon dafür, > irgendwann einmal auch ein bestimmtes Derivat oder eine GUI instaliert > zu haben, um sich einen Eindruck zu verschaffen. > und wenn ich mir heute auf der Raspberry Seite die Anzahl der Derivate > ansehe, kriege ich Luftnot. > und hinter keinem steht die Restlebensdauer . :) Du musst bei Linux zwischen Kernel und Userland unterscheiden. Das was du als Derivat bezeichnest ist das Userland und da würde auch keiner auf die Idee kommen zwischen einem HP-Windows und einem Dell-Windows zu unterscheiden, bloß weil beim einen Sophos und beim anderen Kaspersky vorinstalliert ist, oder? Wenn man etwas Erfahrung mit dem System hat kann man sich sein Userland selber zusammenstellen (weshalb es eben auch so viele unterschiedliche Distributionen gibt). Am Kernel kann man natürlich auch nach eigenen Vorstellungen Änderungen vornehmen, auch wenn das sicher etwas schwieriger ist. Sicher lernt man das nicht von heute auf morgen aber es gibt genug Leute, gerade in Deutschland, die mit solchen Dingen Erfahrung haben. Die Restlebensdauer einer Kernelversion ist meistens schon vor deren Release bekannt. Ausnahmen gibt es wenn überhaupt nur nach oben. Bei Prozessoren, die hauptsächlich in Industrieanwendungen verwendet werden, wie etwa der AM335x-Serie von TI oder der i.MX-Serie von Freescale bekommt man normalerweise eine Verfügbarkeit des Prozessors von mindestens 10 Jahren ab Erscheinungsdatum garantiert und normalerweise gibt es für diese Zeit auch jeweilige Kernelupdates des Herstellers, so dass man immer auf dem neuesten Stand ist. Bei Windows würde ich einen riesengroßen Bogen um irgendwelche IoT-Versionen machen. Was machst du wenn die Hardware auf der du das implementiert hast nicht mehr verfügbar ist und Microsoft keine Versionen für aktuellere Hardware herausgibt? Norbert B. schrieb: > wo fangen eurer ansicht nach denn die zeitkritischen momente an ? Das musst du selber wissen, wie zeitkritisch deine Anwendung ist. Genaueres hast du ja nicht verraten. Nur soviel sei hier mal gesagt: Bei einem normalen PC, egal ob mit Windows oder Linux, kann sich das Betriebssystem immer eine gewisse "Bedenkzeit" genehmigen und die ist erstens vollkommen undeterministisch und zweitens durchaus auch mal etwas länger (>1s). Ob das für deine Anwendung kritisch ist oder nicht, das musst du schon selber wissen. Für Linux gibt es noch Kernel-Patches um das ganze einigermaßen echtzeitfähig zu machen (Preempt-RT) aber allgemein würde ich für zeitkritische Dinge immer auf einen Mikrocontroller zurück greifen.
Norbert B. schrieb: > alex, ich habe 0 erfahrung in diesem umfeld , keine frage . > > ich strebe allerdings auch kein Hobbyprojekt an . > davon habe ich die nase voll, das sind die frusterlebnisse. immer > wieder neu erlebt, wenn ich mir eine neue Forumslösung erarbeitet habe. > dabei konzidiere ich dabei partiell meine ehrfurcht vor der expertise . > das ergebnis jeweils war für mich selbst aber nie befriedigend . > das liegt aber im einzelfall nicht an der qualität , sondern an den > anderen > kriterien. > > > ich möchte eine investitionssichere innovative perspektive auf der > Grundlage anerkannter STANDARDS nach dem Stand der Technik zeichnen . > es ist alles bereits erfunden und da ! > > es muss nur jemand zusammenbringen . > > ich kann mir sehr sehr gut die Zielprojektion im Blick Übergangslösungen > vorstellen . > ich kann mir auch sehr gut eine Lösung im Team vorstellen. > > nicht zuletzt kann ich mir im Erfolgsfall auch eine kommerzielle Lösung > vorstellen. Dann verstehe ich überhaupt nicht wofür du diesen Thread eröffnet hast. Niemand wird dir die fertige Lösung für dein Projekt hier bereitstellen können. Such dir das Team und eigne dir das nötige Wissen an. Wenn du das nicht alleine kannst, bezahle Berater aus der Industrie. Für Umsonst wirst du hauptsächlich vorschläge für Hobby-Projekte finden. Falls du mit Industriestandards das meinst was heutzutage in Autos verbaut wird, dann solltest du wissen dass wohl das allermeiste davon unter Lizenzen steht oder gar komplett prpriätär ist - jeder Autohersteller kocht sein eigenes Süppchen. Christopher J. schrieb: > Das musst du selber wissen, wie zeitkritisch deine Anwendung ist. > Genaueres hast du ja nicht verraten. Nur soviel sei hier mal gesagt: Bei > einem normalen PC, egal ob mit Windows oder Linux, kann sich das > Betriebssystem immer eine gewisse "Bedenkzeit" genehmigen und die ist > erstens vollkommen undeterministisch und zweitens durchaus auch mal > etwas länger (>1s). Ob das für deine Anwendung kritisch ist oder nicht, > das musst du schon selber wissen. Für Linux gibt es noch Kernel-Patches > um das ganze einigermaßen echtzeitfähig zu machen (Preempt-RT) aber > allgemein würde ich für zeitkritische Dinge immer auf einen > Mikrocontroller zurück greifen. Naja, eine Sekudne halte ich für etwas übertrieben! Vergleiche doch nicht ein zugeschnittenes OS auf dem fast nur die Nutzer-Applikation läuft und noch dazu ohne Bildschirmausgabe, mit einem vollständigen PC mit 1000 Hintergrundservices.
:
Bearbeitet durch User
Norbert B. schrieb: > wo fangen eurer ansicht nach denn die zeitkritischen momente an ? Das hängt immer vom konkreten Anwendungsfall ab.
Alex G. schrieb: > Naja, eine Sekudne halte ich für etwas übertrieben! Ähm ja :D habe das "m" vergessen. Soll natürlich >1ms heißen.
Christopher J. schrieb: > Alex G. schrieb: >> Naja, eine Sekudne halte ich für etwas übertrieben! > > Ähm ja :D habe das "m" vergessen. Soll natürlich >1ms heißen. Achso. Der TE hat weiter oben gesagt seine Anforderungen wären nur 1/2s Reaktionszeit. Das ist also prinzipiell Problemlos machbar - das Wissen und Durchhaltevermögen dafür vorausgesetzt.
Norbert B. schrieb: > alex, ich habe 0 erfahrung in diesem umfeld , keine frage . Genau, und das ist das erste Problem. Das zweite Problem ist, daß Deine Herangehensweise vollkommen erratisch ist. Was Du über Deine Idee sagst, ist ausgesprochen nichtssagend. Aber obwohl Du uns nichts über den Anwendungsfall sagen willst, sollen wir Dir Ratschläge geben. Aber wenn Dir jemand Ratschläge gibt -- zum Beispiel ein Raspbian Linux auf einem Raspberry Pi 3 zu benutzen -- erklärst Du, daß Du Dich eigentlich schon für Windows 10 IOT Core entschieden hast, weil Du das aus welchen Gründen auch immer für zukunftssicherer hälst. Warum fragst Du denn noch, wenn Du Deine Entscheidung ohnehin schon getroffen hast? Ohnehin ist es ziemlich unsinnig, sich Gedanken über Hardware und das zu verwendende Betriebssystem zu machen, bevor Du das Anforderungsprofil der Anwendung herausgearbeitet hast. Es ist nämlich ein großer Unterschied, ob Du nur ein paar Wegpunkte Deines LEV erfassen und später bei Google Maps oder Openstreetmap visualisieren willst, oder ob Du die Telemetriedaten Deines Fahrzeuges in Echtzeit erfassen und zur Steuerung des Fahrzeuges benutzen willst. Daß Deine Lösungsstrategie grob unsinnig ist und Du obendrein gereizt auf Kritik reagierst, wird es vermutlich nicht einfacher machen, Mitstreiter für Dein Projekt zu finden. Ich vermute mal, Du willst wahlweise entweder eine Telemetrie oder eine alternative Steuerung für LEVs entwickeln. Ich nehme lange genug an diesem Forum teil, um mittlerweile Dutzende Leute erlebt zu haben, deren Vorkenntnisse, Lösungsstrategien, und Verhalten Deinem geähnelt hat, und bisher hat es keiner von denen geschafft, einer Lösung auch nur einen einzigen Schritt näher zu kommen. Versteh' mich bitte nicht flasch: ich will Dir nichts Böses, sondern Dir lediglich vermitteln, daß der Weg, den Du eingeschlagen hast, mindestens steinig sein wird, wahrscheinlich aber eher ein Holzweg ist. Ich schlage daher vor, wir fangen nochmal von vorne an: Du sagst uns, was Du vorhast, und wir überlegen uns dann, ob wir Dir helfen können und wollen.
Christopher J. schrieb: Toller Beitrag, danke! > Die Restlebensdauer einer Kernelversion ist meistens schon vor deren > Release bekannt. Eigentlich spielt sie aber auch keine sonderlich große Rolle, zumindest, wenn der Kernel in vertrauenswürdigen Umgebungen betrieben wird. Denn im Prinzip stellt der Kernel nur weitgehend standardisierte Schnittstellen bereit -- und solange die sich nicht ändern, was sehr selten geschieht, funktioniert das Vorhandene auch weiterhin. Problematisch wird es in derartigen Fällen erst, wenn man neuere Kernelfeatures benötigt, also beispielsweise Kernelmodule für neue Hardware oder -Subsysteme (think Control Groups oder Namespaces), die der alte Kernel nicht unterstützt. > Nur soviel sei hier mal gesagt: Bei > einem normalen PC, egal ob mit Windows oder Linux, kann sich das > Betriebssystem immer eine gewisse "Bedenkzeit" genehmigen und die ist > erstens vollkommen undeterministisch und zweitens durchaus auch mal > etwas länger (>1s). Ob das für deine Anwendung kritisch ist oder nicht, > das musst du schon selber wissen. Für Linux gibt es noch Kernel-Patches > um das ganze einigermaßen echtzeitfähig zu machen (Preempt-RT) aber > allgemein würde ich für zeitkritische Dinge immer auf einen > Mikrocontroller zurück greifen. An dieser Stelle möchte ich noch darauf hinweisen, daß es wohl die Option gibt, dem Linux-Kernel einen oder mehrere Kerne des Raspi-SOC zu entziehen und darauf Echtzeitanwendungen laufen zu lassen, die dann nicht von dem Scheduler des Systemkernels verwaltet werden und auch nicht von diesem unterbrochen werden können. Hab' ich noch nicht ausprobiert, aber mit ein oder zweimal 1,2 GHz kann man sicher eine Menge Echtzeit abfackeln und auf den anderen Kernen trotzdem ganz normal Linux benutzen.
Sheeva P. schrieb: > An dieser Stelle möchte ich noch darauf hinweisen, daß es wohl die > Option gibt, dem Linux-Kernel einen oder mehrere Kerne des Raspi-SOC zu > entziehen und darauf Echtzeitanwendungen laufen zu lassen, die dann > nicht von dem Scheduler des Systemkernels verwaltet werden und auch > nicht von diesem unterbrochen werden können. Hab' ich noch nicht > ausprobiert, aber mit ein oder zweimal 1,2 GHz kann man sicher eine > Menge Echtzeit abfackeln und auf den anderen Kernen trotzdem ganz normal > Linux benutzen. Richtig, allerdings ist das eher experimentell und fügt nur noch mehr Komplexität hinzu. Ind en Meisten Fällen dürfte es sinnvoller sein einen Arduino oder einen kleinen ARM, dem Android zur Seite zu stellen. Vorteile hat der direkte Ansatz nur wenn man unbedingt viel Speicher braucht.
Sheeva P. schrieb: > An dieser Stelle möchte ich noch darauf hinweisen, daß es wohl die > Option gibt, dem Linux-Kernel einen oder mehrere Kerne des Raspi-SOC zu > entziehen und darauf Echtzeitanwendungen laufen zu lassen, die dann > nicht von dem Scheduler des Systemkernels verwaltet werden und auch > nicht von diesem unterbrochen werden können. Hab' ich noch nicht > ausprobiert, aber mit ein oder zweimal 1,2 GHz kann man sicher eine > Menge Echtzeit abfackeln und auf den anderen Kernen trotzdem ganz normal > Linux benutzen. Hast Du da eine Quelle? Die Umsetzung wuerde mich interessieren.
Alex G. schrieb: > Sheeva P. schrieb: >> An dieser Stelle möchte ich noch darauf hinweisen, daß es wohl die >> Option gibt, dem Linux-Kernel einen oder mehrere Kerne des Raspi-SOC zu >> entziehen und darauf Echtzeitanwendungen laufen zu lassen, die dann >> nicht von dem Scheduler des Systemkernels verwaltet werden > > Richtig, allerdings ist das eher experimentell und fügt nur noch mehr > Komplexität hinzu. Wenn Du das sagst, wird es wohl stimmen. Aber wie gesagt: ich habe das noch nicht ausprobiert und kann wenig dazu sagen, nur, daß in meiner Kerneldoku der Parameter isolcpus= nicht als experimental markiert ist. > Ind en Meisten Fällen dürfte es sinnvoller sein einen Arduino oder einen > kleinen ARM, dem Android zur Seite zu stellen. Das wäre prinzipiell auch einer meiner ersten Ansätze, die anderen wären zuerst nice(1), taskset(1), oder die Realtime-Patches. > Vorteile hat der direkte Ansatz nur wenn man unbedingt viel Speicher > braucht. Hast Du dazu vielleicht einen Link?
Hugo schrieb: > Sheeva P. schrieb: >> An dieser Stelle möchte ich noch darauf hinweisen, daß es wohl die >> Option gibt, dem Linux-Kernel einen oder mehrere Kerne des Raspi-SOC zu >> entziehen und darauf Echtzeitanwendungen laufen zu lassen, die dann >> nicht von dem Scheduler des Systemkernels verwaltet werden und auch >> nicht von diesem unterbrochen werden können. > > Hast Du da eine Quelle? Die Umsetzung wuerde mich interessieren. Um dem Kernelscheduler die Kontrolle über einen CPU-Kern zu entziehen, reicht es, den Bootparameter isolcpus=[n] zu setzen, auf einem RasPi unter Raspbian in /boot/cmdline.txt. Die Dokumentation dazu findest Du unter [1]. Hab ich ausprobiert auf einem Raspbian, der in einem Apache Storm-Cluster läuft: funktioniert anscheinend wunderbar. Nach dem Setzen eines neuen Bootparameters sollte man natürlich rebooten... nur zur Erinnerung. ;-) Danach kann man seinen Prozeß auf der betreffenden CPU laufen lassen, indem man deren CPU-Affinität auf die vom Scheduler nicht verwaltete CPU legt -- mit dem Systembefehl sched_setaffinity(2). Das ist der Teil, den ich noch nicht ausprobiert habe. Ansonsten ist mir noch nicht ganz klar, wie man Interrupts von einer isolierten CPU fernhalten kann oder ob man das muß. Ich weiß auch noch nicht, ob ich das tatsächlich lieber nutzen will als taskset(1), Realtime-Patches oder vielleicht sogar das schnöde, traditionelle nice(1). Nebenbei bemerkt finde ich in den letzten Monaten immer wieder neue und ausgesprochen interessante Features im Linux-Kernel. Klar, Control Groups und Namespaces sind bekannt, seit sie von Containerlösungen (ähnlich wie weiland unsere Solaris Zones) benutzt werden. Aber APIs wie inotify (see incrond(8)), auditd(8) oder die TPM-Werkzeuge? Sehr kewl! [1] /usr/src/linux/Documentation/cgroups/cpusets.txt
:
Bearbeitet durch User
Sheeva P. schrieb: > Hast Du dazu vielleicht einen Link? Hmpf, es gab einen sehr schönen blog in 4 oder 5 Teilen wo jemand das realisiert und relativ brauchbar dokumentiert hatte. Hab vorhin mehrfach versuch es wieder zu finden, aber leider erfolglos :( Dumemrweise keinen bookmark angelegt. Das wurde mal hier im Forum verlinkt. In einem thread über Realtime OS auf dem Raspi. Von dem Blog hab ich auch auch die Aussage dass es experimentell wirkt. Auf jeden Fall gibt es keine Anleitung von der Raspberry Foundation zum Thema oder so.
so, jetzt sind wir doch genau dort, wo ich hin wollte, was mir wertvolle erkenntnisse bringt und falsche entscheidungen bei der festlegung der Plattform verhindern helfen kann. das war der Sinn meines Threads . die details interessieren mich dabei nicht . kann ich festhalten, daß es auf OS-Ebene möglich ist, 1 oder 2 Kerne einer 4 oder 8kern CPU beim Start zu parken und dann später über einen Laufzeitprozeß gezielt anzusteuern ? habe ich das so richtig verstanden ? kurz nur , ich meine, es war alex mit den Vergleichen zu Dell und HP etc. , auf diesem Beitrag werde ich später noch eingehen. da ist offensichtlich einiges fehlgelaufen in der Einschätzung. ich möchte diese Diskussionsentwicklung hier nicht bremsen. ich möchte 2 oder 3 Events in die Diskussion einstellen, die von dem System abgearbeitet werden müssen. da ist zum einen der Neigungssensor . ------------------------------------- es ist dabei nach meinem Verständnis vollkommen egal, wieviel Werte dieser Sensor in der Sekunde oder Minute liefert. es darf niemals in direkter Folge auf einen solchen Wert reagiert werden. es wird i.d.R. über einen Algorithmus , z.b. eine Tendenz dieser Werte reagiert, das kann u.U. sogar über einen Lerneffekt erfolgen. es ist also eher eine Aufgabenstellung des OS basierten Systems. Echtzeit ist da eher kein Thema. jetzt aber zum Bremsevent oder zur Notbeschleunigung . ---------------------------------------------------------- das sind m.E. die zeitkritischen Events, auf die in Echtzeit oder annähernd Echtzeit reagiert werden muss. die Bremsverzögerung wird bei einem solchen System nicht primär über eine mechanische Reibung erzielt. Die Verzögerung wird über eine Funktionsumkehr des Motors in einen Generator bei gleichzeitiger Rückgewinnung -Rekuperation- von energie erzielt. die 1. Aktion ist mit dem Auslösen der Bremse die unmittelbare Unterbrechung der Stromzufuhr. danach kommen eine Vielzahl von Schaltvorgängen und Entscheidungen abhängig vom jeweiligen Aggregatzustand (Restgeschwindigkeit etc.) , Stromlauf, step down oder step up Spannungswandlung, um auf die jeweilige Batterienennspannung zu adaptieren. schwieriger wird das noch bei der im Rahmen der aktuell erarbeiteten festgelegten LEV Standards neuen Batteriegeneration . in China ist heute schon ein 36V Controller seltener geworden. was früher 24V/36V/48V war , ist heute 48V/60V/72V . da geht man auch gerne noch höher, wenn 1Kw oder 2Kw Motoren angesteuert werden. das verhindert u.a. immer dickere Kabel trotz Leistungssteigerung . die LEV Standards sehen einen neuen Batterietyp vor, den man Cube nennt . hier unterscheidet sich die Abgabespannung von der physikalischen Spannung der Zellen oder des Zellverbunds. das kann am Ende dann in der Theorie auch heissen, eine Batterie für alles. die Anpassung an die notwendige Versorgungsspannung ist im System Batterie implementiert. es ist also eine ganze Menge zu regeln - in Echtzeit - . kriegt man das möglicherweise immer noch hin mit den 1 oder 2 geparkten CPU Kernen ? was meint ihr ?
machmal sieht man die einfachen Lösungen nicht unmittelbar, weil man einfach zu kompliziert denkt. das Kappen der Stromzufuhr läßt sich unmittelbar unabhängig von welcher Intelligenz immer auch auf ganz simple klassische weise realisieren. und damit ist das zeitkritischste Moment herausgenommen . oder ?
Norbert B. schrieb: > ich bin weder Bastler noch Elektroniker noch C-Programmierer. Wenn ich das richtig lese, willst Du eine Elektrofahrzeug basteln. Dann sollte der Satz eigentlich lauten: "Ich bin ein begeisterter Bastler und Mechaniker und Elektroniker und Programmierer." Ansonsten ist Frust vorprogrammiert. Ob man für ein Elektrofahrzeug einen 1- oder 8-Kerner braucht, halte ich in diesem Projektstadium für vollkommen nebensächlich. Das Projekt muß eh noch wachsen, d.h. kein einziger Teil der Hardware wird entgültig sein.
Norbert B. schrieb: > kann ich festhalten, daß es auf OS-Ebene möglich ist, 1 oder 2 Kerne > einer 4 oder 8kern CPU beim Start zu parken und dann später über einen > Laufzeitprozeß gezielt anzusteuern ? > > habe ich das so richtig verstanden ? Falls du es verstanden haben solltest, dann drückst du dich zumindest komisch aus. Aber ja, es gibt mindestens ein Betriebssystem (Linux) das auf mindestens einer Plattform (Raspberry Pi) ein solches Vorgehen ermöglicht. Es ist also möglich. Inwieweit dir das hilft, steht auf einem ganz anderen Blatt. Insbesondere angesichts deiner Linux-Phobie. [Geschwurbel gesnipt] > es ist also eine ganze Menge zu regeln - in Echtzeit - . > > kriegt man das möglicherweise immer noch hin mit den 1 oder 2 geparkten > CPU Kernen ? Die meisten dieser Regelkreise können (und sollten sogar) unabhängig und autark ausgelegt werden. Damit sind sie prädestiniert dafür, auf einem µC implementiert zu werden. Der µC kann ja trotzdem noch über einen Feldbus (z.B. CAN) mit einer Zentrale reden, z.B. um parametriert zu werden oder um Störungen zu melden. Ganz allgemein sehe ich hier keinen Bedarf für ein Betriebssystem, zumindest bei klassischer Auslegung des Begriffs.
guten morgen, peter, das siehst du aber vollkommen falsch . ich möchte eine offene Systemarchitektur für ein ELV auf der Grundlage anerkannter technologischer Standards um hier auch auf einen beitrag einzugehen - propietär und standard und ein widerspruch in sich - entwickeln, ein pflichtenheft über stufenweise im Zuge der Realisierung einzusetzende Verfahren und verwendete Plattformen unter Einbeziehung aktuell stattfindender Forschung schreiben . und da wo es um Key Verfahrensansätze geht, im Modell auch selbst oder mit fremder Expertise testen . kannst du es dir als bastler vorstellen, daß jemand das system zu ende denken will, bevor der lötkolben heissläuft ? kannst du dir vorstellen, daß es menschen gibt, die sich intellektuell mit einer Sache auseinandersetzen, weil a) der Markt aus wirtschaftlichen Interessen kein für ihn akzeptables Angebot im preislich fairen Rahmen anbietet . b) er sich der bewußt anbietererzeugten Abhängigkeit nicht ausliefern will c) er nicht für auch verfügbare anspruchsvolle Lösungen einen den Materialwert um ein Vielfaches übersteigenden Preis zahlen will . und d) bei aller Anerkenntnis und Hochachtung für die jeweils in Foren präsentierten Lösungen und die Expertise der Protagonisten - ich ziehe oft genug meinen Hut- hier es sich häufig genug konzeptionell um brotlose Kunst handelt . eine Konzeption , das ist aber auch nicht die Ausrichtung solcher Foren. also gebastelt wird nur da wo zwingend notwendig . ich bin übrigens Betriebswirt ohne Löterfahrung und jetzt schreibe bitte nicht, daß es anmaßend ist, sich mit einer solchen Thematik auseinanderzusetzen.
lieber Peda, vielleicht kannst du aber auch mit einer konstruktiven Ansage zur Diskussion beitragen, z.b. mit einem substantiellen Beitrag zu den gezielt anzusteuernden parkenden CPU Kernen ? das bringt den thread nach vorne .
Irrelevant. Jede Empfehlung. >der Hintergrund beim Gyroskop ist die Idee, abhängig vom Profil die >eingesetzte Kraft (Ampere) zu steuern, u.U. auch den Speed (Volt) >anzupassen. - Steigungen , Ebene .... >das ist erst einmal eine Idee . ob sich das so umsetzen läßt, ist >vollkommen offen . Bevor es hier ausartet, mein gut gemeinter Rat an den TO. Versuche bitte Dein Vorhaben mit Äpfeln und Birnen zu erklären. Ich möchte bauen dass das und das macht. Es ist müssig über Kernel oder Gyros zu diskutieren bei Deinem technischen Fachwissen.
Norbert B. schrieb: > kannst du es dir als bastler vorstellen, daß jemand das system zu ende > denken will, bevor der lötkolben heissläuft ? Ja, kann ich. Aber trotzdem fängst Du am falschen Ende an, nämlich beim Betriebssystem. Erst kommt die Definition des Soll-Konzeptes, dann die Frage: womit kann ich das umsetzen? Und gaaaaanz hinten die Frage: Ist ein nicht-echtzeitfähiges Betriebssystem wie Windows sinnvoll? Und dann die Antwort, wenn man sich die Aufgaben näher anschaut: Nein, ist es nicht. Wäre es sinnvoll, gäbe es schon Millionen Autos mit Windows als Steuersystem. Gibt es aber nicht - aus gutem Grund. Übrigens ist solch eine Vorstellung echt gruselig. Du willst Standards? Windows ist in der Automotive Industrie kein Standard. Deine Überlegungen zu mehreren CPU-Kernen sind nicht zielführend. Egal, wieviel Kerne Du benutzt, wirst Du damit niemals die Nicht-Echtzeitfähigkeit eines Betriebssystems umgehen können. Ich stelle mir gerade eine Seifenkiste mit einem E-Motor vor, dahinter ein ganzes Rechenzentrum, welches von der Seifenkiste gezogen werden soll... Also fang nochmal ganz vorne an: Was soll die Kiste können?
:
Bearbeitet durch Moderator
Norbert B. schrieb: > die entscheidende , aber auch schwierigste Frage ist im Augenblick, die > richtige Plattform für die Realisierung zu wählen. Auch (oder gerade) ein Betriebswirt sollte wissen, dass vor dem Pflichtenheft das Lastenheft existieren muss. Oder anders gesagt: die Lösung entsteht aus dem Problem, nicht anders herum. Solange Du dein Problem nicht formulieren kannst (ich habe da bislang nichts Verwertbares gefunden), wird hier ausser Rumgelaber nichts substantielles kommen (können).
hallo frank, lassen wir doch einfach die diskussion zu LINUX/Windows 10 IOT . ich habe es in der Überschrift auf gleicher Ebene behandelt . es war dann falsch , dazu weitere ausführungen zu machen. ich hätte das ergebnis kennen müssen . es ist für meine Frage absolut schnurz ob das eine oder das andere . dazu gehört auch , was wo in welchem Bereich standard ist . ich werde das nicht weiter kommentieren, es ist nicht zielführend. es ist vollkommen klar, daß, daß ich im vorne ein OS basiertes System brauche. aber auch das muß hier nicht diskutiert werden. es geht mir allein darum, daß, wenn ich in der Verfügbarkeit und zukünftigen Verfügbarkeit der Hardware, der Kontinuität der Entwicklung von OS und Entwicklungsplattform und auf eine breite leistungsfähige CPU Palette setzen will, bleibt die 40 JAHRE alte Ehe von intel und microsoft. das das ist , nenne es eine strategische oder auch politische Entscheidung . es würde gewichtiger Argumente bedürfen, davon in einem neueren Erkenntnisstadium abzuweichen. ich schließe es aber nicht im Grundsatz aus. der zunächst angedachte RASPI fügt sich hier nicht nahtlos ein. die Hardware Ressourcen sind sehr eingeschränkt, ich möchte z.b. nur ungerne mein system auf einer Sd Karte vorhalten. da MS aber nur die 2 BCM Plattformen direkt supported , bin ich hier wieder abhängig von der Produktpolitik von RAspberry. ich mag keine Abhängigkeiten. es gibt dann den Allwinner 64 chipsatz, von BANANA und ORANGE angeboten u.a. mit 2GB RAM und eMMC, der mein "politisches" OS im Prinzip kann . dumm ist nur, daß beide Hersteller auf der Grundlage des aktuellen Builds kein image zur Verfügung stellen können. ich habe beide Hersteller kontaktiert . alle anderen ALLWINNER SOCs oder sonstigen kompatiblen fucken nicht . und an dieser Stelle der Erkenntnis bin ich zum Industrieboard gestoßen, weil MS die Ünterstützung aller ATOM CPUs zusichert. gibt es ab knapp 70€ mit einem Z3735F auf einem PICO ITX . das kostet ein dragonboard 410C bei viel weniger an Leistung auch. und dieses mehr an Leistung hat mich auf die Idee gebracht, auf den ursprünglich im Verbund vorgesehen ARDUINO u.U. zu verzichten. nach dem Stand der Diskussion werde ich mir wohl beide Möglichkeiten vorbehalten. ich muss nur schauen, wie sich das auf die konstruktion des shield boards auswirkt , das ich auf den Arduino setzen wollte . wie würde ich das dann intelligent an das PICO ITX industrieboard direkt adaptieren ?
Hatten wir derartige Diskussionen nicht schon gefühlt 100 mal?
lieber markus, rumgelaber , ja . so habe ich deinen beitrag empfunden . ich habe präzise die Bremsproblematik angeführt . im sinne der Überschrift : geht das nur mit einem mikrocontroller in echtzeit oder auch mit einem leistungsfähigen OS basierten Industrieboard auf Basis einer 4-stelligen ATOM CPU ? die problematik ist doch präzise oder wie willst du sie präziser bekommen ? kannst du etwas beitragen zu den beim systemstart geparkten CPU Kernen ?
mein lieber Philip, merke dir , deine angebliche technische Expertise sei dahingestellt . du hast sie dann, wenn du in der Lage bist, einen komplexen technischen Zusammenhang einem durchschnittlich intelligentem Menschen in 3 Sätzen zu erklären in der Lage bist. kannst du das nicht , hast du selbst nicht wirklich verstanden !!!
Norbert B. schrieb: > kannst du etwas beitragen zu den beim systemstart geparkten CPU Kernen ? Du weißt schon, dass dies eine eher fortgeschrittene Angelegenheit ist, und du scheinbar keine Erfahrungen von hardwarenaher Programmierung hast, meinst du nicht selbst das dies ein bisschen viel für den Anfang ist?
Norbert B. schrieb: > lassen wir doch einfach die diskussion zu LINUX/Windows 10 IOT . Wie kommst Du auf das schmale Brett, dass wenn ich sage, dass ein Windows-Steuerrechner in einem Auto gruselig wäre, ich automatisch Linux präferiere? Auch das ist nicht echtzeitfähig! > es ist vollkommen klar, daß, daß ich im vorne ein OS basiertes System > brauche. Das ist Unsinn. Du hast noch nichtmals die Anforderungen formuliert und fängst ganz am Ende an. Willst Du mal dazu etwas sagen?!? Frage: "Ich will mein Wohnzimmer neu anstreichen. Ich will dafür einen Feuerwehr-Schlauch nehmen, die Gartenspritze taugt nichts. Wie mache ich das?" Die richtige Antwort ist: "Weder noch." Fazit: Du hast überhaupt nicht die Kompetenz, die richtige Plattform für Dein Vorhaben auszusuchen. Formuliere die Anforderung, nicht eine absurde Lösung, die für die Tonne ist!
Norbert B. schrieb: > ich habe präzise die Bremsproblematik angeführt . Das einzige was ich dazu von dir gelesen habe war das hier: Norbert B. schrieb: > jetzt aber zum Bremsevent oder zur Notbeschleunigung . > ---------------------------------------------------------- > das sind m.E. die zeitkritischen Events, auf die in Echtzeit oder > annähernd Echtzeit reagiert werden muss. > > die Bremsverzögerung wird bei einem solchen System nicht primär über > eine mechanische Reibung erzielt. > Die Verzögerung wird über eine Funktionsumkehr des Motors in einen > Generator bei gleichzeitiger Rückgewinnung -Rekuperation- von energie > erzielt. > > die 1. Aktion ist mit dem Auslösen der Bremse die unmittelbare > Unterbrechung der Stromzufuhr. und in Kombination mit Norbert B. schrieb: > machmal sieht man die einfachen Lösungen nicht unmittelbar, weil man > einfach zu kompliziert denkt. > > das Kappen der Stromzufuhr läßt sich unmittelbar unabhängig von welcher > Intelligenz immer auch auf ganz simple klassische weise realisieren. frage ich mich was du mit diesen verklausulierten Sätzen eigentlich sagen wolltest. Keine Ahnung was du dir vorstellst. Willst du beim bremsen einfach einen Schalter umlegen, der den Stromkreis unterbricht? Wie willst du dann rekuperieren? Was genau willst du überhaupt bremsen? Du sprichst in Rätseln... Vor Augen habe ich im Moment nur die sehr blumige Beschreibung von Frank :D > Ich stelle mir gerade eine Seifenkiste mit einem E-Motor vor, dahinter > ein ganzes Rechenzentrum, welches von der Seifenkiste gezogen werden > soll...
lieber Frank, ich kann das sehr gut aus der Nutzer Akzeptanz beurteilen . und das ist die Perspektive die zählt !! ich will ein GUI Frontend, das ist eine sine qua non bedingung . ich habe auf dem Arduino die Ansteuerung eines LCDs erlebt. das will ich mir nicht antun. ich möchte mir auf den Monitor des Systems Zusatzapplikationen, z.b. Standard Apps, die unter dem OS verfügbar sind, rufen. das kann z.B. die Navigation sein , aber durchaus auch einen messenger dienst. daß die Vorgabe vom Kunden kommt, das versteht der Bastler eher selten.
Norbert B. schrieb: > ich möchte eine offene Systemarchitektur für ein ELV auf der Grundlage > anerkannter technologischer Standards ... > entwickeln, ein pflichtenheft über stufenweise im Zuge der Realisierung > einzusetzende Verfahren und verwendete Plattformen unter Einbeziehung > aktuell stattfindender Forschung schreiben . > und da wo es um Key Verfahrensansätze geht, im Modell auch selbst oder > mit fremder Expertise testen . LOL Schade, ganz knapp am BINGO vorbei. Dabei fe lte nur noch ein einziges Buzzword. Ich biete "Blockchain"!
Axel S. schrieb: > Norbert B. schrieb: >> ich möchte eine offene Systemarchitektur für ein ELV auf der Grundlage >> anerkannter technologischer Standards > ... > >> entwickeln, ein pflichtenheft über stufenweise im Zuge der Realisierung >> einzusetzende Verfahren und verwendete Plattformen unter Einbeziehung >> aktuell stattfindender Forschung schreiben . >> und da wo es um Key Verfahrensansätze geht, im Modell auch selbst oder >> mit fremder Expertise testen . > > LOL > > Schade, ganz knapp am BINGO vorbei. Dabei fe lte nur noch ein einziges > Buzzword. Ich biete "Blockchain"! IoT
Norbert B. schrieb: > ich kenne mich einigermaßen aus mit Es wäre besser, wenn Du - statt über Deine Kompetenz zu reden - diese hier durch eine ausreichend umfassende aber prägnante und klare Präsentation Deines Problems beweisen würdest. Es ist ja nun bereits mehrfach gesagt worden, dass wesentliche Informationen fehlen und dass Deine Vorstellungen vor diesem Hintergrund etwas "von hinten aufgezäumt" wirken. Wollen die Leute Dich alle ärgern? Oder versuchen sie vielleicht tatsächlich angestrengt und vergeblich sich aus Deinen dünnen Informationen ein Bild zu basteln? Hab' doch keine Angst davor, mehr Informationen zu geben - niemand wird Dir Deine tolle Idee klauen. Bestimmt nicht. Schau mal hier: Forum-Fragenformulierung Dazu gehört auch, dass man den Mitlesern das Lesen erleichtert, indem man sich an irgendeine alte oder neue Rechtschreibung mit Groß-/Kleinschreibung hält und Plenken vermeidet. Norbert B. schrieb: > welche sensoren ß > das sind speed sensoren, kraftsensoren, kontaktsensoren, GPS sensorik , > evtl auch gyroskop , höhenmeter Was sollen die in welchem Zeitschema messen und innerhalb welcher Zeit soll darauf welche Reaktion erfolgen? Welche Funktionen soll das User Interface haben? Norbert B. schrieb: > es gibt wahrscheinlich in deinem berufsleben auch jemanden, der dir die > aufgaben zuteilt Bei manchen mag das im Berufsleben so sein. Hier im Forum jedoch nicht. Vor allem bist Du nicht derjenige, der hier Aufgaben zuteilt. Du hast nämlich eine Frage und bittest um Antwort.
hallo christopher, ich will bremsen, indem ich einen Bremshebel betätige oder ein Fußpedal trete. in dem einen wie dem anderen gibt ein Sensor die Info weiter . die Vorgabe ist, die Maßnahme muß unmittelbar vom System umgesetzt werden . das muß als Vorgabe reichen !!! es ist doch ganz einfach . die notwendigen Einzelaktionen habe ich angerissen, die kann sich aber jeder selbst erschließen. das ist doch kein Atomkraftwerk ! die entscheidende frage ist, kriege ich diesen zeitkritischen Vorgang nur mit einem Mikrocontroller, der die Aktion auslöst, hin oder kann das auch auf welche Weise immer auf einem wie auch immer nicht Echtzeit OS basiertem System fucken ? z.b. über diese Mimik der geparkten CPU Kerne . oder auch ganz ohne Trickserei ? wenn jemand damit nichts anfangen kann oder will (!) , dann sollte er sich aus diesem Thread besser verabschieden .
Norbert B. schrieb: > das muß als Vorgabe reichen !!! Es ist aber nicht Deine Sache zu definieren, was als Information für eine vernünftige Antwort ausreichend ist. Das ist Sache der Antwortenden. Und wenn die Informationen brauchen, die Du nicht geliefert hast, dann musst Du eben nachliefern.
Norbert B. schrieb: > es ist doch ganz einfach . die notwendigen Einzelaktionen habe ich > angerissen, die kann sich aber jeder selbst erschließen. > das ist doch kein Atomkraftwerk ! > > die entscheidende frage ist, kriege ich diesen zeitkritischen Vorgang > nur mit einem Mikrocontroller, der die Aktion auslöst, hin oder kann das > auch auf welche Weise immer auf einem wie auch immer nicht Echtzeit OS > basiertem System fucken ? > > z.b. über diese Mimik der geparkten CPU Kerne . oder auch ganz ohne > Trickserei ? > > wenn jemand damit nichts anfangen kann oder will (!) , dann sollte er > sich aus diesem Thread besser verabschieden . Glaub mir und den meisten anderen hier wenn sie dir sagen ein (einfacher) Mikrocontroller ist einfacher als ein x86 Prozessor mit Echtzeitbetriebssystem, vor allem wenn du dies eigentlich nicht bräuchtest, den so ein Betriebssystem ist eine zusätzliche Komplexitätsstufe in deinem System und auch Fehleranfällig. Um dir aber zu sagen, ob dies notwendig ist, braucht man entsprechende Info, sonst ist das eher stochern im Nebel. Was du allerdings hier schreibst wäre mit einer CPU für Grafik und einem Controller für Steuerung und Messung wahrscheinlich ausreichend. (Übrigens ist Windows kein Echtzeitbetriebssystem, im Automotiv nutzt man dann eher so etwas wie QNX)
Norbert B. schrieb: > die Vorgabe ist, die Maßnahme muß unmittelbar vom System umgesetzt > werden welche Maßnahme denn? Bremsen? Rekuperieren? Welches System??? > das muß als Vorgabe reichen !!! Nein, das reicht eben nicht!
Norbert B. schrieb: > mein lieber Philip, > > merke dir , > > deine angebliche technische Expertise sei dahingestellt . > > du hast sie dann, wenn du in der Lage bist, einen komplexen technischen > Zusammenhang einem durchschnittlich intelligentem Menschen in 3 Sätzen > zu erklären in der Lage bist. > > kannst du das nicht , hast du selbst nicht wirklich verstanden !!! Du hast überhaupt gar nichts verstanden Norbert. Auch die Empfehlung anderer hast Du sanft überlesen. Norbert B. schrieb: > ich habe präzise die Bremsproblematik angeführt . > > im sinne der Überschrift : > > geht das nur mit einem mikrocontroller in echtzeit oder auch mit einem > leistungsfähigen OS basierten Industrieboard auf Basis einer 4-stelligen > ATOM CPU ? WAS? GEHT WAS? WAS DENN? WAS BITTE? Automatisiert ein Fahrzeug negativ beschleunigen, welches obendrein noch eine Zulassung der europäischen Wirtschaftskommission, dem Tuev, der Stvo, und hunderten anderen Instanzen braucht? Dein Vorhaben geht ein bisschen weiter als Luftfiltertuning, welches ich noch immer nicht kenne. Ich denke Du willst sowas bauen, nur selbstfahrend: https://de.wikipedia.org/wiki/Renault_Twizy Und jetzt machst Du Dir Gedanken, ob das OS strategisch ist? echt jetzt? Oder ob der CPU 16 oder 32Mhz braucht? Daher noch mal mein gut gemeinter Rat an einem praktischen betriebswirtschaftlichen (Wortspiel) Beispiel: Du baust ein Haus. Sanitär, Strom, alles da. Jetzt brauchst Du noch eine Heizung. Gut. Frage: Gehst Du jetzt www.bau-mein-haus-forum.de und fragst: Guten Tag, ich möchte für mein neues Haus eine Heizung installieren. Soll ich eine Gasheizung, eine elektrische Heizung, eine Ölheizung oder eine Pellet Heizung nehmen? Oder gehst Du in ein microcontroller Forum und fragst: Guten Tag. ich möchte für mein neues Haus eine Heizung installieren. Ist das mit einer Siemens SPS möglich oder brauche ich einen CAN Bus. Der Bus soll strategisch sein, weil früher hatte ich Probleme mit der Fehlerkorrektur am 37igst Frame gleich nach dem Startbit.
Norbert B. schrieb: > die Vorgabe ist, die Maßnahme muß unmittelbar vom System umgesetzt > werden . umdiesefragezubeantwortenmussdaswort"unmittelbar"näherdefiniertwerden! Wahrscheinlich wird es aber auf einen Mikrocontroller hinauslaufen.... Bei "Bremse" fallen mir aber auch noch andere Dinge, wie z.B. Ausfallsicherheit etc., ein! Norbert B. schrieb: > z.b. über diese Mimik der geparkten CPU Kerne . oder auch ganz ohne > Trickserei ? Oha, deine präferierten Betriebssysteme können das? ...oder willst du gar ein eigenes schreiben? Norbert B. schrieb: > oder kann das > auch auf welche Weise immer auf einem wie auch immer nicht Echtzeit OS > basiertem System fucken ? Liest du dir eigentlich mal deine Sätze durch, nachdem du sie in die Tastatur gehämmert hast?
Norbert B. schrieb: > ich möchte mir auf den Monitor des Systems Zusatzapplikationen, z.b. > Standard Apps, die unter dem OS verfügbar sind, rufen. > das kann z.B. die Navigation sein , aber durchaus auch einen messenger > dienst. Du möchtest ein einfach zu bedienendes Monitoring-System haben - mit einer GUI. Norbert B. schrieb: > ich will bremsen, indem ich einen Bremshebel betätige oder ein Fußpedal > trete. > in dem einen wie dem anderen gibt ein Sensor die Info weiter . > > die Vorgabe ist, die Maßnahme muß unmittelbar vom System umgesetzt > werden . Hier möchtest Du ein Steuersystem haben, das "unmittelbar" reagiert. Lösung: - Für die GUI nimmste Dein Windows, ist ja nur zum Spielen, also Radio, Navi usw. - Für Dein Steuersystem nimmst Du etwas echtzeitfähiges, also ein MikroController-System. Beide Systeme kann man durch aus koppeln, zum Beispiel zum Übertragen von Meßwerten an Dein GUI-System. Alles andere macht keinen Sinn.
Norbert B. schrieb: > ich will bremsen, indem ich einen Bremshebel betätige oder ein Fußpedal > trete. das Problem ist doch längst gelöst: das heisst (je nach Umsetzung) "Bremszug", "Bremsleitung" oder "Bremsgestänge". Wenn Du's unbedingt moderner haben möchtest: auch die elektrische Bremse im Pkw gibt's längst. Dort hat sie aber - entgegen deiner Anforderung - einen Grund (die ABS-Steuerung). Wenn man den nicht hat, wär's blöd, ohne Not einen zusätzlichen SPOF einzubauen. Wie Du siehst, ist es gar nicht so einfach, ein klares und verständliches PRD zu erstellen.
Nette Diskussion ;) Ich versuche es mit einer High-Level Antwort... Meine Empfehlung: Microcontroller: Für alle Aufgaben die zeit- oder sicherheitsrelevant sind und die in einem relativ engen Rahmen definiert sind. Diese Systeme machen die Arbeit. Mit großer Wahrscheinlichkeit gibt es davon mehrere mit unterschiedlichen Einzelaufgaben. Minicomputer: Ein System im Hintergrund, dass mit den verschiedensten Nebenaufgaben betraut wird und dessen Aufgaben auch deutlich wachsen können. Solche Systeme stellen Webserver bereit, halten Datenbanken und tun Dinge auf die man teilweise auch verzichten könnte. Man beachte: Diese Computer müssen (zeitintensiv) booten und benötigen einen Manager der die einzelnen Aufgaben am laufen hält. Des weiteren haben Sie einen größeren Wartungsaufwand, da Sie mehr Dynamik und mehr Einzelkomponenten (HW und SW) enthalten. Mir ist klar, das diese Definitionen nicht vollständig sind und es jede Menge Gegenbeispiele gibt. Sie veranschaulichen aber ganz gut mit welchem Ziel ich was einsetzen würde. //JJ
Markus F. schrieb: > > das Problem ist doch längst gelöst: das heisst (je nach Umsetzung) > "Bremszug", "Bremsleitung" oder "Bremsgestänge". > > Wenn Du's unbedingt moderner haben möchtest: auch die elektrische Bremse > im Pkw gibt's längst. Dort hat sie aber - entgegen deiner Anforderung - > einen Grund (die ABS-Steuerung). Wenn man den nicht hat, wär's blöd, > ohne Not einen zusätzlichen SPOF einzubauen. Drive by Wire hat MB wieder 'ausgeführt'. Kleine Anekdote hierzu, damit der Thread nicht ganz verschwendete Lebenszeit wird. Wenn Du bei den alten MB mit drive-by-wire Systemen versehentlich während einem Bremsscheibenwechsel die Türe öffnest, haut es die Bremskolben raus. Um das zu umgehen brauchst deren Software. >> ich will bremsen, indem ich einen Bremshebel betätige oder ein Fußpedal >> trete. In meinen Auto kann ich das mit dem mittleren Pedal. Auch mit der Handbremse. Du möchtest einen elektronische Lösung mit einem uc? Eine CO2 Druckgasflasche über ein Magnetventil mit dem Hauptbremszylinder verbinden. Magnetventil über Arduino ansteuern. if (speed >= 200) { DoBrake } Problem solved. kann zu.
Ganz großes Kino der Thread. Sieht aus als würde das Forum auf einen wildgewordenen (fast) deutschsprachigen Klon von SCIgen o.ä. einprügeln. So wird das jedenfalls nix. Wenn ich unbedingt ein Schachturnier gewinnen will denke ich auch nicht drüber nach ob Holz- oder Plastikfiguren die bessere Haptik haben, sondern lerne zuerst mal Schachspielen.
Norbert B. schrieb: > lieber markus, > rumgelaber , ja . so habe ich deinen beitrag empfunden . > > ich habe präzise die Bremsproblematik angeführt . > > im sinne der Überschrift : > > geht das nur mit einem mikrocontroller in echtzeit oder auch mit einem > leistungsfähigen OS basierten Industrieboard auf Basis einer 4-stelligen > ATOM CPU ? Echtzeit: Grob vereinfacht: Antwort des Systems garantiert innerhalb einer festgelegten Zeit. Bremsen sind sicherheitskritisch. Mal in die ISO 26262 schauen... und es reicht nicht nur Software oder Hardware für sich alleine zu betrachten. Kurzfassung, auch wenn ich nicht in dem Bereich arbeite: Weder Linux, noch Windows, noch irgendwelche Standard-Atom-Boards, Arduinos etc. erfüllen auch nur ansatzweise die dortigen Anforderungen.
Markus F. schrieb: > Norbert B. schrieb: >> ich will bremsen, indem ich einen Bremshebel betätige oder ein Fußpedal >> trete. > > das Problem ist doch längst gelöst: das heisst (je nach Umsetzung) > "Bremszug", "Bremsleitung" oder "Bremsgestänge". Das war auch mein erster Gedanke. Mit den Infos die bisher vom TO kamen könnte ich mir ein E-Bike vorstellen, was an seinem Bremshebel einen Sensor montiert hat. Wird dieser betätigt wird die "Maßnahme", d.h. der Bremsvorgang direkt umgesetzt (rein mechanisch). Wenn der Sensor betätigt wird, misst ein Beschleunigungssensor die Bremsverzögerung und ein Win10-IoT Board auf dem Gepäckträger nimmt diesen Wert um ihn direkt bei Twitter zu posten. Auf einem 24" Touchscreen, welcher auf dem Lenker montiert ist wird dieser Wert ebenfalls angezeigt. Außerdem kann man damit natürlich auch noch Angry Birds spielen oder sich etwa den neuesten Klatsch und Tratsch bei Facebook anschauen. Frank M. schrieb: > Lösung: > > - Für die GUI nimmste Dein Windows, ist ja nur zum Spielen, > also Radio, Navi usw. > > - Für Dein Steuersystem nimmst Du etwas echtzeitfähiges, also > ein MikroController-System. > > Beide Systeme kann man durch aus koppeln, zum Beispiel zum Übertragen > von Meßwerten an Dein GUI-System. > > Alles andere macht keinen Sinn. Das wäre in der Tat sehr sinnvoll. Im Prinzip setzt das ja auch jeder so um, vom Staubsaugerroboter bis zum Tesla.
1 | Abstand-Sensor an Windows: "Das wird eng!" |
2 | Bremse an Windows: "Soll ich bremsen?" |
3 | Windows an Abstand-Sensor: "Wie eng?" |
4 | Abstand-Sensor an Windows: "VERDAMMT ENG!" |
5 | Windows an Rad-Sensor: "Wie schnell sind wir denn?" |
6 | Rad-Sensor an Windows: "20 Radumdrehungen pro Sekunde!" |
7 | Bremse an Windows: "Soll ich bremsen?" |
8 | Windows an Taschenrechner: "Rechne mir das mal in km/h um!" |
9 | Taschenrechner an Windows: "180km/h!" |
10 | Windows an Abstand-Sensor: "Wie eng war es nochmal?" |
11 | Bremse an Windows: "Ich kann bremsen, sag was!" |
12 | Abstand-Sensor an Windows: "NOCH ENGER! Tu was, aber SCHNELL!!!" |
13 | Windows an Temperatur-Sensor: "Wie kalt ist es? Glatteis-Gefahr?" |
14 | Temperatur-Sensor an Windows: "-7 Grad! |
15 | Bremse an Windows: "Flöööööööt.... soll ich jetzt bremsen?!?" |
16 | Windows an Feuchte-Sensor: "Ist die Straße naß?" |
17 | Feuchte-Sensor an Windows: "Nee, die ist eisig!" |
18 | Windows an GPS: "Verdammt, sind wir soweit im Norden?" |
19 | GPS an Windows: "Süd-Bayern, reicht Dir das?" |
20 | Windows an ABS: "Wenn wir jetzt bremsen, bringt das was?" |
21 | Bremse an Windows: "Windows! Sprich mit mir!" |
22 | ABS an Windows: "Kannste vergessen, Reifen werden blockieren!" |
23 | |
24 | Windows an alle: |
25 | |
26 | "Okay, dann mache ich jetzt erstmal was anderes ...." |
27 | "Installing Update 1705, please wait..." |
28 | |
29 | Alle an Windows: "AAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH!!!" |
nacheinander jetzt zu marian : es ist mir wurscht, wie komplex ein x86 gegenüber einem mikrocontroller ist . ich kenne bis jetzt nur einen X86 . ich komme immer vom ergebnis ! nicht das was am einfachsten ist, ist eine gute Lösung, sondern das, was eine hohe UserAkzeptanz hat . und da hilft auch dein grafikcontroller oder was nicht . oder gibt es darauf auch standard apps ? an Axel: unqualififiziertes Geschwätz . hast du u.U. einen Beitrag zu den geparkten CPU Kernen zu leisten ? an np: das respektiere ich . ich wollte ja auch hier mit Entwikclern reden, die entsprechende Erfahrungen und Expertise haben. wer neben meinen Infos da noch mehr input für eine Antwort braucht, ist eher der klassische Typ Batchprogrammierer, der eine Listenvorgabe mit Angabe der TAB Positionen bekommt und die dann abarbeitet. an Christopher die gleiche antwort. ich habe das Bremsen nicht als eine Einzelaktion vorgestellt , sondern als einen komlexen Prozeß . dazu gehört natürlich auch die rekuperation nach dem Umschalten zum Generator , der eigentlichen Bremsfunktion. die frage eines Systems stellt sich nicht, weil der Prozeß immer vergleichbar ist. a Philip ich gebe auf . wer mir mit TÜV und EU kommt, während ich eine technische Alternative hinterfrage ............. vergessen wir es . es wir mir zu anstrengend , auf alle wahnsinnig zielführenden Antworten zu reagieren . -------------- dafür, daß ich einen Beitrag aufgenommen habe und ihn gerne weiter recherchieren würde, weil ich ihn im sinne der Überschrift als zielführend angesehen habe, erhalte ich jetzt den Vorwurf, ein neues Betriebssystem erfinden zu wollen . an die lieben Herren Entwickler , ihr seid mir alle zu schlau . ihr wißt zuviel über EU , Wirschaftskommisonen, STvo und STVZO und TÜV und .... wenn man das alles wissen muss, um eine Plattformentscheidung zwischen einer ATOM CPU und einem Mikrocontroller treffen will , dann geht mir das entschieden zu weit . da bekomme ich Kopfschmerzen . ich würde mich allerdings freuen, wenn der schreiber des beitrags über den geparkten CPU Kern , sollte er etwas finden, sich noch einmal meldet.
@ukw Sehr amüsant, aber setze das Desktop Windows nicht mit Windows iOT gleich :) Ansonsten trifft die obige Aussage zu - Das OS wird eingezetzt wo kein sofortiges Handeln erforderlich ist. Btw. dachte eigentlich der TE wollte an nichts rumbasteln was auf der Strasse sicherheitskritisch wird.. und jetzt soll das System Bremsen kontrolieren?! EDIT: Norbert will offensichtlich nur unsere Zeit verschwenden und wird höchstwahrscheinlich das Projekt nicht mal in Angriff nehmen.
:
Bearbeitet durch User
Vielleicht noch mal ganz ruhig, es gibt genügend Gründe die warum hier dir mehr oder weniger alle, diese Variante empfohlen haben. Da ist es egal ob du vom Kunden her denkst oder nicht, entwickeln tut sich das System mit Windows nicht alleine, und eine Anwendung (App) willst du nicht auf einem System das sicherheitskritisch ist haben!
Norbert B. schrieb: > hallo, > ich bin weder Bastler noch Elektroniker noch C-Programmierer. > > d.h. ich habe in diesem Umfeld 0 Erfahrungswerte . > und dennoch erlaube ich mir , eine Idee zu haben , und die würde ich > auch gerne umsetzen. https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt
Norbert B. schrieb: > den geparkten CPU Kern , sollte er etwas finden, sich noch einmal > meldet. seitwärts oder rückwärts?
Ich kann mir auch einen Linienbus kaufen, um 600 Meter um die Ecke Brötchen zu kaufen. Andere gehen zu Fuß oder nehmen ein Fahrrad. Beides funktioniert. Unter Umständen (wenn z.B. Parkplätze knapp sind), ist das Fahrrad nicht nur einfacher und billiger, sondern auch besser. So ist das auch mit den Computern. Ein großer Computer funktioniert anders und hat andere Ansprüche an seine Betriebsumgebung und Wartung. Das sollte man berücksichtigen. Niemand käme auf die Idee, eine Wanduhr mit Windows zu betreiben. Bei einer Universal-Fernbedienung wäre das schon eher denkbar. Bei Spielkonsolen und Smartphones ist es längst Realität.
Der Poster hat den Unterschied zwischen mit und ohne Beriebssytem noch nicht ganz gerafft. Mit Betriebssytem bedeutet : Wir verbessern die Software laufend. Im idealfalls fuer t gegen unendlich laeuft's dann auch, vielleicht. Ohne Betriebssystem, als Embedded System : Die Software muss fehlerfrei sein, ohne Verhandeln. Und das schafft man auch. Allerdings ohne Schnick-Schnack. Also irgendwelche Visualisierung ist ausserhalb des Prozesscontrollers, angebunden per zustandsloser Kommunikation. Irgendwelche Ansaetze mit mehreren Kernen sind dann schon advanced.
:
Bearbeitet durch User
Spätestens wenn USB und/oder Netzwerk Kommunikation Bestandteil des Projektes ist, kann der Einsatz eine Betriebssystems hilfreich sein. Muss aber nicht zwingend so sein, denn es gibt ja auch spezielle Chips für diese Kommunikationsschnittstellen, wie die üblichen USB-UART's und die kleinen Ethernet Controller (von Wiznet, sowie ESP8266, ESP32, CP2201, EN28J60).
Ich hab jetzt nicht alles durchgelesen, aber ich wollte einfach mal das Stichwort "Kosten" in den Raum werden. Wenn du es später verkaufen willst, macht es schon einen Unterschied ob der Mikrocontroller auf deiner Platine 50c kostet (zB 8-Bit PIC) oder dein Raspberry noch angeschlossen wird (Stecker/Kabel, Raspberry -> 25€). Ich behaupte: Für alles, außer Kameraverarbeitung/Multimedia/Großer Bildschirm, reicht ein Mikrocontroller. Geschwindigkeiten gibts ja mittlerweile alles von 100 kHz bis 200 MHz.
Norbert B. schrieb: > an die lieben Herren Entwickler , ihr seid mir alle zu schlau . > > ihr wißt zuviel über EU , Wirschaftskommisonen, STvo und STVZO und TÜV > und .... > wenn man das alles wissen muss, um eine Plattformentscheidung zwischen > einer ATOM CPU und einem Mikrocontroller treffen will , dann geht mir > das entschieden zu weit . > da bekomme ich Kopfschmerzen . Nochmal: Sicherheitskritische Systeme - und das sind Bremsen und entsprechende Kontrollsysteme - müssen nicht einfach so zum Spaß gewisse Anforderungen erfüllen. > ich würde mich allerdings freuen, wenn der schreiber des beitrags über > den geparkten CPU Kern , sollte er etwas finden, sich noch einmal > meldet. Völlig unerheblich, ob und wie das geht: "Einfach" mal überlegen was bspw. bei einer elektronischen Feststellbremse schiefgehen kann und was die Folgen des Fehlers sind und dann überlegen, wie das System aufgebaut sein müsste... Gibt's da auch was fertiges mit Intel: Z.T. ja, https://www.intel.com/content/www/us/en/automotive/go-automated-driving.html Intel Atom (ASIL C oder zwei Prozessor-Lösung ASIL D) kombiniert mit Infineon Aurix (ASIL D). https://newsroom.intel.com/newsroom/wp-content/uploads/sites/11/2017/01/intel-go-product-brief.pdf Nvidia geht in eine ähnliche Richtung: https://www.nvidia.com/en-us/self-driving-cars/drive-px/
Beitrag #5333196 wurde vom Autor gelöscht.
Norbert B. schrieb: > ihr wißt zuviel über EU , Wirschaftskommisonen, STvo und STVZO und TÜV > und .... > wenn man das alles wissen muss, um eine Plattformentscheidung zwischen > einer ATOM CPU und einem Mikrocontroller treffen will , dann geht mir > das entschieden zu weit . > da bekomme ich Kopfschmerzen . Zur Plattformentscheidung schreibt niemand was weil das für ein nebulös skizziertes Elektrofahrzeug komplett wurscht ist, vor allem wenns nur in niedrigen Stückzahlen gebaut wird. Wenn das halbwegs vernünftig programmiert wird ist das auch im nu auf eine andere Hardware portiert. > ich würde mich allerdings freuen, wenn der schreiber des beitrags über > den geparkten CPU Kern , sollte er etwas finden, sich noch einmal > meldet. Das ist ja doch auch vollkommen wurscht. Wayne(tm) interessierts wie man einen CPU-Kern von einem BCM2835 schlafen legt und aufweckt, das macht das Betriebssystem, und wenn mans wirklich wissen will, use the force, read the (linux kernel) source. Was man aber schon genau wissen sollte sind dinge wie "wie schnell muss das bremspedal reagieren wenn man es betätigt, und wie weit fährt das fahrzeug in der zeit". wenn man mal weiss was man da braucht kann man sich gedanken machen wie man das technisch umsetzt. Zuerst die technische Umsetzung festlegen und dem dann die Aufgabenstellung anpassen macht man eventuell noch in Nordkorea (notgedrungen).
rµ schrieb: > Was man aber schon genau wissen sollte sind dinge wie "wie schnell muss > das bremspedal reagieren wenn man es betätigt, und wie weit fährt das > fahrzeug in der zeit". wenn man mal weiss was man da braucht kann man > sich gedanken machen wie man das technisch umsetzt + mit welcher Kraft muss das Pedal betätigt werden + wieviel Hub + in welcher Zeit + + + + @TO: Lies mal über PID Regler, evtl. hilft das ja. Regelung, nicht Steuerung.
Es ist nützlich, bei einem Projekt zunächst einmal die Anforderungen zu beschreiben. Und zwar, weil sich aus diesen Anforderungen weitere nützliche Informationen ergeben. Ein, wie ich meine guter, Ansatzpunkt wäre der Artikel https://de.wikipedia.org/wiki/Lastenheft Es ist weiter nützlich, von einer Idee ausgehend, zunächst nicht in die Implementierungsdetails zu gehen. Es ist bei etwas komplexeren Vorrichtungen fast immer so, dass die Anforderungen voneinander abhängen und sich sogar gegenseitig widersprechen - in den meisten Fällen quantitativ. Es muss also oft ein Kompromiss gefunden werden - schon auf der Anforderungsebene. Es ist ebenso so, dass die Gesamtmenge an Anforderungen ein wesentlich zuverlässigeres Bild davon geben, was das System leisten muss, als einzelne Punkte. Du hast nun im Gegensatz dazu, Gedanken zu einzelnen Details und fragst danach. Insofern muss man Dich um Verständnis dafür bitten, dass man diesen Ansatz entweder grundsätzlich verwirft oder Dir Probleme mit diesen Details aufzeigt, die letztlich auf Annahmen über plausible Anforderungen an ein solches Projekt beruhen. Es ist letztlich so, dass hier relativ viele Leute sind, die auch Erfahrungen mit grösseren, komplexeren Projekten haben. Es wäre sinnvoll, wenn Du diese Erfahrungen für Dein Vorhaben nutzt.
Niine schrieb: > Ich hab jetzt nicht alles durchgelesen, aber ich wollte einfach mal das > Stichwort "Kosten" in den Raum werden. Das hat unsere vermeintliche BWL-Führungskraft* ja schon deutlich klar gemacht, dass ihm die Kosten wichtig sind: Norbert B. schrieb: > c) er nicht für auch verfügbare anspruchsvolle Lösungen einen den > Materialwert um ein Vielfaches übersteigenden Preis zahlen will . Leider hat der gute Mann hier wohl übersehen (bzw. vergessen), dass der Preis eines Produkts sich nicht nur aus den Materialkosten zusammensetzt, sondern dass auch jemand das Ding produzieren, verpacken und im Einzelhandel vertreiben muss - nachdem es entwickelt und validiert wurde, die Einhaltung aller relevanten Normen und Gesetze sichergestellt und das Benutzerhandbuch etc. geschrieben wurde. Und zu guter Letzt erlaubt sich der Gesetzgeber - eine Steuer auf Produkte für Endverbraucher aufzuschlagen - und die gaaanz bösen Hersteller erlauben es sich dann tatsächlich auch noch, für ihre Arbeit eine Gewinnmarge einzukalkulieren ;-) Aber zurück zum Thema: @TO: Wie hier schon mehrfach angemerkt wurde, fehlen entscheidende Informationen - das sind zumeist noch nicht einmal konkrete Zahlenwerte à la Strom, Spannung, Zeit - sondern tatsächlich eher Informationen aus "Nutzersicht". So wurde bisher mehr oder weniger beiläufig beschrieben, dass es um den "Zentralrechner" eines LEVs geht, der u. a. auch die Bremsfunktion sowie ein Rekuperieren regeln soll. Wie hier allerdings nun schon mehrfach beschrieben wurde, hat der Gesetzgeber (aus m. M. n. gutem Grund) hohe Anforderungen an elektronisch geregelte/bremsbare Gefährte gestellt - ich jedenfalls würde ungern von einem Fahrzeug überfahren werden, das nicht bremsen kann, weil das Betriebssystem abgestürzt ist o. ä. Daher jetzt zum wiederholten Male die Empfehlung, zunächst die konkreten Anforderungen an das System in Form eines Lastenhefts zusammenzustellen, bevor man überhaupt erste Gedanken an den/die CPUs verschwendet (kaum ein auch nur halbwegs modernes Gefährt kommt mir nur einer CPU aus - aus gutem Grunde, wie ich finde). Das sind nicht nur Anforderungen aus unmittelbarer Nutzersicht (Das Gefährt muss x km/h schnell fahren können, in y Sekunden von 0 auf z km/h beschleunigen können, maximal x kg transportieren können; das Gefährt braucht einen Tacho und eine Batterie-Ladezustandsanzeige sowie einen zentral integrierten Touchscreen mit installierbaren Apps für Navi und "Musik" etc.), sondern auch Umwelt-Randbedingungen (Temperatur-/Klimabereich, Lebensdauer) sowie gesetzliche Anforderungen (Straßenzulassung muss möglich sein, Einsatz in welchen Ländern möglich, geeignet zur Personenbeförderung oder nur für Waren usw.). Diese Anforderungen detaillierst Du dann so weit wie möglich, so dass dann im Pflichtenheft z. B. stehen kann: "Bei Betätigung des Bremspedals soll die Bremswirkung spätestens nach 100ms einsetzen und das Fahrzeug in jedem Betriebsfall bei voller Bremsung eine maximale Beschleunigung von mindestens -1m/s² aufweisen" (Zahlen aus der Luft gegriffen und auf die Schnelle hingerotzt; Definitionen fehlen natürlich auch noch - nur, um eine Idee zu geben) - oder auch "als zentrales Bedienteil soll ein Tablet mit Windows/Android/whatever verwendet werden können, das mit dem Hauptrechner mittels USB 3.0/Bluetooth 4.0/whatever kommuniziert" (Ebenfalls noch deutlich weiter auszudetaillieren; z. B. unterstützte Dienste, Wechselwirkungen usw.). Und genau für dieses Detaillieren suchst Du Dir dann Expertenhilfe - oder stellst uns konkrete Fragen, die die entsprechenden Randbedingungen beinhalten. *) Belege dazu aus: Norbert B. schrieb: > ich habe einleitend gesagt, daß ich weder löte noch programmiere. > es gibt auch ganz andere projekte, die man mit nem rechner anstoßen > kann. > > es gibt wahrscheinlich in deinem berufsleben auch jemanden, der dir die > aufgaben zuteilt , dazu muß er nicht selbst löten können. und Norbert B. schrieb: > ich bin übrigens Betriebswirt ohne Löterfahrung
Meine Empfehlung wäre ein kleiner AVR oder PIC zur Vorverarbeitung (Mittelwert berechnen, digitalisieren...) an jedem kritischen Sensor, die dann alle an etwas größeres, wie z.B. einen STM32, angeschlossen sind, der sich um Auswertung und UI kümmert. Keine sonderlich elegante Lösung, und auch nicht die billigste, aber relativ einfach zu bauen. Ein Betriebssystem braucht man grundsätzlich nur, wenn echtes Multitasking wichtig ist. Das, was du wahrscheinlich unter "Betriebssysten" verstehst, braucht man z.B. dann, wenn sehr komplizierte mathematische Aufgaben schnell gelöst werden müssen, während der Benutzer am PC herumdaddelt, denn so etwas bekommt man nur mit Assembler/hardwarenahmen C nicht so schnell gelöst. Für so etwas wie Bremsen musst du wohl wen anders fragen, da bist du hier im falschen Forum.
:
Bearbeitet durch User
Norbert B. schrieb: > ich bin übrigens Betriebswirt ohne DAS ist nun jedem klar. Damit sind tiefergreifende technische Diskussionen sinnlos. asdfghjklö
asdfghjklö schrieb: > Norbert B. schrieb: >> ich bin übrigens Betriebswirt ohne > > DAS ist nun jedem klar. DAS war auch schon bevor er es schrieb jedem klar (ergibt sich aus seiner Ausdrucksweise und Diskussionsführung/-führungsversuch). asdfghjklö schrieb: > Damit sind tiefergreifende technische Diskussionen sinnlos. Er will ja nicht tiefgreifen.
Als Betriebswirt bist Du es vermutlich gewohnt, von Technikern und Entwicklern relativ abstrakte Zusammenfassungen zu erhalten. Das ist zum einen der notwendigen Kürze geschuldet. Zum anderen aber, wird von Betriebswirten auch nicht verlangt, dass sie Detailinformationen beurteilen können. Details sind also in solchen Dokumenten eher spärlich vorhanden und beschränken sich meist auf die Nennung von Prozessoren, Betriebssystemen und allenfalls einer relativ abstrakten Begründung für deren Wahl. Nun, da Du ein eigenes Projekt aufziehen willst, ist es wichtig, dass Du den Standpunkt und die Sichtweise änderst, falls Du darauf bestehst Dich um technische Details zu kümmern. Du scheinst anzunehmen, dass Du im Sinne einer Art "Mittelweg" von Standpunkt des Betriebswirtes, - und mit dem für diesen Beruf typischen Kenntnissen -, aus, die Detailfragen angehen kannst. So, wenn Du zwar einerseits nach etwa der Aktivierung von Kernen fragst, aber andererseits Detailfragen ausdrücklich von Deiner Fragestellung ausklammern willst. Dieser Ansatz ist nicht erfolgversprechend, denn es gibt keine Betriebswirtschaftliche Sicht (abgesehen von der Frage nach dem Preis) der Aktivierung von Kernen oder der Funktion von Regelkreisen, die Dir gestatten würde, daraus Entwicklungsschritte, Systemarchitektur oder Implementierungsdetails abzuleiten.
Norbert B. > - propietär und standard und > ein widerspruch in sich - .... > ich bin übrigens Betriebswirt... „...Das Adjektiv proprietär bedeutet in Eigentum befindlich (von lateinisch propriē „eigentümlich“, „eigen“, „ausschließlich“). Es wird in Bezug auf Soft- und Hardware, die auf herstellerspezifischen, nicht veröffentlichten Standards basiert, verwendet, um diese zu freier Software und freier Hardware abzugrenzen...“
Es macht keinen Sinn einem Kaufmichel, der wie der blinde von der Farbe spricht vernünftig zu entgegnen. Das geht nicht, Ihr wisst das doch!
WWobei ich inzwischend avon ausgehe dass es sich absichtlich doof stellt und darum auf keine der erwähnten Kritiken reagiert.
Norbert B. schrieb: > wenn man das alles wissen muss, um eine Plattformentscheidung [...] > da bekomme ich Kopfschmerzen . Naja, deshalb bist Du ja auch nicht Ingenieur geworden. Ist ja nicht schlimm. Du kannst hier ja auch Antworten bekommen, ohne dass Du das alles weißt. Allerdings solltest Du wenigstens wissen, was Du eigentlich vor hast, und auf Fragen antworten können. Am besten mit den nachgefragten Informationen. Norbert B. schrieb: > das respektiere ich . [...] > wer neben meinen Infos da noch mehr input für eine Antwort braucht, ist eher ... Aha - wieder geplenkt, wieder unleserlich, wieder keine einzige Antwort auf irgendeine der Fragen. Statt dessen persönliche Angriffe. Was oder wen genau "respektierst" Du da? Wenn Du Deinem Spiegelbild mit ebenso viel Respekt begegnest, überlebst Du Deine morgendliche Rasur nicht.
Axel S. schrieb: > Aber ja, es gibt mindestens ein Betriebssystem (Linux) das > auf mindestens einer Plattform (Raspberry Pi) ein solches Vorgehen > ermöglicht. Gerade auf einem Intel NUC5i3 unter Ubuntu 17.10 ausprobiert: dort scheint das ebenfalls zu funktionieren. Den Teil mit sched_setaffinity(2) habe ich allerdings auch dort noch nicht getestet.
Beate schrieb: > Es macht keinen Sinn einem Kaufmichel, der wie der blinde von der Farbe > spricht vernünftig zu entgegnen. > Das geht nicht, Ihr wisst das doch! :) ...ist aber unser täglich Brot. (Dann aber gegen Bezahlung und nicht hier im Forum.)
Norbert B. schrieb: > ich komme immer vom ergebnis ! Dann erklär doch bitte einmal strukturiert, in möglichst einfachen Sätzen, aber gleichermaßen ausführlich und detailliert, wie Dein Ergebnis am Ende genau aussehen soll. > wenn man das alles wissen muss, um eine Plattformentscheidung zwischen > einer ATOM CPU und einem Mikrocontroller treffen will , dann geht mir > das entschieden zu weit . Eine Plattformentscheidung hängt jedoch im Wesentlichen davon ab, was die Plattform am Ende tun soll. Genau das haben Dir jetzt gefühlt zehn Leute mehrfach und mal mehr, mal weniger freundlich gesagt, aber aus irgendeinem Grund kannst oder willst Du nicht darauf eingehen. Aussagen wie: "wenn der Bremshebel betätigt wird, soll das System bremsen" sind da nicht hilfreich und jedenfalls auch nicht die Art von Information, die da gefragt ist. Also, bitte, wenn das hier noch irgendwas Konstruktives geben soll, setz' Dich mal in Ruhe hin, erkläre, welche Komponenten Dein System haben soll (Antrieb, Lenkung, Bremse, Sensoren, Telemetrie, Bedienelemente), welche Anwendungsfälle existieren sowie welche der genannten Komponenten diese Anwendungsfälle jeweils im Einzelnen betreffen. Erst das wird mit etwas Glück so etwas wie eine Gesprächsgrundlage ergeben, ansonsten wird dieser Thread nur ein anschauliches Beispiel dafür bleiben, warum Betriebswirte und Techniker so oft aneinander vorbei reden. > ich würde mich allerdings freuen, wenn der schreiber des beitrags über > den geparkten CPU Kern , sollte er etwas finden, sich noch einmal > meldet. Der Trick mit den isolierten CPU-Kernen funktioniert so nur unter Linux, ebenso auch der Systembefehl sched_setaffinity(2). Da Du Dich aber "strategisch" für Windows entschieden hast, mit dem ich mich nicht auskenne und, ehrlich gesagt, auch nicht auskennen will, wirst Du wohl selbst recherchieren müssen, ob es entsprechende Möglichkeiten für Windows gibt und wie sie genutzt werden können. Angesichts der Tatsache, daß Du auch sicherheitsrelevante Dinge damit steuern und regeln willst, stellen sich bei einer solchen Lösung allerdings noch weitere Fragen, zum Beispiel, ob der Prozess auf Deiner isolierten CPU auch dann weiterläuft, wenn das Betriebssystem abstürzt oder aus irgendeinem Grund rebootet. Ansonsten bleibt, was hier schon verschiedene Leute gesagt haben: die sicherheits- und zeitkritischen Aufgaben gehören auf Mikrocontroller, im Idealfall sogar mindestens zwei, besser noch dreifach redundant ausgelegt, und nur der im Zweifelsfall verzichtbare Spielkram wie die Anzeige und das Konfigurationsmenü können auf einem Multitasking-Betriebssystem ausgeführt werden. Wenn Du ein offenes, idealerweise sogar standardisiertes Protokoll zum Datenaustausch zwischen Mikrocontrollern und Betriebssystem definierst, dann spielt es am Ende sogar gar keine Rolle, ob die unkritischen Teile mit Linux, Windows, RiscOS oder Plan9 ausgeführt werden. Also bitte, Norbert, setz' Dich jetzt bitte einmal in Ruhe hin und mach' Deine Hausaufgaben, und zwar bitte so vollständig wie Du nur kannst. Erst dann können wir Techniker uns hinsetzen und die unseren machen. Edit: Tippfehler korrigiert
:
Bearbeitet durch User
M.A. S. schrieb: > :) > > ...ist aber unser täglich Brot. (Dann aber gegen Bezahlung und nicht > hier im Forum.) Genau und die Jungs vergolden die Lösung, stopfen sich die Tasche mit Kohle voll, ernten die Anerkennung und wir werden mit ein paar € abgespeist, dürfen uns aber auf Ärger gefasst machen, wenn das Produkt dann doch nicht so funktioniert wie der der Kaufmichel es bewusst lügend verspricht. Hier gibt es von mir nicht das schwarze unter dem Fingernagel für die Vögel. Daer Witz beschreibt die Situation sehr gut: Ein Mann in einem Heissluftballon hat sich verirrt. Er geht tiefer und sichtet einen Mann am Boden. Er sinkt noch weiter ab und ruft: - "Entschuldigung, können Sie mir helfen? Ich habe einem Freund versprochen, ihn vor einer Stunde zu treffen und ich weiss nicht, wo ich bin." Der Mann am Boden antwortet: - "Sie sind in einem Heissluftballon in ungefähr 10m Höhe über dem Boden. Sie befinden sich zwischen 40 und 41 Grad nördlicher Breite und zwischen 59 und 60 Grad westlicher Länge." "Sie müssen Ingenieur sein", sagt der Ballonfahrer. "Bin ich", antwortet dieser, "woher wussten Sie das?" "Nun," sagt der Ballonfahrer, "alles was Sie mir sagten, ist technisch korrekt, aber ich habe keine Ahnung, was ich mit Ihren Informationen anfangen soll, und ich weiss immer noch nicht, wo ich bin. Offen gesagt waren Sie keine große Hilfe. Sie haben höchstens meine Reise noch weiter verzögert." Der Ingenieur antwortet: "Sie müssen im Management tätig sein." "Ja," antwortet der Ballonfahrer, "aber woher wussten Sie das?" "Nun," sagt der Ingenieur, "Sie wissen weder wo Sie sind, noch wohin Sie fahren. Sie sind aufgrund einer großen Menge heisser Luft in Ihre jetzige Position gekommen. Sie haben ein Versprechen gemacht, von dem Sie keine Ahnung haben, wie Sie es einhalten können und erwarten von den Leuten unter Ihnen, dass sie Ihre Probleme lösen. Tatsache ist, dass Sie in exakt der gleichen Lage sind wie vor unserem Treffen, aber jetzt bin irgendwie ich schuld!" Passt doch wie die Faust aufs Auge!!!
Der TO wird sich hier vermutlich sowieso nicht mehr melden. Er hat hier nicht das hören können, was er hören wollte und damit ist für ihn die Sache erledigt - zumindest in diesem Forum. Vermutlich hängt er jetzt in einem anderen Forum, wo er sich für ihn "bequemere" Antworten erhofft. Heuschreckenprinzip halt.
liebe freunde , falsch gedacht , so schnell macht er sich nicht vom acker . :) es bleibt doch noch, hier einen abschluss zu setzen. es ist eigentlich schade, ich habe in der vergangeheit als stiller leser einen eher anderen und eher positiven eindruck dieses forums gehabt. ca. 40% bis 50% der beiträge ohne jeden beitrag in der sache persönlich diffamierend. das nennt man heute shitstorm. jeder der sonst offensichtlich eher nichts zu sagen hat, hat die gelegenheit genutzt sich zu beteiligen. sogar die frauenwelt -beate- hat hier "produktiv" mitgewirkt. das motto " ich habe auch etwas zu sagen !" in ca. 20% aller beiträge offensichtlich, weil mit dem thema überfordert, der versuch, auf ein anderes themenfeld einzuschwenken. weitere ca. 20% der beiträge zeichnen mit einer mixtur aus dem vorgenannten, im besonderen euer moderator, dessen beiträge dermassen unqualifiert und dumm sind, daß er u.a. mit seinen assozierten beispielen die reaktionszeit einer bremsung angehend, die meßlatte von 100 beim IQ-Test mit leichtigkeit nach unten gerissen hätte . irgendwie hat er einmal das Wort ABS aufgeschnappt, nur an dieser stelle wars nun wirklich deplaziert. dem rest von 10% bis 20% der schreiber, die sachliche und qualifierte beiträge eingebracht haben, verspreche ich, diese nacheinander abzuarbeiten. ich bedanke mich jetzt schon bei diesen teilnehmern. so, und jetzt frei schuss für den nächsten shitstorm .
Da hier nichts mehr zur Sache kommt, mache ich hier mal zu.
Thread beobachten
Seitenaufteilung abschalten