• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Reaktives Licht mit Atmel AVR

Windi

Geoguru
Sehr seltsam.
Hast Du schon ein Programm comiliert und versucht runterzuladen? Falls ja, poste doch mal den Quelltext.
Es gibt nämlich in Bascom auch Kommandos welche beim Programmieren direkt die Fusebits verändern können.

Hast Du da einen externen Taktgeber dran?
 

Kappler

Geowizard
Ich habe eben gesehen, dass hier ja ALLE Fuse- und Lockbits auf 0 stehen, was eigentlich nicht die Default-Werte sein dürften (laut Datenblatt).

Spasseshalber hab ich dann mal ein ganz einfaches Programm:
Code:
'      Dauerblinken 3 Sekunden Abstand.
'============================================================
'
' ************************************
' *** ***
' *** Blinklicht 3 Sekunden ***
' *** ***
' ************************************
'
' ƒÊC: ATtiny13
' +Ub: 3,00 V
''
'============================================================
$regfile = "ATtiny13.DAT"
$crystal = 128000                       'Frequenz des internen 128kHz-Oszillators
Config Portb = &B00011000               'Pinb.3 und .4 auf 'Ausgang', Rest auf 'Eingang' schalten
Portb = &B11100111                      'Pullups zuschalten, auser fur Pinb.3 und .4

Stop Adc                                'A/D-Wandler abschalten, um Strom zu sparen
Stop Ac                                 'Analog-Komparator abschalten, um Strom zu sparen

Do
   Wait 3
   Gosub Leuchten
Loop

Leuchten:
   Portb.3 = 1
   Waitms 50
   Portb.3 = 0
   Return

End

