Announcement: there is an English version of this forum on 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.