9. Embedded Programming

This week I worked on logic for my final project, basic Raspberry Pi/Arduino electronics and programming my EchoHello board.

Triangle Game Logic

There would need to be communication between the buoys, perhaps by means of a network, to indicate the status of the game (in play, stopped, restarted) and the movement of the ball (when interacts with other buoys). I've sought to work out the logic for the game which could feature three buoys fitted with sensors. To do this, I've used the loose logic of an if/else statement.

Scenario 1: Continuous Play

  1. if Ball pass A {
    • no light (change)
    • Buoy A = 1 (Store Buoy A)
    • tell Buoy B + C
  2. Buoy B + C
    • Sensor ignore ball pass x1 (ie. leaving inner triangle)
    }
  3. if Ball pass Buoy B {
    • no light
    • Buoy B = 1
    • tell Buoy A + C
  4. Buoy A + C ignore pass x1 }
  5. if Ball pass Buoy C {
    • no light
    • Buoy C = 1
    • tell Buoy A + B
  6. Buoy A + C ignore x1 }

Potential problem: If the ball stops in the middle, ie. the sensors would still be waiting for a pass to ignore. But if this did occur, it is most likely because it has bumped off a buoy, which would result in a different set of logic instructions, for Scenario 3.

Scenario 2: Fault

  1. if Ball passes A {
    • no light
    • Buoy A = 1
    • tell Buoy B + C
  2. Buoy B + C ignore x1 }
  3. if Ball pass Buoy B {
    • no light
    • Buoy B = 1
    • tell Buoy A + C
  4. Buoy A + C ignore x1 }
  5. if Ball pass Buoy A{
    • light activated (Buoy A)
    • indicate fault (Buoy A)
    • indicate score* = +1 (to player 1)
    • Buoy A = Return to 0
  6. Buoy B + C = ignore x1 }

*Note on keeping score: I have taken the decision not to keep track of the score in the game. Doing so adds another layer of complexity which will be difficult to match to the interaction between of the three buoys, the two opponents and the ball. Also, it may be considered be more fun for the opponents to keep track of the score themselves.

Scenario 3: Score

  1. if Ball pass A {
    • no light (change)
    • Buoy A = 1 (Store Buoy A)
    • tell Buoy B + C
    • Buoy B + C ignore ball pass x1
  2. Else (impact) {
    • Buoy B falls*
    • light activated (Buoy B)
    • reset = 1 (Buoy A + B + C)
    • score +1 (eg. opponent 2)
    }
  3. continue continuous play }

* In the Shamrock Rovers video, the bottles knock over easily, they are thin and light. My device will be heavier so the impact will register differently (movement, light) but also in an impactful way.

I continue my final project work in week 14.

Arduino/Raspberry Pi

I worked with the Arduino Starter Kit and tutorials to understand basic circuitry and inserting buttons and LEDs to the breadboard. This gave me further practice at selecting resistors and being able to distinguish between them.

I knew that we would need to use GPIO Pins as part of this week's assignment and this article proved a useful introduction. Togther with Thierry, I experimented in writing basic programs in Arduino IDE to write to the breadboard in Python and C. The program was a variation of the blink program, as outlined on the group page. In this group work I also learnt to install the additional ATTiny libraries. A couple of other references were

I continued to work with the breadboard, experimenting with dials, IR sensor, temperature sensor, and tilt switch. I later found the following articles useful in understanding ATTiny's role in programing boards (direct or with breadboard).

Datasheet & EchoHello Board

The datasheet for ATTiny 24/44/84 provides a comprehensive analysis of its capabilities. There is information on its pin configurations, memory and clock systems.

The pin configurations provide a useful reference to when connecting routing and wires to the microcontroller. With practice, it becomes clearer which are available for use beyond VCC, GND and Reset. Knowing the benefit, for example, of using an ATTiny84 over an 44 allows you to plan a project, especially when creating a machine with a lot of pins.

Chapter 5, on Memories, introduced me to the flash memory available on the microcontrollers. EEPROM forms the core memory that we can use to upload programs – 256k is available on an ATTiny 44 and 512 on an ATTiny 84. Table 5-1 indicates the variable programming time when erasing, writing or erasing and writing in one operation.

Chapter 6, on Clock Systems proved challenging to understand. It appears there are different clock cycles for different operations, such as powering up, managing power and for different parts of the microcontroller, such as the ceramic resonators. These clock cycles can be measured using an on-chip oscillator, perhaps to measure the efficiency of your board eg. data speed.

I initially wired up my TinyISP to the EchoHelo board using a series of femal-female jumpers on the six-pin connector. Later we created a dedicated flat cable to make this process easier. I attempted to power the connection using the TinyISPs USB and an adaptor.

My TinyISP was detected in the System report along with my adaptor and I worked through the following tutorial to install avrdude.

My initial board failed to load avrdude in the Terminal. I attempted the makefile system but this also did not work. In the Arduino IDE, the TinyISP also failed to load.

At this point, I discovered an error on my board. You can read about the redesign/rerouting/soldering in the Electronic Design assignment.

EchoHello Board Programmed

After preparing a second board, I checked if I could first program my Arduino. To do this I selected the following setting under Tools in Arduino IDE,

  • Board: Arduino/Genuino Uno
  • Port: USB
  • Programmer: AVRISP mkll

I uploaded the basic blink example successfully. After recreating the EchoHello board, I attached it to an Arduino Uno using jumper cables. The wires we laid in this configuration,

  • VCC – 5V (dark grey/yellow wire)
  • GND – GND (brown wire)B
  • MOSI - tilda 11 (white wire)
  • MISO – tilda 10 (blue wire)
  • SCK – 13 (green wire)
  • RST – 12 (purple wire)

I then uploaded a variation of the basic blink example to my custom board, declaring an integer for an ledPin. To do this I selected the following setting under Tools,

  • Board: ATTiny24/44/84
  • Processor: ATTiny44
  • Clock: External 20Mhz
  • Port; USB
  • Programmer: Arduino as ISP

            const int LED_BUILTIN; 
            const int ledPin = 7;
 
                void setup() {
                pinMode(ledPin, OUTPUT);
                pinMode(LED_BUILTIN, OUTPUT);
                }
 
                void loop() {
                digitalWrite(ledPin, HIGH);
                digitalWrite(LED_BUILTIN, HIGH); 
                delay(1000);
                digitalWrite(ledPin, LOW);
                digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
                delay(1000);
                }

The program uploaded successfully, however, the timing appeared warped: The delay was longer than was set (100) and even when reduced to 500 did not correlate. This may have been due to a damaged or faulty crystal.

Further Learning

Perhaps the main question I had over this week is what role do programming languages play in connecting devices. It became clear that both python and C are equally able to deliver interactions with an output, whether an fused LED or an external one.

In the future, I would like to learn more about the networking of boards and how they might work together as slave and master. I have identified that it is more challenging to add a second slave to the proceeding network, especially over a wireless network. To this effect, my plan would be to first create a basic wired network with master and one slave and add to this learning. The triangle game requires that I have two slaves if I want the game to provide feeback on the scoreline.

Back to the top

Jump to...
Downloads right-click, save as