Hallo :-)
Ich hoffe es ist jemand hier, der sich mit Assembler auskennt. Das ist
der Codeschnippsel:
ldi r16, 1<<PCIE ;Pin Change Interrupts on/Int0|Int1 off
out GIMSK, r16
Recht einfach, aber will nicht klappen. Im Simulator (AVR Studio 6.1)
wird mir der Wert falsch angezeigt. PCIE ist das 5.Bit in GIMSK, sprich
es hat einen Dezimalwert von 32. Im Simulator steht aber nach dem Laden
der Wert "8" im Register, statt 32. Das ist theoretisch nicht moeglich,
da nur die Bits 7-5 beschrei(b)bar sind :-) Der Rest ist ohne Funktion.
Bug im Simulator?
Schau doch mal im Disassembler nach, welchen Wert ,(1<<PCIE) ergibt und
in welche Registeradresse der geschrieben wird. Die kannst Du ja dann
mal im Datenblatt vergleichen.
Mit meinem AvrStudio 4.19 funktioniert der Befehl einwandfrei. 2313 oder
auch 2313A (sollte eigentlich keine Unterschied sein)
Lingus schrieb:> Target ist ein Attiny2313>> Ich hab bereits alle moeglichen Ladebefehle durchprobiert, immer das> gleiche Ergebnis.
warscheinlich verwendest du nicht die richtige include Datei
tn2313def.inc vom Attiny2313, sondern die vom 90at2313 2313def.inc.
es ist immer besser, wenn man etwas mehr von seinem Programm preis gibt,
als nur eine vermeindlich falsche Zeile.
Hi
>warscheinlich verwendest du nicht die richtige include Datei>tn2313def.inc vom Attiny2313, sondern die vom 90at2313 2313def.inc.
Dann müsste der Assembler über 'ldi r16, 1<<PCIE' stolpern, denn der
AT90S2313 kennt kein PCIE.
MfG Spess
Headerdatei ist korrekt, das war das erste, was ich geprueft habe. PCIE
ist dort mit 5 definiert. Register R16 laed auch korrekt.
Hab gestern mal rumgetestet und GIMSK mit 255 geladen, dann die Bits
einzeln genullt. Und es hat sich herausgestellt, dass der Simulator
Bit.5 markiert, wenn ich ich ihm den Wert 16 schicke, sprich Bit.4. Aber
anzeigen tut er 32, obwohl er 16 bekommen hat. Das sieht mir doch nach
nem Bug im Simulator aus...
Lingus schrieb:> Das sieht mir doch nach nem Bug im Simulator aus...
Auf keinem Fall schreiben, welchen Simulator du verwendest. Du verdirbst
damit den Leuten nur den Spaß, dir die Würmer aus der Nase zu ziehen.
P. S. Ich weiß wo dein Problem liegt.
Hi
>Auf keinem Fall schreiben, welchen Simulator du verwendest. Du verdirbst>damit den Leuten nur den Spaß, dir die Würmer aus der Nase zu ziehen.
Das ATMEL Studio 6.1 hat nur einen Simulator für Assembler.
@ Lingus (Gast)
Für Assembler lohnt sich das 6er Studio nicht. Viel zu aufgeblasen. Mit
dem AVR Studio 4.19 bist du besser bedient.
Bekommst du hier:
http://www.atmel.com/tools/studioarchive.aspx
MfG Spess
Davis schrieb:> Auf keinem Fall schreiben, welchen Simulator du verwendest. Du verdirbst> damit den Leuten nur den Spaß, dir die Würmer aus der Nase zu ziehen.>> P. S. Ich weiß wo dein Problem liegt.
Wer lesen kann ist klar im Vorteil, oben im ersten Beitrag steht, dass
ich AVR Studio 6.1 benutze und das hat nur einen einzigen Simulator.
Wenn Du weisst, wo das Problem liegt, warum schreibst Du es dann nicht?
>Für Assembler lohnt sich das 6er Studio nicht. Viel zu aufgeblasen. Mit>dem AVR Studio 4.19 bist du besser bedient.
Studio 4 hab ich auf meinem Laptop. Allerdings gefaellt mir die 6.1
besser, auch wenn sie in vielen Dingen aufgeblasen ist, das ist wahr.
Auch die staendigen Konflikte mit Microsofts Visual 2010 nerven.
hallo,
so ich habs mal für mich ausprobiert mit deinem code und ja auch bei mir
tritt das phönomen auf das anstatt $20=PCIE in refister gesetzt und $08
in das GIMSK geschrieben wird auch beim tiny2313A.
Wenn man das ding händisch setzt passiert nix ausser das die INT0/1
keine flags setzen und wenn man denn den PCIE setzt und dazu den
entsprechenden pin setzt wird auch das flag gesetzt zum anspringen der
ISR aber nop kein sprung in die ISR.
könnts vielleicht nen BUG sein in der 6er??
habs auch mit der 4.19er versucht passt soweit man sollte das I-Bit noch
setzen UND dann gehts los UDRIE=1 fährt dir dein prgramm zu, weil
(>>>>31<<<<<<<TXEN) gesetzt wird.
ldi r16, (31<<TXEN) ;USART Rx, Tx, all Interrupts activated
out UCSRB,r16
fix ausgebessert und in der 4.19er PIN0/1/4 durchgetestet und die ISR
wird angesprungen.
Versuche mal statt Bit.5 fuer PCIE Bit.4 (ohne Belegung) zu setzen und
kuck was passiert.
>UDRIE=1 fährt dir dein prgramm zu, weil (>>>>31<<<<<<<TXEN) gesetzt wird.
Was meinst Du damit?
na der int wird immer ausgelöst weil UDR empty als Interrupt freigegeben
war und solange das UDRE leer ist löst das ding halt aus und dein
programm ist immer nur mit der ISR beschäftigt, kann natürlich sein das
du es brauchst aber das kann man aus deinem programm so nicht eindeutig
erkennen.
>>UDRIE=1 fährt dir dein prgramm zu, weil (>>>>31<<<<<<<TXEN) gesetzt wird.>Was meinst Du damit?
entweder
ldi r16,(1<<RXCIE|1<<TXCIE|0<<UDREI|1<<TXEN|1<<RXEN.....)
out UCSRB,r16
wegen der übersichtlichkeit
bei dir steht jedoch
ldi r16,(31<<TXEN) ;hier ist die 31
out UCSRB,r16
siehe post von Autor: Lingus (Gast) Datum: 25.11.2013 13:05
wenn du allerdings die 31 absichtlich gesetzt hast denn ok hat mich nur
erschrocken weil wie oben beschrieben das ding andauernd aufgerufen wird
in der simulation und ich zumindest nur beim simulieren keinen weiteren
zusammenhang erkennen konnte.
ok denn hab i nix gesagt.
aber funktioniert nun dein programm so wie du es dir vorgestellt hast??
ach und ja $10 ins reg laden und auf das GIMSK geben hat den
entsprechenden effekt das PCIE=1 wird ich gahe mal von nen bug aus.
Lingus schrieb:> Hier der Quelltext:
Es ist schlicht und einfach Simulatormurks im Studio 6.1, denn lädt man
das von 6.1 erzeugte Hex in Studio 4 und simuliert dort, verhält es sich
so wie vorgesehen: PCIE wird gesetzt. Der compilierte Code ist also
lauffähig, die Simulation scheitert dagegen.
Lingus schrieb:> Na wenigstens eine gute Nachricht. Das waere ja mal ne Fehlersuche, wenn> der Code korrekt ist aber der Compiler ne Macke hat
Nicht der Compiler. Der Simulator.
Ja, das meine ich ja. Gottseidank das nur der Simulator. Muss wohl doch
auf Studio 4 ausweichen. Ohne Simulator werd ich fuer mein Projekt
viermal soviel Zeit brauchen und der PCINT ist einer der wichtigsten
Bestandteile dabei. So ein Mist, Armutszeugnis fuer Atmel
Hab den Bug gestern Abend noch an Atmel geschickt, hier nochmal rein
informativ die Antwort dazu von heute:
2013-11-25 21:04:25 CET
Dear sir and madam,
there is a bug in the simulator for AVR-Assembler. I've tried to
simulate the
commands:
ldi r16, (1<<PCIE)
out GIMSK, r16
PCIE is the 5. Bit in GIMSK, the result should be 0x20 in the register.
But the
result is 0x08. If you now set Bit.4 in GIMSK, which has no function,
GIMSK
shows 0x20 (should be 0x10) and PCIE is activated in simulation.
Target device is Attiny2313, I'm using Atmel Studio 6.1 Service Pack 2
I have posted this bug to some friends, they have tested it too with the
same
result.
------------------------------------------------------------------------
---
[reply] [-] Comment 1 Morten Engelhardt Olsen 2013-11-26 07:37:04 CET
This looks like a simulator issue. Bug AVRSIM-294 reported to the
simulator
team.
[reply] [-] Comment 2 Morten Engelhardt Olsen 2013-11-26 09:05:27 CET
This was a confusing one, but here is the long an detailed explanation:
tiny2313 is a reduced tiny4313. tiny4313 has 3 PCIE-bits located at
GIMSK[5:3].
One would normally think that the three bits were placed as follows:
bit5 = pcie2, bit4 = pcie1, bit3 = pcie0
Which is why we mapped pcie[2:0] to GIMSK[5:3].
It turns out that the bits are placed as follows:
bit5 = pcie0, bit4 = pcie2, bit3 = pcie1
This means that since tiny2313 only has pcie0 this has ended up at bit3
of
GIMSK in the simulator model, rather than bit5.
Keep in mind that this only affects how the bit is presented in the
IO-view in
Atmel Studio. It will look a bit odd, but the device will behave as it
is
supposed to.
