Profibus DP-Slave Kommunikation in C
Von Jörg S., Marc H. und Johannes F.

Geschrieben für MSP430F2252. Getestet an Siemens S7 mit 19,200 und 
93,750kBit/s.
Basis war Reengineering der Kommunikation eines DP/DP Kopplers mit einer 
S7 und vor allen das Profibus Handbuch von Prof. Max Felser (ein 
Dankeschön an dieser Stelle).

Die Entwicklung begann mit kompletter Ahnungslosigkeit vom Profibus. Von 
daher ist der Code ständig verändert und erweitert worden und somit 
nicht unbedingt ein Ingenieurs-Glanzstück ;)
Der DP-Slave ist soweit Profibus konform das normale I/O Daten gesendet 
und empfangen werden können, da der Fokus auf diesem Aspekt lag.

Und noch die h-Datei...

abo

>1. wie stark ist der uC ausgelastet (flash und performance) > gehts noch
>schneller / ist noch platz für andere applikationen?
Er muss halt alles empfangen was los ist und erst dann auswerten ob es 
wirklich für ihn ist. Da empfangen und senden interruptgesteuert ist, 
hat der µC viel Zeit was anderes zu machen. Im speziellen Fall wird noch 
ein 2x16 Zeichen Display mit 4 Tasten, IR Empfänger und Temp.Sensor 
(TSic) "nebenbei" behandelt.
Der MSP läuft auf 8Mhz und hat 16kB FLASH und 512B RAM. Der Profibus 
verbraucht glaub ich um die 2kB FLASH und wohl um die 130B RAM. Wobei 
der RAM Verbrauch fast zu 100% aus den Ein- und Ausgangsregistern und 
dem UART Buffer besteht.
Kommunikation geht sicherlich noch schneller, hab ich aber noch nicht 
getestet da die aktuelle Geschwindigkeit erst mal ausreichend ist.

>2. warum dieser uC (habt ihr einen komerziellen / universitären
>Hintergrund)?
Ich habe vor allem beruflich mit dem MSP430 zu tun, hab aber auch schon 
vorher damit privat gearbeitet. Von daher kam nur der MSP in Frage :)
Das Projekt ist privat.

>3. wie habt ihr die parametresierung der s7 gemacht?
Über den Part kann ich wenig sagen, da kennen sich die anderen zwei 
"Mitstreiter" aus. Es muss halt ne GSD Datei für den Slave angelegt 
werden mit der man die Grundparameter festlegt.

>4. was für treiber habt ihr genommen und wie habt ihr die
>abschlusswiderstände dimensioniert?
RS485 Transceiver ist der MAX3485. Abschlusswiderstand ist 120Ohm 
vorgesehen. Halt Standard RS485...

>5. was für eine applikation habt ihr hiermit realisiert?
Hausautomation. Ich denke da wird es dann noch ne komplette 
Projektvorstellung geben, die Entwicklung ist aber noch nicht wirklich 
abgeschlossen.

>6. habt ihr schon bugs gefunden?
Das einzige was mir einfällt ist die MS1/2 Kommunikation. Wenn sowas 
mitläuft geht nix mehr, das wird wohl die nächste Erweiterung sein die 
rein kommt.

Auf Seite 23 der von dir benannten Datei von Max Felser 
(http://www.profibus.felser.ch/technik/PROFIBUS_Technik.pdf) ist 
beschrieben,  das die Terminierung im Stecker realisiert wird.

Aber sonst finde ich es wirklich interessant! Die einzige realisierung 
auf einem uC die ich kenne ist diese: 
http://www.htw-dresden.de/fe/labor/mikror/projects/pb_slave/
Diese ist jedoch leider auf ASM geschrieben...

Habt ihr eine Testhardware gebaut oder könnt ihr eine Applikation damit 
als Demo zeigen?

Eine Frage habe ich noch!
Handelt es sich um DPV0(zyklisch), DPV1(azyklisch), DPV2(isochron)?

>das die Terminierung im Stecker realisiert wird
Wenn man so einen Profibus Stecker nutzt... Muss man ja nicht.

>Habt ihr eine Testhardware gebaut oder könnt ihr eine Applikation damit
>als Demo zeigen?
Im Anhnag mal die "SPS-Remote" Einheit. Damit soll man dann in jedem 
Zimmer die Heizung, Rolladen, Wecker usw. steuern. Funktioniert so weit 
schon im Testaufbau.

>Handelt es sich um DPV0(zyklisch), DPV1(azyklisch), DPV2(isochron)?
DPV0

Im Anhang die nächste Stufe, die SPS-AudioControl zur umschaltung von 
Audio Signalen für die Deckenbeschallung der Räume. Ansonsten gibt's 
dann  noch die Dimmersteuerung. Da hab ich aber gerade kein Bild von.

>1. hast Du es auch an einer S7-300 getestet?
Wenn ich mich nicht täusche wird das an einer S7-315 CPU betrieben. Was 
anderes wäre nicht ohne weiteres zur Hand.

>2. Wie sieht Dein physikalisches Interface aus?
Also Profibus ist RS485 wenn du das meinst? A, B von Profibus an den 
MAX3485 Transceiver und dann halt auf den UART vom MSP430.

>2) zielte darauf ab, ob Du mit einem käuflichen Siemens-Adapter arbeitest.
Dann wäre es ja nichts besonderes, oder? ;)

Wenn du jetzt noch eine Demo-Software hättest... ach wäre das schön ;)

Ne jetzt mal ganz im ernst! Ich finde es wirklich prima was ihr da auf 
die beine gestellt habt!!!
Aber gerade im bereich Hausautomatisierung denke ich das es andere 
Schnittstellen (CAN/CANopen) gibt die sich im gegensatz zu propritären 
systemen etabliert haben. Das soll euch um gottes willen nicht davon 
abhalten weiter zu machen! So ein ASIC für Profibus ist nämlich super 
teuer.

>Wenn du jetzt noch eine Demo-Software hättest...
Du meinst die SPS Software?

>welche E/A's ansprechbar sind
Wie meinst du das? Die E/As werden halt für Sachen wie Raumtemperatur, 
Aussentemperatur, Solltemperatur (Heizung), Weckzeit Wochentag, Weckzeit 
Samstag, Weckzeit Sonntag, Rolladen Steuerung, SPS Uhrzeit und sowas 
"misbraucht". Physikalische I/Os werden zumindest bei der SPS-Remote 
nicht gesetzt.

