mit Arrays aus Arrays lesen

Kenne Matlab nicht, aber das sollte eigentlich nie ein Problem sein 
(solange der Datentyp im Array stimmt...).
Ansonsten: Was "nörgelt" er denn?

>kann ich mit nem eindimensionalen Array aus einem zweidimensionalen
>lesen?

Zunächst ist ein Array nichts aktives. Es kann also nicht lesen. Es kann 
vielmehr als Quelle oder Ziel einer Leseoperation dienen.

>MPLAB nörgelt rum
Hier fehlt die Fehlermeldung!

1

canTxMessage.data[0]=((profil_time_2[ profil_zuw[j] ][ i*4+0 ]) & 0xFF);

>könnte es daran liegen

Aus der Fehlermedlung sollte hervorgehen auf welche Zeile sie sich 
bezieht.
Die gezeigte Zeile ist syntaktisch korrekt aber das heisst ja noch 
nicht, das sie das auch semantisch ist.

canTxMessage.message_type=CAN_MSG_DATA;
canTxMessage.frame_type=CAN_FRAME_STD;  canTxMessage.buffer=0;
canTxMessage.id=((slave_adressen[j])<<6|(0x8)<<3); 111 000
canTxMessage.data[0]=((profil_time_2[profil_zuw[j]][i*4+0]) & 0xFF);
canTxMessage.data[1]=(((profil_time_2[profil_zuw[j]][i*4+0])&0xFF00)>>8) 
;
canTxMessage.data[2]=((profil_time_2[profil_zuw[j]][i*4+1]) & 0xFF);
canTxMessage.data[3]=(((profil_time_2[profil_zuw[j]][i*4+1])& 
0xFF00)>>8);
canTxMessage.data[4]=((profil_time_2[profil_zuw[j]][i*4+2]) & 0xFF);
canTxMessage.data[5]=(((profil_time_2[profil_zuw[j]][i*4+2])&0xFF00)>>8) 
;
canTxMessage.data[6]=((profil_time_2[profil_zuw[j]][i*4+3])&0xFF);
canTxMessage.data[7]=(((profil_time_2[profil_zuw[j]][i*4+3])&0xFF00)>>8) 
;canTxMessage.data_length=8;             //send a CAN message
sendECAN(&canTxMessage);

das soll er abschicken,alle arrays sind als int definiert.das Programm 
ist MPLAB von Microchip (dspic33f)

die fehlermeldung lautet:

functions.c:367: warning: passing argument 1 of 'sendECAN' discards 
qualifiers from pointer target type

und er spuckt ein wirrwarr von angeblich doppelt definierten variablen 
aus, aber eben genau die , die ich in dem sendepaket benutze...

beste grüße!

>functions.c:367: warning: passing argument 1 of 'sendECAN' discards
>qualifiers from pointer target type

Du hast an die Funktion einen Parameter übergeben der andere Qualifierer 
hat als der deklarierte Parameter der Funktion. Das ist manchmal nicht 
zu vermeiden, aber auch nur eine Warnung und keine Fehlermeldung. 
Trotzdem sollte man das wenn möglich vermeiden. Leider fehlt hier die 
Deklaration der Funktion und die des Parameters.

>und er spuckt ein wirrwarr von angeblich doppelt definierten variablen
aus, aber eben genau die , die ich in dem sendepaket benutze...

Nein! Er spuckt kein "Wirrwar" aus sondern sagt genau wo die doppelte 
Definition auftritt und bei den Compilern die ich kenne, verweist er 
auch auf die erste Definition. Ausserdem sind keine "angeblich" doppelt 
definierten Variablen sondern tatsächlich doppelte. Gewöhn Dir ab zu 
denken Du seist schlauer als der Compiler, jedenfalls in Bezug auf solch 
primitive Fälle.

Danke für die antwort, ja tut mir leid das ich das so forsch sage.
er gibt ime "wirrwarr" aber nicht die genauen reihen an, sondern nur die 
datei, z.b.:

