Hallo, scheinbar gibt es bei Pollin mal wieder zum basteln/hacken. http://www.pollin.de/shop/dt/Njg1NzMxOTk-/Fundgrube/Freizeitartikel/Fitness_Planner_VIVONIC.html Lohnt sich der Kauf oder ist das Gerät nur Schrott bzw. hat sich schon jemand damit befasst ?
Ich bin aus leidvoller Erfahrung von Pollin Schnäppchen geheilt. Ich möchte keine Zeit mehr in solche Hack Angebote investieren, die dann doch nur als Sondermüll entsorgt werden müssen. Briefbeschwerer und "Door Stopper" von dieser Firma habe ich mehr als nötig. Otto
Otto schrieb: > Briefbeschwerer und > > "Door Stopper" von dieser Firma habe ich mehr als nötig. Das ist das doch optimal für Dich?!
Wenn die Abbildung im ausgeschalteten Zustand ist, wird das wohl ein segmentiertes Display mit Maske sein....
>Die Menü Sprache
Jetzt können selbst die Pollinmitarbeiter kein Deutsch mehr...
Falls es jemanden interessiert, was drin ist http://www.surplusgizmos.com/Vivonic-Fitness-Planner-w-accelerometer-adxl202-180x180-touchscreen-LRH6W51113A-vivonics_p_1798.html
It is very similar to a Palm Pilot and fairly small. It actually uses the same CPU as the early palm pilots. Das Ding scheint ja doch nicht so schlecht zu sein.
Hat schon jemand so ein Teil bestellt? Laut Datenblatt http://www.datasheetcatalog.org/datasheet/motorola/MC68EZ328.pdf hat der MC68EZ328 einige interessante Features: - LCD Controller: Software programmable screen size (up to 640*512) to support single (Non-Split) monochrome panels - Bootstrap Mode Function: Allows user to initialize system and download program/data to system memory through UART
M. G. schrieb: > - Bootstrap Mode Function: Allows user to initialize system and download > program/data to system memory through UART Hab' mir für 4€ einen mitbestellt. Einen Accelerometer-Schrittzähler wollte ich schon immer mal haben... Im Batteriefach gibt es neben einem Loch für den Resettaster auch eins, hinter dem sich ein Schiebeschalter verbirgt. Wenn ich den umlege, antwortet der PDA über das mitgelieferte RS232-Kabel bei 9600 baud auf das erste Zeichen mit einem '@'. Alle weitere werden geechot. Das passt genau zum Verhalten des im Datenblatt dokumentierten Bootloaders...
Bild vom Inneren: http://www.surplusgizmos.com/Vivonic-Fitness-Planner-w-accelerometer-adxl202-180x180-touchscreen-LRH6W51113A-vivonics_p_1798.html
Anbei ein paar bessere Fotos.
Ein paar weitere Erkenntnisse: - Der Hersteller scheint tatsächlich von der "fully static operation" Gebaruch zu machen, und dem System beim "Ausschalten" lediglich den Takt wegzunehmen: Das Umlegen des EMUBRK-Schalters wird bis zum nächsten Druck der Resettaste ignoriert, auch wenn ich zwischenzeitlich für 5 Minuten die Akkus entferne. D.h., man bräuchte eigene Software nicht unbedingt zu flashen: Über den Bootstrap-Mode in den SRAM geladen, könnte sie solange überleben, bis der Supercap trocken läuft. - Vorsicht beim Spielen im Bootstrap-Mode. Ich hab' gestern wohl einen Portpin getoggelt, an dem das Display hängt. Nun hab' ich 'ne dunkle Zeile auf dem Display, die sich nur gaaanz langsam zu erholen scheint.
Kommt man an die IRDA sowie RS232 Schnittstelle ran ? Wie sieht es mit dem Display aus, kann man das nachträglich Hintergrundbeleuchten ? Ansonsten sieht es gut aus, FreeRTOS sowie RTEMS sollten darauf problemlos laufen, Linux wenn auch möglich hat aber größere Speicherprobleme mit der Fragmentierung desselben bei längerer Laufzeit.
chris schrieb: > Kommt man an die IRDA sowie RS232 Schnittstelle ran ? Ja, der UART ist über den MAX3221E und eine 2.5mm-Klinkenbuchse ausgeführt. Ein passendes Klinke-auf-DE9-Kabel liegt bei. Der EMUBRK-Schalter ist im Batteriefach zugänglich, man kann also ohne Gehäuseöffnen oder Löten direkt das System übernehmen. > Wie sieht es mit dem Display aus, kann man das nachträglich > Hintergrundbeleuchten ? Sieht mir nicht durchleuchtbar aus. Wenn ich es mit 'ne 3W-LED-Taschenlampe von hinten anleuchte, kommt vorne kaum was raus. Und neben Modellnummeraufkleber ist auch ein Folienleiter an der Rückseite festgeklebt.
chris schrieb: > Wie sieht es mit dem Display aus, kann man das nachträglich > Hintergrundbeleuchten? Das ist ein reflektives, kein transflektives Display. Um das zu beleuchten, müsste die reflektive Folie auf der Rückseite entfernt werden und das Display auf eine gut und gleichmäßig ausgeleuchtete Leuchtplatte gesetzt werden. Da sehe ich keine reelle Chance.
Angehängte Dateien:
-
action.jpg
150 KB
Hab' am Wochende noch ein wenig dran gepuzzelt, und konnte mit dem m68k-gcc und den m68k-binutils display und touchscreen in Betrieb nehmen. Viele der magischen Werte hab' ich im Flash gefunden - der Inhalt läßt sich mit dem angehängten flashdump.c auslesen und mit objdump wieder in Assembler übersetzen.
Angehängte Dateien:
-
spi.jpg
38 KB
Weiteres bastelrelevantes: - Der Touchscreencontroller hat zwei scheinbar unbenutzte ADC-AUX-Eingänge (12bit/150kHz). - Über SPI könnte man - ohne an den TQFP-CPU-Beinchen löten zu müssen - eigene Erweiterungen anbauen: SPITX/RX/CLK kann man an Vias anlöten (Bild), als Chip-Select würde sich das unten genannte PIC_CLK am riesigen SOIC8-PIC anbieten. - Zu Accelerometer/PIC: An die Beschleunigungswerte kommt man scheinbar nicht direkt :-/. Die einzige Kommunikation mit dem PIC (an dem das MEMS hängt), die ich im Flash gefunden habe, liest einen int mit der Schrittanzahl:
1 | #define PIC_PDIR PDDIR
|
2 | #define PIC_PDATA PDDATA
|
3 | #define PIC_VSS (1<<1) /* out, 1 to power PIC and MEMS? */ |
4 | #define PIC_DAT (1<<2) /* in */ |
5 | #define PIC_CLK (1<<3) /* out */ |
6 | |
7 | /* This function reads an int from the PIC. */
|
8 | /* The lowest byte seems to be "steps since previous read" */
|
9 | #define PIC_READ_FUNC ((int(*)())0x803d48)
|
- Die "invalid-level"-Leitung des MAX3221E hängt an IRQ1. Das schreit geradezu nach Einsatz als Luxus-Fahrradcomputer unter Verwendung eines Reedschalters zwischen Spitze und Ring eines Klinkensteckers :-). Leider gäbe es da das mechanische Problem der Lenkerhalterung zu lösen... Das Holster hilft hier nicht, da es das Display verdeckt :-/
ansel schrieb: > - Die "invalid-level"-Leitung des MAX3221E hängt an IRQ1. Das schreit > geradezu nach Einsatz als Luxus-Fahrradcomputer unter Verwendung > eines Reedschalters zwischen Spitze und Ring eines > Klinkensteckers :-). Leider gäbe es da das mechanische Problem der > Lenkerhalterung zu lösen... Das Holster hilft hier nicht, da es das > Display verdeckt :-/ Vielleicht könnte man vorsichtig denjenigen Teil des Holsters wegschneiden, der das Display verdeckt?
M. G. schrieb: > Vielleicht könnte man vorsichtig denjenigen Teil des Holsters > wegschneiden, der das Display verdeckt? Hmm, das würde bedeuten, den Großteil der Rückseite auszusägen... Es scheint aus recht dickem ABS[1] zu sein, also mechanisch ginge das vielleicht sogar. Allerdings wäre das Display dann 5mm versenkt, und weiträumig Aussägen, um Schatten zu vermeiden, scheint problematisch zu sein, da direkt neben dem Display zwei Schienen im Holster sind, die vermutlich für die Klemmwirkung nötig sind. Ich hab' mich auch mal bei den VeloAce-Leuten umgeschaut, und auch prompt Bestätigung gefunden: "Mounting the PDA to your bike might be the trickiest step". Die Lösungen, die ich da gesehen hab', scheitern jedoch wegen der rundlichen Rückseite des Vivonic. Footnotes: [1] Mit Aceton anlösbar, Brennprobe steht noch aus :-).
Hallo zusammen, ich habe auch einige dieser "Türstopper" bestellt, die hoffentlich diese Woche noch bei mir eintrudeln werden, um bei schlechtem Sommer-Regen-Wetter die Schulferien zu gestalten. Die Beiträge von ansel haben mich motiviert hier einzusteigen. Zurzeit bin ich dabei die cross tool chain unter debian aufzubauen und würde in diesem Zusammenhang gerne Tips erhalten. Ich gehe nach diesem Artikel http://www.mikrocontroller.net/articles/GCC_M68k vor. Wenn Du, ansel, oder sonst wer, eine andere Tool chain verwendet, würde ich gerne erfahren, welche. An der bereits teilweise disassemblierten Firmware bzw. den Parametern für objdump wäre ich auch interessiert - man muss nicht unbedingt alle Arbeit doppelt machen. Was habe ich vor? Nun, ich denke es handelt sich hier um eine interessante, im Zweifelsfalle wertfreie intellektuelle Herausforderung. Wenn erfolgreich programmierbar, haben mein Junior und ich vor, ein Schulprojekt "Einführung in die Programmierung mit C" anhand dieser Kisten durchzuführen. Haben sowas schon mal mit Atmega8 und einer LED-Matrix gemacht und waren sehr erfolgreich. Die 68K CPU ist sicher nicht mehr der Renner, aber für 4 EUR hoffen wir eine brauchbare CPU/Display/Eingabeeinheit zu erhalten, die man für ein Schülerprojekt als kostengünstige Beigabe verwenden kann. So können die Teilnehmer am Ende etwas Vorweisen. Gruß swausd
swausd schrieb: > Zurzeit bin ich dabei die cross tool chain unter debian aufzubauen und > würde in diesem Zusammenhang gerne Tips erhalten. Ich gehe nach diesem > Artikel http://www.mikrocontroller.net/articles/GCC_M68k vor. Wenn Du, > ansel, oder sonst wer, eine andere Tool chain verwendet, würde ich gerne > erfahren, welche. Ich hab' meine GNU-m68k-Toolchain vor ein paar Jahren mal durch ein Shellscript von rockbox.org holen und bauen lassen. > An der bereits teilweise disassemblierten Firmware Ich habe bewusst nur die Mittel zum Dumpen der Firmware veröffentlicht, und nicht Teile der Firmware selbst. Urheberrecht. > bzw. den Parametern für objdump wäre ich auch interessiert - man muss > nicht unbedingt alle Arbeit doppelt machen. m68k-elf-objdump -b binary -m m68k -D dump.bin > dump.asm > Was habe ich vor? Nun, ich denke es handelt sich hier um eine > interessante, im Zweifelsfalle wertfreie intellektuelle Herausforderung. > Wenn erfolgreich programmierbar, haben mein Junior und ich vor, ein > Schulprojekt "Einführung in die Programmierung mit C" anhand dieser > Kisten durchzuführen. Haben sowas schon mal mit Atmega8 und einer > LED-Matrix gemacht und waren sehr erfolgreich. Die 68K CPU ist sicher > nicht mehr der Renner, Ack, mit 'nem ARM anstelle des m68k wären die Dinger vermutlich nicht über ein Jahr in Maxs Regal gelegen :-)
Vielen Dank ansel, für die Rückmeldung und für die Vorarbeiten. Ich habe meine Tool chain aufgebaut und anhand Deines malefiles kann auch das Ziel generiert werden. Mal sehen, wenn die Geräte da sind, ob ich sie auch zum Laufen bringe. Gruß swausd
Für den, den es interessiert: Dank der Quelltexte und Infos von ansel (sehe weiter oben) habe ich die Fitness Trainer nun mit den ersten eigenen Programmen zum Laufen bekommen. Mit der Entwicklungsumgebung habe ich etwas Probleme gehabt, da compiler-interne Unterprogramme beim linke nicht gefunden wurden (z.B. __divsi3 und mulsi3). Die habe ich dann als Quelltext aus dem Netz gefischt und einzeln übersetzt und angelinkt. Könnte man bei Gelegenheit noch weiter untersuchen. Zunächst ist es so ok. Ein weiteres Problem war, dass die über die serielle Schnittstelle ins RAM geladenen Programme zuweilen nach trivialsten Änderungen nicht mehr liefen. Ursache war wohl fehlendes alignment der Speicherbereiche, die ich über ein Linker-Script etwas angepasst habe. Seit dem gibt es keine Probleme. Für das Laden über die serielle Schnittstelle gibt es im Netz unter dem Stichwort ezsimm ein Kermit skript. Mit dabei ist auch ein Programm zum flashen des internen Flash Roms. Das müsste wie ich es einschätze funktionieren oder anpassbar sein. Mal sehen ... Bewertung: Für mich stellen die Geräte ein "Schnäppchen" dar. Für 4 EUR erhält man ein handheld device mit leistungsfähigem Prozessor, Speicher, Touch LCD Display mit brauchbarer Auflösung und serieller Schnittstelle. Als Terminal für andere embedded devices gut zu verwenden. Außerdem sind diese Teile eine sehr gute Ausgangsbasis, um das hacken von kostengünstigen Massenartikeln zu "lernen". Die Hardware ist gut dokumentiert, Tools gibt es auch. Und als Sudoku Station ist das Ergebnis immer noch attraktiv. Ein Android Handy hat zwar GSM, WIFI, 1GHz Prozessor usr. aber ein hohe Komplexität, so das diese Geräte für viele Bastler doch zu komplex sind. Außerdem bekommt man die nicht für 4 EUR. Falls ernsthaftes Interesse besteht, kann ich gerne weiter ins Detail gehen. Gruß swausd
Erst einmal ein großes Dankeschön an die Pioniere hier. ;) Ich verfolge die Sache mit Interesse, muß jedoch erst einmal ein lauffähiges Linuxsystem zur Verfügung haben. Feedback folgt, wenn ich die Zeit dazu finde.
swausd schrieb: > Falls ernsthaftes Interesse besteht, kann ich gerne weiter ins Detail > gehen. Ja bitte, das wär prima. Ich habe mir auch so ein Teil gekauft, bin aber bis jetzt leider noch nicht dazu gekommen, damit zu experimentieren. Ich möchte es gerne als Terminal für andere embedded devices verwenden.
Hallo zusammen, nachdem ich nun drei PCs eingerichtet habe, anbei eine kurze Beschreibung der Einrichtung einer Tool Chain und ein kleines Beispiel Projekt für Geany. Es erfolgt ein einfacher Grafik Test. Touch wird (noch) nicht unterstützt. Anzumerken ist, dass das Alignement des Bildschirmspeichers noch zu prüfen ist. So wie in einem anderen Post von Ansel angegeben, ist es nicht optimal und auch nicht notwendig. Der Speicher wird schnell sehr zerklüftet. Zu beachten ist auch, dass die Speicherbereiche ein Alignement 4 zu brauchen scheinen. Sonst brechen Programme sporadisch nach einfachen Änderungen ab. Ich habe versucht es durch ein Linker Script hinzubekommen. Da ich kein linux bzw. gcc Experte bin, ist alles ein wenig hingebastelt. Wenn jemand bessere Lösungen hat, bitte melden. Im zip Archiv gibt es im Ordner Projekte eine README mit der Beschreibung. Die Datei build.sh enthält ein shell script für den Tool Chain build. Gruß swausd
Hallo Sportsfreunde, hier ein Proof of Concept, der nachweist, dass der Flash Speicher gelöscht und neu beschrieben werden kann. Aber Achtung: Nur benutzen, wenn Ihr sicher seid, dass der zu löschende Adressbereich für Euch unproblematisch ist. Laut Datenblatt des Speichers sind die Blöcke 64K und im Boot Block 8K Bytes groß. Es wird immer ein ganzer Block gelöscht! Schreiben geht auch in kleineren EInheiten. Ausgelegt habe ich die Routinen für 16 Bit Worte. Byte-weises Schreiben habe ich nicht hinbekommen. Weiterhin beachten, dass Programme nicht einfach in den Flash geschreiben werden sollten, ohne vorher die start.s datei mit einer entsprechenden Initialisierung zu erweitern und die Reset und sonstigen Vectoren zu berücksichtigen. Vielleicht versucht sich jemand daran. BTW. noch gibt es diese "Türstopper" bei Pollin ... Gruß swausd
Angehängte Dateien:
-
ausverk.png
4,2 KB
swausd schrieb: > Für mich stellen die Geräte ein "Schnäppchen" dar. Für 4 EUR erhält man > ein handheld device mit leistungsfähigem Prozessor, Speicher, Touch LCD > Display mit brauchbarer Auflösung und serieller Schnittstelle. Als > Terminal für andere embedded devices gut zu verwenden. Als Pollin auf 3€ nachgelegt hat, konnte ich nicht widerstehen, meine Sammlung auf sieben Stück zu vergrößern :-) Angedacht sind mal: - Fahrradcomputer a la VeloAce - Si570-VFO mit BNC-Pigtail für den Basteltisch - Gehirn im Schreibtischroboter > Und als Sudoku Station ist das Ergebnis immer noch attraktiv. Auch 'ne gute Idee - In Sachen Laufzeit sticht die energiesparende Hardware wohl jedes Smartphone aus. Ich bin zwar kein Sudokuspieler, aber in Verbindung mit einer individuellen Belohnungsfunktion könnte es ein nettes Geschenk werden. Sebastian schrieb: > Erst einmal ein großes Dankeschön an die Pioniere hier. ;) Ich verfolge > die Sache mit Interesse, muß jedoch erst einmal ein lauffähiges > Linuxsystem zur Verfügung haben. Feedback folgt, wenn ich die Zeit dazu > finde. Die Entschuldigung lasse ich nicht durchgehen - Die Toolchain ist Betriebssystemunabhängig :-) swausd schrieb: > Anzumerken ist, dass das Alignement des Bildschirmspeichers noch zu > prüfen ist. So wie in einem anderen Post von Ansel angegeben, ist es > nicht optimal und auch nicht notwendig. Der Speicher wird schnell sehr > zerklüftet. In Sachen Display wird wohl jeder seine eigene Suppe kochen. Beim Terminaleinsatz wird man vermutlich LSSA über den halben SRAM wandern lassen, um ohne zeitraubende Kopieraktion zu scrollen. Bei Animationen dagegen wäre double-buffering unverzichtbar. Die Mandelbrotmenge sieht vermutlich in Graustufen besser aus... Ich hab' halt zum ersten Mittel gegriffen, welches mir eingefallen ist, und die Anforderungen des DMA-Controllers garantiert. swausd schrieb: > hier ein Proof of Concept, der nachweist, dass der Flash Speicher > gelöscht und neu beschrieben werden kann. Super! Dann rückt auch ein HP48-Emulator in den Rahmen des machbaren. Das Original war mir bisher zu schade, um es regelmäßig als Ladungszähler am rs232-Multimeter mit zum 6W-Solarpanel in's Gras zu werfen.
ansel schrieb: > die energiesparende Hardware Ganz vergessen: Numbercrunchen, Display an: 38mA PLL und Display aus, CPU wartet auf Interrupt: 600µA In letzterem Fall war der MAX3221 an, der sich laut Datenblatt 300µA genehmigt. Ich vermute mal, der Rest geht hauptsächlich für den Switcher drauf, zu dem ich noch kein Datenblatt gefunden habe :-/
Oha, alles ausverkauft ... da habe ich wohl die letzten für 4 eur bekommen. Einen habe ich auch noch auf Garantie ausstehen. Mal sehen, ob der noch geliefert wird. Ansonsten habe ich mich aber ausreichend eingedeckt :-)) Nur zur Info, damit wir keine Doppelarbeit machen. Ich habe vor mich wegen eines Simulators umzusehen, um die vorhandene Firmware etwas besser zu verstehen. 68k Assembler ist mir bisher noch nicht unter gekommen, so dass es etwas mühsam ist, den Code-Dump zu verstehen, Insbesondere der Ein/Ausschalter sollte wohl verstanden werden. Versucht habe ich Easy68k. Der erzeugt auf meinem 64 bit Windows 7 PC aber unsinnige .s68 Dateien aus dem Flashdump. Werde das mal auf einem 32 bit Windows versuchen. Die Ausführungen von Ansel zum Display ram zeigen, dass ich das noch nicht vollständig verstanden habe. Da steckt wohl einiges an Potential drin. Die hoch-Zeit dieser CPU habe ich wohl irgendwie verschlafen. Zwischen Z80 und Atmega hatte ich eine Auszeit in Sachen Embedded-Systeme und habe mich mehr mit Software beschäftigt. Gruß swausd
ansel schrieb: > swausd schrieb: >> Anzumerken ist, dass das Alignement des Bildschirmspeichers noch zu >> prüfen ist. So wie in einem anderen Post von Ansel angegeben, ist es >> nicht optimal und auch nicht notwendig. Der Speicher wird schnell sehr >> zerklüftet. > > In Sachen Display wird wohl jeder seine eigene Suppe kochen. Beim > Terminaleinsatz wird man vermutlich LSSA über den halben SRAM wandern > lassen, um ohne zeitraubende Kopieraktion zu scrollen. Bei Animationen > dagegen wäre double-buffering unverzichtbar. Die Mandelbrotmenge sieht > vermutlich in Graustufen besser aus... Ich hab' halt zum ersten Mittel > gegriffen, welches mir eingefallen ist, und die Anforderungen des > DMA-Controllers garantiert. Ansel, Du scheinst Dich bezüglich der Grafikansteuerung gut auszukennen. Hast Du da eine Quelle (außer dem User Guide der CPU) die Du zum Studium empfehlen kannst? Zum Alignment des Grafikspeichers ist jetzt wohl (fast) alles gesagt. Wichtig ist aus meiner Sicht das Alignment der anderen Speicherbereiche (wie oben von mir ausgeführt), weil sonst die Programme abbrechen. Deshalb das Linker Script. Zum Ausverkauf: Habe heute von Pollin die Bestätigung erhalten, dass ein Ersatzgerät für das defekte Teil zu mir unterwegs ist. Also werde nun wohl das aller letzte Gerät erhalten ;-) Gruß swausd
swausd schrieb: > Ansel, Du scheinst Dich bezüglich der Grafikansteuerung gut auszukennen. > Hast Du da eine Quelle (außer dem User Guide der CPU) die Du zum Studium > empfehlen kannst? Leider nein, mein Wissen in Sachen Grafikprogrammierung hat sich bis ca 1998 angesammelt. Damals ging's drum, möglichst spektakuläre Sachen auf DOS-PCs zu machen. Die genannten Konzepte sind jedoch relativ einfach, und sollten sich durch Googeln/Wikipedia offenbaren. > Zum Ausverkauf: Habe heute von Pollin die Bestätigung erhalten, dass ein > Ersatzgerät für das defekte Teil zu mir unterwegs ist. Also werde nun > wohl das aller letzte Gerät erhalten ;-) Hmm, hier lässt die Versandbestätigung beunruhigend lange auf sich warten... Gruß Andreas
Habe heute auch meinen vivonic erhalten. Ist das bei euch auch so, dass die Gummieinfassung total eklig klebrig ist? Vielleicht wegen der Hitze? Macht keinen Spaß das Ding anzufassen denn sogar die Pfoten kleben danach noch ne Weile :-(
seb.r schrieb: > Habe heute auch meinen vivonic erhalten. Ist das bei euch auch so, dass > die Gummieinfassung total eklig klebrig ist? Vielleicht wegen der Hitze? > Macht keinen Spaß das Ding anzufassen denn sogar die Pfoten kleben > danach noch ne Weile :-(Beitrag melden Bearbeiten Löschen Ja, einige Geräte sind bei mir auch in diesem Zustand. Werde die bei Gelegenheit mit einem Lösungsmittel behandeln (Alkohol oder Benzin). Mal sehen, ob das eine Verbesserung bringt. Ansonsten habe ich "genügend" Geräte, die nicht kleben. Zur Info: Habe gestern mit dem 68000 Emulator Easy68K erste Erfahrungen gesammelt. Wenn man aus dem Flash-Dump mit srec_cat eine Datei im Motorola Format erstellt, kann diese im Simulator eingelesen werden. Die Erstellung einer entsprechenden Datei mit den Utilities aus dem Easy68K-Paket habe ich nicht hinbekommen. Lag nicht an 64 Bit Windows. Ich vermute einen Programmfehler. Leider muss mann den disassemblierten Code in einem extra Fenster daneben halten, da Easy68k nur ein minimalstes disassembling der Befehle am Programcounter vornimmt. Egal, der Simulator ist besser als Raten. Werde heute mal den Einsatz von Breakpoints testen. Das habe ich gestern noch nicht hinbekommen, weil der Dialog nicht ausreichend intuitiv ist. Nach dem Lesen der Anleitung bin ich aber optimistisch. Gruß swausd
swausd schrieb: > Ja, einige Geräte sind bei mir auch in diesem Zustand. Werde die bei > Gelegenheit mit einem Lösungsmittel behandeln (Alkohol oder Benzin). Mal > sehen, ob das eine Verbesserung bringt. Ansonsten habe ich "genügend" > Geräte, die nicht kleben. Zuzmindest Isopropanol bringt absolut nix. Naja erstmal abwarten was daraus noch wird :)
Das mit der klebrigen Gummibeschichtung scheint das gleiche Problem wie beim Psion 3c zu sein. In den entsprechenden Foren werden diverse Mittel von mechanischer Gewalt bis hin zu Butter als Abhilfe diskutiert. Mit unterschiedlichen Erfolgen. Vielleicht ist ja ein Teil dieser Erkenntnisse übertragbar.
Sebastian schrieb: > Das mit der klebrigen Gummibeschichtung scheint das gleiche Problem wie > beim Psion 3c zu sein. In den entsprechenden Foren werden diverse Mittel > von mechanischer Gewalt bis hin zu Butter als Abhilfe diskutiert. Mit > unterschiedlichen Erfolgen. Vielleicht ist ja ein Teil dieser > Erkenntnisse übertragbar.Beitrag melden Bearbeiten Löschen Ich habe es gestern an zwei Geräten ausprobiert. Das leichte Abreiben mit Feuerzeug- bzw. Waschbenzin (nicht E10 Supersprit;-) aus dem Baumarkt hilft definitiv. Das Gerät ist danach wieder wie neu und hat eine gleichmäßig, matte, nicht klebende Oberfläche.
Oops, kleine Korrektur zu meinem tarball: ¬LCDON ist gar keine Steuerleitung, sondern ein Ausgang des MAX686. POK des MAX686 hängt über einen Spannungsteiler an Vbat, womit ¬LCDON zur Batteriespannungsüberwachung verwendet werden kann. Der MAX686 kann also gar nicht abgeschaltet werden, da ¬SHDN fest an Vcc hängt. So langsam wird klar, wohin die 300µA im Tiefschlaf verschwinden...
1 | /* NLCDON is wired for battery monitoring, threshold approx. 1.25V.
|
2 | Open drain, needs internal pullup. */
|
3 | #define MAX686_NLCDON_PUEN PDPUEN
|
4 | #define MAX686_NLCDON_PDATA PDDATA
|
5 | #define MAX686_NLCDON (1<<7)
|
ansel schrieb: > für den Switcher drauf, zu dem ich noch kein Datenblatt gefunden > habe :-/ Hat sich erledigt: Hinter dem "S06A" verbirgt sich wohl ein LM2621.
Hallo, da morgen hier in NRW die Schule wieder anfaengt und ich fuer die Freistunden was zu tun brauche hab ich meine Vivos mal ausgepackt. Mit dem Script aus der vivo.zip ne Toolchain gebaut,(i386, amd64, sparc32, ppc - kann Binaries hochladen wenn gewuenscht). Das Hello-World aus der tgz laeuft prima. Die Grafikdemo tut auf 3 geraeten GAR NICHTS und auf einem kommt eine einzige blinkende Zeile.. Gibts irgendwelche neuen erkenntnisse (oder mal eine fertige brec um das mal gegenzutesten..) darueber die das erklaeren koennten Gruess Martin.
Sorry fuer den DoppelPost, ich hab das Touch+Display Beispiel angeworfen, es bilden sich oben rechts im Display von selber Punkte. Kommt man bei dieser Touchansteuerung an die Z-Koordinate (Druck)
Martin B. schrieb: > es bilden sich oben rechts im Display von selber Punkte. Ist hier auch der Fall, wenn ich die Sensorwerte einfach ungeprüft zum Display durchreiche. (Siehe Foto oben). > Kommt man bei dieser Touchansteuerung an die Z-Koordinate (Druck) Ich vermute mal, dafür ist BBADS7843_IRQ (vivo.h) gedacht, im Datenblatt auch PENIRQ genannt. Ansonsten kann man mit etwas filtern bestimmt auch echte Berührung erkennen, da die falsche sehr viel stärker rauscht.
Hallo Sportsfreunde, anbei einige Infos zum Touch-Display. Der Anschluss PENIRQ des ADS7843 ist nur aktiv, wenn im Modus "power down between conversions", also PD1 und PD0 = 0. SIehe Datenblatt von TI und diverse Diskussionen im Netz. Ich habe mein Programm aus vivo.zip etwas angepasst und nach dem Grafik-Test einen Touch-Test ergänzt. Es werden die x und y Koordinaten im Hex-Format auf dem UART ausgegeben bzw. 0xffff (-1), wenn touch nicht betätigt. Nicht im Programm eingebaut sind folgende Zeilen void touchWaitDown(void) { while (BBADS7843_IRQ_PDATA & BBADS7843_IRQ) ; } void touchWaitUp(void) { while (!(BBADS7843_IRQ_PDATA & BBADS7843_IRQ)) ; } mit denen nun auch PENIRQ abgefragt werden kann. Funktioniert genau so bei mir. Eine INT05 Auslösung ist somit auch möglich, von mir bisher aber noch nicht ausprobiert Die Implementieurung wird hier zur Übung aufgegeben ;-) Im beigefügten Archiv ist ein main.brec, das von Hand ab 0x100 gestartet werden muss. Alternativ kann die Datei main-autostart.brec verwendet werden. Diese startet nach dem Download automatisch. Falls Kermit wie im README beschrieben benutzt wird, erfolgt dann allerdings keine Anzeige der über den UART gesendeten Daten. Bei mir funktionieren alle Geräte problemlos (unterschiedliches Herstellungsdatum und verschiedene Aufkleber im Bateriefach). Wenn Programme nicht das erwartete Verhalten zeigen, erinnere ich nochmals an die Notwendigkeit die Speichersegmente beim Linken auf Word-Grenzen auszurichten, wie von mir mit dem Linker-Script im Beispiel vorgenommen. Sonst zeigt ein bisher funktionierendes Programm nach kleinsten Änderungen plötzlich ein nicht erklärbares Verhalten. Das könnte der Grund für das von Martin B. beschriebene Verhalten sein. Oder aber das Gerät wurde nicht z.B. mit dem init.brec initialisiert, oder das Programm wurde nicht bzw. nicht an der richtigen Adresse gestartet ... Ich hoffe, es konnten einige Unklarheiten aufgeklärt werden. Gruß swausd
Hi zusammen, ich hab' heute eine Platine vom basteltechnisch recht nutzlosen PIC befreit, und das MEMS mal ganz naiv an die AUX-Eingänge des Touchpanel-ADCs geklemmt. Anbei ein paar geplottete Samplewerte. An der unterschiedlichen Phasenverschiebung kann man leicht schütteln von Kreisbewegung unterscheiden. Die Spikes am Ende sind durch sachtes klopfen der Platine an die Tastatur entstanden - es schaut so aus, als könnte man das MEMs beim Roboterbau gut zur Kollisionserkennung verwenden... Es gibt zwei Stolperfallen: - Den bbads7843 musste ich bei Auswahl der AUX-Eingänge explizit in den Single-Ended-Modus schalten. Wenn ich das Datenblatt richtig verstehe, sollten die AUX-Eingänge unabhängig vom SE-Bit immer SE arbeiten, aber ohne gesetztes Bit kam aus meinem Exemplar nur Müll raus... - Das MEMS bekommt nach Auslöten des PICs keinen Saft mehr, da sein VCC aus einem IO-Pin des PICs kam. Ich hab' es provisorisch einfach an den Pluspol des Supercaps geklemmt (nicht auf dem Bild zu sehen). Gruß Andreas
Hallo Andreas, schön, dass Du die Infos der Allgemeinheit zur Verfügung stellts. Werde mir diese auf Wiedervorlage legen. Momentan bin ich an anderen (richtigen) Baustellen eingebunden. Gruß swausd
Thread beobachten
Seitenaufteilung abschaltenBitte 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.