Hallo, nervt es euch eigentlich auch, wenn man einen neuen Controller einsetzen will oder muss und dann alles anders ist? Schon beim Messen einer Spannung beginnt das Trial-and-Error. Es gibt zwar eine Bibliothek, die kann aber fast nichts. Sie kann nur ssynchrones Lesen der ADC. Der Befehl startet die Wandlung und hält den gesamten Programmablauf bis zur Fertigstellung an. Asynchrone Programmierung mit callbacks? Fehlanzeige! Also muss man wohl doch in die 2000 des Datenblatte schauen. Nun wird es umständlich. Man muss in vielen Registern irgendwas einstellen. Vorteiler für den internen ADC-Takt, Referenzspannungsquelle, Triggerquelle für Sample-and-Hold. Man glaubt zwar, man hat alles richtig eingestellt, doch es passiert nichts... Nach Stunden oder Tagen an Lesen und Suchen, bemerkt man noch: Da muss der ADC in einem Power-Management-Subsystem aktiviert werden. Das gleiche gilt für die Referenzspannungsquelle. Dann ist da noch die Stromversorgung für den ADC, die neben extern auch intern generiert werden kann, allerdings muss eine Variante ausgewählt und diese aktiviert werden. Dann hat noch in einem weiteren Register die Pinkonfiguration gefehlt. Nein, die Auswahl des Pins in der ADC-Konfiguration reicht nicht. Er muss noch explizit als analog-in konfiguriert werden und das analog-subsystem für den Port aktiviert werden. Eigentlich müsste es jetzt gehen. OK, doch nicht. Es ist doch ganz logisch, dass das nicht funktionieren kann, denn man kann doch nicht einfach so in irgendwelche Register herumschreiben, das ist viel zu unsichtbar. Diese SFRs dürfen ja nicht von einem Anwendungsprogramm geschrieben werden, sondern nur von einem Treiber, der wieder anderes nicht darf. Man muss also nur noch das Prozesskontextregister richtig setzen, welches allerdings nur wirksam wird, wenn ein spezieller Unterprogrammaufruf erfolgt, und zwar zu einem Programmsegment, welches vorher gewhitelistet wurde. Und nein, dieses Programm darf zwar den ADC konfigurieren, aber keine Werte auslesen. Das muss in einem anderen Programmkontext erfolgen... Ich fände es schön, wenn man diese Peripherie als formales Modell beschreiben würde. Man könnte dann die Entwicklungsumgebung fragen, warum etwas so ist bzw. was noch geändert werden müsste, dass ein gewünschter Zustand eintritt. Der Constraint-Solver würde dann zeigen, welche Einstellungen das Ergebnis beeinflussen oder einen minimalen Programmcode generieren, der die erforderlichen Einstellungen vornimmt. Was gibt es in dem Bereich bereits? Würdet ihr das nutzen? Würde das überhaupt eine relevante Nutzerzahl erreichen?
> Ich fände es schön, wenn man diese Peripherie als formales > Modell beschreiben würde. Dazu müsste es eine allgemein verstandene Sprache zur Modellierung geben. Stefan H. schrieb: > Man könnte dann die Entwicklungsumgebung fragen, > warum etwas so ist bzw. was noch geändert werden müsste, dass ein > gewünschter Zustand eintritt. Klingt nach KI-Bullshit, auch wenn Du das als "Constraint-Solver" bezeichnest. Vielleicht ist Töpfern oder Makramee doch besser?
Ich kann mir ja auch nicht einen Haufen Baumaterial auf den Hof legen und dann mein Werkzeug fragen was fehlt damit daraus ein Haus wird.. Nein, dafür Brauch ich dann eben Leute die wissen wie es geht und das können haben das in die Tat umzusetzen. Und die haben das wissen auch nicht seit geburt, sondern im Laufe ihres Lebens mühsam erworben. Dafür haben sie dann jetzt etwas womit sie ihren Lebensunterhalt bestreiten können.
Stefan H. schrieb: > Ich fände es schön, wenn man diese Peripherie als formales Modell > beschreiben würde. Wer soll das machen? Der Controller-Hersteller, der nichtmal dazu in der Lage ist eine vernünftige Bibliothek in C zu implementieren? Stefan H. schrieb: > Es gibt zwar eine Bibliothek, die kann aber fast nichts. Ich denke, viel sinnvoller wäre es, wenn die Industrie sich irgendwann mal auf einheitliche Standards zur Integration und API von solchen Bibliotheken einigen würde. Momentan weiß es halt jeder Hersteller besser der Rest der Welt. Dann wäre ein derart komplexer und exotischer Ansatz, der dabei hilft dass jeder seinen eigenen Treiber einfach implementieren kann, hinfällig. Zephyr wäre vielleicht ein Anfang.
Stefan H. schrieb: > und dann alles anders ist? Genau dadurch unterscheiden sich die Hersteller der MCUs, die man so auf dem Markt bekommt. Jeder funktioniert etwas anders, und jeder hat seine speziellen Eigenheiten für besondere Anwendungsfälle. Daher muss man sich die MCU ja auch passend aussuchen. Wären alle gleich, wären alle austauschbar. Und das wollen die Hersteller natürlich auch nicht :-) Im Bereich Arm Cortex-M gibt es die CMSIS(-driver). Aber auch hier wird nur ein Basissatz an Funktionen über HAL Librarties abgedeckt, um Funktionen wie FS, USB, ETH etwas generischer ansaften zu können. Alles wird man nie generalisieren können, denn genau für verschiedene Anwendungsfälle dieser kleinen Käfer gibt es diese Unterschiede.
Random .. schrieb: > Wären alle gleich, wären alle austauschbar. Da immer wieder neue Peripherie oder erweiterte Peripherie dazukommt, ist das eh' nicht gegeben. Und das ist auch gut so, daß selbst so etwas "simples" wie z.B. UARTs sich im Laufe der Jahre weiterentwickelt haben.
Stefan H. schrieb: > Würdet ihr das nutzen? Zur Zeit führt kein vernünftiger Weg am Studieren von Datenblatt, Reference Manual und Errata vorbei, ganz egal ob und welche Bibliotheken und Code-Generatoren du verwendest. Wer dazu keine Lust hat, sollte such ein anderes Hobby (bzw. Beruf) wählen.
> nervt es euch eigentlich auch, wenn man einen neuen Controller einsetzen > will oder muss und dann alles anders ist? Nein. Eigentlich finde ich sowas sogar intellektuell anregend. > Ich fände es schön, wenn man diese Peripherie als formales Modell > beschreiben würde. DAs ist ja sogar so. Die Hersteller beschreiben ihre Perpherie als Verilog-Source. Aber den hast du ja nicht. Allerdings kannst bei unterschiedlichen Controllern eines Herstellers oftmals dieselbe Peripherie vorfinden. > Ich denke, viel sinnvoller wäre es, wenn die Industrie sich irgendwann > mal auf einheitliche Standards zur Integration und API von solchen > Bibliotheken einigen würde. Das geht nicht. Weil jeder komplett unterschiedliche Vorstellungen hat was an seinem Zielsystem besonders zu sein hat. Und nur ein paar kleine Bastelbuden oder Studenten nutzen ueberhaubt von Herstellern bereitgestellten Bibliotheken. Man kuckt da vielleicht mal rein, aber im eigentlichen Projekt wirst du das nicht wiederfinden. Vor allem die Entschuldigung fuer Bibliotheken ist ja, wie man sehr schoen an deinem Posting merkt, die Faulheit der Menschheit. Es soll schnell und einfach gehen. Aber wenn da mal irgendwo ein Bug drin ist? Findest du den dann noch? Wenn er nur auftritt wenn drei Bibliotheken gerade zusammen in deinen Projekt sind? Nur bei einem speziellen Typ eines Controllers weil da ein Flag irgendwo falsch ist? Da ist die Kacke dann schnell am dampfen. :-D Vanye
Niklas G. schrieb: > Ich denke, viel sinnvoller wäre es, wenn die Industrie sich irgendwann > mal auf einheitliche Standards Träum weiter. Standards sind antiproduktiv und antiinovativ. DIY. Stefan H. schrieb: > nervt es euch TLDR, schreib ein Roman und erzähls deinem Frisör.
:
Bearbeitet durch User
Monk schrieb: > Wer dazu keine Lust hat, sollte such > ein anderes Hobby (bzw. Beruf) wählen. Ich hab' schon Makramee und Töpfern vorgeschlagen. Gerade Makramee war so lange als langweiliger Scheiß verschrieen, daß es -zusammen mit Batik- eigentlich spätestens nächstes Jahr der neue heiße Scheiß der Generation Z werden müsste.
Vanye R. schrieb: > Das geht nicht. Weil jeder komplett unterschiedliche Vorstellungen hat > was an seinem Zielsystem besonders zu sein hat. Naja, viele Aspekte sind übertragbar. Gerade auch weil Peripherieblöcke zwischen Herstellern oft gleich sind (weil sie z.B. von Synopsys sind). In Sonderfällen kann man immer noch manuell eingreifen. Vanye R. schrieb: > Und nur ein paar kleine > Bastelbuden oder Studenten nutzen ueberhaubt von Herstellern > bereitgestellten Bibliotheken. Kannst du ein paar professionelle Firmen nennen, welche für komplexe Embedded-Software keine Bibliotheken nutzen? Also Peripherie-Ansteuerung, Protokollstacks (USB, TCP/IP, 4G, WiFi, CANopen, ...), RTOS für die Anwendung spezifisch implementieren? Allein schon sowas banales wie das Timing vom I²C der modernen STM32 zu konfigurieren ist total lästig. Hab gar keine Lust da Stunden drauf zu verschwenden, wenn die Bibliothek das einfach so macht. Und so exotisch ist die Ansteuerung eines Temperatursensors per I²C jetzt auch nicht, dass ich da manuell was "optimieren" müsste. Ach warte, das ist die Art von Code die man sich heutzutage von KI generieren lässt, dann braucht man auch keine Bibliothek mehr!
:
Bearbeitet durch User
Zumindest STM liefert doch genau dafür die HAL. Die ist zwar nicht schnell und ziemlich bloated, aber genau deswegen deckt sie schon einige Szenarien ab und geht auch meistens und zumindest einen Referenzcode hat man damit schon mal. Aber ja, den Verilog/VHDL Code des Herstellers hätte ich trotzdem gerne und dann könnte damit eine KI auch mehr tun als nur das Datenblatt interpretieren. Ein Beschleuniger ist ChatGPT da jetzt schon, aber eben keine Universallösung: Von 2023: How do I program timer1 of the STM32L452 for generating a PWM signal on one pin without using the library provided by ST?
1 | RCC->APB2ENR |= RCC_APB2ENR_TIM1EN; |
2 | // Assuming the PWM pin is GPIOx_PINx |
3 | GPIOx->MODER &= ~(GPIO_MODER_MODEy_Msk << (2 * PINy)); |
4 | GPIOx->MODER |= (GPIO_MODER_MODEy_1 << (2 * PINy)); // Set pin to alternate function mode |
5 | GPIOx->AFR[PINy >> 3] &= ~(0xFU << (4 * (PINy & 0x07))); |
6 | GPIOx->AFR[PINy >> 3] |= (GPIO_AFx_TIM1 << (4 * (PINy & 0x07))); // Set alternate function for the pin |
7 | |
8 | TIM1->CR1 &= ~TIM_CR1_CEN; // Disable the timer |
9 | |
10 | // Set the prescaler value |
11 | TIM1->PSC = (prescaler - 1); // Adjust prescaler value as needed |
12 | |
13 | // Configure the timer mode |
14 | TIM1->CR1 = (0 << TIM_CR1_CKD_Pos) | TIM_CR1_ARPE; // Set clock division to 1 and enable auto-reload preload |
15 | TIM1->CR2 = 0; // Default value |
16 | |
17 | // Set the PWM mode |
18 | TIM1->CCMR1 = (6 << TIM_CCMR1_OC1M_Pos); // PWM mode 1 on channel 1 |
19 | TIM1->CCMR1 |= TIM_CCMR1_OC1PE; // Enable preload register for channel 1 |
20 | TIM1->CCER |= TIM_CCER_CC1E; // Enable output for channel 1 |
21 | |
22 | TIM1->ARR = (period - 1); // Adjust period value as needed |
23 | TIM1->CCR1 = (dutyCycle * period) / 100; // Set the initial duty cycle (percentage) |
24 | |
25 | TIM1->EGR = TIM_EGR_UG; // Generate an update event to load the new settings |
26 | TIM1->CR1 |= TIM_CR1_CEN; // Enable the timer |
Funktionierte leider nicht. Es fehlte eine Zeile, die ich nach Lesen des Datenblatts gefunden hatte:
1 | TIM1->BDTR |= TIM_BDTR_MOE; |
Aber immherhin, hätte ich alles manuell recherchiert, hätte ich länger gebraucht.
Stefan H. schrieb: > nervt es euch eigentlich auch, wenn man einen neuen Controller einsetzen > will oder muss und dann alles anders ist? Nö, dann schau ich auf meinen Gehaltszettel und denke mir, na ja dafür wirst du bezahlt, mach mit einen Tee und melde mich zum umfangreichen Handbuchstudium ab.
Stefan H. schrieb: > nervt es euch eigentlich auch, wenn man einen neuen Controller einsetzen > will oder muss und dann alles anders ist? Warum musst du einen neuen Controller einsetzen, wenn sie aus deiner Sicht am liebsten alle gleich sein sollen? Du Unterschiede entstehen daraus, dass sie unterschiedlich sind und jeder Hersteller seine eigene Vorgehensweise hat, um dies umzusetzen.
> Warum musst du einen neuen Controller einsetzen, wenn sie aus deiner > Sicht am liebsten alle gleich sein sollen? Verdammt! Deine Argumentation ist so gut das ich mich jetzt aerger da nicht selber drauf gekommen zu sein. :-D Vanye
Rainer W. schrieb: > Warum musst du einen neuen Controller einsetzen, wenn sie aus deiner > Sicht am liebsten alle gleich sein sollen? Dass sie gleich sein sollen, habe ich nie behauptet! Vielleicht gibt es auch andere Gründe einen anderen Controller zu nehmen, z. B. Zertifizierungen, Verfügbarkeit, Gehäuse, Portanzahl, Preis, rechtliche Gründe, Long-Term-Support. Viele Argumente klingen hier so, als wäre es Hobbybastelei und die Personen würden damit beruflich gar nicht in Kontakt kommen.
Stefan H. schrieb: > Schon beim Messen einer Spannung beginnt das Trial-and-Error. Kommt ganz drauf an, ob der µC Unmengen an Bells & Whistles haben muß. Z.B. beim ATmega1284 umfaßt die Beschreibung der 6 ADC-Register 5 Seiten und damit ist alles komplett. Nach vielleicht 10min sollte der ADC laufen. Trial and Error müßte unnötig sein, es sei denn, das Datenblatt ist Rotte.
Stefan H. schrieb: > Also muss man wohl doch in die 2000 des Datenblatte schauen. Nun wird es > umständlich. Man muss in vielen Registern irgendwas einstellen. > Vorteiler für den internen ADC-Takt, Referenzspannungsquelle, > Triggerquelle für Sample-and-Hold. Ja, wer das Datenblatt (-lesen) nicht ehrt, ist die Elektronik nicht wert! > > Man glaubt zwar, man hat alles richtig eingestellt, doch es passiert > nichts... Ja mit Halbwissen und Rumgestümpere ohne Plan vom Hardware-Debugging kommt man in modernen Zeiten nicht weit. Ok, man kann sich Idiotengerecht aufbereitetes Spielzeugs wie einem Experimentierset für die Schule bspw. https://calliope.cc/ zuwenden. > Was gibt es in dem Bereich bereits? Studiumsangebote im Bereiche Technische Informatik, Embedded, oder gleich Informationstechnik-Elektrotechnik. Oder wie Oma sagte "Ohne Fleiß, keinen Preis".
:
Bearbeitet durch User
Bradward B. schrieb: > Ja, wer das Datenblatt (-lesen) nicht ehrt, ist die Elektronik nicht > wert! Was, wenn das Datenblatt nur minimal ist und man die Bibliothek des Herstellers nutzen muss um es zum laufen zu bringen?
Niklas G. schrieb: > Bradward B. schrieb: >> Ja, wer das Datenblatt (-lesen) nicht ehrt, ist die Elektronik nicht >> wert! > > Was, wenn das Datenblatt nur minimal ist und man die Bibliothek des > Herstellers nutzen muss um es zum laufen zu bringen? Dann hat man sich in die Abhängigkeit eine Herstellers mit propietärer Schnittstelle begeben. Wahrscheinlich wird die Ersparnis beim Preis dieses speziellen Controllers durch die Supportkosten mehrfach aufgefressen. Natürlich kann man diesem Hersteller gehörig auf den Sack gehen, bis der das komplette Datenblatt rausrückt resp. seine Dokumentationspflichten erfüllt. Oder man wechselt zu einen Controller, bei dem die nötigen Informationen ohne viel Sperenzien verfügbar sind.
Bradward B. schrieb: > Oder man wechselt zu einen Controller, bei dem die nötigen Informationen > ohne viel Sperenzien verfügbar sind. Was wenn es keinen solchen gibt? z.B. WiFi-Peripherie oder 3D-Beschleuniger sind m.W. nie dokumentiert. Bradward B. schrieb: > Dokumentationspflichten Aus welchem Gesetz kommt diese Pflicht?
Niklas G. schrieb: > Bradward B. schrieb: >> Ja, wer das Datenblatt (-lesen) nicht ehrt, ist die Elektronik nicht >> wert! > > Was, wenn das Datenblatt nur minimal ist und man die Bibliothek des > Herstellers nutzen muss um es zum laufen zu bringen? Dann sollte die Wahl genau dieses Herstellers auf irgendwelchen anderen Ebenen dermassen grosse Vorteile haben, dass das diesen Malus ueberkompensiert. Sonst ist die Wahl dieses Herstellers einfach in die Hose gegangen. Gruss WK
Niklas G. schrieb: > Bradward B. schrieb: >> Dokumentationspflichten > > Aus welchem Gesetz kommt diese Pflicht? Ich bin Kunde. Also bin ich König. Da brauchts nicht extra noch ein Gesetz.
Dergute W. schrieb: > Dann sollte die Wahl genau dieses Herstellers auf irgendwelchen anderen > Ebenen dermassen grosse Vorteile haben, dass das diesen Malus > ueberkompensiert Ich finde, die Bibliothek des Herstellers zu nutzen, ist kein übergroßer Malus. Axel S. schrieb: > Ich bin Kunde. Also bin ich König Hast du das mal einem Hersteller gesagt? Was hat er geantwortet?
:
Bearbeitet durch User
> Bradward B. schrieb: >> Dokumentationspflichten > > Aus welchem Gesetz kommt diese Pflicht? Aus deinem Arbeitsvertrag o.ä., resp. dem Werkvertrag. Das ein produkt nur so gut ist wie deren Dokumentation muss man doch hier noch nicht erneut ausführlich darlegen. OK, bei Kunstwerken und Speilzeug für Kleinstkinder mag das anders sein, aber ein gerade ein komplexes Hi-Tech Produkt ist eine Dokumentation unbenutzbar. Da hilft auch ein Chat-GPT außer heuchelung von Emapathie und (tröstender) Phrasen nicht weiter.
Bradward B. schrieb: > Aus deinem Arbeitsvertrag o.ä., resp. dem Werkvertrag. Du lässt Mikrocontroller auf Auftrag fertigen, mit Werkvertrag? Sehr praktisch, aber den meisten Unternehmen dürfte dafür das nötige Kleingeld fehlen.
> Ich finde, die Bibliothek des Herstellers zu nutzen, ist kein übergroßer > Malus. Die Nutzung erstmal nicht, komplette Unkenntniss über das "was im Hintergrund der Bibliothek passiert", schon. > Axel S. schrieb: >> Ich bin Kunde. Also bin ich König > > Hast du das mal einem Hersteller gesagt? Was hat er geantwortet? Vielleicht "Ein König zahlt auch königlich für das, was seine königliche Hoflieferanten ankarren'". ;-)
Niklas G. schrieb: > Ich finde, die Bibliothek des Herstellers zu nutzen, ist kein übergroßer > Malus. Doch ist es. Kleines Beispiel: In vielen SoCs werkeln irgendwelche Cryptobeschleuniger (also Hardware, die AES, 3DES, SHA, ... deutlich schneller berechnen kann als entsprechende Software). Wenn dann der Hersteller dieses SoCs nix ueber die Hardware rauslaesst, sondern dafuer eine speziell angepasste Openssl-Library mitliefert (ohne src), dann fangen die Probleme genau dann an, wenn in genau dieser Version irgendein Bug/Designschwaeche/etc. auftaucht. Denn dann kannst du die olle Lib nicht mehr mit gutem Gewissen verwenden, kannst aber selbst nicht auf eine neuere Version updaten, ohne die HW-Unterstuetzung zu verlieren... Gruss WK
Niklas G. schrieb: > Bradward B. schrieb: >> Aus deinem Arbeitsvertrag o.ä., resp. dem Werkvertrag. > > Du lässt Mikrocontroller auf Auftrag fertigen, mit Werkvertrag? Sehr > praktisch, aber den meisten Unternehmen dürfte dafür das nötige > Kleingeld fehlen. Eher fehlt es an Hirnschmalz, denn einen Softcore-controller für einen Wald-Wiesen-FPGA bekommt man nicht nur von opencores.org kostenlos hinterher geworfen. Und auch bei Erbringung von externen Programmierleistungen wie der Erstellung einer Bibliothek spricht man vom Werkvertrag. Ja auch intern kann man von einer "Werksvertrags-ähnlichen" Vereinbarung asugehen, wenn der Abteilungsleiter einen Angestellten auffordert im Rahmen seiner Anstellung eine brauchbare (aka mit Dokumentation) Bibliothek zu erstellen. Es lassen sich genug Gerichtsbeschlüße finden, das die Verweigerung eine Dokumentation zu erstellen zu einer dem BGB nach rechtsmäßigen Kündigung führte.
:
Bearbeitet durch User
Niklas G. schrieb: > Was, wenn das Datenblatt nur minimal ist und man die Bibliothek des > Herstellers nutzen muss um es zum laufen zu bringen? Na ja, dann ist das Teil des realen Lebens. Einen Kompromiss den man machen muss weil man etwas zum Laufen bekommen muss. Niklas G. schrieb: > Was wenn es keinen solchen gibt? z.B. WiFi-Peripherie oder > 3D-Beschleuniger sind m.W. nie dokumentiert. Auch hier, dass ist dann leider die Realität. Als wirklich, wirklich, wirklich großer Kunde bekommst du vielleicht die Dokumentation, oder du bekommst einen Ansprechpartner vom Support des Herstellers. Ansonsten machst du den Kompromiss. Natürlich ist es bitter wenn man nicht mal an der Auswahl des IC beteiligt war und es vorgesetzt bekommt. Noch bitterer ist es wenn man an der Auswahl beteiligt ist und dabei den Kompromiss macht. Wenn dadurch das Produkt scheiße wird oder schlecht wartbar? Das ist dann so. Meine Pflicht ist getan wenn ich auf die Nachteile und möglichen Konsequenzen hingewiesen habe. Manchmal kann man nicht gewinnen sondern nur das kleinere Übel wählen.
IMO führt kein Weg daran vorbei das Referenzhandbuch zumindest zu überfliegen um einen Überblick zu haben was das Ding denn wirklich kann. Für konkrete Anwendung dann kann man sich immer noch in ein Kapitel vertiefen und dazu auch Beispiele vom Hersteller studieren. Über die Registerstruktur und Dinge wie Taktgenerierung und Verteilung muss man auch zumindest grob informiert sein, auch wenn das alles Clicksi-Buntsi-Tools konfigurieren können und Code generieren. Diese Tools gehen auch in die vorgeschlagene Richtung, warnen z.B. bei manchen Fehlkonfigurationen oder fehlenden Einstellungen. Als Hobbyist oder "Gelegenheitsentwickler" kann man es sich auch leisten bei einem Hersteller zu bleiben und sich da noch auf handvoll Typen aus 2 oder 3 Linien zu beschränken, sucht sich z.B. bei ST einen aus der Cortex-M0+-Familie, einen M4 und einen M7 aus und bleibt dabei.
Dergute W. schrieb: > Doch ist es. Kleines Beispiel: In vielen SoCs werkeln irgendwelche > Cryptobeschleuniger Schlechtes Beispiel, an Kryptobeschleunigern gibt es welche mit offener Schnittstelle (die STM32 haben sowas teilweise). Aber bei manchen Peripherien gibt es einfach keine dokumentierten Alternativen. Bradward B. schrieb: > Eher fehlt es an Hirnschmalz, denn einen Softcore-controller für einen > Wald-Wiesen-FPGA bekommt man nicht nur von opencores.org kostenlos > hinterher geworfen. Du meinst man soll sich seinen eigenen SoC per FPGA zusammenbauen statt ein fertiges zu nehmen? Da gibt es auch welche mit Unterstützung von LTE, WiFi, LoRa, 3D-Beschleunigung...? Wie funktioniert das mit dem Analogteil? Und das ist dann auch vergleichbar in Sachen mechanischer Größe, Leistungsaufnahme, Preis, ...? Heißt also dass alle Produkte die einen SoC/Anwendungsprozessor (Smartphones, SBCs, große Industriesteuerungen) oder auch eine SPS (Interna völlig undokumeniert) oder PC nutzen, sind schlecht und sollten durch FPGAs ersetzt werden? Klingt... unrealistisch. Hannes J. schrieb: > Na ja, dann ist das Teil des realen Lebens. Einen Kompromiss den man > machen muss weil man etwas zum Laufen bekommen muss. Das denke ich auch. Bradward B. schrieb: > Es lassen sich genug Gerichtsbeschlüße finden, > das die Verweigerung eine Dokumentation zu erstellen zu einer dem BGB > nach rechtsmäßigen Kündigung führte. Wenn ich also als Angestellter ein Produkt z.B. mit einem NXP i.MX, ESP32 oder auch einem STM32WL55 entwickle kann ich gefeuert werden weil die Schnittstellen dieser ICs nicht vollständig dokumentiert sind und ich diese Details auch nicht aus der Luft greifen kann? Dafür hätte ich doch gerne mal eine belastbare Quelle, denn demzufolge wäre ein großer Teil der Embedded-Entwickler stark gefährdet. Bei sehr viel kommerzieller PC/Server-Software und -Hardware (z.B. Windows und die meisten PC-Komponenten) sind Schnittstellen ebenfalls nicht dokumentiert. Die dürfte man als Angestellter also nicht nutzen?
:
Bearbeitet durch User
> Bradward B. schrieb: >> Eher fehlt es an Hirnschmalz, denn einen Softcore-controller für einen >> Wald-Wiesen-FPGA bekommt man nicht nur von opencores.org kostenlos >> hinterher geworfen. > > Du meinst man soll sich seinen eigenen SoC per FPGA zusammenbauen statt > ein fertiges zu nehmen? Da gibt es auch welche mit Unterstützung von > LTE, WiFi, LoRa, 3D-Beschleunigung...? Wie funktioniert das mit dem > Analogteil? Und das ist dann auch vergleichbar in Sachen mechanischer > Größe, Leistungsaufnahme, Preis, ...? Wenn man es kann, kann man es. Wenn FPGA-Technik hinter dem eigenen Horizont liegt dann kann man es eben nicht und muss sich eben auf das beschränken was man kann. Und wenn man eben nur Zahnbürste oder andere Trivial-tools beherrscht ... praktischerweise braucht man für den Einstieg in Makramee keine Werkzeuge, nur die Fähigkeiten Bindfäden zu vertüdeln. > Heißt also dass alle Produkte die einen SoC/Anwendungsprozessor > (Smartphones, SBCs, große Industriesteuerungen) oder auch eine SPS > (Interna völlig undokumeniert) oder PC nutzen, sind schlecht und sollten > durch FPGAs ersetzt werden? Klingt... unrealistisch. > Bei sehr viel kommerzieller PC/Server-Software und -Hardware (z.B. > Windows und die meisten PC-Komponenten) sind Schnittstellen ebenfalls > nicht dokumentiert. Die dürfte man als Angestellter also nicht nutzen? Naja solange Missverständniss erzeugen Dein fester Wille ist, wird Dich keiner davon abbringen können... IMHO hat man immer die Wahl die nötige Dokumentation ggf. unter Abgabe eines NDA zu erhalten oder eben das undokumentierte Produkt nicht einzusetzen und sich für eins zu entscheiden was den eigenen Informations- und Wissenshorizont nicht überschreitet. Entweder man erschafft sich selbst ein Board-Support-Package (BSP), lässt es sich von anderen (extern, HW-Abteilung, Mutti) schreiben oder man wendet sich anderen System oder eben Spielzeug zu. *https://www.avnet.com/wps/portal/integrated/resources/article/take-a-look-inside-your-first-board-support-package/ *https://www.elektronik-kompendium.de/sites/raspberry-pi/2604131.htm
:
Bearbeitet durch User
Bradward B. schrieb: > Wenn man es kann, kann man es. Wenn FPGA-Technik hinter dem eigenen > Horizont liegt Dann zeig doch mal ein Projekt, wo du ein aktuelles SoC mit einem FPGA bei gleicher Performance, Energieverbrauch und Preis ersetzt. Bradward B. schrieb: > IMHO hat man immer die Wahl die nötige Dokumentation ggf. unter Abgabe > eines NDA zu erhalten Das ist halt schlicht und ergreifend FALSCH. Viele Hersteller geben die Datasheets überhaupt nur raus wenn man Millionenstückzahlen abnimmt. Und das machen nur wenige. Bradward B. schrieb: > Entweder man erschafft sich selbst ein Board-Support-Package (BSP), > lässt es sich von anderen (extern, HW-Abteilung, Mutti) schreiben Ich kann mein Geld auch wunderbar damit verdienen, dass ich ein fertiges SoC nutze. Hat bisher niemanden gestört (genau wie bei unzähligen anderen Produkten). Dass es vielleicht nicht deinen persönlichen Segen erhält kann mir wurscht sein.
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.