Reset bei High Voltage Serial Programming bei TPI?

dann kann man mit 12V am Steuereingang A (Pin 11)
Genau, neben dem 4053 gibt es ja auch noch den 4052 und den 4051.
Du hast grundsätzlich die Eingänge (A, B, C), die die Zustände der Schalter bestimmen.
Die (beiden benötigten) Eingänge könnte man auch über ein Pull-Widerstand auf 12V=Vdd ziehen lassen, und durch den steuernden Tiny über einen FET dann auf Gnd schalten.
Tendenziell werd ich jetzt wohl eher 'ne Schaltung suchen, die UPDI und TPI kann
Beim TPI müßte der Reset (Pin5 des konventionellen 6Pin-Headers bzw Pin6 des 10poligen AVR-Headers des ICE) getrennt und Targetseitig auf 12V geschaltet werden können.
Beim UPDI hingegen MISO/TPIDATA/UPDI (Pin1 bzw Pin3).
Wären folgende Verbindungen (targetseitiger konventioneller 6Pin-Header):
  • Normalzustand
    • Pin1 <----------------> Pin1
    • Pin5 <----------------> Pin5
  • HV-TPI (gesamte Session)
    • Pin1 <----------------> Pin1
    • Pin5 <--> 12V , Vtg <--> Pin5
  • HV-UPDI (nur HV-Reset-Puls)
    • Pin1 <--> 12V , Gnd <--> Pin1
    • Pin5 <-----------------> Pin5 (oder offen, nicht genutzt)
12V, Vtg und Gnd über geeignete Pull-Widerstände, klar.
Sollte sich mit dem 4052 machen lassen.
X und Y auf den Target-Anschluß (Pin1 und Pin5), Kanal0 beide 1:1 auf den Programmer-Anschluß. Bei Kanal1 nur Pin1 auf X1, Y1 bekommt die 12V. Kanal2 entsprechend Pin5 auf Y2 und X2 auf 12V.

Um dem Programmer beim TPI den Reset ordentlich vorzugaukeln, bräuchte man den angedeuteten Pullup nach Vtg.
Beim UPDI sollte während des Pulses ein Low-Pegel am Programmer anliegen.
Beide könnten direkt aus dem steuernden AVR geschaltet werden, mit zwei Pins.
 
So, hab‘s mal ausprobiert.
Umschalter.jpg
Für UPDI reicht einer der drei unabhängigen Umschalter des 4053.
Wenn A high (12V) ist, ist der gemeinsame Ein/Ausgang auch high, ax ist offen.
Wenn A low ist, kann der Pfad ax ↔ a-in/out jede beliebige Spannung zwischen 0 und 12V bidirektional übertragen.

Du kannst natürlich auch einen 4052 nehmen, dann hast Du 2 gekoppelte Kanäle, die Du gleichzeitig auf vier Leitungen umschalten kannst.

Welcher Umschalter für UPDI und TPI besser geeignet ist, wirst Du selbst rausfinden (brauche selbst kein TPI).
 
