Kurz und knapp: Wird RISC-V die Open Source-Revolution in der Hardware einläuten, mit dem Resultat, dass proprietäre Prozessorarchitekturen das selbe Schicksal ereilt wie ihre Pendants auf Seite der Betriebssysteme? Dem Kopf hinter der Architektur hat große Pläne: https://www.golem.de/news/cpu-architektur-risc-v-soll-dominierende-architektur-werden-1702-126022.html Wäre das nicht was: EIN Betriebsystem für alle Geräte, vom smarten Rasenmäher bis hin zur Serverfarm. Und ebenso EINE Prozessorarchitektur.
:
Verschoben durch User
Open Source rockt schrieb: > Kurz und knapp: Wird RISC-V die Open Source-Revolution in der > Hardware einläuten, mit dem Resultat, dass proprietäre > Prozessorarchitekturen das selbe Schicksal ereilt wie ihre Pendants auf > Seite der Betriebssysteme? > > Dem Kopf hinter der Architektur hat große Pläne: > https://www.golem.de/news/cpu-architektur-risc-v-s... > > Wäre das nicht was: EIN Betriebsystem für alle Geräte, vom smarten > Rasenmäher bis hin zur Serverfarm. Und ebenso EINE Prozessorarchitektur. Nein Schuss in den Ofen und ich kennen mich aus
@ Open Source rockt (Gast) >Wäre das nicht was: EIN Betriebsystem für alle Geräte, vom smarten >Rasenmäher bis hin zur Serverfarm. Und ebenso EINE Prozessorarchitektur. Das nennt sich dann Monokultur. Wollen wir heute nicht in allen Lebensbereichen Buntheit, Vielfalt und Diversity? Inklusion, auch für BO8?
Haben wir nicht schon in anderen Bereichen eine Monokultur, und das irgendwie erfolgreich? Oder gibt es ein Lebewesen auf diesem Planeten das keinen DNA-Interpreter verwendet?
Es ist irrelevant, darüber zu spekulieren. Fakt ist: RISC-V wird sich über chinesische Firmen mit unerwarteter Geschwindigkeit ausbreiten. Niemand in China will Lizenzgebühren an ARM entrichten. Gleichzeitig ist das Fehlen von Toolchains ein Hauptproblem von alternativen ISAs. Was glaubt ihr wohl, was die ganzen Startups mit den Mrd an Regierungssubventionen machen werden?
https://www.digitimes.com/news/a20181022PD206.html Consortium formed in China to rev up development of RISC-V processors More than 50 IC designers, academic units and research bodies in China have recently established the China RISC-V Industry Consortium, seeking to develop the country's independent intellectual property rights for core IC technologies and ushering in a new development stage for China's RISC-V industry. RISC-V is an open instruction set architecture (ISA) based on the established reduced instruction set computing (RISC) principles, and can be freely used for any purpose, allowing anyone to design, manufacture, and sell RISC-V chips and software. Members of the new consortium include China IC designers, such as VeriSilicon, Espressif Systems, Ingenic Semiconductor, UNISOC (Spreadtrum & RDA), Zhaoxin Semiconductor, Horizon Robotics, and C*Core Technology, yet excluding Hisilicon and C-Sky Microsystems. Consortium chairman Dai Weimin, currently chairman of VeriSilicon, said at the inauguration ceremony for the new organization that the largest opportunity RISC-V will bring to China is to place the country and the rest of the world on the same starting line. Based on a recent market research report issued by GSMA, the global IoT market scale including connections, applications, platforms and services will amount to US$1.1 trillion by 2025, with commercial applications to command some 50% of the market. GSMA also estimates that there will be 1.8 billion IoT connections done by 2025, and China will become a huge market for IoT technologies and applications, which will naturally drive the birth of RISC-V ISAs. China IC players are strong in application-type SoCs but weak in IP and fabrication ends, vice consortium chairman Hu Zhenpo said, adding that RISC-V can help address the processor IP weakness and build independent ecosystems to materialize more technology innovations and differentiations for the China semiconductor industry. China IC designers are actively developing processor chips based on RISC-V architectures. Andes Technology, for instance, has launched four CPU cores - N25F, A25, NX25F and AX25 - featuring the architectures. At the moment, the company is teaming up with SiFive to develop more RISC-V ISAs, pioneering the development of such RISC-V chips in China. On September 17, Huami also released Huangshan MHS001 chip, touted as the world's first RISC-V processor for wearable devices with a computing performance 38% higher than ARM Cortex-M4.
Der Vergleich mit Linux ist nicht ganz korekt. Linux ist daran gescheitert, ein gutes Endkundenprodukt zu werden. Als Produkt für professionelle Anwendungen ist es aber in vielen Bereichen das Maß der Dinge. Risc-V dagegen ist eine Prozessor-Architektur. Also sicherlich nicht dafür gedacht, irgendwie ein Endkundenprodukt zu sein. Erst Geräte auf Basis von Risc-V sind die Endprodukte. Zudem ist die Entwicklungshürde wohl erheblich höher wodurch nicht jeder Hobbyist aus seinem Keller heraus, das Ganze bis ins Unendliche aufbranchen kann, wie bei Linux.
:
Bearbeitet durch User
Alex G. schrieb: > Der Vergleich mit Linux ist nicht ganz korekt. > Linux ist daran gescheitert, ein gutes Endkundenprodukt zu werden. Aha? Android ist ein Linux. Wie viele Android-Smartphone gibt es? Wie viele Fernseher?
:
Bearbeitet durch User
Alex G. schrieb: > Der Vergleich mit Linux ist nicht ganz korekt. > Linux ist daran gescheitert, ein gutes Endkundenprodukt zu werden. Als > Produkt für professionelle Anwendungen ist es aber in vielen Bereichen > das Maß der Dinge. Huh? Kein gutes Endkundenprodukt? Mit was läuft Dein Handy, mit was Dein DSL Router? Windows ist im Vergleich dazu an dieser Stelle eher völlig tot. Gruß, Holm
yesitsme schrieb: > Haben wir nicht schon in anderen Bereichen eine Monokultur, und das > irgendwie erfolgreich? Oder gibt es ein Lebewesen auf diesem Planeten > das keinen DNA-Interpreter verwendet? Ja, etliche Viren.
Tim . schrieb: > Es ist irrelevant, darüber zu spekulieren. > > Fakt ist: RISC-V wird sich über chinesische Firmen mit unerwarteter > Geschwindigkeit ausbreiten. > > Niemand in China will Lizenzgebühren an ARM entrichten. Gleichzeitig ist > das Fehlen von Toolchains ein Hauptproblem von alternativen ISAs. In der Sache hast Du Recht, allerdings ist das keine Frage der Lizenzgebühren.
Alex G. schrieb: > Der Vergleich mit Linux ist nicht ganz korekt. > Linux ist daran gescheitert, ein gutes Endkundenprodukt zu werden. Also ich finde, Milliarden Mobiltelefone, Fernseher, NAS-Geräte sprechen eine ganz andere Sprache...
Na gut, Android ist ein Argument. Allerdings laufen auf dem Großteil der Handies und auf all den Fernsehern, Builds von Android die von einem bestimmten Hersteller so verpackt sind. Das hat kaum etwas mit der Freiheit von Open Source bzw. dessen Grundgedanken (bei Bedarf anpassbar) zutun. Den Play Store darf z.B. niemand ohne Googles Erlaubniss implementieren und ohne ist Android erheblich weniger sinnvoll. Lineage und alternative Stores gibt es, aber entweder auch unter einem Branchenriesen (Amazon) oder eine Niesche (wie Linux auf Desktops).
Bloßnich schrieb: > NIEMALS! Alles, aber nicht BO8! Seit den letzten Befehlssatzänderungen und der Einführung eines synchronen Resets sollte der Durchbruch von bo8 nicht mehr aufzuhalten sein, siehe: Beitrag "Re: 8bit-Computing mit FPGA"
Zitronen F. schrieb: > Das sind ja tolle Aussichten. Die Toolchain auf chinesisch ... Viele Datenblätter gibt es auch nur noch in chinesischer Sprache. Glücklicherweise sind aber die Zahlen in arabischen Ziffern dargestellt, so dass man mit etwas kombinatorischem Geschick durchaus wichtige Parameter entziffern kann.
Zitronen F. schrieb: > Das sind ja tolle Aussichten. Die Toolchain auf chinesisch ... Das ist die Zukunft. Ein Ing, der kein chinesisch kann, hat gerade so viel Chancen wie heute einer, der kein Englisch kann.
:
Bearbeitet durch User
Schauen wir mal, wann es MCUs von Mainstream-Firmen wie Renesas, NXP, TI, ST oder Microchip gibt. Preiswert und verfügbar. Irgendwelche exotischen 64-Bit dual-core Monster mit Megabytes an RAM für FreeRTOS buche ich nicht unter Mikro-Controller.
Rudolph R. schrieb: > Irgendwelche exotischen 64-Bit dual-core Monster mit Megabytes an RAM > für FreeRTOS buche ich nicht unter Mikro-Controller. nicht? ich höre das aber bei uns .. warum einen µC nehmen wenn man fürs gleiche geld einen quadcore Ax nehmen kann... Das Linux ist viel stabiler und die SW ist auch quasi fertig. man muss ja nur die paar Module zusammenstricke...
Andreas Rückert schrieb: > https://www.heise.de/newsticker/meldung/RISC-V-50-Dollar-Entwicklerboard-aus-China-4198639.html "Die AES- und SHA-Einheiten sind vor allem dazu gedacht, verschlüsselte und signierte Firmware auf dem K210 auszuführen." So ist also der "OpenSource-Prozessor" gleich von Grund auf schon dafür gedacht, dass alles verrammelt und abgeschlossen ist, damit ja keiner dran kommt.
Rolf M. schrieb: > So ist also der "OpenSource-Prozessor" gleich von Grund auf schon dafür > gedacht, dass alles verrammelt und abgeschlossen ist, damit ja keiner > dran kommt. Klar, denn auch die Chinesen wollen nicht, dass jemand ihre Appl SW kopiert. Ironisch, nicht?
A. K. schrieb: > Das ist die Zukunft. Ein Ing, der kein chinesisch kann, hat gerade so > viel Chancen wie heute einer, der kein Englisch kann. Ob es wohl Chinesisch-Kurse gibt, bei denen es (hauptsächlich) ums Leseverständnis von Fachliteratur geht und dafür Aussprache und Hörverstehen vernachlässigt werden? fsdf schrieb: > warum einen µC nehmen wenn man fürs gleiche geld einen quadcore Ax > nehmen kann... Man muss die China-SoC's ja auch mit China-µC vergleichen. Und die gibt es (angeblich) für ab 3ct...
@A. K. (prx) >> Das sind ja tolle Aussichten. Die Toolchain auf chinesisch ... >Das ist die Zukunft. Ein Ing, der kein chinesisch kann, hat gerade so >viel Chancen wie heute einer, der kein Englisch kann. Kann sein, muss nicht. Ich wage dir These, daß die chinesische Sprache sich NICHT weltweit so durchsetzen wird wie es Englisch bisher geschafft hat. Warum? Erstens weil es deutlich schwerer zu lernen ist und 2. die Chinesen selber mit ihrer Sprache viele Probleme haben. Daran ändert auch das simplified chinese nichts. Und der Kapitalismus bzw. die Globalisierung suchen immer nach möglichst einfachen, massentauglichen Lösungen. Eine davon heißt Englisch. Chinesisch ist es eher nicht. Aus der japanischen Dominanz in der Elektronikwelt in den 1980er Jahren ist auch keine weltweite Verbreitung des Japanischen erfolgt. Auch die haben gelernt, englische Datenblätter zu schreiben und zu lesen.
Open Source rockt schrieb: > Wäre das nicht was: EIN Betriebsystem für alle Geräte, vom smarten > Rasenmäher bis hin zur Serverfarm. Und ebenso EINE Prozessorarchitektur. Und der Konzern mit dem meisten Geld+Interesse kauft es dann auf, lass mich raten, fängt mit "G" an und hört mit "oogle" auf? Es reicht schon, dass auf PCs das LINUX in 2 Dutzend Arten ständig gegen einen einzigen Konkurrenten kämpfen muss.
Mike B. schrieb: > Und der Konzern mit dem meisten Geld+Interesse kauft es dann auf, > lass mich raten, fängt mit "G" an und hört mit "oogle" auf? Es ist eine OpenSource ISA. Also eine Spezifikation. Nix mit Aufkaufen. Jeder kann daraus eine Mikroarchitektur basteln. > Es reicht schon, dass auf PCs das LINUX in 2 Dutzend Arten ständig gegen > einen einzigen Konkurrenten kämpfen muss. Nö, es gibt nur EIN Linux.
Rolf M. schrieb: > So ist also der "OpenSource-Prozessor" gleich von Grund auf schon dafür > gedacht, dass alles verrammelt und abgeschlossen ist, damit ja keiner > dran kommt. Es ist kein "OpenSource-Prozessor". RISC-V ist eine freie und offene ISA. Daraus kann dann jeder eine offene oder auch geschlossene Mikroarchitektur basteln. Das ist ja das Schöne daran.
Linux T. schrieb: >> Es reicht schon, dass auf PCs das LINUX in 2 Dutzend Arten ständig gegen >> einen einzigen Konkurrenten kämpfen muss. > > Nö, es gibt nur EIN Linux. Und es muß auch nicht kämpfen. Es tut einfach das was es tut, ganz zwanglos und locker aus dem Handgelenk. Und das tut es weil es das kann, nicht weil es irgendwas "muß".
fsdf schrieb: > Das Linux ist viel stabiler und die SW ist auch quasi fertig. > man muss ja nur die paar Module zusammenstricke... Solche naiven Entscheidungsträger mag ich sehr gerne. Sobald sich herausstellt, dass die Sache doch nicht so einfach ist, werden sie meine Kunden.
Andreas S. schrieb: > Sobald sich > herausstellt, dass die Sache doch nicht so einfach ist, werden sie meine > Kunden. Und dann darfst du vermurkste Linux-basierten Konzepten retten, wo mit haarsträubenden Frickeleien Echtzeitfähigkeit herbeigeschummelt (vorgetäuscht) wird?
Neverever schrieb: > Ja, etliche Viren. Viren leben nicht direkt selber sondern werden gelebt. Sprich: sie sind, wenn man das mit der Datentechnik vergleicht, keine CPUs sondern Programme. Und als solche durchaus mit dem DNA-System der Lebewesen kompatibel (sonst könnten die Lebewesen sie nicht ausführen (sprich: vermehren).
M.A. S. schrieb: > Neverever schrieb: >> Ja, etliche Viren. > > Viren leben nicht direkt selber sondern werden gelebt. Sprich: sie sind, > wenn man das mit der Datentechnik vergleicht, keine CPUs sondern > Programme. > Und als solche durchaus mit dem DNA-System der Lebewesen kompatibel > (sonst könnten die Lebewesen sie nicht ausführen (sprich: vermehren). Das ist Humbug. Es gibt sowohl RNA- als auch DNA-Viren. Erstere sind in der Überzahl. Und Viren brauchen keine Wirts-DNA zum Vermehren. Sie nutzen die restliche Zellinfrastruktur (z.B. Enzyme) für Vermehrungszwecke. Also: Neverever hat Recht.
Tim . schrieb: > Alex G. schrieb: >> Der Vergleich mit Linux ist nicht ganz korekt. >> Linux ist daran gescheitert, ein gutes Endkundenprodukt zu werden. > > Android ist ein Linux. > > Wie viele Android-Smartphone gibt es? Wie viele Fernseher? Naja, das Frontend für den Endkunden bzw. das GUI für alle diese Geräte ist aber fast nie etwas standardmässiges von Linux oder Android, weil es dafür nachwievor unbrauchbar ist. Fast jeder Hersteller implementoiert oder erweitert da selber was. Bei Samsung, dem Branchenführer, z.B. TouchWiz, welches dann noch abgelöst wird durch Samsung Experience. https://en.wikipedia.org/wiki/TouchWiz https://en.wikipedia.org/wiki/Samsung_Experience Google selbst verwendete wohl ihren "Google Now" Launcher, welcher auch anderen Herstellern zur Verfügung gestellt wurde, die stellen aber wohl auf den "Pixel Launcher" um.
Johnny B. schrieb: > Naja, das Frontend für den Endkunden bzw. das GUI für alle diese Geräte > ist aber fast nie etwas standardmässiges von Linux Linux hat überhaupt kein GUI. Auch auf dem Desktop ist das GUI eine komplett separate Komponente von komplett anderen Leuten entwickelt als denen die Linux entwickeln. Was Du da vorbringst ist also ein Null-Argument.
Linux ist in einigen Bereichen zwar der Marktführer, aber da wo es mal hin wollte ist es letzentlich an Opensource gescheitert. Warum?: Weil jeder Depp das Rad neu erfinden musste anstatt das alle mal eine Version fertig gemacht hätten und damit damals Windows das Wasser abgegraben hätten. Gut inzwischen gibt es gute Pakette, aber das sind eigentlich zu viele und damit zu viel verschwendette Zeit. Bei dem RISC-V sehe ich da zum Glück nicht so eine Fehlentwicklung und erwarte 2019 die ersten kaufbaren Prozessoren. Wer als erstes damit auf den Markt kommt wird sich Zeigen, aber am Ende werden es alle grossen sein.
Falk B. schrieb: > Ich wage dir These, daß die chinesische Sprache sich NICHT weltweit so > durchsetzen wird wie es Englisch bisher geschafft hat. Da gehe ich mit. Nur was heisst das? Heisst es, dass Englisch weiterhin linga franca sein wird und die Chinesen wie bisher Englisch sprechen? Oder heisst es, dass jene Nicht-Chinesen, die keinerlei Chinesisch können, in diesen Berufen wenig Chancen haben? Und mit der Zeit die meisten "harten" Ings Chinesen sind. Ok, das ist jetzt bewusst ein wenig ins Extrem gezogen.
Klaus schrieb: > Linux ist in einigen Bereichen zwar der Marktführer, aber da wo es mal > hin wollte ist es letzentlich an Opensource gescheitert. Wo wollte "Linux" denn hin??? Linux ist nichts weiter als ein Kernel. Und als solcher hat er, wenn man schon in diese Richtung argumentiert, gesiegt. Denn oberhalb der Mikrocontroller-Klasse wird die grosse Mehrheit an Geräten mit einem Linux-Kernel betrieben. > Warum?: > Weil jeder Depp das Rad neu erfinden musste anstatt das alle mal eine > Version fertig gemacht hätten und damit damals Windows das Wasser > abgegraben hätten. Nein, das ist doch nicht die Ursache. Wenn dem so wäre, dann hätte sich auch die x86-ISA nicht durchgesetzt. > Bei dem RISC-V sehe ich da zum Glück nicht so eine Fehlentwicklung und > erwarte 2019 die ersten kaufbaren Prozessoren. Gute Nachricht für Dich: Es gibt sie schon!
Linux T. schrieb: > Denn oberhalb der Mikrocontroller-Klasse wird die grosse Mehrheit an > Geräten mit einem Linux-Kernel betrieben. Wobei gerade Android ein äußerst schlechtes Beispiel ist, weil außer dem Kernel (der zudem auch noch von Google geforkt und maintained wird, mit einem Mainline-Kernel kommt man nicht weit) ziemlich genau nichts an das erinnert, was man landläufig unter "Linux" versteht. So eine Router- oder NAS-Firmware ist da schon wesentlich näher dran, ebenso wie ChromeOS.
Klaus schrieb: > Linux ist in einigen Bereichen zwar der Marktführer, aber da wo es mal > hin wollte ist es letzentlich an Opensource gescheitert. > Warum?: Weil viele Hersteller populärer proprietäerer Software bei Windows geblieben sind und weil Microsoft es durch Ausnutzung seines Monopols und durch Knebelverträge geschafft hat, dass praktisch jeder neue PC mit vorinstalliertem Windows ausgeliefert wird.
Klaus schrieb: > Linux ist in einigen Bereichen zwar der Marktführer, aber da wo es mal > hin wollte ist es letzentlich an Opensource gescheitert. Wo wollte es denn hin, und woher weist du das? Ich habe jedenfalls ein Buch von Herrn Linus Torvalds gelesen und dem entnommen, dass Linux zum Selbstsläufer geworden ist, dass seine kühnsten Vorstellungen übertroffen hat. > Weil jeder Depp das Rad neu erfinden musste anstatt Was der Sinn von Open-Source ist. Man greift eine Idee von jemandem auf und verändert sie nach eigenem Gusto. Und Linux ist dazu schlichtweg etwas besser geeignet, als Windows. Auch in der Windows Welt werden viele Räder immer wieder neu erfunden. Ich sage nur Office, Web Browser, Email Programme, Text Editoren, Entwicklungsumgebungen und so weiter. Was die GUI angeht, da müsstest du dich bei Microsoft beschweren, dass die alle paar Jahre umgestaltet wird. Im Gegensatz zu Linux kannst du bei Windows nicht einfach die GUI nach deinen Vorlieben auswählen. Da gilt eher die Regel: Friss oder stirb.
Naja, die Idee einer one size fits all platform for all computing needs war schon seit zwanzig Jahren der feuchte Traum jedes Schlipses. In meiner Firma wird alle 5 Jahre eine neue ELWMS durchs Dorf getrieben, und zur Zeit denkt jeder Hersteller, den Markt in der Hand zu haben, wenn sich nur "sein" Ökosystem durchsetzt... was sollte heute Anders sein als vor 20 Jahren, dass es auf einmal klappt? Als vor knappen 10 Jahren die ARM Cortex PODs begannen, sich richtig breit zu machen, schien die Akte endlich und endgültig geschlossen: Da und nirgendwo Anders liegt die Zukunft. Und nun? Pustekuchen. Zu denken, dass sich eine Plattform (Hart oder Weich) flächendeckend durchsetzen wird ist so naiv wie anzunehmen, dass sich die gesamte Modebranche auf nur eine Kollektion und eine Grösse beschränken würde. Klappt nicht. Schon deswegen nicht, weil die Anforderungen an Embedded Systeme (Hardware wie Software) niemals auf eine kleine Zahl von Anwendungen zusammendrücken lässt. Selbst wenn das "Super Board" noch so billig zu haben sein wird - wenn es auf Consumeranwendungen feingetrimmt ist, wird da mindestens ein TouchController und ein Audiointerface dabei sein, und das wird Niemals in Messfühlern oder medical systems einfach nur als totes Gewicht mitgetragen werden. Wenn nicht, braucht es mindestens ein HMI Expansion board und damit einen Controller, der die dafür benötigten Pins herausführen muss - was für die meisten kleineren Anwendungen ein kompletter overkill ist. Dazu kommt, dass ein weit verbreitetes System umso anfälliger für Attacken ist und umso verletzlicher da steht, wenn wirklich mal eine Lücke aufgemacht wird. So manche auf Sicherheit bedachte Firma setzt deswegen bewusst auf Nischenplattformen, die zu knacken einen komplett neuen Werkzeugsatz erfordert. Das nächste, was man an eine Universalplattform herankommt, ist ein hoch skalierbarer Prozessorkern wie der Cortex oder eben ein RISC V Kern. Aber obwohl momentan ARM Cortex den Markt enorm dominiert, ist trotzdem (vermutlich gerade deswegen) noch Platz für Andere Prozessorarchitekturen. Analoges gilt für den RTOS und Middleware Markt. Also ich gehe jede Wette ein, dass in 10-20 Jahren der Markt noch genau so bunt und fragmentiert ist wie jetzt.
Ob die RISC-V Architektur (oder irgendeine andere) die µC Welt dominieren wird ist mir ziemlich egal, sofern man sie in C programmieren kann. Als Programmierer befasse ich mich zu 99% der Zeit ohnehin mit der Peripherie, nicht mit der CPU. Das ist je gerade das schöne an Hochsprachen.
Stefanus F. schrieb: > Klaus schrieb: >> Linux ist in einigen Bereichen zwar der Marktführer, aber da wo es mal >> hin wollte ist es letzentlich an Opensource gescheitert. > > Wo wollte es denn hin, und woher weist du das? Interessant zu wissen dass "es" da nicht hin wollte und der Erfinder auch nicht. Tatsache ist aber dass immer wieder behauptet wird, Linux sei besser als Windows und müsste es ablösen. An jeder Ecke, auch hier im Forum liest man von typen die es besser als Windows darstellen wollen und es überhaupt nicht verstehen wieso alle Microsoft anhängen ;) Dabei heisst es auch immer "Linux", nicht ein bestimmtes Derivat. Entsprechend ist "Linux" für viele offenbar doch das Betriebssystem inkl. einer GUI, nicht nur der Kernel.
Alex G. schrieb: > Entsprechend ist "Linux" für viele offenbar doch das Betriebssystem > inkl. einer GUI, nicht nur der Kernel. Sicher ist es das. Wer hier darauf beharrt, das Linux nur den Kernel bezeichnet, der korrigiert auch anderer Leute Rechtschreibfehler.
Alex G. schrieb: > Entsprechend ist "Linux" für viele offenbar doch das Betriebssystem > inkl. einer GUI, nicht nur der Kernel. Stichwort GNU/Linux.
Stefanus F. schrieb: > Ob die RISC-V Architektur (oder irgendeine andere) die µC Welt > dominieren wird ist mir ziemlich egal, sofern man sie in C programmieren > kann. Kann man z.B. die Rockchip RK3... CPUs auch, aber nur wenn man einen angepassten alten Linux Kernel mit binary Blobs, einen angepassten U-Boot und undurchsichtige Programme zur Erstellung des Flash Abbilds nutzt. Da überhaupt keine Doku existiert hat man keine andere Möglichkeit. Ist das die Art wie dann alles programmiert wird? Bei ARM ist ja immerhin der Prozessorkern sehr ausführlich auf Englisch dokumentiert, d.h. man könnte sich eigene RTOS programmieren. Wenn dann aber alles von ultrabilliger chinesischer Massenware dominiert wird deren Dokumentation, selbst wenn man sie bekäme auf chinesisch wäre, könnte man das nicht mehr. Dann können nur noch große reiche Konzerne echtzeitfähig programmieren, weil nur die die Doku bekommen und sich die Übersetzer bzw. chinesische Programmierer leisten können, um ohne ein vermurkstes China-Linux arbeiten zu können. Schöne neue Welt?
S. R. schrieb: > Alex G. schrieb: >> Entsprechend ist "Linux" für viele offenbar doch das Betriebssystem >> inkl. einer GUI, nicht nur der Kernel. > > Stichwort GNU/Linux. So wünscht sich Stallman, dass man es nennt. Passt aber auch nicht, da sehr große Teile der üblichen Linux-Distributionen nicht GNU sind, z.B. KDE, Firefox, LibreOffice, X.org u.s.w.
Dr. Sommer schrieb: > Dann können nur noch große reiche Konzerne > echtzeitfähig programmieren, weil nur die die Doku bekommen Auch die bekommen die Doku nicht, höchstens einen Sourcedump. Hätte ich ordentliche Datenblätter auf Arbeit, käme ich besser voran.
S. R. schrieb: > Auch die bekommen die Doku nicht, höchstens einen Sourcedump. > Hätte ich ordentliche Datenblätter auf Arbeit, käme ich besser voran. Auch nicht wenn man große Stückzahlen p.a. abnimmt? Heißt das, dass die Treiber für diese SoCs ausschließlich von den Leuten geschrieben werden, welche den SoC entwickelt haben, und sonst kann das niemand?
Ich halte es durchaus für möglich, dass sich RISC-V durchsetzen wird. Allerdings vermuteich, dass wohl Nischen für andere Architekturen (z.B. im 8-bit-Bereich, oder bei GPU) bleiben. RISC-V ist ja bei den µC schon halbwegs dabei, und wird da wohl ARM verdrängen. Und auch am gegenüberliegenden Ende der Performanzskala nimmt RISC-V Fahrt auf: https://insidehpc.com/2018/05/mateo-valero-risc-v-can-play-major-role-new-supercomputer-architectures/ Philipp
Philipp Klaus K. schrieb: > RISC-V ist ja bei den µC schon halbwegs dabei, und wird da wohl ARM > verdrängen. Wie finanziert sich eigentlich das ganze Ökosystem um RISC-V herum, also Compiler, IDEs, Doku & Literatur? Bei ARM wird das ja über die Lizenzen gehen, sodass man vieles vom Drumherum gratis herunterladen kann.
Rolf M. schrieb: >> Stichwort GNU/Linux. > > So wünscht sich Stallman, dass man es nennt. Passt aber auch nicht, da > sehr große Teile der üblichen Linux-Distributionen nicht GNU sind, z.B. > KDE, Firefox, LibreOffice, X.org u.s.w. Stallman hatte früher ein Betriebssystem ohne Kernel, Torvalds einen Kernel ohne Tools. Was macht eigentlich der Hurd-Kernel?
Stefanus F. schrieb: > Ich habe jedenfalls ein Buch von Herrn Linus Torvalds Wobei gemäss Aussage von Terry Davis (RIP) der Herr Torvalds kein professioneller Programmierer ist, da er nie in seinem Leben einen eigenen Compiler programmiert hat.
Michael X. schrieb: > Was macht eigentlich der Hurd-Kernel? Wikipedia: "After years of stagnation, development picked up again in 2015 and 2016, with four releases during these two years." Die Version 0.9 von Ende 2016 ist der letzte Stand.
Johnny B. schrieb: > Wobei gemäss Aussage von Terry Davis (RIP) der Herr Torvalds kein > professioneller Programmierer ist, da er nie in seinem Leben einen > eigenen Compiler programmiert hat. Dieser Terry Davis? (Wikipedia) `After being in direct communication with God, God told him the operating system he built was for God's third temple, and that TempleOS is of "divine intellect" due to the inspired nature of the code.´
:
Bearbeitet durch User
A. K. schrieb: > Johnny B. schrieb: >> Wobei gemäss Aussage von Terry Davis (RIP) der Herr Torvalds kein >> professioneller Programmierer ist, da er nie in seinem Leben einen >> eigenen Compiler programmiert hat. > > Dieser Terry Davis? (Wikipedia) `After being in direct communication > with God, God told him the operating system he built was for God's third > temple, and that TempleOS is of "divine intellect" due to the inspired > nature of the code.´ Ja genau dieser Terry. Wohl aufgrund seiner psychichen Krankheit und deren Auswirkungen nahm er sich aber vor kurzer Zeit das Leben.
Dr. Sommer schrieb: > Ist das die Art wie dann alles programmiert wird? Leider ja Wird bereits so weit, dass Endkunden nicht mehr die volle Kontrolle über ihre eigenen Geräte haben. Schlimmer noch, immer mehr Geräte werden von externen Diensten abhängig. Versuche z.B. mal eine Playstation 4 zu benutzen, während die zugehörigen Server von Sony ausgefallen sind. Dann geht fat nichts mehr! So wird es bald auch den Entwicklern gehen. Google geht da mit Meilenstiefeln voran. Die meisten Entwickler haben keinen Schimmer, was sie sich und ihren Kunden mit den Google Services an Bein hängen. Selbst bei Mikrocontrollern (Espressif) ist das schon angekommen. Heute verstehen einmal mehr die Entwickler ihrer eigenen Produkte. Ich finde das schade. Den damit verbundenen Kontrollverlust finde ich sogar ziemlich gefährlich. Vielleicht sollten wir alle mal darüber nachdenken, ob es wirklich überall eine gute Idee ist, Lichtschalter ans Internet zu hängen - um nur ein Beispiel zu nennen.
Stefanus F. schrieb: > Vielleicht sollten wir alle mal darüber nachdenken, ob es wirklich > überall eine gute Idee ist, Lichtschalter ans Internet zu hängen - um > nur ein Beispiel zu nennen. Für manche könnte es eine gute Idee sein. Als Hersteller von Kerzen würde ich mir überlegen, eine Tochterfirma zu gründen, die Lichtschalter vertreibt, die sich per Netz steuern lassen. Dann profitiert man von Fehlern in der Technik, statt unter ihnen zu leiden.
:
Bearbeitet durch User
Johnny B. schrieb: > Wobei gemäss Aussage von Terry Davis (RIP) der Herr Torvalds kein > professioneller Programmierer ist, da er nie in seinem Leben einen > eigenen Compiler programmiert hat. Jeder hat da halt seine anderen Kriterien. Fakt ist immerhin auch, das er den Linux Kernel ursprünglich nur für sich selbst entwickelte, weil er keine Lust hatte, auf Zugang zum Rechner der Uni zu warten. Es war also von Anfang an eine Bastelei. Ich verstehe nicht, warum dies immer wieder als Schlecht herausgestellt wird. Was ist daran schlecht, wenn ein Bastler seine Software an andere Bastler verschenkt und diese daran weiter arbeiten? Wenn Linux verbastelt ist, dann ist Windows professionell vermurkst. Beide Systeme sind über lange Zeit gewachsen und werden fortlaufen aufgeräumt. Jetzt schneiden die Linux Entwickler etwas schneller alte Zöpfe ab, als Microsoft und schon wird wieder herum gemeckert dass das nicht akzeptabel sei. WTF? Frei nach dem Motto: Wasch mir den Pelz, aber mach mich nicht nass. Und nicht vergessen: Dem geschenkten Gaul schaut man nicht ins Maul.
Falk B. schrieb: > Das nennt sich dann Monokultur. Wollen wir heute nicht in allen > Lebensbereichen Buntheit, Vielfalt und Diversity? Nö, gerade die Linuxwelt ist alles andere als eine Monokultur, obwohl alles im Kern das gleiche ist, während es bei Windows tatsächlich Monokultur gibt, dess es gibt halt nur das eine Windows. Bei Prozessoren genau das gleiche: Monokultur von Intel und ARM, wohin man blickt, während eine offene Architektur, die einen gemeinsamen Kern aufweist, aber jeder erweitern kann, dieses Problem nicht hat. Einfaches Beispiel die Intel Management Engine: Ein eigenes Betriebssystem integriert in jedem Intel-Prozessor, von dem keiner (außer Intel und der NSA) so genau weiß, was es so tut, und welche Lücken es aufreisst (absichtlich oder unabsichtlich). Weder einsehbar, noch austauschbar, jeder mit Intel-Prozessor hat es und muss es verwenden.
vn nn schrieb: > Bei Prozessoren genau das gleiche: Monokultur von Intel und ARM Und die meisten Anwendungsprozessoren sind praktisch ausschließlich mit dem Linux-Kernel nutzbar (s.o.), weshalb es hier eine Linux-Monokultur gibt... Nur weil jeder dieser Prozessoren auf eine andere veraltete Linux-Version festgenagelt ist, ist das keine Diversität ;-)
fsdf schrieb: > Rudolph R. schrieb: >> Irgendwelche exotischen 64-Bit dual-core Monster mit Megabytes an RAM >> für FreeRTOS buche ich nicht unter Mikro-Controller. > > nicht? Nein, es gibt ja auch genug Anwendungen bei denen der *Mikro*-Controller nur mit ein paar Pins wackeln muss. Dafür klemme ich doch keinen Task in ein OS damit das vielleicht irgendwann mal passiert - schauder. > ich höre das aber bei uns .. > warum einen µC nehmen wenn man fürs gleiche geld einen quadcore Ax > nehmen kann... Bekommt man das wirklich? Vor allem wenn man so ein überflüssiges Detail wie die Leiterplatte dazu berücksichtigt? Am oberen Ende dessen was inzwischen noch als MikroController durch geht und noch kein Applikations-Prozessor ist mag das gelten. Aber man braucht auch kein 300MHz BGA um zum Beispiel einen 3D-Drucker zu steuern, da sind die 16MHz AVR immer noch sehr stark verbreitet. Rechenpower geht dann drauf für Komfort-Funktionen mit dem RaspberryPi neben dem Drucker der das Ding per WLAN steuerbar macht und Bilder von seiner Kamera ins Netzt wirft - Luxus, Auswege aus dem Dilemme den Hintern aus dem Sessel bewegen zu müssen. Und direkt den AVR ersetzen geht mit dem RaspberryPi nicht mal. Also RISC-V, schauen wir mal wo die Reise hin geht, das wird sich aber noch ein paar Jahre hin ziehen bis das richtig Fahrt aufgenommen hat, nicht nur auf dem Papier.
Stefanus F. schrieb: > Dem geschenkten Gaul schaut man nicht ins Maul. Das Hauptargument für Linux :)
Dr. Sommer schrieb: > Philipp Klaus K. schrieb: >> RISC-V ist ja bei den µC schon halbwegs dabei, und wird da wohl ARM >> verdrängen. > > Wie finanziert sich eigentlich das ganze Ökosystem um RISC-V herum, also > Compiler, IDEs, Doku & Literatur? Bei ARM wird das ja über die Lizenzen > gehen, sodass man vieles vom Drumherum gratis herunterladen kann. GCC und LLVM gibt es auch für Architekturen, bei denen die Hardwarehersteller kein Geld geben. SDCC erst recht¹. Und auch wo keine Lizenzgebühren für die Architektur fällig werden, finanzieren Hardwarehersteller trotzdem oft teils die Compilerentwicklung. Philipp ¹ Mir ist keinerlei durch Hardwarehersteller bezahlte Arbeit an SDCC bekannt. Allerdings haben SDCC-Entwickler kostenlose Entwicklungsboards von ST erhalten.
Rudolph R. schrieb: > Monster mit Megabytes an RAM > für FreeRTOS buche ich nicht unter Mikro-Controller. Also ich nehme sehr gerne auch für kleine/einfache Anwendungen FreeRTOS, weil man jederzeit mit sehr kleinem Aufwand weitere Funktionalität in seine Software einbauen kann. LED blinken lasssen in einem Task z.B. so:
1 | while(1) |
2 | {
|
3 | ToggleLED(); |
4 | osDelay(1000); |
5 | } |
Später sagt der Chef, es braucht noch eine andere LED, welche im 13ms Takt blinkt; nichts leichter als das, macht man halt einfach noch einen zweiten Task. Den ersten kann man völlig unberührt lassen.
1 | while(1) |
2 | {
|
3 | ToggleLED2(); |
4 | osDelay(13); |
5 | } |
Auf einem STM32F1 oder STM32F3 benötigt das nackte FreeRTOS meiner Erfahrung nach ca. 14kB. Das klingt zwar nach sehr viel, aber es kann dann auch schon sehr viel und um sagen wir mal weitere 10kB zu füllen, programmiert man dann schon sehr viel Funktionalität.
:
Bearbeitet durch User
Dr. Sommer schrieb: >> Auch die bekommen die Doku nicht, höchstens einen Sourcedump. >> Hätte ich ordentliche Datenblätter auf Arbeit, käme ich besser voran. > > Auch nicht wenn man große Stückzahlen p.a. abnimmt? Hängt von der Firma ab, mit der man zu tun hat. Die externe Dokumentation bekommt man - die kann aber auch reichlich nutzlos sein und sich auf "nimm unser Tool, klicke hier, klicke da, speichere die Datei ab und lese sie bei jedem Systemstart ein" beschränken. Oder es ist ein reines Datenblatt (Abmessungen, Temperaturbereich, elektrische Eigenschaften, Pinout). Manche Firmen kippen auf Nachfrage einfach den Sourcetree aus, in dem Zustand, in dem er gerade ist. Muss auch nicht unbedingt bauen. Andere Firmen haben extensive Dokumentation, die beschreibt, wie man die Hardware zum Laufen bekommt und benutzt, aber trotzdem nichts darüber verrät, wie sie eigentlich funktioniert. Dann gibt es ein (mehr oder weniger funktionierendes und dokumentiertes) SDK und fertig. Als Unternehmen interessieren mich solche Details auch nicht. Hauptsache, die eingekaufte Ware kommt mit Funktionsgarantie, ich kann im Problemfall jemanden ankacken, der sich drum kümmert und muss mich nur um das kümmern, was mein Produkt gegenüber der Konkurrenz auszeichnet. > Heißt das, dass die Treiber für diese SoCs ausschließlich von > den Leuten geschrieben werden, welche den SoC entwickelt haben, > und sonst kann das niemand? Das ist korrekt. Die GPL hilft da auch nur bedingt, weil die veröffentlichten Kerneltreiber zwar die reine Hardware exportieren, aber die eigentliche Ansteuerung durch Userspace-Bibliotheken erfolgt. Damit kann man sich übrigens auch besondere Features vergolden lassen... Rate mal, warum Android ausschließlich über wohldefinierte HALs mit der Hardware redet und wer die für jeden SoC entwickelt. Android ist kein bisschen Linux, auch wenn da ein Linux-Kernel drin steckt. Wenn man solche SoCs überhaupt kaufen kann (unter Mindeststückzahl reden die nicht mit dir), dann bekommt man auch Zugang zum Ticketsystem und zur Entwicklungsabteilung vom SoC-Hersteller. Benutzt das eigene Produkt aber nicht den absoluten Hot Shit(TM) - also das, was in 6 Monaten zu haben sein wird - bekommt man aber nur Zugang zu den Ingeneuren, die für "Maintenance alter Chips" zuständig sind.
S. R. schrieb: > Manche Firmen Ja, so hab ich mir das schon gedacht... S. R. schrieb: > Als Unternehmen interessieren mich solche Details auch nicht Auch wenn du so gezwungen wirst Linux zu verwenden und deine Flexibilität eingeschränkt wird? Was, wenn du einen aktuellen Linux Kernel brauchst? Die Befürchtung ist, dass mit RISC-V dann die chinesischen Hersteller alles dominieren, alle Chips eine solche Doku-Situation haben und man nicht mal mehr einen so gut dokumentierten Core hat wie bei ARM.
Dr. Sommer schrieb: > Die Befürchtung ist, dass mit RISC-V dann die chinesischen Hersteller > alles dominieren, alle Chips eine solche Doku-Situation haben und man > nicht mal mehr einen so gut dokumentierten Core hat wie bei ARM. Dieser Fall wird wohl mittel- bis langfristig eintreten, sofern die Wirtschaft in Fernost weiterhin so gut läuft. Europa und die USA befinden sich aus diversen Gründen ja schon viele Jahre auf Talfahrt und das wird sich auf absehbare Zeit auch nicht ändern. Man denke nur schon an die ganzen Normen und Richtlinien und die ganze Industrie/Politik welche dahintersteckt. Ein gewisses Mass an Normen und Richtlinien sind schon ok, aber vieles ist ein wenig aus dem Ruder gelaufen und vorallem kleine Firmen haben sehr Mühe, eigene Produkte auf den Markt zu bringen. Mir persönlich ist eigentlich egal welcher Prozessorkern in einem Mikrocontroler steckt, solange ich eine vernünftige Programmiersprache und Entwicklungsumgebung dafür habe.
Johnny B. schrieb: > Mir persönlich ist eigentlich egal welcher Prozessorkern in einem > Mikrocontroler steckt, solange ich eine vernünftige Programmiersprache > und Entwicklungsumgebung dafür habe. Mir wäre halt noch eine komplette Dokumentation sehr wichtig, und Unterstützung durch Open Source Compiler. Da wird's schnell eng... Johnny B. schrieb: > Europa und die USA befinden sich aus diversen Gründen ja schon viele > Jahre auf Talfahrt und das wird sich auf absehbare Zeit auch nicht > ändern. Tja... Man hat fast das Gefühl das hierzulande keiner mehr weiß, wie die ganze Technik funktioniert, auf die sich alle verlassen.
Die Chips von Espressif sind jedenfalls kein guter Ersatz für derzeitige Mikrocontroller.
Stefanus F. schrieb: > Die Chips von Espressif sind jedenfalls kein guter Ersatz für > derzeitige > Mikrocontroller. Ach... Obwohl die so viel Speicher und Rechenleistung haben? Das Internet liebt die ja geradezu (und die anderen zig sehr ähnlichen Systeme überhaupt nicht).
> Stefanus F. schrieb: >> Die Chips von Espressif sind jedenfalls kein guter Ersatz für >> derzeitige Mikrocontroller. > Dr. Sommer schrieb: > Ach... Obwohl die so viel Speicher und Rechenleistung haben? Die sind eigentlich nur wegen dem WLAN interessant. Das war's dann auch schon. Wenn ich einen schnellen Rechner mit viel Speicher brauche, nehme ich etwas PC basiertes mit Linux. Mikrocontroller nutze ich wegen ihrer Timer, I/O Funktionen und exakt berechenbarer Zeiten. Da haben die ESP Chips nu wenig zu bieten. Dokumentation ist beim ESP nicht so dolle. Glaubwürdigkeit ist auch so ein Thema. Noch ein Aspekt: Ich kann nichts, wo ein ESP Chip drin ist, kommerziell verwenden. Weil ich dann nämlich diverse Prüfungen durchmachen muss, die ich nicht einmal Ansatzweise überschauen und bezahlen kann.
Dr. Sommer schrieb: > S. R. schrieb: >> Manche Firmen > Ja, so hab ich mir das schon gedacht... Zu zwei großen Herstellern könnte ich was sagen. Einer davon chinesisch. >> Als Unternehmen interessieren mich solche Details auch nicht > > Auch wenn du so gezwungen wirst Linux zu verwenden und deine > Flexibilität eingeschränkt wird? Was, wenn du einen aktuellen Linux > Kernel brauchst? Brauche ich nicht. Wenn ich ein Android-Gerät mit den Google-Services verkaufen will, bedeutet das erstens eine bestimmte Android-Version und damit auch eine bestimmte Version des Kernels. Was anderes wird von Google sowieso nicht zertifiziert, wäre also unverkäuflich. Die vom SoC-Hersteller gelieferte Kernelversion unterstützt auch sämtliche Features der Plattform für den gegebenen Kontext (d.h. die Android-HAL einer bestimmten Version wird unterstützt), zusätzliche Hardwaretreiber brauche ich also nicht. Die vorgeschriebene Version ist immer eine gepflegte LTS-Version, also warum sollte ich - aus Unternehmenssicht - einen anderen Kernel wollen? Die Zwänge liegen bereits an ganz anderer Stelle, die Kernel-Version ist vollständig irrelevant. Und nein, ich finde das auch nicht gut. Aber ich verstehe, warum die Situation so ist, wie sie ist. > Die Befürchtung ist, dass mit RISC-V dann die chinesischen Hersteller > alles dominieren, alle Chips eine solche Doku-Situation haben und man > nicht mal mehr einen so gut dokumentierten Core hat wie bei ARM. Ich sehe da keinen großen Unterschied zu heute. Gut dokumentierte Chipsätze wird es auch weiterhin geben, die große industriell gefertigte Masse braucht keine öffentliche Dokumentation. In der großen Masse steht Embedded für Wenigzweckgeräte. Da definiert man sich seine Use-Cases, implementiert und testet die, schubst das Gerät auf den Markt und geht zum nächsten Gerät über. Wo das nicht so ist, wird es passende Chips geben. Dr. Sommer schrieb: > Mir wäre halt noch eine komplette Dokumentation sehr wichtig, und > Unterstützung durch Open Source Compiler. Da wird's schnell eng... Und wenn der Markt gute Dokumentation will, die Asiaten aber nicht liefern, dann wird es auch Firmen in der westlichen Welt geben, die diese Bedürfnisse befriedigen. Guten Tool-Support (Compiler) wird es geben. Die Infrastruktur (GCC, LLVM) ist vorhanden und die Chinesen arbeiten daran auch aktiv mit. Und wenn nicht, dann findet sich immer jemand, der die in China vom Laster gefallenen Codeschnipsel aufräumt und integriert. > Johnny B. schrieb: >> Europa und die USA befinden sich aus diversen Gründen ja schon viele >> Jahre auf Talfahrt und das wird sich auf absehbare Zeit auch nicht >> ändern. > Tja... Man hat fast das Gefühl das hierzulande keiner mehr weiß, wie die > ganze Technik funktioniert, auf die sich alle verlassen. Stimmt doch.
S. R. schrieb: >> Tja... Man hat fast das Gefühl das hierzulande keiner mehr weiß, wie die >> ganze Technik funktioniert, auf die sich alle verlassen. > > Stimmt doch. Wie die gesamte Technik funktioneirt kann ein einzelner auch nicht wissen... Ob es deshalb soweit kommt wie in http://archive.ncsa.illinois.edu/prajlich/forster.html ? Denke nicht. Dafür ist der Mensch generell zu wissensdurstig und neugierig. Wieso Foster meinte das würde irgendwann einfach aufhören, kann ich mir nicht so ganz erklären.
Ich empfehle den Wikipedia-Artikel https://de.wikipedia.org/wiki/B%C3%BCcherverluste_in_der_Sp%C3%A4tantike - Wissen kann innerhalb relativ kurzer Zeit verloren gehen. Außerdem sind so ziemlich alle aktuellen Medien zum Wissenserhalt sehr kurzlebig.
S. R. schrieb: > Ich empfehle den Wikipedia-Artikel > https://de.wikipedia.org/wiki/B%C3%BCcherverluste_in_der_Sp%C3%A4tantike > - Wissen kann innerhalb relativ kurzer Zeit verloren gehen. Außerdem > sind so ziemlich alle aktuellen Medien zum Wissenserhalt sehr kurzlebig. Naja, heute wird aber extrem viel dokumentiert und meinte ja Technik die wirklich Verwendet wird. Denke das unrealistsichte an der Geschichte ist, dass die Menschen so lange mit der einen Technologie leben würden. Wenn nicht grade die Religion dazwischen funkt (Mittelalter), entwickelt sich Technik immer weiter.
:
Bearbeitet durch User
S. R. schrieb: > Ich empfehle den Wikipedia-Artikel > https://de.wikipedia.org/wiki/B%C3%BCcherverluste_in_der_Sp%C3%A4tantike > - Wissen kann innerhalb relativ kurzer Zeit verloren gehen Habe ich neulich erst gesehen: die Jugend ist zu dumm geworden um sich richtig bei Kälte und Nässe draussen zu kleiden. Rennt im kalten Regen kilometerweit im Pullover ohne Mütze oder sowas...
Alex G. schrieb: > Wenn nicht grade die Religion dazwischen funkt (Mittelalter), > entwickelt sich Technik immer weiter. Geschichte wiederholt sich.
> Habe ich neulich erst gesehen: die Jugend ist zu dumm geworden um sich > richtig bei Kälte und Nässe draussen zu kleiden. Rennt im kalten Regen > kilometerweit im Pullover ohne Mütze oder sowas... Hab ich nicht erst neulich gesehen: Leute mit alten Knochen, die zu dumm geworden sind, um sich daran zu erinnern, dass man in jungen Jahren nicht so empfindlich war wie jetzt. Es gibt schlicht einige, die zumindest in jungen Jahren gut genug heizen, um die nicht so schnell zu frieren. Besonders wenn sie rennen. Dumm sind nicht diese, sondern die anderen.
:
Bearbeitet durch User
Beitrag #5599276 wurde vom Autor gelöscht.
S. R. schrieb: > Brauche ich nicht. Ich sehe eine Plattform als ein System an, das man für alle möglichen Dinge nutzen kann, inklusive Dinge die der Ersteller nie im Sinn hatte. Linux selbst ist ja wie bereits erwähnt ein gutes Beispiel dafür, aber natürlich auch Windows, der 8086-Prozessor usw. CPUs auf denen nur Android benutzt werden kann sind also eine sehr eingeschränkte Plattform; man kann damit eigentlich nur das 1000. Tablet oder Smartphone bauen, aber keine wirklich neue Anwendung. S. R. schrieb: > zusätzliche > Hardwaretreiber brauche ich also nicht. Manche Geräte haben einen USB-Anschluss, wo man zusätzliche Dinge anschließen kann, wenn man dafür einen Treiber hat... S. R. schrieb: > Gut dokumentierte > Chipsätze wird es auch weiterhin geben, Hoffentlich! Leider sind die jetzt schon so viel teurer (wie teuer ist eigentlich das Schreiben einer Doku?), dass der Wettbewerb einem das verbietet und man auf Android festgenagelt wird. S. R. schrieb: > In der großen Masse steht Embedded für Wenigzweckgeräte. Aber Android ist ein Vielzweck-System. Möchte man explizit ein Wenigzweck-Gerät, welches nur eine Aufgabe optimal erfüllt, muss man lange gegen Android/Linux kämpfen um alles loszuwerden, was man nicht braucht. S. R. schrieb: > Und wenn der Markt gute Dokumentation will, die Asiaten aber nicht > liefern, dann wird es auch Firmen in der westlichen Welt geben, die > diese Bedürfnisse befriedigen. Aber nur wenn die Nachfrage groß genug ist. Da der riesige Markt mit 0815-Mobilgeräten alles erdrückt, bleibt für Nischen-Anwendungen nicht mehr viel Spielraum... Alex G. schrieb: > Ob es deshalb soweit kommt wie in > http://archive.ncsa.illinois.edu/prajlich/forster.html ? Denke nicht. So war das nicht gemeint. Eher so, dass das Wissen bei der "Elektronik-Elite" in China gesammelt ist und der Rest der Welt mit "Ja, Amen" die Produkte kauft... Aber interessanter Text - erinnert an "The Naked Sun"... und Wall-E :-)
A. K. schrieb: > Michael X. schrieb: >> Was macht eigentlich der Hurd-Kernel? > > Wikipedia: "After years of stagnation, development picked up again in > 2015 and 2016, with four releases during these two years." > > Die Version 0.9 von Ende 2016 ist der letzte Stand. Was ist früher fertg? Die kommerzielle Nutzung der Kernfusion oder der Hurd-Kernel? ;-))
Michael X. schrieb: > Was ist früher fertg? Die kommerzielle Nutzung der Kernfusion oder der > Hurd-Kernel? ;-)) Der Berliner Airport.
Dr. Sommer schrieb: > Ich sehe eine Plattform als ein System an, das man für alle möglichen > Dinge nutzen kann, inklusive Dinge die der Ersteller nie im Sinn hatte. Das ist richtig, aber als Unternehmen, was die Hardware verkaufen will, bin ich der Ersteller und kümmere mich natürlich nur um die Dinge, die ich im Sinn habe. Die Hardware ist aus meiner Sicht zweckgebunden. Wäre dem nicht so, käme ich als Unternehmen schnell in rechtliche Probleme. > CPUs auf denen nur Android benutzt werden kann sind also eine > sehr eingeschränkte Plattform; man kann damit eigentlich nur > das 1000. Tablet oder Smartphone bauen, aber keine wirklich > neue Anwendung. Das ändert sich auch - siehe z.B. Android TV oder Android Things. Aber: Wenn mein Firmenprodukt das Telefon XY oder der Fernseher YX sind, und der Markt Android haben will (bzw. die Kunden, bzw. die Content-Provider), dann kaufe ich einen Android-fähigen Chipsatz mit Android-fähiger Software und Android-fähiger Zertifizierung und baue das restliche Produkt. >> zusätzliche Hardwaretreiber brauche ich also nicht. > > Manche Geräte haben einen USB-Anschluss, wo man zusätzliche Dinge > anschließen kann, wenn man dafür einen Treiber hat... Korrekt, aber irrelevant. Als Unternehmen steht es mir frei, eine Kompatiblitätsliste unterstützter Hardware mitzuliefern. Ab einer gewissen Unternehmensgröße ist alles andere auch ein unnötiges Risiko. Davon abgesehen steht es mir (noch) frei, Ressourcen zu investieren und die entsprechenden Treiber in den vorhandenen Kernel rückzuportieren. >> Gut dokumentierte Chipsätze wird es auch weiterhin geben, > > Hoffentlich! Leider sind die jetzt schon so viel teurer (wie teuer ist > eigentlich das Schreiben einer Doku?), dass der Wettbewerb einem das > verbietet und man auf Android festgenagelt wird. Einen UART-Treiber für drei Anwendungsfälle schreibt dir ein fähiger Ingeneur recht schnell runter. Die Dokumentation für den UART-Block zu schreiben, inklusive aller Rand- und Sonderfälle, sowie das Verhalten im Fehlerfall kann schonmal ein paar Monate in Anspruch nehmen. Zumindest, wenn die Doku auch einigermaßen korrekt sein soll. Doku schreiben dauert wesentlich länger als die Entwicklung, wenn man nicht gerade auf unvorhergesehene Probleme stößt oder die Hardware selbst entwickelt hat. >> In der großen Masse steht Embedded für Wenigzweckgeräte. > Aber Android ist ein Vielzweck-System. Ein Router ist kein Vielzwecksystem. Eine IoT-Haustürklingel ist kein Vielzwecksystem. Und an sich ist auch Android - das vom Hersteller vorgesehene - auch nur ein Ein-Zweck-System: Nämlich "Apps ausführen". Es ist genaustens festgelegt, was die Apps können dürfen, welche APIs sie wie benutzen dürfen und auch, welche Apps es für dein Gerät überhaupt geben darf (ohne Root). Damit unterscheidet es sich von einer Linux-Distribution, die man beliebig anpassen kann. Android ist für den Kunden nicht offen (es ist nur konfigurierbar). Auch eine Router- oder Festplattenfirmware ist es nicht. >> Und wenn der Markt gute Dokumentation will, die Asiaten aber nicht >> liefern, dann wird es auch Firmen in der westlichen Welt geben, die >> diese Bedürfnisse befriedigen. > Aber nur wenn die Nachfrage groß genug ist. Da der riesige Markt mit > 0815-Mobilgeräten alles erdrückt, bleibt für Nischen-Anwendungen nicht > mehr viel Spielraum... So ist die Welt nunmal, da kannst du hoch und niedrig hüpfen. Entweder, du bezahlst die Dokumentation, du bezahlst jemanden, der sie für dich schreibt, oder du verzichtest drauf. Was du - als Unternehmen mit einem Produkt - auch kannst. Internes Reverse-Engineering ist möglicherweise trotz Vertrag billiger, als an die Dokumentation zu kommen... > Eher so, dass das Wissen bei der "Elektronik-Elite" > in China gesammelt ist und der Rest der Welt > mit "Ja, Amen" die Produkte kauft... Ist doch jetzt schon so. Und glaubst du ernsthaft, dass RISC-V daran irgendwas ändern wird?
H-G S. schrieb: > Habe ich neulich erst gesehen: die Jugend ist zu dumm geworden um sich > richtig bei Kälte und Nässe draussen zu kleiden. Rennt im kalten Regen > kilometerweit im Pullover ohne Mütze oder sowas... Das liegt eher an der "Seht her, ich bin der unsterbliche Superheld auf den die Welt gewartet hat" Einstellung einiger Teenager. Das vergeht. Bei manchen dauert das bis zum Ü30 Alter.
Dr. Sommer schrieb: > Manche Geräte haben einen USB-Anschluss, wo man zusätzliche Dinge > anschließen kann, wenn man dafür einen Treiber hat... Da sagst du was. In meinem Haushalt hat fast jedes Gerät USB Anschlüsse und bei einigen habe ich (mangels Doku) keinen blassen Schimmer, wozu der gut ist. Schlimmer noch: Die Bedienungsanleitung meines TV Receivers fordert mich auf, ein Netzwerkkabel anzuschließen. Wozu, steht da aber nicht drin. Auch hier konnte ich keine relevante Funktion im Menü und auf der Fernbedienung entdecken. Eigentlich fehlt nur noch, das der nächste Gasherd einen USB-Anschluss bekommt und sich per WLAN automatisch vernetzt. Bis dahin sind die WLAN Router dazu passend so weit "fortgeschritten", dass sich alle Geräte vollautomatisch anmelden können und man das absichtlich nicht mehr verhindern kann. Meine Tochter fand neulich ein buntes Plastik-Tier mit USB Stecker auf der Straße und wollte das an ihren Laptop stecken. Ich konnte sie gerade noch bremsen.
Stefanus F. schrieb: > Schlimmer noch: Die Bedienungsanleitung meines TV Receivers fordert mich > auf, ein Netzwerkkabel anzuschließen. Wozu, steht da aber nicht drin. > Auch hier konnte ich keine relevante Funktion im Menü und auf der > Fernbedienung entdecken. Das wird auch nicht für dich sein, sondern fürs Gerät und den Hersteller. Für Autoupdate, und für die Protokollierung deiner Sehgewohnheiten. Sowas muss heute einfach sein.
A. K. schrieb: > Das wird auch nicht für dich sein, sondern fürs Gerät und den > Hersteller. Für Autoupdate, und für die Protokollierung deiner > Sehgewohnheiten. Sowas muss heute einfach sein. Ja, wenn man denn ein Autoupdate bekäme. Meiner flippte aus, als die Sender damit begannen, Umlaute in ihren Namen zu benutzen. Das Update musste ich per Email erbetteln und dann über einen seriellen Port installieren. Dazu musste ich mir auch noch ein Adapterkabel kaufen (mit RS232 Pegeln). Heute musst du bei jedem Kauf damit rechnen, Schrott zu bekommen.
Tim . schrieb: > Fakt ist: RISC-V wird sich über chinesische Firmen mit unerwarteter > Geschwindigkeit ausbreiten. Und hier kommen die Produkte auch schon. Eine RISC-V MCU im STM32F103 Format. Sehr spannend, damit könnte Gigadevice endgültig den Ruf als "China-Clonefirma" abschütteln. https://www.cnx-software.com/2019/08/23/gigadevice-gd32v-risc-v-mcu-development-board Der Prozessor von Alibaba wurde schon woanders erwähnt: Beitrag "Xuan Tie 910: Erster 16-Kern RISC-V-Prozessor kommt aus China" Sehr interessant ist auch der Huangshan No.1 von Xiaomi. Anscheinend der erste RISC-V prozessor, der in einem Hochvolumen-Konsumerprodukt verwendet wird. https://www.eefocus.com/consumer-electronics/442089 https://www.gizmochina.com/2019/06/10/xiaomi-mi-band-4-likely-to-use-huamis-risc-v-based-huangshan-no-1-chip/ https://riscv.org/2019/06/eefocus-article-huami-technology-huangshan-no-1-chip-is-currently-using-the-future-or-open-cooperation/
:
Bearbeitet durch User
Angehängte Dateien:
Beim Produktmarketing kopiert GD allerdings trotzdem noch STM...
>A few years ago, we came across GigaDevice GD32 microcontroller compatible >with
STMicro STM32F103, but with a higher 108 MHz clock, and zero wait >state internal
flash. The MCU was also a drop-in replacement for the >STMicro alternative since
beside being software compatible, it was also >pin-to-pin compatible.
Dem Prozessor die Kennung F103 zu geben ist schon ein wenig frech
gegenüber STM. Aber zum Glück gibt's wahrscheinlich keine Namensrecht
auf Zahlen.
Aber: Bewundernswert, wie schnell die Chinesen am Markt sind.
Tim . schrieb: > Tim . schrieb: >> Fakt ist: RISC-V wird sich über chinesische Firmen mit unerwarteter >> Geschwindigkeit ausbreiten. > > Und hier kommen die Produkte auch schon. > > Eine RISC-V MCU im STM32F103 Format. Sehr spannend, damit könnte > Gigadevice endgültig den Ruf als "China-Clonefirma" abschütteln. Langsam wird es spannend. Bisher war ja China-µC immer eher mit Einschränkungen verbunden, aber hier reden wir jetzt von einem modernen 32Bitter mit Flash. Fehlt noch eine ordentliche Doku in Englisch (bisher nicht die Stärke der Chinesen). Wenn das und der Preis stimmen, wird für "unsere" Hersteller die Luft ziemlich dünn. Vermutlich werden sich die in 10 Jahren auf die ganzen durch Normen und Zertifizierungen zernagelten Märkte (Automotive, Medical, Aerospace) zurückziehen.
jemand schrieb: > Tim . schrieb: >> Tim . schrieb: >>> Fakt ist: RISC-V wird sich über chinesische Firmen mit unerwarteter >>> Geschwindigkeit ausbreiten. >> >> Und hier kommen die Produkte auch schon. >> >> Eine RISC-V MCU im STM32F103 Format. Sehr spannend, damit könnte >> Gigadevice endgültig den Ruf als "China-Clonefirma" abschütteln. > > Langsam wird es spannend. > > Bisher war ja China-µC immer eher mit Einschränkungen verbunden, aber > hier reden wir jetzt von einem modernen 32Bitter mit Flash. Fehlt noch > eine ordentliche Doku in Englisch (bisher nicht die Stärke der > Chinesen). Du hast Dich als Deutscher daran gewöhnt englische Datenblätter zu lesen. Datenblätter für STM32 in deutsch gibts wohl eher gar nicht, ich würde mal vermuten das Du Dich jetzt an chinesische gewöhnen mußt, weil die Innovation nicht mehr aus dem englischsprachigen Raum kommt, aus dem deutschsprachigen schon gar nicht. > > Wenn das und der Preis stimmen, wird für "unsere" Hersteller die Luft > ziemlich dünn. Ach? Was dachtest Du ist mit "Globalisierung" gemeint gewesen? Gruß, Holm
Holm T. schrieb: > Du hast Dich als Deutscher daran gewöhnt englische Datenblätter zu > lesen. Englisch ist die internationale Sprache in der Elektronik. Das ist nun einemal so, auch wenn ich persönlich auch lieber deutsche Datenblätter hätte. Weil man es in der Schule lernt, und ich privat teils englische Bücher und Filme sehe, hatte ich auch nie ein Problem damit. Selbst unsere deutschen Herstelller (Infineon) liefern nur englische Datenblätter, und von vielen Asiaten (Taiwan, Japan...) bekommt man auch englische Datenblätter in guter Qualität. Ich weiß ja nicht, wie du dir das vorstellst, soll man als Entwickler sich weiger, Produkte mit englischen Datenblättern zu verwenden? Oder was soll dein anklagender Tonfall sonst aussagen?
jemand schrieb: > Holm T. schrieb: >> Du hast Dich als Deutscher daran gewöhnt englische Datenblätter zu >> lesen. > > Englisch ist die internationale Sprache in der Elektronik. Das ist nun > einemal so, auch wenn ich persönlich auch lieber deutsche Datenblätter > hätte. Du hast Nichts begriffen. Deutsch war mal die Sprache der Wissenschaft, das ist Geschichte. Innovation kommt nun auch nicht mehr aus der "alten Welt", fast alle Elektronik kommt aus Asien, warum sollten die Chinesen Datenblätter für das Zeug das sie zum großen Teil nur selbst verbauen nach englisch übersetzen? Für irgendwelche Holtec LED/LCD Controller Chips gibts die DBs jetzt schon nur in chinesisch. > Weil man es in der Schule lernt, und ich privat teils englische > Bücher und Filme sehe, hatte ich auch nie ein Problem damit. Genau. Ich habe englisch in der Schule nicht gelernt, kanns aber indessen verständlich schreiben und problemlos lesen, sprechen kann ichs eher schlecht aber auch da verstehen mich die Leute. Nun lerne halt chinesisch wenn Du was wissen willst, so einfach ist das. > > Selbst unsere deutschen Herstelller (Infineon) liefern nur englische > Datenblätter, und von vielen Asiaten (Taiwan, Japan...) bekommt man auch > englische Datenblätter in guter Qualität. Weiß ich, wobei Infinion? Ist das Kunst oder kann das weg? Ich designe von Denen Nichts ein, macht zu viel Ärger bei der Beschaffung in Kleinmengen, die haben es nämlich irgendwie nicht nötig...wegen Reichtum geschlossen. > > Ich weiß ja nicht, wie du dir das vorstellst, soll man als Entwickler > sich weiger, Produkte mit englischen Datenblättern zu verwenden? > Oder was soll dein anklagender Tonfall sonst aussagen? Ich habe keinen anklagenden Tonfall, ich versuche Dir nur klar zu machen wohin der Hase läuft. Niemanden interessieren Deine Befindlichkeiten über die Sprache in der chinesische Controller-DBs abgefaßt sind, lies sie oder lasse es. Keine Hände, keine Kekse. Gruß, Holm, der auch russische Datenblätter liest.
Holm T. schrieb: > Deutsch war mal die Sprache der Wissenschaft, das ist Geschichte. Bedank dich bei den Nazis. Die haben viele Menschen mit Hirn verscheucht oder umgebracht. Beispiel gefällig? Lise Meitner, Einstein. Im Übrigen hindern niemand deutsche Firmen daran, eigene RISC-V-µC zu entwickeln. Nur was haben wir in Deutschland? Infineon. Deren XMC-Serie scheint mir auch ein Rohrkrepierer gewesen zu sein. Der Grund war aus meiner Sicht aber nicht, dass die schlecht wären. Wir wollten die einsetzen, sie sind definitiv brauchbar. Aber wer zwar vollmündig ankündigt aber nicht liefert fliegt halt raus. Wenn man 10 Jahre nach allen anderen Herstellern kommt, bleibt halt nicht mehr viel Markt übrig. Im Übrigen ist das aggressive Bejammern von vergangener Größe eine Eigenschaft, die ich an meinen Landsleuten nicht schätze. Wie dein Beitrag auf mich wirkt: https://www.youtube.com/watch?v=kV4vHpqrj6E Tut mir leid, aber so ist es.
Holm T. schrieb: > Nun lerne halt chinesisch wenn Du was wissen willst, so einfach ist das. Englich ist so einfach, das lernt man ja ganz von selbst. Chinesisch ist viel komplizierter, das lernt man nie auch nur halb.
Die Geschichte dass Chinesisch die Pflichtsprache der Zukunft wird, erzählt man nun allerdings schon seit 15 Jahren...
Alex G. schrieb: > Die Geschichte dass Chinesisch die Pflichtsprache der Zukunft wird, > erzählt man nun allerdings schon seit 15 Jahren... Das reicht nicht. Als Sprache der Zukunft erzählte man sich das im Westen schon in der 70ern, als Alternative zu russisch. Wenngleich nicht immer bierernst. Ich weiss nur nicht mehr, was davon die pessimistische und was die optimistische Variante war.
:
Bearbeitet durch User
Naja, es ist nicht so, als würde nur in China Elektronik entwickelt - das passiert durchaus auch anderswo - natürlich bevorzugt in Asien. Allerdings gab es schon bisher von fast allen rein chinesischen Produkten annehmbare englischsprachige Datenblätter, was der These "Friss oder stirb" deutlich widerspricht. Natürlich wollen die Chinesen ihre Chips auch an andere liefern und sorgen dafür natürlich für englischsprachige DBs. Die ersten DBs und manche von kleinen Krautern sind schlimm gewesen - aber mittlerweile sind die DBs wirklich annehmbar. Also: selbstverständlich wird es bei entsprechender Nachfrage (und die wird kommen) auch englischsprachige DBs geben. Die Kosten für eine vernünftige englischsprachige Doku gehen doch im Rauschen unter - erst Recht bei dem zu erwartenden Umsatz im anderssprachigen Ausland.
jemand schrieb: > Im Übrigen hindern niemand deutsche Firmen daran, eigene RISC-V-µC zu > entwickeln. Nur was haben wir in Deutschland? Trinamic? Die verwenden RISC-V aber nur für ihre eigenen ICs, d.h. einen RISC-V-Prozessor zum selber Programmieren bekommt man da nicht.
jemand schrieb: > Fehlt noch > eine ordentliche Doku in Englisch (bisher nicht die Stärke der > Chinesen). Die Dokus von GD32 sind zum Glück in Englisch. Beispiel: http://gd32mcu.21ic.com/en/down/document_id/181/path_type/1 oder hier: http://gd32mcu.21ic.com/en/down/document_id/136/path_type/1 Über die Qualität des Englischen kann man streiten, aber immerhin... zumindest mal ein Anfang. Was allerdings unter aller Sau ist ist die Qualität der mitgelieferten Header bzw. svd-Dateien und die fehlende Dokumentation von deren Peripheral Library (nur ein dürres Doxygen-Gerüst ohne Fleisch auf den Rippen, alles wesentliche fehlt, auch für brandneue Devices wie den GD32F350) bis hin zu Tippfehlern in Funktionsnamen ("sofeware" statt "software" und das HABEN die bemerkt denn der zeitgleich veröffentlichte Demo-Code benutzt die Funktionen samt der Tippfehler) Der einzige Strohhalm an den man sich klammern kann um die Benutzung der Library zu verstehen sind die handvoll Demoprogramme. Oder stundenlanges Reverse-Engineering der Library für jedes scheiß Bit das dort noch ein zweitesmal unter anderem Namen definiert ist! Im gleichen Namensraum wie die CMSIS-Namen, wild gemischt! Programmierung auf Registerebene geht mit Schmerzen, ist sehr anstrengend aufgrund der Struktur ihrer Header und aufgrund der Tatsache daß sie die extrem chaotische STM32-Peripherie benutzen bei der man eh schon nah am Wahnsinn vorbeischrammt. Und natürlich null Kundenkommunikation. Ich habe einen schweren Bug in der SVD-Datei gemeldet der sie in GNU-MCU unbenutzbar macht und habe auch nach Monaten noch keine Ticket-Nummer oder sonstige Bestätigung daß es woanders als in Ablage Rund gelandet ist. Die haben wahrscheinlich gar kein Ticketsystem und wursteln nur so planlos in der Gegend herum. Und es gibt keine Community, kein Nutzerforum wo man Fragen loswerden kann oder Antworten findet, wenn man nicht gerade einen von deren STM32-Klonen benutzt und dann einfach das vorhandene STM32-Ökosystem anzapfen kann steht man vollkommen allein gelassen da! Und es scheint ihnen auch am Arsch vorbei zu gehen daß ihr Zeug (vor allem das neue) von Segger nicht unterstützt wird. Segger J-Link ist der De-Facto-Standard, wie bitteschön wollen die damit leben daß die Hälfte ihrer Produktpalette mit dem J-Link-Adapter nicht verwendet werden kann? Man kann Unterstützung neuer Hardware für J-Link als externes Modul selbst implementieren damit man nicht auf Segger warten muß, also das wär ja wohl das mindeste was sie tun könnten ein J-Link-Plugin mitliefern damit der Anwender seinem eigenen J-Link die GD32 Prozessoren beibringen kann. Und den Source davon an Segger schicken damit sie es irgendwann einpflegen und nicht selber schreiben müssen. Nichts davon geschieht! Ich hab etwas gemischte Gefühle was GigaDevice angeht. Man bekommt zwar nen M4 mit 108MHz für nen halben Dollar, was zwar toll ist, vor allem für meinen Boss der das will, aber die Arbeit damit echt kein Zuckerschlecken, das kann ich euch versprechen! Ich habe früher jahrelang mit Freescale Kinetis gearbeitet und jetzt seit nem halben Jahr mit GigaDevice und ich empfinde die ganze Experience jetzt im Vergleich zu früher massiv schlechter. Alles ist schlechter geworden. Die Doku, die Header, sogar die Organisation der Peripherieregister ist im Vergleich zu Kinetis ein einziges Chaos, die Community (nicht existent) die Dokumentation (nur das nötigste) der Spaß beim Programmieren ist abhanden gekommen, nur noch Ärger mit dem Mist.
:
Bearbeitet durch User
Beitrag #5949216 wurde von einem Moderator gelöscht.
Bernd K. schrieb: > Programmierung auf Registerebene geht mit Schmerzen, ist sehr > anstrengend aufgrund der Struktur ihrer Header und aufgrund der Tatsache > daß sie die extrem chaotische STM32-Peripherie benutzen bei der man eh > schon nah am Wahnsinn vorbeischrammt. Darf ich mal Fragen was dich dort schmerzt? Die Registerebene find ich ganich mal so übel bei der STM32 periph.
Bernd K. schrieb: > Und es scheint ihnen auch am Arsch vorbei zu gehen dass ihr Zeug (vor > allem das neue) von Segger nicht unterstützt wird. Segger J-Link ist der > De-Facto-Standard, wie bitteschön wollen die damit leben dass die Hälfte > ihrer Produktpalette mit dem J-Link-Adapter nicht verwendet werden kann? Einiges an Support haben wir bereits bzw. arbeiten gerade daran. Hier ist eine List von GigaDevice Cortex-M und RISC-V Devices, die bereits vom J-Link unterstützt werden: https://www.segger.com/downloads/supported-devices.php Embedded Studio Packages gibt es auch schon und embOS Board Support Packages machen wir gerade.
Bernd K. schrieb: > Ich habe früher jahrelang mit Freescale Kinetis gearbeitet und jetzt > seit nem halben Jahr mit GigaDevice und ich empfinde die ganze > Experience jetzt im Vergleich zu früher massiv schlechter. Der Vollständigkeit halber muß ich jedoch auch orakeln daß jemand der sein ganzes Leben lang STM32 bare metal ohne HAL gemacht hat und somit mit allen Wassern gewaschen ist beim Umstieg auf GD32 mit Sicherheit keinen derart extremen Absturz in der Produktivität und der Gesamterfahrung erleiden wird wie jemand der wie ich von Kinetis kommt, immerhin sind auch alle neuen GD32 (auch die nicht-Klone!) vollgestopft mit altbekannter Peripherie die aus existierenden STM32 zusammengesammelt ist, nur die Registernamen und Bitnamen sind konsequent anders, die Funktion ist komplett identisch. Für den angekündigten RISC-V Controller von GD32 (noch dazu wenn er die verräterischen Ziffern F103 am Ende seiner Typenbezeichnung hat) erlaube ich mir vorherzusagen daß es wahrscheinlich bis aufs i-Tüpfelchen ein STM32F103 mit all dessen Peripherie aber mit anderem Rechenkern sein wird. So ticken die bei GD. Wer also von STM32 kommt wird wohl weniger Schmerzen leiden als einer der von komplett anderswo kommt.
Til S. schrieb: > Einiges an Support haben wir bereits bzw. arbeiten gerade daran. > Hier ist eine List von GigaDevice Cortex-M und RISC-V Devices, die > bereits vom J-Link unterstützt werden: > https://www.segger.com/downloads/supported-devices.php Ich habe leider den GD32F350 Das ist wohl eins von deren neueren Modellen. Momentan behelfe ich mir indem ich dem J-Link sage es sei ein GD32F170, der hat den selben Flash-Controller und die selbe Sektorgröße aber einen M3 statt M4. Das gibt eine Warnung in der Konsole aber ansonsten kann ich problemlos flashen und debuggen. @Eclipse-Nutzer: Deren SVD-Datei hat 2 überflüssige Leerzeichen am Dateianfang, wenn man die entfernt kann man auch in Eclipse GNU MCU beim Debuggen die Peripherie-Ansicht benutzen, dafür muss in den Projekteinstellungen natürlich der richtige Controller stehen, nur in den Debuggereinstellungen muss man (falls nötig wie bei mir) die gefakete Typenbezeichnung für J-Link eintragen.
Mw E. schrieb: > Darf ich mal Fragen was dich dort schmerzt? > Die Registerebene find ich ganich mal so übel bei der STM32 periph. Beispiel Timer: Bei Kinetis (meine Meßlatte bislang) ist alles in erster Ordnung nach Kanal und in zweiter Ordnung nach Funktion sortiert, bei STM ist alles es in erster Ordnung nach Funktion und in zweiter Ordnung dann nach Kanal (mit unterschiedlichen shifts im selben Register) und das strengt tierisch an. Bei STM32 werden n mal 4 Bit oder n mal 2 bit oder n mal 1 bit in ein und das selbe Register gequetscht, als ob zusätzliche Register Geld kosten würden, bei einem Timer mit n Kanälen sind dann alle Einstellungen für einen Kanale kreuz und quer über alle Register verstreut und wechselst Du den Kanal musst Du alle Konfigbits austauschen weil die für den anderen Kanal alle andere shifts haben. Bei Kinetis hatte jeder Kanal eine identische Struktur an unterschiedlichem Offset, jedes Config-Bit define gabs nur genau einmal und konnte unverändert in jedem Kanal verwendet werden und war nicht für jeden Kanal anders geshiftet. Das hat auch die Gesamtzahl der defines für bits um gefühlt Faktor 6 reduziert. Das zieht sich wie ein roter Faden durch die ganze Periperie. Bei STM32 findet man auch an etlichen Stellen Werte die sich auf 2 Register aufteilen, zum Beispiel die niederwertigsten 3 Bits werden hier irgendwo mit reingequetscht und die höherwertigen 2 kann man noch woanders mit unterbringen. Insgesamt finde ich den Umgang damit im direkten Vergleich zu den großzügig aufgelockerten und nach Kanälen sortierten Registern bei Kinetis sehr nervenaufreibend und verkrampft. Und dazu kommt natürlich noch bei GigaDevice (und das zusammen mit der Registerorganisation ist eine sehr unglückliche Kombination) deren vollkommen beknackter Header-Stil (nicht struct basiert wie man das heute macht) und wenn man sich CMSIS-Header aus dem SVD selber generieren will merkt man daß die ein völlig veraltetes SVD-Format benutzen das auch nicht ganz den erhofften Effekt erzielt. Die Kombination STM32-Registerstruktur und veraltetem GD32 Header Stil und dazwischen noch die ganzen Defines für ihre Library mit kollidierenden Namenspräfixen macht es echt zur Qual. Auf einem reinen STM32 mit echten STM32-Headern ist es wahrscheinlich wesentlich weniger anstrengend. Und am wenigsten anstrengend ist Registerprogrammierung auf einem Kinetis ;-)
jemand schrieb: > Holm T. schrieb: >> Deutsch war mal die Sprache der Wissenschaft, das ist Geschichte. > > Bedank dich bei den Nazis. Die haben viele Menschen mit Hirn verscheucht > oder umgebracht. Beispiel gefällig? Lise Meitner, Einstein. > > Im Übrigen hindern niemand deutsche Firmen daran, eigene RISC-V-µC zu > entwickeln. Nur was haben wir in Deutschland? Infineon. > > Deren XMC-Serie scheint mir auch ein Rohrkrepierer gewesen zu sein. Der > Grund war aus meiner Sicht aber nicht, dass die schlecht wären. Wir > wollten die einsetzen, sie sind definitiv brauchbar. Aber wer zwar > vollmündig ankündigt aber nicht liefert fliegt halt raus. > Wenn man 10 Jahre nach allen anderen Herstellern kommt, bleibt halt > nicht mehr viel Markt übrig. Exakt das meinte ich, bei denen sitzt Du nicht in der ersten Reihe, sondern bist Schütze Arsch im letzten Glied. So lange das denen bekommt ist das auch in Ordnung so..anderenfalls würden die sich ja um kostenlose Compiler und Support kümmern, oder? > > Im Übrigen ist das aggressive Bejammern von vergangener Größe eine > Eigenschaft, die ich an meinen Landsleuten nicht schätze. Ich bejammere das nicht, ich habe festgestellt. Ich bin alt genug das mir das total Rille ist und wenn es hier so weiter geht kommen Neuentwicklungen nur noch in der Form vom Kamel- und Schafsrassen, Burkas und fliegenden Teppichen aus Deutschland. > > Wie dein Beitrag auf mich wirkt: > https://www.youtube.com/watch?v=kV4vHpqrj6E > Tut mir leid, aber so ist es. Hast Du wirklich das Gefühl ich beklage mich über Irgendwas? Das hast Du eindeutig falsch verstanden, nochmal: ich stelle fest, das ist bereits Alles. Ich habe nur meine Meinung zu Infinion bekannt gegeben, die wollen mich nicht, also will ich die nicht. Ich will denen nichts verkaufen und so wie es aussieht die auch mir nicht und damit auch nicht meinen Kunden. Übrigens: Es ist definitiv nicht so das ich mir aus der Meinung eines "Jemand" oder "Niemand" oder eines anderen namenlosen Gastes über mich irgend Etwas machen würde, die ist mir ganz schlicht egal. Warum sollte ich mir Mühe geben irgendwelchen Leuten, die ich nicht kenne und die auch nicht wollen das ich sie kenne, gefallen zu wollen? Ist doch ein Bisschen viel verlangt meinst Du nicht? Gruß, Holm
DPA schrieb: > Holm T. schrieb: >> Nun lerne halt chinesisch wenn Du was wissen willst, so einfach ist das. > > Englich ist so einfach, das lernt man ja ganz von selbst. Chinesisch ist > viel komplizierter, das lernt man nie auch nur halb. Ja..und? Glaubst du die Chinesen hebt das vom Sessel? ..aus Mitleid? Gruß, Holm
A. K. schrieb: > Alex G. schrieb: >> Die Geschichte dass Chinesisch die Pflichtsprache der Zukunft wird, >> erzählt man nun allerdings schon seit 15 Jahren... > > Das reicht nicht. Als Sprache der Zukunft erzählte man sich das im > Westen schon in der 70ern, als Alternative zu russisch. Wenngleich nicht > immer bierernst. Ich weiss nur nicht mehr, was davon die pessimistische > und was die optimistische Variante war. ..das ist auch völlig egal. Hier wurde bemängelt das den Chinesen englisch fehlt ...zu was eigentlich? Damit sie nach D 3 Controller mehr verkaufen? "Jemand" wollte das Datenblatt in englisch haben, damit ist doch klar wer hier Bedarf an was hat. Gruß, Holm
Bernd K. schrieb: > Bernd K. schrieb: >> Ich habe früher jahrelang mit Freescale Kinetis gearbeitet und jetzt >> seit nem halben Jahr mit GigaDevice und ich empfinde die ganze >> Experience jetzt im Vergleich zu früher massiv schlechter. > > Der Vollständigkeit halber muß ich jedoch auch orakeln daß jemand der > sein ganzes Leben lang STM32 bare metal ohne HAL gemacht hat und somit > mit allen Wassern gewaschen ist beim Umstieg auf GD32 mit Sicherheit > keinen derart extremen Absturz in der Produktivität und der > Gesamterfahrung erleiden wird wie jemand der wie ich von Kinetis kommt, > immerhin sind auch alle neuen GD32 (auch die nicht-Klone!) vollgestopft > mit altbekannter Peripherie die aus existierenden STM32 > zusammengesammelt ist, nur die Registernamen und Bitnamen sind > konsequent anders, die Funktion ist komplett identisch. > > Für den angekündigten RISC-V Controller von GD32 (noch dazu wenn er die > verräterischen Ziffern F103 am Ende seiner Typenbezeichnung hat) erlaube > ich mir vorherzusagen daß es wahrscheinlich bis aufs i-Tüpfelchen ein > STM32F103 mit all dessen Peripherie aber mit anderem Rechenkern sein > wird. So ticken die bei GD. > > Wer also von STM32 kommt wird wohl weniger Schmerzen leiden als einer > der von komplett anderswo kommt. Sehe ich ganz exakt genauso und kann nichts Mieses dran finden. Gruß, Holm
Tja, Wenn die Chinesen ihren Prozessor billig anbieten, die Toolchain kostenlos dazuliefern, Die lizensierung vereinfachen, open Source, keine Royalities, dann werden sie den Markt aufrollen und keiner wird sie daran hindern können. Übrigens, war die Raketenforschung auch einmal deutschsprachig. Aber Forschung ist teuer, und die Chinesen habends fast umsonst übernommen und abgekupfert, und sie werden bald besser sein als der Rest der Welt... mfg
jemand schrieb: > Wie dein Beitrag auf mich wirkt: > Youtube-Video "mimi muppet" > Tut mir leid, aber so ist es. Ich finde den eine angemessene Zusammenfassung der Gesamtsituation. Ein mimimi sieht anders aus. Alex G. schrieb: > Die Geschichte dass Chinesisch die > Pflichtsprache der Zukunft wird, erzählt > man nun allerdings schon seit 15 Jahren... Von der Pflichtsprache ist es weit weg, aber hier in Schweden wird Mandarin zunehmend an den Gymnasien als moderne Fremdsprache angeboten - und das Angebot wird auch gern angenommen. Deutsch als Fremdsprache wird immer unwichtiger. Chris D. schrieb: > Allerdings gab es schon bisher von fast allen rein chinesischen > Produkten annehmbare englischsprachige Datenblätter, was der These > "Friss oder stirb" deutlich widerspricht. Logisch, denn Koreaner, Japaner oder Thai können auch kein chinesisch. Englisch ist für internationale Waren die übliche Sprache für Datenblätter und wird es auf absehbare Zeit auch bleiben. ~Mercedes~ schrieb: > Wenn die Chinesen ihren Prozessor billig anbieten, Das wird passieren. > die Toolchain kostenlos dazuliefern, Die kommt aus Europa. Als Open Source und kostenlos. > Die lizensierung vereinfachen, open Source, keine Royalities, Welche Lizenzierung? Bisher verkaufen die Chinesen eher Dinge, das fällt unter Besitz. Die Amerikaner und Europäer verkaufen die zu lizenzierenden Ideen. Wird sich aber wahrscheinlich auch irgendwann ändern. > dann werden sie den Markt aufrollen und keiner > wird sie daran hindern können. Kann doch jetzt auch schon keiner. Die Fertigung findet dort statt. Selbst, wenn $FIRMA sagt, dass jetzt Schluss ist... weiterproduzieren können die Chinesen auch alleine. Weiterentwicklung ist eine andere Frage, denn das müssen sie größtenteils selbst lernen. Und inzwischen sind sie damit produktionsreif und teilweise konkurrenzfähig.
@Bernd K: Ist mir garnicht so sehr aufgefallen, aber jetz wo dus sagst! Da meine erste µC Generation der AVR war bin ich an sowas wohl schon zu sehr gewöhnt. Bei den Kinetis scheints da ja echt gut aufgeräumt zu sein, nur gibts die wohl nicht in Bastlerfreundlich. Das erinnert mich aber wieder an die Flag Register des STM32 DMA. DIE sind widerlich! Da hab ich ne Funktion drumgebaut um das nie wieder anfassen zu müssen. Jedenfalls hab ich mal geguckt die RISC-V F103er sind wohl noch nicht beim Ali aufgetaucht.
Open Source rockt schrieb: > mit dem Resultat, dass proprietäre Prozessorarchitekturen das selbe > Schicksal ereilt wie ihre Pendants auf Seite der Betriebssysteme? Was ist denn mit den proprietären OSen passiert? Hab ich irgendwas verpasst?
Le X. schrieb: > Was ist denn mit den proprietären OSen passiert? Die sind auf dem absteigenden Ast. Von 100% runter auf 98%, Tendenz weiter fallend.
Bernd K. schrieb: > Le X. schrieb: > Was ist denn mit den proprietären OSen passiert? > > Die sind auf dem absteigenden Ast. Von 100% runter auf 98%, Tendenz > weiter fallend. Ja Holla die Waldfee!
Bernd K. schrieb: > Das zieht sich wie ein roter Faden durch die ganze Periperie. Bernd, ich kann deine Kritik nachvollziehen. Aber wenn ST das mal aufräumen würde, hätten sie keinen Grund mehr, diese sogenannte (Cube) HAL zu vermarkten. Und dann wiederum würde es deren Kunden leichter fallen, auf andere Marken zu wechseln.
Selbst MS hat doch schon eingeraeumt, dass Win 10 das letzte Windows sein wird! Wer sich jetzt nicht umorientiert...
Mw E. schrieb: > Da meine erste µC Generation der AVR war bin ich an sowas wohl schon zu > sehr gewöhnt. Ja, AVR sind in dieser Hinsicht ebenso nervig strukturiert. Die meisten jedenfalls. Ab der Xmega Serie sieht es allerdings schon sehr viel aufgeräumter aus.
Maxe schrieb: > Selbst MS hat doch schon eingeraeumt, dass Win 10 das letzte Windows > sein wird! Wer sich jetzt nicht umorientiert... Das bedeutet aber keineswegs, dass MS damit Windows abgekündigt hat, sondern dass sämtliche Überarbeitungen unter dem Namen W10 erfolgen. Dadurch erspart sich MS die umfangreichen und teuren Marketingkampagnen für die Einführung einer neuen Produktversion in einem ohnehin gesättigten Markt. Und auf Kundenseite gibt es auch weniger Gejammer. Vermutlich hat MS erkannt, dass es sich nicht mehr lohnt, Kunden Upgrades auf neue Windows-Versionen bei vorhandenen Rechnern zu verkaufen, sondern eben Windows-Lizenzen nur noch für Neurechner. Falls MS das wirklich so konsequent durchziehen sollte, sähe W10 in zehn Jahren aber wahrscheinlich gänzlich anders aus als heute. Nach und nach werden mehr Funktionen in die Cloud verlagert, damit die Kunden die Hoheit über die eigenen Daten verlieren, ohne das durch ein Downgrade (oder unterlassenes Upgrade) verhindern zu können. Derzeit würde so etwas noch zu einem gewaltigen Aufschrei führen, aber sobald die politischen Parteien erkannt haben, dass sich durch solch ein Vorgehen auch das Volk besser kontrollieren lässt, werden die Datenschutzgesetze wieder abgeschafft werden.
Technisch muss es aber nach wie vor Versionsnummern geben. Die Versionsnummer muss man aber nicht bewerben. Tun andere auch eher selten. Insofern hätten sie es einfach "Windows" nennen können oder "Windows 1904". Das würde jeder verstehen. "Windows 10 Home OEM Version 1904 Build 4125125" finde ich hingegen arg anstrengend. Wenn wir mal ehrlich sind, ist dieser Versionswirrwarr mit Windows 10 noch komplizierter geworden, anstatt einfacher.
Das ist aus technischer Sicht völlig zutreffend, aber so etwas ist aus vertrieblicher und Marketingsicht irrelevant. Und wenn es bei größeren "einheitlichen" Installationen dann doch zu Versionskonflikten usw. kommt, rückt eben eine Horde Berater an, um das ganze wieder in Ordnung zu bringen. Und zwei Jahre später erneut, obwohl es sich formal immer noch um dasselbe Betriebssystem handelt. Der große Erfolg von SAP kommt ja auch nicht daher, dass deren R/3 aus der Tüte fällt und sich in fünf Minuten installieren lässt, sondern weil sie es einem ordentlichen Ökosystem an Beratern und Systemhäusern ermöglichen, anschließend und über sehr lange Zeit viel Geld zu verdienen.
Le X. schrieb: >> mit dem Resultat, dass proprietäre Prozessorarchitekturen das selbe >> Schicksal ereilt wie ihre Pendants auf Seite der Betriebssysteme? > > Was ist denn mit den proprietären OSen passiert? > Hab ich irgendwas verpasst? Es gibt drei proprietäre Betriebssysteme mit großem Marktanteil: Windows, MacOS und iOS. Alle anderen sind verschwunden oder auf dem Weg in die Versenkung - man denke an die kommerziellen Unixe (Xenix, OpenServer, Ultrix, HP/UX, Solaris, etc.), Mobilbetriebssysteme (Symbian, Nokia OS, webOS, etc.) oder Desktopsysteme wie OS/2. Sämtliche Systeme mit steigendem Marktanteil sind Open Source oder zu einem gewissen Grad freie Software: Linux, Android, Darwin, OpenSolaris, ... Ich weiß nicht, ob du was verpasst hast. Entweder verschlafen oder nie von gehört?
:
Bearbeitet durch User
S. R. schrieb: > Sämtliche Systeme mit steigendem Marktanteil sind Open Source oder zu > einem gewissen Grad freie Software: Linux, Android, Darwin, OpenSolaris, > ... > > Ich weiß nicht, ob du was verpasst hast. > Entweder verschlafen oder nie von gehört? Gehört schon, immerhin benutze ich selbst zuhause ausschließlich Linuxoide. Aber von einer nennenswerten Verbreitung oder einem nennenswerten Wachstum derselbigen wüsste ich jetzt nicht. Niedriger einstelliger Bereich, Tendenz stagnierend. Von Solaris oder BSD brauchen wir garnicht erst reden. Darwin ist auch nur mit der Apple-Infrastruktur brauchbar. Die komplett freien Smartphone OSe sterben bisher alle noch vor der Marktreife.
Le X. schrieb: > Niedriger einstelliger Bereich, Tendenz stagnierend. Entschuldige mal, aber der Linux Kern, auf dem alle Android Geräte aufsetzen, ist Open-Source. Ebenso weite Teile des Android Betriebssystems. Android ist jetzt nicht gerade am stagnieren.
Stefanus F. schrieb: > Entschuldige mal, aber der Linux Kern, auf dem alle Android Geräte > aufsetzen, ist Open-Source. Ja, gleiches Spiel wie bei Darwin. Ein Kernel ist kein OS sondern nur ein Puzzlestück im Gesamtsystem.
Le X. schrieb: > Ein Kernel ist kein OS sondern nur ein Puzzlestück im Gesamtsystem. Ja stimmt. Open-Source ist als Teil-Komponente allgegenwärtig, aber eher selten bei kompletten Softwareprodukten.
Andreas S. schrieb: > Maxe schrieb: >> Selbst MS hat doch schon eingeraeumt, dass Win 10 das letzte Windows >> sein wird! Wer sich jetzt nicht umorientiert... > > Das bedeutet aber keineswegs, dass MS damit Windows abgekündigt hat, Doch, es hat den Verkauf eines Betriebssystems für PC abgekündigt und verteilt dafür "kostenlos" Trojaner. > sondern dass sämtliche Überarbeitungen unter dem Namen W10 erfolgen. > Dadurch erspart sich MS die umfangreichen und teuren Marketingkampagnen Nicht zuletzt spart die NSA, die Daten werden eingeleifert (Telemetrie) statt umständlich irgendwelche Trojaner remote installieren zu müssen. Freilich ist die Nützlichket dieses Windows 10 für den Nutzer nicht immer gegeben, das fährt hoch und runter wie es will und zwingt den Nutzer die Datenlieferung an Microsoft zu ermöglichen. Microsoft behält sich per AGB vor, mit den Daten des Nutzers zu tun und zu lassen was es für richtig hält. > für die Einführung einer neuen Produktversion in einem ohnehin > gesättigten Markt. Du verkennst die Lage völlig, die aktive Spionage ist eine Weltneuheit! >Und auf Kundenseite gibt es auch weniger Gejammer. Ich habe früher mal irgendwann zwischen Weihnachten und Neujahr ziemlich viele Level Lemmings gespielt, das Verhalten der Nutzer kommt mir bekannt vor. > Vermutlich hat MS erkannt, dass es sich nicht mehr lohnt, Kunden > Upgrades auf neue Windows-Versionen bei vorhandenen Rechnern zu > verkaufen, sondern eben Windows-Lizenzen nur noch für Neurechner. Kein Wunder, als Betriebssystem ist der Kram ja auch eher untauglich, man fragt sich was zur Hölle mit der im Vergleich zu einem XT gigantischen Rechenleistung passiert, die Antwortzeiten in einer Textverarbeitung haben sich seit dem nicht verändert. > > Falls MS das wirklich so konsequent durchziehen sollte, sähe W10 in zehn > Jahren aber wahrscheinlich gänzlich anders aus als heute. -Man muß jedem reverse Engeneering Paroli bieten können, nicht ddas die Kunden noch erfahren was mit Ihren Daten da passiert. Demzufolge wird gepatcht was das Zeug hält, zwar oft inkompatibel zur Hardware, aber wass solls, hat ja "Nichts" gekostet... > Nach und nach > werden mehr Funktionen in die Cloud verlagert, damit die Kunden die > Hoheit über die eigenen Daten verlieren, ohne das durch ein Downgrade > (oder unterlassenes Upgrade) verhindern zu können. :-) Nee, ne? Wo ist der Unterschied zwischen einer Cloud und Windows 10 in Bezug auf die Kontrolle über die Daten und deren Sicherheit? > > Derzeit würde so etwas noch zu einem gewaltigen Aufschrei führen, aber > sobald die politischen Parteien erkannt haben, dass sich durch solch ein > Vorgehen auch das Volk besser kontrollieren lässt, werden die > Datenschutzgesetze wieder abgeschafft werden. Indessen schafft das Volk heimlich Windows ab. Gruß, Holm
Stefanus F. schrieb: > Ja stimmt. Open-Source ist als Teil-Komponente allgegenwärtig, aber eher > selten bei kompletten Softwareprodukten. Wenn eine Firma wie Apple oder google OSS einsetzen und weiterentwickeln hat das ja auch immer einen betriebswirtschaftlichen Hintergrund. Die machen das ja nicht weil sie so überzeugte FOSS-Enthusiasten sind. Und mit ihrem proprietären Userland/Infrastruktur sorgen die schon dafür das keiner ausbricht. Versteh mich nicht falsch, ich bin selber Freund und User von FOSS. Aber zu behaupten, es fände gerade ein Siegeszug der OS-OSen statt ist Wunschdenken, mehr nicht.
Stefanus F. schrieb: > Le X. schrieb: >> Niedriger einstelliger Bereich, Tendenz stagnierend. > > Entschuldige mal, aber der Linux Kern, auf dem alle Android Geräte > aufsetzen, ist Open-Source. Ebenso weite Teile des Android > Betriebssystems. > > Android ist jetzt nicht gerade am stagnieren. Mikeysoft jünger wollen Sowas nicht hören. Was ist mit WindowsCE? Wer verwendet den Schrott noch? Es gibt eine ganze Reihe Echtzeitkernel für embedded Appilances, oft läuft auch ein FreeBSD Abkömmling oder ein Linux. (Playstation, alle möglichen Router und Firewalls, ,Receiver, Fernseher etc. pp.) Gruß, Holm
Holm T. schrieb: > Andreas S. schrieb: >> Maxe schrieb: >>> Selbst MS hat doch schon eingeraeumt, dass Win 10 das letzte Windows >>> sein wird! Wer sich jetzt nicht umorientiert... >> >> Das bedeutet aber keineswegs, dass MS damit Windows abgekündigt hat, > > > Doch, es hat den Verkauf eines Betriebssystems für PC abgekündigt und > verteilt dafür "kostenlos" Trojaner. > >> sondern dass sämtliche Überarbeitungen unter dem Namen W10 erfolgen. >> Dadurch erspart sich MS die umfangreichen und teuren Marketingkampagnen > > Nicht zuletzt spart die NSA, die Daten werden eingeleifert (Telemetrie) > statt umständlich irgendwelche Trojaner remote installieren zu müssen. > Freilich ist die Nützlichket dieses Windows 10 für den Nutzer nicht > immer gegeben, das fährt hoch und runter wie es will und zwingt den > Nutzer die Datenlieferung an Microsoft zu ermöglichen. Microsoft behält > sich per AGB vor, mit den Daten des Nutzers zu tun und zu lassen was es > für richtig hält. > Na ENDLICH sind wir wieder beim MS bashing! Um es mal richtig zu stellen: Microsoft hat das Data Mining weder erfunden noch betreibt Microsoft das Data Mining am ärgsten. Wie alle grossen Softwarefirmen stand MS lediglich vor dem Dilemma, dass irgendwann mit Software mal kein Geld mehr nachhaltig zu machen ist. Als sich dann herausstellte, dass mit Big Data dagegen eine ständig sprudelnde Einkommensquelle brach lag, haben sie alle zugeschnappt. Das ist aber ein hausgemachtes Problem. Gäbe es nicht den DAU, der arglos seine Daten bereit ist in die Weltgeschichte zu spucken und der nicht versteht, dass ER die Ware ist, wenn's nichts kostet, ginge das nicht. Wenn ich es recht erinnere, hat es vor ca. 2 Jahren mal ein Gutachten darüber gegeben, wie gewissenhaft die Konzerne darin sind, den Benutzern die Option zu geben, der Weitergabe ihrer Daten NICHT zuzustimmen. MS hat zwar (wie fast Alle Anderen auch) den transparenten User zum Default gemacht, schneidet aber mit am Besten darin in, den user die Türen wieder zumachen zu lassen. Ihre Benutzer nacking ausziehen lassen und die Nacktfotos im Internet zu verscheuern ist das Geschäftsmodell JEDER Firma mit einer grossen Nutzerbasis. Aber es gehören immer 2 dazu: Die die es tun und die die es mit sich machen lassen. Wer also Windows installiert und NICHT als Allererstes alles wegklickt, was nach Data Mining riecht, soll sich nicht über das böse Data Mining beschweren.
Wenn ich das richtig verstehe, gibt's bals eine RiscV Bluepill: https://twitter.com/SipeedIO/status/1164500325119610887
Le X. schrieb: > Aber von einer nennenswerten Verbreitung oder einem nennenswerten > Wachstum derselbigen wüsste ich jetzt nicht. Schau mal in den Servermarkt oder in die Cloud, da sind Linux-Distributionen allgegenwärtig. Eine bekannte Linux-Distribution namens "Android" ist Marktführer bei Smartphones und Tablets. ChromeOS (ebenfalls Linux) wächst auch fröhlich vor sich hin. > Niedriger einstelliger Bereich, Tendenz stagnierend. Wenn du ausschließlich an den Desktop-PC denkst, dann ja. Alles eine Wahl der eigenen Scheuklappen.
Harald schrieb: > Wenn ich das richtig verstehe, gibt's bals eine RiscV Bluepill: > > https://twitter.com/SipeedIO/status/1164500325119610887 Die Ereignisse überschlagen sich ja geradezu (wenn das kein Fake ist). Wo bleibt jetzt eigentlich das Reference Manual und das Datenblatt? Wird doch langsam mal Zeit das zu veröffentlichen wenn die schon anfangen wollen das Produkt zu verkaufen!
:
Bearbeitet durch User
Stefanus F. schrieb: > Technisch muss es aber nach wie vor Versionsnummern geben. Die > Versionsnummer muss man aber nicht bewerben. Tun andere auch eher > selten. Naja, der große Unterschied ist, dass zumindest wenn die Updates auch planmäßig verlaufen, es inkrementelle Updates sind und man das Betriebssystem dadurch nicht neu installieren muss wie früher wenn man z.B. von XP auf Win 7 umsteigen wollte. Von Win 7 auf win 10 haben sie schon eine Art Updater angeboten, der war allerdings nicht ganz zuverlässig.
Alex G. schrieb: > Betriebssystem dadurch nicht neu installieren muss wie früher Das musste man seit Windows 3.0 nie - ein Update mit Übernahme verschiedener Einstellungen war immer möglich.
S. R. schrieb: > Alex G. schrieb: >> Betriebssystem dadurch nicht neu installieren muss wie früher > > Das musste man seit Windows 3.0 nie - ein Update mit Übernahme > verschiedener Einstellungen war immer möglich. Huh, echt jetzt? Auch für Privatnutzer? Wurde irgendwie nie so groß komuniziert bzw. beworben.
@ Alex G Ähm nö ;) Vertausche erstmal nicht w10 Updates und Upgrades. Ein Windoof 10 Upgrade ist eine Neuinstallation. Die jetzige Installation wird in einen old Ordner gepackt, dann wird neu installiert und dann werden die alten Einstellungen aus dem old Ordner gezogen. Also 2 mal im Jahr kannste dirn Räucherstäbchen anzünden und beten, dass das gut geht. (Damit gabs ja nu schon desöfteren Probleme laut diverser PC Seiten)
S. R. schrieb: > Alles eine Wahl der eigenen Scheuklappen. Lass stecken. Die Android-Thematik hab ich grad schon Stefanus erklärt. Nochmal schreib ich das nicht.
:
Bearbeitet durch User
Alex G. schrieb: >> Das musste man seit Windows 3.0 nie - ein Update mit Übernahme >> verschiedener Einstellungen war immer möglich. > Huh, echt jetzt? Auch für Privatnutzer? Ja... wenn das Setup-Programm eine Vorversion gefunden hat, dann hat es (mit Bestätigung) die installierte Version aktualisiert. Guckst du z.B. den Marathon auf https://www.winhistory.de/more/386/updatem.htm. Meine Win95-CD ist nur ein Update, die setzt zwingend ein Windows 3.x voraus (wenn nicht installiert, dann fragt es die Disketten ab). Die OEM-Version mit Windows 95c ist zwar eine Vollversion, kann das Update aber auch. Microsoft war auch vor 25 Jahren nicht komplett doof. :-)
:
Bearbeitet durch User
Le X. schrieb: >> Alles eine Wahl der eigenen Scheuklappen. > Die Android-Thematik hab ich grad schon Stefanus erklärt. Nochmal > schreib ich das nicht. Musst du auch nicht. Aber festzulegen, dass (a) der "Desktop" das Maß der Dinge ist und (b) "Open Source" nur dann gilt, wenn man Betriebswirtschaft komplett außen vor lässt, ist schon recht scheuklappig, oder? Ich bin auch nicht begeistert vom aktuellen Vendor Lock-In und ich traue Google/Apple nicht weiter, als ich sie werfen kann (was mit juristischen Personen ohnehin nicht so gut klappt), aber Android ist effektiv freie Software (die Google-Services natürlich nicht).
Alex G. schrieb: > Naja, der große Unterschied ist, dass zumindest wenn die Updates auch > planmäßig verlaufen, es inkrementelle Updates sind und man das > Betriebssystem dadurch nicht neu installieren muss wie früher wenn man > z.B. von XP auf Win 7 umsteigen wollte. Zweimal im Jahr wird das ganze Windows neu installiert. Von wegen inkrementelle Updates.
S. R. schrieb: > Ich bin auch nicht begeistert vom aktuellen Vendor Lock-In [...], > aber Android ist effektiv freie Software. Lies Dir Deinen Text nochmal durch. Den Widerspruch findest Du selbst.
qwerty schrieb: >> Ich bin auch nicht begeistert vom aktuellen Vendor Lock-In [...], >> aber Android ist effektiv freie Software. > > Lies Dir Deinen Text nochmal durch. > Den Widerspruch findest Du selbst. Stimmt. Ersetze Android durch "AOSP" oder "ist" durch "enthält fast ausschließlich", dann stimmt's wieder. Das Problem sind die Google Services, nicht Android.
Kassandra schrieb: [..] > > Na ENDLICH sind wir wieder beim MS bashing! > > Um es mal richtig zu stellen: Microsoft hat das Data Mining weder > erfunden noch betreibt Microsoft das Data Mining am ärgsten. Woher weißt Du das? Hast Du die Quellen einsehen dürfen..oder vermutest Du IrgendwaS? >Wie alle > grossen Softwarefirmen stand MS lediglich vor dem Dilemma, dass > irgendwann mit Software mal kein Geld mehr nachhaltig zu machen ist. Als > sich dann herausstellte, dass mit Big Data dagegen eine ständig > sprudelnde Einkommensquelle brach lag, haben sie alle zugeschnappt. Das > ist aber ein hausgemachtes Problem. Gäbe es nicht den DAU, der arglos > seine Daten bereit ist in die Weltgeschichte zu spucken und der nicht > versteht, dass ER die Ware ist, wenn's nichts kostet, ginge das nicht. Ich habt nichts weiter getan als darauf hinzuweisen das Windows 10 Nutzer DAUs sind wenn sie denken das das Verhalten von dem Zeug so ein müsse wie es ist. > > Wenn ich es recht erinnere, hat es vor ca. 2 Jahren mal ein Gutachten > darüber gegeben, wie gewissenhaft die Konzerne darin sind, den Benutzern > die Option zu geben, der Weitergabe ihrer Daten NICHT zuzustimmen. MS > hat zwar (wie fast Alle Anderen auch) den transparenten User zum Default > gemacht, schneidet aber mit am Besten darin in, den user die Türen > wieder zumachen zu lassen. Freilich. Bis zum nächsten Zwangsupdate.. > > Ihre Benutzer nacking ausziehen lassen und die Nacktfotos im Internet zu > verscheuern ist das Geschäftsmodell JEDER Firma mit einer grossen > Nutzerbasis. Aber es gehören immer 2 dazu: Die die es tun und die die es > mit sich machen lassen. Wer also Windows installiert und NICHT als > Allererstes alles wegklickt, was nach Data Mining riecht, soll sich > nicht über das böse Data Mining beschweren. Einfach Windows wegclicken und eine Software verwenden die man selbst oder auch Andere einsehen können ist die Lösung. Was willst Du eigentlich von mir? Gruß, Holm
S. R. schrieb: > Alex G. schrieb: >>> Das musste man seit Windows 3.0 nie - ein Update mit Übernahme >>> verschiedener Einstellungen war immer möglich. >> Huh, echt jetzt? Auch für Privatnutzer? > > Ja... wenn das Setup-Programm eine Vorversion gefunden hat, dann hat es > (mit Bestätigung) die installierte Version aktualisiert. Guckst du z.B. > den Marathon auf https://www.winhistory.de/more/386/updatem.htm. > > Meine Win95-CD ist nur ein Update, die setzt zwingend ein Windows 3.x > voraus (wenn nicht installiert, dann fragt es die Disketten ab). Die > OEM-Version mit Windows 95c ist zwar eine Vollversion, kann das Update > aber auch. > > Microsoft war auch vor 25 Jahren nicht komplett doof. :-) Nunja, eine win.com auf der Platte reicht aus damit das Update zufrieden ist. Gruß, Holm
S. R. schrieb: > qwerty schrieb: >>> Ich bin auch nicht begeistert vom aktuellen Vendor Lock-In [...], >>> aber Android ist effektiv freie Software. >> >> Lies Dir Deinen Text nochmal durch. >> Den Widerspruch findest Du selbst. > > Stimmt. Ersetze Android durch "AOSP" oder "ist" durch "enthält fast > ausschließlich", dann stimmt's wieder. > > Das Problem sind die Google Services, nicht Android. Ich habe Lineage OS auf dem Handy, ohne einen Google Account. Gruß, Holm
S. R. schrieb: >> Betriebssystem dadurch nicht neu installieren muss wie früher > > Das musste man seit Windows 3.0 nie - ein Update mit Übernahme > verschiedener Einstellungen war immer möglich. 2008 pre-R2 ist der letzte 32-Bit Windows Server und da läuft im Januar der Support aus. Migration 32- zu 64-Bit ist Neuinstallation.
:
Bearbeitet durch User
Ah, das DB is raus, danke dafür. Ließt sich wie von ST, die Bits der Peripherie kann man dann ja im ST RefMan zum 103er lesen ;) Wenn ST jetzt ein Paar STM32 auf RISV-V aufrüstet, wer hat dann wen kopiert?
Harald schrieb: > Hatten wir das GD32VF103 Datasheet schon? Wo hast Du das gefunden? Auf deren Downloadseite find ich immer noch nichts! Ich brauch noch das Reference Manual.
:
Bearbeitet durch User
Wenn ST mit der Produktvielfalt so weiter macht, wie bisher, dann gibt es irgendwann nur noch ein kurzes Datenblatt mit Auflistung der Features und elektrischen Daten. Für jede Peripherie-Einheit gibt es separate Referenzhandbücher, natürlich in mindestens 6 Versionen. Dazu kommt eine riesige nicht druckbare Tabelle, wo für alle STM Modelle die Versionen der Peripherie-Einheiten und deren Basis-Adressen der Register aufgelistet sind. Das wäre die Hölle :-)
Stefanus F. schrieb: > Für jede Peripherie-Einheit gibt es separate Referenzhandbücher, > natürlich in mindestens 6 Versionen. Ich könnte mir vorstellen daß die Reference Manuals auch heute schon (oder zumindest bald) automatisch aus den einzelnen Bausteinen zusammengefügt werden, im gleichen Rutsch wie die SVD-Datei. Irgendwo gibts ne kleine Tabelle in der alle Peripheriegeräte und Speicherbereiche für diesen Typ aufgelistet sind und dann klickt jemand nen Button und unten fallen Refman, Datenblatt und SVD raus.
Bernd K. schrieb: > Ich könnte mir vorstellen dass die Reference Manuals auch heute schon > (oder zumindest bald) automatisch aus den einzelnen Bausteinen > zusammengefügt werden Was dann wahrscheinlich fehlen wird, sind die Querverweise auf andere relevante Kapitel. Das wird für Anfänger schwierig. Ich bin es von AVR gewohnt, dass ich mich mit einzelnen Peripherie-Einheiten befassen kann, während ich die anderen unbeachtet links liegen lasse. Das ist bei ST ja leider (aber verständlicherweise) nicht mehr so einfach.
Stefanus F. schrieb: > Dazu kommt eine riesige nicht druckbare Tabelle, wo für alle STM Modelle > die Versionen der Peripherie-Einheiten und deren Basis-Adressen der > Register aufgelistet sind. > > Das wäre die Hölle :-) Och, diese Hölle ist gar nicht so heiss. Bei den msp430 von TI gibt es auch einen rechten Wildwuchs, dementsprechend viele Header-Files. Lässt sich doch heute alles automatisch generieren. Stefanus F. schrieb: > Was dann wahrscheinlich fehlen wird, sind die Querverweise auf andere > relevante Kapitel. Das wird für Anfänger schwierig. Wieso? Auch die Querverweise kann man auflösen. Man muss sich ja sowieso bei den Referenzmanuals jeweils an die Struktur des Herstellers gewöhnen. Bei TI ist es zum msp430 so, dass alle Peripherie in einem dicken Manual gesammelt dokumentiert ist und die I/O-Verbindungen und verfügbare Peripherie im Datenblatt des jeweiligen Chip-Derivats.
Bernd K. schrieb: > Harald schrieb: >> Hatten wir das GD32VF103 Datasheet schon? > > Wo hast Du das gefunden? Auf deren Downloadseite find ich immer noch > nichts! Ich brauch noch das Reference Manual. Hier ist das User Manual: http://dl.sipeed.com/LONGAN/Nano/DOC/GD32VF103_User_Manual_EN_V1.0.pdf
Der Vollständigkeit halber: https://github.com/nucleisys/Bumblebee_Core_Doc http://dl.sipeed.com/LONGAN/Nano/DOC/ http://dl.sipeed.com/LONGAN/Nano/SDK/
Memory Map des VF103 ist bis aufs letzte i-Tüpfelchen identisch mit dem F103. Die Peripherals scheinen auf den ersten Blick identisch zu sein. Das ist 1:1 ein F103-Klon mit RISC-V Kern. Brillanter Schachzug. Und dann noch die Marketingstrategie die Dokumente nicht ganz normal zu veröffentlichen wie früher sondern sie über "Insider" in sozialen Netzen der Nerds "leaken" zu lassen so daß man viel aufwendiger recherchiert als üblich bis man das gesuchte Datenblatt endlich hat und das dann was "besonderes" ist das man dann irgendwo mirrorn und bookmarken und sharen muss und nicht nur irgendein ein weiteres langweiliges PDF von der normalen Downloadseite. Die Chinesen haben gelernt wie erfolgreiches Marketing geht. Schnallt euch an!
:
Bearbeitet durch User
Bernd K. schrieb: > Und dann noch die Marketingstrategie die Dokumente nicht ganz normal zu > veröffentlichen wie früher sondern sie über "Insider" in sozialen Netzen > der Nerds "leaken" zu lassen so daß man viel aufwendiger recherchiert > als üblich bis man das gesuchte Datenblatt endlich hat und das dann was > "besonderes" ist das man dann irgendwo mirrorn und sharen muss und nicht > nur irgendein ein weiteres langweiliges PDF von der normalen > Downloadseite. Die Chinesen haben gelernt wie erfolgreiches Marketing > geht. Schnallt euch an! Das ist doch Unsinn. Sipeed ist halt Partner für die Entwicklung der Dev-Boards und daher haben die auch Datenblatt/Usermanual/SDK. Von dort kommen auch vorgeblichen Leaks. Abgesehen davon: Anschnallen muss sich jetzt ARM. Deren Geschäftsmodell geht jetzt doch schneller den Bach runter, als erwartet.
John Doe schrieb: > Anschnallen muss sich jetzt ARM. Deren Geschäftsmodell > geht jetzt doch schneller den Bach runter, als erwartet. Das könnte auch an den aufgerufenen Preisen liegen...
John Doe schrieb: > Das ist doch Unsinn. Sipeed ist halt Partner für die Entwicklung der > Dev-Boards und daher haben die auch Datenblatt/Usermanual/SDK. Von dort > kommen auch vorgeblichen Leaks. Naja, wie auch immer. Sipeed ist nicht der Platz wo normalerweise die GD-Dokumente veröffentlicht werden oder wo man auch nur im entferntesten danach suchen würde oder auch nur von der Existenz dieser Bude eine Ahnung hätte wenn man nicht eh schon bis zu beiden Ohren tief in der Materie drinsteckt. Der Effekt ist jedenfalls der selbe: Tagelang diskutieren und spekulieren die Leute sich die Köpfe heiß und generieren Klicks und bauen Spannung auf bis die Information dann um drei Ecken herum eintrudelt, aber nicht aus offizieller Quelle sondern versteckt wie eine exklusive Information die für Normalsterbliche noch gar nicht hätte erhältlich sein sollen und dadurch scheinbar umso wertvoller wird. Marketing! Und selbst jetzt wo es raus ist hört die Diskussion nicht auf und wir streiten uns nun über Meta-Details der Veröffentlichung und kritisieren uns gegenseitig in unserer Einschätzung der Medienstrategie und heben das ganze Ding auf die nächste Abstraktionsebene. Oder auch nicht. Ich bin für letzteres.
> Abgesehen davon: Anschnallen muss sich jetzt ARM. Deren Geschäftsmodell > geht jetzt doch schneller den Bach runter, als erwartet. ARM hat schon reagiert: https://www.elektroniknet.de/elektronik/halbleiter/neues-lizenzierungsmodell-von-arm-attraktiv-fuer-startups-und-smes-167393.html
Bernd K. schrieb: > Das ist 1:1 ein F103-Klon mit RISC-V Kern. > > Brillanter Schachzug. Das ist in der Tat genial. Der User muss nur den arm-none-eabi-gcc durch riscv-none-embed-gcc ersetzen und bekommt ein passendes .elf ausgespuckt. P:S. schrieb: > ARM hat schon reagiert: > https://www.elektroniknet.de/elektronik/halbleiter/neues-lizenzierungsmodell-von-arm-attraktiv-fuer-startups-und-smes-167393.html Nicht nur ARM ist unter Druck. IBM hat vor ein paar Tagen seine Power-Architektur zu Open-Source erklärt: https://www.nextplatform.com/2019/08/20/big-blue-open-sources-power-chip-instruction-set/
Jetzt wäre noch zu klären ob die da auch wieder sowas wie hier gemacht haben: https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices Die Zeitangaben im Datenblatt sagen daß es beim VF schneller geht: VF103: word programming: 37.5µs...86µs page erase: 24ms...300ms mass erase: 1s...3.2s F103: word programming: 200µs...400µs page erase: 60ms...450ms mass erase: 3.2s...9.6s STM32F103: word programming: 40µs..70µs page erase: 20ms...40ms mass erase: 20ms...40ms Aber sie versprechen immer noch Zero Waitstates für den "Flash"-Speicher. Mass erase ist immer noch extrem langsam. Über die Zeit zum Einschalten schweigen sich beide Datenblätter allerdings aus (hab nichts gefunden). -- Meine Messungen an nem anderen ARM von denen (F350 mit 64kB): Einschalten bis reset vektor: 21,5ms Die Zeiten aus dem Datenblatt hab ich nicht direkt gemessen sondern nur was er in meiner Anwendung macht: Beitrag "Re: "NUCLEO"-Borads von GigaDevice" -- Wäre mal interessant wie das beim VF103 ist. Und jemand soll den bitte mal aufmachen und fotografieren, ob da auch so ein lustiges Sandwich zusammen geklebt ist. Verräterische Hinweise: Es müsste einen merklichen Delay beim Einschalten geben vor dem Eintritt in den Reset-Vektor. Es gibt bei deren ARMen keinen Bus-Error wenn man ins Leere schreibt, ins "ROM" schreibt oder ungültige Adressen liest oder schreibt, deren ARMe laufen einfach weiter als ob nichts wäre (machen die STM32 das auch? Ich bin das nämlich anders gewohnt). -- Datenblatt und Refman sind jetzt übrigens online in deren normalen Downloadbereich.
:
Bearbeitet durch User
Bernd K. schrieb: > (machen die STM32 das auch? Ich bin > das nämlich anders gewohnt) KA.. vermutlich unterschiedlich... kenne die STM nicht so gut. Aber: Ohne MMU gibts keine Chance das zu erkennen. Und dann muss die MMU auch noch dafür ausgestattet sein. Über den Kamm geschoren: Die kleinen ARMe, die µC können das nicht. Die Großen, für den Betrieb mit einem OS vorgesehenen, die können Hardware Exceptions werfen. Die kennen "Prefetch Abort" und "Data Abort"
Arduino Fanboy D. schrieb: > Ohne MMU gibts keine Chance das zu erkennen. > Und dann muss die MMU auch noch dafür ausgestattet sein. Nein, dafür benötigt man keine MMU. Will man das ganze in konfigurierbarer Ausführung haben, genügt eine MPU. > Über den Kamm geschoren: > Die kleinen ARMe, die µC können das nicht. > Die Großen, für den Betrieb mit einem OS vorgesehenen, die können > Hardware Exceptions werfen. > Die kennen "Prefetch Abort" und "Data Abort" Einige ARM-Prozessoren, auch ohne MMU/MPU, sind so realisiert, dass auch die normalen Adressdekoder das betreffende Abort-Signal des Prozessorkerns aktivieren können. Ich habe es selbst schon erlebt, dass das Öffnen eines Speicherdump-Fensters im Debugger (Lauterbach) dazu führt, dass dort die Meldung "Data Abort" auftaucht. Das ist auch eine sehr gute Sache, weil damit ungültige Zeigerdereferenzierungen viel schneller bemerkt werden können.
Bernd K. schrieb: > Es gibt bei > deren ARMen keinen Bus-Error wenn man ins Leere schreibt, ins "ROM" > schreibt oder ungültige Adressen liest oder schreibt, deren ARMe laufen > einfach weiter als ob nichts wäre (machen die STM32 das auch? Ich bin > das nämlich anders gewohnt). Der STM32 hats wohl, hier hat ein BusFault zugebissen: Beitrag "STM32 - BusFault finden" Bei manchen ARM Kernen gibts im Speicherbereichmapping im RefMan dann "Data Abort Regions". Zb der uralt AT91RM9200 hat das. Sowas seh ich beim STM32 nicht, eher die ganzen Chipselectbereiche des externen Speichercontrollers. Aber die "Reserved" Bereiche beim STM32 sind wohl bissig. Zumindest bei nem RasPI2 kannste den ganzen 4G Adressbereich lesen ohne, dass es knallt. Es kommt eben nur Müll zurück wenn da nix is.
Christopher J. schrieb: > Nicht nur ARM ist unter Druck. IBM hat vor ein paar Tagen seine > Power-Architektur zu Open-Source erklärt: > https://www.nextplatform.com/2019/08/20/big-blue-open-sources-power-chip-instruction-set/ Damit ist ja jetzt alles lückenlos abgedeckt, inklusive ausgereifte Toolchains und Betriebssysteme, vom kleinsten µC (RISC-V) bis hin zum fettesten Supercomputer der Welt (POWER). Und chinesische Firmen können nun völlig legal bauen und verkaufen was sie wollen, vollkommen frei von jeglicher US-Daumenschraube. Das ging ja schneller als erwartet. Intel und ARM schauen in die Röhre und Huawei kann nicht mehr aufhören zu lachen. Und Trump springt im Dreieck (falls sich schon jemand getraut hat es ihm zu erklären)
Alles irgendwie logisch... Den Firmen, ob IBM oder Huawei, ist es im Grunde völlig egal wie und wo sie ihr Geld verdienen. Und der Trump scheint mir kein besonders guter Schachspieler zu sein.... (kann mich aber auch irren) Denn im Schach gilt die Regel: Zwinge den Gegner niemals zu einem guten Zug. Mir scheint: Wer Keile treibt, erreicht manchmal das Gegenteil, zwingt die anderen zur Kooperation. Selbst wenn harte Konkurrenten, aber Verluste fährt keiner gerne ein. Mein Glaskugel sagt: Das alles wird langfristige Folgen haben!
Arduino Fanboy D. schrieb: > Mir scheint: > Wer Keile treibt, erreicht manchmal das Gegenteil, zwingt die anderen > zur Kooperation. Ja, definitiv. Johnsons Weigerung, den Backstop in die Brexit-Verträge aufzunehmen, hat mittlerweile zu der vor kurzem noch unvorstellbaren Situation geführt, dass Irland und Nordirland mittlerweile sogar Sondierungsgespräche über eine Wiedervereinigung führen. Das hat in den Jahrhunderten zuvor niemand sonst geschafft. Als positiver Effekt stünde dann plötzlich die IRA ohne Feind da. > Mein Glaskugel sagt: > Das alles wird langfristige Folgen haben! Die langfristigen Folgen müssen aber nicht unbedingt schlecht sein, insbesondere auch bezogen auf den Umgang mit den USA. Früher (vor Trump) vertraten US-Diplomaten strikt die zuvor abgestimmte Position des US-Präsidenten und hätten es niemals gewagt, eine eigene Meinung zu vertreten. Mittlerweile haben aber schon mehrere Diplomaten gesagt: "Vergesst, was Trump labert, und lasst uns lieber ordentliche Verhandlungen führen."
Arduino Fanboy D. schrieb: > der Trump scheint mir kein besonders guter Schachspieler zu sein.... > Zwinge den Gegner niemals zu einem guten Zug. Das sehe ich auch so. Die Chinesen hätten es aber auch ohne ihn getan - nur vielleicht nicht ganz so schnell. Beispiel: Huawei arbeitet sicher schon etwas länger an seinem eigenen Android Ersatz.
Andreas S. schrieb: >> Das alles wird langfristige Folgen haben! > > Die langfristigen Folgen müssen aber nicht unbedingt schlecht sein, > insbesondere auch bezogen auf den Umgang mit den USA. Nun, ein Krieg führt immer zu schneller Weiterentwicklung - scheint auch für einen Handelskrieg zu gelten. Mal schauen, ob Europa davon profitiert, Konkurrenz belebt schließlich das Geschäft. Stefanus F. schrieb: > Huawei arbeitet sicher schon etwas länger an > seinem eigenen Android Ersatz. Eher nicht, dafür ist Android auch in China zu groß. Außerdem ist es Open Source und damit frei verfügbar (AOSP). Die Bindung an Google geschieht über die Integration mit den Google-Diensten, die aber in China ohnehin nicht funktionieren. Daher sind Android-Geräte für den chinesischen Markt grundsätzlich anders konfiguriert. Alternativen für die Google-Dienste existieren in China bereits. Die müsste man im Zweifelsfall einfach nur weltweit öffnen. Dazu braucht man Android nicht ersetzen.
S. R. schrieb: > Alternativen für die Google-Dienste existieren in China bereits. Die > müsste man im Zweifelsfall einfach nur weltweit öffnen. Und daraus ergibt sich nun die Frage der Fragen: Vertraut man Google, oder vertraut man den Chinesen?
Bernd K. schrieb: > Damit ist ja jetzt alles lückenlos abgedeckt, inklusive ausgereifte > Toolchains und Betriebssysteme, vom kleinsten µC (RISC-V) bis hin zum > fettesten Supercomputer der Welt (POWER). Der Befehlssatz ist offen. Nicht unbedingt aber eine Implementierung des Befehlssatzes.
A. K. schrieb: > Und daraus ergibt sich nun die Frage der Fragen: > Vertraut man Google, oder vertraut man den Chinesen? Richtig. Das ist der Knackpunkt. Ich mag darauf keine Antwort geben müssen.
S. R. schrieb: > A. K. schrieb: >> Und daraus ergibt sich nun die Frage der Fragen: >> Vertraut man Google, oder vertraut man den Chinesen? > > Richtig. Das ist der Knackpunkt. > Ich mag darauf keine Antwort geben müssen. Ein Unterrnehmen ist von seinen Kunden abhängiger als ein, zur Dikatur neigendes Land. Darum ist die Antwort zumindest für mich eindeutig...
Alex G. schrieb: > S. R. schrieb: >> A. K. schrieb: >>> Und daraus ergibt sich nun die Frage der Fragen: >>> Vertraut man Google, oder vertraut man den Chinesen? >> >> Richtig. Das ist der Knackpunkt. >> Ich mag darauf keine Antwort geben müssen. > Ein Unterrnehmen ist von seinen Kunden abhängiger als ein, zur Dikatur > neigendes Land. > Darum ist die Antwort zumindest für mich eindeutig... So ein Schwachsinn.
Alex G. schrieb: > Ein Unterrnehmen ist von seinen Kunden abhängiger als ein, zur Dikatur > neigendes Land. Jupp, allerdings bist nicht du der Kunde von google (es sei denn du hast ein google pixel?). Kunden sind die, die google Geld für deine Daten zahlen.
Dr. Sommer schrieb: > Andreas S. schrieb: >> Sobald sich >> herausstellt, dass die Sache doch nicht so einfach ist, werden sie meine >> Kunden. > > Und dann darfst du vermurkste Linux-basierten Konzepten retten, wo mit > haarsträubenden Frickeleien Echtzeitfähigkeit herbeigeschummelt > (vorgetäuscht) wird? Ja, warum nicht, wenn der Kunde es bezahlt?
A. K. schrieb: > S. R. schrieb: > Alternativen für die Google-Dienste existieren in China bereits. Die > müsste man im Zweifelsfall einfach nur weltweit öffnen. > Und daraus ergibt sich nun die Frage der Fragen: > Vertraut man Google, oder vertraut man den Chinesen? In China gibt es nicht einen zentralen Android-Appstore. Vermutlich deshalb sind die Stores 'offen', d.h. man kann APKs ohne Anmeldung runterladen. Bspw. der Xiaomi-Appstore: app.mi.com Das wuerde m. E. auch unserem System ganz gut tun, insbesondere wenn die Anbieter wie im Desktop-Bereich ihre Apps wieder selber veroeffentlichen wuerden und nicht ueber einen Monopolisten veroeffentlichen. Ansonsten ist zu sagen, datenschutztechnisch kennen die chinesischen Firmen keine Skrupel, die orientieren sich da gaenzlich an Facebook&Co.
Wer mal mit einem RISC-V spielen möchte, kann hier einen bestellen: https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board-p-4205.html Doku und Tools sind hier: http://dl.sipeed.com/LONGAN/Nano/
mh schrieb: > Alex G. schrieb: >> Ein Unterrnehmen ist von seinen Kunden abhängiger als ein, zur Dikatur >> neigendes Land. > > Jupp, allerdings bist nicht du der Kunde von google (es sei denn du hast > ein google pixel?). Kunden sind die, die google Geld für deine Daten > zahlen. Naja, die besagte Abhängigkeit ist trotzdem da. Würden weniger Leute Google nutzen, könnte Google auch keine personalisierte Werbung bzw. Daten anbieten.
:
Bearbeitet durch User
Alex G. schrieb: > mh schrieb: >> Alex G. schrieb: >>> Ein Unterrnehmen ist von seinen Kunden abhängiger als ein, zur Dikatur >>> neigendes Land. >> >> Jupp, allerdings bist nicht du der Kunde von google (es sei denn du hast >> ein google pixel?). Kunden sind die, die google Geld für deine Daten >> zahlen. > Naja, die besagte Abhängigkeit ist trotzdem da. Würden weniger Leute > Google nutzen, könnte Google auch keine personalisierte Werbung bzw. > Daten anbieten. Das Argument lässt sich aber genau so auf "die Chinesen" anwenden.
mh schrieb: > Alex G. schrieb: >> mh schrieb: >>> Alex G. schrieb: >>>> Ein Unterrnehmen ist von seinen Kunden abhängiger als ein, zur Dikatur >>>> neigendes Land. >>> >>> Jupp, allerdings bist nicht du der Kunde von google (es sei denn du hast >>> ein google pixel?). Kunden sind die, die google Geld für deine Daten >>> zahlen. >> Naja, die besagte Abhängigkeit ist trotzdem da. Würden weniger Leute >> Google nutzen, könnte Google auch keine personalisierte Werbung bzw. >> Daten anbieten. > > Das Argument lässt sich aber genau so auf "die Chinesen" anwenden. Nicht wirklich. In anbetracht dessen wieviel Einfluss die chinesische Regierung auf Unternehmen wie Xiamoi hat (dort könnten die CEOs es nicht im entferntesten wagen sich gegen die Regierung zu stellen, wie es z.B. Unternehmen in den USA gegen Trump tun), kann man schon mindestens von einer Teilverstaatlichung sprechen. Entsprechend könnten sie jeder Zeit ihre gewonnene Macht für ihr Land ausnutzen, ohne existenzielle Einbußen fürchten zu müssen.
:
Bearbeitet durch User
Maxe schrieb: > Das wuerde m. E. auch unserem System ganz gut tun, insbesondere wenn die > Anbieter wie im Desktop-Bereich ihre Apps wieder selber veroeffentlichen > wuerden und nicht ueber einen Monopolisten veroeffentlichen. Du meinst sowas wie: ich zieh mir auf ner Webseite die ich per Suchmaschine grad gefunden habe einen Installer in exe-Form?
Le X. schrieb: > Du meinst sowas wie: ich zieh mir auf ner Webseite die ich per > Suchmaschine grad gefunden habe einen Installer in exe-Form? Anders ausgedrueckt: Wenn ich ne App von der Sparkasse will, dann will ich die direkt von der Sparkasse, ja.
Alex G. schrieb: >>> Und daraus ergibt sich nun die Frage der Fragen: >>> Vertraut man Google, oder vertraut man den Chinesen? >> >> Richtig. Das ist der Knackpunkt. >> Ich mag darauf keine Antwort geben müssen. > Ein Unterrnehmen ist von seinen Kunden abhängiger als ein, > zur Dikatur neigendes Land. > Darum ist die Antwort zumindest für mich eindeutig... Du kaufst dein Telefon weder von "Google" noch von "China", damit geht dein Argument komplett am Kern der Sache vorbei. Weder Google noch China sind deinen Wünschen verpflichtet. Den einen geht es um ihre eigenen Einwohner, den anderen um den Jahresgewinn. Du bist nur Mittel zum Zweck. Alex G. schrieb: > In anbetracht dessen wieviel Einfluss die chinesische > Regierung auf Unternehmen wie Xiamoi hat (dort könnten > die CEOs es nicht im entferntesten wagen sich gegen die > Regierung zu stellen, wie es z.B. Unternehmen in den USA > gegen Trump tun), kann man schon mindestens von > einer Teilverstaatlichung sprechen Hast du zufällig mitbekommen, wieviel Einfluss die amerikanische Regierung auf Unternehmen wie Qualcomm, ARM oder Google hat? Nicht?
S. R. schrieb: > Du kaufst dein Telefon weder von "Google" noch von "China", damit geht > dein Argument komplett am Kern der Sache vorbei. China selbst verkauft keine Telefone, Google aber schon.
Maxe schrieb: > Le X. schrieb: >> Du meinst sowas wie: ich zieh mir auf ner Webseite die ich per >> Suchmaschine grad gefunden habe einen Installer in exe-Form? > Anders ausgedrueckt: > Wenn ich ne App von der Sparkasse will, dann will ich die direkt von der > Sparkasse, ja. Njah.. zu nem Teil ist der Wunsch verständlich, andererseits ist das nicht wirklich ein realer Sicherheitsgewinn und ein Store bringt definitiv Komfortvorteile. Wenn man den "Developermodus" (o.Ä.) aktiviert (geht einfach in den Einstellungen), kann man das übrigens auch mit ansonsten Google-gebundenem Android wenn man will. Nur sind es keine .exe Files, sondern .apk. S. R. schrieb: > Alex G. schrieb: >>>> Und daraus ergibt sich nun die Frage der Fragen: >>>> Vertraut man Google, oder vertraut man den Chinesen? >>> >>> Richtig. Das ist der Knackpunkt. >>> Ich mag darauf keine Antwort geben müssen. >> Ein Unterrnehmen ist von seinen Kunden abhängiger als ein, >> zur Dikatur neigendes Land. >> Darum ist die Antwort zumindest für mich eindeutig... > > Du kaufst dein Telefon weder von "Google" noch von "China", damit geht > dein Argument komplett am Kern der Sache vorbei. > > Weder Google noch China sind deinen Wünschen verpflichtet. Den einen > geht es um ihre eigenen Einwohner, den anderen um den Jahresgewinn. Du > bist nur Mittel zum Zweck. Richtig, wenigstens bin ich für Google Mittel zum Zweck Gewinn zu erwirtschaften, und nicht um Macht für Bürger eines anderen Landes zu erlangen. > Alex G. schrieb: >> In anbetracht dessen wieviel Einfluss die chinesische >> Regierung auf Unternehmen wie Xiamoi hat (dort könnten >> die CEOs es nicht im entferntesten wagen sich gegen die >> Regierung zu stellen, wie es z.B. Unternehmen in den USA >> gegen Trump tun), kann man schon mindestens von >> einer Teilverstaatlichung sprechen > > Hast du zufällig mitbekommen, wieviel Einfluss die amerikanische > Regierung auf Unternehmen wie Qualcomm, ARM oder Google hat? Nicht? BEI WEITEM nicht so viel wie die chinesische! Dort dürften die CEOs sich nicht mal negativ äussern, wie es die ameriaknsichen gemacht haben.
Alex G. schrieb: > Richtig, wenigstens bin ich für Google Mittel zum Zweck Gewinn zu > erwirtschaften, und nicht um Macht für Bürger eines anderen Landes zu > erlangen. Frag mal die NSA, was sie dazu sagen. Bei den USA wissen wir, dass sie Daten mitlesen und nutzen. Bei China wird es behauptet, hauptsächlich von den USA.
mh schrieb: > Bei China wird es behauptet, hauptsächlich > von den USA. In China ist das auch schon längst 'implementiert', zumindest in grösseren Städten wie Shanghai ist das totalitäre Tracking schom im Gange, und den Rest des 'social credit system' wird die Alibaba-Gruppe vermutlich mit einem Staatsdeal abdecken dürfen. Frage ist bloss, wieviel Interesse die Chinesen an unserem Sozialverhalten haben um dem googelschen Datensammeldrang auch hierzulande nachzugehen. Vermutlich ist das geringer und der Fokus ein anderer, da wir ihnen alle wirtschaftlichen Informationen ja bereitwillig liefern. Die Amis müssen dazu wohl noch weiterhin Spionage betreiben. Zurück zum Thema: Den RISCV-Hype kann ich nur begrenzt nachvollziehen, die Chinesen setzen seit Jahren schon in Massen MIPS-Derivate ein, für die eine Menge der hierzulande unbekannten Firmen gar keine Lizenzgebühren für die ISA zahlen müssen. Die Migration zu RISCV ist eine kleine.
Fitzebutze schrieb: > Frage ist bloss, wieviel Interesse die Chinesen an _unserem_ > Sozialverhalten haben um dem googelschen Datensammeldrang auch > hierzulande nachzugehen. Als Basis für gezielte Angriffe auf Personen in interessanten Positionen von Staat und Wirtschaft sind persönliche Informationen Gold wert. Chinesen sind ausserdem nicht ehrlicher als andere auch. Wenn man mit Informationsbeschaffung Geld verdienen kann, könnte auch der eine oder andere Chinese hellhörig werden, und den Bereich von Informationsbeschaffung passend ausdehnen. > da wir ihnen alle wirtschaftlichen Informationen ja > bereitwillig liefern. Nein, das ist nicht der Fall.
A. K. (prx) >Als Basis für gezielte Angriffe auf Personen in interessanten Positionen >von Staat und Wirtschaft sind persönliche Informationen Gold wert. Nicht nur das. Durch die sozialen Medien und die E-Mail-Verteiler liegen alle persönlichen Verbindungen offen. Dadurch lässt sich analysieren, wie die verschiedenen Gesellschaftsgruppen organisiert sind und Bedarf an der richtigen Stelle Einfluss nehmen. Man kann gut heraus kriegen, wer in der Gruppe der "Opinion-Leader" ist und dann entsprechende Maßnahmen ergreifen
Alex G. schrieb: [..] >> >> Das Argument lässt sich aber genau so auf "die Chinesen" anwenden. > Nicht wirklich. In anbetracht dessen wieviel Einfluss die chinesische > Regierung auf Unternehmen wie Xiamoi hat (dort könnten die CEOs es nicht > im entferntesten wagen sich gegen die Regierung zu stellen, wie es z.B. > Unternehmen in den USA gegen Trump tun), kann man schon mindestens von > einer Teilverstaatlichung sprechen. > Entsprechend könnten sie jeder Zeit ihre gewonnene Macht für ihr Land > ausnutzen, ohne existenzielle Einbußen fürchten zu müssen. Ich könnte auch im Wissen um diesen Umstand aber eben auch nicht sagen, Welchem von Beidem ich mehr mißtraue. Die dt. Industrie hat sehr wohl wissen müssen was sie tut als sie eine Hochtechnologie nach der Anderen nach China ausgelagert hat. Der Umstand das Kopieren von IP in China eben nicht unter "Verbrechen" einsortiert wird (in den Köpfen nicht) war lange vorher bekannt. Du kannst gerne die Russen als weiteren global Player noch zusätzlich mit in Betracht ziehen, dann bekommst Du von mir die Antwort das ich die bevorzugen würde, aber im konkreten Falle sind sie wohl nicht relevant. Gruß, Holm
Maxe schrieb: > Le X. schrieb: >> Du meinst sowas wie: ich zieh mir auf ner Webseite die ich per >> Suchmaschine grad gefunden habe einen Installer in exe-Form? > Anders ausgedrueckt: > Wenn ich ne App von der Sparkasse will, dann will ich die direkt von der > Sparkasse, ja. ...Die bekommste aber von dort auch nicht. Ich habe das Problem mit der Hypovereinsbank, große Klappe "..download in allen App-Stores.." die sind aber genau 2, einer bei Apple und einer bei Google, keinen von den Beiden will ich. Dafür gibts aber eine prasslige Begründung mit Geschwurbel über Sicherheit... Gruß, Holm
Alex G. schrieb: > Maxe schrieb: >> Le X. schrieb: >>> Du meinst sowas wie: ich zieh mir auf ner Webseite die ich per >>> Suchmaschine grad gefunden habe einen Installer in exe-Form? >> Anders ausgedrueckt: >> Wenn ich ne App von der Sparkasse will, dann will ich die direkt von der >> Sparkasse, ja. > Njah.. zu nem Teil ist der Wunsch verständlich, andererseits ist das > nicht wirklich ein realer Sicherheitsgewinn und ein Store bringt > definitiv Komfortvorteile. ....hmm.. vllt. so lange es da keine Pgflicht zum Anlegen eines Google Kontos gibt..anderenfalls verkehrt sich der Vorteil in sein Gegenteil. > > Wenn man den "Developermodus" (o.Ä.) aktiviert (geht einfach in den > Einstellungen), kann man das übrigens auch mit ansonsten > Google-gebundenem Android wenn man will. > Nur sind es keine .exe Files, sondern .apk. ...derer Du aber erst einmal habhaft werden mußt. Es ist ja nicht so das Du die völlig problemlos von einem Tel. aufs Andere kopieren könntest. Gruß, Holm
Was genau hat Euer China-Google-Gesülze mit RISC-V zu tun? Bitte klärt mich auf!
Holm T. schrieb: > Es ist ja nicht so das > Du die völlig problemlos von einem Tel. aufs Andere kopieren könntest. Wieso nicht? Ich kann APK Dateien über Bluetooth, USB-Kabel, Email, Web-Download und SD Karte auf mein Smartphone übertragen. Die Installation geschieht dann teils automatisch, teils per Dateimanager. Es gibt sogar noch den eigentlich sinnlosen App-Installer, der das ganze Smartphone nach installierbaren APK's durchsucht. Über die gleichen Wegen kann ich die APK Dateien auch an andere Android Smartphones senden. Ich verstehe nicht, wo da da Problem sein könnte.
Stefanus F. schrieb: > Holm T. schrieb: >> Es ist ja nicht so das >> Du die völlig problemlos von einem Tel. aufs Andere kopieren könntest. > > Wieso nicht? > > Ich kann APK Dateien über Bluetooth, USB-Kabel, Email, Web-Download und > SD Karte auf mein Smartphone übertragen. Die Installation geschieht dann > teils automatisch, teils per Dateimanager. Es gibt sogar noch den > eigentlich sinnlosen App-Installer, der das ganze Smartphone nach > installierbaren APK's durchsucht. > > Über die gleichen Wegen kann ich die APK Dateien auch an andere Android > Smartphones senden. Ich verstehe nicht, wo da da Problem sein könnte. Ich habe mich zwar nicht im Detail damit beschäftigt, aber ich habe schon Schwierigkeiten die apks nachinstallierter Apps auf dem S6 meiner Frau zu finden. Gruß, Holm
> Was genau hat Euer China-Google-Gesülze mit RISC-V zu tun?
Vielleicht sollte man dafür einfach einen neuen Thread aufmachen. Denn
nachdem ich dazu "gedrängt" wurde, mir ein NEUES Smartphone zuzulegen
kämpfe ich auch gegen die ganze "Google-Seuche". Vielleicht lassen sich
ja ein paar Tipps austauschen...
Jörg
Bernd K. schrieb: > Memory Map des VF103 ist bis aufs letzte i-Tüpfelchen identisch mit dem > F103. Die Peripherals scheinen auf den ersten Blick identisch zu sein. > Das ist 1:1 ein F103-Klon mit RISC-V Kern. Ich hab mir jetzt auch mal das User Manual und Datasheet angeschaut. Wenn ich das richtig sehe, dann hat der GD32VF103 die Peripherie vom STM32F105, denn der hat gegenüber dem F103: 2x CAN DAC USB OTG
Holm T. schrieb: > Ich habe mich zwar nicht im Detail damit beschäftigt, aber ich habe > schon Schwierigkeiten die apks nachinstallierter Apps auf dem S6 meiner > Frau zu finden. Wenn du mit der Google Play App installierst, wird das APK nur temporär gespeichert und danach gelöscht.
Holm T. schrieb: > Maxe schrieb: > Wenn ich ne App von der Sparkasse will, dann will ich die direkt von der > Sparkasse, ja. > > ...Die bekommste aber von dort auch nicht. > Ich habe das Problem mit der Hypovereinsbank, große Klappe "..download > in allen App-Stores.." die sind aber genau 2, einer bei Apple und einer > bei Google, keinen von den Beiden will ich. Dafür gibts aber eine > prasslige Begründung mit Geschwurbel über Sicherheit... Na klar, dank Monopolist. Haette jeder Handyhersteller seinen eigenen Appstore, dann wuerde die Sparkasse natuerlich die APK direkt anbieten, allein aus Gruenden der Aufwandminimierung. Und du koenntest dir als Kunde raussuchen, ob du dem Samsung- oder Motorola-Appstore mehr vertraust.
Joerg W. schrieb: > kämpfe ich auch gegen die ganze "Google-Seuche". Konfuzius sagt: "Wenn Du Dich einer Vergewaltigung nicht entziehen kannst dann lehne Dich zurück und genieße sie."
Christopher J. schrieb: > Ich hab mir jetzt auch mal das User Manual und Datasheet angeschaut. > Wenn ich das richtig sehe, dann hat der GD32VF103 die Peripherie vom > STM32F105, denn der hat gegenüber dem F103: > 2x CAN > DAC > USB OTG Ja, ich hab geschummelt. Ich hab ihn mit dem GD32F103 verglichen, nicht mit dem STM32F103. Da hier die Tabellen in den Datenblättern gleich formatiert sind lässt sich das einfacher vergleichen. Und da der GD32F103 zum ST32F103 laut verschiedenen Quellen vollkommen binärkompatibel (abwärts) ist und somit als Drop-In-Replacement funktioniert hab ich den GD32F103 kurzerhand als Drop-In-Replacement in meinen Vergleich verwendet. Wenn man genau hinschaut sind noch mehr Sachen beim GD anders oder besser: * 108MHz Takt * Flash controller kann 16 oder 32 bit schreiben, STM32F103 nur 16 * wahrscheinlich andere Kleinigkeiten die ich noch nicht entdeckt habe
:
Bearbeitet durch User
>* 108MHz Takt >* Flash controller kann 16 oder 32 bit schreiben, STM32F103 nur 16 Wobei natürlich die interessanteste Frage das Ergebnis eines Rechenleistungsbenchmarks wäre.
Harald schrieb: >>* 108MHz Takt > > Wobei natürlich die interessanteste Frage das Ergebnis eines > Rechenleistungsbenchmarks wäre. Die wird schon deutlich höher sein, allein schon aufgrund der fehlenden Waitstates weil sämtlicher Code immer aus dem RAM ausgeführt wird.
Bernd K. schrieb: > Die wird schon deutlich höher sein, allein schon aufgrund der fehlenden > Waitstates weil sämtlicher Code immer aus dem RAM ausgeführt wird. Ist das dann auch beim GD32V so wie beim GD32, dass der den NOR-Flash huckepack dabei hat und beim Start alles ins RAM geladen wird?
Stefanus F. schrieb: > Holm T. schrieb: >> Ich habe mich zwar nicht im Detail damit beschäftigt, aber ich habe >> schon Schwierigkeiten die apks nachinstallierter Apps auf dem S6 meiner >> Frau zu finden. > > Wenn du mit der Google Play App installierst, wird das APK nur temporär > gespeichert und danach gelöscht. ..genau. Und wie kopiert man eine gelöschte Datei auf ein anderes Handy? Wie unterbindet man das Löschen? _Ich schrub doch "ist nicht so einfach.." Wir sollten wirklich einen Android/Lineage OS Thread aufmachen. Gruß, Holm
Maxe schrieb: > Holm T. schrieb: >> Maxe schrieb: >> Wenn ich ne App von der Sparkasse will, dann will ich die direkt von der >> Sparkasse, ja. >> >> ...Die bekommste aber von dort auch nicht. >> Ich habe das Problem mit der Hypovereinsbank, große Klappe "..download >> in allen App-Stores.." die sind aber genau 2, einer bei Apple und einer >> bei Google, keinen von den Beiden will ich. Dafür gibts aber eine >> prasslige Begründung mit Geschwurbel über Sicherheit... > Na klar, dank Monopolist. > Haette jeder Handyhersteller seinen eigenen Appstore, dann wuerde die > Sparkasse natuerlich die APK direkt anbieten, allein aus Gruenden der > Aufwandminimierung. Und du koenntest dir als Kunde raussuchen, ob du dem > Samsung- oder Motorola-Appstore mehr vertraust. Es gibt viele freie Appstores, f-droid z.B. Laß gut sein jetzt hier mit Handy, mich interessiert die RISC-V Sache mehr. Gruß, Holm
Christopher J. schrieb: > Ist das dann auch beim GD32V so wie beim GD32, dass der den NOR-Flash > huckepack dabei hat und beim Start alles ins RAM geladen wird? Die Zeitangaben für Löschen/Schreiben (im direkten Vergleich zum STM32) deuten zumindest darauf hin. Und die Angabe "zero waitstates" im Datenblatt. Ich warte darauf daß bald irgendjemand das Ding mal aufmacht und Fotos vom Innenleben präsentiert.
:
Bearbeitet durch User
Holm T. schrieb: > Es gibt viele freie Appstores, f-droid z.B. Ja, sind auch super seriös. Das Problem sind auch nicht Appstores von Dritten, sondern der eine "Offizielle". Ohne den würden die Anbieter ihre APKs selbst veröffentlichen. Halt wie bei Windows. Ist doch nicht so schwer zu verstehen...
John Doe schrieb: > Wer mal mit einem RISC-V spielen möchte, kann hier einen bestellen: > > https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board-p-4205.html > > Doku und Tools sind hier: > http://dl.sipeed.com/LONGAN/Nano/ Hat den schon einer bestellt und weis wie viel Porto da noch drauf kommt?
https://www.heise.de/newsticker/meldung/5-Dollar-Entwicklerboard-mit-RISC-V-Sipeed-Longan-Nano-4509949.html Bin über diese Meldung darauf gekommen ...
Maxe schrieb: > Holm T. schrieb: >> Es gibt viele freie Appstores, f-droid z.B. > Ja, sind auch super seriös. Würdest Du die Lehman Bros. als seriös betrachtet haben? > Das Problem sind auch nicht Appstores von Dritten, sondern der eine > "Offizielle". Ohne den würden die Anbieter ihre APKs selbst > veröffentlichen. Halt wie bei Windows. > Ist doch nicht so schwer zu verstehen... Wie lange gibts schon Prüfsummen wie MD5 oder SHA256? Gruß, Holm
Himmel Hergott, könnt Ihr die Scheiß App-Store-Diskussion in einem anderen Thread weiter führen. Ich bin dafür, dass das hier ein reiner RISC-V Thread ist.
Harald schrieb: > Himmel Hergott, könnt Ihr die Scheiß App-Store-Diskussion in einem > anderen Thread weiter führen. > Ich bin dafür, dass das hier ein reiner RISC-V Thread ist. Schön, endlich ist eine mal "für" Etwas und nicht nur dagegen. Gruß, Holm
Harald schrieb: > Himmel Hergott, könnt Ihr die Scheiß App-Store-Diskussion in einem > anderen Thread weiter führen. > Ich bin dafür, dass das hier ein reiner RISC-V Thread ist. Wenn du diese Trolle im Thread hast, dann hat sich jede weitere sinnvolle Diskussion erledigt.
A. K. schrieb: >> Du kaufst dein Telefon weder von "Google" noch von "China", damit geht >> dein Argument komplett am Kern der Sache vorbei. > > China selbst verkauft keine Telefone, Google aber schon. Ich gehe mal davon aus, dass er, wie die riesige Mehrheit der Android-Nutzer, kein Pixel hat. Zumal die Pixel-Geräte (zumindest in meiner Wahrnehmung) einen teilweise anderen Zweck erfüllen als andere Smartphones. Alex G. schrieb: > Richtig, wenigstens bin ich für Google Mittel zum Zweck Gewinn > zu erwirtschaften, und nicht um Macht für Bürger eines anderen > Landes zu erlangen. Ob ich nun an den Gelben Spieler oder an den Blauen Spieler verkauft werde, ist mir relativ egal... das Problem ist das Wort "verkauft". >> Alex G. schrieb: >> Hast du zufällig mitbekommen, wieviel Einfluss die amerikanische >> Regierung auf Unternehmen wie Qualcomm, ARM oder Google hat? Nicht? > BEI WEITEM nicht so viel wie die chinesische! Dort dürften die > CEOs sich nicht mal negativ äussern, wie es die ameriaknsichen > gemacht haben. Warum ist dir das so wichtig, was ein Chef sagen oder nicht sagen darf? Viel wichtiger ist doch, ob die Firma spurt, wenn sie Befehle von oben bekommt oder nicht - und die letzten Monate haben recht deutlich gezeigt, dass das bei den USA auch wunderbar funktioniert. Aus meiner Sicht gibt es nur einen wesentlichen Unterschied: - Die Russen bescheißen mich und sagen es mir. - Die Chinesen bescheißen mich, lächeln und schweigen. - Die Amerikaner bescheißen mich und lügen mir Gesicht.
S. R. schrieb: > Ich gehe mal davon aus, dass er, wie die riesige Mehrheit der > Android-Nutzer, kein Pixel hat. Gut. Und was hat das mit RISC-V zu tun? Der ist weder in Pixels, noch läuft derzeit Android drauf.
homa schrieb: > https://www.heise.de/newsticker/meldung/5-Dollar-Entwicklerboard-mit-RISC-V-Sipeed-Longan-Nano-4509949.html > > Bin über diese Meldung darauf gekommen ... Kann jetzt N$A oder CN diese Hardware überwachen oder ist es vor Cyberüberwachung geschützt? Wenn das mit TEENSY 4.0 verglichen wird, was kommt dann dabei raus? Die Unterschiede?
:
Bearbeitet durch User
Helmut V. schrieb: > Kann jetzt N$A oder CN diese Hardware überwachen oder ist es vor > Cyberüberwachung geschützt? Die Bauformen im QFN-Gehäuse sind mit einem Hochsicherheits-Groundpad ausgestattet welches die Cyberüberwachung ausreichend abschirmt. Und nicht vergessen: alle unbenutzten Pins auf GND damit er nicht damit winken kann! Spaß beiseite: Meinst Du daß sie eine Hintertür um die Lockbits herum eingebaut haben damit sie alle westlichen Devices (die dann alle mit GD32 ausgestattet sein werden) in 1 Sekunde klonen können? Das wäre in der Tat ein teuflischer Plan!
:
Bearbeitet durch User
Helmut V. schrieb: > Wenn das mit TEENSY 4.0 verglichen wird, Vergleich es mit einem Blue-Pill, nur doppelt so schnell.
:
Bearbeitet durch User
Beitrag #5956116 wurde von einem Moderator gelöscht.
Beitrag #5956120 wurde von einem Moderator gelöscht.
Hier ist noch ein RISC-V: https://phys.org/news/2019-08-advanced-microprocessor-carbon-nanotubes.html Leider steht da nichts zu Tempo und Wattzahl.
Bla schrieb: > Hier ist noch ein RISC-V: > > https://phys.org/news/2019-08-advanced-microprocessor-carbon-nanotubes.html > > Leider steht da nichts zu Tempo und Wattzahl. Aus Karbonröhrchen? Also das heisst wir können jetzt bald auf Silizium verzichten?
Helmut V. schrieb: > Bla schrieb: >> Hier ist noch ein RISC-V: >> >> https://phys.org/news/2019-08-advanced-microprocessor-carbon-nanotubes.html >> >> Leider steht da nichts zu Tempo und Wattzahl. > > Aus Karbonröhrchen? Also das heisst wir können jetzt bald auf Silizium > verzichten? Steckt sicherlich noch in den Kinderschuhen, aber dass es immerhin schon mehr Transistoren hat als die ersten Röhrenrechner ist ein echt vielversprechendes Zeichen. Wenn die Technik sich durchsetzt, wird es aber natürlich nicht nur bei Risc-V Architekturen bleiben.
:
Bearbeitet durch User
Profibit >Helmut V. schrieb: >> Wenn das mit TEENSY 4.0 verglichen wird, >Vergleich es mit einem Blue-Pill, nur doppelt so schnell. Das wage ich zu bezweifeln. Die ARM-Prozessoren sind sehr gut optimiert. Alleine schon die Grundidee, den Barrel-Shifter separat an den Akku zu koppeln und dabei die geometrischen Möglichkeiten des Chiprouting zu optimieren, war genial. Hier die Geschichte von ARM erzählt von dessen Entwicklerin, Sophie Wilson https://www.youtube.com/watch?v=re5xAqgKqc0
Harald schrieb: > Barrel-Shifter separat an den Akku zu > koppeln Du hast keine allzugroße Ahnung von ARM oder? Das ist keine Akkumulatorarchitektur.
Harald schrieb: >>Vergleich es mit einem Blue-Pill, nur doppelt so schnell. > > Das wage ich zu bezweifeln. Das BluePill hat einen ARM mit 72MHz und 2 Waitstates, das neue Board hat einen RISC-V mit 108MHz und null Waitstates. Ich habe nicht den geringsten Zweifel daß es wenn nicht doppelt so schnell dann zumindest fast doppelt so schnell sein wird.
:
Bearbeitet durch User
>Du hast keine allzugroße Ahnung von ARM oder? Sorry, vertippt: ALU >Ich habe nicht den >geringsten Zweifel daß es wenn nicht doppelt so schnell dann zumindest >fast doppelt so schnell sein wird. Der CPU-Takt ist nicht alles. Auf die Zyklenzahl und die Befehle kommt es an.
Harald schrieb: > Der CPU-Takt ist nicht alles. Auf die Zyklenzahl und die Befehle kommt > es an. Glaubst Du die haben ihren RISC-V versehentlich gedrosselt weil sie so schusselig sind damit er mehr als 1 Takt pro Befehl braucht oder was?
es reicht auch mal schrieb: > Bitte hör auf diesen Thread weiter zu vertiffen! > Danke im Vorraus! Ich gebe die Hoffung nicht auf, das Dir mal aufgeht, das es nicht ich bin der hier den Thread "vertifft", sondern so anonyme Dunkelhüte wie Du. Gruß, Holm
Bernd schrieb: > Harald schrieb: > >> Himmel Hergott, könnt Ihr die Scheiß App-Store-Diskussion in einem >> anderen Thread weiter führen. >> Ich bin dafür, dass das hier ein reiner RISC-V Thread ist. > > Wenn du diese Trolle im Thread hast, dann hat sich jede weitere > sinnvolle Diskussion erledigt. Jetzt beherrsche Dich mal, ich habe auch in den Posts darum gebeten das sein zu lassen, es sind andere (Stefanus, und anonymlinge die zu feige ihren Namen zu nennen) die das hoch holen, gehe Denen auf den Kranz und nicht mir. Gruß, Holm
Der STM32F103 kann ja auch gegen einen STM32F303 getauscht werden. https://robotdyn.com/catalog/development-boards/stm-boards-and-shields/stm32f303cct6-256-kb-flash-stm32-arm-cortexr-m4-mini-system-dev-board-3326a9dd-3c19-11e9-910a-901b0ebb3621.html Das ist ein F4 mit fpu und deutlich moderner. Ob der GD32xx dagegen eine Chance hat ist fraglich. Solange jedenfalls sich ein RISC-V nicht genauso komfortabel Debuggen lässt über 2 Leitungen (SWD) + Versorgung würde ich um nichts in der Welt tauschen. Nicht mal geschenkt, weil die Kosten des Chips nur für Massenproduktion eine Rolle spielt. Im Hobbybereich spielt das aber ein ehr untergeordnete Rolle. Eventuell kann man ja in 5 Jahren mal darüber nachdenken wenn der erste Hype vorbei ist.
Jack V. schrieb: > S. R. schrieb: >> Ich gehe mal davon aus, dass er, wie die riesige Mehrheit der >> Android-Nutzer, kein Pixel hat. > > Gut. Und was hat das mit RISC-V zu tun? Der ist weder in Pixels Das ist doch falsch. Natürlich ist bei den Pixels RISC-V onboard. Hat Google doch ausführlich vorgestellt.
John Doe schrieb: > Natürlich ist bei den Pixels RISC-V onboard. Gerade geschaut, Pixel Visual Core. Ist komplett an mir vorübergegangen – sorry.
Vielleicht sogar schon in absehbarer Zeit zu kaufen: https://www.heise.de/newsticker/meldung/5-Dollar-Entwicklerboard-mit-RISC-V-Sipeed-Longan-Nano-4509949.html
temp schrieb: > Der STM32F103 kann ja auch gegen einen STM32F303 getauscht werden. > > https://robotdyn.com/catalog/development-boards/stm-boards-and-shields/stm32f303cct6-256-kb-flash-stm32-arm-cortexr-m4-mini-system-dev-board-3326a9dd-3c19-11e9-910a-901b0ebb3621.html > > Das ist ein F4 mit fpu und deutlich moderner. Ob der GD32xx dagegen eine > Chance hat ist fraglich. Dann schauen wir mal auf die Fakten: STM32F103: 90 DMIPs - nur aus dem CCM GD32VF103: 153 DMIPS Ziemlich eindeutig. Gleiches Bild beim Stromverbrauch. Der STM32 hat keine Chance. > Solange jedenfalls sich ein RISC-V nicht > genauso komfortabel Debuggen lässt über 2 Leitungen (SWD) + Versorgung > würde ich um nichts in der Welt tauschen. Ob zwei oder 4 Leitungen ist doch wirklich latte. > Nicht mal geschenkt, weil die > Kosten des Chips nur für Massenproduktion eine Rolle spielt. Im > Hobbybereich spielt das aber ein ehr untergeordnete Rolle. Eventuell > kann man ja in 5 Jahren mal darüber nachdenken wenn der erste Hype > vorbei ist. Der Hype ist vorbei. RISC-V Produkte werden in Milliardenstückzahlen verkauft. Demnächst auch am obersten Ende der Skala: EuroHPC (European High-Performance Computing Joint Undertaking). Die Inder haben RISC-V defacto zur zukünftigen National-Architektur deklariert, China ist nach den Trump-Manövern auch dabei, die EU fängt auch an, sich endlich wieder unabhängig zu machen. RISC-V macht das Rennen. Die Frage ist nur, wann ARM die weisse Flagge hisst.
John Doe schrieb: > Dann schauen wir mal auf die Fakten: > STM32F103: 90 DMIPs - nur aus dem CCM > GD32VF103: 153 DMIPS Sollte: STM32F303: 90 DMIPs - nur aus dem CCM heissen...
temp schrieb: > Eventuell kann man ja in 5 Jahren mal darüber nachdenken > wenn der erste Hype vorbei ist. Der erste Hype fing vor 5 Jahren an, der ist durch. Inzwischen kann man die Chips kaufen statt nur simulieren. John Doe schrieb: > Die Frage ist nur, wann ARM die weisse Flagge hisst. Spätestens, wenn sie den ersten RISC V-Core anbieten. Sie wären ja schön blöd, wenn sie nicht aus ihrem Wissen und ihrer Erfahrung Kapital schlagen würden... Ich warte darauf, dass im Android-Baum ein RISC V-Compiler auftaucht. Dann wird es nämlich sehr schnell sehr interessant.
S. R. schrieb: > Spätestens, wenn sie den ersten RISC V-Core anbieten. Sie wären ja schön > blöd, wenn sie nicht aus ihrem Wissen und ihrer Erfahrung Kapital > schlagen würden... > > Ich warte darauf, dass im Android-Baum ein RISC V-Compiler auftaucht. > Dann wird es nämlich sehr schnell sehr interessant. Mich würde es auch nicht wundern, wenn die Nutzer der grossen ARM-Lizenzen wie Apple, Samsung oder Qualcomm nicht schon längst an RISC-V Designs für Smartphones arbeiten. Ich denke, Apple wird in 3-5 Jahren den Vorreiter machen und die anderen ziehen dann nach.
John Doe schrieb: > Dann schauen wir mal auf die Fakten: > STM32F103: 90 DMIPs - nur aus dem CCM > GD32VF103: 153 DMIPS Das will keiner abstreiten. Allerdings kommt es immer drauf an für was man den Chip einsetzt. Wenn die fpu ihren Vorteil ausspielen kann spielen die DMIPS eine ehr untergeordnete Rolle. Und der Stromverbrauch ist für sehr viele Anwendungen auch das letzte was relevant ist, weil der Rest drum rum den Kohl fett macht. John Doe schrieb: > RISC-V macht das Rennen. Die Frage ist nur, wann ARM die weisse Flagge > hisst. totgesagte leben häufig lang. John Doe schrieb: > Der Hype ist vorbei. RISC-V Produkte werden in Milliardenstückzahlen > verkauft. Aber nicht in dem Bereich der hier verglichen wird. Eigentlich ist mir die Architektur auch relativ Wumpe. Für den Anwender in C++ spielt das kaum eine Rolle. Welchen Controller man für den jeweiligen Einsatzzweck benutzt ist von weit mehr Faktoren abhängig wie der Erbsen(DMIPS)-Zählerei. John Doe schrieb: > Ob zwei oder 4 Leitungen ist doch wirklich latte. Für dich ja, für mich nein. Außerdem ist das auch vom Gehäuse abhängig. Bei 48 Pins stört es vielleicht nicht, im Bereich 8-20 eventuell schon deutlich. Ich finde es gut, dass Arm auch im Bereich Cortex M0-M4 Konkurrenz bekommt, aber um mit wehenden Fahnen das Lager zu wechseln, dazu ist es mir noch zu früh.
homa schrieb: > Hat den schon einer bestellt und weis wie viel Porto da noch drauf > kommt? Bestellt noch nicht aber Versand sind 9$ mit Singapore Post und 20$ mit DHL.
Christopher J. schrieb: > homa schrieb: >> Hat den schon einer bestellt und weis wie viel Porto da noch drauf >> kommt? > > Bestellt noch nicht aber Versand sind 9$ mit Singapore Post und 20$ mit > DHL. Die "Estimated availability" hat sich in den letzten Tagen von August über September bis auf aktuell den 9. Oktober verschoben. Keine Ahnung, ob das nun bedeutet, dass die Teile weggehen wie warme Semmeln oder die Produktion stockt.
John Doe schrieb: >> Solange jedenfalls sich ein RISC-V nicht >> genauso komfortabel Debuggen lässt über 2 Leitungen (SWD) + Versorgung >> würde ich um nichts in der Welt tauschen. > > Ob zwei oder 4 Leitungen ist doch wirklich latte. Da muss man ihm schon recht geben. Ich hab es hier zum Beispiel vorwiegend mit fingernagelgroßen Platinen oder kleiner zu tun, da drängeln sich de Bauteile so dicht daß man stundenlang um noch einen weiteren Quadratmillimeter kämpfen kann und wenn man dann noch zwei zusätzliche Pads zusätzlich irgendwo hin basteln muss um den Debugger anschließen zu können fühlt sich das ungefähr so an als ob man im Wohnzimmer unbedingt noch zwei(!) Tischtennisplatten aufstellen möchte ohne dabei auf Couchgarnitur und Esstisch verzichten und noch eine Zwischenwand einreißen zu müssen. Das ist schon äußerst bescheiden daß man die nicht mit SWD oder etwas vergleichbarem debuggen kann, das wurde vollkommen verpennt! Da müssen die sich dringend noch was einfallen lassen im Markt für Mikrocontroller, 4 Pins zu verschwenden sind hier absolut anachronistisch und vollkommen inakzeptabel, selbst 2 Pins sind schon hart an der Grenze des vertretbaren. Wir können Sonden zum Mars schicken und Implantate ins Gehirn pflanzen aber Debugschnittstellen für die modernsten unserer Prozessoren müssen immer noch den selben verstaubten Flair ausstrahlen wie 1970er TTL-Gräber mit monströsen Steckerleisten und handbreitem Flachbandkabel (Übertreibungen erhöhen die Anschaulichkeit). Inakzeptabel!
Helmut V. schrieb: > Bla schrieb: >> Hier ist noch ein RISC-V: >> >> https://phys.org/news/2019-08-advanced-microprocessor-carbon-nanotubes.html >> >> Leider steht da nichts zu Tempo und Wattzahl. > > Aus Karbonröhrchen? Also das heisst wir können jetzt bald auf Silizium > verzichten? Taktfrequenz: 10kHz https://arstechnica.com/science/2019/08/16-bit-risc-v-processor-made-with-carbon-nanutubes/ In their paper, the researchers focus on all the ways their existing design could be improved. For example, the channel length is the distance between the metal contacts bridged by nanotubes. That length helps set the clockspeed, and for RV16X-NANO, the clockspeed was only 10kHz. The metal contacts also had to be very wide in order to ensure that there were enough nanotubes bridging them. We know in theory that improvements in both are possible, and ramping up the clockspeed is a definite option with this approach.
>Wir können Sonden zum Mars schicken und Implantate ins Gehirn pflanzen >aber Debugschnittstellen für die modernsten unserer Prozessoren müssen >immer noch den selben verstaubten Flair ausstrahlen wie 1970er >TTL-Gräber mit monströsen Steckerleisten und handbreitem Flachbandkabel >(Übertreibungen erhöhen die Anschaulichkeit). Inakzeptabel! Naja, nicht zwingend. Atmel hätte da Debug-Wire im Angebot.
Bernd K. schrieb: > Das ist schon äußerst bescheiden daß man die nicht mit SWD oder etwas > vergleichbarem debuggen kann, das wurde vollkommen verpennt! Da müssen > die sich dringend noch was einfallen lassen im Markt für > Mikrocontroller, 4 Pins zu verschwenden sind hier absolut > anachronistisch und vollkommen inakzeptabel, selbst 2 Pins sind schon > hart an der Grenze des vertretbaren. Sorry, das ist aber sowas von bull-shit! JTAG ist nunmal der Standard um mit div. ICs zu "sprechen" Wenn du zum debuggen wirklich möglichst keine Pins verwenden willst, dann bitte nutz doch einen GDB stub am chip selbst. Damit verbrauchst du dann überhaupt keinen kostbaren Platz am PCB und kommunizierst über irgend eine Schnittstelle die ohnehin am Board drauf ist. Beispiele dafür: https://github.com/espressif/esp-gdbstub https://github.com/mborgerson/gdbstub für ein CM3 habe ich das schon einmal gemacht. Ist nicht wirklich nicht die Tragik. 73
temp schrieb: > John Doe schrieb: >> Dann schauen wir mal auf die Fakten: >> STM32F103: 90 DMIPs - nur aus dem CCM >> GD32VF103: 153 DMIPS > > Das will keiner abstreiten. Allerdings kommt es immer drauf an für was > man den Chip einsetzt. Wenn die fpu ihren Vorteil ausspielen kann > spielen die DMIPS eine ehr untergeordnete Rolle. Und der Stromverbrauch > ist für sehr viele Anwendungen auch das letzte was relevant ist, weil > der Rest drum rum den Kohl fett macht. > > John Doe schrieb: >> RISC-V macht das Rennen. Die Frage ist nur, wann ARM die weisse Flagge >> hisst. > > totgesagte leben häufig lang. > > John Doe schrieb: >> Der Hype ist vorbei. RISC-V Produkte werden in Milliardenstückzahlen >> verkauft. > > Aber nicht in dem Bereich der hier verglichen wird. > Eigentlich ist mir die Architektur auch relativ Wumpe. Für den Anwender > in C++ spielt das kaum eine Rolle. Welchen Controller man für den > jeweiligen Einsatzzweck benutzt ist von weit mehr Faktoren abhängig wie > der Erbsen(DMIPS)-Zählerei. Weil Du gerade DMIPS sagst...MIPS gibts auch schon lange und das wird auch verwendet (Router etc) ich sehe nicht das alleine das Vorhandensein einer Weiteren Architektur in dem Bereich dermaßen gründlich aufräumt das MIPS da verschwindet. Ähnlich wirds bei ARM sein, Performance ist nicht Alles. Gruß, Holm
Hans W. schrieb: > JTAG ist nunmal der Standard um mit div. ICs zu "sprechen" Ja, leider. 70er Jahre. Wird zeit für was besseres, SWD existiert ja schon, das oder sowas ähnliches (falls ARM ein Patent drauf hat) hätte man einbauen können. 4 Drähte sind vollkommen inakzeptabel für kleine µC Anwendungen.
:
Bearbeitet durch User
Bernd K. schrieb: > 4 Drähte sind vollkommen inakzeptabel für kleine µC Anwendungen. Wie gesagt: Dann nimm 0 zusätzliche Drähte und einen GDB-Stub. Fändest du es eigentlich super, wenn jeder Hersteller sein eigenes Süppchen kochen täte?
S. R. schrieb: > Dann nimm 0 zusätzliche Drähte und einen GDB-Stub. Das ist doch eine vollkommen exotische Notlösung mit kastrierter Funktionalität die nur in ausgewählten Fällen überhaupt praktikabel ist. Und null Leitungen braucht die auch nicht, denn per Telepathie wird sie die Informationen bestimmt nicht übertragen. Das braucht kilobyteweise kostbaren Flash, dann krallt es sich einen UART samt Interrupt (wenn überhaupt noch einer frei ist) und wenn der µC jungfräulich ist muss ich es erstmal anderweitig drauf flashen, und flashen vor dem Debuggen aus der IDE ist dann auch nicht mehr, das wäre ein einziges vorsintflutliches Gefrickel! Da geb ich doch lieber Morsezeichen an ner LED aus. SWD hätte man schon noch mit einbauen können (und wird man wahrscheinlich noch irgendwann) aber wahrscheinlich hatte man noch nicht die kleinen µC mit wenigen Pins auf dem Schirm als man RISC-V erfand, wahrscheinlich weil noch keine Praktiker mit im Boot waren die das am Ende auch vernünftig benutzen können wollen.
:
Bearbeitet durch User
Mach dich doch mal schlau was da alles geht! Das ist eigentlich ziemlich Standard... also ein Linux Kernel der sich "nebenbei" selbst debuggen kann ohne JTAG interface auf der CPU (nennt sich kgdb). Programmieren ist doch auch kein Problem mehr. Die allermeisten uCs haben doch irgendeinen Bootloader drauf der per USB oder UART Daten annimmt. Ich habe übrigens geschrieben: Hans W. schrieb: > und kommunizierst über > irgend eine Schnittstelle die ohnehin am Board drauf ist. Also wenn du z.B. USB verwendest, dann mach einfach einen weiteren Serial Endpoint auf und du bekommst deinen Debugger fast 4free :) Mich stört JTAG eigentlich gar nicht. Siehs doch mal so, wenn ich neben dem µC noch einen CPLD drauf habe, dann will ich JTAG haben und nicht SWD weil ich so beides ansprechen kann. Außerdem finde ich, dass die RISC-V leute ziemlich coole und praktische ideen habe. Aus der RISC-V debug spec: There may be multiple DTMs in a single platform. Ideally every component that communicates with the outside world includes a DTM, allowing a platform to be debugged through every transport it supports. For instance a USB component could include a DTM. This would trivially allow any platform to be debugged over USB. All that is required is that the USB module already in use also has access to the Debug Module Interface. Also ich fände das Beschriebene schon innovativ. Bisher ist eben nur ein JTAG Modul spezifiziert. Dagegen stört mich, dass man bei der Peripherie sich nicht auf quasi-standards hat einigen können. z.B. einfach einen 16550 UART und nicht etwas verkrüppeltes wie bei SiFive (https://sifive.cdn.prismic.io/sifive%2F834354f0-08e6-423c-bf1f-0cb58ef14061_fu540-c000-v1.0.pdf => nur 8 datenbits! ich nutze oft 9-bit zum synkronisieren) oder einen STM32 Nachbau bei Giga Devices (aber gottseidank nicht etwas komplett eigenes). Aber gut. Der Core skaliert eben von mini bis riesig und die 1. echten chips sind eher größer. Wenn die Chipfläche wirklich so klein ist wie behauptet sehe ich aber gute chancen 8-pinner mir RISC-V zu bekommen. Und da sehe ich dann den wirklichen Vorteil der ISA. Sie ist frei. Es gibt fertige Toolchains und sie skaliert. Wenn jetzt noch freie Perepherie-Standards kommen würden wär das die Krönung. 73
Bernd K. schrieb: > Das ist schon äußerst bescheiden daß man die nicht mit SWD oder etwas > vergleichbarem debuggen kann, das wurde vollkommen verpennt! Ich denke nicht, dass das "verpennt" wurde, sondern eher, dass es auf der Prioritätenliste nicht so weit oben stand und ganz sicher noch nachgeliefert wird. Viel wichtiger - und das wurde bereits geliefert - ist doch die eigentliche Spezifikation für die Debugfunktionalität des Kerns.
Hans schrieb: > Mach dich doch mal schlau was da alles geht! > > Das ist eigentlich ziemlich Standard... also ein Linux Kernel der sich > "nebenbei" selbst debuggen kann Hör auf. Hier gehts um nen kleinen µC mit wenig ressourcen und kein Multicore Linux Monster. Der hat Hardware eingebaut damit man bestimmte Sachen nicht in Software machen muss. Zum Beispiel die Debug-Schnittstelle. Der komische GDB-Stub von Github mit 20 Anwendern weltweit ist bestimmt nicht der Weg wie man sowas stattdessen implementiert. Dieser Vorschlag ist vollkommen grotesk und grenzt schon an Trollerei! Dann schon lieber noch 2 weitere Pins für JTAG freischaufeln und die Pads dafür noch irgendwo unterbringen falls noch irgendwo ein Platz auf der Platine ist, ansonsten Arschkarte gezogen, nicht geeignet für diese Anwendung aufgrund unerreichbarer Debugschnittstelle. Das was ich hier in der Praxis machen muss (und erfolgreich und bequem mache mit swd) bekomm ich mit solchen lächerlichen Krücken nicht abgebildet. Es fängt schon damit an daß ich keinen zweiten UART erübrigen kann und die Unterbrechungen für dessen IRQ auch nicht. Und wenn dann hängt er garantiert am falschen Pin. Und dann noch J-Scope, wie stellt Du Dir das vor? Ich steige gerne auf RISC-V um und portiere auch gerne Code falls nötig und lerne sogar RISC-V-Assembler um im Startup rumzuwerkeln wenns sein muss aber Abstriche (noch dazu so extreme die mich bei der täglichen Arbeit behindern, jeden Tag aufs Neue) will ich dafür keine machen! Nicht solche! Es muss schon besser sein als bisher oder mindestens genauso gut, nicht schlechter! Also warten wir auf den zweiten Versuch.
:
Bearbeitet durch User
Bernd K. schrieb: > Hier gehts um nen kleinen µC mit wenig ressourcen Ähm... die GD32V ist bei weitem kein kleiner µC... aber gut Bernd K. schrieb: > Der komische GDB-Stub von Github mit 20 Anwendern weltweit ist bestimmt > nicht der Weg wie man sowas stattdessen implementiert. Dieser Vorschlag > ist vollkommen grotesk und grenzt schon an Trollerei! Ähm...den kgdb gibts seit über 10 jahren... wenn du das als Trollerei ansiehst... naja 73
Hans schrieb: > Ähm...den kgdb Raffst Du es nicht? Hier gehts um nen kleinen Miokrocontroller! Bare metal! Nix Linux. Da soll ich irgendwelche wackeligen Ungetüme in den UART-Interrupt reinfrickeln damit ich irgendwas debuggen kann, nur leider nicht mehr den eigenlichen UART-Interrupt selbst samt meinem ganzen IO-Link Stack der dran hängt? Was soll ich dann noch groß debuggen wenn meine halbe Firmware davon lahmgelegt ist? Und wie kann ich damit nen leeren µC flashen? Oder meine Änderungen reinladen wenn ich in der IDE auf den grünen Käfer klicke? Und wo kann ich das J-Scope anschließen? Erklär mal!
:
Bearbeitet durch User
Bernd K. schrieb: > Das ist schon äußerst bescheiden daß man die nicht mit SWD oder etwas > vergleichbarem debuggen kann, das wurde vollkommen verpennt! Da müssen > die sich dringend noch was einfallen lassen im Markt für > Mikrocontroller, 4 Pins zu verschwenden sind hier absolut > anachronistisch und vollkommen inakzeptabel, selbst 2 Pins sind schon > hart an der Grenze des vertretbaren. Bitte? Wie willst du sonst vernünftig In-Circuit debuggen? Wie oben schon genannt: der JTAG-Standard ist m.E. der einzig vernünftig gangbare Weg, um robust und non-intrusiv zu debuggen. Alle Ansätze mit gdbstubs sind heilloser Murks im Sinne der quantenmechanischen Messung: Das System wird durch den Debugger schon beeinflusst. Typischerweis debuggt man genau dann per ICE, wenn Exceptions auftreten und der stub schon längst nicht mehr tut. Ansätze mit SWD oder SBW oder wie sie es alle nennen: Meinetwegen, wenn nur ein uC auf der Platte sitzt. Aber für Massenproduktion? Naja. Bei den sog. 'Verbesserungen' der Debugschnittstellen geht der Schuss des öfteren in die Hose, darum fasse ich schon keinen Chip mehr an, der das nicht nachweislich sauber nach Standard implementiert hat. Ich sehe das Problem nicht, vier Traces irgendwo hin zu ziehen und auf einen Nadeladapter zu exportieren. Oder TagConnect, oder irgendwas produktionstaugliches. Ich sehe überhaupt den Grund für die Diskussion nicht, da es auch für den RISC-V einen sauber definierten TAP-Standard (Test access port) gibt. Der tut auch. Es gibt dafür einen gdbproxy und m.W. ein entsprechend funktionierende Unterstützung bei OpenOCD (nicht getestet).
Bernd K. schrieb: > fühlt sich das ungefähr so an als ob man im > Wohnzimmer unbedingt noch zwei(!) Tischtennisplatten aufstellen möchte > ohne dabei auf Couchgarnitur und Esstisch verzichten und noch eine > Zwischenwand einreißen zu müssen. Das ist ein sehr schöner Vergleich! Wenn man bei einer halbwegs fertigen, dicht gepackten Leiterplatten noch eine Befestigungsbohrung für M3 einbringen muss, fühlt sich das auch so an, als ob man das Hauptrohr für ein Wasserkraftwerk nachträglich quer durch das Wohnzimmer verlegen muss. > immer noch den selben verstaubten Flair ausstrahlen wie 1970er > TTL-Gräber mit monströsen Steckerleisten und handbreitem Flachbandkabel Debug-Schnittstellen sind keineswegs an so klobige Steckverbinder gebunden, aber ein einfacher Pfostenstecker im 2,54mm-Raster ermöglicht es eben, sehr einfach einen prüflingsspezifischen Adapter zu bauen. Interessant finde ich die Idee, einen ggf. vorhandenen SD- oder MicroSD-Steckplatz umzuschalten und für Debuggingzwecke zu verwenden: https://www.lauterbach.com/frames.html?ad3787.html https://www.lauterbach.com/frames.html?ad3883.html
Und noch ein Hinweis: die Debug-Funktionalität dient ja primär für Entwicklungszwecke durch den Gerätehersteller (oder eine von ihm beauftragte Entwicklungsbude). Aus Fertigungssicht interessiert wieder vor allem, wie man möglichst schnell und zuverlässig Firmware in das Gerät hineinbekommt und wie man einen Funktionstest (und möglicherweise In-Circuit-Test) durchführen kann. Zu diesem Zeitpunkt sind aber die Leiterplatten in den meisten Fällen nicht vereinzelt, sondern befinden sich noch im Fertigungsnutzen. Daher kann man auch den Nutzenrand für die Kontaktierung der Leiterplatte verwenden. Sofern die Firmware(ladezeit) nicht allzu groß ist, kann man bei JTAG auch mehrere Einzelleiterplatte in Reihe schalten, was die Anzahl an Kontakten am Nutzenrand minimiert. Man muss nur beim Layout entsprechende Vorkehrungen treffen, damit bei der späteren Vereinzelung mittels Schere oder Fräser keine Kurzschlüsse durch Späne entstehen können.
Bernd K. schrieb: >> Dann nimm 0 zusätzliche Drähte und einen GDB-Stub. > > Das ist doch eine vollkommen exotische Notlösung mit kastrierter > Funktionalität die nur in ausgewählten Fällen überhaupt praktikabel ist. > Und null Leitungen braucht die auch nicht, denn per Telepathie wird sie > die Informationen bestimmt nicht übertragen. Bitte lerne lesen: "0 zusätzliche Drähte". Irgendeine Verbindung zur Entwicklungsmaschine wirst du ja schon haben, sonst wäre das mit dem Flashen auch relativ schwer. > Da geb ich doch lieber Morsezeichen an ner LED aus. Du kannst die Morsezeichen auch binär ausgeben und einen gdb am Entwicklungsrechner ranflanschen... Bernd K. schrieb: > Der komische GDB-Stub von Github mit 20 Anwendern weltweit ist > bestimmt nicht der Weg wie man sowas stattdessen implementiert. [ ] Du weißt, um was es geht. > Dieser Vorschlag ist vollkommen grotesk und grenzt schon > an Trollerei! Dann schon lieber noch 2 weitere Pins für > JTAG freischaufeln Ich wusste es, du kannst doch gute Ideen haben! :-) > Ich steige gerne auf RISC-V um und portiere auch gerne Code falls nötig > und lerne sogar RISC-V-Assembler um im Startup rumzuwerkeln wenns sein > muss aber Abstriche (noch dazu so extreme die mich bei der täglichen > Arbeit behindern, jeden Tag aufs Neue) will ich dafür keine machen! Waschen ja, nass machen nein. Kann ich nachvollziehen, denn Veränderungen sind immer anstrengend. Aber dann behaupte nicht, du würdest gerne auf RISC-V umsteigen. Im Übrigen schuldest du mir noch eine Antwort auf die Frage: S. R. schrieb: > Bernd K. schrieb: >> 4 Drähte sind vollkommen inakzeptabel für kleine µC Anwendungen. > > Fändest du es eigentlich super, wenn jeder Hersteller sein eigenes > Süppchen kochen täte? Weil JTAG ist weltweit über so ziemlich alle Chipfamilien der Standard, und kann im Zweifelsfall auch über den SD-Slot benutzt werden.
Bernd K. schrieb: > Hans schrieb: >> Ähm...den kgdb > > Raffst Du es nicht? Hier gehts um nen kleinen Miokrocontroller! Bare > metal! Nix Linux. Naja, das Board das da.gaaaanz oben referenziert wird hat eine sifive fe310 drauf. Das ist kein 1k Wörter otp..... Ich gebe zu das so nicht verwenden zu wollen, aber der cortex-m Kern ist (irgendwie) "Linux-fähig" https://github.com/uclinux-cortexm/uclinux Also ist das mit dem kleineren risc-v cores schon irgendwie vergleichbar. Bei 8pins ist jtag zwar kass, aber in so kleinen packages gibt's den core noch gar nicht. Gib dem core noch 1-2 Jahre und urteile dann. Ich habe mir jedenfalls eine qemu Session über Weihnachten reserviert um die Isa etwas kennenzulernen. Nachdem es stabile llvm und gcc gibt hat der core jedenfalls bessere Überlebenschancen wie jeder proprietäre Newcomer. 73
> Daher kann man auch den Nutzenrand für die Kontaktierung der Leiterplatte > verwenden. So einfach ist das nicht. Du hast dann unter Umstaenden Kontakte aus dem Verguss kucken und haelst Abstaende nicht ein die du vielleicht fuer ATEX brauchst. Und wenn die Schaltung mit HF im zweistelligen Ghz-Bereich arbeitet dann laeuft sie ohne Verguss nicht wenn sie dafuer gerechnet wurde. Ein vernuenftiges durchdachtes Debuginterface mit wenigen Leiterbahnen ist schon toll. Was mich z.B an ARMs stoert sobald da das Interface nutzt geht der Stromverbrauch nach oben und bleibt es auch wenn man den Debugstecker wieder abzieht. Das kann nervig sein wenn die Schaltung nur mit wenigen mA laufen muss. Es ist auch nervig das man mit dem Anstecken die Potentialtrennung aufhebt. Da sind dann moeglichst wenig Leitungen auch von Vorteil wenn man sie trennen muss. Klar, wenn man wirklich will dann gibt es fuer alles eine Loesung. Aber in der Industrie ist das nicht immer so einfach wie auf dem Basteltisch zuhause. Olaf
Andreas S. schrieb: > Wenn man bei einer halbwegs fertigen, dicht gepackten Leiterplatten noch > eine Befestigungsbohrung für M3 einbringen muss, fühlt sich das auch so > an, als ob man das Hauptrohr für ein Wasserkraftwerk nachträglich quer > durch das Wohnzimmer verlegen muss. Das haben sie in unserem winzigen Kellerverschlag mit einem WC-Abwasser-Rohr gemacht. Morgens hieß es noch: Wir müssen da mal in ihren Keller, wegen einem Rohr. Als ich von der Arbeit zurück kam, stand mein ganzes Zeug im Hausflur verteilt. Auch das Regal, denn dass passt nicht mehr in den Raum, weil da jetzt ein Abwasser-Rohr quer durch läuft. Super, ich war hellauf begeistert! Man hätte mich gerne vorher aufklären dürfen. Ich dachte, die reparieren nur etwas.
Fitzebutze schrieb: >> selbst 2 Pins sind schon >> hart an der Grenze des vertretbaren. > Bitte? Wie willst du sonst vernünftig In-Circuit debuggen? Mit SWD zum Beispiel? > Wie oben schon genannt: der JTAG-Standard ist m.E. der einzig vernünftig > gangbare Weg, um robust und non-intrusiv zu debuggen. Alle Ansätze mit > gdbstubs sind heilloser Murks Genau das schreib ich doch die ganze Zeit, hast Du es nicht gelesen? gdb-Stub ist Murks. Ich will SWD. > Ich sehe das Problem nicht, vier Traces irgendwo hin zu ziehen Das habe ich doch weiter oben erläutert anhand der beiden Tischtennisplatten im Wohnzimmer. Das kannst Du auf großen Platinen machen aber je kleiner die Platine wird und je weniger Pins der µC hat desto schwieriger. Ich hab hier mit etlichen Platinen zu tun bei denen wären nochmal zwei weitere Pads vollkommen utopisch. Vollkommen! Utopisch! Genau aus dem Grund wurde SWD erfunden, genau aus dem Grund gibts für noch kleinere µC sogar Eindrahtlösungen. Die können alles was JTAG kann (bis auf Daisy chaining vielleicht aber wir haben es mit fingernagelgroßen Platinen zu tun da sitzt nur ein µC drauf im kleinsten Package in dem er lieferbar ist) und sparen kostbare Pins und kostbaren Platz.
:
Bearbeitet durch User
S. R. schrieb: > Weil JTAG ist weltweit über so ziemlich alle Chipfamilien der Standard, > und kann im Zweifelsfall auch über den SD-Slot benutzt werden. Die kleinen Controller haben alle nur noch SWD weil für 4 Pins gar kein Platz mehr ist. Das ist auch standardisiert.
S. R. schrieb: >> Ich steige gerne auf RISC-V um und portiere auch gerne Code falls nötig >> und lerne sogar RISC-V-Assembler um im Startup rumzuwerkeln wenns sein >> muss aber Abstriche (noch dazu so extreme die mich bei der täglichen >> Arbeit behindern, jeden Tag aufs Neue) will ich dafür keine machen! > > Waschen ja, nass machen nein. Kann ich nachvollziehen, denn > Veränderungen sind immer anstrengend. Aber dann behaupte nicht, du > würdest gerne auf RISC-V umsteigen. Veränderungen... Blödsinn! Ich war schon so weit mich mit dem Ding anzufreunden, ich hab fast schon eine Art von Euphorie verspürt, genau bis zu dem Augenblick als ich das mit dem fehlenden SWD gesehen habe, dann war schlagartig Ende [Geräusch von kratzender Schallplatte und Ende der Musik hier einfügen]. Auf SWD verzichten zu müssen wäre bei allen meinen Anwendungen ein unüberwindlicher Showstopper. Das hat nichts mit "Veränderungen" zu tun und auch nichts mit "mach mich nicht nass" sondern mit dem kompletten ersatzlosen Wegfall eines essentiellen Features. Da bei mir beim besten Willen kein Platz für JTAG ist (hab ich oben erläutert) und SWD dort nicht vorhanden ist wird mir ernsthaft vorgeschlagen ich soll mich stattdessen wieder auf UART-Debugging beschränken wie in der alten Zeit und den BOOT-Pin rausführen und zusätzlich nen UART-Pin und mich dann von allen nützlichen Tools und Arbeitserleichterungen verabschieden und den guten J-Link wieder im Schrank verstauben lassen zusammen mit all der Software die dazugehört. Das ist völlig absurd. Ich weiß sehr wohl wie man seinen Code instrumentiert wenn man aus irgendeinem Grund keinen Debugger hat, ich kenne alle Tricks aus dem Buch und noch ein paar mehr, ich bin ja schließlich nicht auf der Nudelsuppe dahergeschwommen, ich hab das alles schon durch, aber ich hab keine Lust so ein zeitraubendes Gefrickel wieder zum alltäglichen Normalzustand werden zu lassen, dazu hab einfach keine Zeit! Ich brauch ne vollwertige Debugschnittstelle mit maximal 2 Signalleitungen so wie wir es bereits die ganze Zeit hatten in den ganzen letzten zig Jahren oder wie lange es SWD schon gibt.
:
Bearbeitet durch User
Bernd K. schrieb: > Ich brauch ne vollwertige Debugschnittstelle mit maximal 2 > Signalleitungen so wie wir es bereits die ganze Zeit hatten in den > ganzen letzten zig Jahren oder wie lange es SWD schon gibt. Das heißt dann wohl dass du noch nie "vollwertigen" Debugger genutzt, wie z.b. einen Lauterbach genutzt. Vollwertig (ETM) ist mit 2 Pins nicht drin. Aber da reicht auch jtag nicht aus.
Olaf schrieb: > Es ist auch nervig das man mit dem Anstecken die Potentialtrennung > aufhebt. Da sind dann moeglichst wenig Leitungen auch von Vorteil wenn > man sie trennen muss. Naja, ich würde lieber zwei unidirektionale, als eine bidirektionale Leitung trennen. Jedenfalls halte ich das für bedeutend leichter.
Irgendwie hab' ich den Eindruck, als steht Ihr euch bisschen selber im Weg. Passt auch so irgendwie nicht wirklich zum Thema RISCV - aber nun gut. Bernd K. schrieb: > Genau aus dem Grund wurde SWD erfunden, genau aus dem Grund gibts für > noch kleinere µC sogar Eindrahtlösungen. Die können alles was JTAG kann > (bis auf Daisy chaining vielleicht aber wir haben es mit > fingernagelgroßen Platinen zu tun da sitzt nur ein µC drauf im > kleinsten Package in dem er lieferbar ist) und sparen kostbare Pins und > kostbaren Platz. Du kannst mir jetzt doch nicht wirklich erzählen, dass dir der Platz für vier Traces fehlen. Wenn es für Pads nicht reicht, dann eben an den Platinenrand damit. Entweder konstruierst du dafür dann eh einen Adapter selber, oder machst eine Debug-Extension zum Abbrechen hin. So einige Eindraht-Lösungen sind leider auch Murks und vom ICE her inakzeptabel, aber mag bei einem 8051 grade noch benutzbar sein. Bei einem komplexeren RISCV will man das wirklich nicht und den Fehler des Wildwuchses bei den ARM-TAPs nicht wiederholen. Wenn du die Anzahl Pins zum Kriterium machst, dann suchst du dir halt einen passenden Chip. Keep it simple. Keiner braucht wirklich unbedingt RISCV.
Fitzebutze schrieb: > Du kannst mir jetzt doch nicht wirklich erzählen, dass dir der Platz für > vier Traces fehlen. Doch. Ich denke daß Dir einfach nicht bewußt ist wie klein eine Platine sein kann, ihr baut bei euch halt komplett anderes Zeug als wir hier. Bei uns wird mitunter um jeden halben Quadratmillimeter Platinenfläche gerungen.
avr schrieb: > Das heißt dann wohl dass du noch nie "vollwertigen" Debugger genutzt, > wie z.b. einen Lauterbach genutzt. Vielen Dank. Ich bin mit Segger vollkommen zufrieden, der kann alles was nötig ist über SWD. Auch tracen (was ich bisher erst einmal gebraucht hätte aber dank aller anderen ebenfalls funktionierenden Debugfunktionen sparen konnte). Es gibt immer einen noch teureren Debugger, solange bis man den teuersten hat und selbst dann kann man sich noch Sachen ausdenken die man gerne auch noch machen würde und die dann unmöglich sind. Aber das hilft alles nichts wenn man maximal 2 Pins erübrigen kann und damit kann man heutzutage schon hervorragend debuggen. Nur halt nicht wenn man mit UART herumwürgen soll wie weiter oben von der Arduino-Fraktion vorgeschlagen.
:
Bearbeitet durch User
Ich wette als nächstes bringt STM zu ihren ARMen passende RISC-V Varianten heraus, und zwar MIT SWD. Der Ball wurde in deren Seite gekickt und hat sie von hinten am Kopf getroffen, jetzt müssen sie sich umdrehen und den Ball spielen bevor er von selbst ins Tor rollt!
:
Bearbeitet durch User
Bernd K. schrieb: > Ich wette als nächstes bringt STM zu ihren ARMen passende RISC-V > Varianten heraus, und zwar MIT SWD. Ich denke nicht, dass es RISC-V mit "SWD" geben wird, weil eben SWD von ARM spezifiziert ist. Elektrisch ist es aber doch auch nur eine half-duplex SPI-Verbindung, womit dann wiederum die Sache prinzipiell möglich sein wird, wie Hans schon geschrieben hatte: Hans schrieb: > Aus der RISC-V debug spec: > > There may be multiple DTMs in a single platform. Ideally every component > that communicates with the outside world includes a DTM, allowing a > platform to be debugged through every transport it supports. For > instance a USB component could include a DTM. This would trivially allow > any platform to be debugged over USB. All that is required is that the > USB module already in use also has access to the Debug Module Interface.
> Ich wette als nächstes bringt STM zu ihren ARMen passende RISC-V Varianten
heraus
STM ist "nur" silver-member nach riscv.org. SiFive, NXP und Microchip
dagegen platin. Kann man da ablesen, wie ernst es die Hersteller nehmen?
Bernd K. schrieb: > Ich will SWD. Tja, dann musst du wohl auf ewig bei ARM bleiben. SWD ist schließlich deren Eigentum. PS: Genau das meinte ich mit Waschen und Nassmachen.
Ich finde das ganze steht und fällt mit der Entwicklungsumgebung. Dazu die IDE, Debugger und sowie wie das CMSIS Ja Jtag wäre sicher OK. Auch wenn eine schmalere Schnittstelle oft schöner wäre Auf serial Debugging setze ich Mal nicht...
Bernd K. schrieb: > Doch. Ich denke daß Dir einfach nicht bewußt ist wie klein eine Platine > sein kann, ihr baut bei euch halt komplett anderes Zeug als wir hier. > Bei uns wird mitunter um jeden halben Quadratmillimeter Platinenfläche > gerungen. Ist mir bewusst. Aber nochmal: auch bei einem 0.3 BGA kriegt man JTAG noch auf irgend einem Layer an den Rand geroutet. Wo brauchst du da Platinenfläche? Die Diskussion driftet regelmässig in irgend ein Gejammer ab, irgendwas ist immer zu teuer, zu gross, usw. Wenn Ihr genügend von den Dingern produziert, könnt ihr auch einfach zum Hersteller gehen, und euch den Chip so wie ihr in wollt, bestellen. Wenn das unbedingt das hirnrissige Coresight per SWD sein muss, dann kauft ihr euch das halt als IPCore. Macht einfach IMHO keinen Sinn, wenn man einen sauberen JTAG haben kann.
Fitzebutze schrieb: > Ist mir bewusst. Aber nochmal Schon klar, ist anscheinend wirklich nicht leicht zu verstehen, aber es ist so wie ich schon sagte: Es ist kein Platz. Punkt. Ich weiche keinen einzigen Pin zurück, das lass ich gar nicht erst einreißen. Die Platinen sind beidseitig vollgepackt daß man fast kein grün mehr sieht. Es gibt keine weiteren Pins, nicht einen einzigen, Ende der Verhandlung! Außerdem hab ich nicht gejammert sondern nur dem Kollegen beigepflichtet der gesagt hat JTAG sind zu viele Leitungen. Da hab ich beigepflichtet, gejammert hat niemand. Stattdessen werd ich gegen meinen Willen in ne Diskussion reingezogen in der mir jeder erklärt "eine Leiterbahn ist keine Leiterbahn" und "Zwischen Keramik-C und Widerstand passt immer noch n Kupferband". Gejammert hat hier niemand, höchstens genervt gestöhnt.
:
Bearbeitet durch User
Bernd K. schrieb: > Es gibt keine weiteren Pins, nicht > einen einzigen, Ende der Verhandlung! Du scheinst nur ein einziges Projekt, nämlich dein aktuelles, zu kennen.
S. R. schrieb: > Du scheinst nur ein einziges Projekt, nämlich dein aktuelles, zu kennen. Nein das ist eine Grundsatzentscheidung basierend auf einem Dutzend vergangener Projekte und allen die noch kommen werden. 2 Pins zusätzlich lass ich hier nicht einreißen, ich hab nichts zu verschenken, solche weitreichenden Fässer mit solchen Zugeständnissen mach ich nicht auf. Das hab ich doch klar ausgedrückt? Hör auf mich vom Gegenteil überzeugen zu wollen, Du kannst bei Dir selbst meinetwegen 12 Pins anschließen, mach Du Dein Ding, ich hab andere Anforderungen, ich mach mein Ding. Ist jetzt langsam mal Ende der Debatte?
:
Bearbeitet durch User
Bernd K. schrieb: > Schon klar, ist anscheinend wirklich nicht leicht zu verstehen, aber es > ist so wie ich schon sagte: Es ist kein Platz. Punkt Doch. Es ist ganz einfach zu verstehen. Eine Kontaktierung am Platinenrand (und zwar direkt auf der Kante) benötigt keinen Platz! Dritte Dimension! Aber ich habe jetzt nicht noch Lust, das hinzuzeichnen, und ich wette, du möchtest uns dein Layout auch nicht zeigen. Das kindische Gestrampel, weil man ein paar Traces nicht geroutet kriegt/kriegen will hat allerdings nicht allzuviel mit RISC-V zu tun. Aber so kennen wir unser Forum..
So ist es Aberirgendwie scheinen das auch wieder nur aufgebohrte 16 bitter zu sein, obwohl Neuentwicklung. 16 bit timer usw.
Beitrag #5958439 wurde von einem Moderator gelöscht.
Fitzebutze schrieb: > Das kindische Gestrampel, weil man ein paar Traces nicht > geroutet kriegt/kriegen will hat allerdings nicht allzuviel mit RISC-V > zu tun. Aber so kennen wir unser Forum.. Fakt ist doch eins, nur weil der Kern schneller ist werden nicht gleich Heerscharen das Lager wechseln. Und solange man in nur einem Punkt einen Rückschritt hinnehmen muss schon gleich garnicht. Für mich ist fehlendes SWD (oder ähnliches mit 1 oder 2 Leitungen) auch ein Killerkriterium. Und ein einziger Hersteller von Cortex Mx ähnlichen Chips wird nicht allen anderen das Fürchten lernen. Was in ein paar Jahren wird weiss niemand, kann sein dass wir dann deutlich mehr RISC-V im kleinen! Bereich sehen. Dann bewerten wir die Situation eben neu. Im Moment kann ich sehr gut mit dem vorhandenen Cortexen leben.
Beitrag #5958466 wurde von einem Moderator gelöscht.
Beitrag #5958471 wurde von einem Moderator gelöscht.
Beitrag #5958501 wurde von einem Moderator gelöscht.
Beitrag #5958514 wurde von einem Moderator gelöscht.
temp schrieb: > Fakt ist doch eins, nur weil der Kern schneller ist werden nicht > gleich Heerscharen das Lager wechseln. Und solange man in nur einem > Punkt einen Rückschritt hinnehmen muss schon gleich garnicht. Naja, man tauscht einige Vorteile (schnellerer Kern, ähnliche Peripherie) gegen einige Nachteile (kein SWD, kein ARM). Das ist also ein klassischer Kompromiss, bei dem jeder die Vor- und Nachteile für sich abwägen muss. Ein Aber-Das-Wird-Doch-Nie-Was-Geschrei hilft da nicht weiter. temp schrieb: > Im Moment kann ich sehr gut mit dem vorhandenen Cortexen leben. Das wird sich auch auf absehbare Zeit nicht ändern, da braucht man nur in Richtung AVR oder 8051 schielen. Die Frage ist, ob man mit den neuen Chips besser leben könnte. Die Architektur ist da nebensächlich. Dennoch finde ich es ein gutes Zeichen, dass RISC-V langsam käuflich wird.
Leute, es ist hier immer wieder das Selbe. Nur bin dieses mal nicht ich das Opfer, sondern Bernd. Sobald jemand eine Schwäche offenbart, taugt er als Opfer. Dann hackt man auf ihm herum, als müsse derjenige zuerst angeprangert und dann hingerichtet werden, um die Ordnung wieder herzustellen. Wie im Mittelalter bei den Hexen. Der Bernd hat gemeldet, dass ihm in einem bestimmten Projekt seiner Firma wichtig ist, möglichst wenige Pins zu benötigen. Er hat nicht behauptet, dass dieses Bedürfnis allgemein für alle gelten soll. Wenn er in der einen Schaltung keinen Platz hat, dann ist das eben so. Es steht euch nicht zu, ihn deswegen zu kritisieren. Ihr kennt die Situation nicht und ihr habt auch keinen blassen Schimmer, inwiefern Bernd daran Schuld ist. Jetzt lasst ihn und dieses Thema bitte in Ruhe. Das ist ja wirklich zum Fremdschämen hier.
Beitrag #5958634 wurde von einem Moderator gelöscht.
Beitrag #5958636 wurde von einem Moderator gelöscht.
Beitrag #5958644 wurde von einem Moderator gelöscht.
Beitrag #5958645 wurde von einem Moderator gelöscht.
Beitrag #5958650 wurde von einem Moderator gelöscht.
> Jetzt lasst ihn und dieses Thema bitte in Ruhe. Das ist ja wirklich zum
Fremdschämen hier.
+1. Bitte beendet dieses Thema. Weitere Diskussionen zu RISC-V sind
gerne willkommen.
Beitrag #5958660 wurde von einem Moderator gelöscht.
Beitrag #5958714 wurde von einem Moderator gelöscht.
Beitrag #5958718 wurde von einem Moderator gelöscht.
Beitrag #5958728 wurde von einem Moderator gelöscht.
@Stefanus: Warum es hier jetzt um ein Opfer gehen soll, entzieht sich meiner Wahrnehmung, aber es kommt halt nicht so gut, andere als 'ignorant' zu bezeichnen, wo es eigentlich um gutgemeinte Ratschläge geht. Und den Thread für sein Wutkonzert zu kapern ist halt auch daneben. Dann gibt's halt Gegenwind. Zurück zum Thema: Der Grund, warum ein einheitliches Debug-Interface zu begrüssen ist: Die Tools werden viel einfacher zu warten. Bei all den verschiedenen ARM-Derivaten und Interfaces wurden eine Menge Fehler/Verschlimmbesserungen gemacht, das Resultat sieht man im dynamisch verschlungenen Spaghetticode eines bekannten Opensource-Debuggers, der fast nie 100% zuverlässig funktioniert. Diese Verstümmelung von Standards, zu denen ich jetzt auch mal SWD und einige fehlerhafte JTAG-Implementierungen von TI zählen würde, hat einige unserer Kunden schon eine Menge Nerven/Geld gekostet. Für ein einfaches Einprozessorplatinchen mit fertigem Adapter ist das nicht so das Thema, aber bei komplexeren Systemen eben schon. Die RISC-V würde ich auch eher da ansiedeln. Grundsätzliches Problem: IEEE 1149 (JTAG) definiert mal eben die Statemachine und das Verhalten der Schieberegister, aber so einiges anderes nicht. Wenn es die RISC-V-Foundation schafft, mit genügend Moment auch diesen Wildwuchs bei den TAP (Test-Access-Port)-Standards zu beseitigen, dürfte das zu weiterem Erfolg der Architektur führen, und auch div. Hersteller davon abbringen, weitere Standardverstümmelung und Abhängigkeitsverhältnisse zu erzwingen. So kann man sich ganz auf die Entwicklung konzentrieren und (hoffentlich) von ausgehen, dass der Debugger bei jedem Derivat tut. Bei MIPS war das mit dem EJTAG schon anständig, nur viel zu übergewichtig. Mich irritiert es jeweils, wenn ich für einen halbgaren Standard bei der IEEE oder usb.org usw Brückenzoll zahlen muss und immer noch keinen OpenSource-Compliance-Test in der Hand habe. Da hat die RISC-V-Schmiede in weiser Voraussicht schon mal gute Arbeit geleistet, allerdings fehlt mir noch eine VHDL-Referenzimplementation. Und so ist's vermutlich genau das, was die RISC-V-Arch schliesslich erfolgreich machen wird: Nicht die Technik, sondern die Politik.
Fitzebutze schrieb: > Und den Thread für sein Wutkonzert zu kapern Ich fasse dieses "Wutkonzert" mal auf einer Seite zusammen, anscheinend hast Du den wesentlichen Handlungsstrang übersehen: Jemand: Ich mag kein JTAG, zu viele Leitungen, das nehm ich nicht. Störer: Das ist doch nicht Dein Ernst, Traces nehmen keinen Platz weg Ich: Da muss ich ihm aber beipflichten, ich hab auch so enge Platinen. Störer: Blödsinn, Leiterbahnen nehmen keinen Platz weg. Ich: Doch, bei mir jedenfalls schon Störer: Mach Doch UART Debugging wie anno Dunnemals Ich: Nein, das reicht mir nicht, nicht anwendbar. Störer: Doch! UART Debugging ist DER heiße Scheiß, mach das! Ich: Nein mach ich nicht! Und können wir jetzt mal wieder aufhören? Störer: Enge Platinen gibt es nicht, 2 Traces gehen immer! Ich: Doch das gibt es, ich hab keinen Platz. Ende der Debatte. Störer: Leg doch noch 2 Leiterbahnen Ich: Sag mal gehts noch, ist jetzt langsam Ruhe? Störer: Du bist nur unfähig Leiterbahnen zu verlegen Ich: Nein ich hab keinen Platz und können wir das jetzt beenden Störer2: Bernd will hier unbedingt seine Probleme auf RISC-V projezieren Ich: Nein, ich will daß die aufhören auf meinem Beispiel rumzuhacken, das war immerhin nur ein Beispiel, ich weiß gar nicht warum man da so einen Aufstand machen muß. Ich will daß das jetzt aufhört. Helfer: Könnt ihr mal aufhören auf Bernd rumzuhacken, der hat schließlich nur ein Beispiel genannt. Störer: Nein, der macht ein Wutkonzert!
:
Bearbeitet durch User
"The J-Link and J-Trace support cJTAG for ARM and RISC-V" (https://www.segger.com/products/debug-probes/j-link/technology/interface-description) Die scheinen was zu wissen.
Bernd K. schrieb: > Fitzebutze schrieb: >> Und den Thread für sein Wutkonzert zu kapern > > Ich fasse dieses "Wutkonzert" mal auf einer Seite zusammen, anscheinend > hast Du den wesentlichen Handlungsstrang übersehen: > > Jemand: Ich mag kein JTAG, zu viele Leitungen, das nehm ich nicht. > Störer: Das ist doch nicht Dein Ernst, Traces nehmen keinen Platz weg > Ich: Da muss ich ihm aber beipflichten, ich hab auch so enge Platinen. > Störer: Blödsinn, Leiterbahnen nehmen keinen Platz weg. > Ich: Doch, bei mir jedenfalls schon > Störer: Mach Doch UART Debugging wie anno Dunnemals > Ich: Nein, das reicht mir nicht, nicht anwendbar. > Störer: Doch! UART Debugging ist DER heiße Scheiß, mach das! > Ich: Nein mach ich nicht! Und können wir jetzt mal wieder aufhören? > Störer: Enge Platinen gibt es nicht, 2 Traces gehen immer! > Ich: Doch das gibt es, ich hab keinen Platz. Ende der Debatte. > Störer: Leg doch noch 2 Leiterbahnen > Ich: Sag mal gehts noch, ist jetzt langsam Ruhe? > Störer: Du bist nur unfähig Leiterbahnen zu verlegen > Ich: Nein ich hab keinen Platz und können wir das jetzt beenden > Störer2: Bernd will hier unbedingt seine Probleme auf RISC-V projezieren > Ich: Nein, ich will daß die aufhören auf meinem Beispiel rumzuhacken, > das war immerhin nur ein Beispiel, ich weiß gar nicht warum man da > so einen Aufstand machen muß. Ich will daß das jetzt aufhört. > Helfer: Könnt ihr mal aufhören auf Bernd rumzuhacken, der hat > schließlich nur ein Beispiel genannt. > Störer: Nein, der macht ein Wutkonzert! Fehlt noch "Bernd kommt anderen Usern persönlich und blöde" in Deiner Aufstellung. Gruß, Holm
Holm T. schrieb: > Fehlt noch "Bernd kommt anderen Usern persönlich und blöde" in Deiner > Aufstellung. Red nicht immer über dich selber. Wer hat denn hier am Wochenende mit "Arschloch" und weiteren Schimpfwörtern um sich getreten? @mods: Jetzt sperrt diesen Holm doch endlich mal! Mehr als um sich treten und andere beleidigen kann er nicht mehr.
Beitrag #5959596 wurde von einem Moderator gelöscht.
... schrieb: > Holm T. schrieb: >> Fehlt noch "Bernd kommt anderen Usern persönlich und blöde" in Deiner >> Aufstellung. > > Red nicht immer über dich selber. > Wer hat denn hier am Wochenende mit "Arschloch" und weiteren > Schimpfwörtern um sich getreten? > Entschuldige bitte.. doch wohl nur als Echo. > @mods: > Jetzt sperrt diesen Holm doch endlich mal! > Mehr als um sich treten und andere beleidigen kann er nicht mehr. Ach, ich bin Dir wohl in einer Art "..." als Gast lieber? Die Kompetenz, urteilen zu wollen was ich kann und was nicht, spreche ich Dir ganz einfach ab und fertig. Gruß, Holm
Olaf schrieb: >> Daher kann man auch den Nutzenrand für die Kontaktierung der >> Leiterplatte verwenden. > > So einfach ist das nicht. Du hast dann unter Umstaenden Kontakte aus dem > Verguss kucken und haelst Abstaende nicht ein die du vielleicht fuer > ATEX brauchst. Und wenn die Schaltung mit HF im zweistelligen > Ghz-Bereich arbeitet dann laeuft sie ohne Verguss nicht wenn sie dafuer > gerechnet wurde. Aha, nur weil es Baugruppen gemäß ATEX-Norm und ggf. andere im GHz-Bereich gibt, soll der Nutzenrand nicht mehr zur Verfügung stehen? Interessante Logik. Die herausgeführten Leiterbahnen müssen übrigens nicht seitlich herausstehen, sondern ggf. werden dann an den Stellen beim Vereinzeln einfach kleine Kerben hineingefräst. > Klar, wenn man wirklich will dann gibt es fuer alles eine Loesung. Aber > in der Industrie ist das nicht immer so einfach wie auf dem Basteltisch > zuhause. Ganz genau so ist es. Du solltest eben nicht Deinen eigenen Basteltisch als Referenz nehmen. Einige Prüfsysteme, an denen ich mitentwickelt habe und die im Großserienbetrieb eingesetzt werden, kontaktieren exakt so wie von mir beschrieben ihre Fertigungsnutzen, und zwar weil es der Kunde so haben will und es ausgezeichnet funktioniert.
Tim . schrieb: > Es ist irrelevant, darüber zu spekulieren. > > Fakt ist: RISC-V wird sich über chinesische Firmen mit unerwarteter > Geschwindigkeit ausbreiten. > > Niemand in China will Lizenzgebühren an ARM entrichten. Gleichzeitig ist > das Fehlen von Toolchains ein Hauptproblem von alternativen ISAs. > > Was glaubt ihr wohl, was die ganzen Startups mit den Mrd an > Regierungssubventionen machen werden? https://www.reuters.com/technology/us-china-tech-war-risc-v-chip-technology-emerges-new-battleground-2023-10-06/ Selten war es so einfach, die Folgen eines Technologietrends so eindeutig vorherzusehen. Die "some lawmakers" scheinen wirklich "unter einem Felsen zu leben".
:
Bearbeitet durch User
> Selten war es so einfach, die Folgen eines Technologietrends so > eindeutig vorherzusehen. Ja, der Umbruch wird gewaltig sein. :-D Mich wundert das aehnliches nicht auch mit Linux passiert. Waere ich China oder ein anderes Land das sich nicht dem grossen amerikanischen Bruder unterordnen will, dann wuerde ich dafuer sorgen das weitestgehend nur noch Linux genutzt wird. Genauso wie bei Risc-V gibt es irgendwann den Moment wo alles kippt und ARM praktisch ueber nach verschwinden wird. Und der Druck gegen ARM ist gewaltig und das eben nicht nur von China sondern eigentlich von jedem dicken Halbleiterhersteller der frueher eigene Cores hatte und irgendwann vom Markt gezwungen wurde auf ARM umzusteigen. Man schaue sich nur an wie der gesamte Markt vom ESP8266 aufgerollt wurde obwohl der so einen doedeligen unbekannten Core hat. Allein nur wegen billig! Das kann Risc-V genauso, bringt aber noch das Oekosystem mit. Gibt es eigentlich von ST schon was mit Risc-V? Und wenn nein wie lange noch? :-) Vanye
Vanye R. schrieb: > Mich wundert das aehnliches nicht auch mit Linux passiert. Läuft längst, mehrere Anläufe, zurück bis Red Flag Linux 1999. Es wird jedoch nicht in der Bevölkerung erzwungen. Regierungsstellen und Staatskonzerne sollen nun aber endlich abschwören. https://www.neowin.net/news/chinese-government-to-dump-windows-in-favor-of-linux/
:
Bearbeitet durch User
Vanye R. schrieb: > der so einen doedeligen unbekannten Core hat. Allein nur wegen billig! Welches westliches Konkurrenzprodukt gab es denn, vor allem eines mit brauchbarem Support und Toolchains die man ohne NDA bekommt?
Vanye R. schrieb: > Mich wundert das aehnliches nicht auch mit Linux passiert. > Waere ich China oder ein anderes Land das sich nicht dem grossen > amerikanischen Bruder unterordnen will, dann wuerde ich dafuer sorgen > das weitestgehend nur noch Linux genutzt wird. Einige der amerikanischen (und auch deutschen) Firmen agieren halt geschickter, um nicht im Fadenkreuz der chinesischen Regierung zu landen. Microsoft, Apple, Tesla sind hier prominente Beispiele. Microsoft erlaubt ja schon seit Jahren die praktische kostenlose Nutzung von Windows für Heimanwender. Und mich würde es nicht wundern, wenn sie in China "vergessen" kommerzielle Nutzer ohne Lizenz zu verfolgen. Wird Office365 auch in China vermarktet? Das ist sicherlich ein schwierigeres Produkt...
:
Bearbeitet durch User
> Welches westliches Konkurrenzprodukt gab es denn, vor allem eines mit > brauchbarem Support und Toolchains die man ohne NDA bekommt? Warum solltest du eines "bekommen" wollen? Bedenke, bevor sich ARM so erstaunlich verbreitet hatte, da hatte jeder Hersteller seine eigenen Cores (AVR, ST6/7, 68k, Z80, 6502, PIC, SH, M16C, MCS48/51, usw) Lizensieren muss man nur wenn man faul ist oder vielleicht ein paar Tausend Stueck braucht. Vanye
Vanye R. schrieb: >> Welches westliches Konkurrenzprodukt gab es denn, vor allem > eines mit >> brauchbarem Support und Toolchains die man ohne NDA bekommt? > > Warum solltest du eines "bekommen" wollen? Bedenke, bevor sich ARM so > erstaunlich verbreitet hatte, da hatte jeder Hersteller seine eigenen > Cores (AVR, ST6/7, 68k, Z80, 6502, PIC, SH, M16C, MCS48/51, usw) > Lizensieren muss man nur wenn man faul ist oder vielleicht ein paar > Tausend Stueck braucht. Ich meinte den ESP32/ESP8266. War ungünstig zitiert, sorry.
> Microsoft erlaubt ja schon seit Jahren die praktische kostenlose Nutzung > von Windows für Heimanwender. Wuerdest du ein chinesisches Betriebssystem nutzen? Als Behoerde? Bei der Bundeswehr? Hast du jetzt privat vertrauen in Microsoft das die dich nicht aushorchen? .-) Man kann also schon annehmen das China sich berechtigte Sorgen bezueglich des Einsatz von Mikrosoftsystemen machen darf. Wenn aber dann mal Linux das allgemeine STandardsystem in China sein sollte. Etwas das jeder benutzt/kennt und mit dem er jederzeit auch als Microsoftnutzer Daten und Anwendungen austauschen muss. Dann wird sich irgendwann der Rest der WElt auch fragen: Haeh? Wieso eigentlich noch Windows? China ist gross genug da eine kritische Masse aufzubauen. Vanye
Vanye R. schrieb: > Wuerdest du ein chinesisches Betriebssystem nutzen? Als Behoerde? Bei > der Bundeswehr? Ob die Bundeswehr wohl Huawei oder andere Chinesen einsetzt? Und sei es bloß in privaten aber überall mitgeschleppten Smartphones quer durch die Ränge.
:
Bearbeitet durch User
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.