ENC28J60 myEthernet mit NeMo Stack Probleme

[Oliver R. (koreif)]

Hallo, ich bedanke mich schonmal im Voraus für eure Hilfe.
Zu meinem Problem. Ich möchte über ein myEthernet Daten an einen PC 
senden. Dafür hatte ich vor die NeMo-Stack Bibliothek zu verwenden. Mit 
dieser habe ich in Avr Studio ein neues Projekt erstellt. Dort ist das 
Problem, das der Code anscheinend irgendwie eine Mischung aus C und C++ 
ist.
In der net.h steht in der Zeile 183.

 extern uint8_t EEMEM  eeIpAddr[4];

Was folgende Fehlermeldung erzeugt:
expected '=', ',', ';', 'asm' or '__attribute__' before 'eeIpAddr'
Ich finde leider nicht die C Syntax um die Variable im EEPROM zu 
speichern.

Nun zum nächsten Problem. Ich habe in meiner main folgenden Interrupt:

 ISR ( USART0_RX_vect )
{
  usart_new_char();
}

Was folgende Fehlermeldung erzeugt:
undefined reference to `usart_new_char'
Ich binde in meiner main die usart.h ein in welcher die Funktion 
deklariert ist:

 #define USART_NEW_CHAR()      (recv_buf.writ != recv_buf.read)

Usart.c:

 void usart_new_char(void)
{
  recv_buf.buf[recv_buf.writ] = USART_RECV_CHAR();
  if(++recv_buf.writ >= BUFLEN) recv_buf.writ = 0;
}

Ich danke euch für eure Zeit.

[Stefan F. (Gast)]

Oliver R. schrieb:
> usart_new_char()
> USART_NEW_CHAR()

Groß/Klein Schrift ist dem C Compiler nicht egal.

> EEMEM
> Ich finde leider nicht die C Syntax um die Variable im EEPROM zu
> speichern.

Bedenke, dass man bei AVR das EEprom nicht einfach wie RAM adressieren 
kann. Da muss man den Umweg über Hilfsfunktionen nehmen. Ist alles dort 
erklärt:

Siehe 
https://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html

[Oliver R. (koreif)]

Danke Steffan, das hat die Fehler behoben.
Das mit der groß/klein Schrift war schon peinlich^^

Ich habe immer noch paar Fehler wo ich echt nicht verstehe wo das 
Problem ist.

tmp = tcpOpen( remoteIp , 1397 , 1234 , NULL ); // Verbidung oeffnen

erzeugt die Fehlermeldung: undefined reference to `tcpOpen'
Obwohl tcpOpen() mir von der DIE vorgeschlagen wird.
In der main wird net_tcp.h eingebunden

 #include "net_tcp.h"

Diese enthält:

 uint8_t tcpOpen(uint8_t * ipAddr, uint16_t remotePort, uint16_t localPort, connHandler handler);

