Schaltungen, Hilfe bei allen Fragen selbstgebaute Hardware

[Kappler]

Den ersten Denkfehler sehe ich bei:

... die LEDs sind gegenpoligangeschlossen...

Leuchtdioden leuchten nämlich in Fluss-, nicht in Sperrrichtung. Da sperren Sie, wie der Name schon sagt, den Stromfluss ab.

Weiter hab ich noch nicht geschaut...

 

[peter51d]

ok, wohl ungeschickt geschrieben.

Hier mal ein kleines Schaltbild.


Gruß

peter51d

 

[Teddy-Teufel]

ok, wohl ungeschickt geschrieben.
Hier mal ein kleines Schaltbild.

Gruß
peter51d

Gegenläufig ist schon klar aber warum legts Du nicht eine LED an Port3 und eine an Port4, jeweils zu GND und schreibst Dir ein entsprechendes Programm. Da kannst Du Dir dann (falls gewünscht) gleich noch aussuchen welche LED als Lichtsensor dienen soll. Ich würde das so empfehlen, so hast dann die neue LED-Only-Variante realisiert. Weiteres falls erfoderlich über PN.

 

[thomas_st]

Bei PB3 High und PB4 low sollte doch die eine leuchten und wenn ich dann PB3 auf low und PB4 auf High setze müsste doch die andere Leuchten oder?

Jep. Sollten sie.

Code dazu sieht so aus:

Ich kenne mich mit Bascom zwar nicht aus, aber einen gravierenden Fehler habe ich nicht entdeckt. Frage an die Bascom Experten:

Ddrb = &B00011000 'PB3 und PB4 ist Ausgang. Die anderen

Ist das "&" so richtig?

Ansonsten sehe ich einen kleinen Fehler, der aber nicht die eigentliche Funktion verhindern sollte (die LEDs sollten jedenfalls leuchten):

$crystal = 113000 'Reale Frequenz des internen 128kHz-Oszillators

passt nicht zu

Fuse sind out of the Box.

. In diesem Fall rennt der Tiny mit dem 9,6MHz RC-Generator und gesetztem CKDIV/8 Fuse, d.h. mit 1,2MHz - deine waitms 100 werden damit nicht 100ms warten sondern so ca. 10ms - das sind 100 Hz, dass kann man nicht mehr erkennen -> beide LEDs sollten dunkel leuchten aber nicht blinken.

Warum so kompliziert? Wenn wirklich nur die beiden LEDs gegenläufig blinken sollen, könnten auch beide individuell auf GND gelegt werden. Bei Deiner Schaltung könntest Du übrigens einen Vorwiederstand einsparen: der kann in die gemeinsame Leitung zum Tinypin. Da beim Widerstandswert ein "?" steht: was hast Du dort als Vorwiderstand eingebaut - ich würde mal Pi * Daumen 150 bis 220 Ohm vorschlagen.

Viele Grüße,
Thomas(_st)

 

[peter51d]

@ Teddy Teufel

Im Moment, geht es mir gar nicht mehr um ein Reaktivlicht.
Ich wäre zur Zeit schon glücklich, wenn ich dem Tiny irgeneine Reaktion entlocken könnte.

@ Thomas_St

Das & sollte passen, findet sich so zumindest in allen Bascom codes die ich bisher gesehen habe.

OK, die Frequenz hab ich mir aus nem anderen Code "geklaut".
Die Fusebits habe ich jetzt umgestellt auf 128kHz ohne division.
Startup auf slow

Die wait Zeit auf 1000 erhöht, so das die LED's mit ca 1Hz blinken sollten.

Beide LED's einzelnd gegen GND hätte ich auch machen können, hab es auch schon probiert, läuft aber auch nicht.

Die LED's hatte ich grade noch rum liegen. Sind LowCurrent Led's die mal als Kontrollleuchten in Schaltern für ein HomeControl System verbaut werden sollten.
Der Vorwiederstand liegt bei ~ 1k und schon mit der LED verlötet. Stromaufnahme irgend wo bei 5mA.

Es tut sich ums Verrecken nichts.


Zum Testen habe ich jetzt alle Eingänge auf und Reset auf Vcc gesetzt. Die LED's sind raus.

Die Ausgänge bleiben stumm.

Mit dem Multimeter messe ich von den Ausgängen gegen Vcc ~ 0,7V und gegen GND ~0,2V.

Lagsam glaube ich der Programmer schreibt irgendetwas in den Tiny aber nicht das was er soll.

