mikrocontroller.net

Forum: Ausbildung, Studium & Beruf "not my department": Projekt angeboten, was kaum machbar ist


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Freiberufler (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Ingenieur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Natürlich absagen.

Autor: dunno.. (Gast)
Datum:

Bewertung
19 lesenswert
nicht lesenswert
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.

Autor: TestX (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Lasten-/pflichtenheft anfordern und daran abschätzen ob es machbar ist.
Wenn du noch nie etwas in Richtung bildverarbeitung gemacht hast lass 
es...

Autor: Bimbo. (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Ingenieur (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
1/4 Jahr ist sehr kurz, da ist keine Zeit sich noch groß einzuarbeiten.

Autor: Frank T. (unwichtig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fitzebutze (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Firmensanierung durch Rausschmiss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der kein Bock mehr A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, wie Dunno schon schrieb, Du musst die sogenannte "Inverse 
Sizilianische Strategie" anwenden : Mache de Kunde eine Angebote, die 
err Ablehne musse !!!

Gruß

Autor: Andreas B. (buyman)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rpi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mehmet K. (mkmk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Fitzebutze (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ingenieur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lauf so schnell und so weit du kannst weg! Da gibt es wirklich nichts 
weiter zu überlegen.

Autor: Marten Morten (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: Firmensanierung durch Rausschmiss (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Youtube-Video "Embedded rust on the beagleboard X15 - Jonathan Pallant"

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...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. :-/

Autor: Clemens L. (c_l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: soso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: soso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: soso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
soso schrieb:
> Die Anfrage ist so präzise gestellt wie die selbst genähte Unterhose
> meiner Ur-Omma genäht ist

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Zocker_55 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lass fahren dahin, denn es bringt kein Gewinn.

Projekt ablehnen, in der Zeit nicht realisierbar.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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.

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ..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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 :-)

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Au weia... Es war eine sehr weise Entscheidung das abzulehnen... Solche 
Experten möchte man wohl wirklich nicht als Geschäftspartner haben.

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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: Zocker_55 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Autor: Freiberufler (Gast)
> Datum: 03.04.2019 09:30

Hast du das Ganze übernommen ?

Wie ist die Sache ausgegangen ?

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es wird vorerst ein "Raspberry" verwendet.
Das vereinfacht die Kamera-Anbindung.
Ich habe reines Stunden-Angebot gemacht mit Hinweis auf Schwierigkeiten. 
(zeitlich befristet)

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Torben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mut zur Wahrheit (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Das ist nur was für Profis!

Was Hänschen nicht lernt, das lernt Hans nimmermehr

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Rick M. (rick-nrw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Francis 7 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mut zur Wahrheit. (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Freiberufler (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dafür ist das Forum ja da.
Wenn Selbständige sonst nur mit Hays, Gulp ... arbeiten, haben sie keine 
Erfahrung in solchen Fragen.

Autor: Mut zur Wahrheit. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann lehne doch das einfach Projekt ab wenn dir die Rahmenbedingungen 
nicht passen.

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die Stm8 Lösung angeboten.

Autor: Realistischer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Mut zur Wahrheit. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bill Gates und Steve Jobs haben sich nie in Foren ausgeheult. Das waren 
noch Macher.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das waren noch Macher.

Ja, echte Maker eben.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Freiberufler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.