Marc will dann noch genauer was zu der GSD Datei schreiben.

>Naja, auf dem Bild sind u.a. 4 Taster zu sehen. Da könnte man ja auf die
>Idee kommen, dass das Eingänge sind, die an die SPS weitergeleitet
>werden...
Die Tasten sind nur für die Menü-Steuerung vom Gerät, die SPS bekommt 
davon nichts mit.

>Kommt da immer ein Bytehaufen mit der Länge 32 an, den man selbt
>auseinander nehmen muss/kann?
Genau das, ja.

>Da ist am UART des Controllers nur ein RS485-Baustein angeschlossen und
>dieser hängt dann direkt am Profibus, richtig?
Genau, alles Standard RS485 Technik.

Und nur für Profis ;) Wenn das PROFI im PROFIBUS keine Abkürzung wäre, 
würde ich Lachen ;)

>gibt es zu Eurem Projekt auch eine zusammenfassende Dokumentation /
>Website?
Nö :) Gibt aber noch einen kleinen "Schwesterthread" im SPS-Forum:
http://www.sps-forum.de/showthread.php?t=15510

Wie gesagt ist das Projekt ja auch noch nicht abgeschlossen. Von daher 
werden ich auch (vorerst) keine Schaltpläne o.ä. einstellen. Fragen zur 
Hardware dürfen aber natürlich gestellt werden.

>Wärst Du bereit hierzu die Schaltpläne & Board (insb. Dimension-Layer),
>sowie Befestigungsmöglichkeiten offen zu legen?
Das mit den Schaltplänen hatte ich ja schon gesagt.
Bezüglich Befestigungsmöglichkeiten dürfte sich das Problem stellen das 
wir Tragringe von HEWI bzw. Berker verwendet haben die ich bei uns in 
der Firma aus dem Schrott geholt habe und die man wohl sonst nicht im 
freien Handel bekommt. Alternative wäre evt. der Tragring 12700 von 
Gira. Dafür müsste man das Layout aber ändern, von daher würden meine 
Dimensions wohl nicht sonderlich helfen.

>Tragring 12700 von Gira.
Berichtigung: Muss 112700 heissen.

>es gibt noch gira tragring AMP steckbar 019100 ca.3€
>oder einfach eine normale steckdose für 2€ und den rest in den müll ;-)
Da muss man dann aber erst mal schnitzen bis man was brauchbares hat.

Hier mal die Rückseite der SPS-Remote.
Wie man sehen kann bietet dieser Tragring schön viel Platz für 
rückseitige Bauteile.

Links der RS485 Transceiver, mittig der MSP430 mit 8MHz Resonator, unten 
der 8-polige JTAG Stecker, mittig der 6-polige RS485 Stecker (VCC, 2xA, 
2xB, GND), rechts 3,3V Spannungsregler.

Habt Ihr für die SPS Remote auch eine schöne Verkleidung für die Front 
entwickelt oder bleibt das so pur? Frage wegen der 
Frauen-Design-Akzeptanz.

:) Da soll eine Blindabdeckung passend ausgefräst werden.

>wie kann bei Euch die Slave-Adresse eingestellt werden?
Bei der SPS-Remote wird sie per Menü eingestellt und in's Flash 
gespeichert.
Bei der AudioControl und dem Dimmer hat die Steuereinheit dann 
Dip-Schalter.
Bei Profibus muss beachtet werden das die Adresse nicht größer als 127 
werden darf!

>Wird die Adresse dezimal oder hexadezimal erwartet?
Wo ist der der Unterschied? :) Hex oder Dez. ist ja nur ne 
unterschiedliche Darstellung.

So wie sich das anhört geht's wohl nur darum das es bei PICs 
vorgefertigte Funktionen für UART und Standard-Displays gibt. Brauchen 
wir nicht :)

Im Anhang der aktuelle Stand.
Da einige Fragen zur Implementierung aufgetaucht sind, hier mal die 
etwas genauere Beschreibung des Code:

Globale Variablen:
char uart_buffer[MAX_BUFFER_SIZE];
Der UART Daten Buffer in den alle Daten die ankommen gespeichert werden.

unsigned int uart_byte_cnt;
Zähler für die Anzahl der Bytes die in uart_buffer[] eingelesen wurden.

unsigned int uart_transmit_cnt;
Zähler für die Anzahl der Bytes die bereits gesendet wurden. Ist nur 
wichtig wenn man die Interrupt Sende-Funktion benutzt.

unsigned char profibus_status;
Aktueller Status der Profibus Schnittstelle.

unsigned char slave_addr;
Wie der Name schon sagt.

unsigned char master_addr;
Könnte man wahrscheinlich auch weg machen, da wird eh immer nur die 
source_add reinkopiert.

unsigned char group;
Bisher auch unnötig da nicht benutzt.

unsigned char data_out_register[OUTPUT_DATA_SIZE];
Hier die Daten reinkopieren die zur SPS sollen (Daten Slave -> SPS).

unsigned char data_in_register [INPUT_DATA_SIZE];
Hier kommen die Daten der SPS rein (Daten SPS -> Slave).

unsigned char Input_Data_size;
Anzahl der Bytes die die SPS senden will.

unsigned char Output_Data_size;
Anzahl der Bytes die die SPS vom Slave erwartet.

Das Konzept der Input- und Output_Data_size muss evt. überdacht werden 
da die SPS wohl Modulabhängig auch mehrere "Blöcke" Ein-und 
Ausgangsdaten senden kann. Da wird aktuell dran geforscht.

unsigned char Vendor_Data_size;
Unbenutzt



Was ist nötig um das ganze zum laufen zu bekommen?
Zur Initialisierung benötigt der Slave erst mal eine Adresse. Sollte 
zwischen 1 und 126 liegen. Im Code kommt sie von der Funktion 
read_slave_addr();
Dann muss man die Zeitsteuerung rein bekommen. Im Code mit Timer A 
erledigt (unten mehr dazu). Grundsätzlich mal die Zeit Tsyn abwarten 
(Zeit ohne UART Kommunikation) und dann alles an Daten einlesen und 
profibus_RX() aufrufen. Die Funktion erledigt eigentlich alles 
automatisch.
Wichtige Stelle ist diese:

