TriCore: versage schon bei simplen Sachen

[Tim (Gast)]

Hallo,

fuer die Uni soll was auf einem Infineon TriCore 1796 programmieren.
Nur Versage ich schon bei den einfachsten Dingen, wie z.B.:

#include <stdio.h>
#define USERDEBUG

int main(void){
  printf("alles funzt\n");
  #ifdef USERDEBUG
    printf("debugging");
  #endif
  P0_IOCR0 = 0x80808080;
  P0_IOCR4 = 0x80808080;
  P0_IOCR8 = 0x80808080;
  P0_IOCR12 = 0x80808080;
  P0_OUT = 0x0000ffff;

  for(;;){
     __nop();
  }
  return 0;
}


da ist ja nun eigentlich keine Zauberei drin als einfach alle Pins von
Port0 anzuschalten. Leider bekomme ich nur vom Compiler (Altium
Tasking)

ctc E333: ["main.c" 10/11] incompatible types at assignment
ctc E333: ["main.c" 11/11] incompatible types at assignment
ctc E333: ["main.c" 12/12] incompatible types at assignment
ctc E333: ["main.c" 13/9] incompatible types at assignment
ctc W544: ["main.c" 18/2] unreachable code
4 errors, 1 warnings
wmk: *** action exited with value 1.


Nun frage ich mich einfach was ich bei diesem Geraet prinzipiell falsch
mache? Ich hab ja nun schon Atmels Programmiert, aber wieso diese
daemliche Meldung kommt weiss ich einfach nicht.

[Robert (Gast)]

Das ist wohl eher ein C als ein tricore Problem.

entweder es fehlt ein include file, oder deine Typen sind falsch. Guck
doch mal wo die P0_IO.. definiert sind.

[Tim (Gast)]

in diesem Tasking entwicklungumgebungsding hab ich die automatische
Einbindung von .sfr Dateien aktiviert. Da werden die ganzen Register
deklariert, z.B.:
#define P0_IOCR4 (*(P0_IOCR4_type*)  0xF0000C14u)  /* Input/Output
Control Register 4 */

typedef volatile union
{
  struct
  {
    unsigned int           : 4;
    unsigned int PC4        : 4;
    unsigned int           : 4;
    unsigned int PC5        : 4;
    unsigned int           : 4;
    unsigned int PC6        : 4;
    unsigned int           : 4;
    unsigned int PC7        : 4;
  } B;

  int I;
  unsigned int U;

} P0_IOCR4_type;

und er meckert ja auch nicht "unbekannter Name" sondern inkompatible
zuweisung.

[Wolfram (Gast)]

Du hast doch schon alles gefunden was du brauchst. Ich denke du weisst
es eigentlich. Du hast eine union vor Dir. Wie greift man in C auf eine
UNION zu?

[Tim (Gast)]

Stimmt, guter Tipp!

Waere da nie drauf gekommen, dass ich bei meinen Registern jetzt immer
mit .I .U .B indizieren muss.

Aber wieso machen die das? Ist doch voellig egal ob ich

Register.I = 0xffffffff
 oder
Register.U = 0xffffffff

schreibe?

Hoechstens wichtig wenn ich lese? Aber dann koennte ich doch z.B. einer
funktion namens

lesen(signed int)

sowohl register.I als Register.U uebergeben, wichtig ist doch, dass
lesen denkt es sein ein register.I? Aber der Compiler meckert dann,
oder?

[KlausT. (Gast)]

Hey Leute

ich mach mich auch an den 3core.

Nur weis ich noch nicht wie man den programmiert? OK es gibt das 
Starterkit. Aber was wenn ich den TC1130 in eine externe Schaltung 
setzen will? Womit kann ich den programmieren? Oder geht nur Jtag?

[KlausT. (Gast)]

jtag nur zum Debuggen?

[Fabian Scheler (Gast)]

Hallo zusammen,

also wir setzen hier den TriCore TC1796 seit ein paar Monaten 
erfolgreich an unserem Lehrstuhl ein, wir verwenden aber nicht den 
Tasking Compiler, sondern den GCC von HighTec. Ich habe hier ein paar 
Erfahrungen beizutragen, aber auch eine Frage:

Zum Thema eigene Schaltung:
alle TriCore-Derivate sind in BGA-Gehäusen unter gebracht, die in eine 
eigene Schaltung zu integrieren dürfte also schon ziemlich sportlich 
werden, wenn man kein professionelles Equipment zur Verfügung hat.

Zum Thema Debuggen:
der TriCore hat ein sog. OCDS (OnChip Debug System), also soetwas 
ähnliches wie ein JTAG, nur von Infineon :-) und die Eva-Boards von 
Infineon selbst haben auch alle einen Onboard-Wiggler, d.h. man kann die 
Teile einfach über die parallele Schnittstelle an flanschen und das Teil 
prinzipiell debuggen - man braucht aber noch etwas, das das 
OCDS-Protokoll in ein von irgendeinem Debugger unterstütztes Protokoll 
(z.B. für den GDB) umsetzt, die GNU Toolchain von HighTeC bringt hier 
einen sog. jtagserver mit. Das Debuggen mit dem GDB funktioniert zwar 
insgesamt sehr gut, ist aber für einen so komplexen Chip wie den TC1796 
schon etwas spartanisch, wir haben deshalb noch einen Lauterbach Trace32 
inkl. Tracer, d.h. man kann Instruktions-Traces mit Timestamps 
aufzeichnen lassen, zurück steppen (!!!), hat auch noch sehr einfach 
Zugriff auf alle möglichen Peripherie-Register ..., der Nachteil: das 
Teil hat ca. 10000 € gekostet, also für den Hobbyisten nicht 
erschwinglich, für ernsthafte Softwareentwicklung aber auf jedenfall 
lohnend.

Zum Thema Flashen:
Das Flashen über den Debugger (GDB und Trace32) laden zunächst über das 
OCDS ein Programm ins RAM des Controllers, das seinerseits die 
eigentlich Programmierung des Flash übernimmt, es ist also eine 
In-System-Programmierung. Prinzipiell kann der TC1796 auch von diversen 
Schnittstellen, wie z.B. seriell, CAN, etc. booten und man könnte sich 
überlegen, das Programm zum Flashen auf diese Weise zu laden. Wie man 
den TriCore aber "von außen" in den Zustand versetzt, dass er auf dieses 
spezielle Weise bootet, damit habe ich mich noch nicht beschäftigt, und 
weiß demzufolge auch nicht, ob das überhaupt klappt - abgesehen davon: 
man möchte das teil wirklich nicht alleine über eine LED debuggen, also 
kann man auch gleich über den Debugger Flashen (ich habe es allerdings 
noch nicht geschafft über den GDB Breakpoints im Flash zu setzen :-()

Meine Frage zum Thema Tasking:
Wie findest du bisher die Tasking Toolchain - viele Leute mit denen ich 
mich unterhalten habe, empfinden diese Toolchain als einzige Plage. Ist 
da mittlerweile das Linker-Skript-Format sauber dokumentiert?

Ciao, Fabian