übertragen, und siehe da: es funktioniert und die LED blitzt munter vor sich hin (zwar nicht im 3-Sekunden-Abstand sondern deutlich schneller, aber das dürfte wohl daran liegen, dass mein Wert für crystal nicht zur aktuellen Taktrate passt. Es wird übrigens irgendeiner der internen Takte verwendet, extern habe ich jedenfalls nichts angeschlossen.

Anscheinend werden nur die Fuse- und Lock-bits nicht korrekt ausgelesen/geschrieben.
Ich verwende übrigens den myAVR mySmartUSB Programmer, den ich über den ISP-Stecker nach Kochbuch angeschlossen habe. Mein Notebook hat leider keine paralleleln oder seriellen Schnittstellen.
Aber da das Übertragen des Programms funktioniert, gehe ich mal davon aus, dass die Kommunikation Bascom - uC prinzipiell funktioniert...
 

Windi

Geoguru
Kappler schrieb:
Ich verwende übrigens den myAVR mySmartUSB Programmer ...
Da haben wir auch schon des Rätsels Lösung.
Mit dem USB-Programmer kann man unter Bascom nicht auf die Fusebits zugreifen.
Steht sogar irgenwo bei den FAQs auf der myavr-Seite.
 

Kappler

Geowizard
Windi schrieb:
Mit dem USB-Programmer kann man unter Bascom nicht auf die Fusebits zugreifen.
Steht sogar irgenwo bei den FAQs auf der myavr-Seite.

Da muss ich wohl noch mal genauer nachschauen... :oops:

Ich mach mich dann mal auf die Suche nach einem anderen Tool, mit dem der USB-Adapter auf die Fuse-Bits zugreifen kann (ich glaube, in der mySmartUSB-Anleitung waren einige Einstellungen beschrieben; von einem der Programme wird es hoffentlich eine Demo-Version geben... Oder kennt jemand schon eines?)
 

chr2k

Geomaster
Danke Danke Danke!!! Es hat auf Anhieb funktioniert!


verbeugen.gif
verbeugen.gif
verbeugen.gif
verbeugen.gif
 

stonewood

Geowizard
chr2k schrieb:
TeamElvis schrieb:
die bezeichnung ist ATtiny13V-10SU.

Das ist wohl ne zwischengröße. Kompakte Bauform oder so. Der SMD Typ müsste dei Bezeichnung ATTINY13V-10MU haben.
Code:
Ordering Code      Package   Kommentar
ATtiny13V-10SU     8S2       'großes' SMD, 8 Pins, ca. 5x5 mm
ATtiny13V-10SSU    S8S1      'kleines' SMD, 8 Pins , ca. 4x5 mm
ATtiny13V-10MU     20M1       quadratisch, 20 Pins, SMD 
ATtiny13V-10PU     8P3        DIP, 8 Pins

Was im Datenblatt nicht alles drin steht. :wink:

TeamElvis, das ist also definitiv ein SMD-Typ mit 1,27mm Pinabstand. Wer's wirklich klein mag kann ja damit was basteln, aber ich bevorzuge doch lieber den 10PU-Typ im DIP-Gehäuse.
 

Livingdream

Geocacher
Kappler schrieb:
Windi schrieb:
Mit dem USB-Programmer kann man unter Bascom nicht auf die Fusebits zugreifen.
Steht sogar irgenwo bei den FAQs auf der myavr-Seite.

Da muss ich wohl noch mal genauer nachschauen... :oops:

Ich mach mich dann mal auf die Suche nach einem anderen Tool, mit dem der USB-Adapter auf die Fuse-Bits zugreifen kann (ich glaube, in der mySmartUSB-Anleitung waren einige Einstellungen beschrieben; von einem der Programme wird es hoffentlich eine Demo-Version geben... Oder kennt jemand schon eines?)

Mit AVRStudio4, kostenlos von der Atmel AVR Seite downzulowden, sollte es problemlos möglich sein. Im AVRStudio unter tools den Programmer AVRProg auswählen, dann sollte der mysmartUSB Programmer automatisch gefunden werden. (Siehe Seite 11 des mysmartUSB Manuals).
AVRStudio wird auch von BASCOM als externer Programmer angesprochen.
 

Kappler

Geowizard
Danke, aber ich habe es inzwischen auch schon mit der Demo vom "myAVR Workpad" hinbekommen.
Das ist auch sehr komfortabel.

Die ersten Versuche sehen auch schon sehr vielversprechend aus :p
 

chr2k

Geomaster
ich bekomme jetzt beim neu programieren eines Tinys immer wieder die Meldung von Bascom, nachdem er in den chip geschrieben hat und dann den speicher "liest"

"difference at 00000"

Hatte da jemand schonmal?

Auch das setzen der Fusebits klappt nciht wirklich. Ich setzte die beiden und schrieben sie aber wenn ich auf refresh klicke kommen wieder die alten werte raus.

Manchmal beim refreshen auch die Meldung "READLB entry not found"

Was ist da los? :? :? :?
 

Portitzer

Geocacher
Mit welchem Programmer arbeitest Du denn?
Ich hatte diesen Effekt auch schon mal. Es lag an falsch gesetzten Fusebits.
Interner Oszillator auf 128kHz und dann den Takt nochmal durch 8 geteilt... Das macht die ISP-Schnittstelle nicht mit. Da half dann nur noch die Anschaffung eines STK 500. Damit konnte ich die vielen "verkorksten" Chips wieder zum Leben erwecken :).

Viele Grüße
Kurt
 

chr2k

Geomaster
ich arbeite mit BASCOM und gestern, beim ersten versuch einen tiny zu programmieren klappte alles reiblungslos. auch der zweite versuch verlief gut.

Nun wollte ich grade eben einen schon beschriebenen tiny neu beschreiben und dann bekomm ich solche meldungen....
 

Portitzer

Geocacher
BASCOM ist die Programmiersprache...
Ich meinte eher die Hardware, die hinten dran hängt. Also, wo Du den Chip zum "Brennen" reinsteckst.

Beim STK500 vertauscht man auch gern mal die Strippen und bekommt dann auch diese Meldungen.

Gruß
Kurt
 

chr2k

Geomaster
ah, sorry, hab das so verstanden das der "programmer" die software wäre.

nun gut jetzt ist es geklärt ;-)

ich hab den Programmer ausm kochbuch nachgebaut. 5 bzw 6 drähte 2 widerstände an den tiny und gut
spannung dran. die schaltung hängt während des programmeirrens auch dran. sollte ja so funktionieren, wenn ich das richtig verstanden habe. Wie gesagt, gestern gings auch ;-)
 

Portitzer

Geocacher
Ok, also wenns gestern hardwaremäßig noch lief und alle Drähte noch dran sind, vermute ich mal, dass Du bei den Fusebits was geändert hast.

