HALLO ZUSAMMEN kann man Pin5 (PB5) MOSI und AREF zum Programieren und als adc referenzspannung verwenden?? danke
ja. Allerdings kannst du PB5 nur zum Programmieren (als Ein- oder Ausgang) verwenden.
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
VEIEN dANK FÜR DIE ANTWORT, geht es auch mit dem gleichen Programm, wenn ich mit Pin1 debuggen und als aanalogeingang verwenden??
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
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.
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
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?? :-(
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.
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
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
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.
> > 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
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.
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.
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
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
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.