R-IN32M3-CL (Cortex-M3): Wie funktioniert Senden/Empfangen auf dem Feldbus?

[Moe E. (moe_espunkt)]

Hallo Zusammen,

ich bin gerade dabei den Industrial Ethernet Controller "R-IN32M3-CL" 
der Firma Renesas zu verstehen und hoffe einwenig auf Unterstüzung, da 
ich noch blutiger Anfänger bin.
Ich habe den Controller(Evaluation Board: TS-R-IN32M3-CL) in mein 
Feldbus, namens "CC-Link", erfolgreich eingebunden und der Controller 
sendet zur SPS und empfängt von der SPS Daten. Für das Senden und 
Empfangen hat Renesas einen Samplecode zur Verfüfung gestellt. Der 
Samplecode beeinhaltet als Programmbeispiel ein "Loopback-Program" d.h., 
die Daten die zum Controller gesendet werden, sendet der Controller 
einfach wieder zurück zur SPS.

Man sieht im folgendem Quellcode (nur ein sehr kleiner Ausschnitt aus 
"main.c"! Vollständiger Code im Anhang),dass die Daten, welche empfangen 
wurden sind (ry_base) direkt wieder gesendet werden, in dem sie in 
"rx_base" reingeschrieben werden. Der Controller nimmt sich die Daten in 
rx_base und sendet sie.

void main_ccv10(void)
{
  int i, j;
  uint16_t *rx_base =  (uint16_t *)(&(RIN_CCLSLAVE->CCS_M3RMRX00_0F));//Daten senden
  uint16_t *ry_base =  (uint16_t *)(&(RIN_CCLSLAVE->CCS_M3MRRY00_0F));//Empfangene Daten

  /* Main loop */
  while (1) 
  { // Loopback sample 
    j = (occupied_station + 1) * 2; 
    for (i = 0; i < j; i ++) 
        {
           *(rx_base + i) = *(ry_base + i); 
        }
  }
}

Wobei "rx_base" und "ry_base" aus der Struktur "RIN_CCLSLAVE_TypeDef" 
stammen:

typedef struct
{
  __I  uint16_t  CCS_MWRENL_RCEX;      /*!< 0x0000h : Send data write enable information     */
  __I  uint16_t  CCS_M3STNO_BSW_KYOKU;            /*!< 0x0002h : Station number and Baud rate switch information */
  __I  uint16_t  CCS_M3ERR1_ERR2;      /*!< 0x0004h : Error information             */
       uint8_t  RESERVED1[2];        /*!< 0x0006h : Reserved                 */
  __I  uint16_t  CCS_M3MRST1_ST2;      /*!< 0x0008h : M ¨ R status information         */
  __I  uint16_t  CCS_M3MRRY00_0F;      /*!< 0x000Ah : M¨R  RY00-0F              */
  __I  uint16_t  CCS_M3MRRY10_1F;      /*!< 0x000Ch : M¨R  RY10-1F              */
  __I  uint16_t  CCS_M3MRRY20_2F;      /*!< 0x000Eh : M¨R  RY20-2F              */
  __I  uint16_t  CCS_M3MRRY30_3F;      /*!< 0x0010h : M¨R  RY30-3F              */
       uint8_t  RESERVED2[70];        /*!< 0x003Ah-7Fh : Reserved                */
  __IO uint16_t  CCS_M3SDOK_RDRQ;      /*!< 0x0080h : Send data write complete flag and Receive data read request */
  __IO uint16_t  CCS_M3VENDORCODE;      /*!< 0x0082h : Vendor code                   */
  __IO uint16_t  CCS_M3MODELCODE_VERSION;          /*!< 0x0084h : Model code and version          */
  __IO uint16_t  CCS_M3SDLED_TOVER;      /*!< 0x0086h : SDLED illumination time setting and Timeout time setting  */
  __IO uint16_t  CCS_M3RMST1_ST2;      /*!< 0x0088h : Cyclic Communication            */
  __IO uint16_t  CCS_M3RMRX00_0F;      /*!< 0x008Ah : R¨M  RX00-0F              */
  __IO uint16_t  CCS_M3RMRX10_1F;      /*!< 0x008Ch : R¨M  RX10-1F              */
  __IO uint16_t  CCS_M3RMRX20_2F;      /*!< 0x008Eh : R¨M  RX20-2F              */
  __IO uint16_t  CCS_M3RMRX30_3F;      /*!< 0x0090h : R¨M  RX30-3F              */
  __IO uint16_t  CCS_M3HOLDCLR;        /*!< 0x00BAh : HOLD/CLR Information Setting*/
       uint8_t  RESERVED3[5];        /*!< 0x00BB-BFh : Reserved                */
} RIN_CCLSLAVE_TypeDef;

