mikrocontroller.net

Forum: Compiler & IDEs PIC18F252, CCS-IDE 3.9


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Uli N. (uln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PIC18F252, CCS-IDE 3.9

Um überhaupt ein Debug-Mittel bei der Erweiterung eines Uralt-Systems 
zur
Hand zu haben, wollte ich in einem Fifo zwischengespeicherte Debug-Werte
alternierende zur Temperatur üner die serielle Schnittstelle ausgeben.

In einem ersten Schritt habe ich mal zwei Nibble meines ms-Timers 
ausgegeben
und schon damit Problem:

- gebe ich die beiden unteren Nibble des 16bit Return-Wertes aus, 
klappern
  auch die beiden Nibble auf der RS232-Leitung
- gebe ich aber die mittleren beiden Nibble aus (time = ((uint16_t) 
msTime()) >> 4;),
  klappert auf der RS232-Leitung nur noch der untere Nibble
- und gebe ich schließlich die oberen beiden Nibble aus ( >> 8 ),
  klappert gar nichts mehr, ich habe permanent die Ausgabe "@00".

Das Gleiche dann wiederholt mit einer lokalen statischen Variablen 
(tick), mit dem gleichen Ergebnis - wenn ich das ober Byte der 16bit 
Variable ausgebe ( >> 8), sehe ich auf der RS232-Leitung nur "@00" - 
überschreibe ich die berechneten Werte mit den Werten, die ich beim 
ersten Durchlauf erwarte, erhalte ich als Ausgabe auch "@12", das 
Problem muss also bei shift/and/or liegen! Sieht jemand meinen Fehler?
              static signed int tick = 0x1234;

              static uint8_t toggle = 0;

              tick += 7;

              toggle ^= 1;

              if (toggle)

              {

                  uint16_t time;

                  char h, l;
                  
                  //time = ((uint16_t) msTime()) >> 8;

                  time = ((uint16_t) tick);

                  time >>= 8;

                  h = (char) (((time >> 4) & 0xF) | 0x30);

                  l = (char) (((time >> 0) & 0xF) | 0x30);

                  //h = '1';

                  //l = '2';

                  tx_state_a[1] = '@';

                  tx_state_a[2] = h;

                  tx_state_a[3] = l;

                  //tx_state_a[2] = Conv4bitsToAscii(((char) ((time >> 4) & 0xF)));

                  //tx_state_a[3] = Conv4bitsToAscii(((char) ((time >> 0) & 0xF)));

              }


: Bearbeitet durch User
Autor: Uli N. (uln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Scheibenkleister - mein Compiler mag mich nicht!

Unter TDM-GCC kommt das raus, was ich erwarte!

Jemand eine Idee, was dem CCS-PIC18-Compiler an meiner Formulierung 
nicht gefällt?
i=00000 => @12
i=00026 => @12
i=00052 => @13
i=00078 => @14
i=00104 => @15
i=00130 => @15
i=00156 => @16
i=00182 => @17
i=00208 => @17
i=00234 => @18
i=00260 => @19
i=00286 => @1:
i=00312 => @1:
i=00338 => @1;
i=00364 => @1<
i=00390 => @1<
i=00416 => @1=
i=00442 => @1>
i=00468 => @1?
i=00494 => @1?
i=00520 => @20
i=00546 => @21
i=00572 => @21
i=00598 => @22
i=00624 => @23
i=00650 => @24
i=00676 => @24
i=00702 => @25

Autor: Michael D. (Firma: indEAS) (indeas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich es noch richtig im Kopf habe, dann ist der Maximalwert bei 
einem "char" im CCS Compiler 127 (dec).
Poste dein Problem doch einfach im CCS -Forum. Dort bekommst Du schnell 
eine Antwort.

Autor: Uli N. (uln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis - dort gab's schnell einen vielversprechenden 
Hinweis (konnte das noch nicht testen) - bei dem Compiler ist wohl "int" 
nur 8bit breit!

Autor: Michael D. (Firma: indEAS) (indeas)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Am sichersten du hängst an die int immer die passende Breite:
int8 x = 0; 
int16 y = 0;
....
Steht aber auch so in der Hilfe...

: Bearbeitet durch User
Autor: Uli N. (uln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verwende eigentlich immer die Typen aus "stdint.h", also int8_t, 
int16_t uint8_t, uint16_t, ..  -  nur liefert(e?) der CCS-Compiler keine 
stdin.h mit. weshalb ich sie selbst geschrieben habe und das ging halt 
in die Hosen! Mit einem 8bit int hatte ich nicht gerechnet.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uli N. schrieb:
> Mit einem 8bit int hatte ich nicht gerechnet.

Vor allem, weil der C-Standard mindestens 16bit verlangt. Wäre also 
nicht konform...

Autor: Uli N. (uln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Vor allem, weil der C-Standard mindestens 16bit verlangt.

So hatte ich es auch angenommen, war mir da jetzt aber nicht mehr sicher 
- lt. wikipedia ist es aber so:

https://en.wikipedia.org/wiki/C_data_types#Basic_types
bzw.
https://de.wikipedia.org/wiki/Datentypen_in_C#Integer

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.