init_.o(.nbss+0x0):C:\...\init_.c: multiple definition of `profil_load'
functions.o(.nbss+0x0):C:\...\functions.c: first defined here
.
.
.

die funktion lautet:

void sendECAN(mID *message)
{
  unsigned long word0=0;
  unsigned long word1=0;
  unsigned long word2=0;

  /*
  Message Format:
  Word0 : 0bUUUx xxxx xxxx xxxx
           |____________|||
           SID10:0   SRR IDE(bit 0)
  Word1 : 0bUUUU xxxx xxxx xxxx
              |____________|
            EID17:6
  Word2 : 0bxxxx xxx0 UUU0 xxxx
        |_____||       |__|
        EID5:0 RTR       DLC

  Remote Transmission Request Bit for standard frames
  SRR->  "0"   Normal Message
      "1"  Message will request remote transmission
  Substitute Remote Request Bit for extended frames
  SRR->  should always be set to "1" as per CAN specification

  Extended  Identifier Bit
  IDE->   "0"  Message will transmit standard identifier
         "1"  Message will transmit extended identifier

  Remote Transmission Request Bit for extended frames
  RTR->   "0"  Message transmitted is a normal message
      "1"  Message transmitted is a remote message
  Don't care for standard frames
  */

  /* check to see if the message has an extended ID */
  if(message->frame_type==CAN_FRAME_EXT)
  {
    /* get the extended message id EID28..18*/
    word0=(message->id & 0x1FFC0000) >> 16;
    /* set the SRR and IDE bit */
    word0=word0+0x0003;
    /* the the value of EID17..6 */
    word1=(message->id & 0x0003FFC0) >> 6;
    /* get the value of EID5..0 for word 2 */
    word2=(message->id & 0x0000003F) << 10;
  }
  else
  {
    /* get the SID */
    word0=((message->id & 0x000007FF) << 2);
  }
  /* check to see if the message is an RTR message */
  if(message->message_type==CAN_MSG_RTR)
  {
    if(message->frame_type==CAN_FRAME_EXT)
      word2=word2 | 0x0200;
    else
      word0=word0 | 0x0002;

    ecan1msgBuf[message->buffer][0]=word0;
    ecan1msgBuf[message->buffer][1]=word1;
    ecan1msgBuf[message->buffer][2]=word2;
  }
  else
  {
    word2=word2+(message->data_length & 0x0F);
    ecan1msgBuf[message->buffer][0]=word0;
    ecan1msgBuf[message->buffer][1]=word1;
    ecan1msgBuf[message->buffer][2]=word2;
    /* fill the data */
ecan1msgBuf[message->buffer][3]=((message->data[1] << 8) + 
message->data[0]);
ecan1msgBuf[message->buffer][4]=((message->data[3] << 8) + 
message->data[2]);
ecan1msgBuf[message->buffer][5]=((message->data[5] << 8) + 
message->data[4]);
ecan1msgBuf[message->buffer][6]=((message->data[7] << 8) + 
message->data[6]);
  }
  /* set the message for transmission */
  C1TR01CONbits.TXREQ0=1;
}




mit dem struct:


typedef struct{
  /* keep track of the buffer status */
  unsigned char buffer_status;
  /* RTR message or data message */
  unsigned char message_type;
  /* frame type extended or standard */
  unsigned char frame_type;
  /* buffer being used to send and receive messages */
  unsigned char buffer;
  /* 29 bit id max of 0x1FFF FFFF
  *  11 bit id max of 0x7FF */
  unsigned long id;
  unsigned char data[8];
  unsigned char data_length;
}mID;



danke im vorraus

Heini schrieb:
> Danke für die antwort, ja tut mir leid das ich das so forsch sage.
> er gibt ime "wirrwarr" aber nicht die genauen reihen an, sondern nur die
> datei, z.b.:
>
> init_.o(.nbss+0x0):C:\...\init_.c: multiple definition of `profil_load'
> functions.o(.nbss+0x0):C:\...\functions.c: first defined here

Die Fehlermeldung kommt nicht vom Compiler, sondern vom Linker. Du hast 
in der Datei init_.c irgendetwas mit Namen "profil_load" definiert und 
in der Datei functions.c auch nochmal.

> die funktion lautet:
>
> void sendECAN(mID *message)
> {

Wie kommst du jetzt darauf, daß diese Funktion etwas damit zu tun hat? 
In dem gepostetend Code kommt nirgends eine Definition von etwas mit 
Namen "profil_load" vor.

Danke für die antworten!
hab beim antworten auf die antwort durch ausprobieren festgestellt, das 
die 4 arrays die probleme machten NICHT volatile seien dürfen, warum 
auch immer.
jetzt kann ich das nächste Problem bearbeiten!

Danke allen!

dlee schrieb:
> Kenne Matlab nicht
Matlab != MPLAP ;-)

Heini schrieb:
> das die 4 arrays die probleme machten NICHT volatile seien dürfen
= sehr mystisch.
Wenn du dir da mal nicht das nächste Problem einfängst.
'volatile' richtet eigentlich keinen Schaden an. Die Ursache für die 
Warnungen könnte sein, dass der Zeiger nicht als 'volatile' deklariert 
ist:
Heini schrieb:
> functions.c:367: warning: passing argument 1 of 'sendECAN' discards
> qualifiers from pointer target type
Es kann auch sein, das die Variablen gar nicht 'volatile' sein müssen, 
dann funktioniert deine Änderung natürlich...

@Ole... ja, verlesen... kenne ich aber auch nicht, also "egal" ;)

Ralf schrieb:
> Heini schrieb:
>> das die 4 arrays die probleme machten NICHT volatile seien dürfen
> = sehr mystisch.
> Wenn du dir da mal nicht das nächste Problem einfängst.
> 'volatile' richtet eigentlich keinen Schaden an. Die Ursache für die
> Warnungen könnte sein, dass der Zeiger nicht als 'volatile' deklariert
> ist:

Die Ursache ist, daß die Funktion einen Zeiger auf nicht-volatile 
erwartet.

Rolf Magnus schrieb:
> Die Ursache ist, daß die Funktion einen Zeiger auf nicht-volatile
> erwartet.
Das meinte ich auch. Allerdings sollte man verstehen, warum man etwas 
macht und nicht bloß rumprobieren. Falls irgendwann mal wieder so eine 
Warnung auftaucht, könnte es sein, dass die Variable 'volatile' sein 
muss. Dann muss man den Zeiger ändern!