Wie ich schon schrieb, wenn Du da nicht aufpasst, stellen sich die Chips stur und wollen nicht mehr. Im schlimmsten Fall sind sie dann für immer im Siliziumnirvana.

Im besten Fall lassen sie sich mit einem STK500 wieder zum Leben erwecken.

Gruß
Kurt
 

Windi

Geoguru
Was evtl. Probleme bereitet sind die Taktfrequenzen.
Wenn man einen Chip auf 16 kHz "gefused" hat (128 kHz, Teiler durch 8 on) dann hat man nur noch Zugriff auf ihn wenn man im Programm den Crystal-Wert auf 16000 einstellt und dann das Programm nochmals kompiliert.
Dadurch passt der Programmer seine Geschwindigkeit an die Taktfrequenz des Chips an.

Wenn im Programm schon 16000 drinsteht dann mal mit 128000 versuchen und nochmals kompilieren.
 

chr2k

Geomaster
Hallo Kurt,

Portitzer schrieb:
Wie ich schon schrieb, wenn Du da nicht aufpasst, stellen sich die Chips stur und wollen nicht mehr. Im schlimmsten Fall sind sie dann für immer im Siliziumnirvana.

die Fusebits habe ich wie im Kochbuch beschrieben gesetzt, gestern bei den 2 funktionierenden chips genauso wie heute. heute habe ich wie schon gesagt den einen chip von gestern genommen und wollte auf den einen neuen code schreiben. da hats schon nicht mehr funktioniert. und ich denke das ich die fusebits ja nciht nochmal einstellen muss wenn ich sie bei eeinem tiny schon gemach thabe udn diesen wieder beschreiben will.
als das halt nicht funktionierte habe ich einen unbenutzten tiny genommen, dort versucht die fusebits nach anleitung zu setzen, habe vorher auch nochmal die restlichen einstellungen die im kochbuch beschrieben sind überprüft, doch leider fehlanzeige mit diversen fehlermeldungen oder einem refresh die alten fusebit werte, wo ja eigentlich dann die neu gesetzten erscheinen müssten....

selbe spiel wieder. ich hab die programmer schaltung nochmal neu verklemmt, diesmal nur den tiny ohne reaktiv licht schlatung.

aber nichts geht
 

Portitzer

Geocacher
Evtl. waren die Fuses ja schon beim ersten Brennen auf 16kHz eingestellt...
Versuchs einfach mal nach Windis Anleitung.

Gruß
Kurt
 

chr2k

Geomaster
Was evtl. Probleme bereitet sind die Taktfrequenzen.
Wenn man einen Chip auf 16 kHz "gefused" hat (128 kHz, Teiler durch 8 on) dann hat man nur noch Zugriff auf ihn wenn man im Programm den Crystal-Wert auf 16000 einstellt und dann das Programm nochmals kompiliert.
Dadurch passt der Programmer seine Geschwindigkeit an die Taktfrequenz des Chips an.

Ichh bin mir aber sicher, dass ich keinen chip auf 16khz gefused habe. bevor ich auf write FS geklictk habe, habe ich antürlich die fusebits laut Kochbuch gesetzt.


Windi schrieb:
Wenn im Programm schon 16000 drinsteht dann mal mit 128000 versuchen und nochmals kompilieren.

Irgendwie haut das nicht hin. Wobei ich mir nicht sicher bin ob ich alles richtig mache. Die Werte im Reiter FuseBits irritieren mich immer. Manchmal steht sogar 1111 reserved im FS DCBA drin...
 

chr2k

Geomaster
Portitzer schrieb:
Evtl. waren die Fuses ja schon beim ersten Brennen auf 16kHz eingestellt...

wie gesagt bevor ich die unbenutzten tinys bebrannt/gebrannt habe, habe ich die fusebits nach anleitung eingestellt und dann die FS geschrieben, dann ein code "geschrieben" compiled und dann auf den tiny geschrieben/gebrannt.

wie kann sonst noch das fusebit umgestellt werden? durch die $crystal = 16000 ja nicht oder?
was hat es überhaupt für einen sind die fusebits auf 128k zu stellen und im code dann wieder 16k zu sagen?
 
Oben