Lasttests bei Industrial Ethernet

4. Dezember 2014, 11:11 Uhr | Von Bernd Westhoff, Marcus Tangermann und Frank Riemenschneider
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Ausblick

Lasttests werden in Zukunft ohne Zweifel Bestandteil jedes Freigabetests, wenn nicht sogar jeder Zertifizierung. Wichtig ist es dabei, nicht nur den einfachen Kommunikationsfall zu testen, sondern auch die Fehlerzustände im Netz zu simulieren.

Bei Profinet werden die Lasttests schon bald Bestandteil der Zertifizierung werden. Beim Netload-Test werden neben den RT-Daten unterschiedliche Protokolle zusätzlich in den Netzwerk-Traffic eingespielt, sowohl per Unicast und Broadcast als auch per Multicast. Dabei werden unterschiedliche Laststufen vom normalen Netzwerkverkehr bis hin zur Überlast im Netzwerk simuliert. Dies passiert abhängig von der gewünschten Leistungsklasse (Net Load Class).

Auch MCU- und Stack-Hersteller müssen hier ihre Hausaufgaben machen. Soft- und Hardware müssen für den Fehlerfall gerüstet sein, wie dies z.B. beim RX63N bereits der Fall ist.

Die vorherigen Abschnitte hörten sich für den ungeübten Anwender relativ kompliziert an. Für die ersten Schritte wird ein RSK (Renesas Starter Kit) RX63N empfohlen, da es zusammen mit dem Profinet Stack der Port GmbH als Ready-To-Go-Lösung sofortige Erfolge und eine schnelle Prototypen-Entwicklung ermöglicht. Die e2Studio-Entwicklungsumgebung integriert alle notwendigen Tools zum Erstellen und Debuggen der Software. Die Demoapplikation wird mit allen nötigen Projekt-Dateien ausgeliefert.

Auf dem RSK befindet sich die MCU RX63N mit 2 MB Flash-Speicher und 128 kB RAM. Diese Produktgruppe erzielt bei 100 MHz CPU- und Flash-Betrieb ohne Wait States eine hohe Rechenleistung. Um den Einsatz in den verschiedensten Produkten mit ihren verschiedenen Anforderungsprofilen zu ermöglichen, ist diese Produktgruppe sehr breit skalierbar. Es sind RX63N-Derivate mit integriertem Flash-Speicher von 512 kB bis 2 MB Flash und 128 kB bis 256 kB RAM verfügbar. Ebenfalls sind in Bezug auf die Gehäusevarianten LQFP, LGA wie auch BGA verfügbar.

RX-Core mit hoher Rechenleistung

Die 5-stufige CISC-Pipeline des RX600-Core erzielt 1,38 DMIPS/MHz.
Bild 3. Die 5-stufige CISC-Pipeline des RX600-Core erzielt 1,38 DMIPS/MHz.
© Renesas

Wie nicht anders zu erwarten, kann der RX-CISC-Core mit seiner 5-stufigen Pipeline (Bild 3) und Out-of-Order-Befehlsausführung den Cortex-M3/M4 von ARM mit seiner 3-stufigen Pipeline überholen: Renesas gibt in seinen Produktdatenblättern offiziell 1,65 DMIPS/MHz an – doch Vorsicht ist angebracht: Dieser Wert wird nur erreicht, wenn der Compiler im Inline-Modus betrieben wird, d.h. wenn bei Funktionsaufrufen der Code quasi ins Hauptprogramm kopiert wird, so dass der mit dem Aufruf von Funktionen verbundene Overhead (Registerinhalte und Programmzähler auf Stapel sichern, neuen Programmzähler laden usw.) entfällt.

Ohne Inline-Modus erreicht der RX-Core nur 1,38 DMIPS/MHz, was freilich immer noch über dem Wert eines Cortex-M3/M4 liegt, der es auf 1,25 DMIPS/MHz bringt. RX nutzt dazu eine verbesserte Harvard-Architektur. Harvard-Architekturen besitzen separate Speicherbereiche und Busse für Befehle und Daten, so dass Daten- und Instruktionszugriffe gleichzeitig ablaufen können. Von Nachteil bei der klassischen Harvard-Architektur ist, dass konstant bleibende Daten im Code-Bereich gespeichert werden und diese folglich nach einem Reset in den Daten-Bestand (in der Regel RAM) verschoben werden müssen. Dies verlängert die Zeit zum Hochfahren und vergeudet teuren RAM-Speicherplatz. Die klassische Von-Neumann-Architektur besitzt nur einen Speicherbereich/Bus für Code und Daten und umgeht damit diese Nachteile, ist dafür aber langsamer. Die RX-Erweiterungen vereinen das Beste aus beidem: RX benutzt separate Busse (für Code sogar 64 bit breit) mit gemeinsamem Speicherraum und ist damit so schnell wie Harvard, spart dabei aber RAM-Ressourcen wie nach von Neumann.

Neben der Ethernet-MAC-IEEE- 802.3-kompatiblen Schnittstelle mit MII- und RMII-Schnittstelle zum einfachen Anschluss an ein PHY gibt es auch CAN-2.0B-konforme Schnittstellen mit bis zu drei Kanälen (hier ist ebenfalls eine CANopen-Lösung von der Port GmbH verfügbar), zwei USB-Full-Speed-Hosts, USB-OTG- und Device-Funktionen.

Dipl.-Inf. Marcus Tangermann
ist beim Renesas Gold Alliance Partner Port GmbH für den Bereich Entwicklung zuständig und koordiniert die Weiterentwicklung der Protokoll-Stacks und der Entwicklungsdienstleistungen. Er hat sich als Software-Entwickler und später als Leiter R&D lange Zeit mit Industrial Ethernet auseinandergesetzt. 

mt@port.de


Dipl.-Ing. Bernd Westhoff
ist bei Renesas Electronics Europe für das RX-Produktmarketing innerhalb des Geschäftsbereichs ICBG (Industrial & Communication Business Group) verantwortlich.

Bernd.Westhoff@renesas.com



  1. Lasttests bei Industrial Ethernet
  2. Eine Frage der Architektur
  3. Ausblick

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Renesas Electronics Europe GmbH

Weitere Artikel zu Mikrocontroller