ATmega328P; Bit setzen/löschen eines Integers klappt nicht.

Matthias S. schrieb:
> Ratloser schrieb:
>> volatile uint8_t puffer=0;
> Das ist gar kein Integer, sondern nur ein Byte. So ein Byte hat 8
> Bitpositionen (0 - 7).
> Wenn du jetzt
>> puffer |= (1<<bit);
> machen willst schiebst du 10 mal ein Bit nach links. Da müsste dir jetzt
> was auffallen :-P

Oh, hoppla... stimmt. Im richtigen Programm ist das nicht das Problem.
Dort habe ich einen uint32_t und eine höchtste Bitzahl von 26, sollte 
also gehen.

Habe diesen Code zur vereinfachung geschrieben, aber ich kann den 
Originalen Code sonst mitsenden, wenn gewünscht.

Danke dir schonmal

> Im richtigen Programm ist das nicht das Problem. Dort habe ich einen
> uint32_t und eine höchtste Bitzahl von 26, sollte also gehen.

..und schiebst Du auch den passenden Datentyp?

> [..] ich kann den Originalen Code sonst mitsenden, wenn gewünscht.

Natürlich.

g457 schrieb:
>> Im richtigen Programm ist das nicht das Problem. Dort habe ich
> einen
>> uint32_t und eine höchtste Bitzahl von 26, sollte also gehen.
>
> ..und schiebst Du auch den passenden Datentyp?
Hmm... da bin ich jetzt verwirrt... also, ich schiebe eine 1, d.h. es 
ist ja auch Binär ne 1.

So, Datei ist angefügt, sollte nen RC5 Empfänger sein. (Ja, ich weiss 
das es da bessere und vorgefertigte Codes gibt (Peter Danegger), aber 
ich möchte selbst so etwas entwickeln, es geht um die Herausforderung)

> Hmm... da bin ich jetzt verwirrt... also, ich schiebe eine 1, d.h. es
> ist ja auch Binär ne 1.

Jaaber eine "1" ist nur 16 Bits lang, und wenn Du die um 26 stellen nach 
links schubst, dann bleibt davon nicht mehr viel übrig.

g457 schrieb:
>> Hmm... da bin ich jetzt verwirrt... also, ich schiebe eine 1,
> d.h. es
>> ist ja auch Binär ne 1.
>
> Jaaber eine "1" ist nur 16 Bits lang, und wenn Du die um 26 stellen nach
> links schubst, dann bleibt davon nicht mehr viel übrig.

Ja stimmt, Atmel Studio wandelt wandelt aber alle Zahlen direkt in 
Binärzahlen um, d.H. es ist Binär eine 1, welche ja nur ein Bit 
benötigt.

Ich habe jetzt wieder und wieder versucht und ich glaube dem Problem auf 
der Spur zu sein... ich habe in der main Schleife eine Abfrage die so 
aussieht

1

if (puffer==1<<0) PORTC |= 1;

2

else PORTC &= ~1;

Ich glaube das Problem liegt darin das ich mit == teste. Wenn da noch 
weitere Zeichen stehen im puffer als die, die ich prüfe, dann ergibt das 
logisch 1 und nichts geht.

So nochmals um alle Aufzuklären, ich habe den Fehler jetzt.

Mein Programm funktioniert soweit, das Problem lag in meiner Abfrage.

Das Programm erzeugt einen Code: z.B. "0101010101"
Die Abfrage überprüft: if ("0101010101" == "01") //machwas

ich hätte nicht == nehmen sollen in der Abfrage, dadurch wird der 
returnwert immer 0, ausser wenn ich den Integer zurücksetzt und dann 
einen Wert schreibe:

if ("00000001" == "01") //machwas


Vielen Dank an alle die mir zu solch später Stunde noch geholfen haben, 
ihr habt mich indirekt auf die Lösung gebracht dadurch das ich meinen 
Code nochmals aus anderer Sicht hinterfragt habe. Sollte jemand den Code 
für den RC5 Empfänger benötigen kann er sich gerne melden. (Eine 
halbfertige Version ist oben zu finden)

Grüsse und nochmals vielen Dank - Ratloser (naja, jetzt nicht mehr so 
sehr)

