Hier ist ein seltsames Phänomen: Ich habe mich evtl. in des Fuses
vertan, beim programmieren mit AVRdude zeigt er
1
avrdude: safemode: Fuses OK (E:05, H:DF, L:FF)
Ich kann auch mein Mini-Bascom-Testprogramm flashen, aber es
funktioniert nicht - habe es schom bis auf das Problem verkeinert - es
ist fast als ober er irgendwo im Programm rumschreibt??:
Programm:
1
$regfile = "m328pdef.dat"
2
$crystal = 16000000
3
$baud = 115200
4
5
Dim s as byte
6
Dim t as byte
7
8
print "start"
9
t = 1
10
s = 1
11
print "t=" ; t
12
if t = 0 then print "t0" else print "t1"
13
print "s=" ; s
14
if s = 0 then print "s0" else print "s1"
15
16
end
Ausgabe:
1
start
2
t=1
3
t0
4
s=49
5
s1
Wieso ist t = 0 und S 0 49?? Hat es evtl. mit dem Bootsektor zu tun?
(den benutze ich nicht, ich programmiere ja mit ISP..)??
bascommer schrieb:
(...)
> t = 1
(...)
> if t = 0 then print "t0" else print "t1"
(...)
Ich kenne diese Sprache zwar nicht, aber es kommt mir merkwürdig vor,
dass die Zuweisung den selben Operator besitzt wie der Vergleich.
Grüßle,
Volker.
bascommer schrieb:> Wieso ist t = 0 und S 0 49?? Hat es evtl. mit dem Bootsektor zu tun?> (den benutze ich nicht, ich programmiere ja mit ISP..)??
Beim MEGA2560 (Arduino MEGA R3 Board) hatte ich auch das Problem und mir
einen Merker gesetzt:
' ACHTUNG! bei neuem Board erst Resetadresse auf Null setzten !!!!!
Kurt
Volker B. schrieb:> Ich kenne diese Sprache zwar nicht, aber es kommt mir merkwürdig vor,> dass die Zuweisung den selben Operator besitzt wie der Vergleich.
So what? In anderen Sprachen gibt es viel schlimmere Verirrungen bei der
Mehrfachnutzung von Operatoren. Z.B. sobald die Dinger überladbar werden
und jeder hergelaufene Vollidiot meint, für seinen Datentyp ganz
unbedingt einen Standard-Operator überladen zu müssen, ob es nun einen
Sinn ergibt oder nicht, oder einfach nur, weil man es kann...
Letztlich gilt: Operatoren sind immer in dem Kontext zu betrachten, in
dem sie verwendet werden, um die tatsächlich ausgeführte Operation zu
ermitteln. Ende der Ansage.
Bei Basic und dem "=" ist das vergleichsweise wirklich noch sehr einfach
zu beherrschen...
bascommer schrieb:> Ah super - es geht mir nicht alleine so!>> welche Einstellung meinst Du? (ich benutze diese Seite:> http://www.engbedded.com/fusecalc/ )
Ich nehm den STK500 Ersatz zum reinschreiben.
Für den 328P hab ichs wohl so gesetzt: Fuses: FF FF DA FD
Probiers mal, wenns nicht geht dann such ich die HW raus damit ich
reinschauen kann.
Kurt
Kurt B. schrieb:> stacks schrieb:>> Wie sind denn die anderen Einstellungen für framesize, swstack, hwstack?>> Um die braucht man sich normalerweise beim Bascom nicht zu kümmern.
Ich möchte mich daber ausnahmsweise drum kümmern. Kurt, die Frage ging
an den TE, war keine Aussage und braucht nicht falsch von dir
kommentiert zu werden.
stacks schrieb:> Wie sind denn die anderen Einstellungen für framesize, swstack, hwstack?
ich hab mal testweise je 64 gesetzt, war aber kein Unterschied.
Kurt B. schrieb:> Für den 328P hab ichs wohl so gesetzt: Fuses: FF FF DA FD
Ok ich tese morgen mal, welche 3 Bytes von den vieren sind e, h und l?
Rätselhafte Sache - ich dache immer; Selbst wenn der bootloader nicht
richtig konfiguriert ist und ich flashe drin rum - ist doch eigentlich
egal, wenn ich ihn nicht benutze? und das Programm läuft ja wohl an der
richtigen Stelle los, sonst bekäme ich ja meine Ausgaben nicht..
bascommer schrieb:> Hier ist ein seltsames Phänomen: Ich habe mich evtl. in des Fuses> vertan, beim programmieren mit AVRdude zeigt er>> Programm:>
1
$regfile = "m328pdef.dat"
2
> $crystal = 16000000
3
> $baud = 115200
4
>
5
> Dim s as byte
6
> Dim t as byte
7
>
8
> print "start"
9
> t = 1
10
> s = 1
11
> print "t=" ; t
12
> if t = 0 then print "t0" else print "t1"
13
> print "s=" ; s
14
> if s = 0 then print "s0" else print "s1"
15
>
16
> end
17
>
>> Ausgabe:>
1
> start
2
> t=1
3
> t0
4
> s=49
5
> s1
6
>
>> Wieso ist t = 0 und S 0 49?? Hat es evtl. mit dem Bootsektor zu tun?> (den benutze ich nicht, ich programmiere ja mit ISP..)??
Es ist ein neuer Tag und ich sehe dass deine Ausgabe ja läuft, also kann
es an den Fuses ja nicht liegen.
Deine 49 sind wohl der ASCII-Wert der Zahl 1.
Schreib dein Programm mal Zeile für Zeile und setze ein endif hinter
jeder If Abfrage.
if ...
else ...
endif
(Ich hab hier grad keinen AVR sonst würd ich es schnell hineintippeln)
Kurt
Kurt B. schrieb im Beitrag #4617972
> Schreib dein Programm mal Zeile für Zeile und setze ein endif hinter> jeder If Abfrage.>> if ...>> else ...>> endif>> (Ich hab hier grad keinen AVR sonst würd ich es schnell hineintippeln)>> Kurt
Das ändert nichts. Im Simulator funktioniert auch alles. Vielleicht ist
wirklich der Chip kaputt..?
bascommer schrieb:> Kurt B. schrieb im Beitrag #4617972>> Schreib dein Programm mal Zeile für Zeile und setze ein endif hinter>> jeder If Abfrage.>>>> if ...>>>> else ...>>>> endif>>>> (Ich hab hier grad keinen AVR sonst würd ich es schnell hineintippeln)>>>> Kurt>> Das ändert nichts. Im Simulator funktioniert auch alles. Vielleicht ist> wirklich der Chip kaputt..?
Was wäre schon ein seltsamer Fehler.
Mach mal eine Schleife drum und lass mehrmals ausgeben, wobei du die
Variablen jeweils um 1 erhöhst.
Ev. will er ein END (Programm) sehen.
Kurt
Hallo bascommer,
dein “Mini-Bascom-Testprogramm” ist wohl nicht besonders geeignet um
gleich einen Fehler im Fuse oder sogar µC defekt zu vermuten.
Versuche es mal so:
$regfile = "m328pdef.dat"
$crystal = 16000000
$baud = 9600
Dim s as byte
print "start"
For s =1 To 10
print "s= " ; s
Waitms 100
Next
Deine IF- Abfrage macht wohl nun wirklich keinen Sinn.
Sicher ist immer auch gleich ein HW-Test mit dem Standarthinweis “LED
blinken lassen“.
Mit freundlichen Grüßen
Hallo Kurt,
stacks schrieb:> Wie sind denn die anderen Einstellungen für framesize, swstack, hwstack?
Zitat:
Um die braucht man sich normalerweise beim Bascom nicht zu kümmern.
Zitat ende:
Aber nur bei diesem Code-Schnipsel.BASCOM hat eine minimale
Grundeinstellung für Stack (Rücksprung Adresse für Sub usw. merken)
Diese Speicherplatz Reservierung sollte immer optimal sein. Ist er zu
groß gewählt verschenkt man Speicher. Ist er zu klein können im
Programmablauf schon mal irre Aktionen auftreten.
Somit bitte ich auch immer wieder, wenn ich helfen kann, die Stack-
Einstellungen in Header festzulegen.
z.B.
$regfile = "m328pdef.dat"
$crystal = 16000000
$baud = 19200
$hwstack = 30
$swstack = 40
$framesize = 40
Grüß, Fred
Fred R. schrieb:> Diese Speicherplatz Reservierung sollte immer optimal sein. Ist er zu> groß gewählt verschenkt man Speicher. Ist er zu klein können im> Programmablauf schon mal irre Aktionen auftreten.>> Somit bitte ich auch immer wieder, wenn ich helfen kann, die Stack-> Einstellungen in Header festzulegen.
Ja, gerade bei diesem Programm sollte man besonders aufpassen.
Habs gerade probiert, ohne diese Einstellungen im Header wird von
Bascom fur HW-Stack 40Bytes, fur SW-Stack 16Bytes und fur Frame
32Bytes reserviert.
Das ist mehr als genug.
Und somit ist:
Kurt B. schrieb:> Um die braucht man sich normalerweise beim Bascom nicht zu kümmern.
vollkommen richtig, was wolltest du eigentlich sagen ?
Marc V. schrieb:> Habs gerade probiert, ohne diese Einstellungen im Header wird von> Bascom fur HW-Stack 40Bytes, fur SW-Stack 16Bytes und fur Frame> 32Bytes reserviert.> Das ist mehr als genug.>> Und somit ist:> Kurt B. schrieb:>> Um die braucht man sich normalerweise beim Bascom nicht zu kümmern.>> vollkommen richtig, was wolltest du eigentlich sagen ?
Bleibt noch "normalerweise" zu definieren. Ein Fehlerfall ist nicht mehr
normal und die Werte können in der IDE voreingestellt bzw. verstellt
werden. Es ist deshalb ratsam sie immer im Programm mit anzugeben.
bascommer schrieb:> Hier ist ein seltsames Phänomen: Ich habe mich evtl. in des Fuses>> Ausgabe:>
1
> start
2
> t=1
3
> t0
4
> s=49
5
> s1
6
>
>
Diese 49 schauen nach: s = "1" aus.
Ist da ev. irgendwo noch ein alter Programmteil im AVR vorhanden den er
durchrennt ohne das man das mitkriegt?
(Speicherversatz wegen ehemaligem seriellem Laden)
Lösche mal den Chip vor der Neuprogrammierung.
Kurt
Marc V. schrieb:> vollkommen richtig, was wolltest du eigentlich sagen ?
Wie beschrieben. Sagte ich schon.
Kurt B. schrieb:> Lösche mal den Chip vor der Neuprogrammierung.
Diesen Vorschlag kann ich nicht nachvollziehen.
Flash- Speicher wird von 0 bis x überschrieben. Ist schnurz egal was
vorab geflasht wurde.
Nur die Voreingestellen Header (Abhängig vom Fuse sind relevant)
Zum wiederholten mal ein Beispiel.
Fuse auf externen Takt eingestellt. Dies merkt sich der MC. Nun ist aber
kein Taktgeber angeschlossen(Quarz) was nun?
Nachträglich einen anschließen ist möglich aber MC kann log. diesen
nicht erkennen.
Nur dann Hilft es den MC mit min Takt auf Neutral zurück zu setzen. Wenn
überhaupt möglich.
Einige Fuse- Einstellungen sind eine Sicherung, wie das Schoss deiner
Haustür, ist Schüssel verloren, wird es dumm.
Schlussfolgerung:
Wer mit Fuse unüberlegt „spielt“ hat oft die Arschkarte gezogen.
MfG
Kurt B. schrieb:> Mach mal eine Schleife drum und lass mehrmals ausgeben, wobei du die> Variablen jeweils um 1 erhöhst.
Warum? Ich hab doch ein Beispiel, das reproduzierbar nicht funktioniert
- es würde mir mehr helfen, wenn es jemand auf einem Mega328p testet
(z.B. Arduino 3?)
Fred R. schrieb:> Marc V. schrieb:>> vollkommen richtig, was wolltest du eigentlich sagen ?>> Wie beschrieben. Sagte ich schon.>> Kurt B. schrieb:>> Lösche mal den Chip vor der Neuprogrammierung.>> Diesen Vorschlag kann ich nicht nachvollziehen.> Flash- Speicher wird von 0 bis x überschrieben. Ist schnurz egal was> vorab geflasht wurde.
Naja, ich weiss ja nicht ob das bei seinem Proger wirklich so ist oder
ob der Flash mehrere Bereiche hat und nur die gelöscht werden die das
Programm dann wirklich braucht.
Schaum was die Schleife bringt und der damit verbundene
Programmabschluss/Programmende.
Kurt
bascommer schrieb:> Kurt B. schrieb:>> Mach mal eine Schleife drum und lass mehrmals ausgeben, wobei du die>> Variablen jeweils um 1 erhöhst.>> Warum? Ich hab doch ein Beispiel, das reproduzierbar nicht funktioniert> - es würde mir mehr helfen, wenn es jemand auf einem Mega328p testet> (z.B. Arduino 3?)
Wenn du eine Schleife drumrum machst dann hast du mehrere Ausgaben und
kannst sehen ob die sich gleichartig verhalten oder der Fehler nur
einmal auftaucht.
Setz mal deine Ausgabegeschwindigkeit auf 1200 oder 9600.
Kurt
Habs nachgestellt
-------------------------------
$regfile = "m328pdef.dat"
$crystal = 16000000
$baud = 115200
Dim s as byte
Dim t as byte
print "start"
t = 1
s = 1
print "t=" ; t
if t = 0 then print "t0" else print "t1"
print "s=" ; s
if s = 0 then print "s0" else print "s1"
end
----------------------------------
Ausgabe:
------------------
start
t=1
t1
s=1
s1
start
t=1
t1
s=1
s1
------------------
Bei 1200 Baud kommt das raus:
---------
start
t=1
t1
s=1
s1
----------
Welchen Compiler hast du, ich habs mit 2.071 kompiliert
Kurt
Danke Kurt fürs testen! So sollte es sein.. dann ist wohl doch der Chip
hin.. Wenn es ein m328p war, poste doch mal das .hex-file, dann ist auch
der Compiler als Fehlerquelle ausgeschlossen
bascommer schrieb:> Danke Kurt fürs testen! So sollte es sein.. dann ist wohl doch der Chip> hin.. Wenn es ein m328p war, poste doch mal das .hex-file, dann ist auch> der Compiler als Fehlerquelle ausgeschlossen
Der Chip wird's wohl nicht sein.
Ev. sind die 115200 und die 16 MHz nicht passend.
Ich tippe auf den Compiler.
Kurt
mit der .hex-Datei funktioniert es.. na sowas. Ich sollte evtl.
dazusagen, dass ich den compiler (bascomp.exe) mit wine unter ubuntu
aufrufe..
An der Baud-Rate liegt es übrigens nicht, ich habe das gleiche Problem
mit 1200 baud.
Kurt, kannst Du mal den Quelltext für o.g. .hex als Datei posten? evtl.
hab ich hier ein Thema mit unicode oder so... mir ist aufgefallen, dass
er immer eine Zeile Platz lässt, wenn ich den Text nach Bascom (Windows)
kopiere..
Dann kann ich einen Binärvergleich machen.
bascommer schrieb:> mit der .hex-Datei funktioniert es.. na sowas. Ich sollte evtl.> dazusagen, dass ich den compiler (bascomp.exe) mit wine unter ubuntu> aufrufe..>> An der Baud-Rate liegt es übrigens nicht, ich habe das gleiche Problem> mit 1200 baud.
Bei 1200 hab ich nur eine Ausgabe nach Reset bekommen, bei 115200 zwei
davon.
Der Grund ist mir auch nicht klar aber ich denke dass er ev. das nur mit
20 MHz oder so sauber hinbekommt.
>> Kurt, kannst Du mal den Quelltext für o.g. .hex als Datei posten? evtl.> hab ich hier ein Thema mit unicode oder so... mir ist aufgefallen, dass> er immer eine Zeile Platz lässt, wenn ich den Text nach Bascom (Windows)> kopiere..>> Dann kann ich einen Binärvergleich machen.
Natürlich.
Kurt
Kurt B. schrieb:> Bei 1200 hab ich nur eine Ausgabe nach Reset bekommen, bei 115200 zwei> davon.
Vielleicht hat auf Deiner Reset-Leitung etwas geprellt, und mit 115200
war er schnell genug schon vorher was rauszugeben.. Kannst ja mal
"waitms 500" als allererstes Statement schreiben, dann sollte das nicht
vorkommen.
Dann werd ich mal vergleichen..
bascommer schrieb:> Kurt B. schrieb:>> Bei 1200 hab ich nur eine Ausgabe nach Reset bekommen, bei 115200 zwei>> davon.>> Vielleicht hat auf Deiner Reset-Leitung etwas geprellt, und mit 115200> war er schnell genug schon vorher was rauszugeben.. Kannst ja mal> "waitms 500" als allererstes Statement schreiben, dann sollte das nicht> vorkommen.>> Dann werd ich mal vergleichen..
Das könnte sein, denn ich hab einfach die Spannung vom USB-Proger
angelegt, werds probieren.
Kurt
hmmm.. sieht sehr nach Compiler aus, bzw. evtl. hat er mit wine / Ubuntu
nicht die perfekte Arbeitsumgebung.
Quelltexte sind identisch und gleich codiert, Compilat unterscheidet
sich (am Anfang ca. 30% gleich)
Ich werd den Compiler mal in einer VM laufen lassen. Blöd sowas..
Kurt B. schrieb:>> Vielleicht hat auf Deiner Reset-Leitung etwas geprellt, und mit 115200>> war er schnell genug schon vorher was rauszugeben.. Kannst ja mal>> "waitms 500" als allererstes Statement schreiben, dann sollte das nicht>> vorkommen.>>>> Dann werd ich mal vergleichen..>> Das könnte sein, denn ich hab einfach die Spannung vom USB-Proger> angelegt, werds probieren.
Habs grad verglichen, es ist so wie du sagst.
Kurt
