Variablendefinition in Microchip Studio

[LionAVR]

Hallo zusammen,

ich habe seit kurzem wieder mit Programmieren von Mikrocontrollern angefangen. Vor Jahren habe ich mehrere Projekte mit 8051 Serie gemacht (Programmierung in Assembly). Dieses Mal probiere es mit AVR und in C/C++.
In Programmierung in C oder C++ habe ich auch Erfahrung aber Microchip Studio ist ganz neu für mich.

Ich habe seit ein paar Tagen Problem damit eine 8 Bit Variable zu definieren. Ich denke ich mache etwas ganz falsch. Das komische liegt daran, dass das Programm erfolgreich kompiliert wird. Bei Debugging spring aber Microchip Studio manche Zeilen und manche variable sind nicht definiet und haben keinen Wert. Wie zum Beispiel die Variable "i" unten!


#include <avr/io.h>
int main(void)
{

DDRB = 0x0;
PORTB = 0xFF;
uint8_t i = 10; // Diese Zeile wird gesprungen. i hat keinen Wert nach dieser Zeile!

while (1)
{

if(i==0)
PORTB = 0xE5;
else
PORTB = 0x5E; // Immer noch kein Wert für "i"
}

return 0;
}

Ich würde mich freuen wenn jemand mir einen Tipp geben kann, was ich hier falsch mach.

Viele Grüße,

[Andre_S]

Hallo,

habe schon seit Jahren nichts mehr mit Microchip Studio gemacht und zu der Zeit auch nicht mit AVR.
Aber zu meiner Zeit war uint8_t in "stdint.h" definiert, eventuell kannst Du dies wie "avr/io.h" ebenfalls includieren...

https://onlinedocs.microchip.com/oxy/GUID-317042D4-BCCE-4065-BB05-AC4312DBC2C4-en-US-2/GUID-F7C4A68C-761D-465B-A9A6-B22BA8583DCC.html