Wie kommst du auf 16 bit für das integer?
Das int8 hat 8 bit und ist singend.
Das uint32 ist 32 bit lang und unsingned.

Okay, wieder was gelernt. Danke, diese Notation bei den avr war neu für 
mich.

A. K. schrieb:
> Logic Operator schrieb:
>> Wie kommst du auf 16 bit für das integer?
>
> Weil der C Quelltext
>   1
> per Sprachdefinition eine Zahl vom Typ "int" darstellt, und damit bei
> AVR 16 Bits hat. Das Ergebnis der Operation
>   1 << bit
> ist deshalb ebenso per Definition vom Typ "int". Unabhängig vom Kontext,
> in dem dieser Ausdruck steht!

Das war mir auch neu (nicht das ich es nicht glaube). Prima, noch was 
dazugelernt und mein Code funktioniert jetzt auch perfekt.

Sorry, aber diese 1<<irgendetwas ist die größte Schei... wie man hier 
wieder schön sieht.
Schreib ordentliche Bitmasken oder Hex-Werte, so wie es die ganze Welt 
macht. Nur das kleine Atmel-Dorf nutzt den schlecht lesbaren Schei...

Sorry,

so ein wirrer Gedanke kommt nur bei unerfahrenden Programmieranfängern 
erfahrungsmäßig vor.

Auch ist es keine Erscheinung von Atmel, sondern das Mittel zur 
Umsetzung von Bitnummern (Bitbezeichnungen) zu Bitmasken.

Die Nutzung von Bitbezeichnungen erhöht ungemein die Lesbarkeit, da sich 
ein Mensch über die Sprache austauscht. Das Merken und Reden über/ von 
Zahlen fällt vielen dabei viel schwerer.

Denken Sie darüber mal nach.

#define BIT0 0x01 schrieb:
> Sorry, aber diese 1<<irgendetwas ist die größte Schei... wie man hier
> wieder schön sieht.
> Schreib ordentliche Bitmasken oder Hex-Werte, so wie es die ganze Welt
> macht. Nur das kleine Atmel-Dorf nutzt den schlecht lesbaren Schei...

Karl M. schrieb:
> Auch ist es keine Erscheinung von Atmel

Und wer bitte schön nutzt noch dieses Verwirrspiel?

Karl M. schrieb:
> Die Nutzung von Bitbezeichnungen erhöht ungemein die Lesbarkeit

1

    // ala ATMEL

2

#define BIT3    3

3

4

... foo = 1<<BIT3;

5

6

   // und besser

7

#define BIT3    0x04;

8

9

... foo = BIT3;

Karl M. schrieb:
> Denken Sie darüber mal nach.

Das mach einmal, Herr Anfänger.

#define BIT0 0x01 schrieb:
> Sorry, aber diese 1<<irgendetwas ist die größte Schei... wie man hier
> wieder schön sieht.
> Schreib ordentliche Bitmasken oder Hex-Werte, so wie es die ganze Welt
> macht. Nur das kleine Atmel-Dorf nutzt den schlecht lesbaren Schei...

Blödsinn.
Wenn man Bits in einer Integer-Variablem (also einer ganzen Zahl) per 
Schleife setzen will, geht das nur mit Verschiebungen.
Oder einer Switch-Case-Abfrage oder einer If-Orgie.

STK500-Besitzer schrieb:
> per
> Schleife setzen will, geht das nur mit Verschiebungen

??? Es geht nicht um Schiebe-Operatoren, sondern die schwachsinnige 
Deklarations-Variante von Atmel. Also shift mit Konstanten aus dem 
Header.

#define BIT0 0x01 schrieb:
> // ala ATMEL
> #define BIT3    3
>
> ... foo = 1<<BIT3;

Bist du noch im Weichnachstschlaf? ;)

Guten Morgen STK500-Besitzer,

als Ergänzung, kann man noch ein Isomorphismus zwischen den Bit-Nummern 
und den Bit-Masken, über eine Tabelle (Array), nutzen.

1

uint8_t toBitmask[] = {1,2,4,8,16,32,64,128};

2

3

uint8_t bitmask;

4

bitmask = toBitmask[0];

define BIT0 0x01 schrieb:
> Bist du noch im Weichnachstschlaf? ;)

