Forum: Mikrocontroller und Digitale Elektronik aTTiny 45 progrmieren


von Paulo R. (paulo-rock)


Lesenswert?

HALLO ZUSAMMEN
kann man Pin5 (PB5) MOSI und AREF zum Programieren und als adc 
referenzspannung verwenden??
danke

von niemand (Gast)


Lesenswert?

ja. Allerdings kannst du PB5 nur zum Programmieren (als Ein- oder 
Ausgang) verwenden.

von Bernd O. (bitshifter)


Lesenswert?

Paulo Rock schrieb:
> HALLO ZUSAMMEN
> kann man Pin5 (PB5) MOSI und AREF zum Programieren und als adc
> referenzspannung verwenden??
> danke
Gleichzeitig nicht, aber wenn die externe Beschaltung so flexibel ist, 
AREF für die Zeit der Programmierung freizugeben, dann schon. Ist aber 
bei den anderen Pins (SCK, MISO und RESET) nicht anders. Hier muß der 
Programmer auch frei "werkeln" können, also nicht gegen andere Ausgänge 
ankämpfen müssen.

Da die Tinys aber ohnehin zu wenig Pins haben, empfehle ich den Einsatz 
eines Bootloaders. Dann kann man beispielsweise den Reset-Pin 
mitverwenden und das Programm auch schneller aktualisieren als per ISP.

Benötigte Hardware beschränkt sich auf einen Widerstand am Target 
(Pull-Up) und einen Widerstand und zwei Dioden für den (seriellen) 1-Pin 
Programmieradapter.

Hier mal ein guter Link:
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger

Gruß,
Bernd

von Paulo R. (paulo-rock)


Lesenswert?

VEIEN dANK FÜR DIE ANTWORT,
geht es auch mit dem gleichen Programm, wenn ich mit Pin1 debuggen und 
als aanalogeingang verwenden??

von Bernd O. (bitshifter)


Lesenswert?

Paulo Rock schrieb:
> VEIEN dANK FÜR DIE ANTWORT,
> geht es auch mit dem gleichen Programm, wenn ich mit Pin1 debuggen und
> als aanalogeingang verwenden??
Der Anschluß ist nicht zum Debuggen gedacht, sondern zum Programmieren. 
Ob das geht hängt vom Ausgangswiderstand Deiner Analogspannungsquelle 
ab.

Warum bist Du so wild darauf, die Pins zum Programmieren mit 
Analogtechnik zu versehen?

Gruß,
Bernd

von Thomas E. (thomase)


Lesenswert?

Paulo Rock schrieb:
> geht es auch mit dem gleichen Programm, wenn ich mit Pin1 debuggen und
>
> als aanalogeingang verwenden??

Das kann man machen. aber nur einmal.
Pin1 ist Reset und bleibt auch solange Reset, bis nichts anderes mehr 
geht.

Über den Reset-Pin wird das SPI in den Programmiermodus geschaltet. 
Übers SPI wird  das Programm geflasht und es werden die Fuses 
eingestellt. Mit einem JTAGICE kann man über den Reset-Pin auch noch 
debuggen.

Erst wenn alle anderen Möglichkeiten erschöpft sind, das Programm 100% 
läuft und man nie wieder etwas ändern will, dann kann man den Reset-Pin 
für andere Aufgaben verwenden.

Bernd O. schrieb:
> Da die Tinys aber ohnehin zu wenig Pins haben, empfehle ich den Einsatz
>
> eines Bootloaders. Dann kann man beispielsweise den Reset-Pin
>
> mitverwenden und das Programm auch schneller aktualisieren als per ISP.

An sowas sollte man sich lieber nicht halten.

mfg.

von Bernd O. (bitshifter)


Lesenswert?

Thomas Eckmann schrieb:
> Bernd O. schrieb:
>> Da die Tinys aber ohnehin zu wenig Pins haben, empfehle ich den Einsatz
>>
>> eines Bootloaders. Dann kann man beispielsweise den Reset-Pin
>>
>> mitverwenden und das Programm auch schneller aktualisieren als per ISP.
>
> An sowas sollte man sich lieber nicht halten.
Die Tinys haben eine zuverlässige Brownout-Erkennung - da kann man den 
Reset-Pin problemlos für einen Bootloader (und zur Laufzeit auch noch 
für andere Dinge) verwenden. Der Bootloader schützt sich davor, sich 
selbst zu überschreiben.