Den Sende/Empfang-Frame habe ich mir mit CC-Link-Analyzer angeguckt 
(siehe Anhang). Was mich nun interessiert ist, wie  dieser Frame 
zustande gekommen ist, da ich selber solch einen Frame erstellen möchte. 
Der Controller muss diesen Frame ja irgendwie auch erst "entwerfen" und 
dann senden. Wie funktioniert das Senden und Empfangen im "absoluten" 
Ursprung?
Was ich auch sehr kurios finde ist, dass die Daten zwar bspw. im 
Strukturelement "CCS_M3MRRY00_0F" landen, aber es absolut keine 
Zuweisung dafür gibt?

Da der Controller auf einem ARM Cortex M3 basiert und die Headerdatei 
"core_cm3.h" eingebunden ist vermute ich, dass der Frame in "core_cm3.h" 
entworfen wird (bzw. in weiteren Headerdateien, die im "core_cm3.h" 
eingebunden werden.), dort habe ich zumindest die Funktionen 
"ITM_SendChar" und "ITM_ReceiveChar" gefunden, bei denen ich vermute, 
dass diese zum Senden/Empfangen beitragen. Sagen euch diese Funktionen 
etwas?

Abschließend meine eigentliche Frage: fallen euch Schlagwörter zum 
recherchieren ein hinsichtlich der Erstellung des Frames in dem Cortex 
M3 bzw. hat jemand eine Vermutung wo der Frameentwurf im Controller sein 
könnte? Oder weiß sogar jemand genau wie es funktioniert?

Ich habe den kompletten Programmcode als Textdatei beigefügt, falls sich 
jemand freundlicherweise die Mühe machen möchte. Sofern weitere 
Informationen/Headerdateien/Quellcodes gebraucht werden, kann ich 
selbstverständlich weitere hinzufügen.

Ich bedanke mich wirklich recht herzlich für jede Hilfe und möglichen 
Hinweis!

Viele Grüße
Moe Espunkt

[Moe E. (moe_espunkt)]

Ich merke, die Frage habe ich anscheinend zu kompliziert gestellt ...

[Konrad (Gast)]

Ohne diesen Renesas-uC zu kennen, vermute ich, dass RIN_CCLSLAVE_TypeDef 
das Speicherlayout der fuer CC-Link zustaendigen Register nachahmt. 
Schnapp Dir also das Referenzhandbuch dieses Mikrocontrollers und lies 
das Kapitel ueber CC-Link-Slavebetrieb. Dort werden hoffentlich diese 
Register beschrieben. (Ich hoffe, Renesas ist eine von den Firmen, wo 
man unkompliziert Entwicklerdoku herunterladen kann?)

Cortex M3 ist nur der eigentliche Prozessorkern (hat Renesas zugekauft 
von ARM), der allgemein Programme ausfuehrt; bei ARM wirst Du nichts zu 
CC-Link finden.

[Moe E. (moe_espunkt)]

Hallo Konrad,

erst einmal vielen Dank für deine Antwort!

Konrad schrieb:
> Ohne diesen Renesas-uC zu kennen, vermute ich, dass RIN_CCLSLAVE_TypeDef
> das Speicherlayout der fuer CC-Link zustaendigen Register nachahmt.