Du!

Wenn du einen einzelnen Ausgang adressieren möchtest, dann geht das nur 
über das IO Register und eine Pin Nummer.
Genau diese beiden Daten brauchst du dafür!


Andere Systeme, als AVR, machen das genau so.
Nur, dass die Register da anders heißen, evt. viel breiter sind, und der 
Zugriffscode in HALs verborgen wird.

Karl M. schrieb:
> uint8_t toBitmask[] = {1,2,4,8,16,32,64,128};

Aber bitte nur mit const davor und hoher Optimierungsstufe. Wir wollen 
ja keine Variablen.

A. K. schrieb:
> AVR Assembler und bei diversen ARMen

von A T M E L. Bitte zeige mir einen Header eines anderen großen 
Herstellers, der das auch so macht.

@all:
Die Welt ist größer als das Atmel-Dorf.

Arduino F. schrieb:
> Andere Systeme, als AVR, machen das genau so.

Beispiel, bitte zeige ein Beispiel.

Alle anderen geben im Header die Wertigkeit an, die du direkt nutzen 
kannst.
Die Welt ist größer als Atnmel!

> Insofern macht Atmel es IMHO richtig.

Sehe ich auch so. Die Header Dateien von STM sind voller magischer 
Zahlen.

A. K. schrieb:
> Die Includes werden bei Atmel aus der gleichen Quelle für C und für Asm
> erzeugt. Folglich enthalten die Includes sinnvollerweise die Bitnummer
> an Stelle einer Maske.

Danke, du schreibst ja selbst, dass es aus der Not geboren ist.

Und wenn man so eine Zusammenstellung einer Bitmaske mit 3 oder mehr 
Bits vor sich hat, erkennt man sofort diese Krücke.

A. K. schrieb:
> Insofern müsstest du eigentlich die Hardware-Designer verprügeln. Weil
> sie die für dich unerträgliche Frechheit besassen, Bits zu nummerieren,
> statt sie ausschliesslich als Maske zu codieren.

Nö, Atmel müsste für seine Faulheit gekopfft werden. Und du kannst das 
natürlich schreiben, wie du möchtest.

Heute ist man um lesbaren Code bemüht. Und da ist Atmels Krücke 
kontraproduktiv.
Und um das zu umschiffen, hat man das Makro _BV bemüht.

Wie gesagt, die ganze Welt macht es scheinbar falsch, ausser Atmel. ;)

Es ist doch völlig egal, welche Syntax der eine oder der andere schöner 
findet. Mit Makros kann man es sich ggf. so umbauen, wie man es gerne 
haben möchte. Zur Not steht es sogar jedem frei, die ganze Datei gegen 
eine schönere auszutauschen.

Man bedenke auch, wie alt diese Sachen sind. Damals war das vielleicht 
"state of the art".

Wichtiger ist doch, dass es funktioniert.

Abgesehen davon ist Software von  Hardware Herstellern fast immer 
suboptimal. Die haben ihre Expertise eben woanders.

Stefan U. schrieb:
> Man bedenke auch, wie alt diese Sachen sind. Damals war das vielleicht
> "state of the art".

Nö, das gibt es erst seit den AVRs, C on µC aber schon länger.

Stefan U. schrieb:
> Wichtiger ist doch, dass es funktioniert.

Das ist nicht der Ansatz moderner Programmierung. Oder wie stehst du zu 
MISRA und Co.? Code darf übersichtlich und lesbar sein. Er darf Qualität 
besitzen. Dazu tragen Atmels Schiebespielchen nicht bei.

Ich finde wenn dem "Autor: define BIT0 0x01 (Gast)" das Atmel Prinzip 
nicht gefällt, dann soll er sich bei dem Verein beschweren.

Hier kann er/sie/es solange mit den Füßen auf der Erde rum stampfen, wie 
es will. Atmel/Microchip wird das nicht kümmern.
Es wird die Situation nicht ändern.

Meine Oma sagte schon:
> Gott gebe mir Gelassenheit, hinzunehmen, was nicht
> zu ändern ist. Mut zu ändern, was ich ändern kann.
> Und Weisheit, zwischen beidem zu unterscheiden.

