1 bit Wert PB2 direkt übernehmen (Assembler)

Weniger als ein Befehl?
Das dürfte sportlich werden.

Vielleicht könntest Du einen Tipp zum verwendeten Prozessor geben.

Meine Glaskugel ist nämlich immer noch in der Werkstatt.

Hallo,

sorry. Der µC ist Atmel Attiny 13A. Ich shifte das Datenbit, lese dann 
PB2 ein, setze das Bit (0/1), vergleiche, wieviele Schiebeoperationen 
ich hatte und breche bei 8 ab.

1. LSL data ; Datenbyte linkshift
2. SBIC PINB,2             ; Überspringe nächste, wenn PIN PB2 = 0
3. ORI data,0x01           ; wert setzen
4. INC counter             ; Counter erhöhen
5. CPI counter,8           ; Counter auf max-wert prüfen
6. BRNE                     ....etc..pp

Das ganze wollte ich gerne (Durchlaufzeit) etwas "Kompakter" haben !!!

Mathias

Hi
Eleganter? Keine Ahnung, aber was ist, wenn PINB nicht "1" ist? 
Vieleicht setzt du noch vor deine Anweisung ein
   ANDI data,0xFE
Sonst bleibt ein einmal gesetztes Bit für immer und ewig "1"
Aber mal eine Frage, wieso willst du bei ca. 3 Takten noch "eleganter" 
werden?
Gruß oldmax

Hallo,

wenn PB2 nicht 1 ist, ist er automatisch null (da shift vorher). Dann 
wird gezählt.

Routine dient zum seriellen einlesen. Mit jedem Shift rückt das 
datenbyte nach links, bis 8 "voll" sind. Ich wollte nur die Zählerei 
kürzer machen, hab aber noch keine idee !

Mathias

Wenn Du schon schiebst...
Ein paar Schiebebefehle schubsen das oberste/unterste Bit ins Carry-Bit.
Dieses kann als Sprungbedingung verwendet werden.

@Ralf

Geht!

...aber 1 x LSR  = 1 x DEC
        1 x LDI  = 1 x LDI (1/8)
        1 x BRCS = BREQ

als Schleifenbegrenzung also gleichwertig

Hallo,

gibt es einen "Trick" um den PB2 (und nur das Bit von PB2) direkt mit 
Data zu verknüpfen, ohne es vorher explizit in ein register einzulesen?

Mathias

@ Mathias

Soweit mir bekannt ist, hat der AVR keinen Befehl um unter Angabe einer 
Bitnummer, oder auch einer Bitmaske und einer Speicheradresse (oder auch 
eines Registers, dass eine Speicheradresse enthält) ein Bit an dieser 
Speicheradresse zu beeinflussen. 
http://www.atmel.com/images/Atmel-0856-AVR-Instruction-Set-Manual.pdf

Wenn das in data zu beeinflussende Bit an der selben Position sitzt, wie 
in Port, dann ist diese Befehlsfolge

1

ANDI data,(0xFF-0x04)

2

SBIC PINB,2

3

ORI data,0x04

die kürzeste die mir einfällt. (Wobei "data" ein Register ist).

Nebenbei:
Ich verstehe nicht, zu welchem Zweck Du diese Schiebeoperationen machst. 
Kannst Du das mal erklären, bitte?

Wenn PINB eher als dünn besetzt zu erwatzen ist, könntest du folgenden 
Ansatz in Betracht ziehen.

1

.DEF  tmp  = r16

2

.DEF  tmp2= r17

3

.DEF    data= r1

4

5

6

.CSEG

7

.ORG 0

8

startup:

9

  ldi    tmp,0xff

10

  out    portb,tmp

11

12

  in    tmp,pinb

13

loop:

14

  breq  end

15

  mov    tmp2,tmp

16

  neg    tmp2    ;mask rightmost 1

17

  and    tmp2,tmp

18

  eor    tmp,tmp2  ;clear bin in pinb

19

  rjmp  loop

20

end:

21

  rjmp end

Mit der Bitmaske kann, logo, auch was mit dem data-register gemacht 
werden

Ah. Moment. Willst Du eine "Folge von 8 Bits von PINB2" in "data" 
übernehmen?

Ein Port-Register zu verschieben ist nicht sinnvoll.

Außer dem SBI?-Befehl gibt es nicht viele Möglichkeiten.

... aber manche Programmierer haben, aus Geschwindigkeitsgründen ein 
Register welches konstant mit Null belegt ist.

also weit außerhalb Deiner Schleife gibt es dann einmalig
ein LDI Rx,0 oder wie auch immer Du löschst.

