openPowerSwitch 2/… : Playing with ethernet interface and setting-up a test env

Abstract : First experimentations with an ENC28J60 (ethernet MAC+PHY interface from Microchip). Setting up a minimal server, and test it in an isolated network environment.

Introduction

As usual, let’s introduce the hardware. ENC28J60 is a 10 base T MAC+PHY <=> 40MHz SPI interface. In runs under 3.3V but is designed to handle 5V logic seamlessly. It embeds 8Kb of RAM to buffer ethernet frames.

enc28j60

An ENC28J60 module for prototyping. Many clones, in various form factor, are available.

Let’s review the pinout of the module (if not exhaustive, rather complete for most purposes).

  • CLKOUT : a configurable clock source. By default the modules start clock it @12.5MHz but it can be configured/scaled, by writing chip registers through SPI commands.
  • INT : Interrupt pin
  • WOL : the “Wake On LAN” pin, usable to wakeup the interface controller in sleep mode.
  • SO : Slave Out (MISO)
  • SI : Slave In (MOSI)
  • SCK : SPI ClocK
  • CS : Chip Select. Hold low if you want to enable the chip as the slave listening the master
  • RESET : No comment.
  • Vcc : NOTE TO MYSELF : PLS read datasheet / check module wiring and DO NOT write crap here instead
  • GND : The ground.

If you lacks knowledge about the SPI protocol, let’s review the basic :

Back to basics : SPI

SPI is an electronic protocol that allows full duplex (read and write simultaneously) serial communication between two chips.

The master “clocks” the line, and on each tick each peer reads the bit provided on its input line, and provides next bit to write on its output line. Communications can be single sided, though. For instance, master can issue a “register read” command to the slave (which, in  the meanwhile does not write anything to the master). While the slave answers, the master has nothing to say to the slave. Then the communication ends. HALF DUPLEX !

Maybe this chip is able to do real full duplex but I’m unsure. Anyway, the driver presented in this article does NOT. (It was a bit curious to me at first to realize that the chip acheives most communication NOT taking advantage of full-duplex. So why SPI ? Because it is CAN BE fast. And presently IT IS.)

If you want more information, or want a refresh of your already acquired knowledges, it invite you to check this damn good article on Hackaday.com.

Software driver for the ENC28J60

The datasheet for ENC28J60 is pretty well written and clear, but it is always challeging to write such a driver library “from scratch”, even with a good datasheet. By the way of discussing about full/half duplex on #avr (on freenode’s IRC), @Lambda_Aurigae, advised me to have a look on the tuxgraphics project.

I did and found what I would call an “half driver” : the basic parts of the datasheet are implemented (…roughly, the half…) but not the advanced features, and among them, what seems very important to me, the interrupt part.

In pratice, this driver is the bare minimum to start with, and also sufficient to integrate with already existing higher-level software (but let’s discuss this in part 3).

After few digging, I forked a github repository that contains an “UDP spoutnik” (beep, beep, beep !). IIRC I did a few Makefile re-working to fit my env, but it compiled, installed and runned seamlessly.

Implementing

I caugh the UDP packets using this setup :

oPS_20170219

And, not shown on photograph, I used a TU2-ETG (that is, an ethernet-to-USB converter) to isolate the prototype. I just captured traffic on the network interface related to this device with wireshark, and could see the beep UDP packet spawing every second !

The workbench can be schematized by the following:

setup_ops

A linux laptop is connected by USB to an Arduino and an TU2-ETG device, with is a network interface. The net dev is connected to the ENC28J60, which is powered by and connected to the Arduino. Finally a relay board is connected to the Arduino : the aim is to control the relays using the network interface. NB : INT (magenta) wire is not used yet, as far as I know, by the driver (eventhough it enables the interrupt flag, it does not implement a callback… WTF ? But there is room here from improvment)

That allowed me to validate both at once the tuxgraphics simple driver and my ethernet module ! This was a really happy evening I remember ! Double headshot ! But I did not much by myself, so let’s work now…

Toward a real test environment…

Right now the TU2-ETG provides some network isolation and allows monitoring through wireshark… But this is not enough !

We want this interface to behave like a “natural network”, and, mainly, by providing (coherent and consistent) answers to DHCP request.

I dediced, that, while 192.168.0.0/8 was my main network, this interface will behave as a 192.168.2.0/8 network. The laptop is 192.168.2.254 on this network, and we want it to serve DHCP requests.

So we have to install the dhcp SERVER daemon package (link is for Arch Linux, but ths package exists for any Linux distribution). After the installation, on my side the configuration was as simple as editing /etc/dhcp.conf and :

  • declaring the “normal” network on which I don’t want the daemon to serve anyone :
subnet 192.168.0.0 netmask 255.255.255.0 {
}
  • declaring the “special” subnet on which I want the daemon to act as a server :
subnet 192.168.2.0 netmask 255.255.255.0 {
   range 192.168.2.2 192.168.2.252;
}

after that it was possible to start the interface and the server…

$ ip a show
[...]
5: enp0s20u6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:50:b6:??:??:?? brd ff:ff:ff:ff:ff:ff

 

$ sudo ip link set enp0s20u6 up
$ sudo ip address add 192.168.2.254 dev enp0s20u6
$ ip a show
[...]
5: enp0s20u6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:50:b6:??:??:?? brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.254/32 scope global enp0s20u6
       valid_lft forever preferred_lft forever

 

$ sudo strace /usr/bin/dhcpd -V -4 -q -cf /etc/dhcpd.conf -pf /run/dhcpd4.pid

 

Testing the DHCP server

As we can test the server using our “under development” module, lets use some of that raspi laying around !! I just booted a minimal system, connecting the raspi to a monitor and a keyboard, and eventually to RJ45 “auxilliary network”, after boot completed.

raspi_is_DHCPed_by_laptop

Conclusion

I started to integrated uIP stack on the workbench prototype, and I have hope it will work soon ! I guess the problem I’m facing right now is about braodcast and packet filtering at the ethernet module level… So I hope to solve it by tweaking the network_init() function that initialise the eth chip…

I saw (in wireshark) the DHCP server offer a valid adress on the subnetwork to my work-in-progress device requesting one… But sadly, the latter did not take the offer into account ! Look at traces, it seems the interface does not see any packet (at least… matching its filters…)

setup_photo

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s