Und auch, wie Noäl Coward schon schrieb:
> Die Kritik an anderen hat noch keinem die eigene Leistung erspart.

Also nicht meckern...
Sondern: Zeige uns, wie es besser geht!

> Zeige uns, wie es besser geht!

Das hat er doch schon. jetzt fehlt nur noch die praktische Umsetzung für 
sämtliche AVR's. Das kann man dann als Fork bei GitHub veröffentlichen 
und dann staunen, wie viele Leute diesen Fork verwenden (oder auch 
nicht).

Arduino F. schrieb:
> Zeige uns, wie es besser geht!

Habe ich doch schon.

A. K. schrieb:
> Wie sieht dein umgedrehter _BV Makro aus, also der aus einer Maske eine
> Bitnummer macht?

Zeig mal dein Atmel-konformes Beispiel.

A. K. schrieb:
> Nein? Vielleicht doch.

Atmels Header werde ich nicht mehr ändern. Aber ich lasse mir den Mist 
nicht schön reden. Das einzige Pro-Argument war bisher die 
Bequemlichkeit, keine vernüftigen C-Header schreiben zu wollen, von A. 
K.

A. K. schrieb:
> Was stört dich am Klassiker

Den habe ich doch selber schon ins Spiel gebracht. ;)
Und der macht eine Bit-Maske, wie in allen nicht-Atmel Headern bereits 
deklariert. Wenn du _BV() gut findest, sind wir einer Meinung und 
verbannen diese Schiebespielchen aus unseren Quelltexten.

define BIT0 0x01 schrieb:
> A. K. schrieb:
>> Wie sieht dein umgedrehter _BV Makro aus, also der aus einer Maske eine
>> Bitnummer macht?

Wo bleibt das Beispiel?

A. K. schrieb:
> Ja, das frage ich mich auch. ;-)

A. K. schrieb:
> Wie sieht dein umgedrehter _BV Makro aus, also der aus einer Maske eine
> Bitnummer macht? Vorzugsweise Standard-C bis 64 Bits. Gehen tuts, aber
> schön geht anders.

Zeige bitte das Beispiel mit den Atmel-Deklarationen, damit der Vorteil 
der Schiebespielchen ersichtlich wird. Bisher gab es nur heisse Luft.

Ich finde es schlechter, weil der Quelltext unnötig überladen wird:

