Tuxgraphics AVR ethernet kit notes

From Helpful
Jump to: navigation, search
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, or tell me)


AVR board with ethernet. Lower-cost than an Arduino with an Ethernet shield.

Specifically an Atmega328, an ENC28J60, an ethernet socket, a clock source, and some resistors and capacitors to make everything work.

Programmed via ICSP


The ENC28J60 is a 3.3V chip, and since the AVR can run at that too, the entire board is at 3.3V.

The 3.3V regulator seems comfortable with 5V..12V and is rated at 500mA, and you should assume the ENC28J60 takes 250mA. Keep this in mind when powering other things through the regulator.

The exception to the-board's-at-3.3V is that CONN3 exposes the board input voltage (apparently largely to switch something of that voltage via pin13 via the 100mA transistor on the board, that you could replace with something slightly beefier)


Ethernet is connected via SPI.

Most AVR pins are exposed, via as-yet unpopulated holes.

Pin 13 has a LED, and a transistor that can deal with 100mA (on CONN3). Taken from the voltage input before the board's regulator. Can also be a useful spot to take that voltage for other specific purposes.


The ENC28J60 has a 25MHz clock, and can output (an divided version of it) on one of its pins. The board uses this for the AVR's clock.

The ENC28J60 can be told to divide by five different things:

  • 8, for 3.125MHz
  • 4, for 6.25MHz, the ENC's default
  • 3, for 8.333MHz
  • 2, for 12.5MHz, which is what the tuxgraphics code seems to use
  • 1, for 25MHz, which is too fast for the AVR

Note that an AVR at 3.3V has a lower max clock than it has at 5V. The 12.5MHz is technically slightly beyond specs at 3.3V, but proves quite stable.

The practical choices here are:

  • use the default 6.25MHz it gets
  • programming the AVR's fuses to use its internal clock (probably at ~8MHz)
  • telling the ENC28J60 to give you 8.33MHz or 12.5MHz

As long as you define F_CPU (as the clock frequency in Hz), the util/delay.h functions (delay_ms, delay_us) should work as intended at any speed(verify).

Arduinoish code that assumes 16MHz (doesn't use F_CPU) may well run into some timing trouble.



This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, or tell me)

(This is largely just sifting through Guido Socher's code)


The ENC28J60 is a layer-2 device, and effectively promiscuous by default(verify).

It has a 8KB buffer and a round-robin replacement thing, which means you can easily miss packets if you do not pick them up fast enough.

Due to how switches work, we should mostly just receive unicast for our MAC, and broadcast (of which there often isn't that much).

...but it can't can't hurt to tell the ENC to filter basically the same way, for example:

accept unicast only if it's for us (our MAC)
accept broadcast only if it's ARP
dump everything else.

You may also still want to limit the rate at which you send packets at this board, particularly if your code has things to do other than reading out packets from the network.


Look at the source for the 'Embedded client'


Most common, in general, is to indicate link on one and activity on the other.

For some debug it can be handy to change that - they can be configured to indicate link status, duplex status, activity (transmit, receive, or both), collisions, and a few combinations (link+receive, link+receive+transmit, duplex+collision), or to permanently be off, on, or blink.

(note that for activity to be more visible, the led can stretch the amount of time it's on for each event)

Building on tuxgraphics' embedded client



undefined reference to `__eerd_byte_m328p'

That symbol is apparently in an old version of (AVR) libc. The quick (and quite dirty) workaround is to copy an older version, something like:

cp /usr/avr/lib/avr5/* /usr/avr/lib/

I don't yet know the proper fix.