// Daten von Master einlesen
for (cnt = 0; cnt < INPUT_DATA_SIZE; cnt++)
{
  data_in_register[cnt] = uart_buffer[cnt + 7];
}

// Daten fuer Master in Buffer schreiben
for (cnt = 0; cnt < OUTPUT_DATA_SIZE; cnt++)
{
  uart_buffer[cnt + 7] = data_out_register[cnt];
}

Sollte selbsterklärend sein, oder? SPS Daten einlesen, Slave Daten raus.

Die Funktion profibus_send_CMD() macht alles selber, nur die Funktion 
profibus_TX() muss wieder an eure Hardware angepasst werden. Einfach die 
Anzahl length Bytes von *data auf den RS485 schicken, fertig.

Hardware abhängig ist also nur die UART Empfangs- und Sendefunktion so 
wie die Zeitsteurung. Die Auswertung der Daten sollte auf jedem 
Controller laufen. Für einen einfachen Taster oder Schalter/Relais Slave 
kommt man auch komplett ohne Interrupts aus.



Ein Wort zur Zeit-Steuerung:
1) WAIT_SYN: Warten auf Tsyn (Gewisse Zeit ohne UART Kommunikation).
2) Wenn Tsyn erreicht ist auf WAIT_DATA schalten
3) In der Zeit WAIT_DATA alles an UART Daten einlesen und auf GET_DATA 
gehen
4) GET_DATA hat ein Timeout. Wenn eine gewisse Zeit keine weiteren Daten 
über UART rein kommen wird profibus_RX() aufgerufen um die Daten 
auszuwerten
5) Beim senden wird auf SEND_DATA geschaltet
6) Sind alle Daten rausgeschickt, gehen wir wieder auf WAIT_SYN und das 
Spiel beginnt von vorn.

Und noch die neue h-Datei.

Damit wird der externe RS485 Transceiver von TX auf RX und umgedreht 
umgeschaltet.

//////////////////////////////////////////////////////////////////////////
/* RS485 Transceiver */
//////////////////////////////////////////////////////////////////////////
#define RS485_TX_EN           (P3OUT |= PIN6);
#define RS485_RX_EN           (P3OUT &=~PIN6);
//////////////////////////////////////////////////////////////////////////

Ist ein Function Code. Siehe (alte) h-Datei:

///////////////////////////////////////////////////////////////////////////
// Function Codes
///////////////////////////////////////////////////////////////////////////
#define REQ_FDL_STATUS        0x49  // SPS: Status Abfrage
#define FDL_STATUS_OK         0x00  // SLA: OK
//#define SEND_DATA
#define SEND_REQ_DATA         0x5D  // SPS: Ausgaenge setzen, Eingaenge lesen
#define SEND_REQ_DATA_T       0x7D  // SPS: Ausgaenge setzen, Eingaenge lesen (Toggle)
#define SEND_REQ_DATA_FIRST   0x6D  // SPS: Erste Anfrage

#define SLAVE_DATA            0x08  // SLA: Daten Eingaenge senden
///////////////////////////////////////////////////////////////////////////

In der aktuellen Version durch

#define DATA_LOW              0x08

ersetzt

>OK, dann passt die Quelle nicht ganz zum Header.  ;o)
Stimmt, mein Fehler. Gibt seit gestern aber eh wieder ne neue Version :) 
Werde ich im laufe der Woche reinstellen.

>Vielleicht sollten wir uns mal unterhalten, wie man den Code
>hardwareunabhängig macht und so auf verschiedener Hardware nutzen kann.
Na ja, der Hauptteil (profibus_RX) ist ja schon unabhängig. Was stellst 
du dir da noch vor?

Logische Auslagerungen könnte man natürlich machen, all zu viele 
Änderungen werden ich (zumindest beim aktuellen Projekt) vermutlich aber 
nicht machen können. Muss jetzt schon darauf achten das die 
Funktionsaufrufe bzw. Interrupts nicht zu lange dauern.

Aber am besten warten wir mal ab bis du fertig bist und reden dann 
weiter über das Thema :)

War die letzten Tage etwas kränklich, von daher hat es noch nicht 
geklappt. Ich denke mal heute abend oder morgen stell ich die neue 
Version rein.... Hauptänderung waren aber eh nur Interrupt Geschichten. 
Für AVR Umbastler wohl nicht sooo interessant.

So, die aktuelle Version.

Änderungen:
- RX Interrupt optimiert.
- Slave Adresse wird vor Checksummenberechnung überprüft
- TX Interrupt wartet nicht mehr bis letztes Byte gesendet wurde
- Umschaltung von TX auf RX (RS485 Transceiver) jetzt per Timer 
(PROFIBUS_SEND_DATA)
- Timer Interrupt Stop Timer für die Zeit der Verarbeitung
- Interrupt nesting im Timer Interrupt möglich

Alle Änderungen verringern die Verarbeitungszeit für die Profibus 
Schnittstelle und geben anderen Applikationen mehr und schnelleren 
Zugriff auf die CPU.

Und die h....

Die Diagnose kann gesendet werden indem man bei der I/O Datenübertragung 
anstatt Data-low

profibus_send_CMD(SD2, DATA_LOW, 0, &uart_buffer[7], OUTPUT_DATA_SIZE);

Data-high sendet (Define: DIAGNOSE):

profibus_send_CMD(SD2, DIAGNOSE, 0, &uart_buffer[7], OUTPUT_DATA_SIZE);

Das führt dazu das die SPS über den SAP 62->60 die Diagnose Daten 
abholt. Im Status1 Byte muss dann das Bit 0x08 (EXT_DIAG_) gesetzt 
werden

uart_buffer[9]  = EXT_DIAG_;                    // Status 1
uart_buffer[10] = STATUS_2_DEFAULT;             // Status 2
uart_buffer[11] = DIAG_SIZE_OK;                 // Status 3
uart_buffer[12] = master_addr - SAP_OFFSET;     // Adresse Master
uart_buffer[13] = IDENT_HIGH_BYTE;              // Ident high
uart_buffer[14] = IDENT_LOW_BYTE;               // Ident low
uart_buffer[15] = 0x05;     // Geraetebezogene Diagnose (Anzahl Bytes)
uart_buffer[16] = 0x00;     // Geraetebezogene Diagnose Byte 1
uart_buffer[17] = 0x20;
uart_buffer[18] = 0x20;
uart_buffer[19] = 0x00;