... if (registerFoo & ((1 << BIT6) | (1 << BIT5) | (1 << BIT4) | (1 << 
BIT3)) ...


besser lesbar (wie bei allen anderen Herstellern)

... if (registerFoo & (BIT6 | BIT5 | BIT4 | BIT3) ...

Du kannst ja die überflüssigen Zeichen zählen. ;)

A. K. schrieb:

Wie bitte geht daraus ein Vorteil für die Atmel-konforme 
Headerverkrüppelung hervor?

In deinem Makro oben steht eine 31. Kannst ja einmal erklären, wie sich 
deine 64Bit Anfrage oder auch 8Bit und 16Bit dort wieder finden.

Alles sehr dünn hier mit den Argumenten für den Atmel-Quatsch. Bleibt 
einzig Atmels Bequemlichkeit; und das ist, zwar nicht technisch, 
nachvollziehbar.

Carl D. schrieb:
> Nachteil einer Maske statt der Bitnummer bleibt aber, daß man auch
> mehrere Bits setzen kann. Welches soll es dann sein? Das
> Erste/Letzte/Mittlere?

??? Die Maske kann (und bei einzelnen Bits "besteht") nur aus einem 
gesetzten Bit bestehen.

Carl D. schrieb:
> Bitnummer->Maske ist eine Funktion, umgekehrt nicht!

Maske1Bit->MaskeVieleBits auch!!!

;(((

A. K. schrieb:
> Was stört dich am Klassiker
>   #define _BV(n) (1<<(n))

... oder an der Variante von P. Dannegger mit der sbit.h?

1

#include "sbit.h"

2

3

#define LED0      PORT_B0

4

#define LED1       PORT_B1

5

#define INPUT     PIN_B2

6

7

#define EIN 0      

8

#define AUS 1   

9

.

10

.

11

// im Code dann z.B.: 

12

13

if(LED1 == EIN) LED0 = EIN;

14

.

15

.

16

LED0 ^= 1;  // Toggle

17

.

18

.

19

if (INPUT == LOW) LED0 = AUS;

Eine mir sehr sympathische Variante der Bitmanipulation :-)

(sbit.h ist im Forum schon mehrfach gepostet worden).

HildeK schrieb:
> #include "sbit.h"

... und eine weitere Variante, sich dem Schiebespiel zu entziehen.

Danke für die Unterstützung.

A. K. schrieb:
Wo bleibt dein Beispiel?

A. K. schrieb:
> Wie sieht dein umgedrehter _BV Makro aus, also der aus einer Maske eine
> Bitnummer macht? Vorzugsweise Standard-C bis 64 Bits.

Zeig doch endlich mal Code, wo das schön leserlich eingesetzt wird. 
Bisher gibts nur rosa Elefanten von dir.

define BIT0 0x01 schrieb:
> ... und eine weitere Variante, sich dem Schiebespiel zu entziehen.

Für die Bedienung der IOs wird das Ergebnis sehr leserlich.
Für die Registersettings ist für mich auch das 'Schiebespiel' ok. Man 
sieht ja durch die Bitnamen noch deutlich, was gemeint ist.

A. K. schrieb:
> #define VRAM_RAS

... was ja wieder nix anderes als die, von dir gescholtene, Bit-Maske 
darstellt. Und schon sind wir uns einig: Bit-Maske ist besser lesbar 
(egal wie sie erstellt wurde).

A. K. schrieb:
> Es macht mir nichts aus,
> beispielsweise ins Config-File für die genutzten Port-Bits sowas
> reinzuschreiben

... was sonst die Hersteller, ausser Atmel, per Header bereits mit 
liefern.

Man, war das ein langer Weg.

Carl D. schrieb:
> eine Bitnummer kann jederzeit eindeutig zu einer
> Maske gemacht werden, ist also quasi die höherwertige Information. Eine
> Mask dagegen kann ganz leicht uneindeutig bzgl. "welches Bit ist das"
> gemacht werden.

Puh, was geht denn jetzt ab? ;(

In beiden Varianten gibt es einen eindeutigen Zahlencode. Die eine
1, 2, 3, ...
und die andere
0x01, 0x02, 0x04, ...

Sorry, aber es wird albern.



A. K. schrieb:
> Ich mag es nicht, wenn ich in Headern nur die Maske
> zur Verfügung habe.

Also nutzt du nur Atmel und kennst nix anderes? Das erklärt deine 
Verbohrtheit.

Und natürlich soll jeder nutzen, was ihm gefällt. Aber bitte nicht in 
Entwicklungsteams mit Qualitätsstandards. ;)

Carl D. schrieb:
> 0..255

Oh man, du weisst gar nicht worüber hier die ganze Zeit geschrieben 
wurde? ;(((

A. K. schrieb im Beitrag #5256717:
> Plonk

Wenn keine Argumente vorhanden, ist das auch eine Art. ;)

Carl D. schrieb:
> Geisterfahrer

Im Ursprung hatte der TO genau das Problem der Schiebespielchen. Mit 
entsprechenden Bitmasken (nur eine '1' pro Maske, wie üblich) wäre das 
nicht passiert.

Und wie wir im Verlauf schön sehen können, landen auch die ganzen Umwege 
wieder bei der Bitmaske (mit nur eine '1' pro Maske, wie üblich). Und 
alle finden es gut. ;)

Thomas E. schrieb:
> Du sagst es.

Und ich konnte ihn sogar "aufbohren". ;)
A. K. schrieb:
> #define VRAM_RAS

A. K. schrieb:
> #define enableStart_disableOverflow()  setUSICR(1,0)

sehr aussagekräftig, super
setUSICR(1,0)
man erkennt sofort, welches Bit gesetzt wird. ;(
Oder was passiert bei setUSICR(7,0)? ;(

Üblicherweise (mit richtigem Header) schreibt man  USICR = USISIE
was man natürlich auch noch abstrahieren kann
#define enableStart_disableOverflow  (USICR = USISIE)

Ist wohl für jeden leicht zu erkennen, was lesbarer ist. ;)