(https://onlinedocs.microchip.com/oxy/GUID-317042D4-BCCE-4065-BB05-AC4312DBC2C4-en-US-2/GUID-F7C4A68C-761D-465B-A9A6-B22BA8583DCC.html)
Gruß André

[oberallgeier]

.. wieder mit Programmieren von Mikrocontrollern angefangen .. Microchip Studio ist ganz neu für mich ..Hmmm, jetzt versuche ich mal meine (äusserst negative) Meinung über/zu Microchip bzw. deren ATMELchips-Dokumentation für mich zu behalten. Nur so viel: ich arbeite (noch immer) mit Studio4 - Studio7 hatte ich z.B. wegen des für mich fast immer unnötigen Organisations-Wasserkopfs schnell sein lassen.

André´s Meinung ist ganz meine - da fehlt wohl was.


.. Problem damit eine 8 Bit Variable zu definieren. Ich denke ich mache etwas ganz falsch ..
#include <avr/io.h>
int main(void)
{ . . .

Mit diesen Includes hatte ich anfangs auch immer wieder Probleme bis ich .. ja, bis ich so ne Art "Standardkopf" (und Code-Schema) für meine Programme geschrieben hatte. Da waren ein paar häufige includes drin (obs die braucht oder nicht *ggg*).

Bei Deinem Code - eine Ausgabe erfolgt nicht - scheint mir ja auch die "..io.."-Bibliothek nicht nötig zu sein (vermutlich liegts aber an der Darstellung Deines Codes - und Du hast wesentliche Codezeilen einfach weggelassen :-/). Dagegen fehlt die
#include <stdlib.h>
evtl auch die
#include <inttypes.h>.

Nur so, als Beispiel und nicht unbedingt als Empfehlung mal ein stark gekürzter, aktueller Code (m)einer aktuellen "main"-Code-Datei. Die Wellenlinien stehen für entfernte Abschnitte - hier vorwiegend projektbezogener Code des "main" mit den zugehörigen Kommentaren.

/* >> Stand D:\D_pro-fils\compu_MC\C2\Db030\Db030.c
================================================== ===============================
Target MCU : ATMEGA328 - PU
Target Hardware : Mini2D0(.15)=R7D01 ("Steckbrett") ATMEGA328-PU + L293DNE
Target cpu-frequ. : 20 MHz, externer Quarzoszillator
================================================== ===============================
Enthaltene Routinen :
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ < Wellenzeile steht für entfernten Text
*** Versionsgeschichte:
========================
x23 22Okt24 1106 Portbelegung-Liste geordnet, TC1PWM u IRLEDset wieder includet
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
**Aufgabenstellung : Software f Mini2D0(.15) .#2 / auf m328+
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
>> besseres Dokmt.: ATmega328-P_ab48A_8271I_10-2014__NEU-NEU-NEU-NEU-NEU-NEU.pdf
================================================== ============================ */
#include <stdlib.h> //
#include <avr/io.h> //
#include <avr/interrupt.h> //
//#include <inttypes.h> // < < < < Ist das notwendig ? ? ?
// - - - - - - - - - - - - - - - -
// F-CPU ab #>hier<# von Libs etc benötigt, = NICHT definiert in CurrConfOptions
#define F_CPU 20000000L // 02 10 2016 1330
#define BAUD 120000 // Akzeptiert br@y als 128kBd >> 5Nov2018 !!
#define DATM "23 10 2024 1630"// <<== Textstring als Konstante
// - - - - - - - - - - - - - - - -
// ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
/* Es folgt der aktuelle Übersetzungskommentar: **************************
Device: atmega328p
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Build(s) Program Data EEPROM
30. 7.2024 16:14:12 10982 bytes (33.5%) 1409 bytes (68.8%)
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
22.10.2024 16:57:36 6848 bytes (20.9%) 1137 bytes (55.5%) erste NUR-x23

Build succeeded with 0 Warnings...
================================================== ========== ***************** */

Anmerkung: Wenn ich in den im Code eingebetteten Kommentaren undoder in der Arbeitsmitschrift ALLES notiere das ich wichtig finde, dann habe ich nach einigen Monaten und später meist rund die Hälfte der wichtigen Dinge die ich bei späteren Überarbeitungen brauchte :-//

[Holomino]

Zum jetzigen Zeitpunkt würde ich davon ausgehen, dass die beim Anlegen eines neuen Projektes voreingestellte Optimierungsstufe im Compiler Dein "i" einfach rauskickt. Die kannst Du aber in den Projekteigenschaften auf "None" stellen.
Dazu:
ALT+F7
dann Karteikarte Toolchain
auf <C oder C++>Compiler,
dann Optimization
da dann "None" auswählen.

Das Ergebnis der Aktion kannst Du dann auch im Listing in den unterschiedlichen Optimierungsstufen anschauen und vergleichen. Listing und Map-File landen nach dem kompilieren im Solution-Explorer unter "Output Files" als *.lss und * map. Und damit arbeitet auch der Debugger.

Kurz: Was in *.lss und *.map nicht drin steht, findet der Debugger nicht.

(Also hast Du auch nix falsch gemacht)

Nachtrag noch (für die anderen beiden Threadteilnehmer):
An den Includes kanns hier nicht liegen. Man kann, wenn man so ein Projekt offen hat, den Weg von IO.h zu StdInt.h in den jeweilig eingebundenen Headern verfolgen.
IO.h->sfr_Def.h->IntTypes.h->StdInt.h.
Entsprechend taucht die StdInt.h auch nach dem Kompilieren in den "Project Dependencies" auf, ohne dass man sie jemals selber direkt eingebunden hat.

Macht nix, ich will nicht klugscheißern, aber vielleicht habt Ihr was mitgenommen.

[Andre_S]

Nachtrag noch (für die anderen beiden Threadteilnehmer):
An den Includes kanns hier nicht liegen. Man kann, wenn man so ein Projekt offen hat, den Weg von IO.h zu StdInt.h in den jeweilig eingebundenen Headern verfolgen.
IO.h->sfr_Def.h->IntTypes.h->StdInt.h.
Entsprechend taucht die StdInt.h auch nach dem Kompilieren in den "Project Dependencies" auf, ohne dass man sie jemals selber direkt eingebunden hat.

Macht nix, ich will nicht klugscheißern, aber vielleicht habt Ihr was mitgenommen.

Danke für die Information...
Dies hätte man sicher nachschauen können, so man diese Entwicklungsumgebung aktuell noch nutzt bzw. installiert hat,... allerdings bin ich über diesen Punkt seit Jahren hinweg... :-)


Gruß André

[oberallgeier]

..Nachtrag noch (für die anderen beiden Threadteilnehmer): An den Includes kanns hier nicht liegen...Hmmm. Muss ich bei Gelegenheit nachsehen.

Aktuell hatte ich gecodet:
//#include <stdlib.h> //
//#include <avr/io.h> //
//#include <avr/interrupt.h> //

Und das gibt einige Fehlermeldungen, u.a.
...
In file included from ../Db030.c:68:0:
D:\D_pro-fils\compu_MC\C2\Db030\..\..\CLib_01/uart0_16.h:29:25: error: expected ')' before 'bauddivider'...

[Holomino]

Und das gibt einige Fehlermeldungen, u.a.
Ich hänge mich mal jetzt nicht pauschal mit einer allgemeinen Gültigkeit aus dem Fenster.
Fakt ist für mich allerdings, dass nach Anlegen eines neuen Projektes im jetzigen Microchip-Studio und auch in dem vorhergehenden AVR-Studio 7 für AVR-Projekte in der main.c bereits im Grundgerüst die io.h einbindet. Das mag aber auch in älteren Versionen (AVR Studio4 oder WinAVR) anders gewesen sein. (Erkenne bitte wohlwollend an - ich schränke es ein - mehr weiß ich auch nicht - ich bin nicht der brennende Busch - eigentlich schade, aber ich hab's mir schon lange selber eingestanden - eingestehen müssen, um es genau zu nehmen ;)
)

Nichtsdestotrotz:
Die io.h lädt hier in Abhängigkeit vom festgelegten Controllertyp nicht nur die entsprechende Headerdatei mit den Registern, Flags und Ihren Offsets, sondern auch über sfr_Def.h zumindest die Grunddatentypen, so dass man ohne weitere Ergänzung das vom TO vorgestellte Stückchen Code zum Compilieren bewegen kann. Man könnte vielleicht sagen: Wenn's um ein paar Schleifenzähler und die Registerzugriffe in der Peripherie geht, dann reicht die io.h aus.

Es kommt ja beim TO auch kein Compile-Fehler. Nur der Debugger ist unwillig. Und da ist meine Erfahrung:
Schalte zuerst die Optimierung ab.

[LionAVR]

Zum jetzigen Zeitpunkt würde ich davon ausgehen, dass die beim Anlegen eines neuen Projektes voreingestellte Optimierungsstufe im Compiler Dein "i" einfach rauskickt. Die kannst Du aber in den Projekteigenschaften auf "None" stellen.
Dazu:
ALT+F7
dann Karteikarte Toolchain
auf <C oder C++>Compiler,
dann Optimization
da dann "None" auswählen.

Das Ergebnis der Aktion kannst Du dann auch im Listing in den unterschiedlichen Optimierungsstufen anschauen und vergleichen. Listing und Map-File landen nach dem kompilieren im Solution-Explorer unter "Output Files" als *.lss und * map. Und damit arbeitet auch der Debugger.

Kurz: Was in *.lss und *.map nicht drin steht, findet der Debugger nicht.

(Also hast Du auch nix falsch gemacht)

Nachtrag noch (für die anderen beiden Threadteilnehmer):
An den Includes kanns hier nicht liegen. Man kann, wenn man so ein Projekt offen hat, den Weg von IO.h zu StdInt.h in den jeweilig eingebundenen Headern verfolgen.
IO.h->sfr_Def.h->IntTypes.h->StdInt.h.
Entsprechend taucht die StdInt.h auch nach dem Kompilieren in den "Project Dependencies" auf, ohne dass man sie jemals selber direkt eingebunden hat.

Macht nix, ich will nicht klugscheißern, aber vielleicht habt Ihr was mitgenommen.

Vielen herzlichen Dank. Das hat mein Problem gelöst.
Auch danke an den beiden anderen Teilnehmern.

Viele Grüße,