...
XOR Rz,Rz        ; Lösche Ergebnisregister  (1 Takt)
MOV Ry,PINB      ; Port lesen               (1 Takt)
LSR Ry           ; Abfragebit [1] nach [0]  (1 Takt)
LSR Ry           ; Abfragebit [0] nach [C]  (1 Takt)
ADC Rz,Rx        ; Rz = 0 oder 1 je nach B2 (1 Takt)

Lese gerade, dass es -nur- um PB2 geht. Dann ist es natürlich unnötig, 
sich um den ganzen PINB zu kümern...
Tschuldigung mein Fehler ich habe hier gar nicht mehr weitergelsen, ich 
hab mich etwas in avrasm eingelesen schnell, das ist Jahre her, dass ich 
damit gespielt habe.

Wie gesagt: sorry

@Bedienungsanleitungssucher (Gast)

2-Wire in Software, bei jedem Takt an PB1 lese ich PB2 ein, shifte bis 8 
bit voll->Flag setzen und verarbeiten!

Mathias

Mathias schrieb:
> @Bedienungsanleitungssucher (Gast)
>
> 2-Wire in Software, bei jedem Takt an PB1 lese ich PB2 ein, shifte bis 8
> bit voll->Flag setzen und verarbeiten!
>
> Mathias

Aha. Danke.

Und das ist tatsächlich ein Protokoll mit byteweisem Takt? Kenne ich 
gar nicht. Nun gut. Ich kenne nicht alles, was es gibt. Hast Du da mal 
einen Link auf die Protokollbeschreibung?

Ah jetzt habe ich es auch begriffen. War bischen Salami.
Aber du gibts doch gar keinen Takt aus. Wo spielt denn da der Takt?

An PB1 liegt die Taktleitung. Bei jedem Takt wird ein Bit (0/1) 
übernommen und weitergeschoben. Link zu Protokoll wird schwierig, da 
Eigenbau!

Mathias

Mathias schrieb:
> An PB1 liegt die Taktleitung. Bei jedem Takt wird ein Bit (0/1)
> übernommen und weitergeschoben. Link zu Protokoll wird schwierig, da
> Eigenbau!
>
> Mathias

Aha. Dankeschön.

Hmm. Naja. Auch bei selbst definierten Protokollen ist eine Beschreibung 
zweckmäßig, denke ich. Aber gut. Deine Sache. Im übrigen ist dann I2C 
das ähnlichste Protokoll.

Nur berücksichtigt der Code oben, wenn ich das richtig sehe, den Takt 
nicht. Weder die von den Antwortern (die das ja nicht wissen konnten) 
noch Dein eigener. Es wird einfach, so schnell wie möglich eingelesen 
und geschoben.

Eigentlich schmeckt Salami ganz gut.

Aber Informationen Scheibchenweise sind aber nicht der Wahre Mathias.

Amateur schrieb:

1

XOR Rz,Rz        ; Lösche Ergebnisregister  (1 Takt)

2

MOV Ry,PINB      ; Port lesen               (1 Takt)

3

LSR Ry           ; Abfragebit [1] nach [0]  (1 Takt)

4

LSR Ry           ; Abfragebit [0] nach [C]  (1 Takt)

5

ADC Rz,Rx        ; Rz = 0 oder 1 je nach B2 (1 Takt)

Abgesehen davon, dass es in statt mov heißen muss, fehlt da doch ein 
lsr Ry.

Ein paar Randbedingungen fehlen aber immer noch.
Ist, bezogen auf den Takt, das Datenbit während der ansteigenden Flanke 
gültig; während er high oder low ist; oder während der abfallenden 
Flanke?

Und was vielleicht nicht ganz unwichtig ist: Wie schnell Tickst Du?

Aber vielleicht fallen Dir ja noch ein paar Randbedingungen ein, die das 
alles umwerfen.

@S. Landolt

Stimmt, mein Editor hat aber nicht gemeckert;)

An der funktionierenden Lösung bastele ich zur Zeit noch.
Der Loop läuft durch, sobald über INT0 die Taktflanke erkannt wurde. 
Wenn 8 bit durch sind, setze ich ein Flag und arbeite das in der 
Hauptschleife ab.
Die Routine muß so schnell sein, um den AVR aus dem Sleep aufzuwecken, 
Bit speichern und wieder schlafen legen zu können !
Und ja, sobald das ganze bidirektional läuft, werde ich eine 
ausführliche Beschreibung machen !

Wie willst Du eigentlich den "Anfang" finden?

Eine kleine Störung reicht da schon aus.

