Hi! Gibt es irgendwo eine Liste aktueller CPUs, der man die Geschwindigkeit entnehmen kann? Ein AVR hat 1MIPS @ 1MHz. Aber wie schnell ist z.B. ein 80320 @ 24MHz oder die PIC-Familie? Mein gegoogle hat leider nichts gebracht. Aber vielleicht weiß es einer auch so. Besten Dank
Eine derartige Liste kenn ich auch nicht, aber es gibt ein paar bekannte Werte wieviele Takte Pro Befehl benötigt werden. AVR braucht für die meisten Befehle 1 Takt, Ein paar wenige 2, 3 oder 4. Die PIC Familie benötigt für die schnellsten Befehle soweit ich weiß 3 Takte. Ob es mittlerweile schnellere gibt weiß ich nicht. Und bei 8051 wirds kompliziert. Der Ur 8051 brauchte glaub ich 12 oder sogar 24 Takte pro Befehl, einige neue Nachbauten brauchen 4 Takte und ein paar total aufgebohrte brauchen sogar nur noch 1 Takt für die schnellsten Befehle. Allerdings hat sich am Flaschenhals "Akku-Register" soweit ich weiß bis heute nichts geändert. Hoffe das war erstmal hilfreich Markus
Das ist leider der typische Apfel-Birnen-Vergleich. Die MIPS sagen im Prinzip nur aus, wieviel NOPs je Sekunde gemacht werden können. Der Cygnal 8051 hat so z.B. 75MIPS bei 75MHz. Aber z.B. für ein "CJNE @Ri, wert, label" benötigt er schon 5 Zyklen, d.h. davon schafft er nur 15MIPS. Der AVR kann das aber gar nicht in einer Instruktion, d.h. er muß das so machen: LD r16,X CPI r16, wert BRNE label Er benötigt für diese 3 Befehle zusammen auch 5 Zyklen. AVRs laufen derzeit aber nur bis 16MHz, so daß der Cygnal in diesem Beispiel schneller ist. Ein echter Vergleich ist daher nur anhand der gewünschten Anwendung möglich. Peter
Quatsch, der PIC hat auch nur 1 und 2 Cycle Commands 35 Intructions: davon 5 mit 2 Cycles und 4 mit 1 oder 2 Cycles (conditional branches) der Rest ist 1 Cycle MooseC
Vorsicht! Die Pic's haben einen Vorteiler von 4. D.h. pro Cyclus 4 Quarztakte -> 1 Befehlszyklus. 1NOP bei 4MHz -> 1µs Der Ur-8051 hat einen Vorteiler von 12 - 12 Quarztakte -> 1 Befehlszyklus. 1 NOP bei 12 MHz -> 1µs Will nicht Klugscheißen, aber das darf man nicht durcheinanderbringen...
Erst einmal vielen Dank für die schnellen Antworten. @Peter: Ich kenne bisher nur den AVR. Dort ist der Befehlssatz soweit vereinfacht, daß nahezu jeder Befehl einen Zyklus braucht. Wenn ich das beim 8051 richtig verstanden habe, gibt es da Befehle, die im Vergleich zum AVR einige Dinge zusammenfassen - wie Dein Beispiel zeigt. Da in Deinem Beispiel beide CPUs das gleiche tun, jedoch nur anders gesagt bekommen, aber für die gleiche Arbeit genau gleiche Zyklenzahl benötigen, dann sind sie doch auch gleich schnell, oder? Mal angenommen, ich würde einen AVR auch auf 75MHz takten, dann wäre er doch genau so schnell, wie der 8051. Wenn ich einen AVR in einer Hochsprache (z.B. C) programmiere, scheint er bei einigen Befehlen auch langsamer zu sein, weil er scheinbar mehr Zyklen benötigt. Doch in Wahrheit wird dieser eine Befehl nur in mehrere aufgeteilt, damit die CPU mit ihrem begranzten Befehlssatz das auch versteht. Oder habe ich das alles falsch verstanden?
Also, hab grad nochmal ein Datenblatt durchstöbert. Da steht zwar drin das die Befehle einen oder zwei Zyklen brauchen, aber trotzdem ist er nur mit 10 MIPS bei 40 MHz angegeben. Es stimmt also was Ralf geschrieben hat. Generell ist der Geschwindigkeitsvergleich zwischen den MCU's ne Milchmädchenrechnung und man kann sich nur grob orientieren. Die Rechnung von Peter weiter oben müsste stimmen, aber ein Programm besteht ja nunmal nicht nur aus CJNE Befehlen. Generell würde ich aber trotzdem sagen das die AVR bei gleichem Takt die schnellsten 8 Bitter sind, ist aber ne rein subjektive Meinung und stützt sich nur zum Teil auf praktische Erfahrung
@Ralf: Das scheint mir doch eine recht wichtige Info zu sein. Warum auch immer dieser Vorteiler bei einigen CPUs existiert, wichtig ist doch, was am Ende bei der CPU ankommt. Und da scheint es im Vergleich "Input/Output" doch so zu sein, daß bei 4MHz ein AVR 4 Zyklen und ein PIC nur einen verarbeitet. Somit ist ein AVR schneller als ein gleich getakteter PIC. Oder? Wie ist das denn nun konkret beim 80320 @ 24MHz? Habe da 'ne Applikation gesehen und würde das gerne mit AVR machen, um nicht noch eine Sprache zu lernen und 'nen Programmer zu kaufen. Angenommen der 80320 hat auch 'nen Vorteiler, dann könnte das doch auch ein AVR schaffen?
Also ich denke wenn das ein 80320 mit 24MHz schafft dann schafft das ein AVR mit 16MHz locker. Der 80320 hat soweit ich weiß noch einen /4 Vorteiler, hat also sozusagen nur 6MHz (jaja, ich weiß. stimmt nicht exakt. nich hauen ;)
Hi zum Vorteiler: Der ist nötig da bei der 8051er Architektur nicht alles mit einem Takt gemacht werden kann. Beim 1sten Takt schreibt er die Low-Adresse auf den Bus, beim 2. legt er die Daten an usw. So das sich eben beim Ur 51er 12 Takte pro Maschinenzyklus ergeben. Der AVR macht das auch nicht alles in einem Takt. Jeder Befehl braucht dort eigentlich zwei Takte. Aber da er aber eine sog. Instruction-Prefetch Einheit hat holt er sich bereits beim Ausführen eines Befehls den nächsten. Bei Sprungbefehlen kann das aber nicht klappen. Deshalb brauchen Sprungbefehle immer 2 Zyklen. Bedingte Sprünge brauchen aus obigem Grund 1 Zyklus wenn nicht gesprungen wird und 2 Zyklen wenn gesprungen wird. 80320 vs. AVR: Das kann man so nicht sagen. Wenn der 80320 ne Menge mit Bitvariablen macht wird der AVR Mühe haben da mitzukommen da er vieles über das ausmaskieren von Bits machen muß wo der MCS51-Kern des 80320 spezielle Befehle dafür hat. Macht der 80320 aber ne Menge Arithmetik und hantiert mit long-Zahlen dann dürft der AVR deutlich schneller sein. Wie Peter geschrieben hat: "Ein echter Vergleich ist daher nur anhand der gewünschten Anwendung möglich." Matthias
@Markus Es ging mit auch gar nicht um die Quarzfrequenz, die ist ohnehin nur von geringer Bedeutung, aus schon hier mehrfach beschriebenen Gründen, sondern um die Richtigstellung, das der PIC keine 3 Takte braucht. Natürlich ist der AVR mit 16MHz schneller als ein PIC18 mit 40MHz, aber es ging mir ja auch gar nicht um den Vorteiler. Entscheidend ist für die Ausführungszeit eh die Befehlszykluszeit und die Architektur der CPU. Peter hat es mit den MIPS schön getroffen... Kommt eben immer darauf an wofür der Controller eingesetzt wird. MooseC
Ok. Vielen Dank! Ich wollte den Vergleich allgemein halten, um ihn auch später noch anwenden zu können. Das ist aber wohl so pauschal nicht möglich. Also werde ich konkret: Mein Laptop hat keine Midi-Schnittstelle. Die brauche ich aber für den mobilen (Service)-Einsatz. Bei Elektor habe ich ein Interface gefunden, das mit einem Treiber von Yamaha den COM-Port umwandelt zu MIDI. Da ich dieses Feature evtl. auch später noch in anderen Projekten einsetzen möchte, würde ich das gerne auf 'nem AVR realisieren (wegen bekannter Sprache, vorhandenem Programmer etc.). Alles, was ich bisher gesehen habe, wo es um Interfaces geht (RS232-MIDI, MIDI-DMX) wurde kein AVR eingesetzt. Mitlerweile gibt es aber auch schon AVRs mit 2 seriellen Schnittstellen, so daß das von der Hardware ein leichtes wäre. Wäre nett, wenn sich das Programm mal einer ansehen könnte, der sowohl 80320 als auch AVR kennt und seinen Kommentar abgeben könnte, ob das konvertierbar ist. Das Listing findet Ihr auf www.elektor.de unter Downloads Heft Mai2001, Projekt RS232-nach-Midi-Interface, Software (leider direkter Link nicht möglich). Besten Dank
Hi Bitbefehle des 8051: Der 8051 kann direkt 256 Bits addresieren. Diese liegen haben im Prinzip einen eigenen Adressraum. 128 Bits davon liegen im internen RAM IIRC von Adresse 0x20 bis 0x2F. Der Rest liegt im SFR-Bereich. D.h. du kannst entweder Bit oder Bytewide auf den selben Speicher zugreifen. Das ist bei Bitgefummel schonmal sehr effektiv. Dann kann er mit jedem dieser Bits Set Bit Clear Bit Complement Bit And with Carry Or with Carry Mov to Carry Mov from Carry Jump if Jump if not Das macht Bitgefummel einfach effektiver als auf dem AVR. Auch kann der 8051 viele Befehle direkt auf dem kompletten internen Speicher ausführen. Auf dem AVR sieht das Drehen eines Bits an einem Port-Bit irgendwie so aus: IN temp1,PINB LDI temp2,0x01 EOR temp1,temp2 OUT PORTB,temp1 auf dem 51er dafür CPL P2_1 Zum RS232->MIDI Das geht auf jeden Fall mit dem AVR. Die serielle Schnittstelle liefert die Daten lange nicht so schnell wie sie der aVR verarbeiten kann. Matthias
@ MooseChecker: naja, ganz uninteressant ist die Taktfrequenz auch nicht. Zum einen steigt die Leistungsaufnahme mit der Taktfrequenz, zum zweiten steigt die Empfindlichkeit der Schaltung und zum dritten steigt mit jedem Mhz auch die Produktion von Störstrahlung (Stichwort EMV). Ein Lochrasteraufbau bei 16MHz ist noch relativ problemlos, bei 40 oder mehr kann es schon schwierig werden. Da kann jeder cm Leitung, jede Lötstelle und jeder Steckkontakt zur Fehlerquelle werden @Gralf: wenn Du 2 UARTS brauchst empfehle ich den ATmega162. Der sollte die Anwendung "auf einer Arschbacke" schaffen ;) Also genug Speicher, genug Leistung, genug Reserven
@gralf Die Schaltung ist ja nichts anderes als ein simple Baudratenkonvertierung 31250 (MIDI) <--> 38400 (PC) mit Software FiFo und Option Hardware Handshake. Läßt sich mit nahezu beliebigem µc lösen. Wenn man die Software möglichst einfach gestalten will, sollte diese über 2 Hardware UART verfügen. Beim AVR kommen da MEGA 128/162 oder 162 in Betracht. Als Taktfrequenz sollten dann 8 MHz vorgesehen werden, um den Fehler bei beiden Baudraten möglichst gering zu halten. 16 MHz geht zwar auch, ist aber hier absolut nicht notwendig, da für die reine Rechnerei wohl schon 1-2 MHz reichen würden.
@Mathias: Ok, da scheint es einige Unterschiede zu geben. Aber der AVR hat auch einige Bit Befehle, einschließlich Compare/JMP und sowas. Dein Beispiel versteh ich aber nicht ganz. Wieso liest Du einen Wert aus PinB aus und schreibst ihn in PortB? Was willst du damit erreichen?
Hi klar hat der AVR auch ein paar Bitbefehle. Die sind aber eben nicht ganz so mächtig. Mit dem Beispiel wollte ich dich verwirren. Nein. Spaß beiseite. Ist einfach ein Fipptehler. Sollte natürlich heißen: IN temp1,PORTB LDI temp2,0x01 EOR temp1,temp2 OUT PORTB,temp1 Matthias
Aha, so macht das schon mehr Sinn, aber auch nicht. Man kann ohne weiteres einzelne Bits direkt in PortB setzen/löschen
Die ganze Diskussion ist realtiv müssig, jede Prozessorfamilie hat ihre Vor- und Nachteile, einen direkten Bit-Toggle Befehl für die I/O Ports kennt der AVR zwar nicht (Anwendung eher selten) dafür aber direkte Bit Set/Reset Befehle. Toggle lässt sich aber auch einfach so realieren, zwar mehr Clock-Zyklen aber dafür keine Registernutzung: sbis PINB,0 rjmp PC + 3 cbi PORTB,0 rjmp PC + 2 sbi PORTB,0
Hi, müsste man nicht, um zwei Prozessoren zu vergleichen, ein Benchmark-Programm laufen lassen (das Programm kann ja durchaus an die jeweiligen Features der Archtektur angepasst sein) ?? Im Prinzip müsste man sich ne Anwendung suchen (Primzahlen berechen für Numerik, Memory-Schreiben für I/O etc.) und die laufen lassen ... Gruß UBoot-Stocki
Da ganze Diskussion geht wohl in die falsche Richtung, Benchmarks für Mikrocontroller sind schlichtweg gesagt ein Witz und dienen wohl eher der Befriedigung irgendwelcher Werbestrategen in den Marketingabteilungen. Die Frage sollte vielmehr laut, kann der Prozessor x die von mir gestellte Aufgabe lösen und passt er in meinen Preisrahmen. Wenn ich diese Frage mit ja beantworten kann hat sich das Thema erledigt, ansonsten muß ich nach einem besser geeigneten Controller Ausschau halten. Was nützt der "beste" Controller wenn dieser 90% seiner Zeit mit "nichtstun" beschäftigt ist und außerdem viel zu teuer da völlig überdimensioniert.
@Markus Das ist doch schon wieder eine Fehlinfo. >>Ein Lochrasteraufbau bei 16MHz ist noch relativ problemlos, bei 40 oder mehr kann es schon schwierig werden. Da kann jeder cm Leitung, jede Lötstelle und jeder Steckkontakt zur Fehlerquelle werden Der PIC hat einen 10MHz Quarz und eine x4 PLL intern. Erzeugt so 40MHz und teilt sie wieder durch 4 um dann auch seine eigentliche Cyclespeed zu kommen. Die 40MHz sind intern, davon merks Du außen gar nichts und hast auch kein Problem mit der EMV. Was die Empfindlichkeit betrifft, stimmt das auch nicht, da das System für sich gekapselt ist. Die PICs laufen sehr sicher, wir haben schon tausende in unseren Geräten verbaut und haben NULL Probleme mit der Funktion. Und mit EMV haben wir auch überhaupt keine Probleme, bei den Messunungen wird schonmal gefragt, ob die Geräte nur eine Attrappe seien Irgendwie ja komisch da ich hier den PIC verteidigen muß... MooseC
@MooseC: sorry, verteidigen mußt du ihn nicht. Da bin ich wohl einer Fehlinfo unterlegen. Für mich heißt 40 MHz das auch ein 40MHz Quarz angeschlossen ist. Ich behaupte sicher auch nicht das die PIC schlechte Controller sind. Ich bin nur der Meinung das die AVR für den Hobbyanwender der geeignetste Controller ist. Die Verfügbare Palette ist übersichtlicher, die Leistung ist mehr als ausreichend und die Handhabung ist recht einfach. Als ich vor ein paar Jahren nach einem für mich passenden µC gesucht habe hab ich mir neben AVR und PIC auch 8051 und 68HC11 näher angeschaut und beim PIC hat mich einfach die unübersichtliche Produktvielfalt gestört. Irgendwie hab ich nie den passenden Controller gefunden. Außerdem hat mich die geringere Leistung, die kleinen Speicher, die damals meist verwendete Speicherwortbreite von 12/14 Bit und das gewöhnungsbedürftige Speichermanagement gestört. Die AVR haben mich einfach von Anfang an überzeugt und ich bin bisher auch noch nicht wirklich entäuscht worden. Aber um das nochmal zusammenzufassen: es ist meist relativ egal welchen µC man wählt da die meisten irgendwo ihre Vorzüge haben. Ein Leistungsvergleich (was ja das ursprüngliche Thema war) ist müßig und eigentlich auch völlig überflüssig. Die Wahl, welchen µC man wählt hängt eigentlich nur von zwei Faktoren ab: 1. Von den persönlichen Vorlieben bzw von der persönlichen Einstellung 2. Von der Applikation Meine Meinung zu 1. habe ich denke ich schon oft genug kundgetan und zu 2. kann ich sagen, das ich bisher noch keine Applikation hatte für die ich nicht einen AVR einsetzen konnte Jetzt wünsche ich erstmal ein schönes Wochenende Gruß Markus
@Markus Kann es sein das Du glaubst ich würde den PIC propagieren? Es ging lediglich um die korrekte Darstellung nicht um Vorlieben. Allmählich solltest auch Du wissen wer hier im Forum welchen Controller einsetzt, beziehungsweise welche Architektur bevorzieht. Ebenso die Ansichten der einzelnen Leute hier ist hinlänglich bekannt. Somit habe ich auch keine Lust immer wieder meinen Standpunkt darzulegen, wobei das auch nur temporär wäre, da ich mich immer gerne nach anderen Controllern umsehe und nicht festgelegt bin und auch nicht sein will. MooseC
Weiter oben habe ich gelernt, daß man den Befehl "CJNE @Ri, wert, label" auf einem AVR wie folgt programmiert: LD r16,X CPI r16, wert BRNE label Vom 68k-Controller kommend möchte ich gerne den superschnellen 75MHz Cygnal 51er einsetzen und brauche eine Lösung, wie ich den Befehl LEA.L $02(A6,D0.L),A3 entsprechend formuliere; er braucht nur wenige Taktzyklen. Das müßte doch ganz einfach sein, schließlich ist der 8051 ja Industriestandard. Wieviel Taktzyklen braucht der 51er, hundert oder noch mehr ?
@Mikki, Markus, Matthias Danke für Eure Einschätzung. Werde dann wohl mal bei Gelegenheit die Schaltung umsetzen. @MooseChecker Wie bitte? Der externe Takt wird intern im PIC vervierfacht und dann wieder geteilt? Dann gibt es ja im Endeffekt doch ein Verhältnis von 1:1 von Quarztakt zu Zyklus. Wie beim AVR. Was dazwischen passiert ist doch eigentlich egal.
Hi nicht ganz egal. Der PIC braucht halt die 4 Takte pro Maschinenzyklus (das ist jetzt keine Kritik so ist halt die Architektur des PIC). Die 3 zusätzlichen Takte werden nicht einfach weggeschmissen. Matthias
Das mit der PLL-Taktmultiplikation und anschließenden Division wird gemacht, um 1. ein Taktsignal mit einem Tastverhältniss von genau 50% zuerhalten, und um 2. einen höheren internen CPU-Clock zuerhalten, als der angeschlossene Quarz direkt liefern kann. Bei meiner MCU(XC161) verwende ich einen 8MHz Quarz. Die PPL jubelt diese Frequenz auf über 100MHz hoch, um dann durch Teilung den 40MHz-CPU-Clock zuerzeugen. Die Instructionzykluszeit ist somit 25nSek.
@Michael, "LEA.L $02(A6,D0.L),A3" ??? Diese Frage kann Dir wohl nur einer beantworten, der sich in der 68k-Syntax auskennt bzw. Du must schon mit Worten beschreiben, was da passiert. Wenn ich mich aber nicht täusche, spielt der 68k in einer ganz anderen Liga (32 Bit) und ist ein riesiges BGA-Monster. Auch ist es kein kompletter MC sondern nur die CPU. Im Stromverbrauch dürfte er auch wesentlich hungriger sein. Das ist dann schon kein Apfel-Birnen-Vergleich mehr, sondern eher ein Ameisen-Elefanten-Vergleich. Peter
@Michael Wenn Du von dem 68k kommst, warum bleibst du dann nicht bei den 16/32Bittern? Sieh Dir doch mal die M16er von Renesas (einst Mitsubishi) an. Die sind dem 68k so ähnlich, das man meinen könnte, die hätten kräftig geklaut. Ist wie Nachhause kommen, wenn man den 68k kennt. Der ist mit dem M16C80 bei ca. 17 Euro und 20MHz ein CISC Arbeitspferd. 256k Flash, 20k SRAM, 5xUARTs/SPI/I2C, 11x16Bit Timer, 8x10BitADC, 2x8BitDAC, integrierter Bootloader und und und... MooseC
@MooseC Danke für Deinen Tipp. Ich setze bereits den H8S/2394 ein; die M16er sind auch eine feine Sache. Meine 'Frage' war eine Überspitzung: wie übertrage ich ein 8051 Programm, ohne mich mit der Struktur des anderen Prozessors auseinanderzusetzen. Folglich ist es kein Wunder, daß bei soviel Ignoranz der andere Prozessor - welcher auch immer - als der schlechtere da steht, wie es dann auch noch genau vorgerechnet wird.
die Ironie hätte mir eigentlich bei der Frage nach den Taktzyklen auffallen müssen. Dann bist Du ja schon bestens versorgt. Ich werde mir die Hitachis/Renesas wohl auch noch einmal ansehen, das hatte ich zwar vor ein paar Jahren schon getan, aber die Kreterien ändern sich ja auch - also auch danke für den Tip. Wie ist es denn mit den Tools und Environments der H8 bestellt? Gibt's die Tools mittlerweile for free? MooseC
@Michael, "Folglich ist es kein Wunder, daß bei soviel Ignoranz der andere Prozessor - welcher auch immer - als der schlechtere da steht, wie es dann auch noch genau vorgerechnet wird." Da hast Du mich leider völlig mißverstanden :-( Die Rechnung sollte doch nur verdeutlichen, das die MIPS etwas sehr relatives sind und absolut nicht bedeuten daß der eine besser oder schlechter ist. Ich habe ja auch nirgends behauptet, daß ein bestimmter Prozessor besser oder schlechter ist. Ich habe immer nur aufgezählt, was mir an dem einen nicht so gut gefällt, bzw. was ich dort zur Lösung bestimmter Aufgaben vermisse, und was mir an einem andern besser gefällt. Einen besten Prozessor gibt es nun mal nicht, sonst würde ja nur noch dieser eine hergestellt. Der beste Prozessor für eine bestimmte Aufgabe kann natürlich bedeuten, daß ich einen nehme, den ich schon gut kenne und damit die geforderte Anwendung in möglichst kurzer Zeit entwickeln kann. Somit kann für jemand anderen für die gleiche Aufgabe ein völlig anderer Prozessor der beste sein. Man sollte bloß vermeiden mit Kanonen auf Spatzen zu schießen (Blinklicht mit einem 68k) oder umgekehrt einen 8-Bitter bis zum letzten verfügbaren Codebyte auszuknautschen. Die hier beschriebene Anwendung eines simplen Baudratenkonverters dürfte eine 86k jedenfalls auch nicht ansatzweise fordern. Da reicht jeder 8051 mit 2 UARTs. Man kann natürlich auch einen ATMEGA8 verwenden und die 2.UART in Software realisieren. Der Cygnal ist zwar einer der schnellsten 8-Bitter aber ich habe ihn noch nie verwendet. Meistens reichen mir die 0,9MIPS (Standard 8051 bei 11.0592MHz Quarz) völlig aus. Es ist eben nur ein beruhigendes Gefühl ohne große Änderungen am Programm auch fast 10000% schneller sein zu können, wenn man sich versehentlich doch mal in der benötigten Geschwindigkeit völlig verschätzt haben sollte. Aber wie es scheint, muß es auch für solche superschnellen 8-Bitter einen Markt geben, sonst würde Cygnal ihn ja nicht herstellen bzw. nicht den 100MIPS-Typ ankündigen. Peter
@MooseC Einen GNU-CC-Compiler mit allem Zubehör gab es schon immer; ich verwende meist die Version 98R2 o.ä.. Die gab es auf der Hitachi CD von 1999 und erzeugt guten Code. Die CD läßt sich bei Bedarf auch kopieren. Gibt zwar auch neuere Versionen, aber die sind mir zu 'windows-haft'. Für den MC16 gib es das glaube ich nicht (?). Beim Prozessor verwende ich immer externes Flash-EPROM+RAM wegen benötigter Akkupufferung und Platzbedarfs. Soweit.
GCC für M16? weiß ich nicht, wozu auch gibt ja den NC30 und NC308. Und als Oberfläche den Toolmanager. Aber der Compiler läuft im Dos-Fenster und kann auch ganz normal in Batchfiles oder vom Editor(z.B. CodeWrite) aus mit dem Makefile aufgerufen werden. Je nach Vorliebe. Der Toolmanager vereint zudem noch den Debugger und ein paar andere nette Dinge wie den Stackviewer. Läßt sich aber auch ohne TM nutzen. Auf der CD von Hitachi ist der Compiler drauf? Dann werde ich mal bei SASCO anfragen... MooseC
@MooseC Der GNU-C-Compiler befindet sich letztmalig auf der CD Sept/2001 (99r1, ca. 95MB). Wohl aus Platzgründen fehlt das Verzeichnis 'tools' auf der CD 11/2002. Unter www.kpit.com gibt es eine für die H8-Familie optimierte Version des GCC (ca. 25MB). Den MC16/80 hatte ich vor längerer Zeit getestet zusammen mit KNC308... Die 3-Monatstestfrist ist lange vorbei. Mit GCC bin ich vertrauter. Wenn es die H8S nicht geben würde, wäre ich wohl bei MC16/32 gelandet. Vielleicht bringt uns der neue Firmenverbund auch verbesserte Prozessoren.
Nachtrag: ich hätte heute zuerst den realen Briefkasten auf Inhalt prüfen sollen. Renesas plant einen H8SX mit dem von mir schon immer vermissten VBR (vector base register)und einigen Erweiterungen.
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.