Dann kann man mehr oder weniger beliebig viele Gerätebezogene Diagnose 
Bytes senden. Was die einzelnen Bits bedeuten muss in der GSD Datei 
beschrieben werden.

>Basic Clock Modul
Bei mir ist SMCLK = 4MHz und MCLK = 8MHz
Im einfachsten Fall mit internem DCO wäre das:

  // DCO auf 8MHz stellen
  BCSCTL1 = CALBC1_8MHZ;
  DCOCTL = CALDCO_8MHZ;

  BCSCTL2 = DIVS_1;  // SMCLK = DCO/2 = 4MHz, MCLK = DCO = 8MHz

>TimerA
Müsste im Source Code schon alles drin sein (Siehe init_Profibus())

>UART

  UCA0CTL0 = UCPEN + UCPAR;     // Parity, Even Parity
  UCA0CTL1 = UCSSEL_2;          // Clock = SMCLK = 4MHz
//  UCA0BR0  = 0xD0;              // Einstellung fuer 19200
//  UCA0BR1  = 0x00;              // Einstellung fuer 19200
//  UCA0MCTL = UCBRS_3;           // Modulation für Korrektur fuer 19200
  UCA0BR0  = 0x2A;              // Einstellung fuer 93750
  UCA0BR1  = 0x00;              // Einstellung fuer 93750
  UCA0MCTL = UCBRS_5;           // Modulation für Korrektur fuer 93750

>Interrupts

IE2 |= UCA0RXIE;                    // Interrupt UART0 an für RX  

Auf die SPS Sachen hab ich keinen Zugriff, da müsste ich erst die 
anderen Fragen...

Hi,
ich möchte auch einen MSP verwenden um den SPC4 anzusteuern. Hast du die 
Funktionalität für den Zugriff auf die 10 Addressbits selbst 
programmiert oder hast du hierfür eine Bibliothek ? Ist dein MSP430F2252 
für die anbindung eines externen Datenbusses besonders geeignet (Adress 
und Datenbus) ?

Gruß
Michael

Da hast du was falsch verstanden. Wir machen ALLES mit dem MSP. Ein SPC4 
o.ä. ist nicht notwendig. Nur ein RS485 Baustein :)
Funktioniert also mit allen MSPs (oder anderen Controllern) die eine 
UART Schnittstelle haben. Der MSP430F2252 ist im prinzip schon etwas 
oversized. Für einfache I/O Sachen geht auch was kleineres.


In den nächsten Tagen wird es übrigens noch ein kleines Update der SW 
geben.

Die neue Version...

Änderungen:
- Mit defines werden jetzt die diversen Arrays automatisch angelegt und 
initialisiert.
- Zwei neue Arrays: Vendor_Data[] und Diag_Data[]
- Neues Flag: diagnose_status
- read_slave_addr() in get_Address() umbenannt

Über "diagnose_status = TRUE" werden Diagnose Daten automatisch 
übertragen.
Der Datentausch wird durch die defines "automatisiert". Wenn keine Daten 
gesendet, sondern nur empfangen werden, wird automatisch nur noch eine 
Kurzquittung anstatt SD2 Kommando gesendet.

Alle müssen die gleiche Busgeschwindigkeit haben, sonst geht nix.

>Könnten Sie mir sagen auf wieviele ms der interrupt eingestellt ist?
Timer A?
Das ist variable, je nachdem in welchem Zustand der Profibus gerade ist.

Relevanter Code:

//////////////////////////////////////////////////////////////////////////
#define TIMEOUT_MAX_SYN_TIME  33 * DELAY_TBIT // 33 TBit = TSYN
#define TIMEOUT_MAX_RX_TIME   15 * DELAY_TBIT
#define TIMEOUT_MAX_TX_TIME   15 * DELAY_TBIT
#define TIMEOUT_MAX_SDR_TIME  15 * DELAY_TBIT // 15 Tbit = TSDR
//////////////////////////////////////////////////////////////////////////

//////////////////////////////////////////////////////////////////////////
#define TA_SMCLK_500KHZ       TACTL = MC1 + TASSEL1 + ID_3;
#define TA_RUN                TACTL |= MC1
#define TA_STOP               TACTL &= ~MC1

#define DELAY_TBIT            5.33    // UART @ 93750
//////////////////////////////////////////////////////////////////////////

> Ist es möglich der code mit der function main() uploaden, es wäre
> nähmlich sehr hilfreich.
Das das sonderlich hilfreich ist, glaube ich nicht :)
Gibt es konkrete Fragen?

//////////////////////////////////////////////////////////////////////////
void main (void)
{

  ///////////////////////////////////////
  watchdog_aus          ();
  init_MCU              ();
  switch_SMCLK_XT1_8MHz ();
  init_UART0            ();
  init_Profibus         ();
  interrupt_settings    ();
  ///////////////////////////////////////

  while(1)
  {
    // Hier Code fuer Hauptprogramm
  }
}
///////////////////////////////////////////////////////////////////////// 

>In dem fall 5.33 sind das 5.33 ms?
Nein, das ist die Anzahl der Takte des Timer A für ein Bit.

Timer A = 500kHz -> 2µs/Takt
Profibus = 93750 Baud -> 10,66µs/Bit

10,66µs/2µs = 5,33 Takte/Bit

Hier war mal die rede von einer Version für einen AVR, ist darraus was 
geworden?

Welche maximale Profibus Baudrate wäre denn mit einem MSP430F2252 
möglich?

>Welche maximale Profibus Baudrate wäre denn mit einem MSP430F2252
>möglich?
Wenn Marc noch ne 2. SPS auftreiben kann, wollte ich ein Versuch mit 
500k und 1,5M starten.
500k sollte sicherlich noch gehen, 1,5M würde schon ausserhalb der Spec 
vom 2252 liegen, es gibt aber MSPs der F2xxer Serie die das laut 
Datenblatt noch können.