Ich weiß, ich bin ein Spielverderber...

Amateur schrieb:
> Stimmt, mein Editor hat aber nicht gemeckert;)
Es reicht ja, wenn der Landolt meckert.

> Wie willst Du eigentlich den "Anfang" finden?
Und wie die Mitte des abzutastenden Bits?

> Ich weiß, ich bin ein Spielverderber...
Da sind wir schon zu zweit, das ist m.E. sehr schwer bis unmöglich.

Ich glaube zwar nicht, dass es weiterhilft, aber hier eine Lösung mit 
1+16 Takten:

1

.def   tmp = r16

2

 ldi   tmp,0

3

 sbic  PINB,2

4

  ori  tmp,(1<<7)

5

 sbic  PINB,2

6

  ori  tmp,(1<<6)

7

.

8

.

9

 sbic  PINB,2

10

  ori  tmp,(1<<0)

> sobald über INT0 die Taktflanke erkannt wurde
> Die Routine muß so schnell sein, um den AVR aus dem Sleep
> aufzuwecken, Bit speichern und wieder schlafen legen zu können!
Bit? Ich dachte Byte.

Das ist so direkt nur bei relativ langsamer Übertragung machbar. Wenn 
aber der Sender dem eigentlichen Byte einen Startimpuls im Abstand von 
etwa 10-15 Takten vorausschickt, dann sollte eine Übertragung mit 
f_CPU/4 machbar sein, vielleicht auch /3.

@Amateur: Takt ist 128KHz über WD-oszi
Datenbit ist während der ansteigenden Flanke des Taktsignals gültig
Sender schickt Taktsignal, um Empfänger zu wecken, Überträgt 3x8bit und 
geht in Empfang/Sleep

128 K ist ganz schön ziemlich.

Ich hoffe, dass Dein µP, zwischenzeitlich, in der Wachperiode, genügend 
Zeit hat sich die Daten auch anzusehen. Datenübertragung ist ja kein 
Selbstzweck.

Vor allem das erste Bit (Takt) hat's in sich.

Ausgehend von "S. Landolt"'s Sequenz brauchst Du, netto, 128K * 16 Takte 
zum Empfangen. Da bleibt kaum zum Speichern Zeit, geschweige etwas 
anderes zu machen.

Wow! ich wusste nicht, daß es schon so viele (und bessere) Ansätze 
gab.....

Wow!
Auch erscheinen mir die in Peters Artikel genannten 
Zeiten/Geschwindigkeiten viel realistischer.

Zum Protokoll:

Prinzipiell steuere ich den Empfänger an, wie ich ein Schieberegister 
ansteuere, die Idee ist entstanden, als ich eine 7seg ANzeige 
angesteuert habe, dachte ich mir: so könnte das auch von µC zu µC 
funktionieren.

Mathias

Hallo,

also der 128KHz Takt kommt, da der Tiny u.a. über einen 0.22F 
Kondensator betrieben wird. Mehr "Power" F_CPU kann ich nicht 
rausnehmen, sonst bin ich nach 30sek schon am Ende.

Supercap lädt auf - ab 1,6/1,8V springt der Tiny an.

Im Versuch läuft der Tiny mit 600KHz aktuell gerade mal ca. 15 min bei 
1,8 V . Da ich ungefähr alle 10-15 min eine kurze "Ladephase" bekomme, 
muß der Tiny die magere Zeit überbrücken können. Bei 1,2MHz saugt der µC 
den Cap zu schnell leer

Hatte das ganze mit 1,2MHz laufen, jedoch schaffe ich die Abarbeitung 
der Daten dann nicht (Look-up table etc..), da der Cap dann zu schnell 
unter die 1,8V (benötigt für 1,2MHz) druntergeht.
Ich komme von der Energie gerade so über 1,6 - 1,8V raus, d.h. bei 1,2 
Mhz gibt es viele Zyklen, bei denen er garnicht mehr "anspringt", daher 
kam die Idee mit 128KHz zu arbeiten!
Mit 128Khz könnte ich an der 1,6V Grenze länger "arbeiten"

Tiny 25 verwenden ist eine Idee wert, glaube ich langsam.....

weil tiny13A keinen SPI hat, deshalb ist glaube ich wechsel zu Tiny25 
sinnvoll, wenn der Preisunterschied so marginal ist

Akku-> Nicht möglich, da Energy Harvesting Lösung angestrebt ist. 0,22F 
ist eigentlich zu viel, es sollten eher <0,1 sein, aber ich muß im 
Prototypenstadium den µC ja auch zum laufen kriegen....paar minuten