Hey Leute! Ich benötige für eine Zeitmessung eine 3 Byte Variable - denn 4 Byte sind zu viel und 2 Byte zu wenig --> daher fallen INT und LONG mal weg... Ich programmiere in C mit CVAVR und verwende eienn AT Mega8... Gibt es da eine Möglichkeit, dass ich mir eine Variable mit 3Byte/24Bit zusammenbastle? Kann ich diese dann noch Problemlos in meinem Array verwenden? lg Patrick
Schreibs doch gleich in ein Array, wozu brauchst du dann noch diese merkwürdige Variable? Was spricht sonst dagegen, ein "long" zu nehmen? Das obere Byte wird dann halt nicht benutzt, und? Wayne interessierts...
Tja, leider ist mein Programm sehr umfangreich und daher muss ich mit meinen Variablen "sparen wo's nur geht"... Wenn ich jetzt mehr als 100 Läufer messe, dann stürzt mir das System ab, da vermutlich mein Array andere Speicherbereiche "angreift"... Gibts da keine Möglichkeit eine 3Byte Variable zu erstellen? lg Patrick
Was ist mit Strukturen? Hab mal gegooglet... Ist das damit nicht irgendwie möglich? Was könnte ich sonst noch machen, damit mir die Variablen nicht zu groß werden? lg Patrick
Erstellen kann man das schon. Aber zum Rechnen wirds
etwas aufwändig.
Alternative, wenn du schon unbedingt auf 1/1000 genau
messen willst (was ich persönlich für Schwachsinn halte,
Tausendstel sind nicht mal bei den Skirennläufern gefragt
und die brettern mit mehr als 100km/h durchs Ziel. Bei
einer Gesamtlaufzeit von über einer Stunde sind 1/1000
sowas von uninteressant).
Nimm 1 uint16_t for die 1/1000 Sekunden. Damit kannst
du 1 Minute gerade noch abdecken. Dann noch einen uint8_t
für die Minuten dazu. 256 Minuten reichen für etwas mehr
als 4 Stunden
struct MyTime {
uint16_t Tausendstel;
uint8_t Minuten;
};
struct MyTime[100] Zeiten;
Du kannst drei einzelne Bytes in einer struct ablegen. Dann musst Du allerdings bei einer Berechnung alle drei Bytes auch einzeln behandeln (Überlauf usw...).
wie wärs mit der einfachen Alternative: Mega88 statt Mega8? Diese Klimmzieherei hat doch keinen Sinn, überleg dir mal, wieviel Zeit du jetzt schon damit zugebracht hast, zu versuchen, die Chipgrenzen zu überlisten... Fang doch nicht so einen Kram an. Wenn du vorhast, 1000 Stk und mehr davon zu bauen, macht es Sinn, alles in einen kleineren Chip zu pressen, sonst nicht.
crazy horse wrote: > wie wärs mit der einfachen Alternative: Mega88 statt Mega8? Diese > Klimmzieherei hat doch keinen Sinn, überleg dir mal, wieviel Zeit du > jetzt schon damit zugebracht hast, zu versuchen, die Chipgrenzen zu > überlisten... Das hat nichts mit Chipgrenzen zu tun. Selbst 100 Stück long brauchen erst 100*4 = 400 Bytes. Die hat ein Mega8 aber locker. Nichts gegen einen Chip-Upgrade. Aber auch der kann solides Handwerk nicht ersetzen.
@ crazy horse >wie wärs mit der einfachen Alternative: Mega88 statt Mega8? Diese >Klimmzieherei hat doch keinen Sinn, überleg dir mal, wieviel Zeit du >jetzt schon damit zugebracht hast, zu versuchen, die Chipgrenzen zu >überlisten... Ich galube ihm fehlt her noch einiges an Grundverständnis zum Thema Programmieren. >Fang doch nicht so einen Kram an. Wenn du vorhast, 1000 Stk und mehr >davon zu bauen, macht es Sinn, alles in einen kleineren Chip zu pressen, >sonst nicht. Warum nicht gleich nen P4? ;-) Im Ernst, siehe oben. MfG Falk
ich weiss ja nicht, was er sonst noch so braucht. Er wird ja nicht einfach so auf Speichergrenzen gestossen sein. Ich wollte nur sagen: solche "Kunstgriffe" sollte man ohne absolute Notwendigkeit vermeiden. Und in dem Fall kann man sie ganz einfach vermeiden, indem man zusätzliche 15 Cent investiert. Lohnt es sich in dem Fall, auch nur einen Augenblick darüber nachzudenken, wie man mit 3 statt 4 Bytes pro Variable auskommt? So, und jetzt ist für mich hier Schluss.
@Falk: Genau so ist es... Dieses Projekt ist meine Diplomarbeit und leider haben wir nicht wirklich viel zum Thema C-Programmierung in der Schule gemacht... Das was ich bis jetzt weiß, hab ich mir hauptsächlich hier im Forum "angelernt" (erklären lassen) oder eben durch Bücher "erlesen"... Chipupgrade kommt nicht in frage, da ich dann doch einiges im Code ändern muss und dafür fehlt mir leider die Zeit... Denn das Projekt soll so schnell wie möglich abgeschlossen werden... @ Karl heinz Buchegger: Also die Tausendstel hab ich jetzt "aufgegeben" und hab mich jetzt für die hundetertstel Variante entschieden... Mal schaun, ob ich das Programm vl. noch etwas "säubern" kann, um den Speicher zu "schonen"... lg Patrick
Patrick F. wrote: > > Chipupgrade kommt nicht in frage, da ich dann doch einiges im Code > ändern muss Nicht wirklich. Du sagst deinem Compiler, dass du einen Mega88 hast und ... fertig. Eine Sache auf 10 Sekunden. > Also die Tausendstel hab ich jetzt "aufgegeben" und hab mich jetzt für > die hundetertstel Variante entschieden... Das ist vernünftig. Rechne mal nach. Selbst wenn du Spitzenläufer hast, dann legen die in 1/1000 Sekunde im 100Meter Lauf grade mal 1cm zurück. Wenn jetzt sein Leibchen flattert ....
@ Patrick F. >was ich bis jetzt weiß, hab ich mir hauptsächlich hier im Forum >"angelernt" (erklären lassen) oder eben durch Bücher "erlesen"... Uhhhhh, das lässt nichts Gutes hoffen. (Auch wenn die Tutorial hier ganz gut sind) Hast du sonstige Programmierkenntnisse in Basic oder so? >Chipupgrade kommt nicht in frage, da ich dann doch einiges im Code >ändern muss und dafür fehlt mir leider die Zeit... Denn das Projekt soll >so schnell wie möglich abgeschlossen werden... Aha, es brennt also schon. ;-) Kennt man ja. >@ Karl heinz Buchegger: >Also die Tausendstel hab ich jetzt "aufgegeben" und hab mich jetzt für >die hundetertstel Variante entschieden... Das ist so ziemlich egal. Nimm Long oder ein Struct mit 3 Byte. MFG Falk
crazy horse wrote:
> wie wärs mit der einfachen Alternative: Mega88 statt Mega8?
Aprilscherz ?
Mega8: 1kB SRAM
Mega88: 1kB SRAM
Mega168: 1kB SRAM
Peter
>Dieses Projekt ist meine Diplomarbeit
Mit einer Diplomarbeit wird doch idR. ein Studiengang abgeschlossen und
man erhält dann ein Diplom und ist dann Diplomingenieur (oder wiedas
heute heissen mag).
Ich versteh mal garnicht, was die Leute so studieren, wenn die
Diplomarbeiten sich am Ende mit völlig artfremden Themen
auseinandersetzen.
Wenn man sein Wissen aus dem Studium in deiner Diplomarbeit nicht unter
Beweis stellen kann, ist es - wie ich finde - schade um die Zeit, die
beim Studium drauf gegangen ist. Denn die Diplomarbeit ist doch das
Aushängeschild, wenn man später auf Jobsuche geht.
Ich schreibe das, weil mir das in letzter Zeit hier im Forum öfters
aufgefallen ist.
Kann aber auch gut sein, dass solche Äußerungen [Diplomarbeit] nur
vorgeschoben werden, um sich schneller Hilfe gewiss zu sein. kA.
weitermachen
AxelR.
@Karl heinz Buchegger >> Chipupgrade kommt nicht in frage, da ich dann doch einiges im Code >> ändern muss > > Nicht wirklich. > Du sagst deinem Compiler, dass du einen Mega88 hast und ... fertig. > Eine Sache auf 10 Sekunden. Die Register muss ich dazu ja auch "umdrehen" oder? Hab nämlich schon mal versucht einen mega8-Code auf nen mega88 "umzuschreiben"... Hat aber leider nicht geklappt --> mein Compiler spielt da nicht so recht mit... >> Also die Tausendstel hab ich jetzt "aufgegeben" und hab mich jetzt für >> die hundetertstel Variante entschieden... > > Das ist vernünftig. > Rechne mal nach. Selbst wenn du Spitzenläufer hast, dann > legen die in 1/1000 Sekunde im 100Meter Lauf grade mal > 1cm zurück. Wenn jetzt sein Leibchen flattert .... Ich stimme dir völlig zu und werde das dann mal dem Auftraggeber "melden" und ihn darauf hinweisen, was das für ein Schwachsinn ist... @Falk: Also konkret haben wir in der Schule C/C++ gelernt --> da habe ich also mal Grundkenntisse gehabt... Weiters habe ich schon einiges selbst dazugelernt, indem ich mir bei Lehrern "Hilfe" geholt habe... Sonstige "Kenntnisse" habe ich eben aus Foren, Tut's u.ä.... Basic --> nöö... Keine Ahnung damit... lg Patrick
Axel Rühl wrote: >>Dieses Projekt ist meine Diplomarbeit > > Mit einer Diplomarbeit wird doch idR. ein Studiengang abgeschlossen und > man erhält dann ein Diplom und ist dann Diplomingenieur (oder wiedas > heute heissen mag). > > Ich versteh mal garnicht, was die Leute so studieren, wenn die > Diplomarbeiten sich am Ende mit völlig artfremden Themen > auseinandersetzen. > Wenn man sein Wissen aus dem Studium in deiner Diplomarbeit nicht unter > Beweis stellen kann, ist es - wie ich finde - schade um die Zeit, die > beim Studium drauf gegangen ist. Denn die Diplomarbeit ist doch das > Aushängeschild, wenn man später auf Jobsuche geht. > > Ich schreibe das, weil mir das in letzter Zeit hier im Forum öfters > aufgefallen ist. > > Kann aber auch gut sein, dass solche Äußerungen [Diplomarbeit] nur > vorgeschoben werden, um sich schneller Hilfe gewiss zu sein. kA. > > weitermachen > > AxelR. Also ich bin in einer HTL für Mechatronik und Automatisierungstechnik und habe mir diese Diplomarbeit ausgesucht, da sie für mich am interessantesten klang... Das sie aber so umfangreich werden würde, wusste ich damals noch nicht... Die Diploarbeit hat nichts mit einem "Diplomingeneur" zu tun --> zumindest nicht die, die man in einer HTL macht... lg Patrick
@ Patrick F. >Also konkret haben wir in der Schule C/C++ gelernt --> da habe ich also Was heisst "In der Schule gelernt?" Programmieren lernt man im wesentlichen durch Programmieren! Das was man "in der Schule lernt" ist bestenfallst das Grundrüstzeug, der Startschuss. >mal Grundkenntisse gehabt... Mal gehabt, also nicht wirklich benutzt/gefestigt, praktisch das meiste mangels Anwendung schon wieder vergessen. > Weiters habe ich schon einiges selbst dazugelernt, indem ich mir bei Lehrern "Hilfe" geholt habe..>. Sonstige "Kenntnisse" habe ich eben aus Foren, Tut's u.ä.... Also immer nur ein paar Bruchstücke zusammengeflickt, dass es gerade zum Überleben reichte. Naja. >Basic --> nöö... Keine Ahnung damit... Meine Befürchtung bestätigt sich. Also mach das, was Karl Heinz gesagt hat. Poste deinen Quelltext (als Anhang) und wir können das Kind vielleicht noch retten, im Brunnen liegt es sowieso schon. 8-0 Mfg Falk
Falk wrote: > Also mach das, was Karl Heinz gesagt hat. Poste deinen Quelltext (als > Anhang) und wir können das Kind vielleicht noch retten, im Brunnen liegt > es sowieso schon. 8-0 Hat er schon. Im anderen Thread. Meine Befürchtung wurde noch übertroffen. Wird nicht leicht da durchzusteigen.
Der Quelltext ist in meinem anderen Thread "Interrupt- und Speicherproblem mit Mega8"... Tja wir haben im Laufe der Schulzeit einige Projekte mit µC gehabt, die aber nicht allzu schwer waren - z.b. Töne generieren (rechteck mit 200, 400 und 800Hz)... Wäre echt toll, wenn ihr mir helfen könntet... Es stecken immerhin schon eta hundert Stunden im Programm... =o( Und "nebenbei" muss ich ja auch noch für Schularbeiten, Tests und auch für die Matura lernen... STRESS!!! lg Patrick
@ Patrick F. >Wäre echt toll, wenn ihr mir helfen könntet... Es stecken immerhin schon >eta hundert Stunden im Programm... =o( Und "nebenbei" muss ich ja auch Mag sein, das heisst aber nicht, dass dabei viel rauskommen muss. Ich kann auch 100 Stunden im Kreis rennen . . . ;-) OK, hab den Quelltext gefunden, (und glaub ich auch schon einen massiven Fehler) Ich glaube in Zeile 250 fehlt eine { Die Formatierung ist S******. Da übersieht man auch mal fix fehlende Klammern etc. Und dass man sich damit besonders in C sehr schnell ins Knie schiessen kann, ist bekannt. Aber das musst du noch lernen, durch Schmerz. Das musste ich auch. ;-) MfG Falk
warum nicht so...
Man kann doch in einer struct beliebige Bitsizes definieren.
typedef struct {
uint32_t time :24; // 24Bit => 3Byte Laenge
} MYTIME_T;
MYTIME_T MyTime[100];
> typedef struct { > uint32_t time :24; // 24Bit => 3Byte Laenge > } MYTIME_T; Selbst wenn das so ginge, wäre die komplette struct aber immer noch 32 Bit groß... Aber afaik sind Bitfelder (C-Standard) nur in 16 Bit (int) möglich, einige Compiler unterstützen auch 8-Bit-structs...
Rainer I. wrote: > warum nicht so... > Man kann doch in einer struct beliebige Bitsizes definieren. > > typedef struct { > uint32_t time :24; // 24Bit => 3Byte Laenge > } MYTIME_T; > > MYTIME_T MyTime[100]; Und? Was bringt dir das, wenn der Compiler einen uint32_t für die Speicherallokierung benutzt und dann nur 24 Bit davon zum Rechnen benutzt. Die restlichen 8 Bit verschwinden ja nicht magisch, die sind immer noch da, nur benutzt sie keiner.
@ Karl heinz Buchegger >Und? >Was bringt dir das, wenn der Compiler einen uint32_t >8 Bit verschwinden ja nicht magisch, die sind immer >noch da, nur benutzt sie keiner. Sicher, aber das Problem von Patrick liegt sowieso ganz woanders. Mein Kommentar zum Quelltext ist im anderen Thread. Den hier sollten wir schliessen und uns auf das Problem im anderen Thread konzentrieren. FOLLOW ME! Beitrag "Interrupt- und Speicherproblem mit Mega8" MFG Falk
@ Karl heinz Buchegger >Und? >Was bringt dir das, wenn der Compiler einen uint32_t >für die Speicherallokierung benutzt und dann nur >24 Bit davon zum Rechnen benutzt. Die restlichen >8 Bit verschwinden ja nicht magisch, die sind immer >noch da, nur benutzt sie keiner. typedef struct { uint32_t time :24; // 24Bit => 3Byte Laenge } MYTIME_T; Es werden hier definitiv nur 3 Byte im Speicher benutzt ! Der Compiler rundet ggf. auf volle Bytes auf.
Rainer I. wrote: > @ Karl heinz Buchegger > >>Und? >>Was bringt dir das, wenn der Compiler einen uint32_t >>für die Speicherallokierung benutzt und dann nur >>24 Bit davon zum Rechnen benutzt. Die restlichen >>8 Bit verschwinden ja nicht magisch, die sind immer >>noch da, nur benutzt sie keiner. > > typedef struct { > uint32_t time :24; // 24Bit => 3Byte Laenge > } MYTIME_T; > > Es werden hier definitiv nur 3 Byte im Speicher benutzt ! Ehrlich? Das hätte ich nicht gedacht! Wie hast du das festgestellt? Was passiert bei MYTIME_T Times[100]; Wie gross ist sizeof(Times) ?
> Es werden hier definitiv nur 3 Byte im Speicher benutzt ! > Der Compiler rundet ggf. auf volle Bytes auf. Hmmm, das ist ja toll. Mit welchem Compiler hast Du das getestet? GCC? Hab grad noch mal im K&R nachgeschlagen, und da steht eigentlich das, was ich oben schon angemerkt hatte, allerdings direkt darunter: "Almost everything about fields is implementation-dependent [...]" Genau das scheint der Punkt zu sein: In dem Zusammenhang darf anscheinend jeder Compiler machen, was er will (weshalb Programme, die mit bit fields arbeiten auch i.d.R. nicht portabel sind). Und wenn die Optimierung des Compilers merkt, dass nur drei Bytes benötigt werden, wird das anscheinend auch auf drei Bytes "zurechtgeschnippelt".
...Sorry, sollte natürlich "portierbar" und nicht "portabel" heißen...
typedef struct {
uint32_t time :24; // 24Bit => 3Byte Laenge
} MYTIME_T;
MYTIME_T Times[100]; // 100 * 3Byte
sizeof(Times) ist somit 300, zumindest mit GCC ;-)
Habs grad mal ausprobiert, und tatsächlich: Es werden nur drei Bytes benutzt. Man lernt nie aus...;-)
Rainer I. wrote: > typedef struct { > uint32_t time :24; // 24Bit => 3Byte Laenge > } MYTIME_T; > > MYTIME_T Times[100]; // 100 * 3Byte > > sizeof(Times) ist somit 300, zumindest mit GCC ;-) Ist ja hochinteressant. Vielen Dank.
> typedef struct { > uint32_t time :24; // 24Bit => 3Byte Laenge > } MYTIME_T; > > Es werden hier definitiv nur 3 Byte im Speicher benutzt ! > Der Compiler rundet ggf. auf volle Bytes auf. Darauf würde ich mich nicht verlassen! Compiler für Maschinen, die auf ungeraden Adressen keine Worte lesen/schreiben können, allignen üblicherweise den Beginn von structs auf gerade Adressen. Aber es gibt eine viel simplere Lösung für das Problem: Du rechnest mit long und schreibst Dir eine kleine Verwaltung für Dein 3-Byte-Variablenarray: unsigned char Buffer[100 * 3]; long Get3Bytes(int index) { long r = 0; assert(sizeof Buffer >= (index + 1) * 3); memcpy(Buffer + 3 * index, &r, 3); return r; } void Put3Bytes(long val, int index); Die Put... kann Du Dir selbst ausdenken. @ Falk: Statt hier klugscheißend rumzupoltern, hättest Du besser Dein Hirn ein wenig angestrengt und diese Lösung selbst vorgeschlagen - oder reichen dafür die Kenntnisse doch nicht?
@ Uhu Uhuhu >Aber es gibt eine viel simplere Lösung für das Problem: >Du rechnest mit long und schreibst Dir eine kleine Verwaltung für Dein >3-Byte-Variablenarray: Ja, die simpelste Lösung ist die Verwendug eine LONG Arrays. Das ist auch gar kein Problem, sein Speicher ist nicht übrlastet. Es sind Programmierfehler. >Statt hier klugscheißend rumzupoltern, hättest Du besser Dein Hirn ein >wenig angestrengt und diese Lösung selbst vorgeschlagen - oder reichen >dafür die Kenntnisse doch nicht? Du bist der Held des Tages. http://de.wikipedia.org/wiki/Arroganz#Interpretation MfG Falk
Falk wrote: > Ja, die simpelste Lösung ist die Verwendug eine LONG Arrays. Das ist > auch gar kein Problem, sein Speicher ist nicht übrlastet. Es sind > Programmierfehler. Die Frage lautetet: > Gibt es da eine Möglichkeit, dass ich mir eine Variable mit 3Byte/24Bit > zusammenbastle? Ich würde sagen: Thema verfehlt, mein Herr.
Hallo, ich habe gerade auch genau dieses Problem. Am besten würde mir genau die Lösung von Rainer I. gefallen. In meinem Fall sah das so aus:
1 | typedef struct |
2 | {
|
3 | long abc :24; |
4 | }Test; |
Und lief leider mit einem Tasking-Compiler für C167 nicht. komischerweise ging folgendes:
1 | typedef struct |
2 | {
|
3 | int abc :8; |
4 | }Test; |
Ein sizeof() davon belegt aber auch 2 Byte. Weiterhin habe ich auch noch
1 | typedef struct |
2 | {
|
3 | BYTE High; |
4 | BYTE Middle; |
5 | BYTE Low; |
6 | }my24bitData; |
probiert. Auch hier belegt die Struktur aber 4 Byte...
@ Gabriel (Gast)
>probiert. Auch hier belegt die Struktur aber 4 Byte...
Dann musst du im Handbuch des Compilers mal nach Alignment, packed etc.
suchen, um dem Compiler zu verclickern, dass er KEINE Füllbytes in
Strukturen einfügen soll.
MFG
Falk
Pech. Fast alles rund um Bitfields ist abhängig von Zielmaschine und insbesondere Compiler. Zuverlässig portabel ist nur die Speicherung in einem Byte-Array. Wobei die Nummer mit dem Bitfield immerhin auch bei anderen GCC Targets funktioniert, Alignment-Regeln zum Trotz, wenn man dem Compiler mit -fpack-struct auf die Sprünge hilft (z.B. ARM).
@Gabriel Da der C167 ein 16-Bitter ist, nehme ich an, daß er defaultmäßig ein alignment von 2 hat, d.h. die Byte-Größe der struct wird geradzahlig aufgerundet, damit der Proz. immer 16-bittig auf geradzahlige Adressen zugreifen kann. Schau mal ob beim Tasking-Compiler das aligment umgestellt werden kann.
Danke für die Tips, ein Blick ins Handbuch hat weitergeholfen. Ein _packed vor das struct und es funktioniert. Zumindest die Variante mit den 3 bytes. Das :24, was sicher die Arbeit erleichtern würde geht ja aus irgendwelchen anderen Gründen nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.