Allgegenwärtig schrieb:
> Interessant wäre eine Portierung auch auf einen ARM ala STM32 oder LPC2
Auf meinem Schreibtisch liegt schon ne Platine mit ARM Cortex M3 
(LPC1768) :)

Jain, hat mit einem Sample angefangen, den 1768 hab ich aber normal 
gekauft ;)
Wird aber noch etwas dauern bis da Profibus läuft. Bis jetzt blinkt nur 
ne LED, als nächstes kommt erst mal ein Display dran, danach dann 
UART...

Jörg S. schrieb:
> Wenn Marc noch ne 2. SPS auftreiben kann, wollte ich ein Versuch mit
> 500k und 1,5M starten.
> 500k sollte sicherlich noch gehen, 1,5M würde schon ausserhalb der Spec
> vom 2252 liegen, es gibt aber MSPs der F2xxer Serie die das laut
> Datenblatt noch können.

wo bekomme Ich dennam besten die MSP Microcontroller?

Bei welchem würden denn laut Datenblatt 1,5 gehen, hab mal gestöbert, 
aber Ich finde bei allen die gleiche Uart Frequenz!

>wo bekomme Ich denn am besten die MSP Microcontroller?
HBE (www.hbe-shop.de) hat eigentlich alle im Programm.

>Bei welchem würden denn laut Datenblatt 1,5 gehen, hab mal gestöbert,
>aber Ich finde bei allen die gleiche Uart Frequenz!
Die F21x2 gehen z.B. bis 2MHz BitClk.

Hab eben mal schnell mein Projekt total abgespeckt. Es kommen 2,3 kByte 
Flash und 150 Byte RAM raus (bei MSP430 / Code Optimierung "low").
Beim Profibus könnte man aber noch einiges raus werfen (z.B. SAP 62 -> 
DSAP 62) und dadurch noch etlichen Speicher sparen.

Wenn man also nur ein paar Byte direkt von einem Port auslesen oder 
setzen will, könnte man es mit eisernem Willen vielleicht schon mit 2 
kByte Flash und 128 Byte RAM schaffen. Wäre hart an der Grenze, aber 
wohl noch im Bereich des möglichen.

Und wenn wir schon dabei sind....
Der 6-fach Dimmer befindet sich gerade in der Testphase :)

Hallo Joerg,

sieht wirklich Klasse aus was du da machst.
Habe auch eine SPS im Keller hängen zur Haussteuerung.
Wäre sehr an dem 6-fach Dimmer interessiert.

Würdest du die Daten herausgeben (Source-Code, Layout etc.) ?
Ich benutze Eagle. Sieht auch sehr nach Eagle aus.

noeppkes ...

Beschreibung von dem ganzen Kram ist schon in Arbeit.
Evt. könnte ich am Wochenende die Homepage soweit fertig machen das 
schon ein paar Schaltpläne usw. mit drin sind...

Und ja, es ist mit Eagle gemacht :)

Hallo Joerg.

Freue mich schon drauf.
Hinterlasse hier einfach eine Nachricht.

Bis dann ...
noeppkes ...

So, hier findet sich jetzt die Schaltungsbeschreibung, Schaltplan und 
das Eagle Projekt:
http://www.see-solutions.de/projekte/projekte.htm (2007_02)

Weiss noch nicht genau wie das dann mit der Beschreibung der SPS Seite 
werden soll. Evt. gibt es dann mal eine separate Homepage für die ganze 
Sache...

Hallo Jörg,

Als eine PROFIBUS slave sollte es unter beliebige master (SPS oder 
anders) arbeiten.

Ich versuche diese mit ein AVR AtMega16 zu machen. Es springt doch eine 
meldung herüber und die nächste wird dann im Profibus_RX bearbeitet!? 
Also jede zweite meldung ist verloren.

Dann muss immer als 3 oder so in master als Retry Count angegeben. Dann 
wird die fehler behebt bei die nächste (retry) meldung.

Ich hat die Timer_ISR unter case PROFIBUS_GET_DATA ein kurzes ein/aus 
mit der RS485 treiber gemacht (7,5us). Dann kann ich es in ProfiTrace2 
oscilloscope als ein "blip" sehen. Und wenn eine meldung bearbeitet sind 
wird die nächste es nicht. Aber immer die meldung danach.

Hast du mit ProfiTrace oder ähnliches überprüft dass deine slave keine 
meldungen übersehen?

Hurra Propeller!! Nun laüft es.

Und es springt keine meldungen herüber. Dass war meine fehler wenn zum 
AVR umschreiben.

In SAP_CHK_CFG sollte du erst diese kode einsetzen:

Output_Data_size=0;
Input_Data_size=0;

Danach alle "=" mit "+=" ersätzen. Dann wird es mehrere module 
akzeptieren. Wenn du in konfigurator 10 byte input angibt als ein modul 
8byte und ein modul 2byte, dann bekommst du nur 2 byte! Mit diese 
korrektur kannst du mehrere module korrekt einsetzen. Und diese slave 
will sich zum master konfiguration anpassen, nicht nur wie üblich 
überprüfen.

Es lüft nun mit 187.5Kbit/s und Tsdr 42Tbit. Wird mit ProfiTrace2 
ausgemessen.

Mit 2 kleine änderungen ist auch Set Slave Address OK.

Wie geht es dann mit ihre hausautomations projekt Jörg?

Einar S. schrieb:
> In SAP_CHK_CFG sollte du erst diese kode einsetzen:
>

> Output_Data_size=0;
> Input_Data_size=0;
> 

Das wird ja schon in der init_Profibus() gemacht.

Einar S. schrieb:
> Danach alle "=" mit "+=" ersätzen. Dann wird es mehrere module
> akzeptieren. Wenn du in konfigurator 10 byte input angibt als ein modul
> 8byte und ein modul 2byte, dann bekommst du nur 2 byte! Mit diese
> korrektur kannst du mehrere module korrekt einsetzen.
Das mit den Modulen ist bekannt. Hab ich weiter oben schon erwähnt. Für 
Konfigurationen mit mehreren Modulen sind die auskommentierten Arrays
Input_Data_size_Module[INPUT_MODULE_CNT]
und
Output_Data_size_Module[OUTPUT_MODULE_CNT]
vorgesehen. Da hab ich aber noch nicht weiter dran gearbeitet. Das mit 
+= ist natürlich erst mal eine einfache Lösung :)

