Resetpin als I/O mit AVRMKII programmieren?

[stinakovits]

Hallo zusammen,

ich denke ich stolpere gerade über ein Problem.
Möchte vom ATtiny4313 den Reset Eingang als I/O Eingang nutzen. Kann man ja so einstellen. Jedoch kann ich dann mit meinem MKII, der ja den Reset benötigt, den Tiny nicht mehr programmieren. Hab ich so richtig verstanden?
In der Entwicklungsphase könnte ich den benötigten Eingang am Resetpin ja noch übergehen. Aber irgendwann muss ich es testen. Kann ich denn mit dem MKII den Tiny überhaupt beibringen den Reset auf I/O umzustellen (Fuse)? Der würde sich ja dann praktisch sofort selber aussperren.
Ist da dann generell Schluss mit lustig? Oder hab ich noch andere Möglichkeiten?

Bootloader will ich eigentlich für das Projekt jetzt keinen basteln. Anderer Proger?

 

[Dirk]

Hallo Manfred,

wenn du das Fusebit RSTDISBL programmierst (Bit auf 0), dann kannst du nicht mehr seriell programmiern. Das geht dann nur noch über die parallele Programmierschnittstelle (in Verbindung mit 12V am Reset-Pin). Dies nennt sich High Voltage Parallel Programming (HVPP).

Hmmm, ideal wäre hier schon ein Bootloader

LotadaC kennt sich mit den tinyAVRs gut aus und ich meine, er hat da auch schon HVPP verwendet. Vielleicht hat er ja noch Hinweise oder Tipps.

Dirk

 

[TommyB]

Der AVR Dragon kennt den Chip und kann neben debugWire auch die parallele Programmierung (HVPP), allerdings ist der Part nicht bestückt. Aber so einen IC Sockel und ein paar Stiftleisten drauf zu löten sollte ja nicht das Problem sein.

 

[LotadaC]

LotadaC kennt sich mit den tinyAVRs gut aus und ich meine, er hat da auch schon HVPP verwendet.

Jain...
Der Reihe nach:
Du kannst per RSTDSBL (Reset disable) - Fuse den Pin zum I/O-machen. Auch über SPI-ISP. Meiner Erinnerung nach schmeißt der Prorammer/das Studio direkt danch 'n Fehler, weil es den Reset nicht mehr erkennt. Du hast Dich SPI_ISP betreffend ausgesperrt.
selbst wenn Du einen Bootloader implementiert hast, kannst Du die Fuses nicht damit umschreiben (das Self-Programming "von innen" hat nur schreibzugriff auf Flash und Eeprom).
Das debugWire laß ich mal außen vor (keine Ahnung, ob man den dWire-Pin zusätzlich als I/O nutzen kann -> Thomas)...

Um überhaupt wieder Zugriff auf die Fuses zu bekommen, brauchst Du 12V auf dem Reset, und jetzt kommts auf den Controller an:

