Guten Morgen, Immer noch auf der Suche nach einem STM32-Ersatz... Warum liest man hier so wenig von Renesas? * As of 2022, it is the world's third-largest automotive semiconductor company and the largest microcontroller supplier. * Renesas produziert in 12 eigenen Fabs, davon nur 2 in China (laut Wikipedia und OpenStreetMap). * 5V-Chips sind lieferbar -- mit 1MB Flash und 128KB RAM für 10 Euro * insgesamt listet Digikey ca. 3900 Renesas- und 3600 STM-Typen. * das Verhältnis von sofort-lieferbar zu theoretisch-lieferbar war heute bei Digikey 12/37 und bei Mouser 16/40 (Typen, die für meine Anwendung passen). Garnicht schlecht für die heutige Zeit. * die beiden interessantesten davon sollen bis 2035 lieferbar sein * das Preis/Leistungsverhältnis scheint mir sehr gut zu sein * SPI und UART mit FIFOs * UART-, USB- und evt. SD-Card-Bootloader * 32-Bit FPU und der gcc benutzt per Default 32-Bit double Wo ist der Fehler? https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rx-32-bit-performance-efficiency-mcus#featured_products https://gcc.gnu.org/onlinedocs/gcc/RX-Options.html
:
Bearbeitet durch User
> Warum liest man hier so wenig von Renesas? Weil sich Renesas in Deutschland nie so recht bei Bastlern durchsetzen konnte weil die nur DIL haben wollen weil es den einen oder anderen sonst schon ueberfordert. Ausserdem werden auch manche von der Funktionalitaet ueberfordert gewesen sein. Das was ein Renesas M16C von 2000 als Peripherie drin hatte ist so etwa auf dem Level den man heute bei einem STM32 fuer normal haelt und da haben ja auch noch viele Angst vor und programmieren weiter ihren Mega8. Und irgendwann war es in den Koepfen halt so drin. In Japan ist das natuerlich anders. Da findest du auch eine Menge Bastelkram mit Renesas im Elektronikgeschaeft. Vanye
Vanye R. schrieb: > und programmieren weiter ihren Mega8. Wohl auch, weil der schon soviel kann, dass 90% der Bastleraufgaben damit zu erledigen sind.
Vielleicht weil die früher u.a. noch Hitachi hießen? https://de.wikipedia.org/wiki/Renesas_Electronics Renesas Electronics ist der Zusammenschluss der ausgegliederten Halbleiterbereiche von Hitachi, Mitsubishi Electric und NEC. (2003/2004), September 2016 Übernahme von Intersil usw.
Bauform B. schrieb: > Warum liest man hier so wenig von Renesas? Zumindest in der Vergangenheit war es sauschwer, zu deren Chips Datenblätter und andere Informationnen in englisch zu erhalten. Ob es sich inzwischen gebessert hat, weiß ich nicht. Ich habs aufgegeben. Der Erfolg der Atmel AVRs begründet sich großteils auch darin, daß die Datenblätter recht gut zu lesen waren (nicht über haufenweise PDFs verteilt) und sogar die Programmieralgorithmen offen gelegt waren.
Ich sehe die häufig in Weißer ware und Automotive-anwendungen. Für mich fehlte immer ein einfach zugänmglicher Programmer wie der ST-Link /NU-Link, eine gut verfügbare toolchain und eine gewisse community zum austausch. Warum unterstützt Platformio jegliche exotische 8051, jedoch keinen von Renesas?
Bauform B. schrieb: > Warum liest man hier so wenig von Renesas? Weil die nicht bastlerfreundlich sind, obwohl einfach über die serielle uploadbar wie MC68HC11. Es gab mal den Vorstoss mit dem R8C/13 gratis bei Elektor. Kaum haben sich Bastler mit ihm beschäftigt - und erfreut entdeckt, dass darin ein abgespeckter 68000 als uC steckt - hat Renesas dessen Produktion eingestellt und keinen kompatiblen Nachfolger gehabt. Wer sich länger mit den Dingern beschäftigte merkte, dass die Ausgänge nur 2mA vertrugen und für alles Treiber brauchten, und die grösseren M16 mit ihren Ports sehr unflexibel sind, Richtung nur portweise einstellbar oder ähnlichen Blödsinn. Da halfen auch keine komplizierten Timer für BLDC Ansteuerung mehr. Ja, mit mehr Support und Beispielcode, so wie es Microchip und Atmel machten, wäre er sicher erfolgreicher geworden, wenn aber ein Hersteller nur Millionenstückzahlen interessieren, bekommt er halt keine neue Kundschaft.
Peter D. schrieb: > Zumindest in der Vergangenheit war es sauschwer, zu deren Chips > Datenblätter und andere Informationnen in englisch zu erhalten. Das stimmt doch garnicht. Mitte der 90er hatte ich H8/3003 eingesetzt. Schöne Teile, einfacher Umstieg vom 68k war kein Problem. Dann kamen die H8S, die H8SX und schließlich die RX. Allesamt Edelprozessoren mit schöner interner Struktur. Die Datenblätter waren umfangreich und sehr gut! Aber es wurde immer schwieriger die Teile zu beschaffen. STM32 gab es an jeder Ecke, ST-Link war super günstig und die liefen schneller als die RX-Teile.
Es gab eine Zeit (mag so 20J her sein), da bestand die mir zugängliche Doku zu japanischer Elektronik aus großen PDF-Dateien, bestehend aus einigen schlecht eingescannten Papiervorlagen, während westliche Hersteller brauchbare, ausführliche PDF-Dokus bereitstellen konnten. Vor 10J hatte ich ein Projekt mit einem Renesas 16Bit-uC und kann sagen, dass ich mit dem Teil rundrum zufrieden war. Klasse umfangreiche PDF-Dokus, gute Programmier/Debug-Tools, komplexe Peripherie (das meine ich positiv, dagegen sind die von mir eigentlich bevorzugten HCS08/HCS12 peripheriemäßig nahezu auf Steinzeitniveau stehen geblieben). Kann sein, dass ich zukünftig für komplexere Sachen zu Kinetis (M0+/M4/M7) umschwenke. Die Peripheiemodule sind dort deutlich weiterentwickelt worden. Oder vielleicht nochmal bei Renesas vorbeischauen...?
Mi N. schrieb: > Das stimmt doch garnicht. Natürlich sind nicht generell alle ICs von Renesas gemeint. Ich hatte mal nach den ICs in meinem Onkyo Receiver gesucht und bin nicht fündig geworden, wenn da Renesas drauf stand.
Vanye R. schrieb: > Weil sich Renesas in Deutschland nie so recht bei Bastlern > durchsetzen konnte weil die nur DIL haben wollen weil es > den einen oder anderen sonst schon ueberfordert. Demnach dürfte man hier auch nichts über STM32 lesen. Davon gibt es nämlich auch nicht sooo viele Typen im DIL-Gehäuse. > Ausserdem werden auch manche von der Funktionalitaet ueberfordert > gewesen sein. Das was ein Renesas M16C von 2000 als Peripherie > drin hatte ist so etwa auf dem Level den man heute bei einem STM32 > fuer normal haelt und da haben ja auch noch viele Angst vor > und programmieren weiter ihren Mega8. Damals(tm) setzten wir einige M16C und M32C in Telefonanlagen und Routern ein. Deren Codedichte war deutlich höher als bei klassischen ARM-basierten Prozessoren im 32 Bit-Modus und auch im Thumb-Modus. Ein großer Nachteil bestand darin, dass es zu der damaligen Zeit keinen preisgünstigen Debugger gab, sondern nur "echte" In-Circuit-Emulatoren mit Bondout-Chip. Das wäre für Hobbyisten völlig unerschwinglich geworden. Für ARM gab es damals schon JTAG-Debugger für "nur" wenige hundert DM.
Mi N. schrieb: > Das stimmt doch garnicht. Mitte der 90er hatte ich H8/3003 eingesetzt. > Schöne Teile, einfacher Umstieg vom 68k war kein Problem. > Dann kamen die H8S, die H8SX und schließlich die RX. Allesamt > Edelprozessoren mit schöner interner Struktur. Die Datenblätter waren > umfangreich und sehr gut! Die Hitachi H8 basierten ursprünglich auf der DEC PDP-11-Architektur. H8/300H usw. wurden auch an Dritthersteller lizensiert und lebten dort auch noch einige Zeit weiter, ohne dass dies sofort ersichtlich war. In den GSM-Basebandprozessoren von Analog Devices befanden sich solche Kerne. Die Nachfolger der auch weiterhin gepflegten SuperH-Familie haben einen neuen RISC-artigen Kern. Ich weiß aber nicht, ob Hitachi/Renesas damals die Peripherie oder andere Teile von den H8 übernommen hat. Besonders interessant ist deren ausgesprochen hohe Floating-Point-Rechenleistung. Wir hatten mal vor langer Zeit (um 2008 herum) ein Kundenprojekt, bei dem es darum ging, einen Fehler in der Firmware für einen SH-2 zu finden. Es stellte sich heraus, dass der GCC damals fehlerhaften Code generierte. Wenn ich mich recht erinnere, wurden bei Funktionsaufrufen manchmal die Floating-Point-Register nicht korrekt gesichert bzw. wiederhergestellt. Immerhin konnten wir genau identifizieren, wann der Fehler auftrat, und unserem Kunden Workarounds beschreiben.
Vanye R. schrieb: > Weil sich Renesas in Deutschland nie so recht bei Bastlern > durchsetzen konnte weil die nur DIL haben wollen weil es > den einen oder anderen sonst schon ueberfordert. Vielleicht steckt aber auch ein viel profanerer Grund dahinter: Die schlechte Verfügbarkeit von Entwicklungssystemen (Compiler & Debugger). AVRs haben schon vor der Arduino-Welle durch ihre Programmierbarkeit mit einfachen Parallelportadaptern Anklang bei Bastlern finden können; einige MSC-51-Varianten von Atmel aus den gleihen Gründen ebenso. Bevor es den gcc für AVR gab, nutzte man entweder so etwas wie Bascom oder eine "besorgte" Version von IAR ... Bei PICs sah es ähnlich aus. Irgendwann erkannten die µC-Hersteller, daß es nicht reicht, µCs zu produzieren, sondern daß auch Unterstützung für Entwicker nötig ist. Da gab es dann codegrößenbeschränkte kostenlose Compiler (wie z.B. die "Kickstarter"-Varianten von IAR) und nach und nach auch insgesamt kostenlose Compiler und Entwicklungsumgebungen (wie CodeComposer von TI oder Atmel/Microchip Studio). Dann haben sich auch die Preise für Programmiergeräte und Debuginterfaces sehr deutlich nach unten bewegt; war früher ein sauteurer In-Circuit-Emulator nötig, konnte durch JTAG die Angelegenheit deutlich einfacher werden, und durch Offenlegung der Protokolle bzw. Schaltungen konnten halt auch Bastler etwas damit anfangen. Für ARMe gab es vor den FT2232-basierenden OpenOCD-Adaptern mit dem "Wiggler" eine leicht nachbaubare Variante für den Frickelport (die in leichter Abwandlung auch für MSP430 verwendbar war). TI hat eine Zeitlang JTAG-Debug-Hardware in Form des "Launchpads" praktisch verschenkt (auch wenn das nur die Zweidraht-Variante namens SBW war, die Hardware entsprach bis auf ein paar Bustreiber dem deutlich teureren USB-JTAG-Interface). Und jetzt ist die klare Erwartungshaltung, daß Programmier- und Debuginterfaces kostengünstig sind, daß Entwicklungsumgebungen kostenfrei verfügbar sind und daß es gute und umfangreiche Dokumentation gibt. Vielleicht hab' ich das ja nur nicht mitbekommen, aber von Renesas habe ich in der Richtung nichts großartig gehört.
Harald K. schrieb: > Vielleicht steckt aber auch ein viel profanerer Grund dahinter: Die > schlechte Verfügbarkeit von Entwicklungssystemen (Compiler & Debugger). Sind doch Cortexe. Sowas läuft in unter 1h mit einer unveränderten Eclipse und GCC. BTDT. Ja, libs sind ein Thema, aber beherrschbar. Es hofft nur jeder, dass niemand zu seinem gerade verfügbaren Controller wechselt und der dann auf einmal nicht mehr verfügbar ist. Ich kann mich noch gut an die spöttischen AVR Leute hier erinnern die gemeint haben, ihr Zeug wäre immer und überall verfügbar... Ist halt leider nicht so. Sobald die kritische Masse portiert hat, sind die Lager leer. Es wird immer besser, aber noch sind die engpässe nicht ganz abgebaut. 73
Mir wurde mal gesagt, dass die Renesas-Chips eher spezialisiert sind. Automotive nach Kundenanforderung. Und weniger allgemeine Peripherie für den Consumer-Markt. Es wäre interessant zu wissen, ob hier Entwickler unterwegs sind, die auch privat Renesas einsetzen?
Ich kenne nur aus Fertigungssicht zwei SH4-MCUs. Der umständliche dreistufige Bootloader über die serielle Schnittstelle. Erst muss mit dem internen Bootloader eine Datei reingeladen werden, die kann dann das interne Flash programmieren, und schließlich noch das Flashen eines zusätzlichen externen Speichers. Wenn es nicht klappt, gibt es eine nichtssagende Fehlermeldung. Meistens war es nur der falsche COM-Port. Die MCUs haben zwar eine JTAG-Schnittstelle, aber die boundary scan Funktion besteht nur darin, die Daten durchzuwinken. Zum Debuggen gibt es nur eine Hitachi-eigene Schnittstelle (die beim Platinenlayout nicht berücksichtigt wurde, kann also auch nicht genutzt werden).
Bauform B. schrieb: > Warum liest man hier so wenig von Renesas? > Wo ist der Fehler? µC.net hat sich halt zu einem Laienmurkser-Forum entwickelt. Beruflich hatte ich bereits vor Jahrzehnten mit Renesas-Controllern (SH4) zu tun. Kann sein das die wiedermal anders heissen, war schon damals besser als NEC, Hitachi oder Misubishi oder einfach "Japan" bekannt. https://en.wikipedia.org/wiki/SuperH Das gibt es schon seit den Neunzigern, also spricht das auch nicht für Dich, das du das erst jetzt "gefunden" hast.
Bauform B. schrieb: > As of 2022, it is the world's third-largest automotive semiconductor > company and the largest microcontroller supplier. Alle Firmen sind die größten - in ihrer eigenen Werbung. Worin genau sie die größten sind, das bleibt bewusst offen. Haben sie das größte Gebäude, den größten Wasserkopf, die größten Bauteile (in Millimetern gemessen),...? Solche Sätze haben überhaupt keine Aussagekraft, außer: Es waren Angeber am Werk.
Steve van de Grens schrieb: > Bauform B. schrieb: >> As of 2022, it is the world's third-largest automotive semiconductor >> company and the largest microcontroller supplier. > gemessen),...? Solche Sätze haben überhaupt keine Aussagekraft, außer: > Es waren Angeber am Werk. Oder der Leser ist ein Ignorant mit sehr beschränkter Einsicht in globale Märkte. Im Bereich der "Global Player" sind japanische Halbleiter seit Jahrzehnten bekannt. Naja, für manchen ist das halt "Neuland", was man sich aber nicht eingestehn will. Ebenso bei koreanischen Quellen wie SK Hynix und samsung (als Halbleiterhersteller) https://de.wikipedia.org/wiki/SK_Hynix
Christoph db1uq K. schrieb: > Renesas Electronics ist der Zusammenschluss der ausgegliederten > Halbleiterbereiche von Hitachi, Mitsubishi Electric und NEC. DSGV-Violator schrieb: > Beruflich hatte ich bereits vor Jahrzehnten mit Renesas-Controllern > (SH4) zu tun. Kann sein das die wiedermal anders heissen, war schon > damals besser als NEC, Hitachi oder Misubishi Ja, damals war alles besser, sogar besser als das, was damals besser war. Oder wars doch anders herum? Oliver
Ich finde es bemerkenswert wieviel Ahnunglosigkeit und Unkenntnis es hier teilweise zum Thema Renesas gibt. Wissen durch Vorurteile? > Vielleicht weil die früher u.a. noch Hitachi hießen? Du meinst deshalb benutzt heute keiner Mehr Atmel Controller weil der Laden verkauft wurde und einen anderen Namen bekommen hat? :-D > Ich sehe die häufig in Weißer ware und Automotive-anwendungen. Man muss unterscheiden zwischen Bastelzimmer und Beruf. Wer beruflich entwickelt/programmiert wird sehr schnell auf Renesas stossen und damit arbeiten. > Zumindest in der Vergangenheit war es sauschwer, zu deren Chips > Datenblätter und andere Informationnen in englisch zu erhalten. Also ich war auch schon so 2003/4 in der Lage die einfach im Internet runterzuladen. Allerdings war das Englisch darin zu anfang schon holprig und nicht immer so einfach zu verstehen! Die haben sich dann aber irgendwann EXTREM gebessert. Spaeter war es mir immer eine Freude die zu lesen. > Weil die nicht bastlerfreundlich sind, obwohl einfach über die serielle > uploadbar wie MC68HC11. Bullshit. Die alten Renesascontroller liessen sich sowohl ueber einen dedizierten Debugger (E8) wie auch ueber eine RS232 programmieren, und noch 10x wichtiger debuggen! Davon konnten Atmeluser LANGE nur traeumen. Gerade der KOSTENLOSE Debugger (KD30, spaeter Teil von HEW) von Renesas war fuer mich vor >20Jahren der Grund dem Atmelzeugs den Ruecken zu kehren. Du hast damit gerade auch als Bastler zuhause die Moeglichkeit gehabt professionell zu entwickeln und zu lernen waehrend der kleine AVR-Bastler glaubte das Debuggen=printf sei. > Es gab mal den Vorstoss mit dem R8C/13 gratis bei Elektor. Ich hab das damals sozusagen "initiiert". Renesas hat damals in Japan mit der Transistor Gijutsu zusammengearbeitet und denen eine Platine in ihrem Elektronikheft gesponsert. Ich hab angeregt das dies auch in Deutschland moeglich sein muesste und dann hat Elektor das hier auch gemacht. War wohl eines der best verkauften Elektorhefte aller Zeiten weil wenn der deutsche Geizling auf eines abfaehrt dann darauf etwas umsonst zu bekommen. :) > sich Bastler mit ihm beschäftigt - und erfreut entdeckt, dass darin ein > abgespeckter 68000 als uC steckt - Also da ist ganz gewiss kein 68000 drin. Der R8C/M16C waren einfach eine eigene CPU. Allerdings eine CPU mit bis zu 128k flash und 20k Ram. Das war als bei uns in Deutschland mit Mega8 mit 1-2k Ram umgefummelt wurde. Das hat mir bereits Mitte der 2000er ermoeglicht mit Grafik-LCDs rumzufummeln als der Durchschnittbastler bei uns den 2x16Zeichen Hitachi fuer das Mass der Dinge hielt. .-) > hat Renesas dessen Produktion > eingestellt und keinen kompatiblen Nachfolger gehabt. Gerade Renesas ist dafuer bekannt EXTREM lange CPUs zu unterstuetzen. Du kannst selbst heute noch kompatible M16C Derivate kaufen obwohl ich die wahrlich nicht mehr fuer Neuentwicklungen einsetzen wuerde. > und die grösseren M16 mit ihren Ports sehr unflexibel sind, Richtung > nur portweise einstellbar oder ähnlichen Blödsinn. Schon wieder bullshit. Die hatten ein ganz normale Direktion-Register wo du fuer jedes IO die Richtung einzeln einstellen konntest. Lediglich Pull-Up war in Gruppen von 4Bits. Hatten die AVRs damals ueberhaubt schon PullUps? > Vielleicht steckt aber auch ein viel profanerer Grund dahinter: Die > schlechte Verfügbarkeit von Entwicklungssystemen (Compiler & Debugger). Nein. Es gab von Renesas damals bereits HEW mit dem KD30. Der kostete fuer Firmen so in der Gegend von 2000DM. Fuer Bastler war der umsonst, aber auf eine maximale Codegroesse von 64kb beschraenkt. Das zu einer Zeit als kein Bastler zushause einen Controller mit 64k Flash hatte! Zu der Zeit war die Entwicklungsumgebung von Atmel einfach peinlich im Vergleich zu HEW und gerade der KD30 war einen Offenbarung. Das war fuer mich DER Grund privat auf Renesas umzusteigen. Spaeter gab es dann auch den GCC falls man sich an der Codegroesse gestoert hat. Allerdings war der Renesascompiler effizienter als GCC. (etwa doppelte Ausfuehrunggeschwindigkeit) Und Leute das war vor Eclipse! Und HEW ist einer der Gruende warum mich Eclipse heute noch ankotzt. Das war naemlich richtig schnell, hatte sicher hier und da auch ein paar kleine Macken, aber klein Vergleich zu der absurden kroetenlahmen Zauberbude von Eclipse wo keiner so genau weiss wo welcher Click zu betaetigen ist. > Es wäre interessant zu wissen, ob hier Entwickler unterwegs sind, die > auch privat Renesas einsetzen? Ich. :-) Allerdings muss ich zugeben das ich in den letzten Jahren auch verstaerkt ARM einsetze. Das hat aber andere Gruende. .-) Das Problem was Renesas damals (fuer Bastler!) hatte, die MCUs hatten sehr viel Peripherie und man musste dicke Datenblaetter lesen! Ja richtig LESEN! Und verstehen! Heute sind die meisten Bastler dafuer zu doof und nutzen fertigaufbereiten Code wie STM32Cube oder gleich Arduino. (ausspuck) Das hat damals viele ueberfordert. Die haben sowas wie Bascom genutzt. :) Vanye
> Im Bereich der "Global Player" sind japanische Halbleiter seit > Jahrzehnten bekannt. Naja, für manchen ist das halt "Neuland", was man > sich aber nicht eingestehn will. Man muss in solchen Diskussionen immer Bastler und Profi auseinanderhalten. Das sind einfach zwei Welten die teilweise Beruehrungspunkte haben, aber sich sonst stark unterscheiden! Vanye
DSGV-Violator schrieb: > Oder der Leser ist ein Ignorant mit sehr beschränkter Einsicht in > globale Märkte. Im Bereich der "Global Player" sind japanische > Halbleiter seit Jahrzehnten bekannt. Ich habe ja auch nicht behauptet, dass Renesas "klein" sei.
Harald K. schrieb: > Vanye R. schrieb: >> Weil sich Renesas in Deutschland nie so recht bei Bastlern >> durchsetzen konnte weil die nur DIL haben wollen weil es >> den einen oder anderen sonst schon ueberfordert. > > Vielleicht steckt aber auch ein viel profanerer Grund dahinter: Die > schlechte Verfügbarkeit von Entwicklungssystemen (Compiler & Debugger). Dafür gab es auch mini-Debugger für RX von Segger oder die Hausmarken E8, E10 und richtig Hochpreisiges. HEW hatte mir sehr gut gefallen. Dort konnte man die Compiler von KPIT einbinden. Die SH hatte ich ganz vergessen. Wenn ich mich recht erinnere, war der SH7216 einer der ersten Controller mit double-precision Hardware auf dem Chip. Ab SH2A gab es für Interruptverarbeitung zu jeder der 16 Prioritätsebenen ein Satz Schattenregister. Da mußte nichts "gepusht" werden. Bei einem 80 MHz SH7211 betrugt die ISR-Reaktionszeit ca. 60 ns. Seinerzeit ein schneller Wert. Heute rechnet auch ein Cortex-M7 mit double-Werten in Hardware und mit seinen 550 MHz "pusht" er die paar Register auch noch schneller. Wenn man die Eigenschaften/Probleme aus heutiger Sicht betrachtet, muß man auch sehen, wann das so war. Was heute mit Renesas und ihrer ursprünglichen Hitachi-Linie angesagt ist, verfolge ich nur noch am Rande. Es werden jetzt auch ARM-Kerne verwendet. Mit Linien von NEC oder Mitsubishi (M32 z.B.) hatte ich nur am Rande zu tun.
Vanye R. schrieb: > ... obwohl ich die wahrlich nicht mehr fuer Neuentwicklungen einsetzen wuerde. Und Deine (renesas-spezifische) Empfehlung bei Neuentwicklungen wäre was?
Michael B. schrieb: > Es gab mal den Vorstoss mit dem R8C/13 gratis bei Elektor. Kaum haben > sich Bastler mit ihm beschäftigt - und erfreut entdeckt, dass darin ein > abgespeckter 68000 als uC steckt - hat Renesas dessen Produktion > eingestellt und keinen kompatiblen Nachfolger gehabt. Das war gerade die Zeit, als NEC und Renesas fusioniert sind. Aus R8C und 78K wurde der RL78 und aus dem V850 der RH850. Beide Produktlinien sind seitdem bestens etabliert. Allerdings nicht unbedingt in Bastlerkreisen. Die alten Typen gibt es durchaus noch, aber nicht für Neupojekte. Entsprechend werden sie auch nicht mehr beworben. Es gibt kostenlose GNU-basierte Tools: https://llvm-gcc-renesas.com/#
Mehmet K. schrieb: > Und Deine (renesas-spezifische) Empfehlung bei Neuentwicklungen wäre > was? RL78 mit E20 debugger und KPIT GNU Toolchain. Link siehe oben.
Vanye R. schrieb: >> Weil die nicht bastlerfreundlich sind, obwohl einfach über die serielle >> uploadbar wie MC68HC11. > > Bullshit. Die alten Renesascontroller liessen sich sowohl ueber einen > dedizierten Debugger (E8) wie auch ueber eine RS232 programmieren, und > noch 10x wichtiger debuggen! . Oje, deine Verständnisfähigkeit geht gegen 0. Ich habe die einfache Uploadfähigkeit als positiv herausgestellt (den teuren Debugger hat eher kein Bastler, daher nicht erwähnt). Vanye R. schrieb: >> hat Renesas dessen Produktion >> eingestellt und keinen kompatiblen Nachfolger gehabt. > > Gerade Renesas ist dafuer bekannt EXTREM lange CPUs zu unterstuetzen Du ignorierst Fakten (hier über den R8) zu Gunsten von Marketinggeschwafel. Vanye R. schrieb: > Schon wieder bullshit. Die hatten ein ganz normale Direktion-Register > wo du fuer jedes IO die Richtung einzeln einstellen konntest. Nicht jeder Port. > Lediglich Pull-Up war in Gruppen von 4Bits. Das war bestimmt kein Nachteil, wenn man wie du Fanboy ist. > Hatten die AVRs damals > ueberhaubt schon PullUps? Natürlich. Du kennst dich offensichtlich nicht aus. Vanye R. schrieb: > Zu der Zeit war die Entwicklungsumgebung von Atmel einfach peinlich im > Vergleich zu HEW Na ja, HEW war ein extrem langsames Visual Studio und Atmel hatte ein langsames Visual Studio. Aber woher sollst du das wissen...
> HEW hatte mir sehr gut gefallen. Dort konnte man die Compiler von > KPIT einbinden. Mir auch. Der Weggang von HEW war ein Verlust. Das Zeug fluppte einfach. Der GCC von Kpit kam allerdings spaeter. Zu Anfang ging nur der Renesascompiler. Aber man darf nicht vergessen, die Alternative fuer Bastler war damals die Kommandozeile und kein Debugger! > Die SH hatte ich ganz vergessen. Ja, die waren auch cool. Teilweise hat man denen zwar angemerkt das sie alte Wurzeln hatten, aber auch andererseits sehr ausgereift und innovativ. > Ab SH2A gab es für Interruptverarbeitung zu jeder der 16 > Prioritätsebenen ein Satz Schattenregister. Richtig. Wenn ich dagegen dieses kranke Gehampel mit push/pop bei anderen MCUs sehe muss man kotzen. Wieso eigentlich? Selbst der Z80 hatte schon zwei Registerbaenke. Man sollte doch meinen das sowas auch bei ARM moeglich sein sollte. Oder einstellbare Interruptsprioritaeten. Den meisten Bastlern ist gar nicht klar das es sowas gibt und warum das wichtig ist. Kennen sie ja von AVR nicht und man muesste sich dann ja auch um seinen Code mehr Gedanken machen als es das reinkopieren von Libaries aus dem Internet erlaubt. > Bei einem 80 MHz SH7211 betrugt die ISR-Reaktionszeit ca. 60 ns. > Seinerzeit ein schneller Wert. Ich meine die SHs waren auch in irgendeiner Spielkonsole. > Wenn man die Eigenschaften/Probleme aus heutiger Sicht betrachtet, muß > man auch sehen, wann das so war. Richtig. Das darf man nicht vergessen. Und manches wird auch einfach aus Zufall so passiert sein. Wobei es fuer Deutschland schon sehr absurd ist das gerade der groesste MCU Hersteller kaum bekannt ist. Oder ein anderes schoenes Beispiel, warum war im Gameboy ausgerechnet ein Z80 Derivat drin? Die Antwort nach meiner Einschaetzung, die meisten japanischen Entwickler damals kannten den Z80 bestens weil der in den MSX-Consolen drin war und die waren da SEHR viel verbreiteter wie bei uns weil die mit japanischen Zeichen umgehen konnten. Deshalb entwickelt sich manches Laenderspezifisch ohne das dies von ausserhalb immer so nachvollziehbar war. Ich glaube z.B auch das es dem MCS51 fuer die deutschen Bastler damals sehr geholfen hat das viel Doku/Datenblaetter auch in Deutsch verfuegbar war. Vanye
Vor ein paar Jahren war die Integration noch nicht soweit. Man brauhte für die NEC-Abkömmlinge andere Infrastruktur als für Hitachi/Mitsubishi. Das war nervig wenn du ein Projekt mit dem RL78 und eines mit dem R8 hattest.
Michael X. schrieb: > Vor ein paar Jahren war die Integration noch nicht soweit. Nicht nur dort. Ich habe hier noch einen klumpigen SAM-ICE für AT91SAM7xxx. Bei dem AT91 gab es nur eine Interruptebene. Kein Vergleich zu den genannten Hitachi/Renesas-Teilen. Erst SWD hat das Debugging deutlich vereinfacht.
Soul E. schrieb: > Mehmet K. schrieb: >> Und Deine (renesas-spezifische) Empfehlung bei Neuentwicklungen wäre >> was? > RL78 mit E20 debugger und KPIT GNU Toolchain. Link siehe oben. Gibt es auch eine Empfehlung mit 32 Bit?
Bauform B. schrieb: > Gibt es auch eine Empfehlung mit 32 Bit? Da kenne ich aus eigener Erfahrung nur den RH850. Den würde ich aber für private Nutzung nicht empfehlen, da 70% der Doku nur per NDA verfügbar ist.
Die Diskussion hat sich verlagert. Die alte Garde, die über Befehlssätze, und Länge der FIFO diskutierten stirbst so langsam aus. Die heutige Generation diskutiert über MicroPython oder Arduino. DIL oder QFN interessiert auch nicht mehr. Heutzutage streiten sich die Bastler: chinesischer oder deutscher Leiterplatten-Fertiger. Altium oder Kicad?
> DIL oder QFN interessiert auch nicht mehr. Stimmt. Heute pappen die Chinesen QFN oder BGA auf Adapterboard mit 1mm castellated Holes fuer die heimischen Bastler und fuer die Deutschen gibt es dann einen Zwischenhaendler der das chinesische Board auf ein fetteres Adapterboard mit DIL loetet. Das nimmt einer und pappt das auf seine Monsterplatine und nennt sich Maker. :-D > Bastler: chinesischer oder deutscher Leiterplatten-Fertiger. Echt? Welcher Bastler kann sich denn einen deutschen Leiterplattenfertiger leisten? Vanye
Xanthippos schrieb: > Altium oder Kicad? Welcher Bastler kann sich denn Altium leisten? :-D Website sagt: »Schon ab EUR 370 pro Monat« ... Die Bastler-Lager spalten sich wohl eher in EAGLE und KiCad.
Bauform B. schrieb: > Gibt es auch eine Empfehlung mit 32 Bit? Was willst Du eigentlich machen? Für den "kleinen" Bedarf nehme ich den RP2040 als Pico-Board schön verpackt: Begrenzte GPIOs, dafür aber schnell, lieferbar und günstig. Als Asse habe ich aber auch noch STM32F7xx und STM32H7xx im Ärmel ;-)
Mi N. schrieb: > Bauform B. schrieb: >> Gibt es auch eine Empfehlung mit 32 Bit? > Was willst Du eigentlich machen? Für STM32F051, F205, L031, L412, L496 eine Alternative finden, falls die nicht mehr an jeden verkauft werden. ARM will evt. für jedes verkaufte Gerät mit ARM-CPU Lizenzgebühren kassieren. Damit kommen RP2040, ATSAM, EFM32, Kinetis, PIC32C, Renesas RA auch nicht in Frage. Nach AT32, PIC32M und PowerPC schaue ich mir jetzt die Renesas RX an und bis jetzt gefallen mir die fast zu gut, aber auf 3000+ Seiten wird sich schon noch etwas finden ;) Auf jeden Fall sind sie viel übersichtlicher als STM32F1 u.ä., auch wegen der besseren Doku. Weil alles in einem Adressraum memory mapped ist, sind sie sogar einfacher als die AVR, also auch für Anfänger geeignet. Es würde direkt Spaß machen, die in Assembler zu programmieren, ganz in Gegensatz zu ARM.
:
Bearbeitet durch User
nochmal zur >Hitachi-eigenen Schnittstelle wir hatten diese SH4-MCU, davor noch eine ältere 5V-Version (7044 oder 45?): https://www.renesas.com/us/en/document/mah/sh7144-group-sh7145-group-hardware-manual?r=1054856 Seite 739 von 932 zum Debugging via JTAG: "Note: This LSI does not support test modes other than the bypass mode" wie gesagt, unbrauchbar. Seite 751: "Advanced User Debugger (AUD)" Eight input/output pins (nicht identisch mit JTAG) Die waren aber im Platinenlayout schon belegt, also kein Debuggen möglich. Wenn man das vorher gelesen hätte, hätte man einen Debugger selbst schreiben müssen oder kaufen. Kurz gegoogled: es gibt was von Lauterbach. Wir hatten schon lange vorher einen Hitachi Mikrocontroller eingesetzt, vielleicht war das der Grund wieder einen dort zu kaufen. HD6301 oder 6303, das war ein sehr früher Mikrocontroller mit Ports, 2 Timern und sogar einem 8-Bit Multiplizierbefehl. Basierend auf der noch älteren Motorola-CPU MC6800 Mitte der 70er, aber CMOS und die Erweiterungen zum Mikrocontroller. Programmspeicher war noch ein externes EPROM, Flash gab es noch nicht.
Christoph db1uq K. schrieb: > aber CMOS und die > Erweiterungen zum Mikrocontroller Die Erweiterung war nicht von Hitachi, die kam noch von Motorola (als 6801/6803). Hitachi hat nur den CMOS-Prozess hinzugefügt. Beim 6809 war das anders, Hitachis 6309 hatte etliche sehr interessante Befehlssatzerweiterungen, die allerdings jahrelang unter Verschluss gehalten wurden (und viel zu spät erst allgemein bekannt wurden). Die µCs gab es auch mit maskenprogrammiertem ROM und als (sündhaft teure) EPROM-Version, die hieß dann 68701/68703 bzw. bei Hitachi 63701/63703: http://datasheets.chipdb.org/Hitachi/63701/HD63701V0.pdf
> Es würde direkt Spaß machen, die in Assembler zu programmieren
Eine gute Antwort auf die ursprüngliche Frage!
Die einzigen, die noch irgend etwas mit Assembler machen sind die
Compilerbauer. Nur die paar Leute, die Arduinolibs oder ähnliches
portieren, schauen noch ins Datenblatt.
Alle anderen diskutieren nicht über Renesas, weil ihnen gar nicht
aufgefallen ist, UNO R3 und R4 haben nur die selbe Stiftleiste.
So genau hatte ich mich mit der Vorgeschichte nicht befasst. Jedenfalls waren Bauteile der Einzelfirmen, die zu Renesas wurden, hier durchaus bekannt. Auch NEC hat eine lange Tradition im Mikrocomputerbereich. https://de.wikipedia.org/wiki/NEC_Corporation Vor allem Intel-8080 Peripheriebauteile wurden dort hergestellt, später auch in CMOS.
Oliver S. schrieb: >> mit Renesas-Controllern >> (SH4) zu tun. Kann sein das die wiedermal anders heissen, war schon >> damals besser als NEC, Hitachi oder Misubishi > > Ja, damals war alles besser, sogar besser als das, was damals besser > war. Oder wars doch anders herum? ??? Extreme ADHS oder warum reicht die Aufmerksamkeitsspanne nicht um den Satz vollständig zu lesen und vollständig zu zitieren?! Da steht nämlich "besser ... bekannt." also "mehr bekannt". Von "Besser sein" war nicht die Rede.
Vanye R. schrieb: > Ich meine die SHs waren auch in irgendeiner Spielkonsole. Sega Dreamcast Und vielen On-Board Navism als das mit den Navis/Car Entertainment losging. Gab auch einen Co-prozessor dazu, für die, die unfähig waren einen PLD als Clue-logic und Grafik-Controller einzusetzen. Der geringe Stronverbrauch war auch von Vorteil weil man sich lärmende Lüfter und aufwendige Kühlung sparte. Selbst Kühlkörper waren selten nötig idel um das ganze in einer schmalen Box unterzubringen. PCI-Controller on board war auch ne feine Sache.
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.