Ich arbeite freiberuflich als embedded SW-Entwickler bei einer Firma, die mechanische Sachen herstellt und ein Patent hat (Stellglieder für Ventile, Kamera-Objektive, ...), aber mit SW wenig am Hut hat. Manchmal wollen deren Kunden ein Komplett-System, da holen sie mich und ich schreibe ihnen die SW für das Steuergerät. Nun haben sie von einer bekannter US-Firma eine Anfrage bekommen: Stellglieder für Michelson interferometer (Spiegel-Position), aber auch die angeschlossene Kamera (OV9281) soll ausgelesen werden und Bilder verarbeitet. Das ganze auf einem sehr leistungsfähigen embedded Linux System. Die Rechen-Power ist da, aber es gibt noch keine Installation (Bootloader + Kernel), gar nichts. Die wollen mich engagieren, damit ich das in ein 1/4 Jahr erledige. Von Embedded Linux habe ich etwas Ahnung, von Video/Kamera gar nichts. Ich habe gesagt, "Finger weg und aufs Kerngeschäft konzentrieren. Video ist eine Welt für sich. Und (Embedded) Linux auch." Wie verhält man sich da? 1) Probieren und scheitern und Geld versenken. 2) Gleich sagen, "not my department", und absagen.
3) So ein hohes angebot abgeben, dass du davon auch einen bezahlen kannst das zu tun was du nicht kannst, und hoffen dass du den zuschlag nicht kriegst.
Lasten-/pflichtenheft anfordern und daran abschätzen ob es machbar ist. Wenn du noch nie etwas in Richtung bildverarbeitung gemacht hast lass es...
TestX schrieb: > Lasten-/pflichtenheft anfordern und daran abschätzen ob es machbar ist. > Wenn du noch nie etwas in Richtung bildverarbeitung gemacht hast lass > es... Schuster bleib bei deinen Sohlen. Nebenbei darf sich der Schuster natürlich auch weiterbilden. Aber wenn ich erst noch das Schnüren lernen muss, dann werde ich nicht der Kundschaft die Schuhe zubinden.
Die Bildverarbeitung selber ist nicht das Thema.
Die low-level Anbindung der Kamera, und bereitstellung der Bilder.
("bining" und "windowing" war angedacht, aber dann weggelassen.)
1/4 Jahr ist sehr kurz, da ist keine Zeit sich noch groß einzuarbeiten.
Guten Morgen Erst das: >TestX schrieb: > Lasten-/pflichtenheft anfordern und daran abschätzen ob es machbar ist. > Wenn du noch nie etwas in Richtung bildverarbeitung gemacht hast lass > es... und wenn die Hefte Vorliegen, dann das: > 3) So ein hohes angebot abgeben, dass du davon auch einen bezahlen > kannst das zu tun was du nicht kannst, und hoffen dass du den zuschlag > nicht kriegst. Mfg aus dem Rhein-Ruhr
Moin, auch mit der vollen Ahnung sind 3 Mannmonate für so einen Umfang zu knapp bemessen. Passiert mir auch immer wieder. Der dritte Weg wäre, wie schon oben genannt, den Kunden auf eine "Requirement specification" zu drängen, und, wenn sie das nicht können/wollen, artig darauf hinzuweisen dass es komplexer ist als sie denken, und Du ihnen erst mal mit Consulting auf Stundenbasis beiseite stehst.
4) Den Kunden auf einen vermutlich deutlich höheren Aufwand hinweisen und die Beauftragung im Rahmen eines reinen Dienstvertrags durchsetzen. Bei Beauftragung in die Thematik einarbeiten und viel lernen.
TestX schrieb: > Lasten-/pflichtenheft anfordern Das Lastenheft wird durch den Auftraggeber erstellt und das Pflichtenheft darauf basierend durch den Auftragnehmer. Leider wird der zweite Schritt oft übersprungen. Das kann man tun, sollte aber genau wissen, welches die Folgen sein können, insbesondere in Bezug auf die spätere Abnahme des Liefergegenstandes.
Gleich zwei Baustellen auf einmal von denen du keinen blassen Dunst hast: Kamerasensor und embedded Linux und dafür ein 1/4 Jahr? Vergiss es. Ich habe mich auch schon in Projekte gestürzt von denen ich keine Ahnung hatte, da verschätzt man sich immer weil einfach die Erfahrung fehlt, das Fiasko ist vorprogrammiert.
Hi, wie Dunno schon schrieb, Du musst die sogenannte "Inverse Sizilianische Strategie" anwenden : Mache de Kunde eine Angebote, die err Ablehne musse !!! Gruß
Vorsicht: wenn er verzweifelt genug ist, dann nimmt der Kunde auch solche Angebote an (selbst erlebt). Für eine Firma kann das ein Jackpot sein, für eine Einzelperson aber äußerst riskant, wenn man keine Unterstützung in der Hinterhand hat.
:
Bearbeitet durch User
Freiberufler schrieb: > Das ganze auf einem sehr leistungsfähigen embedded Linux System. Die > Rechen-Power ist da, aber es gibt noch keine Installation (Bootloader + > Kernel), gar nichts. So eine Embedded-Linux-Geschichte ist extrem komplex und ein riesiger Aufwand. Wenn das eine bekannte Plattform ist (Raspberry PI oder Beaglebone o.ä.) kann man da auf was bestehendem ansetzen, aber wenn man bei 0 anfangen muss ist das ein Fass ohne Boden... Das fängt schon an alle Treiber für alle Peripherie aufzutreiben, die per DTS zu konfigurieren, den Bootloader U-Boot anzupassen (möglicherweise proprietäres RAM & Flash-Interface), ggf. Treiber reverse engineeren weil natürlich nichts dokumentiert ist und nur die billigsten China-Komponenten verbaut wurden, usw usf. Mit den kleinsten Detailproblemen kann man sich Wochen beschäftigen. Das ganze ist eigentlich keine Embedded-Entwicklung, sondern Linux-System-Bastelei. "Normale" Embedded-Kenntnisse helfen dabei auch kaum. Die meisten (Groß-)Baustellen und Probleme wird man erst später überhaupt finden; man kann kaum einen Projektplan aufstellen und von A-Z durchgehen, selbst wenn ein perfektes Pflichtenheft vorliegt. Es ist eine Menge Forschung und Einarbeitung angesagt. Das sind vermutlich mehrere Mannjahre Arbeit für einen erfahrenen Linux-Entwickler, stark abhängig davon wie viel Vorarbeit schon geleistet wurde. Einfach mal Linux auf so ein System packen ist ein Wunschtraum - das ist ja sogar bei PCs manchmal eine Odyssee... Ggf. kann es sogar einfacher sein, das komplett ohne Linux "bare metal" zu machen. Das setzt natürlich voraus, das alle Peripherie dokumentiert ist, was schwierig bis unmöglich wird wenn WLAN, HDMI, 3D-Beschleunigung und andere Multimedia-Technologien im Spiel sind. Erfordert aber auch eine Menge Wissen und Erfahrung.
PS: Da sich der Aufwand kaum abschätzen lässt, wäre die einzige Alternative zu ablehnen es auf Stundenbasis ohne Deadline zu machen (3 Monate sind sowieso utopisch); dann kannst du nach Bedarf mehr Zeit nehmen. Es ist nicht wie Web oder App-Entwicklung wo man sich mal 1-2 Bücher durchliest, 3 gut dokumentierte Frameworks kombiniert und ein paar User Stories nacheinander umsetzt. Es ist sehr viel Googlen, Foren durchwühlen, Datenblätter lesen, Code durchgehen (inkl. Haare ausreißen), Phantome jagen, Zusammenhänge erraten... Die einzige Rettung wäre wie gesagt eine wohlbekannte Plattform à la R-Pi.
Raspberry ist dafür wirklich keine schlechte Ausgangslage. Ich habe mal ein Projekt mit einer externen Kamera und LCD Anbindung via FPD link mit einem RPi compute module gemacht. Man hat das CSI Interface dann direkt zugänglich und den I2C auch um die Kamera zu konfigurieren. Raspberry unterstützt bis heute nur zwei verschiedene Kamera-Typen dafür kriegt man diese aber teilweise auch als einzelnes Kameramodul zu kaufen (abgesehen von der Pi-Cam) und kann schon sehr kundenspezifische Projekte damit realisieren. CSI + I2C + Power für die Cam lässt sich dann auch problemlos über ein Standard HDMI Kabel übertragen wenn es sein muss
Ingenieur schrieb: > Natürlich absagen. dito, man sollte genug Selbstvertrauen haben auch mal was abzulehnen. 3 Monate sind verdammt kurz, erst Recht wenn man sich selber einarbeiten muss oder keine Erfahrung vom Umfang hat und was da noch nachkommt oder kommen könnte. Wer es trotzdem machen möchte aus Interesse, nicht auf 3 Monate festlegen lassen und nach Aufwand anbieten auf Stundensatz. upps wurde ja schon geschrieben! sorry Dr. Sommer schrieb: > PS: Da sich der Aufwand kaum abschätzen lässt, wäre die einzige > Alternative zu ablehnen es auf Stundenbasis ohne Deadline zu machen (3 > Monate sind sowieso utopisch); dann kannst du nach Bedarf mehr Zeit > nehmen.
Ich schliesse mich all den vorangegangenen Bedenken an. Insbesondere die Aussage von Dr. Sommer, dass "embedded Linux" auf einem eigenen Board kein Spaziergang ist, sollte man mehrfach unterstreichen.
Rpi schrieb: > Raspberry ist dafür wirklich keine schlechte Ausgangslage. Ich habe mal > ein Projekt mit einer externen Kamera und LCD Anbindung via FPD link mit > einem RPi compute module gemacht. Ich musste zweimal lesen, steht wirklich ein k. Das ist genau das Problem, dass Kunden denken, mit einem RPi und der Standardlösung sei das alles abgefrühstückt. Aber man muss es immer wieder erklären: Der RPi ist für Industrielösungen absolut unbrauchbar, das liegt an div. Stabilitätsproblemen, Hardware-Bugs, geschlossene Treiberblobs, usw. so dass es eine Menge Zusatzarbeit gibt, um eine robuste Industrielösung zum Abschluss zu bringen, geschweige überhaupt selbst Hardware mit dem Chip zu produzieren. Oft kommen Kunden, nachdem sie schon bis zu 6 Mannmonaten in den Sand gesetzt haben danach wieder, und kriegen die Krise, wenn sie hören, dass man alles nochmal von vorn für eine neue Plattform machen muss und das Rpi "proof of concept" eigentlich für die Tonne ist. Das ist dann der Zeitpunkt, die zweite Anfrage definitiv abzulehnen, weil dann noch weniger Geld fürs Projekt da ist (und der Zeitdruck...). Lieber von Anfang an richtig machen...
Fitzebutze schrieb: > Der RPi ist für > Industrielösungen absolut unbrauchbar, das liegt an div. > Stabilitätsproblemen, Hardware-Bugs, geschlossene Treiberblobs, usw. so Da kann man erstmal nicht widersprechen, aber was die Menge an verfügbaren Informationen und Software angeht ist der R-PI kaum zu schlagen. Gefühlt wurde schon jeder erdenkliche Anwendungsfall damit abgedeckt. Systeme ohne proprietäre Treiber sind rar und solche ohne Bugs sind nicht existent :) Absurderweise ist man, je leistungsfähiger und Multimedia/Internet-affiner ein System ist, umso mehr auf die Hobby-Bastler-Community angewiesen und desto weniger "seriöse" Quellen gibt es. Am Schlimmsten ist das mit Android-Interna oder Embedded-WLAN; da kann man seine Informationen quasi nur aus Foren ziehen. Die Industrie macht es sich einfach und nutzt für Steuerungen eingebettete Systeme mit Dokumentation und Tools (d.h. diverse Mikrocontroller oder SPS); sobald es aber um Technik geht die aus dem Consumer/Multimedia-Bereich kommt (also viele Linux-geeignete SoC) wird es dünn.
Freiberufler schrieb: > Die wollen mich engagieren, damit ich das in ein 1/4 Jahr erledige. In der Zeit sehr wahrscheinlich nicht machbar. Wenn Du bei der Aufwandsabschätzung noch nicht mal gefragt wirst, dann sag besser ab.
Lauf so schnell und so weit du kannst weg! Da gibt es wirklich nichts weiter zu überlegen.
Fitzebutze schrieb: > Oft kommen Kunden, nachdem sie schon bis zu 6 Mannmonaten in den Sand > gesetzt haben danach wieder, und kriegen die Krise, wenn sie hören, dass > man alles nochmal von vorn für eine neue Plattform machen muss und das > Rpi "proof of concept" eigentlich für die Tonne ist. Das ist dann der > Zeitpunkt, die zweite Anfrage definitiv abzulehnen, weil dann noch > weniger Geld fürs Projekt da ist (und der Zeitdruck...). Ich bin so weit, dass ich Projekte bei denen Worte wie "Raspberry Pie" oder "Arduino" fallen gar nicht mehr annehme und auch nicht diskutiere. Ich kann Leute die mit solchen Vorschlägen und Projekten kommen nicht ernst nehmen. Egal wie schön der Prototyp oder Proof of Concept aussieht.
Marten Morten schrieb: > Ich bin so weit, dass ich Projekte bei denen Worte wie "Raspberry Pie" > oder "Arduino" fallen gar nicht mehr annehme und auch nicht diskutiere. > Ich kann Leute die mit solchen Vorschlägen und Projekten kommen nicht > ernst nehmen. Egal wie schön der Prototyp oder Proof of Concept > aussieht. Das Problem bei solchen Projektanfragen besteht darin, dass die Kunden die Preisvorstellung für den Kauf solcher billigen Standardprodukte dann auch auf individuelle Produktentwicklungen projizieren. Ich hatte auch schon jemanden am Telefon, der von mir verlangte, dass ich für ihn eine Embedded-Linux-Entwicklung kostenlos durchführen müsse. Denn schließlich habe er ja gelesen, dass es bei Linux alles für lau gäbe.
Andreas S. schrieb: > Ich hatte auch schon jemanden am Telefon, der von mir verlangte, dass > ich für ihn eine Embedded-Linux-Entwicklung kostenlos durchführen müsse. > Denn schließlich habe er ja gelesen, dass es bei Linux alles für lau > gäbe. Ja das sind dann so DAUs die von gar nix ne Ahnung haben, da kommt nur Müll als Projektanfrage rein. Besser mit Firmen arbeiten die auch in der Technik drinn sind aber halt keine Kapazitäten frei haben das selber zu machen, da ist dann der Ansprechpartner auch vom Fach und muss nicht jedesmal nem Esel erklären wie man frisst, das ist geht einem irgendwann nur noch auf den Wecker für solche Leute zu arbeiten, die kapieren auch nie warum das soviel kostet wie es eben kostet, Geld haben sie meist auch keines, von wenigen Ausnahmen mal abgesehen. Auf so einen Mist antworte ich inzw. auch gar nicht mehr, ist Zeitverschwendung. Und auch oben schon jemand schrieb wenn Arduino oder Raspberry genannt wird hört man automatisch auf zu lesen. Das sind dann so Startups mit Schnappsideen und ohne Geld oder fachfremde denen Sohn vom Hausmeister was mit nem Arduino grob zusammengeklöppelt hat oder so ähnlich. Bringt kein Geld -> uninteressant -> der nächste Bitte.
Dr. Sommer schrieb: > So eine Embedded-Linux-Geschichte ist extrem komplex und ein riesiger > Aufwand. Wenn das eine bekannte Plattform ist (Raspberry PI oder > Beaglebone o.ä.) kann man da auf was bestehendem ansetzen, aber wenn man > bei 0 anfangen muss ist das ein Fass ohne Boden... Das fängt schon an > alle Treiber für alle Peripherie aufzutreiben, Wenn es ein ernstzunehmender Hersteller ist dann empfiehlt der ein Buildsystem (zum Beispiel Yocto) und bietet alle erforderlichen board-support-packages und Metainformationen an die man dort reinstöpseln muss um damit ein genau auf dieser Hardware laufendes System bauen zu können. Und gleich noch ein Hello-World mit dazu ums mal auszuprobieren. Allerdings wenn man das noch nie zuvor gemacht hat ist man auch als eingefleischter Linuxer erstmal wochenlang (monatelang) am Lernen wie das Buildsystem überhaupt tickt, wie man es korrekt benutzt, wie und wo man Recipes für eigene Software dort richtig einbindet, wo man man fertige Pakete von Drittanbietern findet, wie man notfalls selber welche erstellt für externe Software für die es das noch nicht gibt. Und dann muss man sich auch noch einen ganzen Haufen drumherum bauen um das Gerät und seine Software die darauf laufen soll zu testen und zu debuggen, man muss sich mit U-Boot vertraut machen, etliche Hilfsscripte schreiben die das Entwickeln erleichtern, erlauben von TFTP zu booten, etc., und nicht zuletzt muss man sich auch überlegen wie der Kunde später gefahrlos ein Firmwareupdate einspielen können soll ohne daß man am Ende selber in den Flieger steigen muß um vor Ort mit der seriuellen Konsole am U-Boot-Prompt rumzufrickeln weil es sich "selbst" gebrickt hat. Auch das dauert Zeit. Nach 3 Monaten intensiver Einarbeitung in all das und Klärung aller verbliebenden Unsicherheiten (kann dieser oder jener Treiber dies oder das überhaupt, weiß ich jetzt was ich alles brauche und bekomm ich das auch alles auf der Plattform kompiliert), dann erst, also nach ungefähr 3 Monaten intensivster Beschäftigung mit teilweise absolutem Neuland kann man sich dann auf die eigentliche Entwicklung konzentrieren weil man erst dann so weit ist daß man mehr gegen die ganzen Tools kämpft sondern an ihrer Seite. Beim zweiten mal gehts schneller. Das Wissen das man sich dabei aneignet ist sehr nützlich oder zumindest äußerst interessant und lehrrreich. Aber 3 Monate beim ersten Mal sind in der Tat vollkommen utopisch.
Bernd K. schrieb: > Wenn es ein ernstzunehmender Hersteller ist dann empfiehlt der ein > Buildsystem (zum Beispiel Yocto) Das ist der Idealfall. Chinesische Hersteller (z.B. Rockchip, Allwinner) sind aber so schön billig und haben nichts dergleichen. Die existierenden Fetzen an Doku sind auf chinesisch. Deren Marktmacht und Konkurrenzfähigkeit ist aber durchaus ernst zu nehmen... Sonst stimme ich dir zu. Es gibt eine Unmenge an fiesen Details zu beachten. Kleines Beispiel: Treiber für WLAN-Module per SDIO werden geladen, nachdem der Linux Kernel das Modul angesprochen und identifiziert hat (eine Art Plug&Play, "probe"). Wenn man aber einen separaten Pin zum Aktivieren des Spannungsreglers für das Modul hat, wird das Modul gar nicht erst erkannt und der Treiber nicht geladen. Jetzt hat man ein Henne-Ei-Problem, weil wo will man jetzt den Pin einschalten? Im WLAN-Treiber bringt's nichts... Es irgendwo in den Kernel Source rein hacken ist auch nicht sehr zukunftsfähig.
Dr. Sommer schrieb: > Jetzt hat man ein Henne-Ei-Problem, weil wo will man jetzt den Pin > einschalten? Im WLAN-Treiber bringt's nichts... Es irgendwo in den > Kernel Source rein hacken ist auch nicht sehr zukunftsfähig. Ggf. muss man so etwas im Bootloader, z.B. U-Boot, machen. Es hat auch sich sehr bewährt, dort für Entwicklungszwecke und ggf. auch den Fertigungstest ein paar Kommandos für Low-Level-Funktionen (Pinwackeln) und Initialisierungen zu implementieren. Bei der Gelegenheit kann man dann ggf. auch standardmäßig das o.a. Modul einschalten. Der Vorteil, den Fertigungstest aus U-Boot heraus zu unterstützen, besteht darin, dass man in der eigentlichen Linux-Anwendung keine bzw. deutlich weniger fertigungsrelevante Funktionalität einbauen muss bzw. auch Bedienkonzepte komplett umstellen kann, ohne dass jemand aufwändige Änderungen am Fertigungstester durchführen muss. Außerdem kommen sich dann die kernel- bzw. treiberseitige Initialisierung der Peripherie und die itendierte manuelle Ansteuerung nicht ins Gehege.
Andreas S. schrieb: > Ggf. muss man so etwas im Bootloader, z.B. U-Boot, machen. Auch irgendwie unschön. Ideal wäre es, im DTS zu annotieren, welcher Pin zu welchem Spannungsregler und welcher Regler zu welchem Modul gehört und welches Modul an welcher SDIO/MMC-Schnittstelle hängt. Dann im MMC-Kernelmodul vor "probe" alle Pins aktivieren oder so. Dann könnte man es leicht konsistent in der DTS anpassen.
Dr. Sommer schrieb: > Andreas S. schrieb: >> Ggf. muss man so etwas im Bootloader, z.B. U-Boot, machen. > > Auch irgendwie unschön. Ideal wäre es, im DTS zu annotieren, welcher Pin > zu welchem Spannungsregler und welcher Regler zu welchem Modul gehört > und welches Modul an welcher SDIO/MMC-Schnittstelle hängt. Dann im > MMC-Kernelmodul vor "probe" alle Pins aktivieren oder so. Dann könnte > man es leicht konsistent in der DTS anpassen. Und wie testet man während der Fertigung ganz isoliert, ob diese oder jene Schaltfunktion wirklich funktioniert, ohne dabei Gefahr zu laufen, dass sich der betreffende Linuxtreiber aufhängt, wenn im laufenden Betrieb seine Hardware ausgeschaltet wird? So etwas gehört ganz klar in den Bootloader. Es ist nirgendwo in Stein gemeißelt, dass der Bootloader eine komplett nicht-initialisierte Hardware an den Kernel "übergeben" muss.
Andreas S. schrieb: > So etwas gehört ganz klar in > den Bootloader. Auch die Initialisierung des WLAN-Moduls (Firmware), Displays, Touchscreen usw., USB-Peripherie, und sonst der gesamten Hardware? Die will man ja auch alle bei der Fertigung testen. Wozu überhaupt noch Hardware-Ansteuerung im Kernel haben? Andreas S. schrieb: > wenn im laufenden > Betrieb seine Hardware ausgeschaltet wird? Kernel-Treiber vernünftig implementieren oder den vorher ent-laden.
Andreas S. schrieb: > So etwas gehört ganz klar in > den Bootloader. Hast du dazu vielleicht eine Quelle, Best-Practice oder stammt die Idee von dir? Was auch gemacht wird: Den Fertigungstest in eine normale Linux- oder gar Android-App packen, weit weg von U-Boot. Die wird dann nur 1x beim Hersteller gestartet.
Bernd K. schrieb: > Wenn es ein ernstzunehmender Hersteller ist dann empfiehlt der ein > Buildsystem (zum Beispiel Yocto) und bietet alle erforderlichen > board-support-packages und Metainformationen an die man dort > reinstöpseln muss um damit ein genau auf dieser Hardware laufendes > System bauen zu können. Und gleich noch ein Hello-World mit dazu ums mal > auszuprobieren. Dazu empfehle ich folgendes Video: https://youtu.be/YSUz3xQxCvc Es geht darin um bare-metal Programmierung auf einem beagleboard X15 auf dem ein Texas Instrument SoC sitzt. Das Video ist derart voller WTF-Momente, dass ich mir nicht einmal im Traum ausmalen möchte wie es um die Doku und "Metainformation" von chinesischen Fabrikaten steht...
Vincent H. schrieb: > dass ich mir nicht einmal im Traum ausmalen möchte wie es > um die Doku und "Metainformation" von chinesischen Fabrikaten steht... Die ist schlicht nicht vorhanden. Man muss das mitgelieferte Android nehmen oder hat verloren. Der Kram von TI ist da geradezu vorbildlich im Vergleich. Das Android hat auch den angenehmen Vorteil, dass es so unglaublich komplex ist (50-100GB nur Sourcecode) dass selbst die winzigste Anpassung Wochen-Monate dauert, weil man dazu erstmal die richtige Code-Stelle finden muss. "find" und "grep" werden deine besten Freunde.
Andreas S. schrieb: > Marten Morten schrieb: >> Ich bin so weit, dass ich Projekte bei denen Worte wie "Raspberry Pie" >> oder "Arduino" fallen gar nicht mehr annehme und auch nicht diskutiere. >> Ich kann Leute die mit solchen Vorschlägen und Projekten kommen nicht >> ernst nehmen. Egal wie schön der Prototyp oder Proof of Concept >> aussieht. > > Das Problem bei solchen Projektanfragen besteht darin, dass die Kunden > die Preisvorstellung für den Kauf solcher billigen Standardprodukte dann > auch auf individuelle Produktentwicklungen projizieren. > > Ich hatte auch schon jemanden am Telefon, der von mir verlangte, dass > ich für ihn eine Embedded-Linux-Entwicklung kostenlos durchführen müsse. > Denn schließlich habe er ja gelesen, dass es bei Linux alles für lau > gäbe. Das ist geil, da weiss man nicht ob man Lachen oder Schreien soll. Wenn ich naechstes mal Maler im Haus habe, vorher die Farbe kaufe und diese kostenlos zur Verfuegung stelle, dann muss der Maler doch auch nicht umsonst arbeiten? Ok ich merke, wenn mit so einem Kaese mein Telefon klingeln wuerde, dann werde ich wohl eher sauer als lustig. Das ist eine ziemlich respektlose Anfrage. :-/
Tobias B. schrieb: > Wenn ich naechstes mal Maler im Haus habe, vorher die Farbe kaufe und > diese kostenlos zur Verfuegung stelle, dann muss der Maler doch auch > nicht umsonst arbeiten? Wenn das Bild an der Wand ("weißer Adler auf weißem Grund") unter der GPL lizensiert ist, dann ist das latürnich so ...
Tobias B. schrieb: > Das ist geil, da weiss man nicht ob man Lachen oder Schreien soll. Wenn > ich naechstes mal Maler im Haus habe, vorher die Farbe kaufe und diese > kostenlos zur Verfuegung stelle, dann muss der Maler doch auch nicht > umsonst arbeiten? Nein, Du hast die Argumentation nicht verstanden: Wenn die Farbe Geld gekostet hat, dann wird der Maler natürlich auch bezahlt. Wenn man die Farbe kostenlos erhalten hat, besteht der Anspruch gegen jeden beliebigen Maler, dass er die Wand kostenlos mit der beigestellten Farbe zu streichen habe.
Clemens L. schrieb: > Wenn das Bild an der Wand ("weißer Adler auf weißem Grund") unter der > GPL lizensiert ist, dann ist das latürnich so ... Nein. Wie kommst Du auf diese abwegige Idee? Wie kommen Leute immer nur auf so schwachsinnige Ideen und posaunen sie lautstark in die Welt hinaus ohne sich vorher auch nur im Geringsten informiert zu haben?
Andreas S. schrieb: > Es ist nirgendwo in Stein gemeißelt, dass der Bootloader > eine komplett nicht-initialisierte Hardware an den Kernel "übergeben" > muss. Es sollte nur in Stein gemeisselt sein, dass sich der Linux-Kernel nicht auf eine vom Bootloader initialisierte HW verlässt. Das fällt unter 'very bad practise'. Einen Selbsttest den Bootloader machen lassen ist ansich eine gute Idee, aber nicht unbedingt für peripheriespezifische I/Os, das kann auch schon mal fehlschlagen, wenn der BL auf eine nicht passende HW geladen wird und die Kunden dir einen "Brick" an den Kopf werfen. Das kann überdies zum Maintenance-Albtraum werden, wenn eine ganze Geräteklasse mit unterschiedlichen Bootloadern abgedeckt werden muss. Lieber das Minimum für den BIST, und den Rest je nach gesetzter Variable nachladen. Aber: Das Thema ist abgeglitten, und der "Freiberufler" ist wohl schon längst davor geflohen...
Bin zu Faul zum lesen, aber.... Nehmen wir mal das Basissystem. Die neuen kommerziellen Plattformen ala i.MX6 bringen doch oft schon ein Ökosystem und das BSP mit. Bleibt noch die Kamera und die Anforderungen an die Bildverarbeitung. Vorrausgesetzt, da liesse sich was passendes finden - OpenCV usw.->ist das nix? 3 Monate sind natürlich halsbrecherisch und völlig unrealistisch. Aber es steht doch nirgends, dass alles vom Grund auf nue aufgezogen werden muss.
soso schrieb: > Nehmen wir mal das Basissystem. Die neuen kommerziellen Plattformen ala > i.MX6 bringen doch oft schon ein Ökosystem und das BSP mit. Wenn man sowas denn benutzt. Es gibt keinen Hinweis, dass das kein Frankenstein-System ist mit Rockchip SoC, TI PMIC, Microchip WLAN und irgendeinem NAND-Flash ohne Treiber/FTL. So etwas zusammen zu frickeln ist ein riesiger Aufwand. Wenn man jetzt wüsste dass das einfach nur ein R-PI oder ein abgekupferter BeagbleBone-Schaltplan oder irgendein Eval-Board ist sähe das schon anders aus, aber ohne genauere Angaben kann man das kaum sagen.
Fitzebutze schrieb: > Es sollte nur in Stein gemeisselt sein, dass sich der Linux-Kernel > nicht auf eine vom Bootloader initialisierte HW verlässt. Das fällt > unter 'very bad practise'. Der (Linux-)Kernel sollte z.B. seine Finger von den Timingeinstellungen des Speicherinterface lassen, wenn er selbst aus diesem Speicher ausgeführt wird. Auch das elektrische Einschalten der Versorgungsspannungen, die für den Betrieb wichtig sind, darf ausschließlich im Bootloader erfolgen und sollte vom Kernel nicht mehr angefasst werden. > Einen Selbsttest den Bootloader machen lassen ist ansich eine gute Idee, > aber nicht unbedingt für peripheriespezifische I/Os, das kann auch schon > mal fehlschlagen, wenn der BL auf eine nicht passende HW geladen wird > und die Kunden dir einen "Brick" an den Kopf werfen. Bei der relevanten Projekten, die auch einen Bootloaderaustausch im Feld ermöglichen, setze ich ausschließlich kryptografisch signierte Firmwareimages ein. Und in den - nach bestandener Signaturprüfung - ausgeführten Update-Skripten kann man selbstverständlich auch Fallunterscheidungen für verschiedene Hardwarestände, Firmwarevorgängerversionen und auch Produktvarianten betreiben. > Das kann überdies > zum Maintenance-Albtraum werden, wenn eine ganze Geräteklasse mit > unterschiedlichen Bootloadern abgedeckt werden muss. Es kann zum Fertigungsalbtraum werden, wenn sich hardwaremäßig baugleiche Geräte je nach zu installierender Applikationssoftware während des Fertigungstests unterschiedlich verhielten. Außerdem kostet ein vollständiger Systemstart in der Großserienfertigung einfach viel zu viel Zeit, weswegen man für den Baugruppentest lieber nur eine sehr schnell startende Minimalfirmware verwendet. Wie ich aus eigener Erfahrung weiß, kann man dies auch sehr gut in U-Boot realisieren. Wenn man z.B. bei einen zusätzlichen vollständigen Bootvorgang mit 10 Sekunden durchführt und für einen Fertigungsprüfplatz 60 EUR/h veranschlagt, verursacht das bereits Mehrkosten von 17ct! > Lieber das Minimum für den BIST, und den Rest je nach gesetzter Variable > nachladen. Ich verlange ja auch nicht, möglichst viel Funktionalität in den Bootloader zu packen, sondern genau so viel, dass damit der Fertigungstest möglichst schnell, zuverlässig und reproduzierbar möglich ist. Die Applikationssoftware soll möglichst wenig von den fertigungsrelevanten (und später servicerelevanten) Anforderungen mitbekommen.
SNIP--------------- Das ganze auf einem sehr leistungsfähigen embedded Linux System. Die Rechen-Power ist da, aber es gibt noch keine Installation (Bootloader + Kernel), gar nichts. SNAP--------------- Vll. Ubuntu Server;-) Und ein bissle QT - und die Sache läuft. Die Anfrage ist so präzise gestellt wie die selbst genähte Unterhose meiner Ur-Omma
soso schrieb: > Die Anfrage ist so präzise gestellt wie die selbst genähte Unterhose > meiner Ur-Omma genäht ist
soso schrieb: > soso schrieb: >> Die Anfrage ist so präzise gestellt wie die selbst genähte Unterhose >> meiner Ur-Omma genäht ist Das wurde schon so richtig verstanden und die Knackpunkte angesprochen (Bootloader, Linux, Driver, ...) Ich suchte ja keine technische Hilfe, sondern Beratung in der Entscheidung. Der Thread war mir in der Tat eine große Hilfe.
Freiberufler schrieb: > Ich suchte ja keine technische Hilfe, sondern Beratung in der > Entscheidung. Man könnte besser beraten, wenn man genauer wüsste worum es ginge. Dann könnte man den Aufwand deutlich besser einschätzen.
Andreas S. schrieb: > Ich hatte auch schon jemanden am Telefon, der von mir verlangte, dass > ich für ihn eine Embedded-Linux-Entwicklung kostenlos durchführen müsse. > Denn schließlich habe er ja gelesen, dass es bei Linux alles für lau > gäbe. Es herrscht aber auch die Meinung, dass Linux-Programmierer unheimlich viel Spass mit Linux haben und sowieso (d.h. auch privat ohne Bezahlung) gerne die Arbeit machen würden, weil die Linux-Programmierer sogar das ganze OS für die Allgemeinheit kostenlos zur Verfügung gestellt haben. Wenn sie kostenlos für die Allgemeinheit programmieren, dann natürlich auch für die Firma xy. (Anm: hatte mal gehört, dass 60% des Linux-Code von Firmen, also von bezahlten Mitarbeitern, beigesteuert wurde)
Andreas S. schrieb: > Wenn man die Farbe kostenlos erhalten hat, besteht der Anspruch gegen > jeden beliebigen Maler, dass er die Wand kostenlos mit der beigestellten > Farbe zu streichen habe. Ich hab da ein bisschen einfacher gedacht. Wenn die Arbeitsmittel fuer den arbeitenden Umsonst sind, dann ist auch die Arbeit damit umsonst. In diesem FallL Maler muss nicht fuer Farbe bezahlen, also hat er auch kein Geld zu verlangen. Wie auch immer, die Anfrage ist/war eine Frechheit!
Lass fahren dahin, denn es bringt kein Gewinn. Projekt ablehnen, in der Zeit nicht realisierbar.
Und nicht zuletzt denk daran daß der Kunde Dir einen funktionsfähigen kompletten Aufbau samt oben genanntem Interferometer und Kamera und was noch alles an dem Apparat dranhängt irgendwo hinstellen muss wo Du Zugang hast (am besten bei Dir im Büro) so daß Du in Ruhe entwickeln und alle Funktionen testen kannst damit Du nicht 99% Trockenschwimmen machen musst um dann am letzten Tag bei der Inbetriebnahme festzustellen dass das SO unter DIESEN Umständen ganz anders gehen muss und Du dann irgendwo in der amerikanischen Wüste 72 Meilen entfernt von der nächsten Stadt bei 50°C im Schatten weitere 3 Monate einsam und allein mit nem Laptop in einer Wellblechhütte auf dem staubigen Boden kniest um das an der echten Hardware zum Laufen zu bekommen!
...ich frag mich eher, wie man als oneman-show mit etwas Projekterfahrung überhaupt auf die Idee kommt, dass das zu schaffen sei. Der Rest wurde je bereits gesagt. Ich schwitze schon, weil ich an die Wellblechhütte denken muss :) Klaus.
> ..ich frag mich eher, wie man als oneman-show
Aber wo bringt eine Firma so schnell Mitarbeiter her, die das in zeitnah
bearbeiten könnten?
Hays und Co ist ihnen zu teuer.
Da die Aufgabenstellung sehr interessant klingt, hätte ich den
Personalern empfohlen, an die Unis zu gehen, das Projekt vorstellen und
die besten abzugreifen für eine Diplomarbeit und Werkstudent.
Aber die Personalabteilung macht da nichts in der Richtung: die sind
froh keine weiteren Mitarbeiter zu haben, weil dies dann noch mehr
Arbeit für sie bedeutet.
Freiberufler schrieb: > an die Unis zu gehen, das Projekt vorstellen und > die besten abzugreifen für eine Diplomarbeit Nein, Du brauchst Leute die ähnliche Sachen schon ein paar mal erfolgreich bis zum Ende durchgezogen haben (und die auch wissen wie und wo man auf die Schnauze fallen kann und auch diese Erfahrung bereits hinter sich haben) wenn dieser enge Zeitplan auch nur ansatzweise eingehalten werden soll (und selbst dann ist es noch zu knapp) denn die Skills und die praktischen(!) Erfahrungen die man braucht um das ohne zu stolpern im ersten Anlauf erfolgreich durchzuziehen sind ganz erheblich (Wizard-Level!) und sie sind breit gefächert, da ist nicht viel Zeit für Frischlinge sich vorher erst mal noch mit irgendwelchen Grundlagen vertraut zu machen von Dingen die sie an dem Tag zum ersten Mal zu sehen bekommen, die müssen alle (und das sind viele!) Konzepte und Tools und Vorgehensweisen aus dem ff beherrschen damit sie zielsicher loslegen können.
Freiberufler schrieb: > Aber wo bringt eine Firma so schnell Mitarbeiter her, die das in zeitnah > bearbeiten könnten? > Hays und Co ist ihnen zu teuer. Ach, billig muss es auch sein? Dafür braucht es erfahrene Experten, das wird auf jeden Fall teuer bis sehr teuer... Freiberufler schrieb: > das Projekt vorstellen und > die besten abzugreifen für eine Diplomarbeit und Werkstudent. Studenten und Masteranden werden wohl nur in den allerseltensten Fällen die Erfahrung und das Wissen mitbringen, um so ein Projekt zu stemmen (aber natürlich immer noch nicht in 3 Monaten). Man könnte es in Asien versuchen; da gibt es mehr Leute, welche sich mit Linux und Low-Level-Programmierung auskennen. Hierzulande interessiert man sich ja mehr für das "Big Picture" als für technische Details. Wie kommt man nur auf die Idee, so eine hochkomplexe Angelegenheit wie Embedded Linux in Angriff zu nehmen und dann zu denken das ließe sich mal eben fix billig zusammenschustern?
"Wie kommt man nur auf die Idee, so eine hochkomplexe Angelegenheit wie Embedded Linux in Angriff zu nehmen und dann zu denken das ließe sich mal eben fix billig zusammenschustern?" Weil man es nicht so richtig kennt. Wenn man nur Erfahrung mit einem RPi hat, d.h. fertiges iso image mit Bootloader, Kernel und root-fs, dann denken viele, dass wäre immer so einfach.
Freiberufler schrieb: > Weil man es nicht so richtig kennt. Aber man war in der Lage die Hardware von so einem System zu entwickeln (SoC, DRAM, Interfaces, Layout, ...) und war dabei komplett blind für die Software? Weiß man überhaupt ob dieses System überhaupt ansatzweise funktionsfähig ist? Sonst sitzt man in der Wellblechhütte und schaut den E-Technikern dabei zu wie sie an SMD-Komponenten und kaputten Layouts herumflicken...
"Studenten und Masteranden werden wohl nur in den allerseltensten Fällen die Erfahrung und das Wissen mitbringen" Ich meinte aber die 5% der Studenten, die schon richtig viel Praxiserfahrung haben, mit Low-Level und Video-Verarbeitung, seit ihrer Kindheit gut und schnell programmieren. Die gibt es in jeden Semester. Die nehmen solche Herausforderungen gerne an, um ihr Können zu zeigen, arbeiten rund um die Uhr. Vielleicht zum CCC in Hamburg gehen und sich umsehen? Da zeigen Kids ihre selbstgebauten (und programmierten) Optocopter und lassen sie fliegen. Auf so ein Potential würde ich setzen. Nicht die Normal-Studis, die ihren Stoff gut lernen und dann die besten Noten schreiben.
Freiberufler schrieb: > Die gibt es in jeden Semester. > Die nehmen solche Herausforderungen gerne an, um ihr Können zu zeigen, > arbeiten rund um die Uhr. Uhhm... Also Einhörner? Und die sind wirklich so naiv den finanziellen Wert ihrer Kompetenz nicht zu kennen? Und würden so ein Himmelfahrts-Projekt den vielen anderen gut zahlenden Arbeitgebern vorziehen? Warum stellt nicht einfach jeder solche kompetenten und billigen Leute ein? Gute Außerordentliche Leistung erfordert außerordentliches Gehalt, ob Student oder nicht! Freiberufler schrieb: > Da zeigen Kids ihre selbstgebauten (und programmierten) Optocopter und > lassen sie fliegen. Ardupilot flashen kann ich auch :-)
"Aber man war in der Lage die Hardware von so einem System zu entwickeln (SoC, DRAM, Interfaces, Layout, ...)" Da wird ein Evalboard verwendet. Es existiert ein BSP, aber man kann es erst runterladen, wenn man ein Board hat, und es ist nicht bekannt, was und wie unterstützt wird.
Freiberufler schrieb: > Da wird ein Evalboard verwendet. Es existiert ein BSP, aber man kann es > erst runterladen, wenn man ein Board hat, und es ist nicht bekannt, was > und wie unterstützt wird. Ach, jetzt erfahren wir das! Das ändert die Situation dramatisch. Dann kann man davon ausgehen dass Linux an sich funktioniert. Dann kann man U-Boot und alle möglichen Treiber & Baustellen abhaken und kann sich relativ direkt auf die Video-Angelegenheit konzentrieren.
Also, ich hatte in solchen BSP schon unbrauchbares Zeug, d.h. veraltete Linux-Kernel (ca 2 Jahre). Damals brauchte ich den neuesten mit SocketCAN und dann auch wieder wochenlang alles neu konfiguriert. Der Board-Hersteller schreibt zwar über die Linux-Unterstützung, aber keine Angabe der Kernel-Version. Das ist ein schlechtes Zeichen.
Freiberufler schrieb: > Also, ich hatte in solchen BSP schon unbrauchbares Zeug, d.h. veraltete > Linux-Kernel (ca 2 Jahre). Das ist im Embedded-Umfeld absolut Standard. Selbst mit kompletter Eigenentwicklung ist der Aufwand, das immer auf aktuellem Stand zu halten, kaum zu bewältigen. Freiberufler schrieb: > Damals brauchte ich den neuesten mit SocketCAN und dann auch wieder > wochenlang alles neu konfiguriert. Das ist doch harmlos - besser als alle Treiber von 0 an neu zu erstellen! Freiberufler schrieb: > Der Board-Hersteller schreibt zwar über die Linux-Unterstützung, aber > keine Angabe der Kernel-Version. Das ist ein schlechtes Zeichen. Es ist ein Ausgangspunkt - immer noch viel besser als gar nichts. Kann die "bekannte US-Firma" nicht vielleicht mal freundlich beim Board-Hersteller anfragen wie aktuell das Linux ist und man sich das mal anschauen kann?!
"anfragen wie aktuell das Linux ist und man sich das mal anschauen kann?!" Genau, das wird z.Zt. gemacht. In der Boardbeschreibung stand nur "Supported OS Linux, Android 7,8,9". Das ist eher wenig. Ich vermutete, solange nicht dabei steht "bootable linux kernel 4.x.x", dann ist das auch nicht drin.
Wenn Du sagen würdest welches Board das ist oder wenigstens wie der Hersteller heißt könnte man vielleicht mal nachschauen was die sich unter "Linux support" im Einzelnen vorstellen, zum Beipspiel ob sie OpenEmbedded-Layer liefern wie das zum Beispiel Toradex zu tun pflegt, etc.
Bernd K. schrieb: > Wenn Du sagen würdest welches Board das ist Will er ja leider nicht verraten. Dass überhaupt ein Eval Board genutzt wird ist ja eigentlich auch ein gut gehütetes Geheimnis, damit hat er ja auch gerade erst rausgerückt... Freiberufler schrieb: >>> Die Anfrage ist so präzise gestellt wie die selbst genähte Unterhose >>> meiner Ur-Omma genäht ist > > Das wurde schon so richtig verstanden und die Knackpunkte angesprochen > (Bootloader, Linux, Driver, ...) > Ich suchte ja keine technische Hilfe, sondern Beratung in der > Entscheidung.
> Ich suchte ja keine technische Hilfe, sondern Beratung in der > Entscheidung. Die ist ja im Prinzip gemacht, d.h. Angebot nach obiger Empfehlung. > Dass überhaupt ein Eval Board genutzt > wird ist ja eigentlich auch ein gut gehütetes Geheimnis Das war zum Zeitpunkt des OP noch nicht entschieden, dann hat sich der Favorit geändert, und jetzt betrifft es mich nicht mehr. Genau das war ja das Problem: Dass die Anfrage des Kunden sehr ungenau war (Diagramm mit ein paar Sätzen). Mein Problem war, dass ich eine Stundenabschätzung abgeben sollte, aber nur wenig Anhaltspunkte hatte. So ähnlich wie wenn jemand in die Autowerkstatt geht: "Mein Auto springt nicht an, aber sagen Sie mir genau, was es kostet, und wie lange die Reparatur dauert" Die Projektleute dachten, dass durch das Diagramm die Aufgabe ganz genau beschrieben sei, ich genau wissen müsste, was zu tun sei.
Au weia... Es war eine sehr weise Entscheidung das abzulehnen... Solche Experten möchte man wohl wirklich nicht als Geschäftspartner haben.
"wirklich nicht als Geschäftspartner" so würde ich das nicht unbedingt sagen. Die wollten ins Gespräch kommen, haben erst mal die Idee ganz grob vorgestellt, um erst mal die grundsätzliche Machbarkeit abzuchecken (Vermutung). Ich hatte keinen Kontakt mit denen, die Projektleute dachten, alles ist klar, und man könnte es in einem 1/4 Jahr machen.
> Autor: Freiberufler (Gast) > Datum: 03.04.2019 09:30 Hast du das Ganze übernommen ? Wie ist die Sache ausgegangen ?
Es wird vorerst ein "Raspberry" verwendet. Das vereinfacht die Kamera-Anbindung. Ich habe reines Stunden-Angebot gemacht mit Hinweis auf Schwierigkeiten. (zeitlich befristet)
Bei all den Antworten vermisse ich die Kernfragen nach den anvisierten Stückzahlen, Amortisierungsdauer und Stückpreisen. Daraus ergeben sich ja dann automatisch ein paar Entscheidungen. Ich persönlich würde, wenn es um industrielle Bildverarbeitung geht und damit was kosten darf pro Installation, zu einem NI-System greifen und mit LabView programmieren. Setzt natürlich voraus, dass man fit ist. Dann ist das in 3 Monaten locker erledigt. Ich schätze mal anhand meiner bisherigen Erfahrungen, dass Du in zwei Wochen das Setup fertig hättest und in der restlichen Zeit Dich auf die Programmierung der eigentlichen Anwendung konzentrieren könntest. Was ich sagen will: es ginge in der Zeit, kostet aber. Wäre auch ein RT-Linux dabei. In einem meiner ersten Projekte nach dem Studium, musste ich ein Tektronix Oszilloskop per VISA auslesen und in Matlab m-Files speichern zur später3n Auswertung und parallel mit einer Logitech USB-Camera das Geschehen mitschneiden (DivX) und diese Messdaten dann offline und synchron darstellen. Das ganze hatte ich mit Delphi unter Windows umgesetzt und hatte 4 Monate gedauert. Vielleicht helfen Dir diese Angaben bei Deinen zukünftigen Abschätzungen oder Tool-Auswahlen. Und bitte keine pro/contra Diskussionen zu LabView oder Delphi. Jeder soll dass nehmen, womit er am schnellsten zum Ziel kommt. Gruß Stefan
Absagen oder 3rd Party Partner + Consultor einplanen, welche sich um Yocto und die Kamerasachen etc. kümmern. Eventuell hast Du Glück und die CPU ist schon in den Yoctorezepten drin und du hast somit ein Imagebeispiel, trotzdem bedeutet das viel lernen bis das erste Image, SDK und SDE rauspurzelt, danach kannst erst die eigentliche Applikation beginnen.
Das ist nur was für Profis! Was Hänschen nicht lernt, das lernt Hans nimmermehr
Mut zur Wahrheit schrieb: > Was Hänschen nicht lernt, das lernt Hans nimmermehr Nichtssagende Bullshit-Aussage. Gerade wenns darum geht in 12 verschiedenen Gebieten einigermaßen Erfahrung und Übung zu haben findest Du keine Hänschen sondern nur ausgewachsene Hanse mit grauen Bärten. Die haben nicht aufgehört obwohl der Bart schon grau wurde.
Beitrag #5823942 wurde von einem Moderator gelöscht.
Mut zur Wahrheit schrieb im Beitrag #5823942:
> Die alten Säcke bringen häufig weniger als ein motivierter Frischling
Bis ein motivierter Frischling sich alles angeeignet hat was für die
Aufgabe des TO erforderlich ist (sowas auf Zuruf in 3 Monaten aus dem
Boden stampfen zu können) ist nicht nur die Deadline verstrichen sondern
der Frischling ist bis dahin zum alten Sack gealtert und hört jetzt nur
noch auf den Namen Gandalf und hat auch dessen Fähigkeiten.
:
Bearbeitet durch User
Mut zur Wahrheit schrieb im Beitrag #5823942:
> Die alten Säcke bringen häufig weniger als ein motivierter Frischling
Das glaubst nur Du!
Was manchmal nur auf den ersten Blick funktioniert, die Funktion also
"nur "erfüllt, den Rest aber nicht berücksichtigt.
Das es alte Säcke gibt, die deinem Bild genau entspricht, mag es geben.
Es wird oft viel gestrickt, Updates werden noch bis zum 23.12.
zusammengestrickt und dann für den Kunden zum Update schnell
veröffentlicht, gegen den Rat der alten grauen Säcke.
Die jungen haarlosen Säcke - EY-Chef - ich mache das!
Das läuft! Die alten Säcke haben keine Ahnung!
Der Launch geht raus am 23.12. um 23:30 Uhr.
Nur über Weihnachten/ Silvester kackt das System bei hunderten Kunden
über Weihnachten ab.
Keiner mehr da, weder die alten Säcke noch die geilen Jungspunde mit
Ahnung von eigentlich gar nichts.
Das ist dann lustig!
Die Alten sagen dann zu Recht: not my department"
Ich hatte ein Angebot eingereicht von zunächst 300h, damit man sehen kann ob es überhaupt machbar ist, aber habe die Fertigstellung nicht in Aussicht gestellt. Jetzt nach ca 4 Wochen kommt wieder Bewegung in die Sache. Die 300h sind aber zuviel, deren Budget gibt nur 120h her. Vermutlich wollen die in den 120h alles entwickelt haben.
> Die 300h sind aber zuviel, deren Budget gibt nur 120h her.
Ich hoffe für dich, dass du nicht so fürchterlich dringend auf dieses
Geld angewiesen bist.
Ich frage mich, was seriöser ist: 1. Gleich absagen [Bindefrist vom Angebot war 14 Tage und ist schon abgelaufen, somit ist mein Angebot nicht mehr bindend] 2. Die 120h-Stundensätze mitnehmen und etwas unfertiges im Anfangsstadium zurücklassen.
Freiberufler schrieb: > Vermutlich wollen die in den 120h alles entwickelt haben. Mein Gott lehn den Müll endgültig ab das ist doch jetzt schon von vorne bis hinten durchgenudelt worden. Über so einen Blödsinn überhaupt nur einen Gedanken zu verschwenden, habt ihr keine besseren Projektanfragen, na dann mein Beileid.
> 1. Gleich absagen [Bindefrist vom Angebot war 14 Tage und ist schon > abgelaufen, somit ist mein Angebot nicht mehr bindend] Da musst du nicht einmal antworten.
Freiberufler schrieb: > 2. Die 120h-Stundensätze mitnehmen und etwas unfertiges im > Anfangsstadium zurücklassen. Und anschließend einen ressourcenfressenden Rechtstreit mit dem Auftraggeber führen, weil dieser angeblich nicht gewusst haben will, dass es für den reduzierten Aufwand auch nur einen Teil der erhofften Leistung gibt. Da hilft es ggf. auch wenig, wenn man einen entsprechenden Ausschluss in hundert Steintafeln gemeißelt hat.
Ich habe am Freitag formal abgesagt (Leider kann ich unter diesen Rahmenbedingungen die Leistung nicht erbringen). 1/2 Stunde später kam die Email rein, dass der Umfang im 1. Schritt reduziert wird (Kamera weggelassen, nur Positionsregler), ich "soll" Angebot schreiben. Ursprünglich sollte der Regler von einem externen STM8 betrieben werden wegen schnellen Antwortzeiten ca. 1ms. Jetzt soll das der RPi mit normal Linux. Ich weiß jetzt schon, dass das Timing mit Linux nicht geht, also müsste ich die anfrage ablehnen. Aber dann hätte die Firma ein ganz großes Problem. Das ist Wahl zwischen Pest und Cholera.
Als Selbständiger bist du komplett ungeeignet wenn du keine selbständigen Entscheidungen treffen kannst und ständig wie ein Kleinkind im Forum nachfragen musst.
Dafür ist das Forum ja da. Wenn Selbständige sonst nur mit Hays, Gulp ... arbeiten, haben sie keine Erfahrung in solchen Fragen.
Dann lehne doch das einfach Projekt ab wenn dir die Rahmenbedingungen nicht passen.
Ich habe die Stm8 Lösung angeboten.
Mut zur Wahrheit. schrieb: > Dann lehne doch das einfach Projekt ab wenn dir die Rahmenbedingungen > nicht passen. Wozu gänzlich ablehnen? Wenn das zu negativ aufgenommen wird, gibt es in Zukunft keine Anfragen mehr. Stattdessen bringt man den Kunden durch ein Angebot mit hohem Risikopuffer in die Realität zurück. Im Forum fragt er ja nur, weil er sicher gehen will nichts zu übersehen. Das finde ich richtig. Er ist kein Elektriker. Als selbstständiger Entwickler lernt man lebenslang. Manchmal erweitert man so sein Gebiet.
Bill Gates und Steve Jobs haben sich nie in Foren ausgeheult. Das waren noch Macher.
> Das waren noch Macher.
Ja, echte Maker eben.
Freiberufler schrieb: > Ich habe die Stm8 Lösung angeboten. Und ist denn derjenige, der nun die Lösung mit reduziertem Umfang haben will, auch exakt derjenige, der die Beauftragung veranlassen und die Abnahme der Leistung durchführen wird? Oder fällst Du gerade auch auf den Trick herein, den ich selbst aus leidvoller Erfahrung schon erfahren habe, dass für die Abnahme plötzlich jemand anderes zuständig ist, der den vollen Lieferumfang erwartet? Mitarbeiter: "Wir finden niemanden, der alles für kleines Geld und Funktionsgarantie erledigen will." Chef: "Dann verhandeln Sie weiter!" Mitarbeiter: "Ich habe nachverhandelt, und derjenigen macht das jetzt für deutlich kleineres Geld als von uns geplant." Chef: "Und ist da auch wirklich alles enthalten?" Mitarbeiter: "Ähh, ja natürlich, fast alles." Und wenn es dann ans Bezahlen geht, beruft sich der Chef darauf, dass der Lieferant seinem Mitarbeiter gegenüber zugesagt hätte, alles zu liefern.
"beruft sich der Chef darauf, dass der Lieferant seinem Mitarbeiter gegenüber zugesagt hätte, alles zu liefern." Nicht irgendwie schriftlich oder per Email dokumentiert? Ich habe bei dieser Firma innerhalb 10 Jahr Projekte bearbeitet und es lief super, besser als Hays/Solcom Projekte. Jetzt wurde eine Stelle eines "Entwicklungsleiters" geschaffen, und dieser junge Mitarbeiter scheint erfolgreich sein zu wollen. Eine Stelle eines weiteren SW-Entwicklers wäre wesentlich dringender.
Andreas S. schrieb: > Oder fällst Du gerade auch auf den Trick herein, den ich selbst aus > leidvoller Erfahrung schon erfahren habe, dass für die Abnahme plötzlich > jemand anderes zuständig ist, der den vollen Lieferumfang erwartet? Alles ganz genau und absolut unmißverständlich schriftlich fixieren so daß man später auch unter größten Verrenkungen es nicht schaffen kann Art und Umfang des Projekts nachträglich irgendwie umzuinterpretieren!
:
Bearbeitet durch User
Andreas S. schrieb: > Und wenn es dann ans Bezahlen geht, beruft sich der Chef darauf, dass > der Lieferant seinem Mitarbeiter gegenüber zugesagt hätte, alles zu > liefern. Mündliche Zusagen sind irrelevant. Es zählt das, was schwarz auf weiß geschrieben steht.
Mark B. schrieb: > Mündliche Zusagen sind irrelevant. Es zählt das, was schwarz auf weiß > geschrieben steht. Und von den Vertragsparteien auch so unterschrieben wurde, versteht sich.
Mark B. schrieb: > Mündliche Zusagen sind irrelevant. Es zählt das, was schwarz auf weiß > geschrieben steht. Grundsätzlich zählen nach BGB auch mündliche Absprachen. Es ist nur immer wieder ein Problem, sie zu beweisen. Mark B. schrieb: > Und von den Vertragsparteien auch so unterschrieben wurde, versteht > sich. Interessant ist in dem Zusammenhang die Frage, wie lange man sich eigentlich Zeit lassen darf, wenn ein Vertrag einseitig unterschrieben wurde? Gerne werden ja Verträge unterschrieben und versendet und man wartet dann auf Gegenzeichnung. Wie lange ist man daran gebunden?
Bei so muehsamen Projekten, immer etwas offen lassen. Wenn also Funktionsumfang und Preis fest sind, die Lieferzeit offenlassen und allenfalls ein besseres Projekt in der Mitte einschieben. Bei diesem zB kommunizieren, dass du erst ein anderes Projekt beenden muesstest. Bevor sie auf die Idee kommen, sie haetten dich priorisiert.
Beitrag #7124666 wurde von einem Moderator gelöscht.
Beitrag #7124675 wurde von einem Moderator gelöscht.
Freiberufler schrieb: > Wie verhält man sich da? > > Probieren und scheitern und Geld versenken. > Gleich sagen, "not my department", und absagen. 3. "Partner" mit Ahnung suchen, auf seine Preise 200% aufschlagen.
Beitrag #7124730 wurde von einem Moderator gelöscht.
Beitrag #7124775 wurde von einem Moderator gelöscht.
Bimbo. schrieb: > TestX schrieb: > >> Lasten-/pflichtenheft anfordern und daran abschätzen ob es machbar ist. >> Wenn du noch nie etwas in Richtung bildverarbeitung gemacht hast lass >> es... > > Schuster bleib bei deinen Sohlen. Nebenbei darf sich der Schuster > natürlich auch weiterbilden. Aber wenn ich erst noch das Schnüren lernen > muss, dann werde ich nicht der Kundschaft die Schuhe zubinden. Du meinst wohl Priester bleib bei deinen jungfräulichen Kindern. Oder Pfarrer bleib bei deinen anonymen Liebesknechten.
Beitrag #7127115 wurde von einem Moderator gelöscht.
Dich qualifiziert genau was hier diesen Ratschlag zu geben?
Beitrag #7130413 wurde von einem Moderator gelöscht.
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.