Gast
#3982609
Hi, kann ich sowas machen, oder handele ich mir damit Probleme ein?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
Solange du uns nicht verrätst, was MCP2515_FILTER und MCP2515_FILTER_EXTENDED macht, wird dir das keiner beantworten können...
Gast
#3982675
Michael Reinelt schrieb: > Solange du uns nicht verrätst, was MCP2515_FILTER und > MCP2515_FILTER_EXTENDED macht, wird dir das keiner beantworten können... Mir geht um prog_uint8_t, was unter Atmel Studio nicht vorhanden ist. Der Rest ist erstmal irrelevant. prog_uint8_t ist doch auch ein uin8_t, oder nicht?
Uwe schrieb: > Michael Reinelt schrieb: > Solange du uns nicht verrätst, was MCP2515_FILTER und > MCP2515_FILTER_EXTENDED macht, wird dir das keiner beantworten können... > > Mir geht um prog_uint8_t, was unter Atmel Studio nicht vorhanden ist. > Der Rest ist erstmal irrelevant. > > prog_uint8_t ist doch auch ein uin8_t, oder nicht? Ja das ist ein Datentyp mit dem gleichen Wertebereich. Solltest du allerdings einer uint8_t Variable einen prog_uint8_t Wert zuweisen gibt es je nach Compilereinstellung mindestens mal ne Warnung.
Grml ... schrieb: > Solltest du allerdings einer uint8_t Variable einen prog_uint8_t Wert > zuweisen gibt es je nach Compilereinstellung mindestens mal ne Warnung. Warum? @TE: wofür brauchst du den typedef denn überhaupt? Was mindestens noch fehlt ist das "const" bei der Definition. Aber sinnvoller wäre es, stattdessen dann gleich __flash zu benutzen, wenn du sowieso einen hinreichend neuen Compiler benutzt.
Uwe schrieb: > prog_uint8_t ist doch auch ein uin8_t, oder nicht? Ja, aber einer der im Flash liegt: typedef uint8_t PROGMEM prog_uint8_t; ist allerdings schon lange deprecated:
1 | |
2 | |
3 | |
Jörg Wunsch schrieb: > Grml ... schrieb: > Solltest du allerdings einer uint8_t Variable einen prog_uint8_t Wert > zuweisen gibt es je nach Compilereinstellung mindestens mal ne Warnung. > > Warum? Das hat etwas mit Typsicherheit zu tun, da der typdef nur eine Aussage über die Speichergröße und Wertebereich/Präzision gibt. Ein Beispiel ist boolean in c (auch eine Variable mit 8bit). Siehe auch Misra Rule 10.1. Grml ... schrieb: > ...gibt > es je nach Compilereinstellung mindestens mal ne Warnung. Falsch ausgedrückt. Muss heißen gibt bei entsprechender Compilereinstellung eine Warnung
Gast
#3982775
Habe es nun folgendermaßen:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
Die typedef habe ich nun entfernt und fühle mich sicherer :-) http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#AVR%20Named%20Address%20Spaces
Gast
#3982786
Grml ... schrieb: > Das hat etwas mit Typsicherheit zu tun, da der typdef nur eine Aussage > über die Speichergröße und Wertebereich/Präzision gibt. Quatsch. Ein typedef ist einfach nur ein Typ-Alias. Deswegen ist folgender Code auch kein Problem und gibt keine Warnung:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Die 7 ist zwar vom Typ "int", aber x ist vom Typ "foo" - trotzdem keine Warnung, da "foo" und "int" das selbe ist. Millionen Zeilen Code verlassen sich darauf dass typedef einfach nur ein Alias ist und man beliebig zuweisen kann...
Grml ... schrieb: > Muss heißen gibt bei entsprechender Compilereinstellung eine Warnung Nein, gibt es nicht, und darf es nicht geben. prog_uint8_t war pure Augenauswischerei, und genau deshalb ist er auch entsorgt worden.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.