ich habe mal irgendwo was gelesen, dass jemand ein Palm zu einem kleinem logicanalyser umgebaut hat. Hat einer entsprechende Links oder Infos? Auch alles andere zum Thema PALM-Modding/Hacking wäre interessant. Also ruhig alles zuschicken.
www.google.de/search?q=palm+logic+analyzer --> erster treffer im grunde keine grosse kunst, da der palm nur als benutzerschnittstelle herhalten muss. interessiere mich aber auch fuer alles rund um die alten palms. habe einen Vx und einen m100. werde wohl demnaechst mit hilfe von ebay ne kleine sammlung aufbauen. in die programmierung von palms bin ich auch schon mit miniprograemmchen eingestiegen. macht spass und ist als eventgesteuerte software mal was neues fuer mich. habe im moment aber leider viel zu wenig zeit fuer meine hobbys. als naechstes grosses projekt ist ein kamera-modul mit gameboy-cam fuer den palm geplant. kann aber noch eine ganze weile dauern. gruss, bjoern.
nun ja. Das habe ich auch gefunden, aber irgendwie ist da nix von einem Schaltplan geschweige denn von einem Programm zu sehen. Scheint auch irgendwie mehr oder weniger ein geplantes Projekt zu sein (dummerweise schon in Planung seit 2002) :) Nen Vx habe ich auch noch hier rumliegen. Eigentlich sollten die Dinger mit 16Mhz und mehr für alles mögliche ausreichen.
ja sind schon nette teile, vor allem wegen der langen laufzeit, bzw. dem niedrigen stromverbrauch. hab noch das hier gefunden: http://www.jwardell.com/about/seniorproj/index.html http://www.dataget.com/ wie waere es selbst ein solches projekt zu starten? hat das sinn? immerhin ist der bildschirm mit 160x160px doch schon sehr klein. desweiteren hat kaum noch jemand einen palm und der aufwand eine vernuenftige software zu schreiben ist schon sehr hoch, wenn die mehr koennen soll als nur das noetigste. der hardwareteil sollte sich jedoch recht einfach mit einem kleinen avr, oder wenns wirklich schnell sein muss, mit avr+cpld+sram loesen. insgesamt waere das eine nette sache, hat aber in meinen augen keinen grossen nutzwert. gruss, bjoern.
Naja, es gibt ja auch schickere Palm-Ausgaben; mein Sony Clié hat ein 320x320-Farbdisplay ... und damit könnte ein LA schon was hermachen.
Na, das sieht ja alles ganz nett aus, aber auch wieder nix richtiges dabei. Da muß es doch irgendwas geben. Kann ich mir nicht vorstellen, dass bisher keiner was mit den Dingern gemacht hat. Leider sieht es bei mir Zeitlich im Moment auch mehr als mau aus. Würde mich gerne mal in die Programmierung von den Dingern einarbeiten. Sinnvolle Sachen kann man damit wohl eher weniger machen. Auch die Bandbreite wird wohl kaum ausreichen um einen akzeptablen LA zu bauen. Sei denn man geht vielleicht irgendwie direkt an den Prozessor ;)
Jo Rufus. Da hast du den SJ33, oder? Den habe ich auchnoch :) Habe ne ganze Sammlung voll g
Salve, die alten Palm-Modelle haben's mir auch angetan. Da bekommt man wirklich viel Leistung und Hardware für sehr wenig Geld. Meine Palm-Projekte: Open Source Fahrradcomputer: http://veloace.sf.net -> Sollte ursprünglich auf AVR mit LCD und CF-Karte basieren. Der Palm bietet aber eine viel bessere Hardwarebasis (Touchscreen, GLCD, viel RAM) und ist mit seinen 20 Euro wesentlich günstiger als jede Selbstbaulösung. Außerdem ist der Nachbau somit denkbar einfach. Open Source AVR In-System-Programmer: http://palmavr.sf.net -> Programmer-Software für AVR109- und AVR061-basierte Programmer (STK500, Butterfly, AVR910, etc.). Bietet eine GUI zum Up-/Downloaden/Verifizieren/Identifizieren von Images, und außerdem einen grafischen Fuses-Editor, der mindestens so übersichtlich ist wie der von PonyProg. ;) Vielleicht ist das ja für den einen oder anderen Palm-User hier von Interesse. :) Mark
Jep, das waren die einzigen beiden Projekte die ich bei meiner Recherche gefunden habe. Das AVR-Dingen ist ja inzwischen schon ein bisschen bekannter und der Fahrradcomputer ist gut, aber nix für die Jahreszeit (wenn man mal von den abnormalen Temperaturen absieht). Sind aber echt gut geworden die beiden Projekte
@Mark Hämmerling palmavr benutze ich auch. vielen dank an dieser stelle fuer dieses tolle programm. ist ja doch mehr resonanz, als ich erwartet haette. man koennte ein solches projekt ja in 3 voneinander unabhaenige teile aufteilen: -hardware bzw. controller-software -palm-software -pc-software die hardware sollte sich wahlweise an palm oder normalen rechner anschliessen lassen. damit wird es auch fuer nicht-palm-besitzer interessant. desweiteren sollte eine uebertragung der auf dem palm gesammelten daten auf den rechner moeglich sein. zu den anforderungen: ich bin fuer eine moeglichst nachbaufreundliche version. das bedeutet kein cpld und kein externer ram. damit ist zwar die bandbreite stark begrenzt, sollte aber fuer den hausgebrauch durchaus ausreichen. genauso siehts bei der software aus: auf dem palm wirklich nur das noetigste, auf dem pc was praktikables ohne erweiterbare modulbauweise und sonstige spielereien. als erstes sollten wir uns gedanken um die exakten anforderungen machen. danach sollten die schnittstellen festgelegt werden und sich einzelne arbeitsgruppen bilden. wenn wir es bis dahin geschafft haben, sollte sich so ein projekt durchaus realisieren lassen. wie waere es erstmal mit einer projektseite hier im wiki? die wichtigste frage ist fuer mich aber immer noch, ob genug leute interesse an einem solchen projekt haben. gruss, bjoern.
so, und nun nochmal die korrigierte Adresse des Artikels: http://www.mikrocontroller.net/articles/Palm-Logicanalyzer damit auch rechtschreibfehlersucher zufrieden sind... gruss, bjoern.
Hi Leute Ich fände es auch ganz toll, wenn ich meinen Palm Vx als einfachen LA, zum Beispiel für I2C benutzen könnte. Da der LA offensichtlich nur für Hobby- und Amateur-Basteleien taugen wird, schlage ich vor, dass wir nach dem KISS-Prinzip vorgehen (keep it simple, stupid). Ich schlage vor, die Daten vom uC zum Palm/PC kommasepariert zu übertragen. So kann man auf dem PC mit dem HyperTerminal mitprotokollieren, und wenn man genug gemessen hat, das ganze z.B. in Excel importieren und dort nach Bedarf auswerten. Was für Software es für den Palm gibt weiss ich nicht, aber ein Terminal-Programm wird schon verfügbar sein. Ich würde folgende Modi implementieren: - Timed-Modus -> Alle Eingänge werden so schnell wie möglich ausgewertet und per RS-232 ausgegeben, das Zeitintervall ist konstant - Change-Modus -> Sobald eine Veränderung an einem der Ausgänge bemerkt wurde, wird eine Übertragung gestartet. Wenn das ganze in der Art von TIMESTAMP P0 P1 P2 P3 P4 P5 P6 P7 ------------------------------------- 00:00:01 L L H L L L L L 00:00:02 L H L L L L L L 00:00:03 L H H L L L L L 00:00:04 L H L L L L L L ausgegeben wird, dann kann man den Palm zur Seite kippen und sich den zeitlichen Verlauf schon einigermassen anschauen. Das würde IMHO für einen ersten Prototypen schon genügen. Für meine ersten Experimente muss bei mir ein MSP430F149 herhalten, welcher zweifelsfrei überdimensioniert ist (IO). Das ist der einzige uC, den ich ein wenig kenne, ich komme halt mehr aus der Software-Ecke. Zur Beschaltung werde ich also nicht all zu viel beitragen können. Just my 2 cents Tom
übertragt doch einfach daten und einen netten header... z.b timebase:1m inputs:blah-bits ... und dann die daten als block.. ggf. auch binär und nur die änderungen damit man auch langsame übertragungen schnell samplen kann (=>timingfehler suchen) ist programmtechnisch kein prob... zur pc-soft.. man schaue sich die la-soft-seite an... ;) da bei der diskussion gibts einen netten hinweis... falls mal eine funktionierende hardware haben sollte werde ich gtkwave anpassen... 73
@Tom natuerlich koennte man die werte auch in "sonderformaten" aus dem mc rausschicken, allerdings ist das reinste verschwendung an bandbreite. um ein bit zu uebertragen, waeren dann 2 ganze byte noetig. das halte ich dann doch fuer eher unwirtschaftlich. da es aber softwaretechnisch auf dem mc kein problem darstellt(und die maximale speichertiefe sowieso bei 1-4k liegt) kann man das wegen mir zusaetzlich implementieren. einen msp zu benutzen sollte kein problem sein, da sich die hardware wohl auf spannungversorgung(batterie/akku?), mc, eingangstreiber und max232 beschraenken wird. ob die software einfach portierbar sein wird, kann ich leider nicht sagen, da ich den msp nicht kenne. @Hans so oder aehnlich hatte ich mir das protokoll auch vorgestellt. im labornetzteil-artikel gibt es ein beispiel, wie man sowas konstruieren kann. die "diskussion" zur la-software habe ich schlicht uebersehen. natuerlich waere es genial, einfach bestehende software um einen "treiber" zu erweitern. man muss das rad ja nicht mit aller gewalt neu erfinden wollen. allerdings hatte ich da nur die hier entwickelte la-software im sinn, die ja definitionsgemaess universell sein soll und leicht an verschiedene hardware angepasst werden kann. da es aber im artikel schon lange keine updates mehr gab (ich gebe zu, dass ich die verschiedenen threads zum la nicht mitverfolge) bin ich davon ausgegangen, dass die sache sich im sande verlaufen hat. wenn du bereit waerst auch einen gtkwave-treiber fuer den palm-la zu schreiben, schlage ich vor, dass du dazu ein paar worte im wiki schreibst und vielleicht auch ein sinnvolles (mit dem "echten" la gemeinsames?) protokoll vorgeben kannst. wichtig waere eine abfrage, welche features der la hat(max kanaele, sampleraten, usw.), damit flexible hardwareloesungen moeglich sind. gruss, bjoern.
bei richtigen la wirds so wie ich das mitbekommen hab erst ein protokoll geben wenn es hardware gibt => es muss zuerst mal ein komplett durchkontrollierter core fertig sein... kann also noch dauern... im prinzip sollte das aber kein problem sein, da die "driver" in gtkwave eigentlich sehr ähnlich ausfallen dürften... solange die daten über die serielle wandern... oder eben über den ftdi... interessant wäre eine autobaud-funktion wobei ich mir noch nicht sicher bin ob das der la können soll oder die soft am pc... was mir da an protokol-spec einfallen würde wäre folgendes... get blah gibt blah zurück (kann baudrate,version,features,timebase,data oder status sein) set blah wie oben.. version,features und status sind aber nicht schreibbar ;) startsampling startet sampling vorgang.. beim status soll zurückkommen was denn gerade so los ist.. z.b sampling, idle, fail die timebase würde ich als zahl + prefix der einheit übegeben... z.b 100n für 100ns, 1u für 1µs... oder eben nur 1 für 1s ;) get features gibt einfach eine liste aus.. z.b max_sampling_timebase 1,min_sampling_timebase 100n,channels 8,bytes_per_sample 1 der version string ist nicht allzuwichtig.. falls aber jemand mods macht sollte das auch irgendwie erkennbar sein... mein vorschlag: SimleLA Major.Minor.build [küzel des codemassakrieren +rev oä] [küzel des nächsten codemassakrieren +rev oä] beginnend bei "SimpleLA 0.0.1" bzw wenn ich böse war und 2 patches gemacht hab "SimpleLA 0.0.1 HW1 HW2" dann weis jeder was los ist und beim supporting ists auch einfacher wenn man sieht was da für eine firmware jetzt tatsächlich läuft G das wär alles was mir bis jetzt so einfällt... wenn das "protokoll" etwas diskutiert wurde schreib ichs ins wiki... 73
autobaud: waere zumindest auf dem palm recht umstaendlich, da man dann nicht mehr auf die API zurueckgreifen kann. es ist zwar vorgesehen, eigene "treiber" fuer die serielle zu schreiben, finde ich jedoch overkill, weil es sowieso darauf hinauslaeuft 115200baud zu benutzen. und da die datenmenge ja ueberschaubar bleibt, sollten auch ftdi-nutzer mit dieser geschwindigkeit klarkommen. ich will dich jedoch nicht daran hindern, so etwas pc-seitig zu implementieren. falls es dann aufgemotzte versionen mit mehr sram gibt, wird das bestimmt interessant. andererseits sollte sich mit "kompression" einiges wieder rausholen lassen. protokoll: es kommt fuer mich so rueber, als wolltest du die befehle plain-text uebertragen. das waere zwar debug-freundlich, da per terminal benutzbar, in der auswertung jedoch recht umstaendlich. deswegen schlage ich folgende struktur vor: es werden immer 4+x byte uebertragen. das erste byte ist reserviert; das zweite enthaelt die befehlsart(get, set, get_database, set_database,..); das dritte enthaelt den eigentlichen befehl; das vierte eine weitere differenzierung des befehls; 5-n sind dann die daten. hat den vorteil, dass man mit ein paar switch- und if-konstrukten die komplette auswertung machen kann. koennte ungefaehr so aussehen: 0 1 2 3 4...n reserviert befehlsart befehl_high befehl_low daten byte1: 0x00-0x0F get la 0x10-0x1F set la 0x20-0x2F get palm 0x30-0x3F set palm byte2: byte3: byte4-n: 0x00 hw-version 0x01 sw-version 0x10 timebase 0x00 s uint16_t 0x01 ms uint16_t 0x02 ns uint16_t 0x11 trigger 0x00 "OR" uint8_t mask,uint8_t value 0x01 "AND" uint8_t mask,uint8_t value 0x02 "toggle" zb 00 00 01 00 get sw-version from la 00 10 10 01 00 0A set timebase to 10ms on la 00 10 11 00 05 01 trigger if channel 0=TRUE or channel 3=FALSE ich hoffe man kann dieses wirrwarr entziffern und versteht, wie ich das meine. muss allerdings noch ausgereift werden, da zb "get timebase from la" ja keine unterscheidung zwischen s, ms, ns braucht, dafuer aber mehrere werte zurueckgeben soll, die ausgewertet werden wollen. vielleicht waere auch ein antwort-protokoll sinnvoll, ansonsten waeren das nur die reinen daten ohne header. habe gestern angefangen meinem palm, bzw dem emulator die serielle kommunikation beizubringen. bin dabei auf folgendes problem gestossen: der palm verhaelt sich so wie es sein soll, ich sende was, es kommt was an. der emulator verhaelt sich jedoch recht zickig; wenn ich was sende landet das in irgendeinem buffer und bleibt da auch. wenn man dann ein anderes serielles prog startet(ptelnet in dem fall) und dort etwas sendet, dann wird mit einem schlag der buffer + die neuen daten uebertragen. habe dann den palm-api befehl zum buffer flushen ergaenzt(was beim hardware-palm nicht noetig war), bringt aber auch keine verbesserung. os: gentoo x86 pose: v3.5 (binary aus debian/sarge kopiert) rom: platform41_Vx_full_eng (wer mal software fuer palm geschrieben hat, weiss, dass das programm 99% der zeit auf dem emulator getestet wird und erst wenns fertig ist auf den echten palm kommt) gruss, bjoern.
naja.. soo umständlich ist es auch wieder nicht ;) nur etwas speicherlastiger...sollte aber nicht das problem sein glaubich.... vorallem wenn man am avr transitional time analysis implementiert... ob ich jetzt in einem char-array bits fischen tu oder mir mit strtok oä den string zerpflücke ist mehr oder weniger wurscht... wichtiger sind so kleine definitionen wie trigger.. die hätt ich wieder mal untern tisch fallen lassen ;) 73
denkfehler: das autobaud ist sinnvoll, gehoert dann aber auf den mc. hat sich eigentlich schon jemand gedanken um die programmierung desselben gemacht? bin leider zu unerfahren um sowas effizient zu programmieren. ausserdem sollte das ganze moeglichst resourcenschonend sein, da ja der groesste teil des srams fuer die daten gebraucht wird. gruss, bjoern. (leicht offtopic, da gegen die anforderungen verstossend: externe sram-erweiterung schonmal grundsaetzlich im hinterkopf zu haben ist dabei sicher nicht schlecht. wie siehts da eingentlich mit der geschwindigkeit von dem xmem-interface aus? brauchbar?)
was ich so im hinterkopf hab ohne waitstates möglich... das wär nicht das problem.. im übrigen wäre die verwendung eines lpc21xx vllt auch nicht schlecht ... wenn man den sram betrachtet ;) wies da aber ausschaut mit polling speed... eher schlecht als recht jenn ich das richtig im kopf hab... das ist aber meine geringste sorge muss ich zugeben... zumal es ja in der codesammlung auch ein bsp für dram gibt ;) unter mega128 wirds eh nix werden.. 1k reservier ich einfach mal für die firmware... der verbleibende rest ist zwar nicht allzuviel aber wenn man keine redundanten daten speichert dürften 1k samples (transitional time analysis) schon überbleiben... und 1000 zustandsänderungen sind doch eigentlich schon mal ein guter anfang wenn man z.b i2c sniffen will ;) 73
also meiner meinung nach kommen nur die im wiki genannten controller in frage, da als dip erhaeltlich. nicht, dass ich mich davor scheuen wuerde doppelseitige platinen zu aetzen und TQFPs zu verloeten, aber das kann halt nicht jeder. und meiner meinung nach soll es ein "volks-la" werden. ansonsten wuerde ich sowieso nen cpld+cacheram aus nem alten motherboard bzw vllt einen SAM7 nehmen, da ich mir den demnaechst mal genauer anschauen will. dass die AVRs nur sp "wenig" ram haben, ist mir allerdings auch erst aufgefallen, als ich die controller rausgesucht habe. einzig akzeptable(lochrasterfaehige) loesung stellt meiner meinung nach das xmem-interface dar. gruss, bjoern.
so, grade reichelt-bestellung rausgeschickt. atmega8515+adresslatch war auch dabei. und soweit ich das auf die schnelle aus dem datenblatt rauslesen konnte(oder eben grade nicht), macht es von der geschwindigkeit keinen unterschied, ob interner oder externer ram verwendet wird. ich kann mich also beruhigt wieder auf die programmierung des palm stuerzen, ohne im hinterkopf zu haben, wie unbrauchbar das ganze am ende wird. leider muss ich am wochenende sehr viel fuer die fh machen, mal sehen wieviel zeit da noch fuer das projekt bleibt. als erstes steht wohl nochmal grundsaetzliche planung, datenblaetter waelzen, protokollentwicklung und vorversuche auf dem programm, damit sich das chaos in grenzen haelt. gruss, bjoern.
ich verweise mal auf http://www.mikrocontroller.net/forum/read-4-121457.html ;) ein grundsätzliche frage wäre tatsächlich der speed... im prinzip ist man doch sehr eingeängt mit den 16Mhz vom AVR... bei 16Mhz sollte der dram zugriff 1-2us dauern (laut thread von oben)... sagen wir mal wir bräuchten 2us für einen zyklus... => 500khz max sampling rate... verfünftig... im prinzip dauerts dann 4s bis der ram voll das probem, das entsteht.. die refresh zyklen... die sind böse ... andere alternative... etwas ttl, sram und etwas mehr fläche ;) 74HC4060 einen netten 8 oder 16k sram und einen schnellen latch.. der 4060 kann max 87Mhz ;) weils nachbaubar sein soll... sram der günstig ist.. 3-5e bei 12-50ns zugriffszeit => 20-83Mhz max sampling rate.. also auf jeden fall schneller als der AVR takt generiere kann... => 0815latch sollte auf jeden fall reichen... den avr lässt man dann einfach nur toggeln.. das sollte eigentlich mit 8Mhz möglich sein...wobei dann müssten 16k im flash nur getoggle sein.. also eher um die 3mhz max.... da könnte man aber mit etwas ttl.. noch was machen.. sprich noch einen lustigen 4060 hernehmen und den mit einem z.b 64Mhz oszillator paaren ;) => 15 timebases von 64Mhz bis 3,6KHz... dazu noch ein bisserl mehr logik um die jeweilige timebase auswählen zu können... naja... kingt gut aber aufwendig... aber die zähler-sram kombination dürte der einfachste weg sein schnell zu samplen.. ich würde sagen 80mhz sind sicher drinnen.. taktgeneration muss noch überlegt werden... der avr kann dann richtig niedlich sein ;) ich würde sagen 5e für ram, 5e für avr und 5e für den rest (max232,spannungsversorgung,75hc4060,..) viel billiger dürfte es nicht machbar sein... ich bin mal für ein irc meeting... wann ist denn wer von euch so im irc ??? 73
für die, die das oben etwas zu wirr finden... http://www.avrfreaks.net/index.php?module=FreaksTools&func=viewItem&item_type=tool&item_id=318 timebase-generation muss ich mir noch überlegen...
<buhmannmode> auch auf die gefahr hin mich unbeliebt zu machen, muss ich das mal so klar sagen: wir sollten auf dem teppich bleiben! fliegen koennen wird der LA aus dem "richtigen" LA-projekt. nicht ohne grund werden da so sachen wie perfektes(doppelseitiges oder besser eigentlich vier-lagiges) layout, hoher schaltungsaufwand, aktive probes, riesige cplds und was sonst noch noetig ist, um auf akzeptable sampleraten(>50Mhz) zu kommen, ohne dass ein "cat /dev/urandom" in etwa das gleiche ergebniss liefern wuerde. die wuerden dumm gucken, wenn wir aus bauteilen fuer unter 20euro mal eben einen 80mhz la auf lochraster herzaubern. </buhmannmode> dram waere zwar schoen gross, aber wie ja schon erwaehnt mit 1-2µs doch recht langsam. hinzu kommem die refreshcycles(oder sind die in der rechnung vllt schon drin?). im vergleich dazu(ich kann nicht wirklich assembler): [lade endadresse des ram zu vergleichen] loop: in tmp, port 1cycle (store with increment) 2cycles cmp aktuelleadresse, endadresse 1cycle brne loop 2cycles unter der vorraussetzung, dass der externe ram in 2 zyklen angesprochen werden kann, und unter nichtbeachtung, dass die adressen wohl 16bit-werte sein muessten, kommt man bei 14Mhz takt auf knapp ueber 2Mhz. (man koennte ja nur das high-byte vergleichen und auf die letzen 256 werte aus dem low-byte verzichten-->ich hoffe man verstehts). aber wiegesagt, ich bin nicht erfahren genug um sowas auch in der praxis effizient umzusetzen. bleibt noch die frage nach dem ripple-counter. war auch mein erster gedanke, um die samplerate hochzujagen. hat nur einen kleinen schoenheitsfehler. woher weiss der counter respektive die taktquelle, wann es losgeht mit dem samplen? sprich triggerung ist dann nicht mehr moeglich. klar koennte das der avr machen, nur halt nicht so schnell. also triggerlogik+counter in nen cpld packen und schon sind wir wieder bei smd-bauteilen und weitaus hoeherem aufwand. insgesamt waere ich mit 1-2mhz und 16-64kb speichertiefe mehr als zufrieden. das ist mit "einfachsten" mitteln moeglich, stellt keine grossen anforderungen an das platinenlayout(ob lochraster die 2mhz mitmacht, muessen experimente zeigen; denke aber schon) und sollte erstmal realisiert werden(was schon aufwand genug ist). da das protokoll aber offen liegt, steht es jedem frei spaeter auf dieser basis diverse hardware zu realiesieren(pimp my la). so, genug meinen standpunkt vertreten, diskussion erwuenscht, gruss bjoern.
saetze die grammatisch keinen sinn ergeben, bitte selbstaendig sinnvoll ergaenzen. ach ja, im irc bin ich 24/7, einfach meinen nickname schreiben, bekomme dann ein akkustisches bing. gruss, bjoern.
kurzes update: hardware: es hat ein langer core-entwickler-chat stattgefunden. dabei wurde sich auf eine vorlaeufige hardwareversion geeinigt. erste prototypen sind realisiert worden. kleines wiki-update zur software. palm: nichts neues. der emulator weigert sich immernoch sich so zu verhalten, wie er soll. gesucht wird noch ein erfahrener avr-programmierer mit asm-kenntnissen um das letzte aus dem avr rauszuholen. weitere wiki-eintraege werden im laufe des wochenendes folgen. persoenliches fazit: so langsam nimmt die sache form an. gruss, bjoern.
kurzes lebenszeichen von mir. die emulatorprobleme sind zwar laengst geloest, aber die zeit noch knapper geworden. sowohl palm-soft als auch mein prototyp gammeln seit meinem letzten eintrag vor sich hin und warten drauf, dass es weiter geht. das projekt ist aber keinesfalls untern tisch gefallen. einzig der zeitplan wird noooooch weiter gedeeeeehnt. @Hans: gibts bei dir was neues? gruss, bjoern.
Hallo Björn, gibt es schon was Neues? Kann man evtl. schon mal den Prototypen, Schaltpläne, Quellcode oder irgendwas bestaunen? Frank
aufsdatumvomletztenpostschau Wie doch die Zeit vergeht... Leider gibts immer noch nichts neues. Das Projekt liegt erstmal auf Eis, bis ich wieder mehr Zeit habe. Wird aber auf jeden Fall noch realisiert. gruss, bjoern.
Hallo Björn, Hans und alle anderen, könnt ihr nicht mal die vorläufigen Stände Eurer Arbeit hier posten. Vielleicht findet sich ja der ein oder andere, der das dann aufgreift und ein paar Dinge dazu beiträgt. Frank
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.