Embedded Linux und die Verwendung in QRP Geräten

    Das Thema bezieht sich auf ein anderes Thema hier im Forum: "Das nächste Projekt?" - Ab Beitrag 41 wird über die Usability und den Preis solcher Teile diskutiert. Vielleicht auch mal etwas realisiert?


    Zitat

    Interessanter wird die Frage nach AD (oder bei diesem Board unnötig) DA Wandlern.


    Nein. Das wird geradezu langweilig. Soundchips werden normalerweise per I2S oder ähnlichem angesprochen. Zumindest ist das bei Mikrocontrollern so!


    Zitat

    Leider habe ich noch keine riesen Ahnung.. aber falls der 700MHZ ARM es schaffen sollte mit einer Samplefrequenz von fast 1MHZ aus zu kommen (700Khz), dann kann das ganze 20m Band (oder andere) komplett im ARM verarbeitet werden.


    Nein, auch das ist viel zu viel für den ARM. 700khz Bandbreite bei einer halbwegs hohen FFT Auflösung schafft kein ARM! Das schaffen vielleicht gerade mal Quadcore Prozessoren oder FPGA.


    Womit wir beim Thema wären: Ein digitales System hat durch die Fouriertransformation immer eine gewisse Latenz gegenüber den auf die Sprungantwort direkt antwortenden analogen Filtern. Diese Latenz lässt sich durch den Einsatz einer parallelen Implementation und damit einer kürzeren FFT Stage bis auf 1-2 ms herunter drücken, was so ziemlich unhörbar ist. Eine eingebettete CPU hat allerdings nur einen Kern, weshalb hier eine parallele Abarbeitung unmöglich wird. Ich weiß auch nicht, ob die Rechenpower ausreicht um ein halbwegs brauchbares Spektrum hinzubekommen. Bei meinem ExoPC hat es auf jeden Fall nicht gereicht (Atom CPU).


    Weiterhin steht die Usability im Vordergrund. Hierzu empfehle ich euch diesen vortrag vom 28c3. Wer ihn nicht sehen will und nur die Quintessenz möchte: Sobald man einen ARM hat, auf dem ein Linuxsystem läuft, ist die Box offen für Spielereien, die der Support vllt gar nicht will. Auf der anderen Seite hat Linux den großen Vorteil, ein ruhiges Gewässer für andere Programmierer darzustellen: Programme und Scriptspracheninterpreter lassen sich sehr leicht auf ein Linuxsystem portieren und man kann bereits fertige Programme kompillieren und sehr schnell nutzen. Bibliotheken gibt es auch genug.


    Am Ende bleiben also nur zwei Möglichkeiten: Ein eigenes Embedded System zu entwickeln (Sehr kleine Kosten im GGsatz zum BeagleBoard) oder einen FPGA mit DA Wandler dafür herzunehmen (superviel Entwicklungsaufwand!).

    Hallo Nico,



    der Propeller ist absolut nicht geeignet, leider. Die Prozessorkerne, die "Cogs" erhalten nacheinander Zugriff auf den Hauptspeicher. Der RAM ist neben Rechenleistung einer der kritischen Punkte einer FFT. Willst du eine FFT implementieren musst du folgendes tun:


    • Werte Samplen und in den Speicher ablegen
    • Von der Zeit in die Frequenzdomäne springen
    • (Evtl Filter applizieren)
    • Inverse Fouriertransformation über den Frequenzbereich laufen lassen
    • Samples nacheinander an den DA Wandler geben


    Jeder Schritt benötigt einen Puffer, der - ob man es will oder nicht - nur im RAM liegen kann, weil der RAM der einzige Speicher ist, der schnell genug schreiben und lesen kann. Wenn man nun das ganze Sample auf 8 CPU Kerne aufteilt muss jeder Kern mindestens seinen Samplespeicher haben, den Zwischenspeicher für die Fourierkoeffizienten und den Ausgabespeicher. Wenn man einen Filter darauf anwendet kommt noch einer hinzu.


    Nun müssen die Kerne aber immer warten, bis sie wieder an der Reihe sind, was den Vorteil einer Parallelisierung zunichte machen würde.


    Ein anderer Ansatz ist es, eine CPU zu nutzen, die schneller als Echtzeit vom Zeit in den Frequenzbereich umsetzt, Filter appliziert und dann wieder in den Zeitbereich umsetzt. Das ist der Ansatz, der bei "normalen" SDR's benutzt wird: Das eigentliche SDR sampelt nur die Werte und schiebt sie über USB (oder wie der Harzburg: setzt sie in ein IQ Signal um) an den Rechner, der dann mit seinem riesigen Hauptspeicher und der schnellen CPU in "schneller als Echtzeit" (dh mehr Werte/s berechnen kann, also gemessen werden) den Output berechnet. Da stellt sich die Frage, ob der OMAP auf dem Beagleboard schnell genug ist. Vom Raspberry PI wissen wir leider auch noch nichts.

    Hallo Jan!


    Vielen Dank für Deine erläuterne Antwort. DSV haben wir nur im Studium angerissen da das Spektrum da sehr groß ist. Ich habe mich danach auch nicht weiter beschäftigt. Momentan arbeiten wir in meiner Fortbildung noch etwas damit, da aber mehr auf händischen Rechenweg sowie mit Labview.


    In meiner Freizeit arbeite ich mich im Moment in das "Gnublin"-Board ein. Das hat auch einen ARM-Prozessor unter Linux. Aber meiner bescheidenen Meinung nach ist es für DSV gar nicht geeignet. Mann müsste ihm da erst einmal einen DAU und ADU spendieren und diese per SPI oder I²C ansprechen. I²C kann nur maximal 1MBit die Sekunde und für SPI hab ich im Moment keine Daten zur Hand. Also nix mit hoher Datenübertragungsleistung.


    Ein anderer Gedanke wäre es mehrere µC zu nutzen und diese per Dual-Port-RAM zu verbinden. Da wäre aber der Aufwand wahrscheinlich zu groß.


    In diesem Sinne


    73 de Nico
    DD6VFS

    Zitat von dd6vfs


    In meiner Freizeit arbeite ich mich im Moment in das "Gnublin"-Board ein. Das hat auch einen ARM-Prozessor unter Linux. Aber meiner bescheidenen Meinung nach ist es für DSV gar nicht geeignet. Mann müsste ihm da erst einmal einen DAU und ADU spendieren und diese per SPI oder I²C ansprechen. I²C kann nur maximal 1MBit die Sekunde und für SPI hab ich im Moment keine Daten zur Hand. Also nix mit hoher Datenübertragungsleistung.


    Ich habe mich letzte Woche einmal darüber informiert. Aus der Reihe gibt es den LPC3250, den du dir mal angucken könntest: http://www.nxp.com/documents/data_sheet/LPC3220_30_40_50.pdf
    Der wäre wohl schnell genug. Ein dicker Nachteil ist das BGA mit dem er angeschlossen wird. Das macht selbst eine Einmalbestückung unmöglich. Da steigen die Kosten für's bestücken lassen in schwindelerregende Höhen. Vielleicht habe ich aber auch die Möglichkeit, das im Reinraum der Hochschule zu machen. Da steht eine Maschine, mit der Man BGA und wesentlich kleinere Bausteine (die ohne Package) platzieren kann. Da könnte ich mal nachfragen, wenn wir uns auf das festlegen.



    Zitat von dd6vfs


    Ein anderer Gedanke wäre es mehrere µC zu nutzen und diese per Dual-Port-RAM zu verbinden. Da wäre aber der Aufwand wahrscheinlich zu groß.


    Nein, das ist auch wieder unpraktikabel. Der beste Ansatz ist meiner Meinung nach ein einzelner Prozessor, der die komplette FFT macht oder ein FPGA. Wobei ich bei beidem relativ wenig Erfahrung im programmieren habe. Da müsste man sich mit den Softwarejunkies auseinander setzen.


    Auch eine Möglichkeit wäre dieser Chip hier, den man wenigstens noch selbst löten könnte: http://www.youtube.com/watch?v=zY9aEIHem-4
    Das Board selbst ist günstig und ein ADC mit ein paar MSPS lässt sich sicher noch finden. Dazu müsste dann noch eine schnelle UART zum embedded System implementiert werden, was normalerweise kein Problem ist, mit dessen Hilfe dann ein Wasserfalldisplay angesteuert wird.


    Ideen?

    Hallo Jan!

    Zitat von DL8JAN

    Der wäre wohl schnell genug. Ein dicker Nachteil ist das BGA mit dem er angeschlossen wird. Das macht selbst eine Einmalbestückung unmöglich. Da steigen die Kosten für's bestücken lassen in schwindelerregende Höhen.

    Ich denke mal das das mit dem Löten vom BGA weniger das Problem ist, nur brauchst du für das Teil eher eine Mehrlagenleiterplatte. Diese lässt sich nur in großen Stückzahlen zu einem vernünftigen Preis herstellen.


    Zitat von DL8JAN

    Auch eine Möglichkeit wäre dieser Chip hier, den man wenigstens noch selbst löten könnte: http://www.youtube.com/watch?v=zY9aEIHem-4
    Das Board selbst ist günstig und ein ADC mit ein paar MSPS lässt sich sicher noch finden. Dazu müsste dann noch eine schnelle UART zum embedded System implementiert werden, was normalerweise kein Problem ist, mit dessen Hilfe dann ein Wasserfalldisplay angesteuert wird.

    Ein STM-32 wäre schon interessant zumal sich der im LQFP "noch" löten lässt. Das Board ist wirklich günstig ca. (12,60€). Der STM32F407VG hat ja auch sehr vieles nützliches als I/O vorhanden. Ich schaue mir mal heute Abend oder morgen früh die Datenblätter an.


    73 de Nico
    DD6VFS

    Hallo,


    das kam diese Woche über den TI Ticker:


    73 de Uwe
    DC5PI

    Zitat

    ob die Rechenpower ausreicht um ein halbwegs brauchbares Spektrum
    hinzubekommen. Bei meinem ExoPC hat es auf jeden Fall nicht gereicht
    (Atom CPU).

    Äh... welche Software nutzt Du ?
    Also FLDIGI läuft selbst auf dem kastrierten EEEPC 701 (533MHZ).
    SSB habe ich noch nicht getestet..

    Ähmm... genau deswegen würde ich offenes Linux-System Bevorzugen ? Amateurfunk ? Nicht kommerzielle angelegenheit ? Basteln ?
    Bei all den SDR-Zeugs ist basteln nicht mehr nur Hardware, sondern auch Software.
    Eine Technologie, die auch für andere Zwecke (QRL) von nutzen sein kann. Also nichts was nur den reinen Zeitvertreib darstellt.
    1920 war es noch so, das Amaterfunk gerade mal war : 3 Röhren unter misachtung sämtlicher VDE Richtlinien verbauen, und dann mit CW versuchen über den Acker zu kommen (zuvor hat man festgestellt das funkensender zu sehr nerven)
    Heute ist das Feld weiter. Mann kann zwar immer noch Röhren unter Mißachtung sämtlicher Normen verbauen.. aber man kann auch nen DSP + Mosfet einsetzen. Oder ne Kiste kaufen, oder oder oder...
    Auch das mit dem Netzwerk, was um die Jahrundertwende noch händisch gemacht wurde, kann man heute in Technik giesen.


    Und Wenn irgendein Hersteller etwas nicht supporten will, was er nicht verbrochen hat, dann muss er das auch nicht.
    Hash des Images ? Aha.. tut mir leid.. wir supporten nur unveränderte Images..
    Ach.. das Gerät funktioniert wieder, wenn sie unsere originale SD-Karte reinstecken ? Prima ! Dann schönen Tag noch.

    Zitat


    Am Ende bleiben also nur zwei Möglichkeiten: Ein eigenes Embedded System
    zu entwickeln (Sehr kleine Kosten im GGsatz zum BeagleBoard) oder einen
    FPGA mit DA Wandler dafür herzunehmen (superviel Entwicklungsaufwand!).

    Also nachdem D05PI diese netten Chips vorstellte.. musste ich an den Pactor Controller denken :
    CPU + DSP.


    Also erst mal ein ARM Board so hinbiegen, das es die Grundlegenden Dinge für einen HAM kann...
    Damit man schon mal spass hat.
    .. und später nen DSP mit AD/DA Wandler drantütteln.
    Dieser braucht dann auch kein Flash, er bekommt sein Programm immer frisch vom ARM.
    Und der ARM weis auch genau was er von dem DSP will.
    Und der DSP liefert dem ARM dafür, fein zurrechtgeschnittene Rohdaten.. z.B. nen kleinen Audio-Stream, mit SSB oder PSK31 signalen..


    lg JAn

    Hey Jan,



    ich nutze fldigi - Die CPU überhitzt alle paar Minuten und schaltet ab.



    Ich sehe bei einem ARM Board das Problem, dass man die beiden Komponenten später einfach nicht mehr zusammenbringt. Ein direkt auf der HF sampelnder ADC erzeugt einen Datenstrom, der nurnoch mit einem FPGA/DSP gebändigt werden kann. Wenn die höchste Empfangsfrequenz 30 Mhz beträgt, dann muss mit mindestens 60MSPS gesampelt werden (Nyquist - Shannon Theorem) das macht 60M Werte bei beispielsweise 14bit Auflösung -> 100MB/s. Nicht falsch verstehen, mich macht das als Funkamateur total heiß, aber ich bin mir als Nachrichtentechniker leider auch der Risiken, bzw der Probleme viel zu bewusst. :(


    Zitat

    Also erst mal ein ARM Board so hinbiegen, das es die Grundlegenden Dinge für einen HAM kann..


    Was stellst du dir genau vor? :)



    Zitat

    Also nachdem D05PI diese netten Chips vorstellte.. musste ich an den Pactor Controller denken :
    CPU + DSP.


    Da hätte ich absolut Lust drauf, doch in der Hochschule habe ich mitbekommen, wie schwer es ist einen DSP zu programmieren. Drei Leute saßen mehrere Monate an einem einfachen Kammfilter.

    Zitat

    ich nutze fldigi - Die CPU überhitzt alle paar Minuten und schaltet ab.


    Ok.. sprich weiter.
    Ich habe hier einen EEEPC 701Ĝ und einen Samsung NC10. An jeweils nur den eigenen Monitoren. Beides verdammt coole Kisten.
    Das einzigste was ich am NC10 doof finde, ist das sich der Akku seit anfang 2010 nun verabschiedet hat.
    Wo ich erwartet hatte, das durch die niedrige Temp, der Akku länger halten müsste, als bei einem Hitzköpfigen Notebook...
    Bei anderen NC10 Usern soll der Akku aber schon seit 2009 noch nahezu die volle leistung bringen...

    Achja.. und Compiz bei Ubuntu abgeschaltet.
    Also "Gnome Classic ohne effekte". Mit Compiz, schafft es selbst mein X2 mit nigelnagelneuer 60EUR Graka auf meinem Samsung 2343 Monitor ein Video ruckelfrei in Vollbild darzustellen.


    Eine überhitzte CPU hatte ich zuletzt bei einem Medion Notebook das nen 2,4GHZ P4 intus hatte. Der lüfter lief so stark, das der Kühlkörper immer schnell verdreckt war.
    Dann wurde alles instabil. Ausserdem haben die Elkos gelitten.
    Austausch der defekten Bauteile + Runtertakten auf 1,6 GHZ brachte dann brauchbares Notebook zum vorschein.
    Das war mir wichtig.


    Zitat

    Was stellst du dir genau vor? :)


    PSK31.. RTTTY... also alles das was man mit der Soundkarte auflesen kann..
    Ax25 wird schon sowieso vom Kernel unterstützt..


    Zitat

    Da hätte ich absolut Lust drauf, doch in der Hochschule habe ich mitbekommen, wie schwer es ist einen DSP zu programmieren. Drei Leute saßen mehrere Monate an einem einfachen Kammfilter.


    Erst mal keine Angst . Angst tötet den Geist.
    Kann ja immer noch sein, das die 3 Leute nur so getan haben, und in Wahrheit im Biergarten waren. Und damit keiner doofe fragen stellt, gestöhnt haben, das das sooo schwierig sei. ;)
    Was ich an DSP's gesehen habe, ist das das einfach nur spezialisierte Controller sind.
    Ich habe mal ein wenig nach den Algos der Weaver Methode ( SSB ) umgeschaut ,und gemerkt, das das so schwehr gar nicht mal ist.
    Aber das wäre wieder ein viel weiterer Schritt...


    z.B. frage ich mich immer noch, welches Display vernünfig ist.
    Ich Idiot habe eben verpennt, als ich beim strahlenden Sonnenschein im Baumarkt war(strippen für Hühnerleiter kaufen) mein Blackberry mitzunehmen.
    Dann hätte ich ja sehen können, ob so ein Display für sowas taugt.
    Also die grösse von meinem Blackberrydisplay finde ich, bei entsprechender Zeichengrösse für sehr gut ablesbar. Nur der in der Sonnetest, fehlt noch.


    Wegen der Usability, kam mir gerade in den Sinn, wenn man z.B. für PSK31 2 Fliegen mit einer klappe erschlagen möchte, nämlich lesbarkeit, und Wasserfall, dann könnte man ja 2 umschaltbare "Fenster" haben.
    1. mal nur Text (empfang und gesendet) und einmal nur Wasserfall + emfpang.


    lg JAn

    Hallo liebe Mitleser und -schreiber!


    Um noch einmal auf das ursprüngliche Thema zurückzukommen, ich habe mir mal das Datenblatt vom STM32F405XX angesehen. Ich bin am überlegen, ob ich mich damit auch etwas näher beschäftige. Von der Grundidee würde ich einen µC mit Embedded Linux oder einem RTOS benutzen. Zur Signalverarbeitung könnte man einen DSP nehmen der auf einer Zwischenfrequenz arbeitet. Das arbeiten auf der Empfangs-/Sendefrequenz denke ich wäre zu aufwendig. Als Display würde ich ein normales nehmen und die Tastatur extra ansteuern (nicht als Touchpad). Der erste Schritt wäre erst mal ein Board mit dem µC, DSP und Peripherie zu entwickeln. Das sollte man dann erst einmal versuchen zum laufen zu bekommen.


    Was meint Ihr dazu?


    73 de Nico
    DD6VFS

    Hi.


    Das Thema reizt mich auch immer mehr, obwohl ich wirklich nicht im sommer programmieren wollte.
    Wegen dem Board :
    http://www.olimex.com/dev/index.html
    bzw http://www.olimex.com/dev/imx233-olinuxino-maxi.html


    Lies mal ganz genau : Alles ist hier GPL ! Selbst das Board. (Was übrigens auch bedeutet, das sämtliche änderungen auch darunter fallen. )
    Das einzigste was ich noch nicht weis, aber da lese ich mich gerade ein, ist, wie man ein xxx*xxx Pixel Display ansteuert.
    Aber es scheint, als würde da schon was in richtung Framebuffer gehen.
    Dann kann man schon fast auch X Applikationen andenken.
    z.B. ein abgespecktes FL-DIGI.
    Gui anpassen, kein Window-Manager... könnte klappen.
    Mein erster Linux-Rechner hatte auch nur 48MB... und da war ein vollständiges X drauf.


    DSP würde ich wirklich erst im 3. Schritt als Modul andenken.
    So könnte man im ersten schritt relativ schnell ein Digitales Modul entwickeln, was die Grundlegenden Funktionen beherscht, was ggf weitere zum mitmachen anregt, was wesentlich günstiger wird als das NUE PSK aber dafür mehr leistet !
    Und die Hardcore-SMD-ler können sogar dieses Board sogar selbst bestücken.


    Wobei .. so ein DSP könnte natürlich noch viel bewegung in noch ganz andere dinge bringen : z.B. breitband Datenfunk (hamnet userzugang) auf 70cm. Also auf 5 GHZ gewinne ich bei meinem QTH dort keinen Blumentopf.... :(
    Aber wie gesagt, ein DSP als optionaler "CO-Prozessor"... wäre schon ein ding. Direkt via Netzwerk Programmierbar..(Für die Spielkinder unter uns... )


    lg JAn

    Hallo zusammen


    Ich habe gerade gesehen dass ihr einen neuen Thread auf gemacht habt.....


    wir verwenden für unsere Linux basierten Firewalls diese kompletten Mini-ITX Boards
    http://www.pcengines.ch/alix1d.htm


    Laufen mit verschiedenen Linux Versionen oder auch Windows XP, haben einen I2C Bus, Audio, CF, TFT LCD Buchse, etc.
    und eine RS232 um den TX zu steuern, brauchen aber ca. 4 Watt im Betrieb

    73 de Thomas
    HB9RML

    Mal ne ganz blöde frage zu dem Board :
    Wieviel kostet das ?
    Lässt sich der Stromverbrauch eventuell durch runtertakten noch reduzieren ?
    Oder durch nicht aktivieren von nicht benötigten komponenten ?


    Wenn es nur klein sein soll, habe ich schon Atom-Boards der 50Eur klasse gesehen : http://www.hiq24.de/products/M…-ITX-Atom-D425-18GHZ.html


    Aber ein günstiger Preis wäre mir da schon wichtig. Sosnt würde ich weiterhin auf meinen EEEPC 701 schwören (11Watt mit LCD und Backlight, Wlan, etc.. ) und lieber ein paar Akkus mehr dran machen.


    lg Jan

    Die Frage, die ich mir stelle ist: Passen diese Boards wirklich in einen Transceiver?


    Eine weitere Frage ist: Wollen wir versuchen, etwas selbst zu bauen? Wie wollen wir es angehen? Großer DSP mit A/D Wandler und lediglich ein ARM zur Steuerung und zur Anzeige des ganzen (Display, DAC)?
    Oder lieber doch ein komplettes Linux auf dem ARM und ein kleiner DSP/Tayloe Detektor, der lediglich das Signal in ein IQ Signal umsetzt, welches dann per I2S zum Linuxsystem durchgeroutet wird?


    Ein ARM braucht definitiv weniger als 1Watt. Mit der ganzen Peripherie sind wir optimistisch geschätzt bei 4 Watt (incl ADC + evtl DSP).


    (Man merkt schon - Ich bin heiß auf DIY. Alleine kommt man da aber keinen Meter weit :))

    Variante 2 gefällt mir am besten : Denn hier kann man ganz in ruhe Schritt für Schritt arbeiten :
    1. mal board ans laufen kriegen...
    2. Display dran tütteln..
    3. X (frambuffer) zum laufen kriegen..
    4. Fldigi oder andere Software so abändern, das sie mit dem kleinen Display harmoniert..
    ... ab hier wäre schon ein wichtiger Meilenstein erreicht : Ein System das PSK und andere Betriebsarten(CW.. SST.V.. zu dem Bruchteil der kosten von Nuepsk beherscht. )
    5. sich langsam gedanken über DSP machen...
    6. ...
    7 ...
    8 ...
    9 ...
    Modul an bieten, das z.B. 400KHZ direkt verarbeiten kann.


    Die Lösung hat sogar den vorteil, das man über das Netzwerk mal eben neuen Code testen kann.
    Also sehr elegant.


    Also ich habe beschlossen nachdem ich hier ein paar kleinere projekte fertig habe, mir so ein OpenSource ARM Board zu holen, und in der zwischenzeit überlege ich mir gelegentlich welches Display wohl am vernünftigsten wäre...
    Und wie man das ansteuert.
    Und diese überlegung sollte wirklich mit sorgfalt geschehen. Doof wird es nämlich wenn jeder OM eine andere Pixelanzahl hat.
    Das macht das Programmieren, dann noch umständlicher.


    lg Jan

    Bevor wir das dann tun, sollten wir uns auf ein Board einigen, das sich jeder beschafft!


    Andere Boards, andere Verbinder und Standards. Ich habe hier ein Board, das ein LVDS Interface hat, welches ich locker mit Linux ansteuern kann. Andere Boards haben vllt ein anderes Interface.


    Möglichkeiten sind:

    • VGA
    • DVI
    • LVDS
    • Generisches LCD Interface #1 oder #2
    • Oder eine der folgenden Prozessorinterfaces die nach aussen geführt wurden:
      • Intel StrongARM/XScale
      • Motorola MX1 Dragonball
      • Motorola MC68K
      • Motorola DragonBall MC68EZ328/MC68VZ328
      • Hitachi SH-3
      • Hitachi SH-4


    Habe ich was vergessen?


    sollte das Beagleboard die Wahl der Qual sein könnte man dieses hier nutzen: http://www.chalk-elec.com/?pag…e=product&product=7703686


    So schaut das Addon Board für VGS Output vom P3 aus: http://www.elecraft.com/P3/p3_svgapcb.jpg


    Erkennen kann man einen Spartan FPGA (VGA Output), einen ROM, um das Programm in den FPGA zu laden und einen dsPIC zur Kontrolle mit einem DSP (AD6620)für die 2048pt FFT.


    Der P3 nutzt als Display das http://www.hantronix.com/files/data/1278363262s430-3.pdf
    Und als Display Controller den SSD1906.


    Keine schlechte Kombination - Und das alles ohne Linux :)

    Also ich persönlich finde ja das hier sehr interessant : http://www.olimex.com/dev/imx233-olinuxino-maxi.html
    Das kann man auch mal eben kommerziell vertreiben, und daran was abändern.(opensource)
    Sogar es komplett selbst bauen.
    Nur, wie man dort am besten ein Display anschließt weis ich noch nicht... noch nicht.
    Aber möglich ist das bestimmt.


    Aber von der Leistung und vom Preis her, ist das wirklich top !
    z.B. würde das http://www.olimex.com/dev/imx233-olinuxino-mini.html
    je nach stückzahl unter 30 Eur kosten.


    Soundkarte mit Ein und Ausgang ist für den "ersten meilenstein" und für den zweiten (ssb) schon drin.
    wieder ein problem weniger.(rasperry hat nur ausgang.)


    lg JAn

    Der Controller hat laut Datenblatt lediglich ein 8 bit LCD Interface. Soweit ich weiß braucht ein 8080 oder M68K Interface aber 16 bit. Das heißt, ein Display auf diesem Board fällt flach.