Einar S. schrieb:
>Wie geht es dann mit ihre hausautomations projekt Jörg?
Grundätzlich läuft's. Ein paar kleine Probleme und Änderungen müssen 
noch bearbeitet werden :)

Ich muss es doch erst ein bisschen durchsehen, so bitte geduld Kilian.
Und nur wenn Jörg gibt sein OK.

@Jörg: Ist es OK wenn ich die modifizierte kode auch für andere zu 
verfügung stellt? Es is ja nahezu 100% deine arbeit.

>@Jörg: Ist es OK wenn ich die modifizierte kode auch für andere zu
>verfügung stellt? Es is ja nahezu 100% deine arbeit.
Hätte ich kein Problem mit.

KiliPet schrieb:
> Dann muss ich das Rad nicht neu erfinden.

Hier isses.
Das rundlauf diese rad konnte besser sein. ;-)

Bei mir geht es ziemlich gut, aber es ist bekannte fehler darin.

Für meine erste projekt LEDlicht steuerung/dimmer ist es scon gut genug. 
Verbesserungen will ich trotzdem machen.

Ich habe die PROFIBUS treibern von eine slave modul ausgeschlachtet.

Meistens ist die alle gleich. Und in das buch "The New Rapid Way to 
Profibus DP" (Manfred Popp) ist auch shaltplan zu finden.

Oder 75176 datenblatt suchen.

Jochen Kühner schrieb:

> Und in dem Datenblatt finde Ich kein Schaltplan mit AVR...

Findet du auch nicht in buch.
Diese kannst du in Profibus.c lesen:
"Pins used: USART RX / TX, Portd:2 controls TX enable."
Besser kann ich nicht tun. Ich habe selber keine schaltplan.

Diese DP-slave ist keine DIY DP-slave.
Es ist auch keine komplette DP-Slave, aber eine basis für DP funktionen 
herumzuspielen. Man sollte PROFIBUS und AVR ziemlich gut verstehen um 
von hier weiter zu kommen. (Gilt mindestens für meine AVR anpassung. Wie 
es mit Jörg's MSP430 ist, weiss ich nicht.)

>geht auch ein Max3485 als PB Treiber??
Es sollte jeder 485 Treiber gehen.

>Why apper that? can u help me? please
What Compiler are you using?
It looks like you do not include the Header Files for the MSP430 
specific Defines.
Other Defines like "LED_ERROR_AN" or "RS485_TX_EN" are Defines for some 
Port-Pin Switching. They have to be created by you.

Has the "SPC3" Name to do anything with your Project? Because this 
Source Code isn't for any Profibus-ASIC like the SPC!

In eigener Sache:

Das Profibus Handbuch von Max Felser habe ich mal auf meine Homepage 
gestellt, da es ja nicht mehr im web verfügbar ist:
http://www.see-solutions.de/sonstiges/sonstiges.ht...

In den nächsten Woche gibt's auch wieder ein kleines Update. Da ist das 
dann mit den Modulen für die I/O Datengröße besser gelöst.

Soares schrieb:
> Im using mplap. I trying to developing a module with VPC3+S using the
> SPI interface. Can you help me ?please
Sorry, i don't know nothing about mplap and nothing about the VPC3 Chip.


Summary:
This Project implements a Profibus Client ONLY WITH SOFTWARE to a MSP430 
Microcontroller. There is no need for a special Profibus Chip, because 
this things are done within the Software on the µC!
On the Hardware-Side, you need a µC with UART and a RS485 Transceiver 
Chip, that's all :)

Neue Version.

Änderungen:
diagnose_status wird nicht mehr als Flag benutzt, sondern jetzt direkt 
als Status Byte 1 in der Diagnose verwendet. Daher Umbenennung in 
diagnose_status_1.
Der Ablauf der Diagnose wurde ebenfalls überarbeitet, da ein Bug dazu 
führte das die falsche Anzahl der Diagnose Bytes gesendet wurde.
Die Software benutzt zur Zeit die Gerätebezogene Diagnose. Die weiteren 
zwei Diagnosemöglichkeiten wurden noch nicht getestet.
Das Define DIAGNOSE wurde in DATA_HIGH unbenannt, um konform zur Felser 
Dokumentation zu sein.
Hinweis zum Ablauf: Wenn man Diagnosedaten überträgt, löscht die SPS den 
Diagnosestatus erst wenn bei gesetztem Diagnosebit (diagnose_status_1 & 
EXT_DIAG_) leere Diagnosedaten übertragen wurden. Löscht man EXT_DIAG_ 
zusammen mit den Diagnosedaten, so erkennt die SPS den gelöschten 
Diagnose Status nicht.


Beim "Parameter Request" ist die Bezeichnung User Parameter richtiger. 
Daher wird das Define VENDOR_DATA_SIZE umbenannt in USER_PARA_SIZE.
Achtung: Der Name VENDOR_DATA_SIZE wird weiterhin verwendet (Bei Config 
Request).


Wie bereits angekündigt wird die Input/Output Datengröße neu ermittelt. 
Dazu wird ein neues, 2-Dimensionales, Array Module_Data_size[][] 
verwendet.
Die SPS kann nicht nur eine einzige Eingangs- und Ausgangsgröße 
festlegen, sondern auch verschiedene Module. Vor allem beim "speziellem 
Format" spielt das eine Rolle.
Mit MODULE_CNT wird die Anzahl der Module festgelegt. In den zwei Byte 
pro Modul im Array wird die Anzahl der Eingangs- und Ausgangsbytes 
gespeichert.
Bei einem Fehler wird automatisch das entsprechende Flag (CFG_FAULT_) in 
der Diagnose gesetzt.
Der gesamte Abschnitt "Check Config Request" wurde diesbezüglich 
überarbeitet.

Einar S. schrieb:
> KiliPet schrieb:
>> Dann muss ich das Rad nicht neu erfinden.
>
> Hier isses.
> Das rundlauf diese rad konnte besser sein. ;-)
>
> Bei mir geht es ziemlich gut, aber es ist bekannte fehler darin.
>
> Für meine erste projekt LEDlicht steuerung/dimmer ist es scon gut genug.
> Verbesserungen will ich trotzdem machen.

