14. Networking and communications

This week I will:

  • Send a message between two projects (group project)
  • Design and build a wired &/or wireless network connecting at least two processors (individual project)

Results

  • Made serial bus bridge and 3 nodes

  • Programmed boards

  • The bridge board had power through the TTY cable, but I had to provide a power source to the node boards using a USB adapter.

  • I flashed all of the boards with the address of “0” and the are all double flashing when I push “0”. I reprogrammed them with the proper address and they will double flash when their respective number is pushed, but they still double flash when “0” is pushed. Only “node 1” is displayed in the terminal; the other node responses are not displayed.

  • I decided to erase the chips and start over. I erased “0” first; it does not single, or double flash anymore, but the other boards do through the serial bus cable using the TTY cable. Very cool!

  • So, I recompiled the code after placing it back in the “0” condition.

Code Example

jimhart@jimhart-Xubuntu2:~/serialbus$ sudo make -f hello.bus.45.make
[sudo] password for jimhart: 
avr-gcc -mmcu=attiny45 -Wall -Os -DF_CPU=8000000 -I./ -o hello.bus.45.out hello.bus.45.c
avr-objcopy -O ihex hello.bus.45.out hello.bus.45.c.hex;\
avr-size --mcu=attiny45 --format=avr hello.bus.45.out
AVR Memory Usage
----------------
Device: attiny45

Program:     766 bytes (18.7% Full)
(.text + .data + .bootloader)

Data:          4 bytes (1.6% Full)
(.data + .bss + .noinit)


jimhart@jimhart-Xubuntu2:~/serialbus$ sudo avrdude -p t45 -P usb -c usbtiny -U flash:w:hello.bus.45.c.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9206 (probably t45)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "hello.bus.45.c.hex"
avrdude: input file hello.bus.45.c.hex auto detected as Intel Hex
avrdude: writing flash (766 bytes):

Writing | ################################################## | 100% 1.15s

avrdude: 766 bytes of flash written
avrdude: verifying flash memory against hello.bus.45.c.hex:
avrdude: load data flash data from input file hello.bus.45.c.hex:
avrdude: input file hello.bus.45.c.hex auto detected as Intel Hex
avrdude: input file hello.bus.45.c.hex contains 766 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.34s

avrdude: verifying ...
avrdude: 766 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

avrdude done.  Thank you.

jimhart@jimhart-Xubuntu2:~/serialbus$ sudo python term.py /dev/ttyUSB0 9600
  • Tested serial bus communications

  • Communicated through terminal using TTY cable

  • So far, I found that I only needed to change the node_id and nothing else in the code.

  • I will change the node_id to “2” to test my findings. Instead of doing a forced erase, I decided to reprogram directly since I found out from Lady Ada that an auto-erase occurs before programming unless it is prevented.

  • The LED on the board stayed on after programming. I am not sure why. I will program it again.

  • The LED stayed on again. I erased it again and the LED went out.

  • The LED on the board stayed on after programming.

  • The board with node_id = “2” is not providing a text output, but it does double flash. I am replacing it with a different board to see if it is a board fault. I programmed the new board and the LED went out after programming, but then came back on. The same results occured.

  • I uploaded the .hex file with the node_id = “2” into the board acting as “1” and tested it to find that “node 2” was displayed. It must be a board problem in 2 boards.

  • I successfully programmed the previously “2” board with the “1” .hex and the LED went out after programming. It did not diplay or flash twice.

  • I discovered when I put my hand close to the faulty board with the programming cable attached, the LED came on as it it sensed my hand/finger. I will try the other board and see if I get the same effect.