Hallo, ich mache für diese Fragestellung jetzt mal einen neuen Fred auf (Beim letzten hat sich der Titel schnell als "suboptimal" erwiesen). Ich habe jetzt einiges über Vergleiche der Professoren gelesen, aber alle Unklarheiten sind noch nicht behoben. Die Mega-Familie ist klar. Die ARM-Familie ist rel. klar, da konnte ich im Datenblatt die unterschiedlichen Taktraten finden. Beim AVR32 wird es schon etwas schwieriger. Im Datenblatt haben alle IO-Module Bezug zum Master-Clock. Allerdings habe ich nicht gefunden, wo der einstellbar ist, bzw. wovon der abhängt. Letztens bin ich über einen Fred gestolpert, in dem Peter schrieb, dass es 8051 mit 100MHz gäbe, die IOs mit 1:1 angebunden haben. Bei Atmel habe ich nur welche bis 60 MHz gefunden und da steht auch schon, dass es einen 2x Faktor gäbe (also IO doch nur halb so schnell wie der Core?). Wie sieht es sonst mit dem 8051ern aus? Sind die mit den Megas vergleichbar? Die seriellen Daten haben eine Taktrate von ca. 13 MHz und die möchte ich lesen, umpacken und weiter kopieren. Jetzt suche ich eine möglichst preiswerte Variante, die auch mit einer akzeptablen Einarbeitungszeit zu bewältigen ist. Welche µCs haben schnellere IO als ein mega mit 20MHz? Vielleicht auch noch etwas Luft für interne Schiebereien... 8Bit CPU wäre völlig in Ordnung - es geht hauptsächlich um serielle Protokolle, 32Bit-Performance spielt nur sekundär eine Rolle. Gruß Santi
@Santiago m. H. (mausschubser) >Die seriellen Daten haben eine Taktrate von ca. 13 MHz und die möchte >ich lesen, umpacken und weiter kopieren. Was für serielle Daten? SPI? > Jetzt suche ich eine möglichst >preiswerte Variante, die auch mit einer akzeptablen Einarbeitungszeit zu >bewältigen ist. Lass es jemanden machen, der sich damit auskennt ;-) >Welche µCs haben schnellere IO als ein mega mit 20MHz? Vielleicht auch >noch etwas Luft für interne Schiebereien... Wenn es WIRKLICH 13 Mbit/s sind, wird es eng mit "normalen" uCs. Da ist ein CPLD die bessere Wahl. MFg Falk
Falk, solche Antworten wollte er das letzte Mal schon nicht hören. Schnelle serielle Signale mit einem µC abzutasten macht halt nur bedingt Sinn, mit einem normalen IO noch weniger. Sowas kann man in Timer-Funktionen packen oder eben in externe schnelle Hardware auslagern. Es gibt allerdings auch schnelle IOs, wie du schon herausgefunden hast, bei einigen 8051 Derivaten, oder auch beim Propeller meines Wissens. Sind die seriellen Signale asynchron oder synchron?
Hallo, > Was für serielle Daten? SPI? Hm - weiß ich nicht, was ich darauf antworten soll. Ich denke, mit SPI könnte man es verarbeiten. > Wenn es WIRKLICH 13 Mbit/s sind, wird es eng mit "normalen" uCs. Da ist > ein CPLD die bessere Wahl. und wie sieht es mit Einarbeitung in CPLD aus? Dürfte nicht unerheblich sein, oder täusche ich mich da? > Falk, solche Antworten wollte er das letzte Mal schon nicht hören. Christian, ich weiß nicht, wie Du zu dem Statement kommst. Ich bin für alles offen, was nachvollziehbar und praktikabel ist. Wenn mir jemand stichhaltige Argumente liefert, habe ich schneller meinen Standpunkt gewechselt, als Du mit den Augen zwinkern kannst - aber eben nur dann. Ich bin Überzeugungstäter und nicht jemand der aus dem Fenster springt, nur weil jemand "spring" ruft. > Sind die seriellen Signale asynchron oder synchron? Worin unterscheiden die sich? Also wenn I2S asynchron ist und SPI synchron, dann sind es synchrone Daten. Wie sieht es denn mit dem AT89C51RE2 aus? Wäre der schnell genug? Wenn ich es richtig verstanden habe, geht SPI mit 1/4 des Systemtaktes, also bei 60 MHz wären das ca. 15 MHz, würde also knapp reichen. In Zusammenhang mit dem SPI-Interrupt sollte es also möglich sein, die Daten zu verarbeiten. Bleibt nur die Frage, ob die 60MHz für die Berechnung gelten oder ob anders gerechnet werden muss. Gruß Santi
Hallo, habe gerade mal gelesen, was es mit dem "Propeller" auf sich hat:
1 | Der Propeller Chip enthält acht 32-Bit CPU-Kerne. |
2 | Jeder dieser Kerne (COGs) verfügt über 2KB (512 Langworte) RAM |
3 | und alle COGs haben Zugriff auf den gemeinsamen 32KB großen HUB RAM Bereich. |
4 | Allerdings kann ein COG nur Code im eigenen COG RAM abarbeiten, |
5 | zudem wird der COG RAM sowohl für Befehle als auch für Daten verwendet. |
Hm, sehe ich das falsch, oder relativiert die COG-Verwendung die Vorteile wieder? DIP-Gehäuse hätte natürlich wieder was für sich :)
Vielleicht sagst du uns erst mal, welche Signale du einlesen möchtest. I2S ist ebenfalls synchron, da eine Takt-Leitung vorhanden. UART wäre asynchron, FireWire und USB auch. Aber was genau willst du denn machen?
Zum Propeller: Auch mit 9 Frauen dauert ein Kind immer noch 9 Monate. Es sind zwar 8 COG mit 20 MIPS, aber abtasten müsste es ein einziger und 13Mbps zu verdauen ist nicht da m.E. drin.
@ Santiago m. H. (mausschubser) >Hm - weiß ich nicht, was ich darauf antworten soll. Ich denke, mit SPI >könnte man es verarbeiten. Die Antwort hat exakt 0 (Null) Wert. >und wie sieht es mit Einarbeitung in CPLD aus? Dürfte nicht unerheblich >sein, oder täusche ich mich da? Ja, das dauert. >Worin unterscheiden die sich? Also wenn I2S asynchron ist und SPI >synchron, dann sind es synchrone Daten. Sag doch mal GENAU, was du machen willst! MFG Falk
der Vergleich mit den Frauen hinkt ein bischen, man könnte es nämlich auch so programmieren, das wenn Core 1 die Daten eingelesen hat und am Verarbeiten ist, man mit dem 2ten Core schon wieder neue Daten einließt, und wenn dieser am Verarbeiten ist mit Core Nr. 3 Daten einlesen. 9 Frauen schaffen also 9 Kinder in 9 Monaten und übertreffen die eine Frau um das 9fache. Durch geschickte Aufgabenverteilung kann man also noch ne Menge rausholen, Schade das es keine AVRs mit mehreren Kernen, mit getrennte Register usw gibt.
@Thomas O. (kosmos) >rausholen, Schade das es keine AVRs mit mehreren Kernen, mit getrennte >Register usw gibt. Die AVRs sind aus kernig ! ;-) MFG Falk
Thomas O. wrote: > der Vergleich mit den Frauen hinkt ein bischen, man könnte es nämlich > auch so programmieren, das wenn Core 1 die Daten eingelesen hat Klar doch. Vorausgesetzt es gelingt dir, ein 13MHz Signal mit einem einzigen 20 MIPS COG ohne jede Unterstützung durch spezielle Hardware einzulesen. Und eben dies bezweifle ich. Anders sieht es natürlich aus, wenn du es schaffst, das erste Bit mit COG#1, das zweite mit COG#2, ... ;-)
Hallo, > Die Antwort hat exakt 0 (Null) Wert. Sorry, aber genauso ging es mir mit der Frage. Solange man nichts über den Dateninhalt wissen will, geht es doch nur noch um die Frage, ob die Daten von einem Taktsignal begleitet werden oder nicht. Bei meiner Anwendung wäre das der Fall. > Sag doch mal GENAU, was du machen willst! Beitrag "Suche Mentor für Entwicklung eines Audio-Messwert-Erfassers" > Zum Propeller: Auch mit 9 Frauen dauert ein Kind immer noch 9 Monate. Es > sind zwar 8 COG mit 20 MIPS, aber abtasten müsste es ein einziger und > 13Mbps zu verdauen ist nicht da m.E. drin. Die schrieben was von 80 MHz - aber gut, wenn die ähnlich wie bei einem ARM verteilt werden, bleibt natürlich nix mehr überig. Jetzt seid Ihr alle auf die Frauen und Propellors eingestiegen, aber zu dem AT89C51RE2 hat niemand was geschrieben. Ist der zu unbekannt? ... oder ist das Kwatsch, was ich geschrieben habe? Gleiches gilt natürlich für den AVR32 ... Also wenn der 51er die Bits entsprechend schnell einlesen könnte, wäre ich damit schon ein ganzes Stück weiter. So wie ich gelesen habe, könnte ich den Wiz5300 mit 16Bit Breite bedienen, da sollte also auch was gehen. Bleibt noch die Frage, sind 60 MHz bei einem 8051er vergleichbar mit 60MHz (theoretisch - ich weiß, dass es die nicht gibt) bei einem ATmega? Gruß Santi
@Santiago m. H. (mausschubser) >> Sag doch mal GENAU, was du machen willst! >Beitrag "Suche Mentor für Entwicklung eines Audio-Messwert-Erfassers" Jaja, deine Vision. Und wie speilen dann die 13 MHz rein? USB? >... oder ist das Kwatsch, was ich geschrieben habe? Ähhhh, wenn du so fragst . . . >Bleibt noch die Frage, sind 60 MHz bei einem 8051er vergleichbar mit >60MHz (theoretisch - ich weiß, dass es die nicht gibt) bei einem ATmega? Kann sein, muss nicht. Es gibt RISC-artige 8051er, die sind den AVRs ähnlich. Und nochmal, sag lieber, WAS du iM WESENTLICHEN machen willst, und NICHT, wie du glaubst irgendwelche Detail lösen zu wollen. MFG falk
@ Santiago m. H. Es sollte mit eimem Schieberegister oder einer anderen Hardware auf parallel gewandelt werden. 13MHz/8 = 1,625MHz Clocksignal vorhanden -> syncrone Übertragung (SPI, I2C...) Kein Clocksignal -> asyncron (RS232, RS485, USB ...) Die syncrone Übertragung kann zwischendurch anhalten ohne Datenverlust. Beim Standard 8051 wird der Oszillator erst mal durch 12 geteilt und dann werden etwa die Hälfte der Befehle in einem Takt ausgeführt. Er besitzt sehr wenige Register und die meisten Aktionen müssen über den Akku laufen. Es gibt neuere Derivate, bei welchen der Oszillatortakt /4 bzw. /3 geteilt wird. Wichtig finde ich auch, mindestens 2 Adresspointer zur Verfügung zu haben. Ein Pointer zeigt auf den zu lesenden I/O, der zweite auf die Adresse im RAM. Sonst muss zwischen jedem Schreib/Lesezugriff noch die Adresse im Pointerregister getauscht werden. Der AT89C51RE2 hat 128kByte internes RAM und 2 Adresspointer. Das kann nur mit Bankumschaltung und z.B. Dem Keil Compiler genutzt werden. Bei einmaligem Bankumschalten (x µs) sind bestimmt schon 2 Bytes futsch. High Speed Mode: 6 Clocks/Machine Cycle
Hm, also ich versteh nicht, wieso du das nicht in einem kleinen FPGA erledigen willst. Da gibts fertige Cores für I2S Schnittstelle. Die liefern dir die Daten parallel, muss man nur noch in ein (im FPGA integriertes) FIFO schreiben und kann man vom µC dann problemlos auslesen. Obwohl dann halt 1,65 MByte/s immer noch recht viel sind für einen µC. Interessant wäre zu wissen, ob das Ding kontinuierlich über Stunden aufzeichnen soll, oder ob immer mal eine Messung mit x Sekunden/Minuten gemacht wird. Wenn das kontinuierlich werden soll, wirst du an einem schnellen ARM o.ä., der die Daten vom FPGA holt nicht vorbei kommen. Oder du lässt den FPGA gleich auf einen großen RAM schreiben, Mobile SDRAM oder sowas, da kannst du ja einige GByte speichern, wenn es erforderlich ist.
Hallo, > Es sollte mit eimem Schieberegister oder einer anderen Hardware auf > parallel gewandelt werden. 13MHz/8 = 1,625MHz Hey, das ist doch mal ein genialer Tip! - Auf die Idee wäre ich jetzt garnicht gekommen. Aber klar, so läßt sich das Ganze vielleicht sogar mit einem Mega verarbeiten... Ich danke Dir!!! Gibt es jetzt noch einen Baustein, der aus einem Pin-Change einen Rechteckpuls machen könnte (dann könnte ich das Kanalwechselsignal als RCK für einen 74HC595er nehmen). Hey, ich bin völlig off socks, begeistert, und ... :D > Hm, also ich versteh nicht, wieso du das nicht in einem kleinen FPGA > erledigen willst. Nun, "eigentlich" bin ich nur ein PC-Programmierer - fernab von jeder HW. Ich habe mich zwar schon in Einiges etwas einarbeiten können, trotzdem habe ich weiterhin so gut wie keine Ahnung von den harten Fakten. ... und ich denke, dass ein allgemeines HW-Verständnis nicht schadet, wenn man sich mit FPGAs beschäftigen will.
> Es gibt neuere Derivate, bei welchen der Oszillatortakt /4 bzw. /3 > geteilt wird. Wichtig finde ich auch, mindestens 2 Adresspointer zur > Verfügung zu haben. Ein Pointer zeigt auf den zu lesenden I/O, der > zweite auf die Adresse im RAM. Sonst muss zwischen jedem > Schreib/Lesezugriff noch die Adresse im Pointerregister getauscht > werden. Diese Derivate müssen dann aber schon "etwas" älter sein ;-) Bspw. gilt bei den 8051er von SiLabs Maschinenzyklen = Taktzyklen. Allerdings haben die keinen zweiten DP, dafür gibt's bei einigen eine MAC-Einheit. Derivate die mit bis zu 100 MHz laufen sind z.B. F12x, F13x, F36x. Controller mit wirklich flexiblen IOs gibt's z.B. von Imsys oder XMOS.
>> Es sollte mit eimem Schieberegister oder einer anderen Hardware auf >> parallel gewandelt werden. 13MHz/8 = 1,625MHz >Hey, das ist doch mal ein genialer Tip! - Auf die Idee wäre ich jetzt Machen das gewöhnliche serielle Schnittstellen nicht sowieso, wenn die alle nötigen Bits eingelesen haben? D.h., der empfangene Bitstrom wird doch sowieso intern in einzelne Bytes umgewandelt, und wenn fertig mit einem Byte, gibts'n Interuptus.
Hm, also wenn deine Elektronik-Kenntnisse so gering sind, dass du nicht auf die Idee gekommen wärst, ein Schiebregister (was für serielle Daten immer verwendet wird) einzusetzen, dann würde ich kühn behaupten, dass das Projekt eine Nummer zu groß für deinen derzeitigen Kenntnisstand ist. Aber gut, wenn du viel Zeit hast, dann mach mal, da lernst du sicherlich eine Menge dabei.
Hallo, > Hm, also wenn deine Elektronik-Kenntnisse so gering sind, dass du nicht > auf die Idee gekommen wärst, ein Schiebregister (was für serielle Daten > immer verwendet wird) einzusetzen, dann würde ich kühn behaupten, dass > das Projekt eine Nummer zu groß für deinen derzeitigen Kenntnisstand > ist. Hm, das ist keine kühne Behauptung, sondern eine Tatsache. Aber wie heißt es doch in der asiatischen Weisheit: auch der weiteste Weg fängt mit dem ersten Schritt an. Das Schieberegister verwendet werden, war mir schon klar, ich habe die Teile ja auch schon für Segmentanzeigen und LCD verwendet, aber so ein Teil im Eingangsbereich zu verwenden - nun ja, da stand ich wohl auf der Leitung. > Controller mit wirklich flexiblen IOs gibt's z.B. von Imsys oder XMOS. Whow - das sind Teile - aber mit BGA kann ich nicht. > Machen das gewöhnliche serielle Schnittstellen nicht sowieso, wenn die > alle nötigen Bits eingelesen haben? Klar, aber z.B. bei Atmel heißt es, dass SPI max. mit Sysclock/2 gelesen werden kann (was imho auch einleuchtet), also bei 20MHz Teilen heißt das, dass die seriellen Daten max. 10 MHz Takt haben dürfen. Da hilft es ungemein, einen 74HC595 zu nehmen, der auch noch mit 50 MHz getaktet werden darf. Mit dem Pin-Change war ich auf der falschen Spur, der kommt zu spät. Könnte ich den Bytewechsel auch mit einem zusätzlichen Schieber triggern? Ich stelle mir das so vor, dass ich den Takt auf ein zusätzliches Schieberegister lege und den Dateneingang des Registers mit seinem eigenen Überlauf verbinde. Zusätzlich verbinde ich den Eingang mit einem Pin des µCs. Der Datenpin wird mit 1 initialisiert. Wenn der serielle Takt anfängt, schalte ich den Pin um auf Eingang. Nach 8 Takten müsste dann die 1 am Überlauf ankommen und somit am Eingang wieder neu reinlaufen - und ich hätte am µC-Pin einen Byte-Trigger. Lassen sich die Bausteine so verbinden, oder bekomme ich da Kurzschlussprobleme o.ä.?
Angehängte Dateien:
-
SIPO-Input.png
6 KB
Hallo, ich habe meine Idee mit den beiden Schieberegistern mal in einen Schaltplan gezeichnet. Die Stecker High und Low zusammen ergeben einen Eingangsport. Pin 3 des Control-Steckers wird High initialisiert, Pin 1 kommt an einen Pin-Change Interrupt. Wenn der Interupt von Pin 1 zuschlägt, gehe ich davon aus, dass die Daten kommen und schalte den Pin 3 um auf Eingang. Könnte das so klappen, dass durch das Schieberegister IC2 zyklisch der Byte-Trigger für IC1 und den µC kommen, oder habe ich einen Denkfehler? Gruß Santi
@Santiago m. H. (mausschubser) >Könnte das so klappen, dass durch das Schieberegister IC2 zyklisch der >Byte-Trigger für IC1 und den µC kommen, oder habe ich einen Denkfehler? Der Ansatz ist richtig, die praktische Ausführung, ähhhh, ausbaufähig ;-) MFG Falk
Wiso verwendest du eigentlich keinen µC mit Hardware I2S? Viele dsPICs haben sowas und mit 40MIPs Rechenleistung und DMA werden die sich sicherlich langweilen. Auch andere DSPs sollten I2S haben.
Hallo, > Der Ansatz ist richtig, die praktische Ausführung, ähhhh, ausbaufähig > ;-) Wenn Du mir jetzt noch schreiben würdest, was suboptimal ist, dann könnte ich von Deinem Beitrag sogar noch was lernen :) > Wiso verwendest du eigentlich keinen µC mit Hardware I2S? Mangels besseren Wissens? Nachdem, was ich so über PICs im Vergleich zu AVRs las, kommen die PICs nicht gut weg dabei. So habe ich mit AVRs angefangen und PICs nicht weiter beachtet. Wenn Du jetzt meinst, dass ein PIC für die konkrete Aufgabe besser geeignet wäre - ok, warum nicht? Bislang bekam ich eher Hinweise, was nicht geht. Wenn Du mir noch einen Tip zu einem konkreten Modell hättest, würde mich das sehr freuen. Gruß Santi
Santiago m. H. wrote: > Wenn Du jetzt meinst, dass ein PIC für die konkrete Aufgabe besser > geeignet wäre - ok, warum nicht? Ich meine nicht PIC, sondern dsPIC. Das ist eine komplett andere Familie an µC. Welchen du verwendest hängt davon ab, was du alles mit den Daten vorhast. Es gibt die ältere dsPIC30Fxxxx Serie, die mit 5V und maximal 30MIPS läuft (und so heiß wird, dass man sich die Finger daran verbrennt, habe gerade einen mit 80°C Gehäusetemperatur am Laufen), und die neueren 33Fxxx die mit 3,3V laufen und 40MIPS schnell sind. Diese haben mehr Features (z.B. DMA), sind ansonsten Codekompatibel zu den 30ern. Und dann gibt es noch jeweils 2 Untertypen, die Motor Controll Serien und die General Purpose Reihe. Letztere ist für dich interessant. Alle dsPICs die ein DCI (data converter interface) haben, können I2S. Im Vergleich zu AVRs sind die aber ziemlich unschön zu programmieren, da die Datenblätter teilweise unvollständig sind. Die restlichen Infos muss man aus AppNotes, Beispielcodes usw. zusammensuchen. Außerdem scheinen da ab und zu Fehler in den Datenblättern oder AppNotes zu sein. Ich habe zwar immer noch nicht verstanden, was du eigentlich vorhast, aber ich behaupte einfach mal mit den dsPICs geht das.
Hallo Benedikt, dank Dir für die wertvolle Info. Habe eine Familienübersicht gefunden und ich tendiere zu dem dsPIC33FJ256GP510 Also die Beschreibung der Chips klingt erst mal genau so wie Du es sagtest: genau das was ich bräuchte. Bleibt noch die Frage, gibt es einen freien C-Compiler für die Steinchen? ... und gibt es bei den dsPICs auch sowas wie ISP bei den AVRs? > Ich habe zwar immer noch nicht verstanden, was du eigentlich vorhast Hm, ist mein Vorhaben so absurd? Mein "must-have" wäre ein teilweise ein mobiler Datenlogger - und - mein "nice2have" wäre eine halbe Soundkarte, die die Eingangsdaten als Audio-Stream im Netzwerk anbietet. Details können im Beitrag "Re: Suche Mentor für Entwicklung eines Audio-Messwert-Erfassers" nachgelesen werden. Gruß Santi
Wenn wir jetzt schon bei dsPICs sind, würde ich eher etwas anderes vorschlagen, insbesondere wenn's später auch netzwerkfähig oder vllt HiSpeed-USB haben soll: http://www.cyantechnology.com/support/USB_Ethernet_Devkit.php Die Controller haben neben Ethernet, USB auch I2S onboard.
Hallo, > Wenn wir jetzt schon bei dsPICs sind, würde ich eher etwas anderes > vorschlagen, Hm, die kleineren machen "nur" 24, bwz. 25MHz, dürften damit wohl kaum schnell genug sein. Bliebe nur der "fette" mit 70MHz. Dem würde ich das schon zutrauen, bliebe aber die gleiche Frage wie bei den dsPICs: Mit was kann ich den programmieren, bzw. gibt es einen freien C-Compiler und wie bekomme ich die Firmware in den Chip. So gesehen gefällt mir die Variante mit den Schieberegistern immer noch sehr. Bei den AVRs fühle ich mich schon fast zuhause und einen Wiz5300 anzusteuern traue ich mir auch noch zu. Mit dem mega644-20 könnte ich z.B. einen 2kanal Doppelpuffer aufbauen. Damit sollte die Datenrate in den Griff zu bekommen sein. Gibt es für den Byte-Trigger eine einfachere/bessere Variante, als die von mir oben vorgeschlagene? Gibt es sowas wie einen 3Bit Zähler o.ä. oder wie könnte ich noch den Byte-Takt aus dem Bit-Takt bekommen?
Angehängte Dateien:
-
SIPO-Input.png
8,4 KB
Hallo, ich glaube, ich bin selber fündig geworden. Könntet Ihr bitte mal die Schaltung begutachten/kritisieren? Gruß Santi
Santiago m. H. wrote: > Bleibt noch die Frage, gibt es einen freien C-Compiler für die > Steinchen? GCC. Von Microchip. Allerdings haben die es geschafft, diesen wider dem Geist der FSF so zu kastrieren, dass man für bessere Optimierung zahlen muss, indem dann ein separates proprietäres Programm eingeschleift wird. Und das eben kostet. Geht aber auch ohne Dollars, wenn man mit -O1 oder so zufrieden ist. Oder es schafft, den Sourcecode selber zu übersetzen. > ... und gibt es bei den dsPICs auch sowas wie ISP bei den AVRs? Yep, läuft ähnlich ab. Erinnert allerdings eher an das serielle HVP der 8pin Tinys und anders als Atmel hat Microchip sich dabei so dämlich angestellt, dass die beiden Programmierpins bisweilen nur eingeschränkt für die Anwendung zur Verügung stehen. Manche der Programmer für die PIC16/18 sind auch für die PIC30/24/33 zu gebrauchen. Siehe sprut.de. Und ICD2-Klone gibt's recht günstig, damit ist dann auch Debugging möglich.
Ach ja: Bei Microchip generell aber besonders bei den 16bit PICs sollte man sich das jeweilige Errata-Sheet ansehen. Da sind so manche dollen Klöpse drin. Das ist zwar anderswo (ARM&Co) auch so, aber wer bisher nur AVR gewohnt war, der könnte sich verwundert die Augen reiben. Aber um auch mal was positives über Microchip loszuwerden: Deren Support im Web ist recht gut. Frage/Antwort-Spielchen bei Problemen mit Hard- und Software funktionierte, obwohl ich keine 10000-er Charge geordert hatte, und das war auch noch schnell.
Andreas Kaiser wrote: > GCC. Von Microchip. Allerdings haben die es geschafft, diesen wider dem > Geist der FSF so zu kastrieren, dass man für bessere Optimierung zahlen > muss, indem dann ein separates proprietäres Programm eingeschleift wird. > Und das eben kostet. Geht aber auch ohne Dollars, wenn man mit -O1 oder > so zufrieden ist. Oder es schafft, den Sourcecode selber zu übersetzen. So steht das zumindest auf der Microchipseite. Allerdings erhalte ich unterschiedliche Codegrößen, wenn ich zwischen o0, o1, o2 und oS umschalte. Keine Ahnung was die wirklich da eingebaut haben. Auf jedenfall optimiert der Compiler ziemlich gut.
Der propietäre Optimizer macht meiner Erinnerung nach im Wesentlichen den gleichen Zirkus wie beim C18: Er erkennt mehrfach auftretende identische Befehlssequenzen und macht winzige Unterprogramme draus. Zeit spart das nicht, im Gegenteil, aber etwas Platz. Wobei der ja auch erst nach ein paar Monaten kostenpflichtig wird.
Andreas Kaiser wrote: > Der propietäre Optimizer macht meiner Erinnerung nach im Wesentlichen > den gleichen Zirkus wie beim C18: Er erkennt mehrfach auftretende > identische Befehlssequenzen und macht winzige Unterprogramme draus. Zeit > spart das nicht, im Gegenteil, aber etwas Platz. Kann ich eigentlich nicht bestätigen. Ich schau mir eigentlich regelmäßig den erzeugten Code an, sowas wäre mir aufgefallen. o2 und os sind meiner Meinung nach in etwa gleichwertig, und erzeugen den schnellsten und kleinsten Code. Schneller geht es nur noch in Assembler mittels der DSP Befehle.
Probier mal "-mpa". Die Doku sagt übrigens, dass alles ausser -O0 und -O1 Geld kostet. Aber der Code ist ok, keine Frage, und auch bei -O1 schon gut zu gebrauchen.
Andreas Kaiser wrote: > Aber der Code ist ok, keine Frage, und auch bei -O1 schon gut zu > gebrauchen. Ja, eindeutig. Nur o0 erzeugt viel unnötigen Code (und auch o3).
Santiago m. H. wrote:
> Ich habe jetzt einiges über Vergleiche der Professoren gelesen, aber
Der Mikroprofessoren nehme ich an ;-).
Andreas Kaiser wrote: > Santiago m. H. wrote: > >> Ich habe jetzt einiges über Vergleiche der Professoren gelesen, aber > > Der Mikroprofessoren nehme ich an ;-). Den gibts wirklich: http://www.sbprojects.com/projects/mpf1/mpf1.htm
Hallo, ich muss Abbitte leisten. War mal wieder zu oberflächlich. Nachdem Benedikt schrieb, dass dsPICs was anderes als PICs sind, bin ich nicht auf die Idee gekommen, dass die die gleiche Mutter haben könnten. > GCC. Von Microchip. Oups - d.h. man muss den nehmen? "Frei" verfügbar gibt es keinen? > Manche der Programmer für die PIC16/18 sind auch für die PIC30/24/33 zu > gebrauchen. Siehe sprut.de. Sprut kenne ich - aber da es für mich 2 paar Stiefel waren, bin ich nicht auf die Idee eines Zusammenhanges gekommen. > Kann ich eigentlich nicht bestätigen. Ich schau mir eigentlich > regelmäßig den erzeugten Code an, sowas wäre mir aufgefallen. o2 und os > sind meiner Meinung nach in etwa gleichwertig, und erzeugen den > schnellsten und kleinsten Code. Na das macht doch Mut. Dann werde ich doch mal einen Abstecher in die Welt der rosa Glücksbringer waagen ;) >>> Ich habe jetzt einiges über Vergleiche der Professoren gelesen, aber >> >> Der Mikroprofessoren nehme ich an ;-). > > Den gibts wirklich: http://www.sbprojects.com/projects/mpf1/mpf1.htm LOL - das ist mal ein gelungener Einstieg in den Feierabend :D Danke Euch! Gruß Santi
Santiago m. H. wrote:
> Oups - d.h. man muss den nehmen? "Frei" verfügbar gibt es keinen?
Frei verfügbar ist der C30 mindestens nichtkommerziell ja schon, mitsamt
IDE, Simulator und In-Circuit-Debugger (d.h. die Software dazu) - was
willst du mehr?
Und da das der GCC ist, kannst du dir jederzeit bei Microchip die
Quellen besorgen und übersetzen. Das ist dann noch ein bischen freier
und dafür ein bischen umständlicher.
Aber du kannst auch bei den üblichen Verdächtigen nachsehen, IAR hat
bestimmt auch was. Frei bis 4KB oder so. Jenseits davon dann ein kleines
Auto.
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.