Die implementierung in net_tcp.c sieht folgendermaßen aus:

 uint8_t tcpOpen(uint8_t * ipAddr, uint16_t remotePort, uint16_t localPort, connHandler handler)
{
  uint8_t * mac;
  uint8_t ind;

  // Prüfe, ob Verbindung bereits existiert
  ind = tcpGetConnHandle(myIpAddr, ipAddr, localPort, remotePort);

  if(ind != 255)
  {
    if(debugLevel & DEBUGLVL_STACK_TCP_ERROR)
    {
      usart_send_line_P(PSTR("tcpOpen: conn already exists"));
    }
    return ind;
  }

  // Suche nach freiem Eintrag in TCP-Verbindungsliste
  ind = tcpGetFreeConnEntry();

  // Kein freier Eintrag mehr vorhanden
  if(ind == 255)
  {
    if(debugLevel & DEBUGLVL_STACK_TCP_ERROR)
    {
      usart_send_line_P(PSTR("tcpOpen: connList full"));
    }
    return 255;
  }
  else
  {
    // MAC-Adresse zu IP-Adresse ermitteln
    mac = arpGetMac(ipAddr);

    tcpConnList[ind].handler = handler;
    tcpConnList[ind].localPort = localPort;
    tcpConnList[ind].remoteIp[0] = ipAddr[0];
    tcpConnList[ind].remoteIp[1] = ipAddr[1];
    tcpConnList[ind].remoteIp[2] = ipAddr[2];
    tcpConnList[ind].remoteIp[3] = ipAddr[3];
    tcpConnList[ind].remotePort = remotePort;
    tcpConnList[ind].closeAfterSend = 0;

    // MAC-Adresse ist noch nicht bekannt: ARP Request absetzen
    if(mac == NULL)
    {
      tcpConnList[ind].timer = TCP_ARP_REQUEST_TIMEOUT;
      tcpConnList[ind].retryCnt = 0;
      tcpSetConnStatus(ind, TCP_STAT_ARP_REQUEST);
      arpRequest(ipAddr);
    }
    // MAC-Adresse bereits bekannt: Verbindungsanfrage senden
    else
    {
      tcpConnList[ind].iss = tcpInitialSeqCnt;
      tcpConnList[ind].sndUNA = tcpConnList[ind].iss;
      tcpConnList[ind].sndNXT = tcpConnList[ind].iss + 1;
      tcpSetConnStatus(ind, TCP_STAT_SYN_SENT);

      tcpConnList[ind].timer = TCP_ACK_TIMEOUT;
      tcpConnList[ind].retryCnt = 0;

      // Verbindungsanfrage erstellen und senden
      tcpCreatePacket(&pack, mac, ipAddr, remotePort, localPort, tcpConnList[ind].iss, 0, 0, TCP_FLAGS_SYN, TCP_WINDOW_LENGTH);
      enc28SendPacket(pack.buf, HTONS(pack.pkt.ipArp.ip.ipLength) + 14);
    }
  }

  return ind;
}

Andere Funktionen tcpSend(), tcpClose(), sowie die Variable 
tcpInitialSeqCnt, aus net_tcp.h werden ebenfalls nicht gefunden obwohl 
sie von der IDE vorgeschlagen werden.

Ich bedanke mich nochmals für eure Hilfe.

[Stefan F. (Gast)]

Es gibt da dreierlei Suchpfade:

- für die IDE
- für den Compiler
- für den Linker

Möglicherweise stimmen diese nicht überein.

Und dann musst du noch bedenken, dass der Compiler schon zufrieden ist, 
wenn er die Deklaration einer Funktion in einer Header Datei findet. Der 
Linker, der das ganze zu einem ausführbaren programm zusammen baut, 
braucht aber die compilierte Version der Funktion. Die findet er 
üblicherweise in einer *.o Datei die der Compiler aus einer *.c Datei 
heraus erstellt hat.

Vermutlich fehlt dir also die *.c Datei, in der die fehlende Funktion 
definiert ist. Oder sie wurde nicht compiliert, warum auch immer.

[Oliver R. (koreif)]

Ok habe das Compiler Problem nun gelöst.
Lösung:
Im Projekt im "Solution Explorer" auf "Show All Files" gehen und dann 
alle Datein mit Rechtsklick über "Include To Project" zum Projekt 
hinzufügen.

Nun scheint alles zu funktionieren außer das Data Memory Usage mit 
116,2% überschritten wird.
"Data Memory Usage : 4759 bytes   116,2 % Full
Warning: Memory Usage estimation may not be accurate if there are 
sections other than .text sections in ELF file  (Memory Overflow)"

[jo mei (Gast)]

Oliver R. schrieb:
> Nun scheint alles zu funktionieren außer das Data Memory Usage mit
> 116,2% überschritten wird.

Na hättste halt mal von Anfang an aufs richtige Pferd gesetzt.
Will heissen W5100 oder W5500. Dafür gibt es auch "Libs". Ist
schneller und verbraucht deutlich weniger Speicherplatz für
die Bedienung des Netzwerks da Vieles bereits im Chip abgehandelt
wird.

So gesehen ist der ENC28J60 wirklich ein Teil von vorgestern.

[Stefan F. (Gast)]

// Die folgenden zwei defines beeinflussen maßgeblich den RAM-Verbrauch der Firmware.
// Diese sollten für die jeweilige Anwendung entsprechend angepasst werden, um Speicher zu sparen.

#define TCP_RXTX_BUFLEN             512         //!< Anzahl Bytes für jeweils Sende- und Empfangspuffer
#define TCP_MAX_CONNECTIONS         3           //!< Max. Anzahl gleichzeitig geöffneter Verbindungen