So, hab‘s mal ausprobiert.
Du meinst auf dem Papier?!
Wenn A high (12V) ist, ist der gemeinsame Ein/Ausgang auch high, ax ist offen
Damit hängt der Programmer aber während des UPDI-Reset-Pulses in der Luft. Meiner Meinung nach müßte er aber auf Gnd liegen, um dem Programmer zu signalisieren, daß das Target noch nicht bereit ist. Einen permanenten PullDown will ich da eigentlich nicht dran haben.
Ich müßte eigentlich beide Seiten schalten können, programmerseitig habe ich aber keine 12V-Probleme zu bewältigen. Vier Kanäle bietet mir auch der 4052 (da wollte ich wegen nur zwei Steuerleitungen 'ne Lösung suchen) nicht, aber die drei vom 4053 kann ich sinnig verwenden.
Ein Kanal schaltet die UPDI-Datenleitung targetseitig zwischen 12V oder UPDI, ein zweiter Kanal schaltet programmerseitig zwischen GND und UPDI. Dann kann ich erst die Programmerseite auf Gnd setzen, dann den 12V-Puls am Target triggern, und wenn das Target wieder auf Vtg zurück ist den Programmer wieder auf UPDI legen.
Die (beim UPDI nicht genutzte) Reset-Leitung würde über den dritten Kanal targetseitig genauso auf 12 geschaltet werden können, währenddessen hätte ich auf der Programmerseite gern einen Pullup. Da könnte man aber auch einfach einen Controllerpin drauflegen, der zwischen Tristate und Pullup toggelt.

Im "Normalmodus" sind beide Leitungen ohne irgendwelche weiteren Pull-Widerstände durchgeschaltet.
Um einen UPDI-HV-Puls auszulösen wird erst mit Kanal2 UPDI am Programmer auf Gnd geschaltet, dann der kurze HV-Puls am Target mit Kanal1 gegeben, und dann wieder der Normalmodus hergestellt.
Im "TPI-HV-Modus" wird der Tiny-Pullup aktiviert (quasi Kanal4) und überwacht. Sobald der durch den Programmer auf Gnd gezogen wird, schaltet Kanal3 Target-Reset auf 12V.

Die Reaktion muß natürlich möglichst schnell erfolgen (SBIC+RJMP-Schleife). Wenn das nicht reicht, muß das Target vor dem Programmierzugriff "manuell" auf 12V geschaltet werden.
Daß die Software im Target die jeweils verwendeten Leitungen nicht aktiv auf irgendwelche Pegel legen darf (bzw man das beachten muß) ist klar.
Bim UPDI könnte man das 8,8ms-Powerup-Fenster miteinbeziehen - beim TPI kenne ich sowas nicht...

Im TPI-HV-Modus liegt der Pullup des Steuer-Tinies zeitweise parallel zum Reset-Pullup des Targets, aber damit sollte der Programmer eigentlich klarkommen.
 
Du meinst auf dem Papier?!
Nein, auf dem Steckbrett.
Probierst Du auf dem Papier aus, wie ein IC funktioniert? :p
Damit hängt der Programmer aber während des UPDI-Reset-Pulses in der Luft.
Es ging mir erstmal nur darum, festzustellen, ob das IC so funktioniert, wie ich mir vorgestellt hatte.
Wenn der Programmer am Rechner und über den Umschalter am Target angeschlossen ist, sind seine Datenleitungen im Ruhezustand hochohmig.
Wenn ich ein Target, bei dem die UPDI-Fuse umprogrammiert wurde, programmieren möchte, drücke ich auf den Taster für den Umschalter (ggf. über Monoflop, für einen 1µs-Puls). Damit ist das Target im programmierbaren Zustand. Anschließend klicke ich im Atmel-Studio auf Programmieren. Erst dann wird der Programmer aktiv. Vorher ist es egal ob die Leitung offen ist.
Wenn das so nicht funktioniert und ich das tatsächlich mal brauchen sollte, frage ich den Hersteller, wie er sich das gedacht hat.

Falls ich mal in die Verlegenheit kommen sollte einen Controller mit TPI programmieren zu müssen, benutze ich den Dragon. Der kann auch HV- und Parallelprogrammierung und fast alle anderen AVRs bis auf die neuen Xtinies (vielleicht gibt es dafür auch noch ein Update…).
Vier Kanäle bietet mir auch der 4052 (...) nicht,
Wie ich schrieb, kannst Du mit beiden Kanälen gleichzeitig zwischen vier Leitungen auswählen.
Sollte sich mit dem 4052 machen lassen.
Sorry habe Deinen Gedankengang, wofür Du einen Vierfachumschalter brauchen könntest, nicht weiterverfolgt, da mich TPI nicht interessiert.

Mach doch mal ‘ne Zeichnung, vielleicht wird es dann klarer. ;)
 
