Hallo! Ich suche eine Empfehlung für ein RTOS für den kommerziellen Einsatz Situation: Bei meinem Arbytegeber werden aktuell TI TIVA TM4C Controller zusammen mit dem TI RTOS und dem Code Composer Studio eingesetzt. Funktioniert soweit, aber das TI RTOS ist nicht wirklich bugfrei, die TIVA-Prozessoren werden irgendwie nur stiefmütterlich unterstützt, und eine Weiterentwicklung und ein Wachstumspfad (z.B. in Richtung Cortex M7 oder so) ist nicht in Sicht. Daher suche ich jetzt eine Alternative. Anforderungen: • Komponenten o RTOS-Kernel o TCP-IP Stack mit Basis-Protokollen (DNS, DHCP, TFTP, SNMP, …) o USB-Stack mit Support für minimal HID, CDC-ACM, CDC-ECM/EEP, Mass Storage als Device o gerne Support für CAN-High-Level Protokolle wie CANOpen o Hardware-Abstraktionsschicht • Herstellerübergreifend, möglichst architekturübergreifend • Support für o TI TIVA TM4C o Microchip PIC32 o gerne weitere Cortex M/Cortex R Architekturen • Kommerzieller Support verfügbar. Meine Arbeitszeit ist teuer, und wenn es da Probleme mit dem Produkt gibt, will ich die gelöst haben. • Lizenz geeignet für den kommerziellen Einsatz (BSD, MIT, proprietär,...), kein GPL • stabiler Hersteller, den es auch noch in 5 oder 10 Jahren gibt • kann ruhig Geld kosten vxworks hatte ich schon mal in den Fingern gehabt, aber das ist jetzt 20 Jahre her. Mit ThreadX/NetX habe ich auch schon gearbeitet, aber das ist ja jetzt vermicrosoftet und heißt nun AzureRTOS - keine Ahnung, was ich davon halten soll und welche Zukunfsaussichten das Zeugs jetzt hat. EmbOS von Segger klingt erstmal interessant, ist mir aber ansonsten unbekannt. Mein Arbytegeber ist im allgemeinen industriellen Umfeld unterwegs. Sachen, die speziell für Automotive oder Luftfahrt zugeschnitten sind, passen für uns nicht. Irgendwelche SIL oder ISO26262 Sachen brauchen wir auch nicht. Anregungen? fchk
FreeRTOS -> gehört jetzt glaube ich zu Amazon, gab meines wissens auch komerzielle support/versio NucleusPlus -> Mentor graphics, OS war eigentlich grauchbar, Vom Functkions umfang vergleichbar mit ThreadX. nicht ganz preiswert. für das was du alles haben wilst, wird das sicher ganz schnell 6 stellig. USB Code (Class / controller) waren so ne sache, Waren damals nicht immer bug frei. der Code waren mit irgend einem Code generator generiert. In dem C code Fehler suchen war ein echter graus, ... 5 fach erweiterte Arrays of function pointers, ... (war vermutlich OO code der als C generiert wurde) Micrium OS ist weniger complex wie ThreadX / NucleusPlus (keine aufteilung in Hiser und Liser) eher vergleichbar mit FreeRTOS RTXC Quadros (nur mal geschult worden nie eingesetzt) eher unbekant.
Wenn es gratis sein soll und Du viel Zeit+Lust auf patchwork-debugging hast: FreeRTOS + LwIP + FatFS Zahlbar, performant und mit gutem Support: ChibOS http://www.chibios.org/dokuwiki/doku.php Für wenig Geld (bzw. beim Kauf einer Lizensierung) wird Giovanni rasch eine Portierung/BSP auf deine CPU erzeugen. TCP/IP Stack: https://www.oryx-embedded.com/products/CycloneTCP
Schau dir mal MDK-ARM Professional an. CMSIS-RTOS (RTX5), Middleware mit FlashFS, Ethernet, USB. Unterstützung / Visualisierung im UV Debugger. Vorteil: Alles aus einem Guss, einfachere Integration und Zusammenspiel. Und es sollte alle deine Anforderungen erfüllen :-) https://www2.keil.com/mdk5/editions/pro
:
Bearbeitet durch User
Frank K. schrieb: > • stabiler Hersteller, den es auch noch in 5 oder 10 Jahren gibt > > Anregungen? Damit bleibt kein RTOS mehr übrig. Dein Problem ist gelöst.
Seggers embOS kann ich nur empfehlen. Bisher keine Probleme gehabt und der Support meldet sich i.d.R. noch am selben Tag.
Schade, hätte ja gerne Mbed empfohlen, aber ARM und TI scheinen nicht die besten Freunde zu sein, da gibt es so gut wie nix. Und PIC32 sind auch nicht von ARM. Ein OS das die alle Unterstützt wird teuer sein und ich gehe davon aus das man auch den Herstellersupport öfter braucht. Wenn soviele grundverschiedene Targets gleichermassen incl. High Level Funktionalität zuverlässig unterstützt werden sollen, dann ist das ein irrer Testaufwand. Das FreeRTOS ist sicher ein gutes RTOS, aber der freie Kernel hat erstmal keine Unterstützung für Prozessorspezifische Peripherie. Da muss man sich selber um Mutex & Co kümmern, und das ist sicher nicht immer trivial. Zusätzliche Bibliotheken waren bei FreeRTOS ja auch Kaufware.
Frank K. schrieb: > vxworks hatte ich schon mal in den Fingern gehabt, Das hätte ich jetzt genannt. Erfüllt das was du suchst. Was spricht für dich dagegen es wieder zu nutzen? Der Preis?
900ss D. schrieb: > Frank K. schrieb: >> vxworks hatte ich schon mal in den Fingern gehabt, > > Das hätte ich jetzt genannt. Erfüllt das was du suchst. Was spricht für > dich dagegen es wieder zu nutzen? Der Preis? Ich habe mir die Liste der Board Support Packages angeschaut und recht wenig Cortex M3/M4/M7 gefunden. Insbesondere kein TI TIVA. fchk
> Frank K. schrieb: >> vxworks hatte ich schon mal in den Fingern gehabt, > > Das hätte ich jetzt genannt. Erfüllt das was du suchst. Was spricht für > dich dagegen es wieder zu nutzen? Der Preis? Der Preis ist definitiv ätzend. Viel Geld für (*)Null Support und Unterstützung.
Mike schrieb: > Viel Geld für (*)Null Support und Unterstützung. Selten soviel Blödsinn gelesen. Kann aus eigener Erfahrung sagen, dass Support und Unterstützung recht gut sind wenn man entsprechend zahlt natürlich. Aber das wird OT.
Zu deinem TI Prozessor kann ich jetzt leider nix sagen. Ich kann aber für die anderen beiden Serien mich den Vorrednern nur anschließen und MicriumOS sowie FreeRTOS empfehlen. MicriumOS hat ne gute Doku, da fuchst man sich schnell ein. Nen TCP Stack gibts auch, aber dann doch lieber lwip. Die Aufkauferei hat auch Micrium nicht verschont, die wurden von SiliconLabs geschluckt.
Frank K. schrieb: > Ich habe mir die Liste der Board Support Packages angeschaut und recht > wenig Cortex M3/M4/M7 gefunden. Insbesondere kein TI TIVA. TI bietet scheinbar ein BSP an. http://www.ti.com/tool/WIND-3P-VXWORKS-LINUX-OS#descriptionArea
900ss D. schrieb: > Frank K. schrieb: >> Ich habe mir die Liste der Board Support Packages angeschaut und recht >> wenig Cortex M3/M4/M7 gefunden. Insbesondere kein TI TIVA. > > TI bietet scheinbar ein BSP an. > > http://www.ti.com/tool/WIND-3P-VXWORKS-LINUX-OS#descriptionArea Das ist für die SItaras (Cortex A) und für die Windriver Linux-Variante, nicht fürs RTOS und auch nicht für die TIVA Cortex M. fchk
Frank K. schrieb: > Das ist für die Sitaras (Cortex A) ... nicht fürs RTOS Für Sitara AM5728 gibt es auch RISC OS und ein Eval-Board damit: http://www.ti.com/tool/ELESAR-3P-SITARA-SOMS https://www.riscosopen.org/content/downloads/titanium
pc schrieb: > Seggers embOS kann ich nur empfehlen. Bisher keine Probleme gehabt > und > der Support meldet sich i.d.R. noch am selben Tag. Das hätte ich jetzt auch empfohlen ;-). Also eigentlich versuchen wir sogar in den ersten 15 Minuten zu antworten und sei es nur ein "Danke für die Anfrage, müssen wir uns kurz anschauen und melden uns gleich wieder.". Frank K. schrieb: > Hallo! > > Ich suche eine Empfehlung für ein RTOS für den kommerziellen Einsatz Da können wir dir weiterhelfen. Auf den ersten Blick würde ich sagen wir haben alles bis auf CAN da: https://www.segger.com/products/rtos-embedded-software/ https://www.segger.com/products/rtos/embos/ Du könntest dir einfach mal die embOS Cortex-M ES Free Version und das Embedded Studio downloaden (oder alternativ das embOS Cortex-M für einen anderen Compiler/IDE) und damit rumspielen. https://www.segger.com/products/rtos/embos/supported-cores-compiler/arm/cortex-m/embos-cortex-m-embedded-studio/ https://www.segger.com/downloads/embos/embOS_CortexM_EmbeddedStudio_Trial https://www.segger.com/products/development-tools/embedded-studio/ Oder erstmal einen Blick in das embOS Manual werfen: https://www.segger.com/downloads/embos/UM01001 Du kannst mich natürlich auch gerne direkt per Email oder Telefon erreichen. Telefonnummer steht unten auf https://www.segger.com/. Entweder hier ein Ticket aufmachen (https://www.segger.com/support/technical-support/) oder die embOS Support Emailadresse benutzen. Diese findest du im embOS Manual im Kapitel Support. Ist nur wahrscheinlich besser sie hier nicht hinzuschreiben wegen Spam.
also ich schaue mir gerade Zephyr näher an. Das kommt aus dem Linux-Umfeld. https://www.zephyrproject.org/ Wer mit der Kommandozeile vertraut ist, wird auch zurechtkommen. Das basiert auf einem Windriver OSKern. Gut finde ich die Treiberintegration. TCP, USB, BLE, Sensoren, Flash, Filesysteme alles drin. Aktuell stabilisieren sich auch die Windows-Umgebungen dazu. Sie benutzen ARM GCC. Inwiefern auch der Keil Compiler geht, weiss ich nicht. HTH, Adib. --
Frank K. schrieb: > • Kommerzieller Support verfügbar. Meine Arbeitszeit ist teuer, und wenn > es da Probleme mit dem Produkt gibt, will ich die gelöst haben. Ich kenne sowohl von einem früheren Arbeitgeber als auch von etlichen meiner Kunden die massiven Probleme mit einigen Betriebssystemherstellern, die vorrangig unter dem Gesichtspunkt des kommerziellen Supports ausgewählt wurden. Der Vertrieb erzählt dem Kunden, dass es ja überhaupt kein Problem wäre, nur ein vorkompiliertes Betriebssystem auszuliefern, denn schließlich gäbe es ja den kommerziellen Support, über den man als Kunde ja beliebige Wünsche einkippen kann. Die Praxis sieht leider deutlich anders aus. Schon kleinste Anpassungen sind nicht in den schon horrenden Supportkosten enthalten, sondern kosten natürlich extra. Die Bibliotheken werden natürlich ohne Debug-Symbole ausgeliefert, damit der Kunde kaum eine Chance hat, Fehler zu suchen bzw. zu finden. Bei nachgewiesenen Fehlern heißt es dann, man hätte die Software auf einer nicht durch den OS-Hersteller zertifizierten Hardware eingesetzt. Bei nachgewiesenen Fehlern im Netzwerkstack werden Support und Fehlerkorrektur mit der Begründung abgelehnt, es handele sich auf Seiten des Herstellers um zugekaufte Module, die selbstverständlich vom Support ausgenommen seien. Bei Änderungswünschen heißt es, dass diese zu einer Aufsplitterung der Quellcodebasis führen. Die o.a. Probleme kenne ich sowohl von ENEA bzw. OSE (um 2002) und von Windriver bezüglich VxWorks (2013). ENEA wurde nach einer länglichen gerichtlichen Auseinandersetzung dann irgendwann verurteilt, den Quellcode zu liefern, damit der Kunde die Fehler selbst beheben konnte; allerdings war der Quellcode nicht vollständig, sondern sie lieferten dann einfach nur winzige Codefragmente aus, in denen die konkret reklamierten Fehler waren. Ein anderer Kunde hatte für sehr viel Geld die Anpassung von VxWorks auf den damals neuen Prozessortyp im 64 Bit-Modus beauftragt. Das lief auch soweit ganz gut, so dass die Lieferung auch abgenommen wurde. Später stellte sich dann aber heraus, dass wichtige APIs keine 64-Bit-tauglichen Datentypen unterstützten. Windriver verlangte einen siebenstelligen Betrag(!) für die Erweiterung. Auf eigener Erfahrung kann ich Nucleus PLUS empfehlen. Das gesamte Betriebssystem wird als Quelltext geliefert. Die Anpassungen der Makefiles an die eigene Buildumgebung war auch sehr einfach. Damals(tm), d.h. 1998 oder 1999, war jedoch der TCP/IP-Stack sehr fehlerhaft. Der damalige Hersteller Accelerated Technology (mittlerweile Mentor/Siemens) hatte einfach den damals eigentlich sehr guten kostenlosen NCSA-Telnet-Stack genommen und rudimentär angepasst. Leider berücksichtigten sie dabei nicht, dass auf damaligen ARM-Prozessoren Langwortzugriffe nur auf durch vier teilbaren Adressen zulässig waren. Da ein Ethernet-Header aber 14 Byte lang ist, waren alle Zugriffe auf IP- und TCP-Ebene falsch ausgerichtet. Und die Puffer für Netzwerkpakete wurden auch einfach mittels der normalen dynamischen Speicherverwaltung (NU_Allocate_Memory oder so) angefordert, was in Windeseile zu einer Fragementierung des spärlichen RAMs führte. Auch hier folgte von Seiten ATI die Argumentation, der Stack sei ja nicht selbst entwickelt worden und somit vom Support ausgeschlossen. Und wieso verlangten sie dann rund $20.000 für den eigentlich freien Stack? Letztendlich lief es darauf hinaus, dass ich eine eigene Speicherverwaltung für Netzwerkpuffer schreiben und die Datenstrukturen für TCP, UDP und IP so umbauen musste, dass keine Alignmentprobleme mehr auftraten. Bei OOO-TCP-Paketen kam das ganze aber aus dem Tritt, da die entsprechende Funktionalität zum Umhängen von Pufferketten komplett fehlte. Einige Monate später gab es dann von ATI ein umfangreiches Update mit einerm komplett überarbeiteten Netzwerkstack. Die o.a. Probleme waren darin eigentlich behoben, aber leider war die Pufferverwaltung extrem fehlerhaft. Deswegen blieben wir bei der von mir überarbeiteten Version. Ein generelles Problem solcher Betriebssysteme mit irgendwie rangeflanschtem Netzwerkstack besteht aber oft darin, dass man nicht veranlassen kann, dass beim Beenden einer/s Task/Prozess/Thread die offenen Netzwerkverbindungen automatisch geschlossen werden. Daher muss man ggf. noch einen Wrapper bauen, der den Überblick behält und nur lokal genutzte Verbindungen wieder schließt. Einen anderen wesentlichen Unterschied von Nucleus PLUS zu den meisten anderen Betriebssystemen gilt es auch noch zu beachten: die beim Erzeugen eines Prozesses vergebene PID entspricht der Speicheradresse des zugehörigen Task Control Blocks. Das ist sehr praktisch, weil ohne längliche Suchoperation auf den TCB zugegriffen werden kann; auch das Debugging wird immens vereinfacht. Wenn jedoch ein Prozess beendet und wieder neu gestartet wird, bekommt er wieder dieselbe PID, da der TCB wiederverwendet wird. Damals setzten wir einen SDL-Codegenerator ein, der (bzw. dessen zugehörige Bibliotheken) sich darauf verließ, dass PIDs eindeutig waren bzw. eine Wiederverwendung erst nach Überlauf eines Zählers erfolgt. Das krachte natürlich gewaltig, wenn SDL-Prozesse sofort wieder neu gestartet wurden. Aus diesem Grund erweiterte ich die TCB-Struktur um eine "konventionelle", fortlaufende PID, und die Funktionen in der SDL-Integration schauten dann nicht mehr auf die durch den TCB bestimmte PID, sondern auf die darin enthaltene fortlaufende. Es war ja auch überhaupt nicht erforderlich, nach diesen PIDs suchen zu können, sondern die SDL-Integration machte nur einen einfachen Vergleich, um erkennen zu können, ob ein Prozess neu gestartet wurde. Da das ganze mitterweile rund zwanzig Jahre her ist, gehe ich davon aus, dass ATI/Mentor mittlerweile auch die Probleme mit dem TCP/IP-Stack selbst in den Griff bekommen hat. Ansonsten wäre der Kram heutzutage unverkäuflich. Die Kernaussage ist jedoch: Wer sich auf den teuren kommerziellen Support verlässt, ist verlassen. So etwas in komplett unwägbar, und der Aufwand, um Fehlerkorrekturen oder Anpassungen durchzusetzen, ist meist höher als wenn man es selbst erledigt. Zudem müssen unnötig viele Leute (Einkauf, Rechtsabteilung, usw.) involviert werden. Wenn man es trotzdem nicht selbst machen will, rate ich dazu, ein Betriebssystem zu nehmen, das komplett mit Quelltext geliefert wird, und sich einen mit diesem Betriebssystem erfahrenen externen Entwickler zu suchen, der die Anpassungen usw. wesentlich schneller durchführt. Und wenn derjenige auch ins Projekt komplett einbezogen wird, muss man ihm auch nicht bei jeder Kleinigkeit erklären, worum es überhaupt geht. Die Support-Mitarbeiter der Betriebssystemhersteller interessiert das Kundenprojekt nämlich nicht die Bohne.
:
Bearbeitet durch User
900ss D. schrieb: > Mike schrieb: >> Viel Geld für (*)Null Support und Unterstützung. > > Selten soviel Blödsinn gelesen. Kann aus eigener Erfahrung sagen, dass > Support und Unterstützung recht gut sind wenn man entsprechend zahlt > natürlich. > Aber das wird OT. Aus der Erfahrung meiner Kunden kann ich sagen, dass VxWorks zum Fass ohne Boden wird, wenn man auf Anpassungen durch den Hersteller angewiesen ist.
Andreas S. schrieb: > Ich kenne sowohl von einem früheren Arbeitgeber als auch von etlichen > meiner Kunden die massiven Probleme mit einigen > Betriebssystemherstellern, die vorrangig unter dem Gesichtspunkt des > kommerziellen Supports ausgewählt wurden. Ok, das sind mal echt krasse Erfahrungen, das würde ich mich gar nicht gegenüber meinen Kunden trauen. Ich empfehle immer allen Interessenten auch den Support vor dem Kauf bzw. während der Evaluierung zu testen. Also nicht nur schauen, ob das Produkt passt sondern wie schnell und kompetent ist der Support? Es macht nämlich z.B. keinen Spaß drei Tage auf eine Antwort warten zu müssen und währenddessen nicht weiterarbeiten zu können. > Die Bibliotheken werden > natürlich ohne Debug-Symbole ausgeliefert, damit der Kunde kaum eine > Chance hat, Fehler zu suchen bzw. zu finden. Die embOS Libraries werden auch ohne Debug Informationen gebaut aber das hat einen anderen einfachen technischen Grund. Würde man ansonsten in eine RTOS API Funktion reinsteppen fragen die meisten Debugger nach der Source Datei, die in dem Moment natürlich nicht automatisch gefunden werden kann. Eigentlich sollten Kunden auch nicht in RTOS Libraries Fehler suchen müssen. In dem Fall, wenn man meint etwas funktioniert nicht so, wie erwartet, sollte man den RTOS Hersteller um Hilfe bitten. Und der soll das Problem dann asap lösen, auch wenn das in 99% der Fälle ein Anwendungsfehler ist. Denn auch das hilft dem RTOS Hersteller sein Produkt zu verbessern indem er einen zusätzlichen Debug Check einbauen oder die Dokumentation verbessern kann. Es sollte aber immer auch die Möglichkeit geben den Source Code bekommen zu können. Das hat einfach den Vorteil das man unabhängig ist. Andreas S. schrieb: > Bei nachgewiesenen Fehlern > heißt es dann, man hätte die Software auf einer nicht durch den > OS-Hersteller zertifizierten Hardware eingesetzt. Mich als RTOS Hersteller sollte gar nicht interessieren müssen auf welcher Hardware das RTOS läuft (solange der gleiche Core/Compiler verwendet wird). Wie sollte ich denn auch Kundenhardware zertifizieren können? Andreas S. schrieb: > Die Kernaussage ist jedoch: Wer sich auf den teuren kommerziellen > Support verlässt, ist verlassen. So etwas in komplett unwägbar, und der > Aufwand, um Fehlerkorrekturen oder Anpassungen durchzusetzen, ist meist > höher als wenn man es selbst erledigt. Das würde ich nicht so pauschal sagen aber wie schon gesagt, stimme ich dir zu, dass man guten Support nicht unterschätzen sollte. Denn selbst wenn man fit in RTOS ist, kann während der Entwicklung immer der Punkt kommen, an dem man ein Problem/Frage/Anforderung hat und auf die Hilfe des Supports angewiesen ist.
Til S. schrieb: > Eigentlich sollten Kunden auch nicht in RTOS Libraries Fehler suchen > müssen. In dem Fall, wenn man meint etwas funktioniert nicht so, wie > erwartet, sollte man den RTOS Hersteller um Hilfe bitten. Und der soll > das Problem dann asap lösen, auch wenn das in 99% der Fälle ein > Anwendungsfehler ist. Wenn man eine nagelneue eigene Hardware entwickelt, zeigen sich manche Hardwareprobleme erst bei laufendem Betriebssystem. Einer meiner Kunden beauftragte mich, ihn bei der Fehlersuche im TCP/IP-Stack von Linux zu unterstützen. Wie ich jedoch durch scharfen Blick auf Kernel Oopses, einige Anwendungsfehler und eingebauten Testcode herausfand, war bei korrupten Daten immer entweder Bit 1 oder Bit 17 gesetzt. Nach langen Diskussionen mit dem zuständigen Hardwareentwickler schaute ich dann auf das Leiterplattenlayout, und siehe da: aus Platzgründen war eine Datenleitung des mit 16 Bit angebundenen und 400 MHz getakteten DDRRAMs ganz anders, d.h. mit etlichen Zentimetern Umweg, verlegt als die restlichen Leitungen. Bei einem anderen Projekt gab es sporadisch unerklärliche Abstürze, scheinbar verursacht durch durch falsche Pointerzugriffe o.ä.. Auch hier musste ich das ganze auf sehr, sehr tiefer Ebene debuggen. Die Speicherfehler ließen sich aber selbst mit Write-Watchpoints nicht finden. Nach mehrwöchiger Suche mit Debugger und Logikanalysator fand ich heraus, dass während eines normalen Speicherzugriffs auf das externe SRAM einfach eine neue Adresse angelegt wurde. Es lag also ein Busarbitrierungsfehler vor. Zusammen mit noch einigen anderen Hardwarebugs führte das dazu, dass der Hersteller den Prozessor einstampfte. Bei demselben Projekt gab es aber auch noch andere Speicherfehler, d.h. einzelne Bitkipper. Ebenfalls nach langer Fehlersuche fand ich auch hier die Ursache, nämlich eine Fehlbestückung der SRAMs. Bei einigen, aber nicht allen Bausteinen, wurde irrtümlich die 5V- statt der 3,3V-Variante bestückt. Meistens, aber nicht immer ging das auch gut, so dass es erst recht spät auffiel. Es wäre niemals möglich gewesen, diese Fehler ohne Betriebssystemquellen zu finden. > Es sollte aber immer auch die Möglichkeit geben den Source Code bekommen > zu können. Das hat einfach den Vorteil das man unabhängig ist. Genau. Und da helfen keine vollmundigen Versprechungen der schmierigen Vertriebler, denen nach Vertragsschluss eh alles egal ist, sondern nur Fakten: Quellcode im Lieferumfang und nicht erst bei Problemen. > Mich als RTOS Hersteller sollte gar nicht interessieren müssen auf > welcher Hardware das RTOS läuft (solange der gleiche Core/Compiler > verwendet wird). Wie sollte ich denn auch Kundenhardware zertifizieren > können? Und genau da wären wir bei dem eigentlichen Problem: die Fehler werden zwischen Kunde und Hersteller hin- und hergespielt. Natürlich handelt es sich in den meisten Fällen um Fehler des Kunden. Und auch eine instabile Hardware liegt in der Verantwortung des Kunden. Aber wenn sich der Betriebssystemhersteller in solchen Fällen komplett zurückzieht > Das würde ich nicht so pauschal sagen aber wie schon gesagt, stimme ich > dir zu, dass man guten Support nicht unterschätzen sollte. Denn selbst > wenn man fit in RTOS ist, kann während der Entwicklung immer der Punkt > kommen, an dem man ein Problem/Frage/Anforderung hat und auf die Hilfe > des Supports angewiesen ist. Ein großes Problem bei vielen Unternehmen besteht darin, dass die Entscheidungen für oder gegen bestimmte Lieferanten und deren Produkte völlig unabhängig von deren Eignung für den konkreten Zweck gefällt werden. Bei einem meiner Kunden ist das wichtigste Kriterium für einen Lieferanten, dass er mindestens 5.000 Mitarbeiter hat. Ich habe es dort selbst mitbekommen, dass ein Lieferant aussortiert wurde, weil er bei der Produktpräsentation jedes technische Detail genau erklären konnte. Wir Entwickler waren positiv beeindruckt. Einer der anwesenden Manager meinte in der Nachbesprechung, die beiden Referenten hätten einen nicht hinreichend selbstbewussten Eindruck vermittelt, und das wäre ein Zeichen dafür, dass sie von ihrem eigenen Produkt nicht überzeugt seien. Und wie wir ja auch bei dem TE sehen, will er ja auch Verantwortung deligieren. Ich habe durchaus auch schon Techniker/Entwickler erlebt, die den angeblich so schlechten Herstellersupport vorschieben, um von ihrer eigenen Inkompetenz abzulenken. Begründet wird dies - genau wie beim TE - damit, selbst viel zu qualifiziert zu sein, um sich mit solchen banalen Problemen noch abgeben zu müssen. Ich kann mir sehr gut vorstellen, dass auch Ihr einen Haufen solcher "speziellen" Kunden habt... Ich bin auch sehr vorsichtig gegenüber Neukunden, die schon sehr schnell durchblicken lassen, dass sie eigentlich nur einen Schuldigen für ihr totes Pferd suchen.
Andreas S. schrieb: > ein Betriebssystem zu nehmen Das vxWorks bei uns liegt vollständig im Quelltext vor. Und ja, es stimmt, auch da habe ich schon Fehler gesucht und gefunden. Kochen alle mit Wasser ;) Meine Erfahrungen mit dem Support sind nicht schlecht. Aber es wird nichts verschenkt, dass stimmt.
Andreas S. schrieb: > Und wie wir ja auch bei dem TE sehen, will er ja auch Verantwortung > deligieren. Verantwortung weniger. Ich bin Nicht-Leiter und trage daher nach hausinterner Definition eh keinerlei Verantwortung. Viel mehr Arbeit. Wir haben etwa eine handvoll reine Weichwareentwickler, die Applikationsentwicklung machen, auf Standardhardware und auf selbst entwickelter. Mikrocontroller-Weichware machen bei uns nur genau zwei Leute, wobei einer sich um die ganzen Altlasten kümmert - 8 Bit Zeugs. Ich bin der andere, und ich mache auch noch harte Ware und habe noch einen Kollegen, der vor allem Leistungselektronik macht. Bevor ich gekommen bin, war die Firma mikrocontrollertechnisch eher auf gehobenem Arduino-Niveau, was die Komplexität angeht. Ich war der erste, der solch Teufelszeugs wie PCIe, USB, FPGA, RTOS, 32 Bit Microcontroller mit mehr als 20 MHz etc. angefasst hat. Und ich bin momentan der einzige, der davon Plan hat. Klar kann ich mir da in mühsamer Handarbeit irgendeine Open Source Lösung zusammenbasteln. Ich habe aber einfach nicht die drei bis 6 Monate, die ich für unsere Plattformen dafür realistischerweise benötigen würde. Ich brauche irgend etwas, wo der Inbetriebnahmeaufwand überschaubar ist, um in absehbarer Zeit meinen Berg an Arbeit abarbeiten zu können, und wo die Basisarbeit bereits erledigt ist. So bin ich eben zum TI RTOS gekommen. Die letzte Version für Tiva C ist von 2016. Als ich in den Foren beispielsweise den Haufen an Patches für den Ethernet-Treiber gesehen habe, bin ich bleich geworden. Ich hatte nur Glück, auf keinen der Bugs selber zu stoßen, aber wenn, dann wäre das ein elendiger Kampf geworden, der unmengen Zeit gekostet hätte, die ich eigentlich nicht habe. Und da es seit 4 Jahren keine Bugfix-Version davon gibt, wo die ganzen bekannten Problemlösungen mal eingepflegt werden, bekomme ich so langsam kalte Füße und prüfe meine Optionen. fchk
Andreas S. schrieb: > Es wäre niemals möglich gewesen, diese Fehler ohne Betriebssystemquellen > zu finden. > >> Es sollte aber immer auch die Möglichkeit geben den Source Code bekommen >> zu können. Das hat einfach den Vorteil das man unabhängig ist. > > Genau. Und da helfen keine vollmundigen Versprechungen der schmierigen > Vertriebler, denen nach Vertragsschluss eh alles egal ist, sondern nur > Fakten: Quellcode im Lieferumfang und nicht erst bei Problemen. Ja, solche Hardwarefehler sind echt böse. Wir haben bei solchen Geschichten auch schon viel Zeit investieren müssen bevor wir dem Kunden nachweisen konnten das es an seiner Hardware liegt und nicht an unserer Software. Das kann man aber vorab natürlich nicht wissen so das wir solche Probleme erst einmal untersuchen müssen. Kommt aber auch extrem selten vor. Hatte ich vielleicht in den letzten 14 Jahren nur ein paar Mal. Das sehe ich zumindest bei embOS nicht so als Problem. Wenn ich den embOS Source Code haben möchte kaufe ich den einfach, d.h. beim Kauf entscheide ich mich, ob ich nur die Libraries oder auch den Source Code kaufen möchte. Der Source Code ist natürlich teurer. Dann sollte es auch keine Probleme mit Vertrieblern geben ;-). Unser Konzept ist da eh ein bisschen anders. Ich habe kein Interesse daran einmalig an einem Kunden etwas zu verdienen und ihn dann zu vergraulen sondern die meisten Kunden gehen mit uns eine langjährige Partnerschaft ein. Viele größere Firmen entscheiden sich einmalig für ein RTOS und wechseln das dann auch nicht wieder so schnell. Wenn man als gleichwertige Partner auftritt macht das für beide Seiten mehr Spaß und wir können bei vielen Sachen auch einfach mal kulant sein. Ich weiß ja, wenn ich jetzt dem Kunden weiterhelfe, das er happy ist und auch auch in Zukunft unsere Produkte kauft. Und ich muss auch zugeben...letztlich macht mir das persönlich jede Menge Spaß, vor allem wenn man dann sieht in welchen interessanten Produkten so ein RTOS eingesetzt wird.
Ein Aspekt, den ich man nicht unterschätzen sollte: In einem Projekt hatte ich Probleme im Zusammenspiel mit Compiler, Debugger, RTOS, Hardware. Jeder Lieferant einzeln hat die Schuld auf den anderen geschoben. Dann alles in die Tonne getreten (außer unserer Hardware) und alles von einem (Segger) gekauft. Damit war ein Großteil der Probleme weg. Meist war schnell lokalisiert wer zuständig (Hardware wir, Rest Lieferant). Der Support war auch gut.
Frank K. schrieb: > Bevor ich gekommen bin, war die Firma mikrocontrollertechnisch eher auf > gehobenem Arduino-Niveau, was die Komplexität angeht. Ich war der erste, > der solch Teufelszeugs wie PCIe, USB, FPGA, RTOS, 32 Bit Microcontroller > mit mehr als 20 MHz etc. angefasst hat. Und ich bin momentan der > einzige, der davon Plan hat. Das klingt durchaus plausibel. Bei Deiner o.a. Anfrage hörte es sich aber durchaus so an, als würdest Du zu der anderen Kategorie von Kunden gehören. > Klar kann ich mir da in mühsamer Handarbeit > irgendeine Open Source Lösung zusammenbasteln. Open Source bedeutet nicht das gleich wie ein im Quelltext vorhandenes Betriebssystem eines kommerziellen Anbieters, siehe z.B. das von Til S. genannte embOS. Problematisch ist es jedoch, die Nichtverfügbarkeit des Quellcodes als Qualitätsmerkmal darzustellen, insbesondere wenn die Lieferung auch noch etliche hinzugepfuschte Pakete von Drittanbietern beinhaltet, für die der Anbieter dann trotz teuren Wartungsvertrags keinen Support leisten will. Siehe ENEA/OSE vor etlichen Jahren. Oder eben die vergessenen API-Erweiterungen, die sich Windriver vergolden lassen wollte. > Ich habe aber einfach > nicht die drei bis 6 Monate, die ich für unsere Plattformen dafür > realistischerweise benötigen würde. Ich brauche irgend etwas, wo der > Inbetriebnahmeaufwand überschaubar ist, um in absehbarer Zeit meinen > Berg an Arbeit abarbeiten zu können, und wo die Basisarbeit bereits > erledigt ist. Dann wäre doch SEGGER der richtige Lieferant für Euch. Kein aufgeblasener Geldschneider, Quellcode für moderaten Aufpreis erhältlich, Support gleich um die Ecke. Wenn Du jemanden suchst, der ein wie auch immer geartetes Betriebssystem (mit Quelltext) auf Eurer Hardware zum Laufen bringt, kann ich Dir diese Leistung auch anbieten. Wie Du meinen vorherigen Ausführungen entnehmen kannst, habe ich auch etliche Erfahrungen mit "technischen Härtefällen". > So bin ich eben zum TI RTOS gekommen. Die letzte Version für Tiva C ist > von 2016. Als ich in den Foren beispielsweise den Haufen an Patches für > den Ethernet-Treiber gesehen habe, bin ich bleich geworden. Ich hatte > nur Glück, auf keinen der Bugs selber zu stoßen, aber wenn, dann wäre > das ein elendiger Kampf geworden, der unmengen Zeit gekostet hätte, die > ich eigentlich nicht habe. Und da es seit 4 Jahren keine Bugfix-Version > davon gibt, wo die ganzen bekannten Problemlösungen mal eingepflegt > werden, bekomme ich so langsam kalte Füße und prüfe meine Optionen. Immerhin gibt es solche Patches. Es gibt auch Anbieter, die Fehlerkorrekturen mit der Begründung ablehnen, das Produkt sei ja schon nach XYZ "zertifiziert" und dürfe deswegen auch nicht mehr geändert werden. (Atmels offizielle Stellungnahme zu Fehlern im AT91RM9200). Und was dem Kunden überhaupt einfalle, dem "zertifizierten" Produkt irgendwelche Mängel zu unterstellen. Im Zweifelsfall wird die Rechtsabteilung losgeschickt, um den Entdecker solcher Fehler davon abzuhalten, die Fehler öffentlich zu machen (Sharp LH79402: Sharp bot uns nach Prüfung meiner länglichen Fehlerliste an, nach Unterzeichnung eines NDA mit wichtigen Informationen zu dem Prozessor zu versorgen. Wir unterzeichneten das NDA, und deren knappe Antwort lautete sinngemäß: "Wir stellen das Produkt ein, haben unsere inkompetenten Entwickler in den USA entlassen, und Ihr dürft nicht herumerzählen, welche Scheiße wir gebaut haben." Ich sehe mich mittlerweile nicht mehr an das NDA gebunden, zum einen, weil es schon ewig her ist, und zum anderen, weil es uns mit einem gänzlich anderen Versprechen abgerungen wurde.)
Wenn RTOS und Schnittstellen vorrangig sind, dann würde ich genau da ansetzen und nicht das Pferd von hinten aufzäumen. Also erstmal die optimale Entwicklungsumgebung suchen und zum Schluß die CPU, die dazu optimal paßt. Wenn man sich gleich auf eine bestimmte CPU versteift, dann wird man immer wieder Kompromisse eingehen müssen. Der CPU-Typ ist heutzutage nebensächlich und kostenmäßig scheinst Du ja auch keine Bindung an alte Programmiertools zu haben.
Wenn ich mir deine Schnittstellen/Anwendungs Liste so anschaue was du alles haben möchtest, stellt sich mir die Frage ob für die ganzen HighEnd kram eine Linux Platform interresanter währe? wobei das als one man show mit HW schon heftig wird. Die ganzen Netzwerk Protokolle und Dienste die du oben aufgeschrieben hast krigst du alle für fast umsonst und noch jede menge mehr. Ja es gibt keinen support vom hersteller, da es keinen hersteller gibt. aber eine grosse gemeinde die den code pflegt, vorausgesetzt man hat nicht den exoten unter den exoten ausgewählt. und zur not gibt es externe die dir gerne gegen geld beim Fehler fixien helfen. (und davon gibt es genut) Ist halt die Frage wie viel echte RealTime ihr braucht. Und es gibt auch durchaus Bausteine die neben dem Dickschiff (Cortex Ax) noch ein kleines Beiboot (Cortex Mx) haben. (STM32MP1, ab IMX6, Sitara, ...)
Peter D. schrieb: > Wenn RTOS und Schnittstellen vorrangig sind Es sollte immer zuerst das geeignete RTOS gewählt werden, und dann kann man sehen, welche Hardware gut unterstützt wird. Wenn für Sitara AM5728 und NXP i.MX6 und Pi CM3+ unter RISC OS alle Treiber vorhanden und getestet sind, dann muss ich ja nicht unbedingt Experimente mit AM6528 oder i.MX8 oder Pi 4 machen, nur weil die ganz toll neu sind. Mal abgesehen davon ist für den Frager vielleicht doch eine SPS auf Pi CM3+ oder i.MX6 Basis am günstigsten: https://revolution.kunbus.de/ https://www.stv-electronic.de/produkte/automatisierungstechnik/linux-controller/ https://www.controllino.biz/myplc/
123 schrieb: > Wenn ich mir deine Schnittstellen/Anwendungs Liste so anschaue was du > alles haben möchtest, stellt sich mir die Frage ob für die ganzen > HighEnd kram eine Linux Platform interresanter währe? wobei das als one > man show mit HW schon heftig wird. Linux kennen wir, haben wir und nutzen wir, aber das ist eine andere Klasse. Für gewisse Sachen ist Linux einfach zu fett, und für externes RAM und Bootmedien ist der Platz einfach nicht da. Echtzeitig muss es auch sein, und innerhalb weniger ms nach dem Power-on laufen und die Hardware initialisiert haben. Außerdem habe ich dann ernsthafte Probleme, aktuelle Linux-Hardware auf der gleichen Leiterplatte wie die Leistungselektronik daneben mit 105u Kupfer und Stromstärken von >50A unterzubringen. Ein TQFP64 im 0.5mm Raster geht noch problemlos, nur die Vias werden dann etwas unhandlich bei Restringen von min. 0.25mm. Die Frage war berechtigt, aber die Antwort lautet: nein, ist nicht, geht nicht, keine weitere Diskussion. fchk
Ok verstanden, Nachfolgendes zur Info: Es gibt Modul Moudle Hersteller, die dir das ganze auf ein paar quadrat cm zusammen dampfen mit ggf brauchbaren Pinning. Um DDR, Flash, PMIC, HF routing, ... braucht man sich dann nicht zu kümmern alles on "CHIP" bzw "Module" z.B. https://octavosystems.com/octavo_products/osd32mp15x/ Ihr solltet euch auch überlegen ob Ihr eure MCU auswahl nicht ausdünnen könnt. Hintergrund ist für jede HW / IP block braucht ihr einen entsprechenden LowLevel Treiber den Ihr zusätzlich bezahlen Müsst. Ihr zahlt dann den USB LL Treiber für jede zusätzliche Platform. Und die Qualität kann beim gleichen Hersteller durchaus von Platform zu Platform schwanken, je nach dem wie viele User den schon einsetzen oder ob der für euch neu entwickelt wurde. Das gleiche beim RTOS selber, jede MCU architektur muss separat Lizenziert und bezahlt werden. Zumindest kenn ich es nur so von den grossen. Oder noch besser es wird Projekt spezifisch Lizenziert, ... Beim nächsten Projekt mit ähnlichen RTOS anforderungen muss man das ganze noch mal Lizenzieren und bezahlen. Das kann ggf noch teurer werden, ...
123 schrieb: > Das gleiche beim RTOS selber, jede MCU architektur muss separat > Lizenziert und bezahlt werden. Zumindest kenn ich es nur so von den > grossen. Oder noch besser es wird Projekt spezifisch Lizenziert, ... > Beim nächsten Projekt mit ähnlichen RTOS anforderungen muss man das > ganze noch mal Lizenzieren und bezahlen. Das kann ggf noch teurer > werden, ... Ich kann jetzt wieder nur vom embOS reden aber da ist es tatsächlich so, dass es nicht das eine embOS gibt. Jede Portierung für eine beliebige Core/Compiler Kombination ist ein separates Produkt. Zum Beispiel ein embOS für Cortex-M und GCC kann ich auf jedem Cortex-M Device laufen lassen. Ein embOS für PIC32 und dem XC32 Compiler läuft nur auf einem PIC32. Wenn ich beide Cores einsetzen möchte brauche ich zwei embOS Ports, die ich separat lizenzieren muss. https://www.segger.com/products/rtos/embos/supported-cores-compiler/embos-ports-overview/ Wieso gibt es die unterschiedlichen embOS Ports und nicht ein embOS, das alles unterstützt? Während 99% eines RTOS in C geschrieben sind, und auf jedem Core und mit jedem Compiler funktioniert, ist ein kleiner Teil Core und Compiler abhängig. Bei über 80 embOS Ports würde das ansonsten sehr unhandlich werden (vor allem für den RTOS Hersteller ;-) ). Letztlich macht das auch kommerziell Sinn da man als Kunde ansonsten die 79 übrigen embOS Ports mit bezahlt obwohl man nur z.B. ein embOS Cortex-M GCC nutzt.
Til S. schrieb: > Ich kann jetzt wieder nur vom embOS reden aber da ist es tatsächlich so, > dass es nicht das eine embOS gibt. Jede Portierung für eine beliebige > Core/Compiler Kombination ist ein separates Produkt. Eher ein Grund, die Finger davon zu lassen, oder?
Olf schrieb: > Eher ein Grund, die Finger davon zu lassen, oder? Wieso? Ich denke aus technischer Sicht macht das schon Sinn in dem Shipment nur die Sachen drin zu haben, die ich brauche. Wofür brauche ich in einem Cortex-M Shipment Dateien für einen M16C? Das macht es nicht übersichtlicher. Von der kommerziellen Seite könnte man jetzt meinen das es teurer sei die embOS Ports einzeln lizenzieren zu müssen. Aber wie teuer soll dann ein Gesamtpaket sein, in dem > 80 embOS Ports sind? Das wäre so als müsste ich beim VW Händler den ganzen Ausstellungsraum leer kaufen obwohl ich nur einen Golf haben möchte. Das es natürlich auch anders geht zeigt FreeRTOS. Ich finde die Sortierung dort nicht schlecht auch wenn man das vom Konzept her nicht ganz mit embOS vergleichen kann.
Olf schrieb: > Til S. schrieb: >> Ich kann jetzt wieder nur vom embOS reden aber da ist es tatsächlich so, >> dass es nicht das eine embOS gibt. Jede Portierung für eine beliebige >> Core/Compiler Kombination ist ein separates Produkt. > > Eher ein Grund, die Finger davon zu lassen, oder? Wenn alle Portierungen gleiche APIs und Konzepte verwenden, ist das doch alles kein Problem. Ich habe neulich in der embOS-Kompatibilitätsliste sogar etliche ur-uralte unterstützte Plattformen gesehen. Es wäre wenig sinnvoll, all diese "Altlasten" in einem generischen Betriebssystem mitschleppen zu müssen. Wenn ich mir so manche lange gewachsenen Softwarepakete anschaue, sind diese doch aus Kompatibilitätsgründen völlig unübersichtlich geworden. Und wenn man dann in solch einem Grab aus Präprozessordefinitionen usw. einen Fehler finden und beheben muss, ist die Wahrscheinlichkeit sogar sehr hoch, dass es dabei gar nicht um die eigene Plattform geht. Ich gehe aber auch schwer davon aus, dass Segger großenteils auf einer gemeinsamen Codebasis aufsetzt und nicht 80 separate Entwicklungen pflegt.
Andreas S. schrieb: > Wenn alle Portierungen gleiche APIs und Konzepte verwenden, ist das doch > alles kein Problem. Ja, natürlich. Die API ist immer identisch bzw. kompatibel. Ich kann im Prinzip eine 20 Jahre alte M16C Applikation ohne Änderungen auf einem aktuellen embOS Cortex-M laufen lassen. Andreas S. schrieb: > Ich gehe aber auch schwer davon aus, dass Segger großenteils auf einer > gemeinsamen Codebasis aufsetzt und nicht 80 separate Entwicklungen > pflegt. Genau, die gemeinsame Codebasis nennt sich bei embOS "generische Sourcen" bzw. der Verzeichnisname "GenOSSrc". Das sind die embOS C Sourcen, die für alle embOS Ports identisch sind und machen ~99% von einem embOS Port aus. Der Core und Compiler spezifische Teil bestehlt aus ein bisschen Assembler Code, ein paar Core spezifischen C Funktionen und zwei Header Dateien, die Core/Compiler spezifische Settings setzen. Die generischen Sourcen werden weiter entwickelt und neue Features hinzugefügt bzw. Fehler korrigiert. Mit einer neuen Version dieser generischen Sourcen können dann die einzelnen embOS Ports upgedatet werden.
Ich würde hier, gerade angesichts der Forderung nach USB- und IP-Stacks, mal NuttX in die Runde werfen, das läuft nämlich auf so ziemlich allem von ARM9 bis Z-80. Stacks für USB und IPv6 sind vorhanden, ebenso wie ein POSIX-Interface und verschiedene Dateisysteme. Google (Project Ara), Samsung (TizenRT), Sony und die ETH Zürich (PX4) nutzen es, kann also nicht sooo übel sein, oder? Es kommt eben darauf an was man will bzw. braucht. Unter NuttX ist die Hardware halt relativ stark in High- und Low-Level-Treiber gekapselt und sofern es die Low-Level-Treiber noch nicht gibt, muss man die halt schreiben, was nicht sooo trivial ist. Zugegebenermaßen kenne ich außer Gregory Nutt (dem Schöpfer von NuttX) keine Firma die kommerziellen Support bietet. Es liegt aber alles im Quellcode vor (BSD- bzw. seit neuestem Apache-Lizenz) und du kannst es ausprobieren um es auch ggf. mit anderen Kandidaten zu vergleichen. Ich kenne aber kein anderes RTOS, welches so dermaßen stark an Linux bzw. UNIX angelehnt ist und dementsprechend einfach ist es damit wirklich komplizierte Sachen hinzubekommen. Z.B. einen USB-Stick per USB-Host bzw. OTG anbinden und dann mittels BSD-Sockets eine Datei aus dem Netz laden und auf dem Stick speichern ist wirklich ein Kinderspiel (vorausgesetzt die Low-Level-Treiber sind schon vorhanden), weil halt quasi wie unter Linux .
:
Bearbeitet durch User
Noch ein Nachtrag zu WindRiver und vxWorks: WindRiver wurde ja von Intel geschluckt und die haben daraufhin Zephyr auf den Markt der Open-Source RTOS geschmissen. Wenn man so will, bekommt man mit Zephyr jetzt ein leicht abgewandeltes vxWorks in neuer Verpackung und das unter Apache-Lizenz. Zephyr macht auf mich auf den ersten Blick auch gar keinen so üblen Eindruck und es lehnt sich wie bei NuttX alles sehr stark am Linux- bzw. Unixumfeld an. Habe damit aber noch nicht so viel gemacht, lediglich bisschen mit rumgespielt. Habe eben nochmal deine Anforderungsliste durchgelesen und bin dabei auf die Angabe mit "vor deiner Zeit, etwa Arduinolevel" gestoßen. Wie lange ist das denn jetzt her? So wie sich das anhörte möchtest du ja eigentlich Arbeit abgenommen bekommen, weil die Todo-Liste schon ohnehin zu lange ist. Dann bist du vermutlich bei Segger oder Keil besser dran. Die Entscheidung mit PIC32 und Cortex-M parallel zu fahren kostet dann bei Segger entsprechend doppelt, das muss man sich dann eben überlegen ob das Sinn macht. Sich mit Keil bzw RTX auf Cortex-M festzunageln wäre mir persönlich aber auch nicht so ganz geheuer, wenn auch besser als mit TI-RTOS sich an einen einzelnen Hersteller zu binden.
Christopher J. schrieb: > Die Entscheidung mit PIC32 und Cortex-M parallel zu fahren kostet dann > bei Segger entsprechend doppelt, das muss man sich dann eben überlegen > ob das Sinn macht. Einfacher ist das natürlich bei einem Core zu bleiben, aber ansonsten ...mit uns kann man reden ;-). Bis jetzt haben wir immer eine Lösung gefunden, die für beide Seiten passt. Man muss aber auch sehen, das wir hier von "nur" 5 KEuro für Cortex-M und PIC32 reden (Object Code, Singe Developer oder Single Product Lizenz). Ob das im Budget ist kommt natürlich auf das konkrete Projekt an. Für eine 1 Mann Firma mit wenigen Stückzahlen pro Jahr ist das viel Geld aber für einen Konzern mit größeren Stückzahlen eher Peanuts. Fairerweise musst man noch die weitere Embedded Software wie USB oder Filesystem dazurechnen da embOS nur das reine RTOS ist.
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.