[Semi-OT] PIC24FJ64GA202 Headerfile für peripheral features?

ja, gibts ja nicht für Linux, deswegen auf Windows, aber auch da ist das 
File """C:\Program Files (x86)\Microchip\xc16\v1.24 _
\support\peripheral_24F\PIC24F_periph_features.h""" vom 1.9.2014 (sic!) 
und hat natürlich die neue MCU Familie nicht drin. Eine andere Version 
hab ich nicht gefunden.

Hat jemand ein neueres? Und könnte darin vielleicht mal nach einem 
Define für die MCU oben suchen? Danke.

Chris schrieb:
> das Forum hat leider nur ein GCC Forum, hoffe, man verzeiht mir das
> Semi-OT. Ich hab eine Schwierigkeit mit dem offiziellen PIC (1.24)
> Compiler für die 16Bit MCus. Und zwar fehlt in dem File
> PIC24F_periph_features.h eine #define Sektion für den genannten
> PIC24FJ64GA202, die ganzen Makros für alle Peripherals sind also nicht
> verfügbar.

Da fehlt nichts, die sind alle da.

man muß nur 1. beim Projekt den richtigen Prozessor angeben. Wenn dein 
Prozessor dabei ist (bei mir findet ich ihn in der Auswahl-Liste) ist 
alles gut.

Dann 2. ein #include "xc.h" in den source, so wie es auch automatisch 
generiert wird, fertig. Der richtige File (p24FJ64GA202.h) wird 
automatisch angezogen.

Übrigens, XC16 ist der GCC

MfG Klaus

> Da fehlt nichts, die sind alle da.
Magst Du Dir die Mühe machen, einmal in Deinem PIC24F_periph_features.h 
nach dem PIC24FJ64GA202 zu suchen? In meinem ist da nichts drin. Falls 
Du was findest, magst Du mir das zur Verfügung stellen?

> man muß nur 1. beim Projekt den richtigen Prozessor angeben.
Hab ich doch :) Und ja, er findet ihn.

> Dann 2. ein #include "xc.h" in den source [...]
Hab ich doch auch, und das ...202.h wird auch eingebunden.
Nur Calls wie

1

  mPORTBOutputConfig(...);

2

  mPORTBSetBits(...);

3

  mPORTAClearBits(...);

4

  // LATB  = ...; geht natürlich

5

  // TRISB = ...; geht natürlich

usw. schlagen fehl, weil die entsprechenden Features eben in der Datei 
..._features.h ausgewählt werden. Und das haben die Micro-Chipler noch 
nicht erledigt.

Und bevor ich jetzt meinen ganzen Code, der die Lib von Microchip 
extensiv benutzt, umschreibe, dacht ich, ich frag mal, vielleicht hatte 
das Problem ja schon mal jemand. Danke trotzdem.

Chris schrieb:
> Hab ich doch auch, und das ...202.h wird auch eingebunden.
> Nur Calls wie  mPORTBOutputConfig(...);
>   mPORTBSetBits(...);
>   mPORTAClearBits(...);
>   // LATB  = ...; geht natürlich
>   // TRISB = ...; geht natürlich
> usw. schlagen fehl, weil die entsprechenden Features eben in der Datei
> ..._features.h ausgewählt werden. Und das haben die Micro-Chipler noch
> nicht erledigt.
>

Das kannte ich nicht. Hat mir aber noch nie gefehlt. Ein PORT, ein Bit 
oder ein Bitfeld kann ich selber setzen.

Was mir aber aufgefallen ist, die Sachen sind ja noch aus der C30 (MPLAB 
ohne X) Zeit, das ist ja nun schon ein paar Jahre alt. Ob da noch mal 
etwas neues kommt? Für die neueren PIC24H oder PIC24E finde ich noch 
nicht mal die Directories.

MfG Klaus

Chris schrieb:
> ja, gibts ja nicht für Linux, deswegen auf Windows, aber auch da
> ist das

ich komm da jetzt nicht mit, was du meinst. Also den Patch gibt es auf 
jedem Fall auch für Linux.

Chris B. schrieb:
> In dem Headerfile befinden sich diese Definitionen auch nicht und meines
> Wissens, waren die auch nie dort drinnen.
> Diese Definitionen findest du in:
> ....v1.24/support/peripheral_24F/ports.h

Und da es etwas wie .../peripheral_24H/ oder .../peripheral_24E/ nicht 
gibt, vermute ich Obsolenz.

MfG Klaus

Frank K. schrieb:
>> Und da es etwas wie .../peripheral_24H/ oder .../peripheral_24E/ nicht
>> gibt, vermute ich Obsolenz.
>
> oder dafür nimmt man die Ordnern für dspic33f bzw dspic33e.
>
> fchk

Wo es irgendwas mit peripheral... oder PORTBSetBits() oder einen von den 
anderen erwähnten Macros gar nicht gibt. Da finden sich nur die Standard 
.h Files für die Chips, die dem TO nicht reichen. Hilft ihm also nicht.

MfG Klaus

Also ich finde das folgende bei mir 1.24 unter linux nur in ports.h
"mPORTBOutputConfig"

Ein wenig OT:

wann ist es eigentlich Sinnvoll, solche Konstrukte wie in ports.h zu 
verwenden?

#define mPORTAOutputConfig(outputs)         { TRISA &= ~(unsigned 
int)outputs; } /*Configures PortA as output*/

Ok, ein bißchen Clarification, was afaik welche Datei tut =)

