Hallo, ich habe am WE für meinen Sohn einen "Geschichtenbär" geschenkt bekommen. Der hat die Möglichkeit, weitere Geschichten von Cartridges abzuspielen. Nun wird das Teil schon ewig nicht mehr hergestellt. Die Cartridges gibts nur noch selten bei Ebay zu exorbitanten Preisen. Auswahl fällt demnach auch sehr klein aus. Der Plan ist, das ding mit neuen Daten (Hörbücher etc.) zu versorgen damit der Teddy nicht im Container landet. Da hab ich mir gedacht, besorgst dir mal eine und schaust mal drüber. Aufgeflext, eingescant. Kann mir jemand sagen was das für speicher sein könnten? Evtl SPI da die Leiterbahnen wie ein Bus aussehen? Gruß, Christian (Alternativ "operiere" ich Bruno und bau ihm ein Raspberry ein :p)
Ganz links ist GND, dann kommt VCC, ganz rechts ist auch VCC. Den Rest wirst du dir im Betrieb mittels Oszi/Logic Analyzer anschauen müssen. Ich zähle 7 Leitungen, daher würde ich einen 4-Bit Bus vermuten. Clk + 4 Data + ALE + CS? Kaffeesatzleserei. RPi fände ich doof. Reverse die Leitungen/Protokoll und setz' 'nen µC (ggf. mit Mikro-SD) in deine Kassette.
Pin 5 und 6 sind die CS Leitungen für die Chips, da jede Leitung nur zu einem Chip geht, die restlichen 5 dann vermutlich Clock + Data. Wie hast du die Einfärbung im Bild gemacht?
Bei zehn benutzten Anschlüssen bleiben acht für Inhalte übrig (Versorgungsspannung und Masse abziehen). Das kann also irgendwas sein, Speicher mit 4-Bit-Datenbus, SPI, I²C oder auch analoger Kram, der in den ICs unter den Klecksen erzeugt wird. Da die Innenbeschaltung Deines "Geschichtenbärs" vermutlich ebenso aus irgendwelchen Klecksen besteht, wird man entweder die Dinger röntgen müssen, oder aber mit einem Logikanalysator die Verbindungen zwischen Steckkärtchen und Bär abhorchen. Der Aufwand dürfte erheblich sein; des Bären Elektronik durch einen Pi o.ä. zu ersetzen und einen SD-Karten-Leser einzubauen, über den dann einfach mp3-Files geladen und abgespielt werden, dürfte einfacher sein. Ein Pi ist hier schon überdimensioniert; sofern der Bär nichts weiter macht als labern, reicht ein simples mp3-Modul.
Es kann natürlich sein, dass die Dinger jeweils parallel per SPI angeschlossen sind, und sich nur eine Clock-Leitung teilen: 2 * CS + 2 * MISO + 2 * MOSI + CLK.
Rufus Τ. Firefly schrieb: > Bei zehn benutzten Anschlüssen bleiben acht für Inhalte übrig > (Versorgungsspannung und Masse abziehen). Nein 7. VCC ist doppelt dabei.
Das kann auch ein analoger Sprachspeicher sein. Schau doch mal was an Elektronik im Bär steckt, das könnte aufschlussreich sein.
Danke, Wundert mich, das dort 2 chips drauf sind. vieleicht waren die ja günstiger. Einfärbungen sind mit GIMP gemacht, Leitungen mit Zauberstab markieren, neue transparente Ebene in rot od. blau, Auswahl invertieren, markierung löschen. Dann bleiben nur die ausgewählten Bahnen. Vorher noch die Beiden Bilder ausrichten und übereinander legen. der RPi wärs nur geworden, wenn das mit dem Speicher nix wird, dann hätt ich die interne elektronik komplett getauscht. Muss aber nicht sein, wär mir lieber dort ne SD Karte oder sowas reinzuklemmen. Ich werd an die Cardridge mal kabel anlöten und im Betrieb mal die Pegel mitm oszi messen. Logic-Analyzer hab ich grad nicht parrat, wenn aber 3,3v dann kann ich das ding auch an den GPIO vom rasp. hängen oder an nen parallelport oder an nen avr. Ich schau mal. Gruß
Christian schrieb: > Einfärbungen sind mit GIMP gemacht, Leitungen mit Zauberstab markieren, > neue transparente Ebene in rot od. blau, Auswahl invertieren, markierung > löschen. > Dann bleiben nur die ausgewählten Bahnen. > > Vorher noch die Beiden Bilder ausrichten und übereinander legen. Ok, also von Hand. Ich hatte auf eine automatisierte Lösung gehofft ;)
automatisch könnteste ja per Gimp-Script machen. Ebene nehmen, in 1 bit wandeln und einfärben. War mir händisch aber schneller :) Das Vieh zappelt übrigens auch mit Armen und Beinen, hat also ettliche Servos drin, ich denk mal mit Analog is das nicht zu machen.
so, hab mal kurz durchgeklingelt 1 - gnd 2 - vcc 3,3v 3 - nc 4 - nc 5 - bei Modus1 clock 32khz 1,2us 6 - bei Modus2 clock 32khz 1,2us 7 - ??? 8 - data 9 - data 10 - data 11 - data 12 - vcc 3,3v alles 3.3v, müsste ich also mal irgendwie nen LogicAnalyzer organisieren. 5,6 sind mMn das Clock signal des jeweiligen Chips (es gibt 2 Modi, Märchen und Musik). 8-11 sieht verdächtig nach Daten aus. Einzig die 7 macht micht stutzig. sieht wie ein regelmäßiger clock aus, und sobald man ein neues Kapitel anspringt etc. sehe ich "daten". Werden damit evtl. Speicherbereiche angesteuert? (daher so regelmäßig beim normalen abspielen, unregelmäßig beim seek.)
Ich würde mir dieses ganzes "Reverse Engineering" sparen, und ein Arduino o.Ä. einbauen.
Dann müsste ich aber alle servos ansteuern, musik, bewegung, positionsabfrage etc. das halte ich für komplizierter als mit einfach mal den speicher anzuschauen ... Vieleicht ist es ja auch garnicht allzu komplex.
Wie klingt der 'Erklär-Bär' denn? Sind das eher sehr rauhe 4 bit, oder schon saubere 8 bit? Der Hersteller jedenfalls liefert keine Daten: http://www.jetta.com.hk/
:
Bearbeitet durch User
Keine Ahnung wie 4 oder 8 bit klingen. Ich find den Sound ganz gut. siehe: http://www.youtube.com/results?search_query=timmi+geschichtenb%C3%A4r Gruß
32kHz bei 4 Bit, macht 16kHZ bei 8 Bit, kann schon sein. Das Chip Select ist demnach über die Clock realisiert. 7 könnte dann eine Art "address increment" sein. Häng doch mal einen kleinen Mikrocontroller dran, der synchron zum Clock die Nibbles eines 8Bit PCM raushaut. Wenn der Puffer leer ist, einfach wieder von vorn. Wirst ja sehen, ob das geht. Gegebenenfalls Nibbles tauschen. Was macht das Ding denn, wenn der Track zu Ende ist? Das müsste doch auch noch signalisiert werden. Geht das vielleicht mit über die 7?
Klingt für mich nach 8 bit Sound, evtl. mit aLaw oder µLaw noch etwas aufgemöbelt. Was mich dabei wundert, sind die lediglich 4 Datenleitungen, denn irgendwoher müssen ja auch noch die Servosignale für die Motoren kommen. Läuft beim Liedchen immer die gleiche Motorsequenz oder ist das jedesmal anders? Wenn das jedesmal anders ist, könnte ich mir vorstellen, das der Rechner einfach das Audio ein wenig auswertet und mit den Ohren oder der Schnauze wackelt. ghls Vorschlag klingt gut, da könntest du dich mal ranmachen.
:
Bearbeitet durch User
soo, hab ihn mir jetzt nochmal in aktion angeschaut. also die bewegungen sind definitiv programmiert. Audio-Auswertung is das nicht, da er gewisse bewegungen bereits macht, wenn er nichts sagt. also bei "streck die hände in die höhe" hat er schon vor dem satz die hände oben. Also definitiv gescriptet. Ich werd morgen mal den analyzer drankleben und mir das mal mitschneiden. Kann es sein, das über pin 7 quasi die steuersignale kommen (track anfang, ende, handpositionen)? Dann würde das ja bedeuten, das der IC in der Cardridge nicht nur ein speicher ist sondern aufwändiger. Warum sollte ein hersteller soviel logik in ein externes modul stecken wenn es doch eigentlich nur den sinn eines speichers hat. Nagut, danke erstmal, ich werd morgen mal berichten! MFG Christian
Naja, du musst ja noch wissen wie groß der Speicher ist. Woher soll der Player sonst wissen wieviele Samples er holen kann? Etwas an Metadaten wird dann doch noch gebraucht.
Für den Hersteller könnte der "Sinn" durchaus darin bestehen, die ganze Sache so unorthodox zu gestalten, daß er sich das lukrative Folgegeschäft mit den Cartridges sichern wollte - während der "Bär" sozusagen "unter Preis" verkauft wurde. Ist die Sache zu einfach zu kopieren, stehen die Fremdanbieter sofort bei Fuss - und liefern "nur" Cartridges. Der Bär selber ist dann evtl. Gebrauchsmuster/Copyright etc. produktrechtlich einfacher zu schützen, nicht jedoch die Verwendung von "Speichermodulen". Es dürfte also einfach "Absicht" gewesen sein...
Würde man dafür nicht einfach den Inhalt verschlüsseln?! 7 Datenleitungen zu reversen ist ja jetzt nicht der Hit.
Christian schrieb: > (Alternativ "operiere" ich Bruno und bau ihm ein Raspberry ein :p) Wenn der arme Bruno unters Messer muss, dann würde ich zu einem preiswerten MP3 Player und einem kleinen 0,5W Verstärker o.ä. greifen.
Hallo, CHristian, schau mal da : http://elm-chan.org/works/sd8p/report.html Wir haben das DIng damals in etwas abgewandelter Form (nur eine Datei abspielbar) in unserer Relaisfunkstelle eingesetzt....
Plausibel wäre, das es sich hier einfach um "zwei Files in Hardware" handelt. Ich glaube kaum, dass sich der Entwickler hier mit Filesystemen und komplizierten Strukturen aufgehalten hat. Sicherlich werden feste Datenpakete mit z.B. entsprechender ID versandt. Bewegung und Sprache kombiniert, Musik extra.
Pin 7 würde ich für eine Steuerleitung halten, z.B. R/W. Der Controller muß erstmal sagen (schreiben), welche Adresse er lesen will, dann wird auf Lesen umgeschaltet und es kommen Daten aus dem Speicherchip. Beim Kapitelwechsel herrscht da natürlich Aktivität, weil der Controller im Inhaltsverzeichnis herumsucht. Während des Abspielens muß nur gelegentlich eine neue Blockadresse übermittelt werden, so daß das Signal sehr regelmäßig aussieht. Es wäre interessant zu sehen, in welche Richtung jeweils Daten übertragen werden. Ein Widerstand in einer Datenleitung schafft da (am Oszilloskop) Klarheit.
So, hab mal weiter gemacht. Aktuell hab ich noch keinen Logic Analyzer zur Hand. Daher erstmal nur das oszi. Das bärchen wird langsam zum Cyborg, hab die Cardridge verlängert sodass ich jetzt die Leitungen unterbrechen kann etc. Wie messe ich denn die Datenrichtung? Ich hab einen Widerstand zwischen Leitung. Dann habe ich 2Messpunkte: Leitung 1 - zum Bär : 3v Leitung 2 - zur Cardridge: 2,8v würde das nicht bedeuten, das die Signale vom Bär kommen? Im übrigen hat das Tier auch eine Geschichte integriert, also ohne Cartridge. Wenn die Läuft, habe ich auch Signale auf dem Slot. MFG
Das ist ja wie bei der Modelleisenbahn. Sollte nicht eigentlich der Junior .... ;-) Falls Du einen Rechner mit Druckerport hast, hilft vielleicht das weiter: http://jwasys.home.xs4all.nl/old/diy2.html Damit lässt sich sicher schon etwas anfangen bis der LA kommt.
hp-freund schrieb: > Das ist ja wie bei der Modelleisenbahn. > Sollte nicht eigentlich der Junior .... ;-) > > Falls Du einen Rechner mit Druckerport hast, hilft vielleicht das > weiter: > > http://jwasys.home.xs4all.nl/old/diy2.html > > Damit lässt sich sicher schon etwas anfangen bis der LA kommt. ich kenne sowas ähnliches als TFLA (gehostet bei Berlios) http://sourceforge.net/projects/tfla-01.berlios/
ja den TFLA nutze ich hier, bekomm ich aber nix brauchbares raus... Ich werd heut abend mal versuchen, meinen Raspberry zu nutzen, der sollte mehr performance haben: http://tuxbabe.eu/raspalyzer.html Vieleicht kann ich das dann auch gleich aufzeichnen etc. Kann mir eigentl. jmd. sagen wie ich die Flussrichtung der Daten bestimme? Ich steh da n bissl aufm schlauch. MFG Christian
@hp-freund der Junior ist erst 1,5 Jahre alt, das gibt ärger wenn ich dem nen Lötkolben in die Hand drücke. So hat der Papa aber auch noch viel Zeit :) Der kleine hat eh noch Angst vor Bruno.
Christian schrieb: > Kann mir eigentl. jmd. sagen wie ich die Flussrichtung der Daten > bestimme? Ich steh da n bissl aufm schlauch. Interessante Frage. Oder ich weiss es einfach nicht besser :-) Meine Idee: 1m Koaxkabel in die Datenleitung mit Abschlusswiderstand und dann mit dem Oszi vorn und hinten messen. Sollte etwa 5ns Unterschied ergeben. Oder gibt es eine bessere Lösung? Die Richtung kann ja auch wechseln, also evtl. die Messung mit ext. Takt triggern???
Könnte man die Datenrichtung bei Unidirektionaler verbindung nicht mit einer Diode feststellen? So mal kurz zum Status: Logic Analyzer kann ich heute erst probieren, bis dato hab ich aber ein bisschen mitm Raspberry und dessen GPIO rumgespielt. Außerdem gabs einige englischsprachige Seiten, die mit dem Tier (TJ Bearytales) rumgebastelt haben. Auch welche, die das Ding direkt angesteuert haben. Aufgrund dessen, werde ich wohl die interne Elektronik komplett austauschen, denn ich habe Festgestellt, dass die Daten auf der Cartridge doch nur ein teil vom eigentlichen Programm sind. Diverse Texte wie z.B. die Kapitelansage sind auf dem Mainboard. So müsste ich also, sollte ich die Cartridge "nachbauen", meine Daten in das selbe Format bringen. Wer weis welche Beschränkungen man da noch feststellt. Ich erhoffe mir vom direkten ansteuern, dass auch die Bewegungen flüssiger werden und ich völlig frei beim steuern bin. Ich behalte trotzdem das Reverse Engineering im Auge, spätestens wenn ich einen geeigneten Logic analyzer habe. Noch einige Infos die ich erlangt habe: - Es handelt sich nicht um eine einfache SD-Card im 4-Bit Modus, zumindest konnte ich sie an einem Kartenleser nicht zum reagieren Bewegen. (Vermutung war SD-Card, da 4 Datenleitungen + clock + Command) - Pin 7 scheint der gemeinsame Clock, Pin 5/6 scheint die Steuerleitung. - das Teil scheint ziemlich komplex zu sein. Im inneren befindet sich auch eine Antenne. Scheinbar hatte der Hersteller noch einiges vor. - Ich vermute, auf der Cartridge befindet sich ein richtiges Dateisystem. - Wenn man die Cartridge stört (z.b. Data-Leitung im Betrieb auf GND), so laufen die Bewegungen weiter, aber der Ton setzt aus. Heut abend gehts dann weiter, Ich werd das Teil mit seinen Spezialschrauben mal öffnen und werd mal die Hardware ausbauen.
ja, ich hab dem gestern auch das fell über die ohren gezogen und ich hab einen open logic sniffer bestellt... werde dann berichten.
Angehängte Dateien:
-
init_pressplay.png
16 KB -
play_1clk.png
9,8 KB -
play_3clk.png
9,9 KB -
init_2.png
11 KB
So, da bin ich wieder. mit dem Logic analyzer hat das auch alles ganz gut geklappt. Im Anhang einige Dumps der Datenpakete. In Kombination mit meinem Raspberry hab ich dann auch das Init erfolgreich zur Karte senden können. Die Karte antwortet entsprechend. Ist jemanden dieses Protokoll bekannt? Oder muss ich das alles händisch nachbauen... Das normale Datenpaket ist wie folgt aufgebaut (init_pressplay.png): cs1-select (data 0b1111) data 0b0010 (write to card) cs1-release cs1-select (data 0b1111) data 0b0000 (write to card) cs1-release cs1-select (data 0b1111) data 0b1001 (write to card) data payload (write to card) data payload (write to card) data payload (write to card) data payload (write to card) data 0b1111 (write to card) data 0b1000 (write to card) cs1-release cs1-select (data 0b1111) data 0b0000 (write to card) data payload (read from card) .... .... .... cs1-release Ideen? Ansonsten auch noch analysen vom audio-playback (play_??.png). bestehend aus: 1 clock - write to card 1 clock - write to card 2 clocks - read from card (=8bit) Ich glaube bei ca. 8khz, muss ich aber nochmal nachmessen.
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.