Hallo zusammen.
Vorweg: Ich bin ziemlicher Anfänger, was das Programmieren mit Embedded
Systems angeht.
Ich habe meinen Atmega32 über I2C mit einem PCF8574 verbunden. Hinter
diesem sitzt eine Matrix Tastatur, die ich abfragen will. Ausgabe
erfolgt auf LC-Display
Hier erstmal ein kleiner auszug aus dem Code:
1
intmain(void)
2
{
3
lcd_init();
4
5
delay_s(1);
6
7
lcd_on();
8
9
twi_init(72);
10
11
12
while(1)
13
{
14
15
for(inti=0;i<4;i++)
16
}
17
twi_m_start(32,TW_WRITE);
18
twi_m_write(254<<i);
19
20
twi_m_start(32,TW_READ);
21
intj=twi_m_read();
22
23
switch(j)
24
{
25
case190:
26
lcdxy(0,1);
27
printf("1");
28
break;
29
30
case222:
31
lcdxy(0,1);
32
printf("2");
33
break;
34
35
case238:
36
lcdxy(0,1);
37
printf("3");
38
break;
39
40
case189:
41
lcdxy(0,1);
42
printf("4");
43
break;
44
45
case221:
46
lcdxy(0,1);
47
printf("5");
48
break;
49
50
case237:
51
lcdxy(0,1);
52
printf("6");
53
break;
54
55
case187:
56
lcdxy(0,1);
57
printf("7");
58
break;
59
60
case219:
61
lcdxy(0,1);
62
printf("8");
63
break;
64
65
case235:
66
lcdxy(0,1);
67
printf("9");
68
break;
69
}
70
}
71
}
Ich muss im Prinzip 4x abfragen bis ich alle Reihen der Matrix einmal
auf 0 gesetzt habe. Der Wert der bei tw_m_write() übergeben wird ist
int. Ich habe das Problem, wenn ich die 254(1111 1110) nach 1 links <<
shifte, er von rechts wieder mit Nullen auffüllt (1111 1100). Konnte ich
ja am PCF auch nachmessen. Ich möchte aber, dass es nach einem 254 << 1
so aussieht: (1111 1101). Jetzt meine Frage, wie kann ich das
realisieren? Wie lautet der Befehl dafür? Für Antworten wäre ich sehr
dankbar. Das, was ich suche, ist doch doch ein Rotate through Carry
oder?
Gruß Henning
Des ist kacke, weil du um ne Variable schiebst (i), der AVR sowas aber
nicht von Haus aus kann. Speicher lieber die 254 in ne Variable und
schieb in jedem Durchlauf um eins nach links.
ja der ROL steht für Rotate throug Carry. Nur habe ich im Stillen
gehofft, dass ich das Problem mit C lösen kann. Ich kenne mich mit
Assembler nicht wirklich gut aus. :)
Aber werd mir deine Links mal verinnerlichen. danke schonmal
@Sven pauli.
Die Variable i ist bei jeden Duchlauf eins größer und das klappt auch
einwandfrei so, habs nachgemessen mit einem Oszi. Nur die
Bitverschiebung ist keine zyklische, sondern eine arithmetische.
Henning Achter wrote:
> @Sven pauli.>> Die Variable i ist bei jeden Duchlauf eins größer und das klappt auch> einwandfrei so, habs nachgemessen mit einem Oszi. Nur die> Bitverschiebung ist keine zyklische, sondern eine arithmetische.
Du verstehst das falsch. Natürlich funktioniert das, aber schau dir mal
an, welchen riesen Code der Compiler draus macht.
Wenn du immer nur um 1 (eben um eine Konstante) schiebst, gibt das im
Code dann genau eine "lsl"-Instruktion. Wenn du um "i" schiebst, gibts
im Code ne Schleife, die "i"-Mal ausgeführt wird, und das ist total
ineffizient und in deinem Fall auch unnötig.
ok, das hast du natürlich recht. Darüber hab ich auch ehrlich gesagt
nicht nachgedacht. Ich wollte, dass es zumindest erstmal läuft und mich
dann um die Effienz kümmern. Habs aber nun geändert. danke :)
Außerdem sind die ganzen Dezimalzahlen sehr verwirrend, ich würde auf
Jeden Fall die I2C-Adresse 'rausziehen' ("#define PCF8574 0x20" o.ä.)
und die case's zumindest in hex darstellen (0xbe, 0xde, 0xee...) oder
sogar binär...
(und den "case default:" einbauen).
hth. Jörg
ich bin nochmal erstmal danke für die zahlreichen Antworten.
Habe es mal mit asm volatile versucht. hier mal der code nur als
Prinzip.
1
intmain(void)
2
{
3
lcd_init();
4
5
lcd_on();
6
7
unsignedinti=254;
8
9
printf("%i",i);
10
11
for(intj=0;j<3;j++)
12
{
13
delay_s(2);
14
15
dspclr();
16
17
asmvolatile("rol %0":"=r"(i));
18
19
printf("%i",i);
20
}
21
}
Als Ergebnis erhalte ich jedoch meiner Meinung nach immernoch eine
logische Bitverschiebung.
Beispiel 254 (1111 1110)
1. Shift 1111 1100 und nicht 1111 1101
2: Shift 1111 1000 und nicht 1111 1011
usw.
Stimmt da etwas mit der Syntax nicht in dem asm Befehl?
Danke im Voraus.
Gruß Henning
rol verschiebt den Wert im Register um eine Stelle nach links. Dabei
wird das, was grad (in diesem Fall wohl eher zufällig) im Carry-Flag
steht, von hinten in das Register reingeschoben und das MSB wird ins
Carry-Flag geschoben. Es ist sehr unwahrscheinlich, dass nach einem
printf-Aufruf im Carry für den nächsten Schiebevorgang noch der alte
Zustand steht...
Ich würde es ohne das Inline-Assembler-Zeugs machen. Das Carry-Flag kann
man in C auch abfragen. Ist ein recht gewöhnliches Bit im SREG.
> Stimmt da etwas mit der Syntax nicht in dem asm Befehl?
Nein, was nicht stimmt, ist dein Verständnis von "rotate through carry".
Was links raus fällt landet im Carry, und rechts wird nachgeschoben, was
vorher im Carry war.
könnte klappen. Wäre die einfachste und kürzeste Methode.
Aber besser ins Listing schauen, ob der Compiler nicht noch irgendeinen
Carry-Flag-beeinflussenden Befehl dareinschiebt.
Wenn Du auf Nummer sicher gehen willst, dann besser so:
> könnte klappen.
Streng genommen hast du keine Garantie, dass der Compiler das
so umsetzt wie du es erwartest. Der Compiler darf durchaus
(SREG & 1 ) berechnen noch ehe er Code für (variable << 1)
generiert.
Dann schiebst du wieder irgendein Bit hinein
Karl heinz Buchegger wrote:
> Streng genommen hast du keine Garantie, dass der Compiler das> so umsetzt wie du es erwartest. Der Compiler darf durchaus> (SREG & 1 ) berechnen noch ehe er Code für (variable << 1)> generiert.>> Dann schiebst du wieder irgendein Bit hinein
Das ist natürlich richtig. Also besser in zwei Schritten. Und in jedem
Fall ins .lss schauen, was der wirklich draus macht.
Karl heinz Buchegger wrote:
> Johannes M. wrote:>>
1
>>variable=(variable<<1)|(SREG&1);
2
>>
>> könnte klappen.>> Streng genommen hast du keine Garantie, dass der Compiler das> so umsetzt wie du es erwartest. Der Compiler darf durchaus> (SREG & 1 ) berechnen noch ehe er Code für (variable << 1)> generiert.>> Dann schiebst du wieder irgendein Bit hinein
In diesem Fall holt er zumindest vorher das SREG, klappt also nicht:
1
+00000074: B78F IN R24,0x3F In from I/O location
2
+00000075: 0F99 LSL R25 Logical Shift Left
3
+00000076: 7081 ANDI R24,0x01 Logical AND with immediate
Simon K. wrote:
> Wie bekommt man so ausführliche Assembler Listings mit dem AVR-GCC? ;)
Das stammt aus dem Disassembler-Fenster des AVR-Studio-Debuggers. ;-)
Stefan Ernst wrote:
> Das stammt aus dem Disassembler-Fenster des AVR-Studio-Debuggers. ;-)
Besonders ,,nützlich'' finde ich immer die letzte Spalte... Sie hätten
den Platz wirklich sinnvoller nutzen können, bspw. um für Adressen die
symbolischen Namen anzuzeigen (sofern bekannt) oder bei relativen
Sprüngen das Sprungziel auszurechnen. Wer nicht weiß, dass "ANDI"
ein "Logical AND with" ist, dem wird auch der Kommentar beim Lesen
kaum noch helfen.
Jörg Wunsch wrote:
> Besonders ,,nützlich'' finde ich immer die letzte Spalte...
Ja, ist reichlich überflüssig.
Aber das lss-File hat auch so seine Macken. Im konkreten Fall steht da:
1
e8: 8f b7 in r24, 0x3f ; 63
2
ea: 99 0f add r25, r25
3
ec: 81 70 andi r24, 0x01 ; 1
4
ee: 98 2b or r25, r24
Ich finde "lsl r25" lesbarer als "add r25,r25" (ist aber wohl
Geschmackssache).
Stefan Ernst wrote:
> Ich finde "lsl r25" lesbarer als "add r25,r25" (ist aber wohl> Geschmackssache).
Tja, das ist wohl das Dilemma eines Disassemblers, welchen von zwei
Mnemonics es sich für ein und denselben Opcode aussuchen darf...
Letztlich ist wohl das, was man gerade lesbarer findet, vom Kontext
abhängig.