Desweiteren geht die Entwicklung auch flüssiger, da der Download x-Mal 
schneller läuft als per ISP.

Was spricht Deiner Ansicht nach dagegen?

Gruß,
Bernd

von Paulo R. (paulo-rock)


Lesenswert?

aber im datasheet steht pin1 PCINT5/RESET/ADC0/dW
dW debugWIRE.
wenn dW angeslossen zum programmieren ist , dann kann ich ADC0 nicht für 
meinen Temperatursensor verwenden oder?? :-(

von Thomas E. (thomase)


Lesenswert?

Bernd O. schrieb:
> Desweiteren geht die Entwicklung auch flüssiger, da der Download x-Mal
>
> schneller läuft als per ISP.

Wie gross ist denn dein x? Oder andersrum wie lahm ist dein 
ISP-Programmierer?

Bernd O. schrieb:
> Was spricht Deiner Ansicht nach dagegen?

Dass man mit einem Bootloader keine Fuses programmieren und nicht mehr 
debuggen kann.


Thomas Eckmann schrieb:
> Erst wenn alle anderen Möglichkeiten erschöpft sind, das Programm 100%
>
> läuft und man nie wieder etwas ändern will, dann kann man den Reset-Pin
>
> für andere Aufgaben verwenden.

Dann spricht auch nichts mehr dagegen.


mfg.

von Bernd O. (bitshifter)


Lesenswert?

Thomas Eckmann schrieb:
> Bernd O. schrieb:
>> Desweiteren geht die Entwicklung auch flüssiger, da der Download x-Mal
>>
>> schneller läuft als per ISP.
>
> Wie gross ist denn dein x? Oder andersrum wie lahm ist dein
> ISP-Programmierer?
X ist geschätzt Faktor 3 gegenüber einem BitBang-Adapter an RS232 mit 
den Standardeinstellungen von avrdude.

>
> Bernd O. schrieb:
>> Was spricht Deiner Ansicht nach dagegen?
>
> Dass man mit einem Bootloader keine Fuses programmieren und nicht mehr
> debuggen kann.
Klar, wenn man das muß und keinen HV-Programmer hat oder keine 0,44 € 
für einen neuen Tiny, dann lässt man es besser.

Debuggen ist ohnehin eine Glaubensfrage. Ich hatte mal einen 
Vorgesetzten, der ein wirklich guter Programmierer war und der Debuggen 
äußerst skeptisch gegenüberstand - und ich muß sagen - er hatte Recht. 
Ein Programmierer, der seine Programmiersprache beherrscht brauch nur 
äußerst selten bis nie einen Debugger, während Amateure ohne Debugger 
aufgeschmissen sind. Diese Beobachtung hat sich im Laufe der Jahre immer 
wieder bestärkt. Ich habe etliche Leute gesehen, die ständig zwischen 
Editor und Debugger hin- und hergesprungen sind, weil sie ständig 
überprüfen mussten, ob der Code denn auch das tut was sie glauben was er 
tun sollte. Das nennt sich dann "debugging code into existence" (siehe 
"Expert C programming") und ist ziemlich übel zu pflegen.


> Thomas Eckmann schrieb:
>> Erst wenn alle anderen Möglichkeiten erschöpft sind, das Programm 100%
>>
>> läuft und man nie wieder etwas ändern will, dann kann man den Reset-Pin
>>
>> für andere Aufgaben verwenden.
>
> Dann spricht auch nichts mehr dagegen.
Außer vielleicht der Tatsache, dass man es dann nicht mehr braucht, denn 
ein "Programm, das zu 100 % läuft und an dem man nie wieder etwas ändern 
will" kann man nicht mehr an die Nutzung des Reset-Pins anpassen, denn 
dazu müsste man es ändern...

=> Wenn die Pins wie beim Tiny knapp sind, dann lieber frühzeitig den 
Reset-Pin "freifusen" und ordentlich austesten. Späte Änderungen bergen 
ein höheres Risiko, weil die Erprobungstiefe fehlt.

... und wenn man tatsächlich nicht um einen Debugger herumkommt, dann 
muß man wohl oder übel ein paar Cent springen lassen und sich einen 
zweiten Tiny kaufen ;-)