Wenn ich dich jetzt richtig verstanden habe meinst du , dass die 
eingehenden und ausgehenden Daten immer auf dem selben Speicherplatz 
abgelegt werden und die Struktur RIN_CCLSLAVE_TypeDef nur ein  Abbild 
von diesen Speicherplätzen ist? Klingt plausibel!

Renesas stellt realtiv viele Manuals für den Controller zur Verfügung, 
es werden auch die Register erklärt allerdings wird nicht erklärt wird 
die Datenübertragung im Detail funktioniert so, dass man eigene Frames 
schreiben kann und man diese versendet. Ziel ist es ein eigenes 
erstelltes Frame zur SPS zuschicken und dieses Frame mit dem Analyzer zu 
sehen.

Aber ich schaue nochmal genauer in den Manuals nach!Nochmals vielen Dank 
!! Vielleicht kommen noch weitere nützliche Hinweise von dir bzw. 
anderen.

______________________________________________________
Ergänzung: zu CC-Link gibt es lediglich ein Manual während es zu CC-Link 
IE Field ziemlich viele gibt.

[Konrad (Gast)]

> Wenn ich dich jetzt richtig verstanden habe meinst du , dass die
> eingehenden und ausgehenden Daten immer auf dem selben Speicherplatz
> abgelegt werden und die Struktur RIN_CCLSLAVE_TypeDef nur ein  Abbild
> von diesen Speicherplätzen ist? Klingt plausibel!

Janeejaa... hast Du schon mal auf einem Mikrocontroller programmiert? Es 
ist oft so, dass man mit einem Kommunikationsbaustein ueber irgendwelche 
Kontrollregister kommuniziert.

So ein UART beispielsweise hat oft einen Empfangs-FIFO, und wenn man 
(bzw das Programm, das auf dem Prozessorkern laeuft) das 
Empfangs-FIFO-Register ausliest durch Lesen an Adresse 0x123456, hat das 
den Seiteneffekt, dass der UART-Baustein danach dort das naechste Byte 
einblendet. Es sieht also aus, als waeren alle Bytes an derselben 
Stelle.

Fuer den CC-Link-Baustein ist das, was fuer Dein Programm wie 
Variable-Lesen aussieht, einfach irgendwelches Geflacker auf 
Adressleitungen, das er mit Geflacker auf Datenleitungen beantwortet. 
Mit Variablen hat das nicht mehr viel zu tun.

> Renesas stellt realtiv viele Manuals für den Controller zur Verfügung,
> es werden auch die Register erklärt allerdings wird nicht erklärt wird
> die Datenübertragung im Detail funktioniert so, dass man eigene Frames
> schreiben kann und man diese versendet. Ziel ist es ein eigenes
> erstelltes Frame zur SPS zuschicken und dieses Frame mit dem Analyzer zu
> sehen.

Dann versuch doch mal im funktionieren Beispielprogramm bei jedem 
Zugriff auf ein Register nachzulesen, wie dieses spezifiziert ist und 
welche Wirkung die Bits haben. So kannst Du vielleicht ein mentales 
Modell des CC-Link-Bausteins aufbauen.

> ______________________________________________________
> Ergänzung: zu CC-Link gibt es lediglich ein Manual während es zu CC-Link
> IE Field ziemlich viele gibt.

Ich kenn den Feldbus leider nicht; das passende Manual ist eins, bei dem 
irgendwo erzaehlt wird, was zB die einzelnen Bits von MWRENL_RCEX 
bedeuten.

[Moe E. (moe_espunkt)]

Hallo Konrad,

also du hast mir schon sehr weitergeholfen!

Konrad schrieb:
> hast Du schon mal auf einem Mikrocontroller programmiert?