* PIC24F_periph_features.h: Gibt an, welche MCU welche Pheripherals
  besitzt und, über wahnsinnig schwer zu lesende Namen ("crc_v1_1"), auf
  welchen Adressen die sitzen, um sie letztlich diesen PIC Makros zur
  Verfügung zu stellen.

* p24Fxxxx.h: Selektiert anhand der Project-Settings die richtige MCU
  Header-Datei, in welcher natürlich die peripherals beschrieben werden.
  Muß man nicht extra einbinden, macht die obige Datei automatisch.

* PIC24F_plib.h: Ist, wie der Name vermuten läßt, die optionale
  Peripheral Library, die mir diese C Makros an die Hand gibt, mit
  der der Code leserlicher wird.

1

  // Das ist doch was feines :)

2

  OpenTimer3((T3_ON|T3_IDLE_CON|T3_PS_1_8|T3_SOURCE_INT), 8000);

Nun muß man aber in der PIC24F_plib.h die richtigen Makros für seine MCU
aktivieren, was eben in der PIC24F_periph_features.h für jeden Prozessor
von Microchip eingetragen wird. Außer eben für diese ganz neuen, die
sind da noch nicht drin. Daher die Frage, ob sich jemand schon einmal
die Mühe gemacht hatte, über Try/Error die richtigen Makros zu finden.

Im Update vom Februar sind sie noch nicht drin.

Chris schrieb:
> Daher die Frage, ob sich jemand schon einmal
> die Mühe gemacht hatte, über Try/Error die richtigen Makros zu finden.

Gut dann zur Klarstellung: ich habe gesucht, zwar nicht mit Try/Error 
sondern mit z.B. grep, aber nichts gefunden. Ich habe aber auch nichts 
entsprechendes für (die neueren) PIC24H oder PIC24E gefunden. Dafür habe 
ich in allen passenden Files für PIC24F einen Hinweis auf C30 gefunden. 
Der Compiler heißt aber schon ein paar Jahre XC16. Aus beiden Hinweisen 
rührt meine Vermutung, daß es diese Files bzw Macros nicht gibt und auch 
nicht geben wird, sie also obsolete sind.

MfG Klaus

> Aus beiden Hinweisen rührt meine Vermutung, daß es diese Files
> bzw Macros nicht gibt und auch nicht geben wird, sie also
> obsolete sind.

Nein, die Makros gibt es. Sie sind definiert in den folgenden
Dateien:

1

#include <adc.h>, <comparator.h>, <crc.h>, <ctmu.h>, [...], <wdt.h>

Was fehlt, ist die Zuordnung zur jeweiligen MCU. Hier beispielhaft 
einmal für PIC24FJ48GA002, wie in der _periph_features.h eingetragen:

1

#ifdef   __PIC24FJ48GA002__

2

/*############################################################*/

3

/*          Configuration for device =  'PIC24FJ48GA002'      */

4

/*############################################################*/

5

#define adc_v1_1

6

#define cmp_v1_1

7

#define cn_v1_1

8

#define int_v1_1

9

#define icap_v1_2

10

#define i2c_v1_2

11

#define spi_v1_2

12

#define ocmp_v1_2

13

#define port_v1_1

14

#define pwrmgnt_v1_1

15

#define tmr_v1_2

16

#define uart_v1_1

17

#define pmp_v1_1

18

#define pps_v1_1

19

#define crc_v1_1

20

#define rtcc_v1_1

21

#define wdt_v1_1

22

#define sram_v1_1

23

#endif

Und diese Zuordnung jetzt für den PIC24FJ64GA202 zu haben wäre ein 
Traum. Ich weiß ja, daß der einen ADC hat. Aber nicht, ob ich den jetzt 
mit adc_v1_1 oder mit adc_v1_2 aktivieren muß. Wo sind z.B. zwischen 
diesen beiden defines die Unterschiede? Und wie finde ich das für alle 
anderen peripherals (CTMU,...) heraus?

Danke.

Chris schrieb:
> Und diese Zuordnung jetzt für den PIC24FJ64GA202 zu haben wäre ein
> Traum. Ich weiß ja, daß der einen ADC hat. Aber nicht, ob ich den jetzt
> mit adc_v1_1 oder mit adc_v1_2 aktivieren muß. Wo sind z.B. zwischen
> diesen beiden defines die Unterschiede? Und wie finde ich das für alle
> anderen peripherals (CTMU,...) heraus?

Daß es ein Macro mit deinem gewünschten Namen irgendwo gibt, ist 
unbenommen. Es gibt aber offensichtlich keins für deinen Wunschchip. Es 
gibt soviele (manchmal nur leicht) unterschiedliche ADC bei den PIC24 
(mit oder ohne threshold detect, mit oder ohne DMA, ...), daß ich mir 
kaum vorstellen kann, daß da zwei verschiedene Macros reichen. Es gibt 
ja zusätzlich zu den Chipdatenblättern noch mehrere Family Reference 
Manuals für jede Peripherie. Du wirst also mit einfachem Zuordnen nicht 
auskommen sondern sie im Zweifel komplett neu erfinden müssen.

Und selbst wenn ich soetwas in Form eines Headerfiles gebastelt hätte, 
würde ich es nicht veröffentlichen. Ich hätte dann ja auf ewig 
(mindestens moralisch) den Support dafür am Hals, der eigentlich nichts 
als Ärger einbringt. Du hast dir ja selbst noch nicht mal die Mühe 
gemacht, den wirklichen Unterschied zwischen adc_v1_1 und adc_v1_2 
herauszuarbeiten.

MfG Klaus