Gruß,
Bernd

von Bernd O. (bitshifter)


Lesenswert?

Paulo Rock schrieb:
> aber im datasheet steht pin1 PCINT5/RESET/ADC0/dW
> dW debugWIRE.
> wenn dW angeslossen zum programmieren ist , dann kann ich ADC0 nicht für
> meinen Temperatursensor verwenden oder?? :-(
Mal ganz grundsätzlich:
Das Datasheet listet alle möglichen Anwendungen dieses Pins auf. Je 
nachdem wie man die RSTDISB- und die DWEN-Fuse setzt, dient der Pint 
entweder als Reset-Pin und Debugger-Schnittstelle oder als "normaler" 
Port-Pin mit den Zusatzfunktionen PCINT5/ADC0.

Wenn der Pin also für's Debuggen verwendet werden soll, dann kann er 
ohne die Fuses zu ändern nicht als Eingang ADC0 verwendet werden. 
Programmieren über dW geht übrigens nicht.

Wenn Du also alle sechs Pins vom ATtiny brauchst, dann bleibt Dir nichts 
anderes übrig als einen Bootloader zu verwenden oder einen 
HV-Programmierer anzuschaffen. Beim Bootloader kann über jeden 
beliebigen Pin der sechs Pins das Programm aktualisiert werden. 
Typischerweise verwendet man einen Pin, der ansonsten ein Ausgang des 
Tiny ist.

Beschreib' doch Dein Projekt etwas näher, dann kann man vermutlich auch 
besser helfen.

Gruß,
Bernd

von Thomas E. (thomase)


Lesenswert?

Bernd O. schrieb:
> Außer vielleicht der Tatsache, dass man es dann nicht mehr braucht, denn
>
> ein "Programm, das zu 100 % läuft und an dem man nie wieder etwas ändern
>
> will" kann man nicht mehr an die Nutzung des Reset-Pins anpassen, denn
>
> dazu müsste man es ändern...
>
>
>
> => Wenn die Pins wie beim Tiny knapp sind, dann lieber frühzeitig den
>
> Reset-Pin "freifusen" und ordentlich austesten. Späte Änderungen bergen
>
> ein höheres Risiko, weil die Erprobungstiefe fehlt.
>
>
>
> ... und wenn man tatsächlich nicht um einen Debugger herumkommt, dann
>
> muß man wohl oder übel ein paar Cent springen lassen und sich einen
>
> zweiten Tiny kaufen ;-)

Du versuchst hier irgendwas an den Haaren herbeizuziehen.
Das Abschalten des Reset ist einfach nicht ratsam.

Zum Thema Bootloader:

Der Attiny45 verfügt über keinen Bootsektor.
Wie kommt man aus einem verwursteten Programm, dass in einer Schleife 
fest-hängt, wieder in den Bootloader? Kannst du mir das erklären?

mfg.

von Paulo R. (paulo-rock)


Lesenswert?

>
> Beschreib' doch Dein Projekt etwas näher, dann kann man vermutlich auch
> besser helfen.

danke bernd,
 ich möchte ein EVAL.Board selbestbauen für ATTiny 45 mit einem T.Sensor 
und einem Poti, und die soll PWM ausgang haben und einen Openkolektor 
(auch ) als ausgang, deswegen möchte ich wessen, ob das geht oder nicht. 
da alle pins oder fast alle werden belegt

von Bernd O. (bitshifter)


Lesenswert?

Thomas Eckmann schrieb:
> Bernd O. schrieb:
>> Außer vielleicht der Tatsache, dass man es dann nicht mehr braucht, denn
>>
>> ein "Programm, das zu 100 % läuft und an dem man nie wieder etwas ändern
>>
>> will" kann man nicht mehr an die Nutzung des Reset-Pins anpassen, denn
>>
>> dazu müsste man es ändern...
>>
>>
>>
>> => Wenn die Pins wie beim Tiny knapp sind, dann lieber frühzeitig den
>>
>> Reset-Pin "freifusen" und ordentlich austesten. Späte Änderungen bergen
>>
>> ein höheres Risiko, weil die Erprobungstiefe fehlt.
>>
>>
>>
>> ... und wenn man tatsächlich nicht um einen Debugger herumkommt, dann
>>
>> muß man wohl oder übel ein paar Cent springen lassen und sich einen
>>
>> zweiten Tiny kaufen ;-)
>
> Du versuchst hier irgendwas an den Haaren herbeizuziehen.
> Das Abschalten des Reset ist einfach nicht ratsam.
Außer man braucht den zusätzlichen Pin. Was bei einem ATtiny nicht 
unwahrscheinlich ist. Ist ein Ressourcenzuwachs von 20 %!

