a class project, we are to implement Internet 0. The project consists of the
- A sending block to send a UDP internet0 protocol. Implementation:
- A circuit board with a Tiny15
- Assembly code to send the protocol
- Lines for power and signal
- An LED to troubleshooting and to indicate transmission
- A receiving block to translate the Internet0 protocol to a
- AT Mega32 with C code to receive Internet0 transmission
- Internet0 transmission must be then re-sent as UART to
the serial port of the computer
- Computer software to receive the information received
from the receiving block and transmit this through the internet.
- Python code to receive information from the serial port
and transmit this into the internet
We broke up into teams. I was on the team
to design the board and write the code for the sending block. Zach,
Christine, and Emma were also on the team. My main function on the team was
to debug the sending code that Emma wrote, and get the board working. From
our experience prototyping the board with the vinyl cutter, I would recommend
- Don’t use the vinyl cutter for first-time boards which
might need extensive debugging. The board is too fragile for extensive
- There is a standard practice to make vinyl-cut boards
more robust by dabbing hot glue over the components and the board. Don’t
do this until after the board has been debugged. Otherwise, it is very
difficult to probe components.
In terms of debugging the code, the only
real “gotcha” was knowing to recognize that the 3-word stack of the TINY15
was overflowing. Other things of note:
- The z register has to be shifted 1 bit to the left
(multiply by 2) when reading words from the program memory, since each
word in the program memory is 2 bytes long.
The sending code is fairly
straightforward. Now that I know the instruction set better from this
experience, I’m convinced more than ever of the TINY15 as a real workhorse. I
really like finding the most efficient (read “cheapest”) way to do things, so
I wondered if it might be possible to use an ATTINY15 instead of the Mega32
for receive. Here is my outline for how this might be done:
- Wait for a
receive an interrupt on I0 pin
- Set the interrupt registers
- Must adjust for the time for the interrupt to be
serviced (4 clock cycles)
- How long is an instruction cycle in clock cycles?
- Set the I0 pin to trigger an interrupt on a falling
hold in a loop looking for the pin to go high
- Dumb, 'cause the processor can't do anything else (not
that it has anything else to do...unless there is SETI at home for
- My guess is, if we have only 1 instruction cycle to
catch it, we might miss it unless we do an interrupt...
receiving the click, time how long it takes for the next click to come
in, so we know the speed of transmission.
- Best: Use
the built-in timer. Set the timer to 0, wait for another interrupt and
read the timer value
- Set the timer, scalars for the timer, etc.
- Interrupt takes 4 clock cycles to process. Must take
this out in the math.
Wait in a nested loop decrementing registers. 2s complement the
registers and use them in a delay loop for timing later.
- Definitely we will risk missing the next signal if we
are busy dealing with nested loops, unless we make the clicks bigger
- The timer is more precise, although it won't matter a
lot at the speeds we are talking about.
- Read in
each bit, using the timer or the register values from 2.
- Best: use
the timer to interrupt when it reaches 0. Then reenable I0 interrupt.
use the register value countdown. Then watch the pin in a loop.
- Multiply the timing values by 2 (shift left) to double
the length of delay found in (2)
- We need to start looking for signal slightly before we
really expect it, but not a lot before we expect it, or else we might
pick up the impulse response.