schneller als 20MHz - was nehmen? PC oder ARM?

Hallo devBoard,

also von der Rechenpower ist die PC basierte Variante wohl die bessere. 
Wenn es dir aber wie bei einem µC auf die I/O's ankommt ist das 
natürlich etwas anderes. Bei der PC Schiene hat man einiges an Overhead 
dabei und muss sich mit Dingen aus dem OS rumschlagen. Da ist es oft 
auch egal ob Linux, Windows oder DOS. API's, Kernel und Prozesse 
managen...

Die Entscheidung sollte man von genauen Anwendungsfall abhängig machen. 
Ich selbst hab immer noch etliches von der alten PC-Hardware am laufen. 
Und selbst mit FreeDOS kann man einige sehr schöne Dinge, schnell und 
effizient bearbeiten. Dazu hat man noch 'unmengen' an Speicher der 
unterschiedlichen Arten zur Verfügung. Zusatzhardware wie Sound, Grafik, 
Netzwerk und Massenspeicher etc.

Spricht also einiges dafür und auch etwas dagegen, wie auch immer. Ich 
würde diese Aufgabe erstmal mit einer PC Lösung angehen. Als OS dann 
FreeDOS oder Linux wählen.

Viel Erfolg
Rene

Hallo, in den 'guten alten' Zeiten von DOS hat man das mit dem 
dazwischen funken noch ordentlich in den Griff bekommen. Die Probleme 
kammen ja erst später ;-)

Schon klar, wenn du kein OS auf deinem System hast, hast du auch keinen 
Stress damit. Allerdings must du dann auch alles selber bauen und 
managen. Und das könnte ganz schön stressig werden.

Ist aber auf jeden Fall ein ?fauler? Kompromiss. Der Aufwand dürfte aber 
auf der PC-Schiene erstmal geringer sein. Freie, kostenlose Compiler, 
Debugger und Trace-Tools etc. Viel Doku und natürlich die Hardware.

Nimm erstmal ein altes Mainboard mit ein bisschen gedoens drum herum. 
Später kann das auf ein schönes Embedded-PC Modul (z.Bsp.: Pep Modular 
Computers GmbH) drauf. Ich arbeite mit mehreren 'alten' CP30x. Hab damit 
sehr gute Erfahrungen gemacht.

devBoard schrieb:
> Hallo Leute,
>
> ich bastele viel mit ATMega's. Bei manchen Projekten sind die 20MHz zu
> wenig, also orientiert man sich nach oben:
>
> XMegas oder ARMs: Da brauche ich neue Programmer, Dev.-Boards etc.
>
> Also warum nicht güstige PC-Mainboards mit mini-minimalkonfiguration und
> ein mini-Linux? So Tastaturen und Monitor hat man sowieso..
>
> Mir geht es echt um die Kosten so als Bastler. Mir ist schon klar, daß
> ein Mainboard mehr Platz braucht und für die eine Serienfertigung
> wahrscheinlich viel teurer ist als ein einzelner Chip, der die spezielle
> Aufgabe auch kann, aber als Bastler von Unikaten stört das nicht.
>
> Als Beispiel (Audio): angenommen, ich möchte 6 Spuren Stereo-PCM mit je
> 16 bit aufnehmen - die Datenrate dafür schafft auch kein XMega mehr und
> keine sd oder cf-Karte...

6  2  16-Bit * 48000 Hz = 1.152 MByte/s
Ginge also mit jeder SD und CF-Karte (teilweise werden bei CF >50 
MBytes/s dauerhafte Schreibleistung garantiert (und eingehalten)) und 
jedem XMega (das Teil läuft mit 32 MHz und hat einen DMA-Controller, ihm 
fehlt I2S o.ä. damit es wirklich einfach wäre)

> Also ARM/ mehrere parallel / mit mehreren Karten oder gleich einen
> "quasi-PC" nehmen? Was sind die Vor- und Nachteile, was meint Ihr? Was
> gibt es so für Mini-PCs, die Ihr gerne nutzt?

Für sowas, gar keinen. Ansonsten gibt's haufenweise Mini-ITX, PC/104-PCs 
mit allen möglichen CPUs, Speicher, Grafik, Netzwerk-Kombinationen 
(könnte allerdings schwer werden, ein Mainboard in der Größe mit mehr 
als zwei Audio-Eingängen zu finden). Ob das ganze dann noch günstiger 
ist als bspw ein Zoom R16 oder ein entsprechend aufgerüstetes Netbook, 
dürfte fraglich sein.

Hallo, das dürfte dann etwas schwierig werden;

devBoard schrieb:
> Vielleicht geht es ja auch so: Ich schalte im BIOS alle Störenfriede aus
> und lasse den "PC" von einer SD-Karte "booten" - dorthin tue ich dann
> auch mein Anwendungsprogramm - dann könnte ich das doch direkt laufen
> lassen, ganz ohne OS, oder? Müßte mir natürlich alle I/O-Zugriffe selber
> organisieren..