einen Controller mit TPI programmieren zu müssen, benutze ich den Dragon.
Mein letzter Wissensstand war, daß der Drachen kein TPI kann. Möglich, daß das inzwischen erweitert wurde...
Damit ist das Target im programmierbaren Zustand. Anschließend klicke ich im Atmel-Studio auf Programmieren. Erst dann wird der Programmer aktiv. Vorher ist es egal ob die Leitung offen ist.
Ja, so etwa hatte ich mir das auch gedacht - aber Du gehst vom PDI aus. (Ich kann nur von SPI oder TPI ausgehen.
Stutzig macht mich wie gesagt:
When the pull-up is detected, the debugger initiates the enable sequence by driving the line low for a minimum of 200ns and a maximum of 1 us
Das liest sich so, als wenn der Programmer auf die steigende UPDI-Flanke wartet, und dann die Verbindung mittels Gnd-ziehen beginnt.
Wenn der Programmer den Pin überwacht, muß die Leitung am Programmer zu begin auf Gnd gezogen sein, und erst nach dem 12V-Puls am Target auf das Target umgeschaltet werden.
Möglicherweise ist das aber auch nur wie beim SPI/TPI/(PDI) - wenn Du im Studio den Zugriff auslöst, überprüft der Programmer den Zustand der Leitung (=High?), und versucht die zu aktivieren (->Gnd). Vorher kann der Pin am Programmer dann "fliegen"..
Zum 4052: eben. da wären zwei Steuerleitungen für 4 Zustände interessant gewesen, ebr der hat eben nur zwei Kanäle. Deswegen hab ich den Ansatz verworfen.

Wenn die Schaltung sowohl TPI als auch UPDI im HV können soll, brauch ich 12V am Target an zwei Pins, unabhängig voneinander schaltbar.
Also zwei Kanäle, zwei Schalter.
Wenn(!) ich währenddessen programmerseitig auf einen bestimmten Pegel schalten will (Gnd bei UPDI, Vtg bei TPI), brauch ich zwei weitere Kanäle. Die müssen aber nicht unbedingt trennend schalten und nicht mit 12V klarkommen. Können also durch einen steuernden Controller oder so ... gesteuert werden.

Beim TPI zieht der Programmer die Reset-Leitung normalerweise während der gesamten Programmierens (gegen den Target-Pullup) auf Gnd, und löst sie im im Anschluß wieder (was im Target ein Reset-Startup zu Folge hat). Für HV-TPI wäre also ein vorher extern zuschaltbarer programmerseitiger Pullup ideal (sonst gibts nach dem Programmieren wegen der fehlenden steigenden Flanke 'ne Fehlermeldung).

Ob ich beim UPDI den Programmerseitigen schaltbare Pulldown brauch, ist wie gesagt unklar - aber auch der wäre durch einen Tiny direkt zuschaltbar.
Also reichen zwei Kanäle des 4053.
Nein, auf dem Steckbrett
Wenn Du den dahast...
Ich hab weder den Switch-IC, noch den ICE, und erst recht keinen XTiny hier. Also muß ich erst denken, und dann kaufen.

Ok, zumindest der 4053 scheint wie erwartet zu arbeiten, danke.
 
Mein letzter Wissensstand war, daß der Drachen kein TPI kann.
Hab mich geirrt, das war der ICE:
Programming of all tinyAVR 8-bit MCUs with support for the TPI interface
Der kann dann aber wohl keine HV-Programmierung, sonst könnte er mit Update auch UPDI…
Stutzig macht mich wie gesagt:
When the pull-up is detected, the debugger initiates the enable sequence by driving the line low for a minimum of 200ns and a maximum of 1 us
Das Zitat ist aus dem Abschnitt ohne 12V Programmierung.
During power-up, the Power-on Reset (POR) must be released before the 12V pulse can be applied.
Danach kann der 12V Puls jederzeit kommen, denke ich.
The duration of the pulse is recommended in the range from 100us to 1ms, before tri-stating. When applying the rising edge of the 12V pulse, the UPDI will be reset. After tri-stating, the UPDI will remain in reset until the RESET pin is driven low by the debugger. This will release the UPDI reset, and initiate the same enable sequence as explained in UPDI Enable with Fuse Override of RESET pin.
wenn Du im Studio den Zugriff auslöst, überprüft der Programmer den Zustand der Leitung
Würde ich jetzt mal annehmen.
Wenn die Schaltung sowohl TPI als auch UPDI im HV können soll, brauch ich 12V am Target an zwei Pins, unabhängig voneinander schaltbar.
Das macht das Ganze dann natürlich etwas aufwendiger.
Wenn Du den dahast...
Xtinies habe ich auch keine. Habe aber aus den 80ern noch haufenweise TTL- und CMOS-ICs, damit kann man vieles mal auf die Schnelle auf ‘nem Steckbrett aufbauen. Wenn‘s komplizierter wird, eben einen tiny85 oder mega48 dazugesteckt…

Den 4053 habe ich auch nur erwähnt, weil ich noch einige hier zu liegen habe. Inzwischen gibt es so viele verschiedene CMOS-Analogschalter von verschiedenen Firmen, daß ich schon lange den Überblick verloren habe.

Falls Du ihn nicht kennst: der 4066 hat vier einzelne bidirektionale Analogschalter.
http://www.ti.com/lit/ds/symlink/cd4066b.pdf
Vielleicht wäre der sogar noch besser geeignet, wenn Du sowieso noch einen Controller zur Steuerung einsetzt.
 
Das Zitat ist aus dem Abschnitt ohne 12V Programmierung.
Richtig, der Programmer kann ja auch nur "ohne 12V" - mit dem Pulldown kann ich ihm beliebig lange einen XTiny vorgaukeln, dessen UPDI beim Powerup noch nicht bereit ist. Erst, wenn ich am Target den 12V-Puls drauf hatte, und dessen UPDI danach auf Vtg zurückgegangen ist (durch dessen internen Pullup), könnte ich auch die Programmerseite auf UPDI zurückschalten - am Programmer also die steigende Flanke.

Falls das nötig sein sollte... sonst reicht ein Schalter für UPDI.
Das macht das Ganze dann natürlich etwas aufwendiger
Targetseitig das ganze einmal am UPDI-Pin des sechspoligen Headers (1) und einmal am Reset-Pin (5).
Eine Steuerleitung, um 12V auf UPDI zu legen, eine um 12V auf Reset zu legen.
Den programmerseitigen Reset-Pullup kann der Steuercontroller selbst zuschalten.
Sollte sich ganz gut mit 'nem Tiny25 machen lassen (zweimal 12V schalten, max zweimal Pull-Widerstände zuschalten, einen Eingang um "Normalbetrieb" oder "HV-TPI" zu wählen, einen Taster um den UPDI-Puls zu triggern. Wenn der PullDown am UPDI nötig sein sollte, müßte man den RST des Tn25 als I/O nutzen.)

Ich mach morgen wohl mal'n Plan...

Der 4066 hätte vier einfache Schalter, die Umschalter vom 4053 passen schon.

Laut der Seite hier soll Vee im "Analogbetrieb" auf 5V, dann sollen die Steuereingänge mit 0 bzw 5V schalten...
???
 
Laut der Seite hier soll Vee im "Analogbetrieb" auf 5V, dann sollen die Steuereingänge mit 0 bzw 5V schalten...
???
Ich befürchte, die haben das Minus vor den 5V vergessen. Laut Datenblatt verstehe ich das so, daß die positiven und negativen Anteile analoger Signale mit 5V geschaltet werden können, wenn VEE negativ ist.
Control of analog signals up to 20VP-P can be achieved by digital signal amplitudes of 4.5V to 20V (if VDD – VSS = 3V, a VDD – VEE of up to 13V can be controlled; for VDD – VEE level differences above 13V, a VDD – VSS of at least 4.5V is required). For example, if VDD = +4.5V, VSS = 0V, and VEE = –13.5V, analog signals from –13.5V to +4.5V can be controlled by digital inputs of 0V to 5V.
Logic-level conversion for digital addressing signals of 3V to 20V (VDD – VSS = 3V to 20V) to switch analog signals to 20VP-P (VDD – VEE = 20V).
Wenn ich dazu komme, probiere ich es nachher mal aus.
 
Deswegen war ich ja auch verwirrt... ok, Vee auf Gnd, ich gehe von 12V..0V-Logik aus.
Ich mach morgen wohl mal'n Plan
HV_TPI_UPDI.png
Die Werte sind erstmal nur aus dem Ärmel geschüttelt, der 4053 braucht sich noch irgendwelche Pufferkerkos, oder? Statt T1..T3 kommen sicher noch geeignete N-FETs rein.
Falls unnötig, wird der dritte Kanal weggelassen - Y0 programmerseitig mit der UPDI-Leitung verbunden.
B0 des Tiny25 ist Input (Tristate), kann aber bei Bedarf seinen Pullup programmerseitig auf !Reset schalten.
P.S.:
Wenn ich dazu komme, probiere ich es nachher mal aus.
PDI (der XMEGA) ist doch auch bidirektional auf einer der beiden Leitungen, kannst Du mal testen, inwiefern die sich durch so einen 4053 getunnelt Programmieren lassen? Die Schalter stellen ja quasi 120Ohm-Serienwiderstände dar. Die bilden ja dann mit dem jeweiligen PullUp des Empfängers 'n Spannungsteiler. Bei der Schaltung oben würde UPDI ja sogar durch zwei Schalterwiderstände gehen...
 
Zuletzt bearbeitet:
Wie erwartet geht es so nicht. VEE bestimmt die minimal übertragene Spannung. Um Spannungen bis runter auf 0V zu übertragen darf VEE also nicht größer als 0V sein.
CD4053.JPG
Das obere Signal entspricht dem, was vom Programmer kommt.
Das mittlere Umschaltsignal ist invertiert, weil es einen Transistor braucht um auf 12V zu kommen, bei 5V schaltet der 4053 noch nicht durch.
Das untere ist das, was am Target rauskommen würde.

Der 74HC4053 geht übrigens nicht bis 12V, es muß also ein CD4053 kompatibler sein.
Für den einen 12V-Puls nicht unbedingt, kann aber nicht schaden.

Der Plan sieht auf den ersten Blick schon mal ganz gut aus, um da durchzusteigen muß ich mir das aber erstmal umzeichnen. (Die Darstellungsweise des ICs als Block, wo ganz klar ist, daß es sich um drei einzelne Umschalter handelt, finde ich sehr unübersichtlich ;))

PS:
kannst Du mal testen, inwiefern die sich durch so einen 4053 getunnelt Programmieren lassen?
Beim meinem fliegenden Aufbau mit bis zu 20 cm langen Kabeln ist das unwahrscheinlich. Ich schau bei Gelegenheit mal, ob ich das etwas kompakter hinkriege
 
Zuletzt bearbeitet:
handelt, finde ich sehr unübersichtlich
Hätte auch lieber einzelne Gates im Plan gehabt - aber dann hätte auch das Bauteil noch schnell selbst erstellen müssen, und dazu hatte ich grad keine Lust...
(das Power-Gate hatten'se ja schon extra, warum dann nicht auch konsequent drei Switch-Gatter angelegt wurden (wie bei diversen anderen (Logic-)ICs) erschließt sich mir nicht.
Auf dem Zeitungsrand hier hab ich's mit einzelnen Schaltern gezeichnet, aber den wollte ich nicht einscannen...;)

P.S.: Danke...
 
Aus der AN2466: Using Atmel-ICE for AVR® Programming In Mass Production:
--interface <arg>: Physical interface: aWire, DebugWIRE, HVPP, HVSP, ISP, JTAG, PDI, UPDI, TPI, or SWD.
HVPP und HVSP soll doch wohl bedeuten, daß der ICE parallele und serielle High-Voltage-Programmierung kann, d.h. er benutzt dafür 12V. Warum sollte das bei UPDI also nicht auch gehen?
 
Das bezieht sich aber (meiner Meinung nach) nicht auf den ICE konkret, sondern auf das "ATPROGRAM", also die Software im allgemeinen. Du kannst ja neben dem ICE auch andere Tools mit der -t -Option wählen - zB das STK500 oder 600, welche HV-Programming können.
Das ICE kann (laut Online-Manual) kein HV-Programming
All signal channels can be operated in the range 1.62V to 5.5V, although the Atmel-ICE hardware can not drive out a higher voltage than 5.0V.
Der protokollarische Ablauf würde sich mit einer Firmware realisieren lassen, aber die nötigen 12V kann die Hardware nicht generieren (und ich würde nichtmal riskieren, ob die Hardware extern anliegende 12V toleriert).
Theoretisch wäre eine Firmware denkbar, die das HVPP und das HVSP realisiert, wenn der 12V-Reset extern angezogen wird, aber daß Atmochip so'ne Bastel-Firmware entwickelt halte ich für sehr unwahrscheinlich...
Beim TPI (definitiv) und beim UPDI (vermutlich) hingegen gibt es keinen protokollarischen Unterschied zwischen HV und LV.
Beim TPI muß der Reset des Controllers effektiv "angezogen" sein (ob Gnd oder 12V ist irrelevant), beim UPDI erzwingt der 12V-Puls lediglich ein Override des UPDI-Moduls des Targets. Der eigentliche Programmiervorgang entspricht dann der jeweiligen LV-Variante.
Wenn (da) die ICE-Firmware also LV-TPI und LV-UPDI kann, kann sie mit externer Hilfe auch HV-TPI und HV-UPDI...
 
Das bezieht sich aber (meiner Meinung nach) nicht auf den ICE konkret, sondern auf das "ATPROGRAM", also die Software im allgemeinen.
Sieht wohl so aus. Da die AN sich speziell auf den ICE bezieht, hätten sie aber wenigstens erwähnen können, daß der ICE keine HV-Programmierung kann.

Jetzt habe ich endlich die Anleitung zum ICE gefunden.
UPDI.png
Das heißt also, der ICE kann definitiv keine 12V ausgeben, ob er sie verträgt ist immer noch nicht klar. Aber UPDI ist auch keine HV-Programmierung, es wird nur der 12V-Puls benötigt, um in den Programmiermodus zu kommen und dafür muß alles andere, was Schaden nehmen könnte, vom Chip getrennt werden. Auch die Schaltung die am Xtiny angeschlossen ist, wenn sie die 12V nicht verträgt.

Dragon und AVR One! können garkein UPDI. Dann bleibt für die Programmentwicklung wohl nur der STK600 mit dem entsprechenden Adapter und in circuit Programmierung geht nicht, wenn man den UPDI-Pin anderweitig nutzen will. Es sei denn man baut sich so eine Schaltung, wie Du vorhast.

Dann war meine frühere Vermutung offensichtlich richtig: Es ist überhaupt nicht vorgesehen, einen einmal eingebauten Xtiny mit einem Anschaffungspreis von 0.37 bis 0.66 $ noch jemals wieder neu zu programmieren. ;)
 
Das bestätigt eigentlich nur alles, was wir bisher vermutet haben.
12V-Puls benötigt, um in den Programmiermodus zu kommen und dafür muß alles andere, was Schaden nehmen könnte, vom Chip getrennt werden. Auch die Schaltung die am Xtiny angeschlossen ist, wenn sie die 12V nicht verträgt
Nicht alles - nur, was am UPDI-Pin hängt. Wenn der Pins als Reset verwendet wird zB gar kein Problem. Wenn er als I/O verwendet wird, muß das bei der restlichen Schaltung natürlich bedacht werden.
Dann bleibt für die Programmentwicklung wohl nur der STK600 mit dem entsprechenden Adapter und in circuit Programmierung geht nicht, wenn man den UPDI-Pin anderweitig nutzen will.
Jain...
Du kannst die einzelnen Funktionen ja an anderen Pins testen, und wenn alles soweit paßt auf den UPDI umstellen, und als letztes die Fuse umsetzen. Dann hast Du Dich natürlich low-voltage-technisch ausgesperrt, wenn dann noch was zu debuggen ist, hast Du die Brille auf. Aber bis dahin kannst Du den ICE unmodifiziert verwenden.
Dann war meine frühere Vermutung offensichtlich richtig: Es ist überhaupt nicht vorgesehen, einen einmal eingebauten Xtiny mit einem Anschaffungspreis von 0.37 bis 0.66 $ noch jemals wieder neu zu programmieren.
Wiso?
Du kannst den mit dem ICE doch problemlos via UPDI reprogrammieren. Das ist doch nicht anders als beim den SPI- oder TPI-Tinies (und bei vielen konventionellen AVR).
Der einzige Unterschied ist, daß beim UPDI der externe Reset (und der I/O) die Alternativfunktion ist - bei den TPI- und SPI-AVR ist der I/O die Alternativfunktion.

Wenn Du den UPDI unbedingt als I/O verwenden willst, und trotzdem auf Reprogrammierbarkeit nicht verzichten, mußt Du Dir dieselben Gedanken machen wie bei 'nem TPI-Tiny, wo Du den /Reset als I/O verwenden willst, und auf Reprogrammierbarkeit nicht verzichten...
Beim SPI muß ich dann auch die restlichen drei Leitungen bedenken (kann @TommyB ein Lied von singen), beim TPI zwei Leitungen bidirektional empfindlicher...

AFAIR kannst Du bei den XTinies (XCores allgemein?) aber via Software einen Reset auslösen, oder?
(grundsätzlich kann man auch über den Hund 'n Reset realisieren)
 
Nicht alles - nur, was am UPDI-Pin hängt.
alles andere, was Schaden nehmen könnte
hängt am UPDI-Pin (incl. des Programmers). Was anderes habe ich damit auch nicht gemeint. ;)
Jain...
Du kannst die einzelnen Funktionen ja an anderen Pins testen, und wenn alles soweit paßt auf den UPDI umstellen, und als letztes die Fuse umsetzen.
Wenn Du das auf einer fertigen Platine machen willst, wird es aber umständlich. Dann mußt zu zwischen jedem Programmieren und Testen mindestens eine Brücke von Hand umstecken (wenn Du nicht noch zusätzliche Hardware, die dann später überflüssig ist, auf der Platine vorsiehst).
Wenn Du den UPDI unbedingt als I/O verwenden willst
Wenn ich die Xtinies mal verwenden sollte, werde ich den UPDI-Pin ganz bestimmt nicht für was anderes verwenden, da gibt es immer einfachere Möglichkeiten. Da Du danach fragtest, hat es mich mal interessiert, wie es überhaupt möglich wäre und dabei habe ich wieder was gelernt…
ist es relativ einfach, die Leitungen so zu benutzen, daß sie die Programmierung nicht stören.
AFAIR kannst Du bei den XTinies (XCores allgemein?) aber via Software einen Reset auslösen, oder?
Ja, und neben Software gibt es da auch noch mehrere andere Möglichkeiten. Im Zweifelsfall geht der POR immer.
 
Wenn Du das auf einer fertigen Platine machen willst, wird es aber umständlich.
Oder Du erstellst pro zu testendem Block eine, und hinterher dann einen Prototypen, der programmiert, gefused und anschließend verlötet wird.

Ich(!) teste normalerweise vor Bestellung/Erstellung einer Platine...

[beim SPI] ist es relativ einfach, die Leitungen so zu benutzen, daß sie die Programmierung nicht stören.
Wenn Du da den Reset als I/O konfigurierst, muß alles was am Pin hängt ebenso 12V tolerieren, wenn Du im System reprogrammieren willst. Zusätzlich mußt Du dann berücksichtigen, daß während des Programmierens MISO, MOSI und CLK zappeln. Wenn da nur irgendwas via SPI dran hängt, mußt Du nur sicherstellen, daß die Teilnehmer sich nicht adressiert fühlen (also ggf die /CS-Leitungen extern hochziehen, wenn externe Master oder Slaves die dauerhaft chip-enabled sind dranhängen, wird's ggf komplexer). Thomas hatte da zB plötzlich Spiegelschrift auf einem am Bus hängenden Display (AFAIR ging der CS-Pin während des Reset (logischerweise) tristate. Und das Display hat irgendwas interpretieren können.) Wenn über die entsprechenden Pins aber direkt irgendwelche Aktoren angesteuert werden, knallts möglicherweise. Bei Eingängen kann auch einiges falsch laufen (wenn da zB gegen feste Pegel geschaltet wird).
Beim TPI hast Du neben dem Reset nur zwei Leitungen zu berücksichtigen, beim UPDI gar keine weitere.
Du meintest möglicherweise die höhere Robustheit der Signale beim SPI, da (unidirektional) feste Pegel getrieben werden. UPDI und TPI sind wegen bidirektionalen Leitungen und ggf vom Timing her schneller beleidigt...
 
Da es privat nur Einzelstücke werden, gibt es keine Platine. THT, Lochraster, gefädelt, fertig.
Beruflich alles SMD, wenn ich Schaltplan und Layout fertig habe, wird der erste Prototyp gebaut, bevor ich anfange zu programmieren.

SPI braucht keine 12V WIMRE. Und klar, alles was an den betreffenden Leitungen hängt muß beim Programmieren natürlich disabled sein. Da man das aber vorher weiß, ist das leicht einzuhalten. Es bietet sich gradezu an, diese Leitungen für andere SPI-Peripherie zu benutzen. ;)

Mit TPI u.ä. kennst Du Dich sicher besser aus. Alle tinies und megas die ich bisher benutzt habe, hatten SPI.

PDI ist am einfachsten von allen, da braucht man sich keine Gedanken drum zu machen, der Programmierstecker kann während der ganzen Programmentwicklung stecken bleiben und man kann jederzeit neu programmieren oder debuggen ohne daß etwas stört.
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)