www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Vergleich der µCs nach IO-Performance


Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe gerade mal gelesen, was es mit dem "Propeller" auf sich hat:
Der Propeller Chip enthält acht 32-Bit CPU-Kerne.
Jeder dieser Kerne (COGs) verfügt über 2KB (512 Langworte) RAM 
und alle COGs haben Zugriff auf den gemeinsamen 32KB großen HUB RAM Bereich. 
Allerdings kann ein COG nur Code im eigenen COG RAM abarbeiten, 
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 :)

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas O. (kosmos)

>rausholen, Schade das es keine AVRs mit mehreren Kernen, mit getrennte
>Register usw gibt.

Die AVRs sind aus kernig ! ;-)

MFG
Falk

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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, ... ;-)

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
natürlich Kerne

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: B e r n d W. (smiley46)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Jens G. (jensig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.ä.?

Autor: Santiago m. H. (mausschubser)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
Die Controller haben neben Ethernet, USB auch I2S onboard.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Santiago m. H. (mausschubser)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich glaube, ich bin selber fündig geworden.
Könntet Ihr bitte mal die Schaltung begutachten/kritisieren?

Gruß Santi

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Santiago m. H. wrote:

> Ich habe jetzt einiges über Vergleiche der Professoren gelesen, aber

Der Mikroprofessoren nehme ich an ;-).

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.