> Zum Thema Bootloader:
>
> Der Attiny45 verfügt über keinen Bootsektor.
> Wie kommt man aus einem verwursteten Programm, dass in einer Schleife
> fest-hängt, wieder in den Bootloader? Kannst du mir das erklären?
Ja, man unterbricht die Versorgung des Targets, startet das 
Host-Programm des Bootloaders und versorgt das Target wieder. Dann 
startet auf dem Target zuerst der Bootloader und lädt dann die neue 
Version des Programs herunter.

Lies' Dir einfach mal die folgende Seite durch:
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger
Konkret den Teil "Anforderungen an das zu ladende Programm".

Ich gebe ja zu, dass ich vor zwei Jahren noch jeden davongejagt hätte, 
der mir mit "Bootloader" gekommen wäre. Ich wurde früher einfach von den 
Umständen dazu gezwungen, da ich für einen (mikro) Modell-Helikopter 
eine extrem leichte Hardware gebraucht habe. Das flugfertige Modell 
wiegt knapp 40 g - da tut DIL-8 statt SO-8 oder gar ein Sockel sehr weh. 
Natürlich geht da auch keine Leiterplatte, sondern die paar Bauteile 
werden direkt oben und unten auf das SO-8 Gehäuse des ATtiny gelötet und 
mit dünnen CuLa-Drähtchen kontaktiert. Um das im verlöteten 
(==flugfähigen) Zustand noch programmieren zu können bleibt einem nichts 
anderes übrig als einen Bootloader zu verwenden (zumal ich alle sechs 
Pins gebraucht habe).

Einmal erstellt, flasht man den Bootloader per ISP aufs Target und 
probiert aus, ob er läuft und ob sich andere Programme laden lassen. 
Danach nur noch über das serielle Interface.

Der verlinkte Bootloader ist mein Favorit, da er klein und zuverlässig 
ist und viele Bausteine abdeckt.

Mit einem Bootloader kann man übrigens auch einem Kunden ermöglichen, 
die Firmware billig, leicht und sicher zu aktualisieren. Der Kunde 
braucht nicht mehr als einen USB/RS232-Adapter - da tut's schon ein 
billiger prolific pl2303 für 1-2 Dollar oder wenn's Treiberfrei sein 
soll ein 232/USB-HID-Adapter. Wenn das Update warum auch immer abbricht, 
dann kann man es beliebig oft versuchen, da der Bootloader selbst 
niemals gelöscht wird und nach dem Reset immer wieder zur Verfügung 
steht.

Es gibt auch Bootloader, die mit Verschlüsselung arbeiten, dann kann man 
sogar kundenindividuelle Updatestrategien fahren und gibt das HEX nicht 
aus der Hand. Das Target kann dann über die Lock-Bits wirklich 
wasserdicht abgeschlossen werden, damit weder per ISP noch per HV 
irgendetwas geht.

von Thomas E. (thomase)


Lesenswert?

Bernd O. schrieb:
> a, man unterbricht die Versorgung des Targets, startet das
>
> Host-Programm des Bootloaders und versorgt das Target wieder. Dann
>
> startet auf dem Target zuerst der Bootloader und lädt dann die neue
>
> Version des Programs herunter.

Der Target startet von Adresse 0x000 springt in die verwurstete 
Schleife...

mfg.

von Bernd O. (bitshifter)


Lesenswert?

Paulo Rock schrieb:
>>
>> Beschreib' doch Dein Projekt etwas näher, dann kann man vermutlich auch
>> besser helfen.
>
> danke bernd,
>  ich möchte ein EVAL.Board selbestbauen für ATTiny 45 mit einem T.Sensor
> und einem Poti, und die soll PWM ausgang haben und einen Openkolektor
> (auch ) als ausgang, deswegen möchte ich wessen, ob das geht oder nicht.
> da alle pins oder fast alle werden belegt

