Hallo zusammen, ich stand gerade vor dem Problem mit Deklaration einer Variablen.
Ich hatte erst das:
wird der Wert nicht mit UL automatisch zur unsigned long? auch wenn er ein int ist?
Ich steh gerade etwas auf dem Schlauch! 
MfG Marco
wird der Wert nicht mit UL automatisch zur unsigned long? auch wenn er ein int ist?
Ein 32 Bit Wert passt nicht in eine 16 Bit Variable.
Das kann man tun, muss sich aber bewusst sein, dass die obere Hälfte abgeschnitten wird.
Beispiel, 10L Eimer:
Da kannst du ein hundert mal 20L rein gießen.
Beim nutzen des Inhalts wirst du maximal 10L vorfinden.
Das UL ist für das Literal. Das "unsigned long" oder "int" ist für den Datentyp der Variable. Das sind zwei getrennte Dinge.
Lege dir mal ein Programmierhandbuch, vorzugsweise für C zu. Dort wird sowas bereits in den Basics erklärt. Andernfalls gibt es genügend Hilfestellungen auch im Netz.
UL solltest du für Textergänzungen des Compilers lediglich nutzen.
#define F_CPU 8000000UL
beginner34:
wird der Wert nicht mit UL automatisch zur unsigned long? auch wenn er ein int ist?
Kann man ein Kaninchen aus einem Hut zaubern?
Also das mit dem Kaninchen habe ich schon gesehen.
Aber wenn Du "static unsigned int" deklarierst, dann ist das auf einem 8-Bit AVR immer eine 16-Bit Variable, die Du deklarierst. Und wenn Du überschießende Bits von beispielsweise einer 32-Bit Konstanten an die 16-Bit Variable zuweist, bleibt die 16-Bit Variable trotzdem immer noch eine 16-Bit Variable. Und verwandelt sich dabei nicht in ein Kaninchen (oder eine 32-Bit Variable).
unsigned int Wert1 = 6000UL*30;
Links und rechts vom Gleichheitszeichen muss der passende Typ sein.
Hier hast du zwar rechts ein unsigned long ( 180000UL ) das wird aber einer 16-Bit Variable zugewiesen.
Nimm den Windows-Taschenrechner: View: Programmer, Dec, Dword und tippe "6000 * 30 =" ein.
Dann ändere Dword -> Word und bewundere, wie aus 180000 -16608 wird. Viel Spass.
( Leider kann der Windows Taschen-Rechner kein "unsigned", und leider hab ich ein englisches Exemplar )
Danke für die Antworten.
Ich habe mehrere Arduino Bücher, und ja , auch gelesen ! 
Mit dem UL hinter dem Wert, habe ich hier aus dem Forum. Mir sind 16Bit, 8Bit,.... bekannt, nur war mir nicht klar, warum ich dann noch hinter dem Wert (zB: 10000UL) noch ein UL setzen muss, wenn doch in der Deklaration der Datentyp steht.
Das ich am Anfang den falschen Datentyp verwendet habe ist mir erst später aufgefallen und deswegen wollte ich wissen, wie der zusammenhang ist.
MfG Marco
beginner34:
nur war mir nicht klar, warum ich dann noch hinter dem Wert (zB: 10000UL) noch ein UL setzen muss, wenn doch in der Deklaration der Datentyp steht.
Wo das wirklich wichtig ist bei solchen Sachen:
unsigned long var = 1000UL * 10;
Da ist das unbedingt nötig, da sonst in int gerechnet wird
nur war mir nicht klar, warum ich dann noch hinter dem Wert (zB: 10000UL) noch ein UL setzen muss, wenn doch in der Deklaration der Datentyp steht.
In C und C++ sind numerische Konstanten immer vom Type int.
Grundsätzlich.
Wenn du also mit 32Bit Konstanten rechnen willst, dann sage das dem Compiler mit Hilfe von L oder UL.
Wobei die Größe von int Plattform-abhängig ist. Auf einem 8-Bit Prozessor ist int 16 Bit. Auf einem 32 Bit Prozessor (wie dem Due z.B.) ist int auch 32 Bit groß. Da ist der 16 Bit Datentyp short
Auf einem 32 Bit Prozessor (wie dem Due z.B.) ist int auch 32 Bit groß.
Ja, aber auch da richtet ein UL (meist) keinen Schaden an, auch wenn dann in 64Bit gerechnet wird.
Diese Rechenoperationen werden im Compiler durchgeführt. Im Code landet nur das Ergebnis.
Es ist eine Compiezeit Operation.
Keine Laufzeit Operation.
(Vielleicht ändert das ja den Blickwinkel)
Serenifly:
unsigned long var = 1000UL * 10;
Hallo,
ärgere Dich nicht beginners34, über solche Sachen stolpere ich auch. 
Eigentlich sollte dem Compiler klar sein was er machen muß, auch ohne den Hinweis UL.
Sowas muß man sich merken und gut ist.
Ich glaube, das ist der Historie geschuldet.
Denn modernere Sprachen können das durchaus.
Bald 40 Jahre ist es her, der Tag, an dem C erfunden wurde.
Selbst das ++ am C ist recht alt...
Hallo,
dann wird es aber mal Zeit das zu ändern im 21. Jahrhundert.
Ist doch eine Compilersache, hat doch in Sinne nichts direkt mit C zu tun.
Schlimm genug das wir uns mit Bits und Bytes rumärgern müssen.
Schlimm genug das wir uns mit Bits und Bytes rumärgern müssen.
Also, ich mach das freiwillig. Eher interessant, wenn es nur um ein paar byte RAM - Speicher geht.
Die Probleme "im echten Leben", wenn man Code für 64 und 32 bit übersetzt
(wie groß ist size_t , alignment, usw.), sind eigentlich gleich.
Man könnte auch Warnungen bei
if ( x=1 )
und ähnlichen Fallen in c++ erzeugen ...
Hallo,
bei meinen Timer Registern mach ich bald nichts mehr freiwillig zum Spass.
Immer wenn ich denke ich habe die Logik durchschaut, klappt's nicht.
Ich glaube ich nehme mir eine Auszeit ...
Egal, welche Sprache/Baustein, man muss das dahinter stehende Konzept verstanden haben.
Dann geht das...
Ein bisschen auswendig lernen ist auch nicht schlecht.
Und:
Dass ein Feature in dieser da ist, und in der anderen eben nicht, macht den Charakter einer Sprache aus.
Es gibt viel schlimmere(leider wertend) Dinge als L und UL.
z.B.: Mehrfachvererbung, friends, ...
Ganz schlimm, ist für mich, das fehlende Interface Konzept.
Naja....
Man kann auch Spaß an sowas entwickeln..
Und dann berühren einen die Besonderheiten einer Sprache gar nicht so negativ.
Hier mal das Produkt einer meiner Bemühungen:
Ein Forth System in PHP
Hallo,
was die Leute so alles machen ...
Spass habe ich ja noch dran, sonst hätte ich schon aufgegeben. Ist ja alles Hobby das hier. Nur der Timer raubt mir zur Zeit viele Nerven.
combie:
Ganz schlimm, ist für mich, das fehlende Interface Konzept.
Kann man durch abstrakte Klassen (d.h. Klassen die nur rein virtuelle Methoden enthalten) und bei Bedarf Mehrfachvererbung nachbilden. Mit virtueller Vererbung kann man dabei auch die üblichen Probleme der Mehrfachvererbung umgehen.
Ja, man kann alles tun, wenn man nur genügend will...
Meine gnadenlose C(C++) Verweigerung habe ich schon vor einiger Zeit abgelegt...
Auch wenn mir noch einiges sehr umständlich erscheint.
Objekt Methoden als ISR... (static only?!?!)
Callbacks auf Objekt Methoden. (Subject/Observer Design Pattern)
Aber auch dieses ist alles machbar!
Manchmal reicht es den Blickwinkel zu ändern, und manchmal muss man einen dazwischen schieben...