Getestet mit zwei Tiny's, mehr habe ich im Moment nicht, beides mal das selbe.

Langsam glaube ich, das ist nichts für mich.

Gruß

peter51d

 

[thomas_st]

Zum Testen habe ich jetzt alle Eingänge auf und Reset auf Vcc gesetzt. Die LED's sind raus.

Lasse mal den Reset offen - bei bedarf kurzzeitig mal mit einer Drahtbrücke gegen Masse schalten um einen Reset auszulösen.

Merkwürdig, wenn ich den Bascom-Code richtig interpretiere werden die Pins ordentlich auf Ausgang konfiguriert, verhalten sich aber nach diesen Messungen zu urteilen:

Mit dem Multimeter messe ich von den Ausgängen gegen Vcc ~ 0,7V und gegen GND ~0,2V.

wie Eingänge (hochohmig, so dass Du sie per Multimeter auf den gerade verwendeten Referenzlevel ziehen kannst)

Lagsam glaube ich der Programmer schreibt irgendetwas in den Tiny aber nicht das was er soll.

Woran erkennst Du bei bascom eigentlich, dass das Programmieren geklappt hat - beim AVRStudio wird nach dem Programmieren ein Verify durchgeführt. Gibt es bei Bascom was vergleichbares? Sonst könnte es nämlich wirklich sein, dass da irgendwas geschrieben wird nur nicht das was gewollt ist ...

Viele Grüße,
Thomas(_st) - Blöder Gedanke: hat Bascom einen Testmodus fürs Programmieren? Nicht das das Ganze nur Testweise aber noch nicht wirklich in den Tiny gebrannt wird...

 

[Windi]

Das Programm sieht so weit o.k. aus und sollte meiner Meinung nach funktionieren.
Wird denn der Tiny fehlerfrei erkannt und geht die Programmierung ohne Fehler über die Bühne?
Leuchten die LEDs wenn die sie zwischen GND und VCC hältst?
Probier mal zum Setzen der Ports folgendes aus: Config Portb = &B00011000

 

[peter51d]

Die Geschichte mit dem reset brachte keine Änderung.
Die LED's sind OK,
Config Portb = &B00011000 ändert auch nichts.

Der Tiny wird sauber erkannt, Fusebits lassen sich problemlos lesen und schreiben.

Nach dem flashen zeigt Bascom, das x bytes geschrieben wurden.
Der Speicher lässt sich auch auslesen, nur steht dann scheinbar mehr drin als geschrieben wurde.

Hier ein paar Screenshots.
Leere Speicher


Compiliertes Programm vor dem flashen


Anzeige nach dem flashen

 

[peter51d]

Ausgelesener Speicherinhalt.


Was die Kryptischen Zeichen im blauen Bereich neben den Programmzeilen bedeuten weiss ich nicht.

Vielleicht ist das bei Bascom ja normal.

Leider gibt es wohl keine Möglichkeit, den Speicherinhalt wieder "normal" sichtbar zu machen.

Ich hasse so was.

peter51d

 

[Windi]

Was die Kryptischen Zeichen im blauen Bereich neben den Programmzeilen bedeuten weiss ich nicht.

Die kryptischen Zeichen im blauen Bereich sind die entsprechenden ASCII-Zeichen.

 

[thomas_st]

Compiliertes Programm vor dem flashen
[...]
Anzeige nach dem flashen

Das sieht gleich aus.
Einerseits gut: Programm, Programmer, Tiny scheinen in diese Richtung zu funktionieren, aber auch schlecht: es bringt uns der Lösung nicht näher.

Eigentlich die letzte Idee die ich habe: kannst Du mal nachsehen, wie das Fusebit bzgl. Watchdog gesetzt ist (lt. Datenblatt heißt er WDTON und liegt im Fuse Low Byte an Bit 5, allerdings benennt Bascom die Fusebits um - keine Ahnung wie es dort heißt)? Nicht dass Du den Watchdog mit sehr kurzem Intervall laufen hast, ihn aber nicht zurücksetzt und er den Tiny immer gleich wieder resetet.

HTH,
Thomas(_st) - Wenn es gesetzt ist / WD an ist - bitte ausschalten

PS: wenn möglich könntest Du auch den Vorwiderstand etwas verkleinern - 1k scheint mir etwas groß zu sein ... wobei bei Lowcurrent LED könnte es passen.

 

[peter51d]