Ich habe nun auch meine Profibus Platine fertig, habe jedoch statts 
einem 12mHz Quarz ein 16MHz quarz verwendet.

Sehe Ich das richtig, das Ich in der profibus.h die F_CPU auf 16000000 
anpassen muss, und noch die DELAY_TBIT  auf 85 erhöhen, das wars dann 
schon??

Und wenn Ichs mit 1,5 Mbit testen will, muss Ich dann auch nur die 
DELAY_TBIT anpassen (um faktor 8 verkleinern?)

Ok, Ich hab gesehen, Ich muss auch noch die werte bei
#define UART_BAUD_187500 anpassen.

Aber wie kommt man bei 12MHz Quarz auf 7 für #define UART_BAUD_187500 
7
(Wert fürs Register UBBRL)

Wenn Ich da die Formeln aus dem Microcontroller Wiki nehm, kommt bei mir 
bei 12MHz 3 raus!

Die beiden vorherigen Fragen haben sich soweit erledigt, habe jetzt auch 
ein 12MHz Quarz eingelötet, da sonst für die Teilerberechnungen ja 
unschöne Werte rauskommen. Wenns mit dem 12MHz mal läuft werd Ich ja 
sehen ob Ich das 16MHz noch brauche oder nicht.

Hab nur das Problem Ich kriegs nicht zum laufen. Hab mir mal einen 
Blinker ins Hauptprogramm eingebaut, der geht, aber sonst läufts nicht.


In profibus_RX hab Ich mal einen meiner Ausgänge angesteuert, da läufts 
anscheinend rein, aber dann springt er im select zum case default.

Und wenn Ich das ganze ein paar minuten laufen lasse, dann hängt 
plötzlich der PD2 Ausgang (also das Umschalten von Recieve auf Send), 
und dann geht der ganze Profibus nicht mehr (da auch TX die ganze Zeit 
bei 5V ist!)

Hab mal meinen Plan angehängt, viel. ist ja auch da noch was falsch!

Mfg.

Mit 16MHz muss du 500Kbit/s läufen. Und dann wird die PROFIBUS timing 
ein problem. Mindestens mit die heutige erkennung von ende der 
einkommende meldung. Es wird erkannt als die antwort ausgehen sollte.

Ihr plan ist OK. Ich habe galvanische trennung zwischen MCU und RS485. 
Aber wenn deine testbus nur am labortisch ist sollte das kein problem 
sein.

Die steuerungsaufgaben sollte in doit() sein. Und es sollte nimmer die 
interrupt blockieren.

Ich habe nun ein 12Mhz eingelötet, zur Problemanalyse. Auch die 
Busgeschwindigkeit habe Ich auf 187500 eingestellt. Der Profibus 
funktioniert also noch nicht.

Ich habe zur Kontrolle mal die empfangen daten ins Eeprom geschrieben, 
aber im uart_buffer[0] steht nie ein SD1, SD2, SD3 oder SD4. Es wird 
dort immer in den default case gesprungen. d.h. ich empfange daten, aber 
nicht die richtigen.
Hast du da noch irgendwelche Ideen?

Was für einen Optokoppler hast du denn drin, bzw würdest du empfehlen?

Danke schonmals.

A und B vielleicht vertauscht?

Hast du die quellcode wie es ist versucht? Bei mir läuft es gut.
Erst die originalcode nützen. Wenn es läuft ist deine hardware in 
ordnung.

Von störungen weghalten und es sollte ausser galvanische trennung OK 
sein.

Hast du die fuse für externe quarz einprogrammiert? Wenn nicht lauft es 
etwa 8MHz von die interne PLL. Und wenn du eine neue ATmega kriegst ist 
diese fuse nicht für externe quarz programmiert.

Ich Idiot!

Es war das vertauschen von A und B!

Danke schon mal an Einar und Jörg für die Hilfe.

Hab jetzt noch sporadisch Busausfälle, hast du das auch Einar?

Werd mal morgen mit dem Profibusanalyser drangehen, um zu sehen ob er im 
nicht gestörten Zustand schon oft in die Telegrammwiederholung kommt.

Als nächstes werd Ich dann noch versuchen AutoBau Erkennung zu 
implementieren. Müsste doch möglich sein, wenn man einen Zähler bei den 
empfangen falschen Telegrammen einbaut, so das wenn dieser zu groß wird, 
man die Baudrate ändert, bis es funktioniert?

Einar S. schrieb:
> Von störungen weghalten und es sollte ausser galvanische trennung OK
> sein.

Ist den eine Galvanische Trennung bei PB-Vorschrift? Machst du in deinen 
PB Platinen eine galvaische Trennung Jörg?

Noch Infos:

Wenn Ich das RetryLimit hochsetze, bekommt die CPU die Störung nicht 
mehr mit. Muss morgen mal mit dem Busanalyser sehen, ob der Slave gar 
nicht Antwortet, oder was falsches schickt...

Und schon wieder Ich.

@Eimar:

Sollte in deinem AVR Projekt nicht auch unsigned char data_in_register 
[INPUT_DATA_SIZE]; volatile sein?

Wenn es gedacht Ist die Verabreitung in doit zu machen, gehts bei mir 
ohne nicht!

Und nochmals Ich:

Ich hab jetzt das Retry_Limit auf 5, und da läuft es eigendlich stabil. 
Doch wenn ich dann z.B. den baugruppenzustand in Step7 aufmache, und 
somit mein Schnittstellenadapter ein Haufen Informationen vom Bus zieht, 
habe Ich einen Busausfall von meinem Teilnehmer. werd das auch mal 
morgen weiter Analysieren, aber viel. hat ja da schon jemand eine Idee!

Jochen Kuehner schrieb:
> Machst du in deinen PB Platinen eine galvaische Trennung Jörg?
Nein.

> Doch wenn ich dann z.B. den baugruppenzustand in Step7 aufmache, und
> somit mein Schnittstellenadapter ein Haufen Informationen vom Bus zieht,
> habe Ich einen Busausfall von meinem Teilnehmer.
Das Verhalten kenne ich bei der MSP Software als damals noch der Buffer 
-Überlauf durch zu viele Eingangsdaten noch nicht abgefangen wurde.

Jörg S. schrieb:
> -Überlauf durch zu viele Eingangsdaten noch nicht abgefangen wurde.
Das ist aber in dem AVR Code von Eimar schon drinn...

