Hi! Da mein Laptop TFT grad im AR.. ich meine kaputt ist, und er deswegen für eine Weile zur Reperatur verschwinden wird und ich mir jetzt dann ein PDA kaufen werde, stellt sich mir die Frage ob man einen ISP über CF bauen könnte? Eigentlich wird CF ja für Festplatten genützt, aber es gibt ja auch WLan/GPS Adapter dafür?! Ein Schaltplan ist hier http://home.t-online.de/home/w.robel/m_mcbike/cflash/cf_1.htm zu finden. Weiss einer wie die GPS Dinger funktionieren. Man könnte ja "einfach" einen Parallel-Port emulieren, die Signale nach der CF-Karte parsen und von dort aus einfach weiter gehen. Hm.. Theoretisch müsste das doch nicht das allergrößte Problem sein oder? #grs
Damit würdest Du immerhin einen Preis für die mit Abstand aufwendigste Implementierung eines ISP-Adapters gewinnen.
Wieso. Ich finde das ziemlich praktisch. Wenn du im Zug unterwegs bist und ein bisschen spielen willst ?!? Oder wenn man keinen Rechner hat #grs
Gibt es denn für PDAs ein Entwicklungssystem für AVR-Prozessoren? Ein PDA ist kein x86-PC, und Windows CE ist überhaupt nicht kompatibel zu Windows (95-Me, NT/2K/XP/2K3). Du müsstest also wenigstens die Programmiersoftware (zum Übertragen von .hex-Dateien in einen AVR) selbst neu schreiben, und dann kannst Du Dir auch eines der verfügbaren Interfaces Deines PDAs dafür aussuchen, wenn der denn sowas haben sollte.
Also: 1. ist es ein Pocket PC der mir vorschwebt. 2. gibt es Linux implementierungen die OpenSource sind und damit kann man auch für PocketPC kompilieren #grs
Du willst also auf Deinem Pocket PC ein Linux laufen lassen und - beispielsweise - GCC-AVR darauf laufen lassen. Naja, warum nicht, wenn Du auf eine vernünftige Tastatur verzichten willst, bitte. Es gibt, soweit ich weiß, eine Spezifikation für I/O-Karten im CF-Format, an die sich die von Dir erwähnten WLAN- und GPS-Karten halten. Näheres darüber müsste sich hier http://www.compactflash.org/ finden lassen. Ich würde das anders realisieren: Nimm' die Infrarotschnittstelle. Das darüber abgewickelte Protokoll ist sehr an das der seriellen Schnittstelle angelehnt (IrComm); Du müsstest nur einen µC mit Infrarotschnittstelle ausstatten, der dann wiederum via ISP die Atmels programmiert. Das Protokoll betreffend könntest Du Dich am ISP-Programmer des STK500 orientieren, der im Prinzip exakt dasselbe macht, nur über eine "echte" serielle Schnittstelle. Der Vorteil eines solchen Gerätes wäre der, daß so etwas auch an Notebooks mit IR-Schnittstelle genutzt werden kann, damit hätte das Gerät auch einen Mehrfachnutzen. Obendrein ist die galvanische Trennung von Programmiergerät und Entwicklungsrechner auch ein netter Vorteil ...
Du machst dir damitmehr Stress als n paar wochen auf dein LAptop zu warten...wenn du glaubst in der zeit damit fertig zu werden.. besorg dir lieber nen alten rechner oder so.
es gibt auch kleine Computer mit "kompletter" tastatur und allem drum und dran war glaub ich von sony hab so ein teil mal bei einem damaligem klassenlehrer gesehen.. der lief endweder mit 200MHz oder mit 800MHz um den Aku zu schonen da muesste sogar ein komplettes Windoof drauf gewesen sein Gruss Jens
Es geht ja nicht nur darum. Das ganze macht ja auch irgendwie Spass oder? #grs
hier ich hab eben eins in der art bei ibi gefunden http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&category=19540&item=5153679185&rd=1
toll, aber mich reizt das Ding jetzt so dass ich mir mehr oder weniger fest vorgenommen habe das zu bauen. #grs
Ich würde es so machen wie Rufus T. Firefly es beschrieben hat, kannst ja noch einen normalen seriellen Anschluss vorsehen, dann ist der Programmer wirklich autark !
@Christian: Ich schlage Dir vor, daß Du Dir mal die CF-Spezifikationen für I/O-Geräte näher durchliest (Link auf CF-Organisation hatte ich Dir schon genannt), danach können wir ja weiterreden. Ich hab so ein bisschen das Gefühl, daß Du den Hardwareentwicklungsaufwand für ein CF-I/O-Interface ein klitzekleines Bisschen unterschätzt. Ein weiteres Argument zugunsten eines IrDA-basierten ISP wäre der damit auch mögliche Einsatz an Palm-PDAs. (All dies setzt natürlich eine Portierung des AVR-GCC oder vergleichbaren Entwicklungswerkzeug auf den jeweiligen portablen Rechner voraus ...)
Hi! Ich denke aber so ein Parallel-Port am PDA ist schon was nettes... Das mit den Entwicklungswerkzeug sehe ich als relativ kleines Problem. der avr-gcc ist opensource und es gibt bestimmt eine GCC-Portierung für einen PocketPC (was ist das eigentlich für ne Struktur? ARM glaube ich? ARM wird auf jeden vom gcc unterstützt). Wenn es unbegingt sein muss, kann man die verschiedenen Tools (gcc, programmer, editor) zusammen in eine IDE packen. Das mit der Hardwareentwicklung sehe ich bis jetzt wirklich noch nicht allzu kompliziert, aber das liegt wohl an meiner mangelnder Erfahrung auf dem Gebiet der Treiberentwicklung #grs
Und übrigens ich will nicht unbedingt Linux auf dem PDA laufen lassen, da ich auch GPS nützen will und ich nicht denke, dass das ganze so gut unter Linux läuft #grs
In Pocket-PCs ist eine ARM-Variante enthalten (oft Intel XScale), aber das ist nicht entscheidend. Nicht der Zielprozessor des GCC ist relevant, sondern das System auf dem der GCC laufen soll. Dazu musst Du auf Deinem Pocket-PC erst einmal ein Linux zum laufen bringen; unter Windows CE wirst Du es schlichtweg vergessen können, den GCC einsetzen zu können. Windows CE hat sehr eigene Vorstellungen, was es einem anstelle eines Dateisystems anbietet. CE-Rechner haben schließlich keine Festplatten ... Deine (mangelnde) Erfahrung an Treiberentwicklung ist nicht das primäre Problem, sondern Deine - vermutlich - auch mangelnde Erfahrung an Hardwareentwicklung. Das CF-I/O-Interface ist signifikant komplizierter als beispielsweise der ISA-Bus, für den man sich tatsächlich irgendwelche Hardware mit vertretbarem Aufwand selber stricken konnte. Dazu kommt der geringe Platz in einer CF-Karte; hast Du so ein Teil schon mal von innen gesehen? Schonmal Bauteile dieser Größe von Hand verarbeitet?
Ein kurzes googlen nach PocketPC und gcc bringt: Pocket gcc:http://mifki.ru/pocketgcc/ also sollte es schon funktionieren. Aber das soll jetzt ja nicht das Hauptproblem sein, sondern eher die Hardware. Gibt es schon Projekte, die Hardware am CF-Port betreiben? Kann man einzelne PINs auf High setzen, also so wie es beim Parallel-Port geht? #grs
Pocket gcc ist ein C-Compiler, der auf einem CE-Rechner läuft - und Programme für CE-Rechner erzeugt. Das ist für sich schon beeindruckend; aber so für sich hilft das nicht. Du willst damit ja keine Programme für CE-Rechner schreiben (also XScale-Binaries), sondern Programme für AVR. Daher musst Du "nur" noch den GCC-AVR portieren. Ob das auf einem CE-Rechner möglich ist, wirst Du selbst 'rausfinden müssen. Du solltest Dir jetzt aber wirklich mal die CF-Spezifikation ansehen. Das ist keine Schnittstelle wie ein Parallelport, sondern ein Bus-Interface, so wie ISA und PCI auch Bus-Interfaces sind. Das ganze ähnelt der PCMCIA/CardBus-Spezifikation. An so etwas kann man nicht einzelne Pins auf irgendwelche Pegel setzen. CF-Karten können zwar wie Festplatten im True-IDE-Modus angesprochen werden, der aber wird in PDAs nicht verwendet. In denen wird vielmehr der PCMCIA-kompatible Zugriffsmodus verwendet, der ein recht aufwendiges Protokoll zur Geräteidentifikation und Ressourcenverwaltung enthält.
okay zum gcc: Wenn ich den Pocket gcc am laufen hab, kann ich ja den avr gcc kompileren, damit habe ich doch ein lauffähigen avr-gcc Es ist übrigens Windows Mobile 2003. Zum CF: Schwer wird insbesonder wahrscheinlich noch die richtigen Pegel hinzubekommen. Aber ich setzt mich jetzt erstmal hin und les. Gibts da auch was kürzeres als die 150 Seiten Spezifikation? Hast du eigentlich schonmal sowas gemacht? Oder kennst du ein Projekt das sich mit CF-Device Entwicklung auseinandergesetzt hat? #grs
Sieh' Dir mal auf dieser Seite http://www.oxsemi.com/products/devboards/boards.html den letzten Eintrag an und lies' Dir das Datenblatt http://www.oxsemi.com/products/uarts/oxcf950/oxcf950ds.pdf durch. Das ist ein serieller Schnittstellenbaustein mit PCMCIA/CF-Interface. Anhand der Beschreibung solltest Du erahnen können, welcher Protokollaufwand in Hardware von Dir implementiert werden müsste.
oh Nett.. Naja Ich warte erstmal bis "er" hier ist und les mich solange noch ein Danke für deine Hilfe #grs
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.