Wenn du alle Störenfriede deaktivierst, z.Bsp. System-Timer wirst du 
nicht weit kommen.

Was willst du von SD-Card booten wenn du kein OS drauf haben willst?

Und alle I/O's selber organisieren??? Bei Audio mit mehreren Spuren und 
schnellem Datentransfer? Das wird echter Stress.

Guck mal bei http://kontron.de die Embedded-Module. Da hast du fast 
alles selber in der Hand, ein schlankes OS (wieder ein DOS) drauf und 
los gehts.

mfg Rene

Selbst wenn man PC-Hardware ohne Betriebssystem laufen lässt, ist sie 
aufgrund ihrer Architektur für viele Aufgaben ungeeignet. Trotz des sehr 
hohen Systemtakts sind an den einfach zugänglichen I/O-Schnittstellen 
keine besonders hohen Datendurchsätze zu erzielen; per Bit-Banging kann 
ein PC trotz etlicher GHz Systemtakt auf dem Parallelport bestenfalls 
mit 1 bis 2 MHz herummachen. Das liegt an der Systemgeschichte, die den 
mit Resten des ISA-Busses ansteuert.

Der Anschluss ernster gemeinter Peripherie über Schnittstellen wie I2C 
oder SPI scheitert bereits an diesem Problem.

Also müsste man anfangen, PCI-Karten für derlei Anforderungen zu bauen, 
aber das ist nichttrivial.

So aber kann PC-Hardware schön schnell rechnen, aber sie kann Daten nur 
sehr eingeschränkt übertragen oder empfangen, geschweige denn schnell 
auf externe Ereignisse reagieren, weil die Schnittstellen fehlen und nur 
sehr aufwendig nachzurüsten sind.

Hinzu kommt, daß PC-Hardware im Stromverbrauch gleich mehrere 
Größenordnungen oberhalb von sonstiger Embedded-Controller-Hardware 
liegt.

devBoard schrieb:
> angenommen, ich möchte 6 Spuren Stereo-PCM mit je
> 16 bit aufnehmen - die Datenrate dafür schafft auch kein XMega mehr und
> keine sd oder cf-Karte...

Ich habe momentan ein ähnliches Projekt in Planung:
8 Monokanäle mit 192kHz und 24Bit, welche seriell ankommen (TDM), auf 
eine CF-Karte schreiben (Wurde hier ja schon erwähnt, daß das locker 
klappt), zur selben Zeit aber auch von der selben CF-Karte nochmal die 
selbe Menge an Daten lesen und wieder via TDM auszugeben. Desweiteren 
wäre die Möglichkeit, die gelesenen Daten mit den empfangenen Daten zu 
vermischen (keine Addition, nur einzelne Kanäle anstelle empfangener 
Kanäle verwenden)

Eine zufriedenstellende Lösung habe ich noch nicht. Ein PC ist dafür 
allerdings zu groß - auch was den Stromverbrauch angeht.
Derzeit hat dieses Projekt aber auch keine Priorität, weshalb ich im 
Moment auch nicht weiter suche. Von Deinen Erfahrungen zu hören, würde 
mich aber freuen!


Gruß

Jobst

evtl ein kleines FPGA. Das hat dann auch noch Leistungskapazitäten die 
Signale bei bedarf zu bearbeiten.

FPGAs habe ich auch schon gesucht, habe aber kein passendes gefunden.

Voraussetzungen wären:
- Kein BGA-Gehäuse o.ä., max. QFP144 (0.5mm Raster)
- >2kB RAM
- Offene Dokumentation des Programmdatenstroms

Sehr viel habe ich mich mit den Dingern noch nicht auseinandergesetzt, 
aber das sind die Punkte, wo ich immer angeeckt bin. Evtl. hat ja jemand 
einen Tip.


Gruß

Jobst

Och, da kann ich cool bleiben. Da habe ich schon einige Jährchen an 
Erfahrung. Vorzeigen brauche ich das auch nicht, ich weiß was ich kann. 
Wenn mir das wer nicht glaubt, dann ist das sein Problem, nicht meins.


Gruß

Jobst

@  Jobst M. (jobstens-de)

>8 Monokanäle mit 192kHz und 24Bit, welche seriell ankommen (TDM), auf
>eine CF-Karte schreiben (Wurde hier ja schon erwähnt, daß das locker

Macht 8x192kx3 = 4,6 MByte/s. Not bad.

>klappt), zur selben Zeit aber auch von der selben CF-Karte nochmal die
>selbe Menge an Daten lesen und wieder via TDM auszugeben.

