Hallo, Der AP7000 hat ja keine USB-Host-Funktionalität. Nun gibt es meines Wissens nach 2 USB-Host-Controller, die über eine SPI-Schnittstelle kommunizieren ( MAX3421E und der VNC1L ). Weiterhin wäre da noch der ISP1160, der über den on chip static memory controller des AP7000 kommunizieren könnte, wenn denn dieser beim Grasshopper oder den Grasshopper-OEM herausgeführt wäre :( Ich würde gerne eure Meinung dazu hören, ob es Sinnvoll wäre, eines dieser SPI-ICs zu nehmen und es machbar wäre, eines dieser ICs unter der Linuxumgebung anzusteuern. Vielleicht hat ja auch jemand von euch noch eine ganz andere Idee dazu. Gruß Udo
Habe auch schon ein paar mal mit dem Gedanken gespielt. Leider habe ich (fast)keine Ahnung wie der USB Host Layer im Kernel Funktioniert. Meine letzte Überlegung war einen SL811 per CPLD / Shiftregister an den SPI zu bringen. Da man mit dem SPI Interface schön DMA machen kann und DMA Buffer innerhalb des Kernels mmap()en kann , dürften die Änderungen am SL811 Treiber sich auch in grenzen halten. Einen MAX3421E Treiber aus den Boden zu stampfe halte ich für schwer. Einen Ähnlichen Treiber (kzmalloc (buffer)-> mmap(buffer) -> .ioops = &buffer) habe ich schon für ein SPI LCD geschrieben , funktioniert so gut das sogar DirectFB und Duke Nukem/Doom (grins) auf dem SPI LCD laufen. Also machbar ist es bestimmt. Wie wäre es wenn wir uns zusammentun und der Grasshopper (NGW100) Community einen USB Host versuchen zu basteln?
Hallo, Hab mich bevor ich mir den Grasshopper besorgt habe darübe schlau gemacht: Am einfachsten ist meiner Meinung nach der VNC1L: Ohne jetzt den genauen Hintergrund im Kernel zu kennen, bietet der VNC ein "relativ" einfaches Interface. Mit http://apple.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=66&title=VDIP2 ist ein günstiges Board gegeben was sich für erste Tests bezahlt macht. Wobei ich die CPLD Idee aber auch gut finde. Aber Kosten/Nutzen Faktor, so eine CPLD Variante bekommen wir nie sauber released und wird wohl immer als "Zwischenlösung" gelten. Der VNC1L wär halt was richtiges. abo btw
Hallo Michael, vom VNC1L halte ich bei einem Linux System nicht besonders viel. Man müsste immer noch eine Wulst von Treibern dahinter haben um z.b. von einem USB Mass Storage Device auf Linux Block Device zu kommen. Und was ist wenn ich im nächsten Moment einen Wlan Stick oder einen Usb Drucker einstecke? Gibt es da Firmwares? Linux/AVR32 bringt das fast alles schon mit , es fehlt eigentlich nur an den zwei letzten Schichten. Das Problem ist das der OHCI/UHCI Layer einen USB Controller als Memory Mapped erwartet. Deswegen der Gedanke mit dem Schieberegister + SPI(CPLD bietet sich halt an,geht aber bestimmt auch mit einem 74AHC5irgendwas Grab). Es müsste nur ein Treiber laufen der die Register des USB Host Controllers per SPI vom Schieberegister abholt/hoch schiebt und in einen lokalen Buffer schreibt/liest , die Adresse des Buffers wird dann dem OHCI/UHCI Layer als IO Region des USB Host Controllers übergeben. Da der SPI beim AVR32 !sehr! schnell ist und komplett im DMA laufen kann hält sich der Overhead für die CPU in Grenzen. Klar so späße wie DMA vom USB Host Controller zur CPU gehen wahrscheinlich nicht . Aber durch den schnellen SPI ,der von mir aus immer im Kreis laufen kann, hat man schon eine Pseudo DMA. Das ganz würde auch für den MAX3421E funktionieren , ohne SR halt hat er ja schon eingebaut, aber für den Chip fehlt es an einem Treiber und ich bezweifel das der Chip OHCI oder UHCI spricht (Ähnliches Dilemma wie VNC1L).
Hallo Claude, Habe mir gerade noch ein bisschen mehr Wissen ergoogelt, wie gesagt hatte kaum Ahnung vom Kernel Interface (und jetzt auch noch nicht viel :)). Stimm dir voll zu, der VNC1L ist eigentlich nur was für nen kleinen Controller, wo man weiß was rankommt. Was in unserem Fall ja nicht gegeben ist,den VNC1L direkt ins Kernel Interface einzubinden wird schwierig. 95% der Arbeit getan und wir müssten uns nur um den SPI-Parallel Wandler kümmern. Das Problem was ich am CPLD sehe, ist der Aufwand zum Nachbau. Meiner Meinung nach sollte eine Lösung mit 74AHC* angegangen werden.
evtl. könnte auch der TUSB6010 eine Lösung sein. Der ist wohl im Nokia n800 verbaut und kann USB-Host. Dafür gibts zumindest einen Linux-Treiber, ob der allerdings auch den Host-Mode beherrscht hab ich noch nicht nachgeschaut.... Michael
Also ob der TUSB6010 der richtige ist bin ich mir nicht sicher. Es scheint ihn nur in BGA zu geben und mir wäre nicht bewusst, daß der Grasshopper so ein "NOR-flash like interface" hat was zum Anschluß benötigt wird. Bevor wir da mit CPLDs usw. rummachen - wäre es nicht einfacher einen Linux-Treiber für den MAX3421E zu schreiben?
Jetzt muss ich noch mal die Schieberegister Lösung propagieren :-) Der TUSB6010 wäre schon mal , meiner meinung nach , ein guter Ansatz wobei ich denke das dieser IC eine gewisse Herausforderung darstellt (USB2.0 High Speed 480MBps v.s. SPI , DMA und das besagte BGA Gehäuse) an der man im Endeffekt scheitert. Der TUSB6020 wäre auch schön , aber mit 150MHz VLYNQ Seriell Interface passt der eher an OMAPs und Ti DSPs Der MAX3421E hat , soweit ich das beurteilen kann , so ziemlich gar nichts mit einem dem OpenHCI USB Host Controller Standart gemein (ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf , http://pdfserv.maxim-ic.com/en/an/AN3785.pdf). Also würde es bei diesem Chip auf mehrere Layer im Linux Kernel hinauslaufen die man umkrempeln müsste. Dagegen hat z.B. der ISP1160 von NXP ein OpenHCI konformen Registersatz , läuft auch im PIO Modus , ist eingermaßen gut erhältlich , einen wirklich übersichtlichen Linux Treiber der alle IO Operationen auf den Chip im Headerfile per Inline macht. ->
1 | static inline void isp116x_write_data16(struct isp116x *isp116x, u16 val) |
2 | {
|
3 | writew(val, isp116x->data_reg); |
4 | isp116x_delay(isp116x, 150); |
5 | }
|
6 | |
7 | static inline u16 isp116x_read_data16(struct isp116x *isp116x) |
8 | {
|
9 | u16 val; |
10 | |
11 | val = readw(isp116x->data_reg); |
12 | isp116x_delay(isp116x, 150); |
13 | return val; |
14 | }
|
Das wäre mein persönlicher Favorit für einen SPI USB Host. Das ein CPLD abschreckend , komplex und wie eine "Dauer Baustelle" wirkt war mir nicht so bewusst, aus meiner sicht war es eben die einfachste Methode. Das Ganze mit Standart 74HC* aufzubauen wird bestimmt auch gehen , wäre für mich aber zu viel Bastelaufwand und exterm nervig beim Debuggen der Hardware :-) Nur als Beispiel : http://www.harbaum.org/till/spi2cf/spi2cf.html Gruß Claude
Hallo, sorry, dass ich mich erst jetzt wieder melde, aber z.Z ist Prüfungszeit und da bin ich meist im Stress.... ;) Ich finde es Toll, dass sich schon so viele mit konstruktiven Beiträgen beteiligen. Da ich schon mal mit dem VNC1L gearbeitet habe, weis ich um dessen Macken. Außerdem gefällt mir nicht, dass man total von den Firmware-Vorgaben abhängig ist, die im Übrigen nicht gut dokumentiert sind. Weiterhin gibt es auch keine Treiber dafür. An dem MAX3421E gefällt mir, dass er einfach über die SPI-Schnittstelle anzuschließen ist. Wobei natürlich die Entwicklung eines Linux-Treibers dafür heikel ist. Es gibt wohl schon einen Device-Treiber ( inkorrekter Weise als Host-Driver tituliert) für den MAX3420, aber das hilft uns wohl nicht weiter. http://www.bioinspired.com/users/ajg112/circuits/max3420.shtml#hostDriver Den TUSB6010 können wir getrost vergessen, da werden wir keine Schnittstelle am GH oder am GH-OEM zu finden. Bleibt noch der SL811HC und der ISP1160, die man beide über eine CPLD- oder eine 74HC..- Lösung an die SPI-Schnittstelle anbinden könnte. Für beide gibt es Treiber, so dass man sich auf die Hardware-Entwicklung und auf Software für die Anpassung beschränken könnte. Nachteil des SL811HC: er kann nur USB 1.1, während der ISP1160 auch USB 2.0 kann. Mit CPLD hab ich noch nichts gemacht, das wäre Neuland für mich. Andererseits ist der Gedanke an ein 74HC...-Grab auch nicht berauschend. Also für mich wäre demnach auch der ISP1160, in Verbindung mit einem CPLD, der Favorit. Eine andere Möglichkeit würde ich gerne noch Erwähnen: Ein Hack des GH-OEM-Moduls. Es wäre praktisch möglich, den 8MB-Flash zu entfernen und an seiner Stelle 2 zusätzliche Hirose-Verbinder zu montieren. Damit hätte man Zugriff auf den EBI-Bus und netterweise sind die zusätzlich benötigten Steuersignale sowieso herausgeführt. Den Flash könnte man dann wieder auf dem AddOn-Board ergänzen. @Claude Gerne nehme ich dein Angebot zur Zusammenarbeit an, wobei ich den Umfang des Projektes gerne noch etwas steigern würde ;) Ein AddOn-Board für das GH-OEM-Modul mit folgenden Merkmalen: Ethernet mit DM9161A AC97-Audio mit CS4202 USB/Serial-Device mit FT232RL USB-Host mit.........? µSD-Slot PS2 mit 5V-Interface LCD (mit PSP-Display oder das aus dem Shop) Touchpanel mit TSC2046E Spannungsversorgung 3,3V und 5V nicht benutzte Anschlüsse des GH-OEM-Moduls auf 2,54Stiftleisten JTAG ist auf dem OEM-Mudel schon herausgeführt hab ich was vergessen? ;) Gruß Udo
Hallo ihrs, Langsam wirds spannend hier :) @Udo, bist auf den USB-Host trifft es genau das Multimedia Gerät an dem ich gerade bastle. Das sowas ja natürlich nicht für Hobbybastler mit 6 Lagen und BGA realisierbar ist, war klar. Deshalb wollte ich den AT32AP7001 im QFP208 Gehäuse verwenden, der hat aber kein LCD Interface -> Epson S1D*, sollte von der Performance her fürs PSP Display ausreichen. Kommt jetzt USB-Host zB dazu muss man halt schaun wie es sich auf den EBI auswirkt. Das ganze tendiert dann zwar weg vom Opensource Player hin zum Opensource PDA :) Aber genug der Träumerei, fakt ist das es kaum Projekte mit dem AP7 die frei verfügbar sind. Sowas bietet sich an und wir kommen weg von den OEM Modulen. Wir haben so komplett Einfluss auf die was wo verfügbar ist. Michael
@Udo Ja wunderbar :-) Den GH-OEM hatte ich auch schon im Auge , bin aber gerade noch zu stark mit dem TSC2102 Touch Audio Codec für den GH beschäftigt. Mit CPLDs habe ich schon ein paar Erfahrungen sammeln können , ich denke das werde ich hinbekommen. Zur Not wird uns bestimmt von einem der FPGA/VHDL Gurus hier im Forum geholfen (lkmiller,Falk,Kest,etc gibt ja genug hier :-) ). Ich würde dann die Tage mit dem CPLD anfangen. Wird auf eine Xilinx XC9572XL rauslaufen , denn bekommt man auch bei Reichelt für wenig Geld. Zu deiner Liste : - Touch einen Extint spendieren. - GCLKs für AC97/SSC. - Einen "vernünftigen" Reset Baustein für die Peripherie. - uSD wieder zu SD :-) Wegen SDIO Karten,unterstützt ab 2.6.27 - Und ich hätte noch einen halbwegs Funktionierenden Akku Lader für NiMH anzubieten der mit dem Linux Host per SMBus plaudert (Attiny basierend)
Hallo Claude, vielen Dank für deine Anregungen. Im Moment haben wir ja (alle?) das Problem, dass sich der neue Kernel beim touch-irq aufhängt (buildroot 2.3.0), ob das besser wird mit einem Extint? Ist leider beim GH (nicht GH-OEM) nicht rausgeführt. Meine Glaskugel verrät mir, dass du evtl. Probleme bei der Audioausgabe über SSC hast ;) Leg mal MCLK auf PA30 (GCLK0) und editier deine setup.c nach angehängtem Beispiel. Reset-Bausteine gibt es wie Sand am Meer, hast du da einen bestimmten im Auge? µSD oder SD, ich würde vorschlagen: beides. System auf µSD und der SD-Slot für SDIO-Karten. NiMH? ich dachte LiPo ist in? Gruß Udo
Hallo Udo, >Im Moment haben wir ja (alle?) das Problem, dass sich der neue Kernel >beim touch-irq aufhängt (buildroot 2.3.0), ob das besser wird mit einem >Extint? Ist leider beim GH (nicht GH-OEM) nicht rausgeführt. Oh ja die IRQF Flags , sollte morgen/übermorgen mein Touchpanel bekommen. Dann werde ich mich damit mal bschäftigen. Der EXTINT kommt auch mit Edge Trigger zurecht , GPIOs als IRQ Quelle können nur Level Trigger. Mir kam aber schon eine Idee wie man den GPIOs per Software Edge Trigger beibringt. >Meine Glaskugel verrät mir, dass du evtl. Probleme bei der Audioausgabe >über SSC hast ;) Leg mal MCLK auf PA30 (GCLK0) und editier deine setup.c >nach angehängtem Beispiel. Der GLCK0 läuft mit meiner eigenen setup.c ganz gut. Bekomme zwar keine , wie angefordert, 12MHz hin aber dafür 11.6666MHz. Aus dem 25MHz Quarz lässt sich auch nur schwer 12MHZ durch die PLL erzeugen. Da mein TSC2102 Treiber über clk_get die Frequenz ausliest und das SSC Modul im Slave Modus läuft sehe ich da kein Problem. Und im schlimmsten Fall wäre der Sound um ~3% zu langsam. Da ich zu Faul war mir das AP7000 Datenblatt zu Gemüte zu führen , dies aber inzwischen nachgeholt habe , habe ich nur die PLL0 als Clock Source für den GCK0 probiert. Als nächsten Versuch nehme ich den OSC1/PLL1 (12MHz am GH) als Clocksource für GCK0. Damit sollte dann 12MHz kein Problem mehr sein. >Reset-Bausteine gibt es wie Sand am Meer, hast du da einen bestimmten im >Auge? Nö Feld-Wald-Wiese , blos diese RC Glied Resets (GH + GH-OEM) stören mich. Das setzt immer einen Schmitt-Trigger Eingang am zu resetenden Baustein voraus. >NiMH? ich dachte LiPo ist in? Naja da das alles auf der AVRBC100 Application Note aufbaut ist natürlich auch LiPo möglich. Muss halt der Source angepasst werden. Ich persönlich halte nicht so viel von LiPo/LiIon , die Dinger sind mir zu Explosiv :-)
@Udo ahh ich glaube ich verstehe jetzt was du mit dem GCLK0/PA30 Problem meinst. PA30 wird schon als GPIO für die LEDs deklariert, das muss natürlich in deiner setup.c raus. Oder geht das per Kconfig? Ich hab die LEDs bei mir komplett raus genommen da der SSC diese GPIOs ebenfalls benötigt.
Als Reset schmeiss ich einfach ma den NCP302L von ON-Semi rein. SOT23 und 3 Bauteile ;)
@Claude sorry, war von mir ein wohl ein wenig zu Übertrieben(Provokativ) ausgedrückt. Ich meinte, dass du in deinem ersten Stromlaufplan PA21 für MCLK benutzt hast. Nur habe ich dort keine Clock erzeugen können. Mit den LEDs....ich habe die noch mit dran, funktioniert auch. Das Problem was ich habe ist: Wenn ich über MPlayer eine Internetradiostation aufrufe, wird der Cache mit ca. 50KB gefüllt und die Prozessorauslastung liegt bei ca.40%, mit abnehmender Tendenz. Die Übertragung und Wiedergabe ist dann noch einwandfrei. Aber wenn dann die Prozessorauslastung nach ein paar Minuten so auf 1-2% gesunken ist, fängt die Übertragung an zu stottern, als wenn der Cache nicht kontinuierlich aufgefüllt würde. Gehe ich dann für ein paar Sekunden auf Pause und anschließend auf Wiedergabe, ist diese erst wieder einwandfrei, bis die Prozessorauslastung wieder gesunken ist. Dann fängt die Übertragung wieder an zu stottern. Gruß Udo
@Udo Ah den hatte ich schon ganz vergessen , ja inzwischen benutzt ich den PA30 :-) Genau aus diesem Problem. Aber danke für den Hinweis! Hmm hast Du schon einen Audio Codec am Grasshopper am laufen? Weil ich schwanke gerade noch zwischen dem größeren (Alsa ASoC) und dem kleineren übel (Alsa "Normal"). ASoC ist relativ neu und bescheiden Dokumentiert aber es gibt schon einen Rumpf für AVR32 , "Normales" Alsa ist ausreichend gut Dokumentiert aber es gibt nur einen sehr spezifische Treiber für AVR32 (AT73C213). Die ALSA Leute meinen ASoC wäre die Zukunft für SOCs und man sollte bei uCs darauf setzen ...
Und wieder zurück zum Topic ! Hier mal ein Entwurf des USB Adapters , USB Overcurrent und Power Switches fehlen noch. Ist auch eher als Entwicklungs Board gedacht.
Hallo Claude, ja, ich hab einen AT73C213 unter ALSA "Normal" laufen. Gruß Udo
@Claude: bin ich blind oder wo ist bei deinem Konzept das CPLD angesiedelt? Oder ist das nicht mehr für den "normalen" Grasshopper, sondern nur noch für den AP7000 OEM gedacht?
@Udo Wo hat Du den AT73C213 her? Selbst DigiKey,Mouser und Farnell haben ihn nicht auf Lager. Zum TSC2102 habe ich nur gegriffen da ich nirgends den AT73C213 bekommen habe (Nicht mal bei Atmel als Sample über Firmenanfrage). Wenn Du jetzt "CSD" sagst bricht für mich eine Welt zusammen :-) @Gerd Genau wie Michael B. meint , die Bank Blöcke sind der XC9572XL. Mein EDA Tool hat die Bauteile schon so in der Lib drin, was bei größeren Bausteinen sehr angenehm ist.
Habe mich mal ans Layouten gemacht. Einen Schönheitswettbewerb gewinnt man damit bestimmt nicht aber dafür ist alles auf einem Layer. Mal schauen ob ich morgen zum Platinen ätzen komme , der ISP1160 und das CPLD liegen schon neben mir.
@Michael S. Jein, wie schon weiter oben beschrieben hänge ich gerade etwas an der Software. Es fehlt noch der Alsa Treiber und das IRQ Problem mit dem aktuellen Buildroot ist auch noch nicht gelöst. Das Ursprüngliche Layout muss abgeändert werden (MCLK für den TSC2102 an PA30). Benedikt wollte vor ~2 Wochen Platinen fertigen lassen , aber da ich noch nicht soweit mit der Software bin habe ich Ihn gebeten noch zu warten. Bringt ja auch nichts wenn die hälfte der Platine nicht funktioniert und vielleicht sogar noch etwas an der Hardware geändert werden muss.
Hallo, ich habe mal meine Vorstellungen einer Adapter-Leiterplatte für das GH-OEM-Modul in Stromlaufpläne gegossen. @Claude Blatt8 betrifft den USB-Host-Teil. Wenn da Änderungswünsche sind, bitte posten. Was den AT73... betrifft, ja, war sehr schwierig davon Muster zu bekommen, aber ich möchte nicht, dass jetzt eine Welt für dich zusammenbricht.... ;) Gruß Udo
Hallo Udo, wow schaut gut aus! Ein paar Kleinigkeiten hätte ich aber noch. - DREQ am ISP1160 geht nirgendwo hin ? Ist auch korrekt , bleibt NC wenn man kein DMA nutzt. - Der Reset am CPLD , vom Reset/GH-OEM kommend , muss ich noch klären ob das so gut ist. Das CPLD hat einen eigenen "Reset" Eingang den ich aber momentan nicht nutze. War bei mir im Layout (1 Layer) einfacher. - Welt : Am Seidenden Faden :-) Hat CSD noch welche ? Oder war das eine einmalige Muster Aktion? Weil mein TSC2102 treibt mich noch in den Wahnsinn. Wenn der AT73 erhältlich ist Strick ich meine GH Platine auf AT73 um!
Hallo Claude, -DREQ war ein Versehen im Eifer der BUS-Beschriftung...sorry wegen dem RESET.... Ich finde in den Datenblättern zu dem CPLD keinen RESET-Eingang. Wohl ist es aber so , das Xilinx empfiehlt , dass Vccint vor Vccio angelegt werden soll, damit die interne Logik funktioniert, bevor die IOs aktiviert werden. Anders herum würden ggf. kurze Impulse auf den IO-Leitungen auftreten. Das mit dem AT73C213 war eine einmalige 1 Stück Muster Aktion bei CSD. Ob er noch welche hat, weis ich nicht. Aber wenn du willst könnte ich dir noch einen besorgen. Gruß Udo
Hallo Udo, der "Reset" nennt sich GRST , ist eine Globale Leitung im CPLD die an alle FFs geht. Aber ich denke das passt so wie es ist. Auf das Powersequenzing können wir verzichten , der ISP1160 bekommt sowieso über das CPLD einen Reset sobald der Treiber Initalisiert wird. Daher ist es egal ob beim Powerup Mist am ISP1160 ankommt, der GH ist zu diesem Zeitpunkt auch noch nicht mal im Uboot. Habe die Tage mal ein paar Versuche gemacht, und es schaut ganz gut aus! Eine "Unschönheit" besitzt der ISP1160 aber , wenn man vom Command auf das Register Interface umschaltet (Leitung A0) braucht er 300ns Wartezeit. Hab versucht das ins CPLD rein zu quetschen , aber das frisst zuviel Macrozellen. Mal schauen ob mir da noch etwas elegantes einfällt. Mein momentanes Ziel ist es einen kompletten Buszyklus (RW) in einer SPI Message unterzubringen. Dadurch kann man die DMA Einheit auf dem GH besser nutzen. Eine Message besteht momentan aus 24 Bit :
1 | Bit 0 : A0 |
2 | Bit 1 : CS |
3 | Bit 2 : RW |
4 | Bit 3-7: 4 Dummy Bits die als Clock für die CPLD Statemachine dienen |
5 | Rest Bits: Die Daten für den ISP1160 (RW) |
dadurch kann man schön mit spi_message_add_tail() in Linux die DMA Nutzen und muss auch nicht viele SPI Pakete "On The Fly" im Treiber zusammensetzen. Als SPI CLK habe ich momentan 20MHz angesetzt. Hoffe damit bekommt man eine akzeptable Geschwindigkeit auf dem USB hin. Das mit dem AT73 habe ich befürchtet :-( Aber Danke für das Angebot! Werde mich durch meinen TSC durchbeissen..
Habe etwas am USB Host weitergemacht, Vortschritt ist hier zu finden : http://claude.schwarz.googlepages.com/ap7000usbhost
Hey, klasse Fortschritt.... Sieht ja schon toll aus :) Asche auf mein Haupt, aber ich bin noch nicht viel weiter mit dem Layout. Bleibt die Pinbelegung des CPLD wie bisher? Gruß Udo
"Vortschritt" .. hehe Ich vermute das die Pinbelegung so bleiben wird, was sich geändert hat ist das der CPLD nun 2 SPI Chip Selects benötigt aber nur noch eine IRQ Leitung. Mal schauen wann ich zum Linux Treiber komme , danach kann ich mit bestimmtheit sagen ob das Pinout passt.
Habt ihr schon das gesehen? http://www.ic-board.de/product_info.php?info=p85_ICnova-AP7000-OEMplus.html Weiß jemand, ob das nativ unter Linux läuft? Da gibts dann auch ein "Motherboard" dazu, auf dem dann der Eternetcontroller drauf ist und der die Anderen Schnittstellen nach außen führt. http://www.ic-board.de/product_info.php?info=p67_ICnova-ADB1000.html
Da zitiere ich mal Udo ein paar Posts vorher : >Ein AddOn-Board für das GH-OEM-Modul mit folgenden Merkmalen: > >Ethernet mit DM9161A >AC97-Audio mit CS4202 >USB/Serial-Device mit FT232RL >USB-Host mit.........? >µSD-Slot >PS2 mit 5V-Interface >LCD (mit PSP-Display oder das aus dem Shop) .... usw Was meinst du mit Nativ unter Linux laufen? Ja auf dem Modul läuft Linux , und Ja man kann unter Linux (x86,PPC,..) für das Modul Cross Compilieren
Dass da Linux drauf läuft ist schon klar. Es ging mir ja auch nicht um das ICnova AP7000 OEM sondern um das ICnova AP7000 OEMplus. Da ist ein USB-Host Controller draufgelötet, und ob der vom Linuxkernel unterstützt wird war eigentlich meine frage. Das ICnova ADB1000 ist ein Evaluationboard dazu, das alle vorhandenen Schnittstellen nach außen führt.
Huch, das Modul kannte ich wirklich noch nicht. Sorry wenn die Antwort "Patzig" rüber kam. Ich habe gerade mal nach dem ISP1761 Treiber gegoogelt. Also im Mainline Kernel ist er leider nicht (2.6.26), aber es gibt ein Projekt auf SF http://sourceforge.net/projects/isp176x-hcd
Hallo, mmh, da war IC-Nova wohl schneller als wir..... Kann es sein, dass der ISP1761 kompatibel zu dem ISP1160 ist? Jedenfalls bietet IC-Nova keinen Patch an. Gruß Udo
Bitte 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.