"Ja", im rahmen einiger schlulischen Lehrveranstaltungen (7-8  mal à 90 
min) würde ich jedoch nicht als 
"habe-selber-mal-Controller-programmiert" einstufen. Da habe ich das 
erste mal einen Controller angefasst! Atmel ATMega, wernn ich mich recht 
erinnere.Sonderlich viel Erfahrung hab ich dennoch nicht, hat jedoch 
sehr spaß gemacht !

Konrad schrieb:
> Ich kenn den Feldbus leider nicht; das passende Manual ist eins, bei dem
> irgendwo erzaehlt wird, was zB die einzelnen Bits von MWRENL_RCEX
> bedeuten.

Hab das Manual gefunden und dort werden die ganzen Register und 
Strukturelemente erklärt. Mittlerweile kann ich auch die Frames 
manipulieren so, dass ich den veränderten Frame auf dem Analyzer sehe, 
in dem man die einzelnen Strukturelemente/Register setzt.

Es scheint so, als ob alles über das Setzen der Register funktionieren 
würde. Das ist sozusagen "die Frameerstellung" (zumindest so man 
Eindruck)

Ich bedanke mich recht herzlich für deine Bemühungen Konrad!

[Andreas S. (Firma: Renesas Electronics) (andreas_schwope)]

Hallo Moe,

ich möchte hier die Vermutung von Konrad noch einmal bestätigen.

Die Datenstruktur RIN_CCLSLAVE_TypeDef wird (wie andere Peripherals in 
RIN32M3_CL.h ab Zeile 219 auch) über die Basisadresse PERI_BASE und dem 
entsprechenden Offset direkt auf die Register der entsprechenden HW 
gemapped.

Hier ist dir in diesem Zusammenhang vielleicht auch schon etwas 
sonderbar aufgefallen: Mit merkwürdig anmutenden Konstrukten wie

  uint8_t  RESERVED2[70];

werden dann nicht genutzte Adressen im Adressraum des RIN_CCLSLAVE 
einfach "übersprungen", damit die nachfolgenden Definitionen innerhalb 
des TypeDef's wieder ihr passendes Register mappen.


Ein Zugriff (schreiben und lesen) auf die Datenstruktur erfolgt somit 
nicht auf eine Variable irgendwo im Speicher, sondern immer auf das 
entsprechende Register, das die HW des CC-Link Slave Controllers (als 
Beispiel für RIN_CCLSLAVE_TypeDef) zur Verfügung stellt.

> Mittlerweile kann ich auch die Frames
> manipulieren so, dass ich den veränderten Frame auf dem Analyzer sehe,
> in dem man die einzelnen Strukturelemente/Register setzt.

Wahrscheinlich hast du die Daten erst in eine "normale" 
Variablenstruktur eingelesen, manipuliert, dann in die Tx Register 
übertragen ... zumindest prinzipiell:

    for (i = 0; i < j; i ++) 
        {
           *(my_var_rx + i) = *(ry_base + i); 
        }

    process_data();

    for (i = 0; i < j; i ++) 
        {
           *(rx_base + i) = *(my_var_tx + i); 
        }

Viele Grüße,
  Andreas

[Moe E. (moe_espunkt)]

Hallo Andreas,

danke für die Antwort. Gibt es eine Möglichkeit einen eigenen Frame zu 
erstellen und den zu versenden!? Ich hatte im Manual gelesen, dass das 
ganze über einen CAN-Controller läuft (?) auf den ich leider keinen 
Zugriff habe.

[Andreas (Gast)]

Hallo Moe,

es gibt zwar auch noch einen CAN Controller auf dem Chip, aber die 
CC-Link Kommunikation wird über den CC-Link Controller abgewickelt. 
Daher sollte das Erzeugen und Verschicken eines CC-Link Frames über die 
CC-Link API / Treiber erfolgen.

Wo steht denn die Stelle mit dem CAN-Controller im Manual? Vielleicht 
haben wir ja einen Typo im dem Dokument ...

[Moe E. (moe_espunkt)]

Hallo Andreas,

