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 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.
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.
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.
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.
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
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.
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.
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!
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?
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.
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?
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.
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.
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".
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.
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.
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.
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...
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.
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.
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.
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.
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?
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.
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.
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.
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.
Um den Preis etc. geht es hier nicht, es geht hier über die angebliche Nichtverfügbarkeit von Datenblättern und die daraus abgeleitete Notwendigkeit den selbstgefälligen Herren Embedded-Softwerkern Rundum-Sorglos "modelle" resp. BSP mitzuliefern.
Tut hier keiner mehr das für das er bezahlt wird wie Beitrag "Re: Constraint Programming für Mikrocontroller-Peripherie" ?!?
IMHO hat man immer die Wahl die nötige Dokumentation ggf. unter Abgabe
eines NDA zu erhalten oder ...
Das ist halt schlicht und ergreifend FALSCH.
Nö, das übersteigt nur Deinen Erfahrungshorizont. oder das was Du von diesem bekannt machen willst.
Viele Hersteller geben die
Datasheets überhaupt nur raus wenn man Millionenstückzahlen abnimmt. Und
das machen nur wenige.
Du lebst auf einem anderen Planeten, auch die Firmen mit kleinen Stückzahlen (Raumfahrt, Medizintechnik) für die ich in den letzten Jahrzehnten tätig war, hatten keine Probleme nur die IC's einzusetzen für die es Datenblätter gibt. Oft kann man die Datenblätter gleich beim Distri mitrunter laden, oder man wendet sich an den FAE, dann ist es meist ein NDA o.ä. das es vorher zu unterschreiben gilt.
Nö, das übersteigt nur Deinen Erfahrungshorizont. oder das was Du von
diesem bekannt machen willst.
Ich weiß konkret von:
Ein IC-Hersteller der die Bibliothek (!) erst rausrückt wenn man mindestens 100k p.a. kauft. Die Schnittstellen-Beschreibung dann wahrscheinlich ab 10M p.a. ... Immerhin kommt die Ablehnung sehr prompt und höflich.
Ein anderer Hersteller welcher überhaupt nicht auf Anfragen antwortet, wenn die Abnahmemenge zu gering ist (man weiß natürlich nicht ab wann sie hoch genug ist)
Ein bekannter Großkonzern welcher nicht an Datasheets eines IC kommt, weil sie teure hochwertige Produkte haben und einfach nicht auf die Stückzahlen kommen
Das NDA ist den Herstellern wurst. Wenn die zu wenig Gewinn machen mit ein paar Mickrigen Tausend Stück p.a., lohnt sich der Support-Aufwand einfach nicht. Die Fragen daher immer sofort nach der Abnahmemenge, die ist in der Branche das A und O. NDAs sind egal bzw. sowieso selbstverständlich.
oder man wendet sich an den FAE, dann ist es meist ein NDA o.ä. das es
vorher zu unterschreiben gilt.
Ja schön dass das bei dir geht, aber das ist eben nicht bei allen Herstellern so.
Nenn mir doch z.B. mal einen Hersteller von WiFi-Modulen (gerne mit 5 GHz-Support) bei dem das so geht, wenn man nur 1k p.a. kauft. Das wäre doch von allgemeinem Interesse.
