PIC18F252, CCS-IDE 3.9

[Uli N. (uln)]

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)));

              }

[Uli N. (uln)]

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

[Michael D. (Firma: indEAS) (indeas)]

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.

[Uli N. (uln)]

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!

[Michael D. (Firma: indEAS) (indeas)]

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...

[Uli N. (uln)]

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.

[Niklas G. (erlkoenig)]

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...

[Uli N. (uln)]

> 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