Aus RN-Wissen.de
Wechseln zu: Navigation, Suche
LiFePO4 Speicher Test

Für das Projekt "Network Controller/PC" werden hier die ganz konkreten Spezifikationen angelegt. Als "Sprache" wird Pseudo-Code, an C angelehnt, verwendet.


Layer-0

Für die unterste Schicht, Layer-0, gibt es drei Versionen:

IP (TCP/IP)

Rncomformatip.png

Die Länge ist "host-order" d.h. low-Byte zuerst, immer exklusive Länge, d.h. für 4 Bytes Layer-1 Daten werden insgesamt 6 Byte übertragen.

UART

Rncomformatrs.png
  • Maximale Frame-Size
#define FRAME_C_MAX   127     

Das ist die maximale Netto-Länge zwischen STX und ETX, exklusive. Auch das scheint für µC etwas groß, aber es wird davon ausgegangen, daß die real benötigten Messages weit kürzer sein werden, d.h. das regelt sich vermutlich von selbst durch die Vereinbarungen und Restriktionen in den oberen Layern

  • Kontrollzeichen
#define CTL_M_MASK   0xF8 
#define CTL_M_ADON   0x08 
#define CTL_C_BASE   0xA8 
#define CTL_C_STX   CTL_C_BASE + 1 
#define CTL_C_ETX   CTL_C_BASE + 2 
#define CTL_C_PFX   CTL_C_BASE + 3 
  • Code-Beispiel/Muster für Paket-senden

( transmit() stellt die Funktion für den tatsächlichen physischen Output dar).

static unsigned char bTxBcc;            // Checksum für BCC 
// --------------------------------------------------------------
void TxStartFrame ( void )
{
  bTxBcc = 0
  transmit ( CTL_C_STX )                         
}
// --------------------------------------------------------------
void TxCloseFrame ( void )
{
  TxSendStuffByte ( bTxBcc )  // auch das BCC mit ev. prefixed werden
  transmit ( CTL_C_ETX )                         
}
// --------------------------------------------------------------
void TxSendFrameByte ( unsigned char bTxChar)
{
     bTxBcc ^= bTxChar
     TxSendStuffByte ( bTxChar ) 
}
// --------------------------------------------------------------
void TxSendStuffByte ( unsigned char bTxChar)
{
     if (bTxChar & CTL_M_MASK) == CTL_C_BASE) 
     { 
       transmit ( CTL_C_PFX )
       transmit ( bTxChar + CTL_M_ADON )      
     } 
     else 
     { 
       transmit ( bTxChar )        
     } 
}
  • Die entsprechende Empfangsroutine ist etwas komplexer und wird wesentlich mehr vom Geschick und den Gewohnheiten des Programmieres bestimmt.

RS232 mit Windows

I2C

Rncomformati2c.png
  • Fwd die Empfänger-I2C-Adresse. In der vorliegenden Version werden nur 7-Bit Adressen zugelassen. Für Broadcasts (HBT, ASK) wird GCA (= NuLL) verwendet.
  • Bck ist immer die Absender-I2C-Adresse. Aus formalen Gründen wird immer das Bit 0 gesetzt.

Programmiertechnisch ist dazu wohl nicht viel zu sagen.


Layer-1 Version 0.1

Hier sind es zwei Ausprägungen: Für die PC-Seite und für die Microcontroller

PC

Rncomlay1pc.png

In dieser Version gibt es keine Pfadangaben, sondern immer 16-Bit IDs. Da sich eine IP-Verbindung ja als point-to-point darstellt, ist der Bedarf an Routing-Pfaden nicht sosehr gegeben.

ID (Identifier)

Die ID sollte eine systemweit eindeutige Adresse für ein Gerät sein. Also zum Beispiel ein ganz bestimmter AD-Converter auf einem Kontroller im Netzwerk. Oder die Steuerung für einen bestimmten Schrittmotor o.Ä.

µC

Rncomlay1uc.png

T-1, T-2, S-1, S-2 sind in dieser Version immer 8-Bit Pfadangaben. In dieser Version sind nur zwei Pfadangaben je Richtung erlaubt, die sind aber auch immer da, selbst wenn der Inhalt NULL ist (void).

Pathsmall.png

Pfade

Die Referenzen 0-63 brauchen nur innerhalb eines Rechners eindeutig zu sein. Die ersten 8 Werte sind allerdings vordefiniert und für alle Rechner gleich

  • 0 (&H01) HBT "Heartbeat" Broadcast
  • 1 (&H05) NXT "Next" Frage nach Geräteliste Daten: 8-Bit Geräteindex
  • 2 (&H09) IAM "I am" Information über ein Gerät Daten: 8-Bit Device-Index, 16-Bit ID
  • 3 (&H0D) ASK "Suche Gerät" Broadcast Daten: 8-Bit NULL, 16-Bit ID
  • 4 (&H11) UART Die UART (In Vers-0.1 wird von maximal 1 UART je Rechner ausgegangen)
  • 5 (&H15) resv.
  • 6 (&H19) resv.
  • 7 (&H1D) resv.

Autor

Siehe auch


LiFePO4 Speicher Test