Für dein Hallo-Welt brauchst du schätzungsweise nur 50 bytes Puffer eine 
Verbindung.

[Oliver R. (koreif)]

Danke für eure Hilfe.

Ich habe das Problem gelöst indem ich TCP_MAX_CONNECTIONS von 3 auf 1 
reduziert habe.

Das Projekt compiliert aber leider ist mir nun aufgefallen das der 
ENC28J60 auf dem myEthernet Board nicht an dem SPI Bus angeschlossen ist 
sondern an I/O Ports (D2=SO, D3=SI, D4=SCK, D5=CS)(Schaltplan befindet 
sich im Anhang)
Der Code bleibt in der enc28j60.c in der Zeile 462 „spiWrite(ENC_SPI_RCR 
| regAddr);“ hängen. Die Funktion wird in den Zeilen 736-743 
implementiert.
Besteht die Möglichkeit auf diesen Ports ein SPI Bus zu simulieren? Hat 
dort wer Erfahrung?

Zu meiner Aufgabe:
Ich muss über ein Mikrofon Daten sammeln, mit einer ADC Auflösung von 
mindestens 12 Bit. Ich muss 40.000 Messungen die Sekunde auswerten und 
diese an einen PC übertragen. Daraus ergeben sich ca. 0,08MB/s an Daten.

Zu dem W5500:
Ich könnte noch umsteigen, aber dafür müsste ich mir sicher sein, dass 
ich das dann ohne Probleme umgesetzt bekomme. Ist es trivial die 
Bibliothek in ein Mikrokontroller-Board einzubinden.

[Stefan F. (Gast)]

Ich glaube nicht, dass du diese Geschwindigkeit mit den Chips überhaupt 
erreichen kannst. Meine ähnliche Anwendung mit einem parallel 
angebundenen CP2201 kam auf 50k Byte pro Sekunde.

Mit einem Wiznet Controller stehen die Chancen viel besser.

[jo mei (Gast)]

Oliver R. schrieb:
> Daraus ergeben sich ca. 0,08MB/s an Daten.

Schon anspruchsvoll.

Oliver R. schrieb:
> Zu dem W5500:
> Ich könnte noch umsteigen, aber dafür müsste ich mir sicher sein, dass
> ich das dann ohne Probleme umgesetzt bekomme.

Das geht auch nur vielleicht. Kommt sehr auf die Datenpaket-
Grösse an. Kleine Pakete über TCP ergeben eine recht niedrige
Datenrate. Die Wiznet Chips haben auch ihre Latenzzeiten und die
Übertragung per SPI will auch getan sein. Über UDP wäre es
schneller aber da müsstest du schon genau wissen was du brauchst
und was das für Risiken birgt.

Ich würde für diesen Zweck auf jeden Fall eines von den STM32
Nucleo Boards mit Ethernet Anschluss verwenden. Wenn es mehr
Boards sein sollen dann reduziert nachbauen. Oder eine
Kombination aus STM32 f407 Blackboard und Ethernet PHY zusammen-
schustern. Ist die einfachste Möglichkeit ins LAN zu kommen.

[jo mei (Gast)]

Oliver R. schrieb:
> techb_schaltplan-myethernet.png

Der ATMega644 hat übrigens 3 Vcc Pins die alle weit voneinander
entfernt liegen. Deshalb braucht er auch 3 (in Worten: drei)
Abblock-Kondensatoren und nicht nur einen ärmlichen.

Wer das nicht glaubt wird bestraft und merkt es nicht mal.
Naja, vielleicht später mal ....

[Oliver R. (koreif)]

Ich weiß das das myEthernet Board das nicht Schaft. Mir geht es erstmal 
darum überhaupt Daten von meinem Microcontroller an den PC zu schicken.

Kennt irgendwer eine Möglichkeit wie ich den ENC auf dem myEthernet 
Board ansprechen kann obwohl dieser nur an den I/O Ports(D2=SO, D3=SI, 
D4=SCK, D5=CS) angeschlossen ist und nicht an dem SPI Bus?

[Stefan F. (Gast)]

Da musst du wohl eine soft-spi Schnittstelle implementieren. Stichwort: 
Bit banging

Ich bezweifle dass sich die Mühe für das Olle zu langsame Teil lohnt.