Für ein Eval-Board und wenn Du mehr als fünf Pins brauchst, empfehle ich 
Dir, auf einen anderen Controller zu setzen, der genügend Pins hat 
(beispielsweise einen ATmega). Man sollte sich am Anfang nicht mit zu 
vielen Dingen gleichzeitig rumschlagen.

Wenn das Programm läuft kannst Du mit der gesammelten Erfahrung ohne 
große Probleme auf den ATtiny portieren - und lernst dabei gleich eine 
wichtige Lektion: Nicht zu nah an der Hardware arbeiten und 
Schnittstellen einzubauen, die die Portierung später erleichtern.

Technisch ist es wie geschrieben möglich, den Reset-Pin des ATtiny als 
Port-Pin zu verwenden, dann kann man aber nicht mehr mit dem "normalen" 
(ISP-)Programmieradapter arbeiten, sondern es muß auf dem ATtiny ein 
"Grundprogramm" (also der Bootloader) laufen, das nach dem Reset mit dem 
PC kommuniziert und das Programm für den ATtiny runterlädt.

=> Für den Anfang lohnt sich dieser Aufwand nicht. Wenn etwas beim 
Flashen des Bootloaders und beim Umstellen der Fuses schief geht, dann 
ist der Tiny Schrott wenn man keinen HV-Programmer hat und der 
Frustlevel steigt.

Gruß,
Bernd

von Bernd O. (bitshifter)


Lesenswert?

Thomas Eckmann schrieb:
> Bernd O. schrieb:
>> a, man unterbricht die Versorgung des Targets, startet das
>>
>> Host-Programm des Bootloaders und versorgt das Target wieder. Dann
>>
>> startet auf dem Target zuerst der Bootloader und lädt dann die neue
>>
>> Version des Programs herunter.
>
> Der Target startet von Adresse 0x000 springt in die verwurstete
> Schleife...

Ist es denn so schwer einem Link zu folgen und einen Satz zu lesen?

Der Bootloader biegt (auf den ATtinys) die Adresse des ersten RJMP auf 
sich selbst um bevor das Programm ins Flash geschrieben wird und springt 
nachdem der Bootloader abgearbeitet ist an die im RJMP angegebene 
Adresse.

Du kannst Schleifen also verwursten wie Du willst, der Bootloader kommt 
immer als erster dran.

=> Der einzige Weg, den Bootloader zu killen ist mit fehlerhaftem Code, 
der das "self programming feature" des ATtiny nutzt. Wer das nicht 
sauber hinkriegt und schludert hat aber ganz andere Probleme und sollte 
seine Berufswahl überdenken, denn hier sägt man sprichwörtlich an dem 
Ast auf dem man sitzt - auch ohne Bootloader!

Gruß,
Bernd

von Thomas E. (thomase)


Lesenswert?

Bernd O. schrieb:
> Der Bootloader biegt (auf den ATtinys) die Adresse des ersten RJMP auf
>
> sich selbst um bevor das Programm ins Flash geschrieben wird und springt
>
> nachdem der Bootloader abgearbeitet ist an die im RJMP angegebene
>
> Adresse.

Und wenn genau das schief gegangen ist?

mfg.

von Bernd O. (bitshifter)


Lesenswert?

Thomas Eckmann schrieb:
> Bernd O. schrieb:
>> Der Bootloader biegt (auf den ATtinys) die Adresse des ersten RJMP auf
>>
>> sich selbst um bevor das Programm ins Flash geschrieben wird und springt
>>
>> nachdem der Bootloader abgearbeitet ist an die im RJMP angegebene
>>
>> Adresse.
>
> Und wenn genau das schief gegangen ist?
Dann ist der Flash unterhalb des Bootloaders noch leer, da er zuerst 
gelöscht wird und der Controller führt ein paar tausend NOPs aus bis er 
beim Bootloader angekommen ist.
Nach dem Löschen wird als erstes wieder der RJMP geschrieben.

Gruß,
Bernd

Bitte 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
Noch kein Account? Hier anmelden.