Macht in Summe ~9 Mbyte/s. Sportlich, aber machbar denke ich. Das auf 
nehmen und ausgeben ist für ein FPGA ein Klacks.

> Desweiteren
>wäre die Möglichkeit, die gelesenen Daten mit den empfangenen Daten zu
>vermischen (keine Addition, nur einzelne Kanäle anstelle empfangener
>Kanäle verwenden)

Trivial.

>Eine zufriedenstellende Lösung habe ich noch nicht. Ein PC ist dafür
>allerdings zu groß - auch was den Stromverbrauch angeht.

FPGA, selbst die kleinsten Spartan3 reichen.

>FPGAs habe ich auch schon gesucht, habe aber kein passendes gefunden.

>Voraussetzungen wären:
>- Kein BGA-Gehäuse o.ä., max. QFP144 (0.5mm Raster)
>- >2kB RAM

Hat jeder Spartan3 (Xilinx) oder Cyclone I oder II (Altera)

>-> Offene Dokumentation des Programmdatenstroms

Wirst du von keinem Hersteller bekommen. Ist auch vollkommen 
uninterresant.

MFG
Falk

Falk Brunner schrieb:
>>-> Offene Dokumentation des Programmdatenstroms
>
> Wirst du von keinem Hersteller bekommen. Ist auch vollkommen
> uninterresant

Finde ich etwas arm, daß das so ist. Aber es ist absolutes 
Ausschlusskriterium. Wieso das uninteressant sein soll, ist mir ein 
Rätsel. Nur weil es ohne Kenntnis auch funktioniert, ist für mich noch 
lange kein Argument.


Gruß

Jobst

Olaf schrieb:
> Was willst du denn mit der Information anfangen? Die braeuchte man doch
> nur wenn man selber einen Verilog-Compiler fuer sein FPGA schreiben
> wollte.
>
> Olaf

Vielleicht.

Vielleicht soll es ja auch gar kein Verilog sein.

Vielleicht will ich die Möglichkeit haben, den Datenstrom von einem uC 
selber erstellen zu lassen.

Aber auf jeden Fall will ich wissen, wie das Teil funktioniert - und 
zwar komplett.
Und geschlossene Funktionsprinzipien möchte ich in meinen Schaltungen 
einfach nicht haben.


Gruß

Jobst

@Jobst M. (jobstens-de)

>Vielleicht will ich die Möglichkeit haben, den Datenstrom von einem uC
>selber erstellen zu lassen.

[ ] Du hast auch nur ansatzweise eine Vorstellung, wie komplex und 
umfangreich so ein Datenstrom und dessen Erzeugung ist.

>Aber auf jeden Fall will ich wissen, wie das Teil funktioniert - und
>zwar komplett.

Sicher, du kaufst auch nur ein Auto, das bis in die letzte Schaube 
dokumentiert ist.
Und du kaufst nur ein Essen im Restaurant, wenn der Chefkoch dir jede 
Zutat haarklein erklärt.

>Und geschlossene Funktionsprinzipien möchte ich in meinen Schaltungen
>einfach nicht haben.

Dream on. Perfektionist.

http://de.wikipedia.org/wiki/Perfektionismus_%28Psychologie%29

MfG
Falk

Ich konstruiere keine Autos und bin auch kein Koch. Du vermischst gerade 
Entwicklung und Anwendung.
Das der Datenstrom umfangreich und komplex ist, ist mir bewusst. Das 
stört mich aber im Gegensatz zu Dir nicht.

> http://de.wikipedia.org/wiki/Perfektionismus_%28Ps...

Das sehe ich erst einmal als Kompliment. :-)


Gruß

Jobst

Ob das ein Kompliment war ist eher zu bezweifeln.

Pascal L. schrieb:
> Ob das ein Kompliment war ist eher zu bezweifeln.

Das ist mir schon klar ... ;-)
Macht aber nix ...


Gruß

Jobst

Ich möchte mal eine ganz andere Lösung vorschlagen. Schau dir zum 
Beispiel mal den Mega168 an, versorge den gut mit 5 Volt und lege 24 Mhz 
an. Das geht laut Datenblatt gut.
Dann versuchst du dich hochzutasten, ich schätze mal bis 30 Mhz wirst du 
mit einem externen treibenden Quarzoszillator kommen. Vorsaussetzung ist 
ultrastabile Spannungsvorsorung, massig Abbblockkondensatoren.
Wenn das nicht mehr reicht, erstmal Quellcode optimieren, notfalls mit 
inline ASM.
Wenn das jetzt nicht mehr reicht, schauste dir mal die AVR32 series an. 
Da biste dann gleich bei 200 MHz gut unterwegs. Aber das würde ich nur 
als Notlösung in Betracht ziehen.

Das kommt drauf an, welche Komponenten man benutzen will. Das EEPROM 
gibt soweit ich weiß als erstes auf.