|
Das Thema ist das Timing. Der TM1000 bekommt Betriebsspannung, startet, und macht sofort den Scan, will Antworten von JLog.
Wenn JLog bereits vorher gestartet war (so 6..10s vorher Betriebsspg. bekam), ist das kein Thema, der Bootloader war durch, - musste auf Init der SD Card warten, wenn eingesteckt, dann auf ihr rummotschen, - dann konnte er die Applikation starten, die den Scan beantworten kann. Heißt also auch, ohne SD Card ist JLog schneller bereit.
Trotzdem ist es nicht möglich, so umgehend nach Powerup für den Scan bereit zu sein, wie es der TM1000 idiotischerweise erwartet.
Daher gibt es nur einen Weg: Clock Stretching. Das kann JLog schnell tun. Er hält dadurch den TM1000 auf, indem er den Bus blockiert. Erst, wenn JLog in der Applikation und bereit ist, gibt er den Bus wieder frei.
JSPEK tut genau das. Da hattest Du mich aber mit Alzheimer's erwischt, - musste mich erst refreshen. Wir bauten zwei Sorten JSPEK, von der älteren habe ich noch 2 Exemplare rumliegen, Version 2 aber nicht. Beide tun dasselbe, nur ist V1 diskret aufgebaut, V2 hat einen Fliegenschiss-Prozessor ATMEL Tiny4.
Beide machen besagtes Clock Stretching.
(Ich nahm es dann doch auf mich, JLog2 zur mir heimkommen zu lassen, um ihnen einen modifizierten Bootloader zu verpassen, der das Clock Stretching selbst macht, ohne Bedarf für JSPEK.)
Als Hardware und Bootloader des JLog2 designed wurden, ging es ja nur um den JIVE + Multiplex/JETI, von dem TM1000 Xbus Irrsinn war nichts zu ahnen.
Was ist nun die Voraussetzung, dass Clock Stretching funktioniert mit dem TM1000?
Richtig! Man muss rechtzeitig anfangen damit.
Woher weiß man den richtigen Zeitpunkt? Indem JLog selbst (mit Bootloader SBL3SPEK) oder JSPEK im gleichen Augenblick Spannung bekommt wie der TM1000. Diese Betriebsspg. kommt via den 4-poligen Xbus Connector.
Das funktionierte bei Dir bisher so (hast SBL3SPEK Bootloader mit eigenem Clock Streching), weil JLog aus dem Jumper Port des JIVE besaftet wurde (== BEC Spg.), und der TM1000, zeitsynchron im Comeup, aus derselben Spg. vom Master/Slave Port.
Nun gingst Du auf bis zu 8.4V, da wirkt ein Wermutstropfen des JLog2: Er kann max 6V ab.
Das stimmt eigentlich nicht, theoretisch bis zu 25V kann er, aber ich hatte damals einen Last-Minute-Wunsch an Stephan (SM), den er erfüllte: Ich wollte ein dickes (aber kleines) C auf der Betriebsspg. Bingo! Dick + klein == geringe MaxSpg. (6V).
Der Grund war gewissermaßen exotisch: JLog2 bedient auch einen analogen Temp.sensor von SM. Analog! Der BEC des JIVE ist ein Buck (getaktet), die Ausgangsspg. hat Ripple, Reste der Taktfrequenz. Das macht das Meßergebnis trotz Software-Integrator etwas zappelig. Das dicke C lindert es.
Man kann nun rotzfrech mehr als 6V Betriebsspg. an JLog2 geben. Wenn man Glück hat, gibt's nur einen schwarzen Punkt unter dem Label (C den Wärmetod gestorben). Allerdings, bei Pech entlötet es eine Diode daneben, dann geht nix mehr.
Nun versorgst Du JLog2 weiterhin aus den max. 6V des JIVE und den TM1000 (weil den Empfänger) aus dem KETO mit >>6V.
Die beiden, - JLog2 + TM1000, - scheinen nun nicht mehr zeitgleich zu starten. Bingo.
JSPEK kann es heilen, wenn dessen Spg. nicht vom JIVE sondern letztendlich vom KETO kommt.
Sprich, bevor JLog erwacht ist, um Clock Stretching zu machen, tat es JSPEK stellvertretend bereits.
Falls JSPEK seinen Saft auch vom JIVE bekommt, geht es zeitlich so knirsch zu, dass die paar Millisekunden, die JSPEK früher als JLog2+SBL3SPEK den Bus aufhält, das zeitliche Auseinanderfallen heilen.
Also, ja, der KETO scheint seinen Saft früher anzubieten als der JIVE. Das ist auch sehr wahrscheinlich, weil Prozzi #2 im JIVE, ein ATMEL ATmega168, erst einen FET Switch hinter dem BEC einschalten muss, was er absichtlich nicht sofort tut. (sei froh, sonst hätten wird den BEC Design Flaw von JIVEpro/KOSMIK bereits zu alten JIVE-Zeiten ausbaden müssen)
_________________
Tom
|
Anmelden
Registrieren
FAQ
Suche