• der bisher von Euch verwendete Tiny25/45/85 unterstützt dann ein spezielles High Voltage Serial Programming (HVSP), welches auch die drei SPI-Pins nutzt, aber es handelt sich dabei nicht um SPI. Es wird also ein Programmer benötigt, der dieses Protokoll unterstützt, und der von der Entwicklungsumgebung in diesem HVSP unterstützt werden muß (den Reset einfach extern auf 12V zu legen reicht nicht)
• der angedeutete Tiny2313(A)/4313 unterstützt dann das von Dirk genannte High Voltage Parallel Programming (HVPP), welches fast alle Beine verwendet, hier muß logischerweise erst recht die Unterstützung durch Programmer und IDE gegeben sein.
• bei den TPI-Tinies gibt es quasi nur das TPI - ob der Reset konventionell über runterziehen des Reset, oder über 12V am I/O ausgelöst wird - das Programming danach ist identisch. Man kann hier also extern 12V auf den I/O-Reset legen, und dann mit einem normalen Low Voltage TPI Programmer programmieren (das habe ich hier irgendwo bereits mit einem Tiny10 und dem AVRisp mkII gemacht/beschrieben. Da ich die 12V nur am Controller/nicht am AVRisp angelegt habe, hagelts natürlich dann Fehlermeldungen, wenn der Programmer den Reset nicht erkennt (könnte man einfach einen Pull auf 5V legen), aber das wiederherstellen der Fuse war erfolgreich. Das sind meine, von Dirk angedeuteten High Voltage Programming Erfahrungen. (Die Möglichkeiten des STK500 (HVSP/HVPP) hatte ich noch nie gebraucht/verwendet). Als TPI-Tiny könnte Dich eventuell der Tiny104 (14 Beine) oder der Tiny40 (20 Beine) interessieren.
• bei den XTinies kommt das Unified Programm and Debug Interface zum Einsatz, alles über einen Pin. Wird der UPDI-Pin zum I/O oder Reset(!) gefused, kann nicht mehr mit LV-UPDI programmiert werden. HV-UPDI benutzt zwar dasselbe Protokoll, aber der 12V-Override liegt (logischerweise) nicht mehr dauerhaft an - es wird ein Puls benötigt, danach muß die Leitung für das eigentliche UPDI frei sein. Der AVRISP unterstützt kein UPDI, und der ICE unterstützt kein HV-UPDI. Ob sich da sowas wie bei meinem HV-TPI sicher(!) machen läßt, ist mir noch nicht ganz klar (12V-Puls extern auf die bidirektionale Leitung legen, ohne daß der ICE davon was abbekommt - genau genommen muß ich dem Debugger vor/während des 12V-Pulses einen Low-Zustand am Pin vorgaukeln. Wenn der Puls auf 5V runtergegangen ist, wäre die normale UPDI erreicht (Override), jetzt müßte die bidirektionale Leitung hergestellt werden, der Programmer würde die Leitung runterziehen usw...

 

[LotadaC]

Ist da dann generell Schluss mit lustig? Oder hab ich noch andere Möglichkeiten?

Bootloader will ich eigentlich für das Projekt jetzt keinen basteln. Anderer Proger?

Ums nochmal auf'n Punkt zu bringen:
Es geht ja sicher um Eure Beleuchtungs-Steuerungs-Dinger, wo Ihr mehr I/Os und möglichst kleine Controller haben wollt:

• Controller mit noch mehr I/Os über konventionelles SPI-ISP verwenden (mit dem vorhandenen AVRisp)
• Programmer durch HV-fähigen ersetzen (zB STK500 (?)), erfordert zum programmieren je nach Controller ggf viele(!) zusätzliche Verbindungen (ok, kanns Du ggf die Ausgangslitzen verbinden).
• TPI-Tiny mit HVSP und dem vorhandenen AVRisp verwenden (mit externen 12V)
• (Bootloader bzw lediglich das nachladen von Beleuchtungs-Parametrierungen ins Eeprom - die Firmware könnte beim PowerOnReset auf einen speziellen (atypischen) Zustand an den Beleuchtungs-Ausgängen checken, und nur dann (+ Timeout) 'ne serielle Kommunikation zur Parametrisierung einleiten/erwarten)

 

[stinakovits]

LotadaC, danke für deine Antworten und dein Engagement!

Inzwischen habe ich über Google deinen Beitrag, auf den du hier verweißt, gefunden und mit Interesse gelesen.
Mir ging es bei meiner Frage nicht um den Betrieb sondern nur um die Entwicklungsphase. Habe natürlich im Datenblatt über die Parallelprogrammierung gelesen.

 

[LotadaC]

Ist zwar eigentlich alles klar, aber nochmal kurz und knackig...

...Möchte vom ATtiny4313 den Reset Eingang als I/O Eingang nutzen. Kann man ja so einstellen...

Korrekt

...Jedoch kann ich dann mit meinem MKII, der ja den Reset benötigt, den Tiny nicht mehr programmieren. Hab ich so richtig verstanden?

Korrekt

...Kann ich denn mit dem MKII den Tiny überhaupt beibringen den Reset auf I/O umzustellen (Fuse)?

Ja

...Der würde sich ja dann praktisch sofort selber aussperren.

Und ja

...Ist da dann generell Schluss mit lustig?

Für den AVRisp, der nur LV-Programming kann (abgesehen von meinem TPI-Trick) schon.

 

[TommyB]

Das debugWire laß ich mal außen vor (keine Ahnung, ob man den dWire-Pin zusätzlich als I/O nutzen kann -> Thomas)...

Nein, kann man nicht, der ist dann ausschließlich für die Kommunikation zuständig. Und hat man sich mit debugWire stark verhaspelt (ständig Watchdog Resets z.B.) wird's haarig das zurück zu ändern. Wirklich die Kiste vom Eis holen kann man nur mit HVPP / HVSP, falls man sich mit den Fuses mal verfummelt hat, oder den Reset als I/O nutzt.

Bei TPI muss ich passen.

Edit: Addition.
Wenn irgendwie möglich würde ich den Reset Pin unbelegt lassen. Wird der genutzt killt man sich sämtliche Möglichkeiten den Chip im System (um-)zuprogrammieren, man muss ihn also auslöten. Wie ein bekannter TV Koch mal sagte: „Kann man so machen, schmeckt halt nur scheiße.“

 

[LotadaC]

Wird der genutzt killt man sich sämtliche Möglichkeiten den Chip im System (um-)zuprogrammieren, man muss ihn also auslöten.

Nein, kommt eben darauf an.
Du mußt in der Schaltung nur das Signal wo der Reset drauf muß 12V-tauglich halten, und die restlichen benötigten Programmiersignale zugänglich/kontaktierbar gestalten.
Der letzte Punkt ist natürlich bei einem parallelen Interface mit 14 Signalen (HVPP beim Tiny4313) aufwändiger, als bei einem seriellen mit 4 Signalen (HVSP beim Tiny45), oder zwei Signalen (HV-TPI).
Beim UPDI gar kein zusätzliches Signal...

 

[stinakovits]

Wenn irgendwie möglich würde ich den Reset Pin unbelegt lassen.

Ich habe mich entschlossen den Reset Pin nicht als I/O zu verwenden. Er bleibt unbeschaltet. Erspart eine Menge Unannehmlichkeiten.

Zusatzfrage:
Hier im Forum und auch im weiten WWW finde ich immer wieder die Beschaltung des Reset Pin mit einem Pullup Widerstand. Nun hat jedoch der I/O einen internen Pullup Widerstand. In der Dokumentation steht, dass, wenn der Pin als Reset definiert ist, was ja die Standardkonfiguration ist, der interne Pullup automatisch aktiviert ist.

"RESET: External Reset input is active low and enabled by unprogramming ("1") the RSTDISBL Fuse. Pullup is activated and output driver and digital input are deactivated when the pin is used as the RESET pin."

Hab ich bei meinen Überlegungen einen Gedankenfehler? Oder kann ich den externen Pullup doch weglassen? Wie groß der interne Pullup ist konnte ich jedoch nicht ermitteln.

 

[Dirk]

Den Wert für den RESET Pullup Widerstand findest du im Datenblatt unter
Electrical Characteristics -> DC Characteristics
Beim ATtiny4313 sind es 30kOhm..60kOhm

Wenn du eine Längere Leitung am Reset-Signal hast, hilft ggf. ein externer definierter Pullup Widerstand gegen Störungen auf der Leitung.
Manchmal wird auch eine RC-Kombination am Reset-Pin eingesetzt.

 

[LotadaC]

Korrekt, wenn die Fuse aktiviert wird, greift der Pullup-Override. Siehst Du auch bei den -> Alternate Port Functions (Table10-4 im Datenblatt (Tiny4313, RevisionB auf Seite 63)).

Zum Wert hat Dirk grad was gesagt - wenn Du an den Pin keine lange Antenne bastelst, und die Umgebung nicht stark EM-verseucht ist, brauchst Du keinen zusätzlichen Pullup.

Manchmal wird auch eine RC-Kombination am Reset-Pin eingesetzt.

Der zusätzliche C würde als Tiefpaß das Signal strecken/glätten, also irgendwelchem Prellen/Störungen entgegenwirken.
wenn der Reset freigegeben wird, erwacht allerdings der AVR nicht sofort, sondern es läuft erst ein delay Counter ab (siehe SUT-Fusebits) Findest Du im Datenblatt bei System Control an Reset (Tiny4313->S.39).
Manchmal findet sich sogar noch eine Diode gegen Vcc - die interne Schutzdiode fehlt beim Reset-Pin nämlich intern, da da ja bei HV-Programming 12V anliegen können müssen...

 

[TommyB]

Nein, kommt eben darauf an.
Du mußt in der Schaltung nur das Signal wo der Reset drauf muß 12V-tauglich halten, und die restlichen benötigten Programmiersignale zugänglich/kontaktierbar gestalten.
Der letzte Punkt ist natürlich bei einem parallelen Interface mit 14 Signalen (HVPP beim Tiny4313) aufwändiger, als bei einem seriellen mit 4 Signalen (HVSP beim Tiny45), oder zwei Signalen (HV-TPI).
Beim UPDI gar kein zusätzliches Signal...

Ganz klar, der Reset Pin muss 12V Tolerant sein und darf dann aber auch keine Auswirkungen auf den Rest der Schaltung haben. Ebenfalls dürfen keine Signale die für die Programmierung benötigt werden in irgendeiner Art und Weise eingeschränkt sein. Möglich, ja, aber es gibt verdammt viel zu bedenken. Du erinnerst dich ja sicherlich noch an die Spiegelschrift. Und das war nur ISP.

TDI & co. wie gesagt kenn ich mich nicht mit aus, hab dafür weder Chip noch Programmer.

 

[LotadaC]

Ebenfalls dürfen keine Signale die für die Programmierung benötigt werden in irgendeiner Art und Weise eingeschränkt sein.

Das gilt aber bei konventionellem Low-Voltage-ISP ebenso.
Wenn (!) der Programmier-SPI zur Laufzeit als SPI genutzt werden soll (und es sich erstmal um dieselben Pins handelt), ist das natürlich einfacher, als wenn da irgendwelche gefährlichen Lasten angesteuert werden.
Daß die verdrahtung der Programmierbeine im Target die Programmiersignale nicht verbiegen darf, ist auch klar.

Das einzige, was man beim In-System-High-Voltage-Programming zusätzlich beachten muß ist eben, daß die Schaltung mit den 12V auf dem einen (zusätzlichen) I/O klarkommen muß. (ggf andere/mehr Programmierinterfaceleitungen, klar)

 

[TommyB]

Das gilt aber bei konventionellem Low-Voltage-ISP ebenso.

Meinte ich auch
Aber da ISP gerne (möglicherweise nicht überall) mit SPI gleich ist sollte das kein Problem darstellen, sofern man den Bus nutzt. Klar, wenn an MOSI ein Aktor (Motor z. B.) dran sitzt ist das geringfügig kontraproduktiv ^^

 

[stinakovits]

Electrical Characteristics -> DC Characteristics
Beim ATtiny4313 sind es 30kOhm..60kOhm

Ok, danke. Hab ich dann wohl überlesen.

Wenn du eine Längere Leitung am Reset-Signal hast, hilft ggf. ein externer definierter Pullup Widerstand gegen Störungen auf der Leitung.

Der Reset Pin bleibt gänzlich unbeschaltet. ISP wird auf der fertigen Platine nicht mehr verwendet. Hatte die Pins bei der Vorgängersteuerung herausgeführt, aber zum Nachprogrammieren nie benötigt. Das Programm lief nach der Entwicklungsphase so stabil, dass dies nicht mehr notwendig war.

nicht stark EM-verseucht ist

Ok, das ist ein Argument. Wenn ich bedenke was an Steuersignalen da herumschwirrt (DCC Steursignale über Schienen, über DMX angesteuerte Raumbeleuchtungs-LED) werde ich dem Tiny einen externen Pullup gönnen.
Ein 10K, entspricht etwa 0,5mA, sollten dann wohl reichen.

 

[LotadaC]

Wenn Du den Pin gar nicht beschaltest - nichtmal 'n Stück Leiterbahn - , wirkt nur das Bein selbst als sehr(!) kurze Antenne. Ein eventueller externer Pullup liegt parallel zum internen - Du hast also effektiv etwas(!) weniger als 10k
Hattest Du denn bisher Externe?

Falls es dennoch unumgänglich sein sollte, kannst Du die ISP-Beine immer noch über die verwendeten Anschlußlitzen erreichen, lediglich den Reset mußt Du dann anderweitig kontaktieren. Dino hat ja für sowas seine Challenger-Clips (auch wenn die damals freihand am Tiny10 versagt haben...)

 

[stinakovits]

Du hast also effektiv etwas(!) weniger als 10k

Hehe, ich weiß.
Daher schrieb ich vorher: "entspricht ETWA"
Wenn man Dirks Angaben zu Grunde legt ergibt das einen Gesamtwiderstand von, R1*R2/(R1+R2), 7K5 bis 8K57 entspricht 0,67mA bis 0,58mA +- ein paar Prozentchen

Hattest Du denn bisher Externe?

Ja, hatte ich. Da war aber 'ne Leiterbahn zu einem PAD vorhanden für ISP Programmierung.

kannst Du die ISP-Beine immer noch über die verwendeten Anschlußlitzen erreichen

So ist es leider nicht, weil da ein Treiber, ULN2803, dazwischen liegt. Aber macht nichts. Im absoluten Notfall würde ich auch so zu den vier notwendigen Pins kommen. Die restlichen zwei sind ja sowieso kein Problem.