Um erstmal HW Probleme auszuschließen, was macht Ihr denn mit dem 
Schirm?

So....

hab jetzt was Rausgefunden. Sowie es aussieht braucht der Teilnehmer zu 
lange wenn Ich große Telegramme auf dem Bus Verschicke.

Ich bin ja schon bei Normal laufenden Bus bei einer Min-SDT von 49.

Hab die max sdt deshalb mal hochgesetzt, dann geht die CPU auch nicht 
mehr in Stop, doch es kommt immer noch zu einer Telgrammwiederholung, da 
selbst nach über 279 Bitzeiten noch keine Antwort kam.

Hab mal einen Screenshot vom telegramlog angehäüngt, und hab mal auf die 
Telegrammwiederholung getriggert. Im normalen Betrieb tritt keine 
wiederholung auf. Was mich aber wundert ist, das nach dem längeren FDL 
request, welcher wahrscheinlich die Probleme verursacht, erst mal 2 
normale telegramme vom teilnehmer kamen, und erst danach das mit der 
wiederholung passiert ist!

Einer Ne Idee?

Achso, noch Infos: ID SPS=2 , ID AVR=1
Spalte 1 - TeleNr
Spalte 2 - zeitstempel
Spalte 3 - Adressen
Spalte 4 - Protokoll
Spalte 5 - Primitive
Spalte 6 - Dienst
Spalte 7 - Daten

Habs jetzt auch noch im normalen Betrieb geschafft.

Wenn das Global_Control Telegramm kommt, kann der AVR nicht auf die 
Statusanfrage danach gleich Antworten.

Denke das ist aber, da der AVR das Global Control noch verarbeiten muss, 
und daher noch nicht auf das neue Telegramm reagieren kann! Kann das 
sein?

Bei Global Control muss er ja nichts machen, noch nicht mal antworten. 
Von daher sollte er da ja schon sehr schnell durch sein...

Jörg S. schrieb:
> Bei Global Control muss er ja nichts machen, noch nicht mal antworten.
> Von daher sollte er da ja schon sehr schnell durch sein...

keine Ahnung warums dann passiert.

Hast du denn den Bus bei dir ohne ausfälle (Telegrammwiederholungen) am 
laufen? Irgend eine Idee was das sonst verursachen könnte?

Vielleicht ist ist Zeit Tsyn nach Global Control noch nicht abgelaufen.

Hast du ein Speicheroszi? Dann könnte man sich mal an einem Portpin 
ausgeben lassen wann er wieder bereit ist und schauen ob vorher schon 
Daten reinkommen.

Speicheroszi ist leider nicht vorhanden. Mal sehen was Ich noch an Tests 
durchführen kann...

Hallo Jörg S.
ich habe mit Interesse Ihr Projekt und die Kommentare dazu studiert.
Könnten Sie mich diesbezüglich bitte per E-Mail kontaktieren?
mfG
Michael

Ja, für ATmega16. Bitte mein post von Datum: 07.05.2010 14:44 lesen. Da 
ist die quellkode dabei.

Vielleicht kannst du nicht diese als "gast" sehen?

ATmega32 ist soweit ich weiss dieselbe MCU mit mehr Flash & RAM.

Einar

Vielen Dank für die schnelle Antwort, ja die AtmegaXY sind so ziemlich 
gleich, vor allem was Register angeht... werde den Code die Tage mal 
testen..
man muss ja manchmal auch noch arbeiten nebenher :-)

@Zachter (Gast): Leider nicht. Ich bekommt nur ein fehlermeldung:
--------------
Error
Code: ER_NFF_102420110918
Possible reasons for that:
* you have a mistake in the link
* The file was deleted in case of a abuse report.
* The file was deleted by the uploader.
--------------

@Daniel: Wie geht es? Atmega32 sollte ohne änderungen spielen.

Wenn der µC genug Power hat, sollte mit der Software Lösung auch 1,5MBit 
möglich sein.
LPC13xx von NXP sollte z.B. ganz gut passen.

Ist es ein hobbyprojekt? Dann versuchen sie es. Es ist möglich.

Aber wenn es ein kommerzielles produkt ist, dann nein! überhaupt nicht! 
Diese code hat elementen die nie durch eine PROFIBUS certification 
kommt.

http://www.profibus.com/community/test-labs/

Dann sollte du ein chiplösung oder modullösung suchen. Profichip ist 
einer von diese, es gibt mehrere. Ich rate sie mit eine PICC zu sprechen 
wenn dies eine kommerzielle produkt ist.

MvG
Einar

cell85 schrieb:
> Meint ihr das ist mit eurem Code möglich?
Der Code stellt ein Profbus Slave dar. Geht also :)

> Diese code hat elementen die nie durch eine PROFIBUS certification
> kommt.
Ausserdem hab ich komerzielle Nutzung untersagt ;)

Wenn man noch einiges an Zeit reinsteckt kann auch was zertifizierbares 
raus kommen. Aber im aktuellen Zustand ist der Code natürlich nicht 100% 
Profibus konform. Wie auch auch schon im Ursprungspost steht.

This Function reads the Dip-Switch Status on the µC Port, where the 
Profibus Address is set.

See:
Beitrag "Re: Software Profibus DP-Slave in C"

I think it is not 100% correct and doesn't matches the actual Source 
code exactly, but it should be a good starting Point.

I'am not sure what you are mean with "connect"?

If you want to know how to include a Profibus Device into the SPS 
Programm, that are Basics of the SPS Programming. And i'am not familiar 
with that. My Part in this Projekt was only the programming of the 
Firmware for MSP430 µC.

Hello Joerg,

I appreciate your hardwork in developing profibus slave in uC.

Would you please guide me how can I modify this code to view/recive 
32bit(4byte) data from master.
I just want simple DP slave implementation and Slave will receive 4byte 
data from master every second.


Regards,
Azher

In the profibus.h File, there is the Define "INPUT_DATA_SIZE" and 
"OUTPUT_DATA_SIZE". Set Input to 4 and Output to 0.
That should be all...

>Is it possible to get the source code somewhere?
Sure, take a look in the Thread!

For example the newest Version:
Beitrag "Re: Software Profibus DP-Slave in C"