Im Prinzip ja, der Satz geht aber weiter:
Nochmal als Ganzes:
When the pull-up is detected[1], the debugger initiates the enable sequence by driving the line low for a minimum of 200ns and a maximum of 1 us [2] to ensure that the line is released from the debugger before the UPDI enable sequence is done.[3]
The negative edge is detected by the UPDI, which requests the UPDI clock. The UPDI will continue to drive the line low until the clock is stable and ready for the UPDI to use. The duration of this will vary, depending on the status of the oscillator when the UPDI is enabled. A start-up time between 10us and 200us can be expected. After this duration, the data line will be released by the UPDI, and pulled-high.[4]
When the Debugger detects that the line is high, the initial SYNCH character (0x55) must be sent to properly enable the UPDI for communication[5]. If the start bit of the SYNCH character is not sent within 13.5ms, the UPDI will disable itself, and the enable sequence must be repeated. This time is based on counted cycles on the 4MHz UPDI clock, which is default when enabling the UPDI. The disable is performed to avoid the UPDI being enabled unintentionally[6].
[1] steigende Flanke durch den Tiny
[2] der Programmer zieht auf Gnd - warum jetzt? Beim TPI, SPI kann ich den Programmer steckenlassen während das Programm läuft - und ich entscheide im Studio, wann 'n Programming-Zugriff erfolgen soll. UPDI-Reset wird gehalten.
[3] der Tiny reagiert auf die fallende Flanke, indem er seinerseits UPDI auf Gnd zieht, und startet/initialisiert sein UPDI. Der Programmer muß rechtzeitig loslassen, um dies zu erkennen. Deswegen max. 1µs.
[4] wenn der Tiny mit dem StartUp fertig ist, signalisiert er das, indem er UPDI wieder freigibt (Vcc durch Pullup).
[5] der Programmer detektiert diese steigende Flanke, und beginnt mit der Synchronisation, was UPDI-Programming letztendlich enabled.
[6] ist 13,5ms nach... was eigentlich? [2]? [1]? Ist jedenfalls diese Synchro dann noch nicht erkennbar, schaltet der Tiny sein UPDI ab. Ob er dann mit einem normalen POR loslegt, ist mir nicht ersichtlich.
Was geschieht, wenn man den Pin irgendwann im laufenden Betrieb runterzieht? Wenn UPDI wirklich nur 13,5ms nach einem PowerUp möglich sein sollte, bräuchte man keine extra Reset-Fuse-Möglichkeit - dann könnte nach dem UPDI-Timeout ja grundsätzlich ein konventioneller Reset folgen (ok, die SUT wäre länger).
Ich wär mir nichtmal sicher, ob der Programmer wirklich die steigende Flanke beim PowerUp braucht, oder ob er einfach einen High-Pegel erwartet/abwartet/vorraussetzt.
[Reset-Puls durch den Programmer 200ns..1µs] Das verstehe ich so, daß, wenn der Puls nicht kommt
Der Programmer erzeugt den Impuls. Mindestens 200µs lang, damit er vom Tiny erkannt werden kann und dieser den low-Pegel übernehmen/weiter halten kann, maximal 1µs lang, damit er erkennt, daß der Tiny übernommen hat. Weil der Tiny irgendwann (SUT usw) auch losläßt.
So würde ich es verstehen.
Soweit der normale Low-Voltage-UPDI.
Wenn der Tiny auf GPIO oder Reset gefused ist, erzwingt ein 12V-Pegel am Pin den UPDI-Mode (bzw schaltet den zeitweise um).
Es wird empfohlen, den Impuls nach einem PowerUp aufzulegen. Wenn der Pin I/O ist, wird der Output nach einem (PowerUp)Reset nämlich 8,8ms blockiert, um Spannungskonflikte auszuschließen (beim Reset ist er eh nur über'n Pullup hochgezogen).
Ob danach dann trotzdem ein 12V-Reset möglich ist, geht daraus nicht hervor. Dann sollte der Pin natürlich nicht als Output verwendet werden.
Wenn der 12V Puls einmal erfolgt ist (steigende Flanke auf 12V), ist die Fuse bis zum nächsten PowerUp overriden, der Pin ist UPDI.
Außerdem befindet sich der Tiny (nachdem UPDI wieder auf Vcc gesunken ist) solange im Reset, bis UPDI auf Gnd gezogen wird.
12V-Puls
Pullup an 12V, über Transistor/FET schaltbar.
Ja, an sowas in der Art hatte ich auch etwa gedacht, ok.
Aber...
Wenn der Programmerausgang 12V toleriert - kein Problem,
Bei einem HV-UPDI-fähigen ist das sicher so, aber dann ist das hier eh alles egal.
Ein Programmer der von sich aus nicht HV-fähig ist, wird möglicherweise nicht tolerant sein. Ich würds nicht riskieren wollen.
sonst Zenerdiode nach Masse, Reihenwiderstand an UPDI-Pin??
Dann hab ich, wenn ich die 12V aufschalte 'n Spannungsteiler aus dem Pullup und (Reihenwiderstand und Zener). Der Pullup muß also klein genug gegen den Reihenwiderstand sein, um 12V auf den Tiny bringen zu können. Der Reihenwiderstand muß (mit dem PullUp) groß genug sein, um den Strom durch die Zener zu begrenzen.
Auf der anderen Seite sollen Zener und Pullup aber den UPDI-Verkehr nicht/möglichst wenig verbiegen.
Wenn die beiden UPDI-Seiten aber währenddessen verbunden sind, würde der Programmer aber den Pegelanstieg Gnd->Vcc erkennen, und (?) seinerseits bereits UPDI runterziehen.
Man müßte also die Leitung programmerseitig des Reihenwiderstandes auf Gnd ziehen, bis (tinyseitig) der 12V erfolgt ist, und dort das Signal wieder auf Vcc runter ist.
Also:
Vtg aus
UPDI programmerseitig auf Gnd zwingen
Vtg an
irgendwann (max nach 8,8ms) tinyseitig für 500µs 12V auf UPDI
wenn dort wieder Vtg, UPDI programmerseitig freischalten
das der ICE die neuen Xtinies programmieren können soll...
Ja, aber nur Low Voltage. Genau darum geht's ja.
Der AVRisp mkII kann ja auch kein HV-TPI, aber mit wenn man einen TPI-Tiny mit externen 12V in den Reset zwingt, kann der AVRisp ihn ganz normal (low voltage) programmieren. Siehe #10.
Wenn man auf ähnlichem Wege einen UPDI-Tiny mittels externem 12V-Puls in den UPDI-Mode schubsen kann, sollte man auch hier mit dem ICE programmieren können, wenn der Pin als Reset oder I/O gefused ist.
PS: Das verlinkte Datenblatt hat nur 500 Seiten...
Ups.
Haben sie da umgeräumt? Als ich es mir damals gezogen hatte, es noch 605 Seiten, galt für ATtiny 417/814/816/817 und hieß ATMEL-42721C. Ok, Preliminary. 12/2016. Sorry.
Das war ja auch noch nicht von Micromel... äh... Atmochip... oder wie auch immer.
*Link nachreich*