Watchdog werde ich heute abend noch mal nachschauen, bin mir aber ziemlich sicher, das er deaktiviert ist.
Die LED's sind z.Z. schon gar nicht mehr angeschlosse, leuchten aber sicher ab 3,3V. Habe ich mit einer FePo Zelle getestet.

Bringen einen die ACSII Zeichen irgendwie weiter?

Gruß

peter51d

 

[Teddy-Teufel]

...
Gruß peter51d

Trarrar die Post ist da.

 

[peter51d]

Gerade noch mal geschaut, Wotchdog ist aus.

Entweder sind die beiden Tiny's hin, oder der Programmer spinnt.

Mal sehen, ob ich in meiner Nähe jemanden finde, der auch Hardware zum Flashen hat um der Sache mal auf den Grund zu gehen.

Gruß

peter51d

 

[Teddy-Teufel]

Gerade noch mal geschaut, Wotchdog ist aus.
Entweder sind die beiden Tiny's hin, oder der Programmer spinnt.
Mal sehen, ob ich in meiner Nähe jemanden finde, der auch Hardware zum Flashen hat um der Sache mal auf den Grund zu gehen.
Gruß
peter51d

Schmeiß die Tinys nicht weg, bevor Du nicht ganz genau weißt, daß sie kaputt sind. So schnell geht das nämlich nicht. Ich habe schon mal einen falsch gepolt und er wurde sauheiß aber er hat das Ganze gut überstanden, nicht mal der Code war weg.

 

[thomas_st]

Gerade noch mal geschaut, Wotchdog ist aus.

So langsam gehen mir die Ideen aus ...

Entweder sind die beiden Tiny's hin, oder der Programmer spinnt.

Der Tiny 13 scheint mir subjektiv recht robust zu sein (im Gegensatz zum Tiny 25, von dem ich zwei mittels wirklichem ISP geschrottet habe).

Ich schieße jetzt mal wild in Blaue:

ersetze mal die Zeile
Ddrb = &B00011000 'PB3 und PB4 ist Ausgang. Die anderen Pins sind Eingänge
durch:
Config Portb.3 = Output
Config Portb.4 = Output

Baue dann mal vor der do - loop Schleife ein einfaches
Portb.3 = 1 'Signal auf PB3 einschalten (HIGH)
Portb.4 = 0 ' Signal auf PB4 ausschaltem (low)
ein
und leere die do loop schleife mal komplett (ein waitms darf drinnen bleiben).

Jetzt mal mit dem Multimeter die Pins durchmessen.

Dabei noch eine Frage: das "End" am Programmende muss sein, oder nicht?

Viele Grüße,
Thomas(_st)

 

[qByter]

Hallo,

also

Anzeige nach dem flashen

und

Ausgelesener Speicherinhalt.

sind grundverschieden, das sollte aber identisch sein
Insofern scheint der Programmer da wirklich Mist zu machen.
Normalerweise macht Bascom ein Verify, allerdings kann das evtl. deaktiviert sein. Schau mal unter Options -> Programmer, da sollte der Haken bei "AutoVerify" gesetzt sein.

 

[qByter]

Noch eine Idee:
Klassiker, bei dem sich die Fuses auslesen lassen aber beim Programmieren nur Mist geschrieben wird ist eine fehldende/mangelnde Stromversorgung des Tiny´s beim Programmieren.
Hat er auch wirklich Saft?

 

[Teddy-Teufel]

Noch eine Idee:
Klassiker, bei dem sich die Fuses auslesen lassen aber beim Programmieren nur Mist geschrieben wird ist eine fehldende/mangelnde Stromversorgung des Tiny´s beim Programmieren.
Hat er auch wirklich Saft?

Mein Programmieradapter
Ich habe das alles mal erfolgreich "nachempfunden". Es kann doch nur noch sein, daß irgendwo eine Verbindung fehlt. Je öfter man sich seine Schaltung ansieht, desto betriebsblinder wird man. Einfach noch einmal neu löten, hat schon öfter geholfen.

 

[stonewood]

Entweder sind die beiden Tiny's hin, oder der Programmer spinnt.

Ersteres wohl definitiv nicht. Aber zumindest das bascom-avr hat beim usbasp eine Angewohnheit den neuen Code nicht automatisch zu laden. Also: Einmal das Programmer-Fenster schließen und wieder neu aufmachen nachdem neu kompiliert ist. Hat mich auch schon ein paar graue Haare gekostet.