Hallo Zusammen,
ich versuche in Bascom eine TM1637 7-Segment Anzeige anzusteuern. das
klappt hervorragend mit dem Atmega8-8PU. Sobald ich den Code auf den
Atmega8-16PU flashe geht es nicht mehr. Ich sehe, dass der Controller
arbeitet: Eingaben werden gelesen und Serial out geht auch wunderbar,
aber nicht der TM1637. Habt iht eine Idee woran es liegen könnte?
Hier der Code:
$regfile = "m8def.dat"
$framesize = 32
$swstack = 32
$hwstack = 64
$crystal = 1000000 'Resonatorfrequenz
$baud = 9800 'Baudrate (Übertragungsgeschwindigkeit)
Baud = 9800
dim z as integer
dim result as String * 8
dim bit8,bit7,bit6,bit5,bit4,bit3,bit2,bit1 as integer
Config PortB.0 = Input ' Decimal or Hex Mode
'8 Bit Data Input
Config Portc.5 = Input
Config Portc.4 = Input
Config Portc.3 = Input
Config Portc.2 = Input
Config Portc.1 = Input
Config Portc.0 = Input
Config PortB.2 = Input
Config PortB.1 = Input
Config Portd.6 = Output ' for TM1637
data
Config Portd.7 = Output ' for TM1637
clock
Tm1637_clk Alias Portd.7
Tm1637_dout Alias Portd.6
Tm1637_din Alias portd.6
Declare Sub Tm1637_disp(byval Bdispdata As Word) 'The display
can only show numbers
Declare Sub Tm1637_wrbyte(byval Bdata As Byte)
Declare Sub Tm1637_on()
Declare Sub Tm1637_off()
Declare Sub Tm1637_start()
Declare Sub Tm1637_stop()
Declare Sub Tm1637_ack()
'=======================================================================
=
'
' Start main
'
'=======================================================================
=
'Tm1637_on
'Tm1637_disp 45
'Wait 2
'Tm1637_off
Tm1637_on
z=0
Do
result = str(pinc.5) + str(pinc.4) + str(pinc.3) + str(pinc.2) +
str(pinc.1) + str(pinc.0) + str(pinb.2) + str(pinb.1)
'Print result
bit8 = pinc.5 * 128
bit7 = pinc.4 * 64
bit6 = Pinc.3 * 32
bit5 = pinc.2 * 16
bit4 = pinc.1 * 8
bit3 = pinc.0 * 4
bit2 = pinb.2 * 2
bit1 = pinb.1 * 1
z = bit8
z = z + bit7
z = z + bit6
z = z + bit5
z = z + bit4
z = z + bit3
z = z + bit2
z = z + bit1
'if pinb.1 = 1 then
' pORTb.0 = 1
'else
' pORTb.0 = 0
'end if
Tm1637_disp z
'Print "Hallo - Ich zaehle: "; z
'incr z
'toggle PortB.0
'wait 1
Loop
'=======================================================================
==
'
' Subroutines
'
'=======================================================================
=
Sub Tm1637_ack()
Reset Tm1637_clk
Waitus 5
Reset Tm1637_dout
Bitwait Tm1637_din , Reset
Set Tm1637_clk
Waitus 2
Reset Tm1637_clk
Set Tm1637_dout
End Sub
Sub Tm1637_off()
Tm1637_start
Tm1637_wrbyte &H80 'Turn
display off
Tm1637_ack
Tm1637_stop
End Sub
Sub Tm1637_on()
Tm1637_start
Tm1637_wrbyte &H8A 'Turn
display on and set PWM for brightness to 25%
Tm1637_ack
Tm1637_stop
End Sub
Sub Tm1637_start()
Set Tm1637_clk
Set Tm1637_dout
Waitus 2
Reset Tm1637_dout
End Sub
Sub Tm1637_stop()
Reset Tm1637_clk
Waitus 2
Reset Tm1637_dout
Waitus 2
Set Tm1637_clk
Waitus 2
Set Tm1637_dout
End Sub
Sub Tm1637_disp(byval Bdispdata As Word)
Local Bcounter As Byte
Local Strdisp As String * 5
Strdisp = Str(bdispdata)
Strdisp = Format(strdisp , " ")
Tm1637_start
Tm1637_wrbyte &H40
'autoincrement adress mode
Tm1637_ack
Tm1637_stop
Tm1637_start
Tm1637_wrbyte &HC0
'startaddress first digit (HexC0) = MSB display
Tm1637_ack
For Bcounter = 2 To 5
Select Case Asc(strdisp , Bcounter)
Case "0" : Tm1637_wrbyte &B00111111
Case "1" : Tm1637_wrbyte &B00000110
Case "2" : Tm1637_wrbyte &B01011011
Case "3" : Tm1637_wrbyte &B01001111
Case "4" : Tm1637_wrbyte &B01100110
Case "5" : Tm1637_wrbyte &B01101101
Case "6" : Tm1637_wrbyte &B01111101
Case "7" : Tm1637_wrbyte &B00000111
Case "8" : Tm1637_wrbyte &B01111111
Case "9" : Tm1637_wrbyte &B01101111
Case Else : Tm1637_wrbyte &B00000000
End Select
Tm1637_ack
Next
Tm1637_stop
End Sub
Sub Tm1637_wrbyte(byval Bdata As Byte)
Local Bbitcounter As Byte
For Bbitcounter = 0 To 7 'LSB first
Reset Tm1637_clk
Tm1637_dout = Bdata.bbitcounter
Waitus 3
Set Tm1637_clk
Waitus 3
Next
End Sub
Ich würde als erstes die Fuse-Bytes vergleichen.
Da aber sonst alles funktioniert, ist das eher ein Schuss ins Blaue,
zugegeben.
> Serial out geht auch wunderbar
Ich hätte es ja als "wunderlich" bezeichnet - was ist das für ein Gerät
mit 9800 Bd?
Erstmal vielen Dank für die flotte Antwort S.Landolt. Das mit den 9800 Baud ist mir gar nicht aufgefallen, da alles copp/paste code ist :-) Funktioniert aber trotzdem! Kann man die Fuse Bits direkt in Bascom auslesen?
> mir gar nicht aufgefallen Aha - na okay, 2 % Fehler werden verkraftet. > Kann man die Fuse Bits direkt in Bascom auslesen? Tut mir leid, kann ich nicht sagen (arbeite nicht mit Bascom).
Okay Trotzdem vielen lieben Dank für die Hilfe. Ich schaue gerade nach wie ich mit atmel studio die fuse bits auslesen kan...
Angehängte Dateien:
-
fuses.PNG
25 KB
Ich habe es gefunden in Bascom. Geht ziemlich bequem. Ich habe die Fuses beider Controller ausgelesen, sieht bis auf die Kalibrierung ziemlich ähnlich aus (Siehe Anhang). Links ist der Atmega8-8PU und Rechts der Atmega8-16PU. Was könnte es noch sein ...?
:
Bearbeitet durch User
Hm, mit dem internen RC-Oszi und RS-232 hatte ich immer Probleme. Hast Du mal probiert, das Display langsamer anzusteuern? Vielleicht kratzt Du da gerade so an den Limits und reißt sie mit dem -16. Hast Du einen zweiten -16 probiert? Möglicherweise ist der eine defekt. Stimmen die Pegel an den Signalleitungen zum Display? Hat das Display Strom?
War da nicht was mit Fälschungen, gerade beim ATMEGA8?
Das Timing habe ich verlangsamt. Bringt leider auch kein Erfolg. Das ist leider mein einziger 16er. Dann werde ich das ganze mal als Fälschung verbuchen. Habe gestern Abend bei eBay noch weitere atmega8-8 geschossen. Müssten bis Übermorgen kommen! Dann probiere ich es mal mit denen aus! Auf jeden Fall Danke euch allen für eure Unterstützung!
Beitrag #6854186 wurde vom Autor gelöscht.
Asdf schrieb: > Dann werde ich das ganze mal als Fälschung > verbuchen. Das ist natürlich die naheliegendste Erklärung. Direkt danach käme noch ein Compilerfehler. Weit abgeschlagen sind Programmierfehler, und Fehler im Hardwareaufbau. Sowas ist gerade bei Anfängern ja äusserst unwahrscheinlich. Oliver
Gute, belastungsfähige Stromversorgung mit welcher Spannung?
Asdf A. schrieb: > klappt hervorragend mit dem Atmega8-8PU. Den gibt es nicht. Es gibt nur den Atmega8L-8PU. Und den Nachfolger Atmega8A-PU.
Asdf A. schrieb: > Sobald ich den Code auf den > Atmega8-16PU flashe geht es nicht mehr. Und was ist die Fehlerbeschreibung?
Rüdiger schrieb: > Gute, belastungsfähige Stromversorgung mit welcher Spannung? Gerade die Spannung wäre mal einer Messung würdig weil dort der größte Unterschied liegt: - ATmega8L-8PU 2.7 - 5.5V, 8MHz - ATmega8-16PU 4.5 - 5.5V, 16MHz
Irgend W. schrieb: > Gerade die Spannung wäre mal einer Messung würdig weil dort der größte > Unterschied liegt: > - ATmega8L-8PU 2.7 - 5.5V, 8MHz > - ATmega8-16PU 4.5 - 5.5V, 16MHz Asdf A. schrieb: > $crystal = 1000000 'Resonatorfrequenz ?????
Ich messe eine Spannung von 4,7 Volt am Controller. Spannungsversorgung kommt über Computer USB Port. Fehlerbild ist: Keine Leuchtenden Segmente auf der Anzeige :-) Sie haben recht es handelt sich um den Atmega8L-8PU. @Oliver S.: Ein Hinweis für die Fälschung könnte natürlich auch das Logo von Atmel auf dem Chip sein. Es ist nicht das richtige Logo (andere Schriftart) und auch nur sehr blass eingebrannt. Aber Sie dürfen sich jetzt heute morgen wie ein richtiger "Profi" fühlen, der einem Anfänger mit hilfreichen Hinweisen geholfen hat. Hut ab.
Irgend W. schrieb: > Gerade die Spannung wäre mal einer Messung würdig weil dort der größte > Unterschied liegt: > - ATmega8L-8PU 2.7 - 5.5V, 8MHz > - ATmega8-16PU 4.5 - 5.5V, 16MHz Asdf A. schrieb: > $crystal = 1000000 'Resonatorfrequenz ????? Ist das nicht richtig???? interner 1 MHz RC Oszillator?
:
Bearbeitet durch User
Asdf A. schrieb: > Fehlerbild ist: Keine Leuchtenden Segmente auf der Anzeige :-) Das klingt nach einem gern gemachten Fehler beim SPI: Der Pin /SS ist nicht als Ausgang definiert und floatet lustig vor sich hin. Oder wird erst nach dem SPI initialisiert. Daher kann es bei einem Exemplar klappen, bei einem anderen nicht.
Asdf A. schrieb: > Ist das nicht richtig???? > interner 1 MHz RC Oszillator? Wenn man weiß, dass der interne Oszillator kein Resonator ist, fällt einem schon eine Diskrepanz auf. Nicht jedem, aber so manch einem.
Peter D. schrieb: > Der Pin /SS ist nicht als Ausgang definiert und floatet lustig vor sich > hin. Ja, der Fehler wird gerne gemacht und taucht dann auch gerne mit Verspätung auf. Verzweifelte Seelen.... Aber hier, da sehe ich nix von SPI. Daraus folgt: Ohne SPI: Nix der Fehler.
Ahso, die Kommentare sind auch copy paste Überbleibsel :-) deswegen resonatorfrequenz ... Der Segment IC hat kein echtes SPI. Die Tatsache, dass es mit einem Controller läuft aber mit einem anderen (fast gleichen) nicht, ist sehr merkwürdig. Ich hänge da mal einen Logicanalyzer/Speicherscope dran und schaue mal genauer was da so abläuft...
Interrupt-Tabelle? Am Ende sind es die CASE, die den Atmega16 mittels rjmp intern nicht so weit springen lassen, bzw. die oberen 8K nicht adressieren kann, weils im Code blöd liegt. Sowas in der Art. Fake ist es mit Sicherheit nicht.
Asdf schrieb: > Dann werde ich das ganze mal als Fälschung verbuchen. Das ghet aber arg schnell... Hast du auch mal ein simples Blinkprogramm getestet und kontrolliert, ob die Blinkerei zeitlich passt? Oder hast du nur den ganz großen Koffer mit Allem auf einmal getestet? Denn schon, dass die serielle Schnitte läuft ist viel mehr Aufwand, als nur einen Portpin zu schalten. Asdf schrieb: > Ahso, die Kommentare sind auch copy paste Überbleibsel Lieber gar keine Kommentare als Falsche. Asdf schrieb: > Die Tatsache, dass es mit einem Controller läuft aber mit einem anderen > (fast gleichen) nicht, ist sehr merkwürdig. Vielleicht hätte es gereicht, einfach einen anderen, sogar "gleichen" Controller da reinzustecken...
> den Atmega16 mittels rjmp
?-?
Es geht um den ATmega8.
Asdf A. schrieb: > Sobald ich den Code auf den > Atmega8-16PU flashe geht es nicht mehr. > … > Hier der Code: > $regfile = "m8def.dat" > $framesize = 32 > $swstack = 32 > $hwstack = 64 Und das flashst du genau so auf den Mega16? Oliver
@Axl: ich weiß nicht ganz ob ich verstanden habe was du meinst. Es geht
also um diesen Codeblock:
Select Case Asc(strdisp , Bcounter)
Case "0" : Tm1637_wrbyte &B00111111
Case "1" : Tm1637_wrbyte &B00000110
Case "2" : Tm1637_wrbyte &B01011011
Case "3" : Tm1637_wrbyte &B01001111
Case "4" : Tm1637_wrbyte &B01100110
Case "5" : Tm1637_wrbyte &B01101101
Case "6" : Tm1637_wrbyte &B01111101
Case "7" : Tm1637_wrbyte &B00000111
Case "8" : Tm1637_wrbyte &B01111111
Case "9" : Tm1637_wrbyte &B01101111
Case Else : Tm1637_wrbyte &B00000000
End Select
warum sollte hier ein Problem mit den Sprüngen vorliegen??? Ich habe
leider keinen Debugger (soweit ich weiss braucht man einen für atmel
controller).
Warum sollte das selbe compilat auf dem atmega8l-8pu laufen aber nicht
auf dem 16pu. beide haben doch den selben speicher????
Kann man sich in bascom den disassamblierten code anzeigen lassen?
>Das ghet aber arg schnell...
>Hast du auch mal ein simples Blinkprogramm getestet und kontrolliert, ob
>die Blinkerei zeitlich passt?
>Oder hast du nur den ganz großen Koffer mit Allem auf einmal getestet?
>Denn schon, dass die serielle Schnitte läuft ist viel mehr Aufwand, als
>nur einen Portpin zu schalten.
ich habe leider noch kein kleines blinkprogramm getestet. um so
merkwürdiger ist es, dass die serielle schnittstelle läuft der rest aber
nicht!
>Vielleicht hätte es gereicht, einfach einen anderen, sogar "gleichen"
>Controller da reinzustecken...
das ist die naheliegenste entscheidung. Ich brauch für mein Projekt
(Arithmetik- und Logikeinheit) drei binär-zu-dezimal-decoder. Hatte aber
nur diese drei atmega8 controller rumliegen. deswegen habe ich gestern
auch einfach 10 neue atmega8 bestellt :-)
Oliver S.: Dafür das du so gut austeilst, hast du echt schwierigkeiten mit dem lesen: Es geht um den Atmega8! nicht den Atmega16. $regfile = "m8def.dat" passt also für beide Atmega8 Varianten!
Sowas wie Interrupts würde ich ausschließen. Das ist ein Compilerprogramm, damit ist es die Aufgabe des Compilers, daß der sowas crashfrei hinbekommt. Bei Assembler sähe das anders aus.
> Sowas wie Interrupts ...
Das war ohnehin nur der Irrtum von zwei 'Überfliegern'.
Ich würde erstmal testen, ob der MC defekt oder gefälscht ist. Dazu ein Lauflicht programmieren, was nacheinander alle Portpins einschaltet und das mit LEDs (+Vorwiderstand) kontrollieren. Wenn alle Pins als Ausgang funktionieren, sollte auch das Bit-Banging-SPI gehen. Debugging heißt nicht, ratlos vor dem gesamten Klotz zu sitzen, sondern das Programm in einzelne Schritte zu zerlegen, und die dann jeder für sich zu überprüfen. Man kann z.B. das SPI mit 3 LEDs und 1s-Delays oder ner entprellten Taste einzeln durchsteppen.
Das ist ein guter Ansatz Peter. So werde ich es machen!
Thread beobachten
Seitenaufteilung abschaltenBitte 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.