Hallo zusammen, ich würde gerne wissen wie Ihr Embedded Software zusammen fügt um schnell zu einem Ergebniss zu kommen. Z.b. ein uConroller benötigt für ein Projekt ein I2C, SPI, USB und Ethernet. Dafür gibt es 4 verschiedene examples. Jetzt müsste ich die example zusammen fügen. Momentan ist mir Atmel Studio am liebsten, dort kann ich über den Wizard alle treiber hinzufügen, bei anderen uC geht das leider nicht, z.B. für STM oder NXP. Wie geht Ihr dabei vor? Grüße + Danke DDMW
Hallo, Bei STM gibt es Cube, bei Infineon XMC DAVE, etc... Ähnliches gibt es mittlerweile eigentlich bei allen/vielen µCs. Man muss bei konfigurierbaren Pins ein bisschen aufpassen, da diese sich u.U. die Hardware "teilen". Perpiherie-Clock anschalten usw. nicht vergessen. Vorgehensweise: Codeabschnitte strukturieren (Initialisierung, Pin direction etc) kopieren, dann testen. Evtl. Eine Ausgabe über I/O oder Debugger . Wenn zwei gehen, die nächste HW in Betrieb nehmen usw... Gruß BT
Danke für deine Antwort. Das Cube nutze ich gerade für dei Code generierung, nur dann weiß ich noch nicht wie ich den generierten Code in das STM Workbench importieren kann. Gruß DDM
Wobei hier kann man die Toolchain einstellen. Habe die Option dafür gefunden.
Schnelles zusammenfuegen von Modulen.. indem man bereitz modular designt. Zb Fuer alle Projekt dasselbe Protokoll. Der ADC ist auch immer derselbe Code. Das Menukonzept ist dasselbe, Das LCD Konzept ist dasselbe.
Daniel X. schrieb: > Dafür gibt es 4 verschiedene examples. Jetzt müsste ich die example > zusammen fügen. Ja und? Als Programmierer wird man fürs Programmieren bezahlt. Da kann man auch mal ein paar Zeilen Code programmieren. Wenn du als Programmierer wirklich keine Lust auf Programmieren hast, dann würde ich dir statt Embedded eher den Enterprise-Bereich empfehlen. Da wird orchestriert, gebundled, virtualisiert, composed, deployed, distributed und injected. Da werden Microservices für Multilayered Architectures im Rahmen von DevOps in Container gepackt und continuously delivered. Das kommt alles as-a-service und cloud aware, und skaliert im Rahmen des Business Models. Kurz, da passiert alles, nur Programmieren wird möglichst vermieden.
Jack schrieb: > Daniel X. schrieb: >> Dafür gibt es 4 verschiedene examples. Jetzt müsste ich die example >> zusammen fügen. > > Ja und? Als Programmierer wird man fürs Programmieren bezahlt. Da kann > man auch mal ein paar Zeilen Code programmieren. Tja, mit der Einstellung wirst du untergehen. Kein Mensch bezahlt jemanden für "ehrenhfates und rechtschaffenes Coding im Schweiße deines Angesichtes", oder optimalen Code. Flash, Ram und Rechenleistung werden schneller billiger als die Programmierer schlechter werden - optimierung zahlt sich selten aus. Es geht immer nur um schnelle Resultate. Wenn man die huschdipfusch zusammenklicken kann, ist der "ehrenhafte und rechtschaffene Coder" eben überflüssig. Diejenigen, die an ihrer geliebten sauberen und langsamen Arbeitsweise festhalten, werden untergegangen. Das kann dir passen oder nicht aber so ist das nun einmal. Man kann sich möglicherweise eine Niesche suchen (Medizin? Sicherheit?) aber beim Großteil der Anwendungen ist es so. Schau dir den PC-Bereich an: Speicher ist Faktor 1000000 mehr geworden, Rechenleistung auch, aber läuft der Kram schneller? Nein, Word 2010 startet genaus lahm wie Word für Dos 5.0. Gleiches Spiel.
Urks schrieb: > Jack schrieb: >> Daniel X. schrieb: >>> Dafür gibt es 4 verschiedene examples. Jetzt müsste ich die example >>> zusammen fügen. >> >> Ja und? Als Programmierer wird man fürs Programmieren bezahlt. Da kann >> man auch mal ein paar Zeilen Code programmieren. > > Tja, mit der Einstellung wirst du untergehen. > ... > > Diejenigen, die an ihrer geliebten sauberen und langsamen Arbeitsweise > festhalten, werden untergegangen. Das kann dir passen oder nicht aber so > ist das nun einmal. Man kann sich möglicherweise eine Niesche suchen > (Medizin? Sicherheit?) aber beim Großteil der Anwendungen ist es so. > Naja, das mit der Nische ist relativ. Ich habe auf der Messe mal mit den Leuten von Somnium gesprochen. Die stellen i.W. einen optimierenden Linker für ARM Cortex her, mit dem sich die Waage zwischen Codegröße und Laufzeit sehr fein tunen läßt, um auch beim M0+ chips mit sehr beschränktem Flash noch das Optimum rausholen zu können. Klar muss auch eine Firma wie Somnium damit kämpfen, dass Mainstream Embedded dem 90er/00 Trend der PC Welt zu immer leistungsfähigerer und gleichzeitig billigerer Hardware folgt und damit ressourcesparendes Programmieren tendentiell unwichtiger wird. Allerdings gibt es noch mehr als genügend "Nischen" im Embedded Bereich (speziell Industrieautomation), in denen man es sich nicht leisten kann, überdimensionierte Hardware einzusetzen - zum Einen weil sich bei höheren Stückzahlen selbst 10 Cent Preisunterschiede zwischen Controllern zu 5 Stelligen Mehrausgaben anhäufen können, aber auch weil technische Anforderungen wie Stromverbrauch oder Wärmeentwicklung im kritischen Pfad liegen. Für solche Anwendungen wird auch nach wie vor die "schnelle" Entwicklung nicht als primäres Entwicklungsziel gelten. Somnium ist gut im Geschäft, es gibt einen anhaltenden Bedarf für das was sie tun, und Cortex M0+/3/4 wird uns noch viele Jahre Arbeit beschaffen. Was sicherlich stimmt ist, dass sich die Embedded Welt stärker ausdifferenzieren wird und ein wesentlicher Teil von dem, was bislang Domäne der "old Style Handwerker" war, in Richtung "Java Zusammenstecker von der Strasse geheurt" geht (i.W. Alles was im Graubereich zwischen Industrial und Consumer liegt). Damit wird aber trotzdem der Markt für die, die gerne jedes Byte Dreimal umdrehen, nicht völlig austrocknen, sie werden nur (wie eigentlich Jeder Andere im Arbeitsmarkt auch) etwas mehr selber dafür tun müssen, um eine Stelle zu finden, in denen sie sich ausleben können. Und Leute, denen die Ingenieursarbeit nicht in die Wiege gelegt worden ist, werden sich vermutlich in der Java Welt sowieso lieber aufhalten.
:
Bearbeitet durch User
Urks schrieb: > Wenn man die huschdipfusch zusammenklicken kann, > ist der "ehrenhafte und rechtschaffene Coder" eben überflüssig. Ich sehe das nicht so schwarz. Im Embedded Bereich ist die Leidensfähigkeit der Anwender deutlich geringer, d.h. die Programme müssen 365d/a zuverlässig laufen. Und das geht nur, wenn man auch durchsieht, was man da programmiert hat und nicht, wenn man nur unbekannte Legosteinchen zusammenklickt. Insbesondere alle zeitlichen Abläufe sollte man kennen. Oft wird einfach ohne Sinn und Verstand mit Timeouts um sich geschmissen und die Programme laufen wie in Zeitlupe. Der Zusammenklicker hat zwar schnell irgendwas, was so aussieht, als würde es laufen. Aber er braucht dafür umso länger zum debuggen, ehe es wirklich fertig ist. Und eine Supportreise zum Kunden z.B. nach China, Kanada oder Indien sollte er auch schon mal einplanen und seinen Impfstatus aktualisieren. Auf jeden CPU-Zyklus und jedes Byte RAM muß man natürlich nicht mehr optimieren, das stimmt.
Ruediger A. schrieb: > Naja, das mit der Nische ist relativ. Ich habe auf der Messe mal mit den > Leuten von Somnium gesprochen. Die stellen i.W. einen optimierenden > Linker für ARM Cortex her, mit dem sich die Waage zwischen Codegröße und > Laufzeit sehr fein tunen läßt, um auch beim M0+ chips mit sehr > beschränktem Flash noch das Optimum rausholen zu können. Ja, das ist natürlich richtig, auch hohe Stückzahlen sind da so ein Fall. Von dem her ist "Nische" so auch nicht ganz richtig. Andererseits müssen die Stückzahlen schon sehr groß sein. Nehmen wir mal 0,1€ und 100k Stück an, das sind 10000€. Das klingt viel, aber im Endeffekt sind das nur 100 Entwicklerstunden - grob 2 1/2 Wochen. Das hat man bei einem Projekt schnell eingespart, wenn man es sich zum Beispiel spart, die ganzen Treiber selber zu schreiben. Natürlich gibt es auch Anwendungen mit 1M Stück, da zahlt es sich dann aus, 100nF Kerkos wegzuoptimieren, und erst recht, gescheiten Code zu schreiben. Wenn ich zum Beispiel an meinen Arbeitgeber denke, kommen wir selbst bei Highrunnern nur auf 10kStück / Jahr, da wird schon aus Aufwandsgründen immer das größte Derivat genommen - insbesondere wegen des Termindrucks kann keiner optimieren. Dazu kommt: Der µC macht im Schnitt 0,1% des Gerätepreises aus. Das Problem dabei: Firmwareentwickler verhalten sich wie ideale Gase, die füllen den vorhandenen Platz immer zu 100% aus...
Ja. Ist wohl doch eine Schwebung. Habe mich irgendwie durch die Frage nach der Modulation irre führen lassen. Jedenfalls wohl recht viel Schallleistung notwendig.
Und dann gaebe es auch noch die Anwendungen, bei welchen der Code 100% sicher sein soll. Garatiert kein Absturz. Das erwart ich zB bei den selbstfahrenden Auto. Das macht man nicht mit etwas Java zusammenstoepseln.
Das ist ganz böse! Jegliche Art von HAL müsste verboten werden, da es unweigerlich zum Vendor lock in führt und Du wirst dafür in der Hölle schmoren! Du musst erstmal die Spezifikation I2C, SPI, USB und Ethernet auf BIT-Ebene nachlesen (und dann natürlich auch alle oberen Schichten), und Dir Deine eigenen Include-Files und Treiber programmieren. In 5 Jahren, wenn Du dann den lauffähigen Code hast, aber es inzwischen Controller gibt, die 5x schneller sind, Du aber aufgrund Deiner eigenen Low-Level Treiber NICHT migrieren kannst, darfst Du wieder hier posten.
W.S. seine Mutter schrieb: > I2C, SPI, USB und Ethernet > In 5 Jahren, wenn Du dann den lauffähigen Code hast, 5 Wochen. 1 Tag I2C 1 Tag SPI 2 Wochen USB 2 Wochen Ethernet Ab dem zweiten mal (wenn man weiß wies geht und auf eigenen gut verstandenen existierenden Code zurückgreifen kann) gehts dann schneller. In ernsthaften Buden (solche die Sachen bauen bei denen man sich fragt wie die das unmöglich geglaubte möglich gemacht haben) arbeiten nur Leute die sich für das Zeug wirklich tiefgehend interessieren (auch im Hobby). Die lesen Gerätetreiber-Quellcode zum Frühstück anstelle der Zeitung. So jemandem sagst Du daß man noch noch einen I2C-Slave Treiber in den Bootloader einbauen müsste damit Firmware-Update aller Module praktikabel ist und der zieht den fertig aus der Tasche weil er das im Laufe seines Lebens schon auf 12 verschiedenen Architekturen gemacht hat und zufällig letztes Wochenende auch auf dieser (vorausschauender weise).
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.