ich verwede das Evaluation Board von Tessera und dort gehen die Pins vom 
CC-Link Connector direkt auf die Pins "P53" und "P54" des Controllers 
(siehe auch Bild). Wenn ich mir nun im Manual "Peripheral Function" 
anschaue, was die beiden Pins denn sind, dann sehe ich, dass die auf 
einen CAN-Controller gehen (auch hier, siehe Bild). Wo ist mein 
Denkfehler?

Um manuell einen CC-Link Frame zu erstellen wollte ich zuerst UART 
verwenden. Dies wird leider nicht funktionieren weil CC-Link "frame 
synchonisiert" arbeitet und nicht, wie beim UART " Startbit-Stopbit 
synchronisiert". Auch SPI wird kaum möglich sein, auf Grund der Clock: 
die Slavestationen im CC-Link Netzwerk antworten asynchron und somit 
wäre das Empfangen auf Basis von SPI kaum zu realisieren.
Daher wollte ich jetzt die Pins "P53" und "P54" als Output fungieren 
lassen (also nicht als "alternate function") und den Frame wirklich 
manuell im Programmcode erzeugen in dem ich jedes Bit einzeln setze. 
Jetzt ist natürlich die Frage ob die Performance des Controllers dafür 
ausreicht?

Übrigens, die Aufgabenstellung: Ich möchte CC-Linke IE Field und CC-Link 
gleichzeitig zum laufen bringen um somit dass Board als Gatewaymodule 
fungieren zu lassen; ich benutze das CC-Link IE Field Sampleprogram von 
Renesas und in diesem Programm möchte ich den CC-Link Connector des 
Boards verwenden und CC-Link Frames versenden.

Andreas schrieb:
> Daher sollte das Erzeugen und Verschicken eines CC-Link Frames über die
> CC-Link API / Treiber erfolgen.

Momentan erstellt der Controller die Frames und sendet diese 
automatisch. Genau das möchte ich jetzt übernehmen.  Könntest du mir 
kurz erklären wie ich diese API verwenden kann?

Vielen Dank für deine Hilfe.

[Andreas (Gast)]

Hallo Moe,

> Wo ist mein Denkfehler?

Der Trick liegt beim "Port Multiplexing". Hierbei kann ein Pin (oder 
eine Gruppe von Pins) mehrere Funktionen annehmen. Die Bezeichnung in 
den Dokumenten lauten "Shared Ports". Welche Funktion der einzelen Pins 
benutzt werden soll muß zuvor entsprechend per SW konfiguriert werden.

Die Übersicht aller Port Funktionen gibts im Data Sheet "r18ds0008ej". 
Insbesondere zeigt 2.3.16 die Übersicht aller CC-Link Ports. In der 
Tabelle in 2.3.5 sieht man, dass z.B. P53 für CRXD0 (CAN0 receive), 
CCS_RD (CC-Link Slave - Remote Device Station) und für CCM_RD (CC-Link 
Master - Intelligent Device Station) zuständig ist.

Wie die Ports dann auf die einzelnen Funktionen programmiert werden 
steht im R-IN32M3-CL User's Manual (r18uz0005ej), 7.3.3 Port Mode 
Control Registers und 7.3.4 Port Function control Registers. Figure 7.1 
zeigt recht anschaulich das Prinzip der komplexen 
Verschaltungsmöglichkeiten eines einzelnen Ports zu den verschiedenen 
Funktionen.


> Könntest du mir kurz erklären wie ich diese API verwenden kann?

Diese habe ich selber noch nie benutzt. Jedoch sollte eine entsprechende 
Anwendung des CC-Link Controllers aus dem entsprechenden 
Beispielprogramm auf

http://www.renesas.com/products/soc/assp/fa_lsi/multi_protocol_communication/r-in32m3/peer/sample_software.jsp

genügend Hinweise geben. Insbesondere befindet sich hier in main.c / 
CCLink_init() das erforderliche Setting der Ports für die CC-Link 
Benutzung.