Announcement: there is an English version of this forum on Hallo Forum, gibt es zu den RL78/G14 Renesas Controllern freie Tools oder sind die MC's z.B. bei Mouser deshalb so günstig, weil es nur käufliche Tools dazu gibt? Welche Controller Familien AVR, PIC, STM8/32, MSP430 kommen sonst in Frage, wenn man bei kleinen Stückzahlen (<100) einen 12bit ADC, genügent IOs und SPI braucht und 64k ROM 2k RAM gerne hätte und der MC unter 10 Euro (besser unter 5Euro) kosten soll. Wie sieht es bei NXP und Freescale mit diesen Wünschen aus? Wenn man bei Mouser die Filter entsprechend setzt, kosten alle o.g. MCs meist einen zweistelligen Betrag bei Abnahme von 10++ Stück. Nur bei Renesas sind mir die Preise eher als günstig ins Auge gestochen, deshalb meine Frage hier an dieser Stelle. Habt Ihr eventuell ein paar Vorschläge zu meinen Anforderungen. Der MC soll eigentlich nur Relais schalten (nicht direkt!) und zwei bis acht analoge Werte mit mindestens 10bit Auflösung messen, die im kHz Bereich (<2kHz) liegen. Also eigentlich ganz simple Sachen handhaben. Wäre für sachdienliche Hinweise dankbar. Markus
Beitrag #7305543 wurde von einem Moderator gelöscht.
ATTiny424 (75ct)? AVR32DD20 (1,20)? LPC802M001 (2,03)? Alles Einzelstückpreise und bei den üblichen Verdächtigen Lieferbar. Was ist also Dein Problem? Suche geht nicht?
@OpenWRT die STM8 und den SDCC habe ich schon kennen gelernt, wenn auch es schon einige Jahre her ist. Ich wollte mir für ein neues Projekt (200W KW-Antennentuner mit SWR- und Frequenz-Messung) eine MC aussuchen und auch die zugehörige Toolchain. Bis dato habe ich etwas Erfahrung mit AVR und MSP430 sowie einen Hauch von STM32 sammeln dürfen (nicht unter Eclipse!). Die Atmel und TI Tools waren mir vor Jahren bekannt,habe aber schon eine ganze Weile damit nichts gemacht. Da die Zeit ja nicht stehen bleibt, wollte ich mir wieder etwas aktuelleres zulegen, was auch den Hobby-Anwender preislich nicht überfordert. Habe irgendwo gelesen, das Keil eine freie Version von seinen Tools auch für Linux anbietet, die auch die RL78 Controller bedient. Meist sind aber solche Tools kastriert in der Form, dass man nicht größere Programme > 2k erstellen kann, so war es zumindest in der Vergangenheit. Deswegen meine Anfrage hier, um wieder etwas Orientierung von denen zu erfahren, die damit täglich zu tun haben. Danke für Deine Antwort. Markus
Angehängte Dateien:
-
mouser-mc-sel.jpg
250 KB
@Andreas M. ich habe mich an der Mouser Suche orientiert. Kannst Du bitte was nütyliches zu den LPC802M001 MCs sagen? Wie sieht es da mit der Toolchain aus - frei und unter Linux vorhanden? Markus
Beitrag #7305588 wurde von einem Moderator gelöscht.
Ich verwende bei einem älteren Design einen NXP LPC11U68. (ARM M0) Den gibt es in diversen Pinnings und Speichergrößen. Hat SPI, 12Bit ADC, genug IO... und alles sonst noch übliche. Der kostet < 10Euro und ist bei Mouser erhältlich. Die NXP Toolchain war kostenlos mit dabei, es tut aber auch ein Standard GCC für Arm.
Was mich von den MSP430 z.Z. noch etwas abschreckt ist der Spannungsbereich 1.8 bis 3.6V. Sonst finde ich die durchaus mit den 16bit und den ganzen Addons (z.B. MUL) durchaus ok und es gibt eine OS-Toolchain. Die RL78 sind bis 5V einsetzbar, womit ich mich wohler fühle (z.B. Ansteuerung von FETs). Aber ich lassen mich gerne eines Besseren belehren. Markus
@ PittyJ, danke das ist ja schon mal ein Wink in die Richtige Richtung. Ich wollte mir mal zehn Stück ordern und damit ein paar Test-PCBs layouten und die entsprechend programmieren um zu sehen, was es da für Stolperfallen gibt. Da ist der finanzielle Aufwand überschaubar und es ist was anderes als ein fertiges Dev-Board zu verwenden. Markus
OpenWRT schrieb im Beitrag #7305588: > AVR32 ist praktisch tot Gemeint sind damit die uCs aus der (sehr neuen) AVR Dx Serie, die sogar im DIL-Gehäuse angeboten werden. Ich mag die Teile, haben ein paar nette Features. https://www.mouser.ch/ProductDetail/Microchip-Technology/AVR64DD28-I-SP?qs=tlsG%2FOw5FFihPlDfBDs%252Bgg%3D%3D
:
Bearbeitet durch User
@ PittyJ, Sehe leider, dass bei Mouser nur zwei Typen von Infineon lieferbar sind und die kosten über 30Euro. SAK-XC164CS-32F40F BB-A XC2234L20F66LRAAKXUMA1 Mouser ist mir als Lieferant lieb, da ich da auch geschäftlich unterwegs bin. Markus
Markus W. schrieb: > Habe irgendwo gelesen, das Keil eine freie Version von seinen Tools > auch für Linux anbietet, die auch die RL78 Controller bedient. AFAIK bietet Keil "nur" für STM32 Cortex-M0 eine "freie" (nicht OS!) Version der Tools für Windows an: https://www2.keil.com/stmicroelectronics-stm32/mdk Aber: Was versteht du unter einem SDK? Ich nehme halt unter Ubuntu "sudo apt install gcc-arm-none-eabi" + dazu VS Code. Wenn du eher nach einem GUI-SDK suchst, steht einiges im Wiki: https://www.mikrocontroller.net/articles/ARM_Cortex_Mikrocontroller Speziell für STM32 (und auch Linux) gibt es https://www.openstm32.org
Beitrag #7305651 wurde von einem Moderator gelöscht.
Markus W. schrieb: > Habe irgendwo gelesen, das Keil eine freie Version von seinen Tools > auch für Linux anbietet, die auch die RL78 Controller bedient. Auf diese Seite wirst du wohl selbst schon gestoßen sein: https://llvm-gcc-renesas.com/rl78/rl78-download-toolchains/ Ich vermute mal, dass es sich um CLI Versionen der ToolChain handelt, aber zumindest kann man die Tools ohne Registrierung runter laden. Über die Qualität kann ich leider nichts sagen. Da sie LLVM bzw. GCC basiert sind und supportet werden, können sie so schlecht nicht sein. RL78 ist nun in der Hobby-Szene nicht so verbreitet, die Frage ist halt, ob man dann (5V hin oder her...) wirklich auf dieses Pferd setzen möchte. Professionell ist wieder was anderes. Wenn man ein paar k€ für die ToolChain ausgibt, hat man zumeist auch Support dabei und man kann einen FE vom Distributor nerven. Bei den ARM-Cortex µC, speziell den STM32, findet man halt an jeder Ecke im Internet Hilfe. Und langsam sind grad die STM32 wieder besser erhältlich.
Markus W. schrieb: > Habe irgendwo gelesen, das Keil eine freie Version von seinen Tools > auch für Linux anbietet, die auch die RL78 Controller bedient. Unterstützt Keil (seit es zu ARM gehört) überhaupt noch µCs ohne ARM Kern? Wenn man die Device-List von MDK5 ansieht, stehen da unter Renesas nur noch Cortex-Kerne https://www.keil.com/dd2/
Angehängte Dateien:
-
mouser-mw-order.jpg
130 KB
Danke für den Hinweis auf die RL78 Toolchain auf cli Basis. Habe mir diese runter geladen und werde sie mal installieren. Ich habe mir aber gerade ein paar AVRs und PICs bei Mouser zum Spielen besorgt, für kleines Geld, und werde erst damit loslegen, den zu diesem Thema tummeln sich im MC-Forum wohl mehr Hobbyisten, mit denen man sich austauschen kann. Die RL78 habe ich aber auch noch im Hinterkopf und werde im Web weiter nach Infos dazu suchen. Was mir bei den PICs gefällt ist z.B. die Web-Seite https://microchipdeveloper.com/8bit:peripherals und Ihre Unterseiten wo man sich Infos holen kann. Gibt es wahrscheinlich bei den anderen Herstellern auch, nur habe ich diese als erstes gefunden und sie hat mir auf Anhieb gut gefallen. Wenn Ihr noch andere Links in dieser Art zu den anderen MC's habe so bitte ich sie auch hier zu verlinken. Diese Fragen tauchen ja immer wieder im Forum auf und sind für Newcommer nicht so trivial zu beantworten. LG+Danke für die Hilfe. Markus
Wie schon weiter oben beschrieben, hatte ich vor das freie RL78 Toolset zu compilieren. Entsprechend der Beschreibung im u.g Link bin ich vorgegeangen, habe aber noch diverse Probleme beim Compilieren der Toolchain mit dem aktuellem gcc. https://llvm-gcc-renesas.com/wiki/index.php?title=Building_the_RL78_Toolchain_under_Ubuntu_14.04 Mein erster Fehler war:
1 | /dev/shm/RL78-Toolchain/source/gcc-4.9.2-20150423/gcc/reload1.c: In function ‘void init_reload()’: |
2 | /dev/shm/RL78-Toolchain/source/gcc-4.9.2-20150423/gcc/reload1.c:89:24: error: use of an operand of type ‘bool’ in ‘operator++’ is forbidden in C++17 |
3 | |
4 | (this_target_reload->x_spill_indirect_levels) |
5 | | ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~ |
6 | /dev/shm/RL78-Toolchain/source/gcc-4.9.2-20150423/gcc/reload1.c:444:7: note: in expansion of macro ‘spill_indirect_levels’ |
7 | 444 | spill_indirect_levels++; |
8 | |
9 | |
10 | struct target_reload default_target_reload; |
11 | #if SWITCHABLE_TARGET |
12 | struct target_reload *this_target_reload = &default_target_reload; |
Den konnte ich wie folgt lösen,
1 | while (memory_address_p (QImode, tem)) |
2 | {
|
3 | //spill_indirect_levels++;
|
4 | spill_indirect_levels=spill_indirect_levels+(sizeof(default_target_reload)); // modifizierte Code Zeile |
5 | tem = gen_rtx_MEM (Pmode, tem); |
6 | }
|
Nun bekomme ich einen anderen Fehler, den ich nicht ganz verstehe.
1 | cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute |
die besagte Datei sieht an der Stelle (Zeile 101) wie folgt aus:
1 | #gets -- POSIX thread cancellation point
|
2 | #getwc -- POSIX thread cancellation point
|
3 | #getwchar -- POSIX thread cancellation point
|
4 | gmtime
|
5 | isalnum
|
6 | isalpha <=== line 101: |
7 | iscntrl
|
8 | isdigit
|
9 | isgraph
|
10 | islower
|
11 | isprint
|
Ich habe den configure Aufruf mittels der CXXFLAGS auf verschieden compat Stufen gesetzt, leider aber ohne Erfolg. (-std=standard, -Wc++14-compat, -Wc++11-compat, -Wc++-compat, -Wc11-c2x-compat, -Wc99-c11-compat)
1 | CXXFLAGS='-Wc++-compat' /dev/shm/RL78-Toolchain/source/gcc-4.9.2-20150423/configure --target=rl78-elf --prefix=/dev/shm/RL78-Toolchain/prefix/ --enable-languages=c,c++ --disable-shared --with-newlib --enable-lto --disable-werrora |
Hat jemand einen Hinweis, wie ich die cross gcc sourcen für den RL78 von Renesas compilieren kann/muss? Eventuell welche Schalter für den gcc noch erforderlich sind, um die alten Sourcen für den cross gcc-4.9.2 von 2015 zu übersetzen. Meine gcc Version, s.u. gcc version 12.2.1 20221020 [revision 0aaef83351473e8f4eb774f8f999bbe87a4866d7] (SUSE Linux) Danke für nützliche Hinweise. Markus
Markus W. schrieb: > Kannst Du bitte was nütyliches zu den LPC802M001 MCs sagen? > > Wie sieht es da mit der Toolchain aus - frei und unter Linux > vorhanden? Naja das sind ARM Microcontroller. Die können mit jeder beliebigen ARM Toolchain verwendet werden, u.a. basierend GCC und clang. Die meisten aktuellen Linux Distribution liefern ARM Toolchains für "Bare-Metal" als Pakete mit, braucht man nur zu installieren. (Suchwort: arm-none-eabi) Als Editor nimmt man halt das was man mag, ich bevorzuge inzwischen VS Code. Debuggen geht - wie bei jedem ARM Cortex - via SWD. Also z.B. gdb + openocd + irgendeine von openocd unterstützte Hardware. Wenn man will kann man da noch eine der vielen Debugger GUIs, VS Code oder Eclipse CDT drüber schnallen. Oder eben jeder andere Debugger der ARM unterstützt. Mir steht zum Glück ein PowerDebug von Lauterbach zur Verfügung. Der läuft übrigens auch unter Linux (Da lief er schon vor Windows, die haben auf Unix angefangen) Ich verstehe nicht ganz wo deine 64kB Flash Anforderung her kommt. Für ein bischen ADC und Relais schalten braucht man wenige einstellige kB. In 64kB packe ich Dir nen kompletten Netzwerk-Stack inklusive Web-Server.
Hallo Andreas M., Du meinst also einfach einen aktuellen gcc cross für arm-none-eabi Targets nehmen und die RL78 header Files von Renesas für die Peripherie einbinden und die Linker config entsprechend zum RL78 Speicher Bild anpassen? In der Theorie klingt es sehr einfach. Die Tücken liegen wie immer im Detail ;-) Markus
Markus W. schrieb: > Du meinst also einfach einen aktuellen gcc cross für arm-none-eabi > Targets nehmen und die RL78 header Files von Renesas für die Peripherie Nein, ich bezog mich auf die LPC802, das sind Micros mit Cortex-M0 Architektur. Der RL78 ist was vollkommen anderes, da braucht Du eine andere Toolchain. Zur dein Toolchain-Übersetzungsversuchen von oben kann ich nur anmerken, das Ubuntu 14.04 steinalt ist und die Toolchain sehr wahrscheinlich nicht auf einem aktuellen Linux übersetzen wird. Probiere doch mal ein neueres Release von der LLVM Variante: https://llvm-gcc-renesas.com/rl78/rl78-download-toolchains/ LLVM benutzt man genauso wie den gcc, der compiler heißt nur anders. ("clang") Er versteht aber fast alle Argumente vom GCC.
Danke Andreas M. werde ich versuchen. LLVM ist mir soweit ein Begriff. clang Compiler in einer low level VM mit dem neuen Konzept einer Maschinencode Erzeugung über eine standardisierte Schnittstelle auf virtueller Ebene. LG Markus
Markus W. schrieb: > Mein erster Fehler war: > /dev/shm/RL78-Toolchain/source/gcc-4.9.2-20150423/gcc/reload1.c:89:24: > error: use of an operand of type ‘bool’ in ‘operator++’ is forbidden in > C++17 Den Fehler aber scheinst Du nicht verstanden zu haben. Du übersetzt C mit einem C++-Compiler. Das ist natürlich Unfug.
@DerEinzigeBernd, defacto verstehe ich Deinen Einwand nicht ganz! Was gibt es an den u.g. Befehlen auszusetzen?
1 | $ /home/<username>/RL78-Toolchain/source/binutils-2.24-20150423/configure --target=rl78-elf --prefix=/home/<username>/RL78-Toolchain/prefix/ --enable-maintainer-mode --disable-nls --disable-werror |
2 | $ make |
3 | $ make install |
Und wie und womit compiliert wird, ist doch wohl Sache des Makefiles! Das dieses eventuell einen Fehler beinhalten könnte, ist ja nicht auszuschließen - so weit habe ich aber noch nicht gesucht. Siehe auch Verfahrensweise zum Bau der Toolchain unter: https://llvm-gcc-renesas.com/wiki/index.php?title=Building_the_RL78_Toolchain_under_Ubuntu_14.04 Danke für den Hinweis, aber den musst Du bitte genauer erläutern. Mag sein, dass das "CXXFLAGS='-Wc++-compat'" Flag von mir falsch gesetzt oder unangebracht ist, das hat aber keinen Einfluß auf den Aufruf des Compilers, der im Makefile festgelegt wird. Markus Sorry war die falsch cmd Zeile weiter oben. (war für die binutils) Um den gcc zu bauen ist
1 | $ /home/<username>/RL78-Toolchain/source/gcc-4.9.2-20150423/configure --target=rl78-elf --prefix=/home/<username>/RL78-Toolchain/prefix/ --enable-languages=c,c++ --disable-shared --with-newlib --enable-lto --disable-werror |
2 | $ make all-gcc |
3 | $ make install-gcc |
erforderlich. Das geschriebene zu make bleibt aber das gleiche, wie oben.
:
Bearbeitet durch User
Es ist doch ganz offensichtlich: /dev/shm/RL78-Toolchain/source/gcc-4.9.2-20150423/gcc/reload1.c ist ein C-Sourcefile. Wäre es C++, hieße es *.cpp, *.cxx oder auch *.C (Großbuchstabe, sehr "schick" auf case-agnostischen Betriebssystemen). C-Sourcefiles muss man mit einem C-Compiler übersetzen, nicht mit einem C++-Compiler. Ein C-Compiler aber wird niemals einen Fehler ausgeben, der sich auf einen C++-Standard bezieht. Das aber passiert hier. Wie es dazu kommt, daß Dein make/configure/whatever dafür sorgt, daß da C-Sourcecode mit einem C++-Compiler übersetzt wird, weiß ich nicht, aber das ist halt ein Fehler. Eindeutig. Mit dem Problem beschäftigen sich auch andere Leute (zwar nicht im Zusammenhang mit Deinem µC, aber im Zusammenhang mit dem Selbstbau eines gcc). https://github.com/Freetz-NG/freetz-ng/discussions/396 Und da steht ein interessanter Kommentar: > The gcc of you host is to new to build the old gcc for the toolchain > use an old linux with old gcc > or use precompiled toolchains > or change a .mk file somewhere in toolchains/ and set the gcc > compatibility mode, like 94403ec (94403ec ist ein Link auf https://github.com/Freetz-NG/freetz-ng/commit/94403ec7012aa08b7d80ebf4cd431af24f64f487)
Ich bin gerade auf dem Sprung, lese mir Deinen Post später genauer durch. Kann nur sagen, dass ich mit der u.g. Mod
1 | /dev/shm/RL78-Toolchain/source/gcc-4.9.2-20150423/gcc/cp/cfns.h |
2 | |
3 | #ifdef __GNUC__ |
4 | __inline |
5 | #endif |
6 | const char * libc_name_p (const char *, unsigned int); |
7 | /* maximum key range = 391, duplicates = 0 */ |
8 | |
9 | /* |
10 | #ifdef __GNUC__ |
11 | __inline |
12 | #endif |
13 | /* |
14 | const char * libc_name_p (const char *, unsigned int); |
15 | /* maximum key range = 391, duplicates = 0 */ |
16 | |
17 | |
18 | >ls -l | grep '\-rwx' |
19 | -rwx------ 1 mw users 3239 Jan 5 11:24 as |
20 | -rwx------ 1 mw users 72050632 Jan 8 14:59 cc1 |
21 | -rwx------ 1 mw users 78402456 Jan 8 14:59 cc1plus |
22 | -rwx------ 1 mw users 1742272 Jan 8 14:58 collect2 |
23 | -rwx------ 1 mw users 3239 Jan 5 11:24 collect-ld |
24 | -rwx------ 1 mw users 51057 Jan 8 14:57 config.status |
25 | -rwx------ 1 mw users 2476280 Jan 8 14:59 cpp |
26 | -rwx------ 1 mw users 134496 Jan 8 14:59 gcc-ar |
27 | -rwx------ 1 mw users 2466792 Jan 8 14:59 gcc-cross |
28 | -rwx------ 1 mw users 134352 Jan 8 14:59 gcc-nm |
29 | -rwx------ 1 mw users 5721 Jan 5 11:24 gcc-nm.c |
30 | -rwx------ 1 mw users 134360 Jan 8 14:59 gcc-ranlib |
31 | -rwx------ 1 mw users 5721 Jan 5 11:24 gcc-ranlib.c |
32 | -rwx------ 1 mw users 1634432 Jan 8 14:58 gcov |
33 | -rwx------ 1 mw users 1401040 Jan 8 14:58 gcov-dump |
34 | -rwx------ 1 mw users 2479384 Jan 8 14:59 g++-cross |
35 | -rwx------ 1 mw users 744216 Jan 8 14:59 gengtype |
36 | -rwx------ 1 mw users 67933704 Jan 8 14:59 lto1 |
37 | -rwx------ 1 mw users 1931008 Jan 8 14:59 lto-wrapper |
38 | -rwx------ 1 mw users 3239 Jan 5 11:24 nm |
39 | -rwx------ 1 mw users 2479384 Jan 8 14:59 xg++ |
40 | -rwx------ 1 mw users 2466792 Jan 8 14:59 xgcc |
die Vorstufe vom RL78 gcc bauen konnte. Danach lief newlib durch. Nun kommt der finale Schritt, wie in der Verfahrensanweisung beschrieben. [pre] 11) Build final GCC a) Change the current directory to gcc: $ cd gcc b) Build : $ sudo make $ sudo make install [\pre] LG Markus
:
Bearbeitet durch User
Habe es soweit geschafft die RL78 Toolchain auf meinem System zu compilieren. Siehe Anhang des Prefix-Verzeichnisses. Ob alles so ist wie es sein soll kann ich noch nicht Mangels eines Targets sagen, werde ich aber mal soweit mit einem mini C-Prog testen. Eventuell kann ja jemand ein RL78 Target spaßhalber flashen. Ob dass dann schon ein Beweis dafür ist, dass ich alles richtig gemacht habe kann ich aber nicht sagen. Auf jeden Fall habe ich einen RL78 gdb und gcc und die zugehörige stdlib, so daß man schon was testen könnte. Danke allen, die mir geholfen haben. Falls Interesse besteht, kann ich mein Toolchain-Dir irgendwo zum Download rein stellen, für Linux Nutzer. Für die Windows Fraktion macht mein Kompilat wahrscheinlich kein Sinn, kann aber trotzdem jeder gerne haben.
1 | >du -sh ./RL78-Toolchain |
2 | 5.0G ./RL78-Toolchain |
-rw------- 1 mw users 803606194 Jan 8 19:27 RL78-Toolchain.7z LG Markus
:
Bearbeitet durch User
Für die RL78 nutze ich den GCC 4.9.2 (Compilier-Datum: 11/2016 aber immerhin schon 64 Bit), aber mit meiner eigenen Bibliothek, die bereits einen Großteil der Hardware unterstützt (I2C nur in Software). Das Ganze belegt aber nur knapp 250MB. Wenn Du mir einen konkreten Typen nennst, kann ich ein Paket mit allen erforderlichen Dateien generieren, im Makefile musst Du dann nur noch den Pfad zur Toolchain angeben und die Programmierbefehle anpassen. Zumindest früher war es so, dass die Renesas-Toolchains die Register-Deskriptionen in einem eigenen Format verwendet hat. Die musste ich mir erst mit einem eigenen Tool in ein GCC-lesbaras Format (.h) umwandeln. Jörg
Hallo Jörg, danke für das Angebot. Komme eventuell darauf zurück. Die Verhältnisse bei meinem Packet sind wie unten dargestellt. Eine komplette Liste der Files findest Du im Anhang 7z komprimiert.
1 | mw@linux-kwm1:...RL78-Toolchain_MW/prefix |
2 | >du -sh . |
3 | 725M . |
4 | mw@linux-kwm1:...RL78-Toolchain_MW/prefix |
5 | >du -sh bin include lib64 libexec rl78-elf share |
6 | 94M bin |
7 | 12K include |
8 | 15M lib64 |
9 | 213M libexec |
10 | 382M rl78-elf |
11 | 23M share |
Falls Du ein Testprogramm hättest, das ich compilieren könnte und Du es in ein Target flashen könntest um zu testen, ob mein gebauter Compiler das macht, was er soll, wäre das fein. Es hat aber keine Eile, da ich zur Zeit noch nichts mit einem RL78 mache, geschweige den welche habe. Ich besitze nur ein altes Dev-Board mit einem V850, was ich aber noch nie richtig eingesetzt habe. Wenn die Toolchain richtig funktioniert, würde ich durchaus mal einige RL78 bei Mouser bestellen um etwas zu spielen. Bin gespannt, ob es auch so ein Hickhack gibt wie bei den gerade bestellten AVRs und PICs mit Ausfuhrgenehmigung aus den Staaten. Hoffe, das ist bei den Renesas Controllern nicht der Fall. LG Markus
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten