L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 1

As something a little different this year, I offered to open source the Lab. 1 report to a number of students who had completed Assignment. I would like to thank J. for taking the time to do this. His comments were very constructive – and I learnt a lot about which C++ syntax you guys and girls have been taught. Task 1: Quick check of the Lab. Station Hardware and Software

Task 1.1: Check Blackfin BF533 evaluation board works with CCES software and J-TAG hardware Task 1.2: Configuration of Logic Lab Station (LLS) with Blackfin

Task 2: Build a test project to check functionality of uTTCOS LED and Switch Utilities (driver code) Task 2.1: Add a WaitAwhile( ) timer function Task 2.2: Write test for uTTCOS_InitLED( ), uTTCOS_WriteLED( ), uTTCOS_ReadLED( ) Task 2.3: Write and use your test to check uTTCOS_ReadLED( ) and uTTCOS_WriteLED( ) work correctly Task 2.4: Write a test to check uTTCOS_InitSwitches( ) and uTTCOS_ReadSwitches( ) work.

Task 3: Start a new test file Test_My_ReadSwitchesASM in Lab1Test project and start a new Lab1Library project Task 3.1: Control the Blackfin GPIO registers – control the FIO_FLAG_D(GPIO data register) in ASM Task 3.2: Control the Blackfin GPIO registers – control the FIO_INEN (input enable) register in CPP Task 3.3: Control the Blackfin GPIO registers – control the FIO_POLAR (input polarity) register in ASM Task 3.4: Control the Blackfin GPIO registers – control the FIO_INEN (input enable) register in ASM

Task 4.0 New test file Test_InitSwitches.cpp in Lab1Test project Task 4.1: Check whether uTTCOS_InitSwitches( ) works as expected. Task 4.2: Modify test for uTTCOS_InitSwitches( ) to develop your version My_InitSwitchesASM( ) routine Task 4.3: Develop a My_InitSwitchesASM( ) routine

Task 5: We have been working so hard -- Here is a video game based on a previous test. No – perhaps not a good idea.I think we should leave the video game test for another day. I am sure that you will not be able to win – most of the time

Task 6: Making use of Lab0_LEDLibrary to demonstrate a Super Loop operating system during Lab1 Task 6.1: Lab1SuperLoop project Preparation Task 6.2: Develop a Super Loop OS name Task 6.3: Initial TARD-OS development Task 6.4: Making the Lab1Superloop Project Heart Beat using LED_Flash code from Lab0_LEDLibrary Task 6.5: More details of the Lab1Superloop Project Heart Beat Task 6.6: Add in the Super-loop timing control for the tasks Task 6.7: Add a new super loop TARD-OS task into LOOP1 to ECHO_SWITCHES_TO_LEDs Task 6.8 Dr. Smith “Special Programming Tricks” Corner – Use of MACROs could simplify programmi

Task 7: Driving the virtual car (Shown on Blackfin LEDs) Task7.1: A new TARD-OS Task to automatically drive a “virtual car” (Shown on LEDs) Task7.2: TARD-OS Task to record your “commands” to drive a “virtual car” (Shown on LEDs) Task 7.3: TARD-OS Task to “play back your commands” to drive a “virtual car” (Shown on LEDs) Task 7.4: Design problem to solve – how do we decide that we should keep-recording car commands or stop recording car commands – we

have 4 hardware switches and they are all in use

80% of Lab. 1 is now completed (Mark B+ / A- / A)

RECOMMENDATION – time consideration. You might want to consider reading the rest of the lab but not doing any more coding if you are struggling with the C++ coding level

NOTE: You can’t get any more marks for the LAB 1. report by handing in a modified Lab. 1 report. HOWEVER you can get more marks if you show an improved LAB. 1 demo later in the term when you have gained more experience

Last 20% towards A+ on Labs. Lots of work that reuse the original ideas. Possibly four times as long debugging for a quarter extra marks. You make the decision how far to go

Task 8: Controlling a “real” radio controlled (RC) car Task 8.1: First steps to driving the real car and virtual car at the same time Task 8.2: Driven the second virtual car is worth 10%

Task 8.3: Driving the real car is worth 10% (and 10% bonus – because it is hard to drive the real car correctly)

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 2

Task 1: Quick check of the Lab. Station Hardware and Software

Lab 1 Block Diagram (Opportunities for a Quiz or Exam questions are obvious)

Task1.1: Check Blackfin BF533 evaluation board works with CCES software and J-TAG hardware Run Lab 0 Tests for LED1( ) and LED3( ) working together, or final Lab0 uTTCOS demo (If TA around – then get them

to sign off on final Lab 0 demos. Power down Blackfin

Task 1.2 Configuration of Logic Lab Station (LLS) with Blackfin Power down logic lab station (LLS). Use a 4 pin cable to connect a set of 4 switches at the bottom of the LLS (LLS S3-S0) to a set of 4 LLS LEDs (LLS L15 –

L12) at top of LLS. o Check cable polarity – The colour edge to the right of the 4 switches should be to the right of the 4 LEDs

Power up LLS -- check that LLS S3-0 switches turn on the LLS LED (15-12)so Note that LLS switches are press on and then press off

Power down LLS.

Plug the 50 pin cable from the Blackfin output to the Blackfin Extender board on the LLS. Say out loud “Press till it goes click” at both ends of the 50-pin cable

Connect GROUND on Blackfin Extender board to ground on LLS – keep wires as short and neat as possible Use a 4-pin cable to connect the 4 LLS switches (LLS S3- S0) to the 4 PF11 to PF8 lines on the Blackfin extender board.

o Leave the connections from the same LLS switches (S3 -0) to the LLS LEDs (L15-12) as a check of the hardwareo Connect the right most LLS switch (least significant LLS S0) to the top (least significant) PF8 lineo Connect the left most LLS switch (most significant LLS S3) is connected to the bottom (most significant) PF11 line o Later we will be making connections between PF1, 5-7 to LLS L7 - 4

Get your partner to check all connections Make sure and you are not one pin off in making the cable connections and the cable is not being twisted.

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 3

Power up Blackfin and LLS boards.

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 4

Task 2: Build a test project to check functionality of uTTCOS LED and Switch Utilities (driver code)

Task 2.1: Add a WaitAwhile( ) timer function to the Lab1 Library Build a Lab1Library project Add a Lab1.h file to the project’s src directory and add the following prototype and include file request

#include <blackfin.h> #include <uTTCOS2013/uTTCOS.h> void WaitAWhile(unsigned long int longer);

Add a WaitAWhile.cpp file to the library and insert the following code DO A CODE REVIEW, build “selected file”, record any errors missed by YOUR code review for your PSP

#include “Lab1.h”

void WaitAWhile(unsigned int longer) { // TOD – Nasty defect – don’t change anything till about Task 5 unsigned long int delay = 0xFFFF * longer; for (int count = 0; count < delay, count++) { count = count; // Something garbage to waste time -- compiler will indicate you can't type -- ignore it }

Task 2.2: Write test for uTTCOS_InitLED( ), uTTCOS_WriteLED( ), uTTCOS_ReadLED( )

Build an E-UNIT test project called Lab1Tests following Lab. 0 procedure. Check that the project builds and the default test fails

Use Settings | Linker | General -- Link the project to the CCES uTTCOS library and Lab 1 Library Use Settings | Compile | Preprocessor – Add an include path to “Lab1_Library/src” and “Lab0_Library/src”

I am not writing inside CCES and checking code as I go along So you had better consider this pseudo code and do lots of pair programing code review Do a lot of file saving and partial rebuilds to check syntax Make good use of CCES auto-complete capability (CNTRL-SPACE) to check the consistency of the spelling of the names

#include <blackfin.h> // WARNING -- Cutting and pasting Word quotes “this is” or ‘that’-- causes compiler error#include <stdio.h> // You will have to use CTRL-F to find and replace with the C++ quotes#include “Lab1.h”

TEST(DoLEDsWork) { // Get a value from the key board and display in LED char dummyRead[250]; // Buffer used by tests uTTCOS_InitLEDS( ); // Screen capture the error message that using the buffer[ ] causes for your Lab. 1 report // Explain why the error message is important but is expected (can be ignored) in this particular case int validTyping = 0; int request = 0; // Some people may prefer the more self-documenting while (validTyping == 0) which is more obvious when converting to ASM while (!validTyping) { // Manual – non-automated testing – UGH!!! printf(“Type in a hexadecimal number (0x?? format) in the pop-up window then press enter\n”); printf(“ Bit-pattern of the number should appear in LED lights\n”); gets(dummyRead); // Apparently some people have not used this C++ function to get a “string” from a keyboard validTyping = sscanf(dummyRead, “0x%x”, & request); // scanf( ) converts a C++ string into variable CHECK (validTyping == 1); // C++ check that a valid number was entered

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 5

} CHECK(request < 0x3F); uTTCOS_WriteLED(rrequest); printf(“Is the correct bit pattern displayed?\n”); printf(“Answer Yes or No and press enter\n”); gets(dummyRead); // Get a character string from the keyboard and then check its first character for a ‘Y’ or a ‘y’ CHECK( (dummyRead[0] == ‘y’)|| (dummyRead[0] == ‘y’));}

Task 2.3: Write and use your test to check uTTCOS_ReadLED( ) and uTTCOS_WriteLED( ) work correctly

You codeRecord screen shots for your Lab 1 report

Task 2.4: Write a test to check uTTCOS_InitSwitches( ) and uTTCOS_ReadSwitches( ) work.

TEST(Do_uTTCOS_SwitchRoutines_Work) { // Check that the uTTCOS switch routines work correctly char dummyRead[250]; // Buffer uTTCOS_InitLEDS( ); uTTCOS_InitSwitches( );

Unsigned char numbers[ ] = {0, 2, 13, 5, 4};

for (int count = 0; count < 5; count++) { printf(“Set this value 0x%x as a bit pattern in the switches \n” , numbers [count]);); printf(“Then type ‘GO’ in the pop-up window -- press enter\n The same bit pattern should appear in LED lights\n” gets(dummyRead);

unsigned int switchValue = uTTCOS_ReadSwitches( ); // Grab switch value using uTTCOS utility uTTCOS_WriteLED(switchValue); // Echo value to LEDS

CHECK(numbers [count] = = switchValue);

// From Lab 0 – we know that E-UNIT prints “char” values that are unreadable. // So use the C++ syntax of “CAST”ing into an integer so that “unsigned char” number values print CHECK_EQUAL((int) numbers [count], (int) switchValue); }

}

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 6

Task 3: Start a new test file Test_My_ReadSwitchesASM in Lab1Test project and start a new Lab1Library project

TASK 3.1: Control the Blackfin GPIO registers FIO_FLAG_D (GPIO data register) in ASM Details were in the class notes on 3rd October Add My_ReadSwitchesASM( ) ASM stub to Lab1Library Project Lab1LibraryASM.asm file

o Put #include <blackfin.h> at the top of the fileo In Lab report – explain why #include <blackfin.h> is needed (or what happens if not included)

Add extern “C” int My_ReadSwitchesASM(void ) to Lab1.h in Lab1Library

Use the Linker settings to add Lab1Library.dlb and the Preprocessor setting to Lab1Tests/src path to the Test project (Took me 5 mins to see that this was what was causing me a problem in getting the Test project to link)

Add a new test file Testing_MySwitchRoutinesWork.cpp using E-UNIT GUI Test driven development (TDD) – Copy and modify Lab1Test TEST(Do_uTTCOS_SwitchRoutines_Work) to become

TEST(Do_My_SwitchRoutines_Work) Make the new test call your function My_ReadSwitchesASM( ) instead of uTTCOS_ReadSwitches There is no valid My_ReadSwitchesASM code so the tests should fail – Test of the Test

o In your report – show a screen dump of the failed testo Explain, using the ASM-C++ calling conventions, why it might be expected that such a value is returned by the

unfinished My_ReadSwitchesASM( )?

Now add sufficient code to My_ReadSwitchesASM( ) to pass the tests (see class notes). Demonstrate that making use of volatile registers R0 – R3 and P0 – P2 in your routine.

o This routine accesses the GPIO data register. Look in the class notes and Blackfin hardware manual for its nameo To be able to use the macros lo( ) and hi( ) you will need to use the C++/Assembler safe header file

#include <blackfin.h> at the top of the ASM file Check that the tests pass NOTE: Bug in Eclipse that is inherited by CCES about interlinked projects that should cause each other to rebuild

o Make the changes to Lab1Library and rebuildo If you now rebuild the Lab1Tests (F7) it does not “know” the Lab1Library has been rebuilt so it uses the olde

version o We need to force Lab1Tests to use the new library

Method 1 – Easiest but very slow when there is a large project – Clean Lab1Tests project and rebuild Method 2 – Faster -- Go to Lab1Test/Debug directory – delete the Lab1Test.dxe from the project – rebuild Method 3 – The Open-CCES-me-Help GUI has a menu item to automate Method 2

TASK 3.2: Control the Blackfin GPIO registers – control the FIO_INEN (input enable) register in CPP Add My_DisableSwitchesCPP( ) and My_EnableSwitchesCPP( ) CPP stubs to Lab1Library Project Lab1LibraryCPP.cpp

file TDD – build tests to check that the functions work. The tests should fail as there is no valid code

o A little bit difficult to test My_DisableSwitchesCPP( ) as the tests that switches work will always fail – so how can you test the test? WIDFI for this special instance – use an XF_CHECK( ) and try to think of a better test later

o I took a version of TEST(Do_My_SwitchRoutines_Work) and made it TEST(Do_My_DisableEnable_Work)o I added DisableSwitchesCPP ( ) after InitSwitches( ) and XF_CHECK that a read switches test failedo Then I add the code EnableSwitchesCPP( ) after the XF_CHECK and did another test to check that reading switches

now passes.

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 7

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 8

TASK 3.2.A: Dr. Smith’s special programming cornerHere is a poorly written version of my CPP code

void My_DisableSwitchesCPP(void) { *pFIO_INEN = 0; }

The code worked but there was no equivalent of the ASM “ssync” function being used to force the writes to memory to occur now – so the code may be working by luck.

So I modified the code to be

void My_DisableSwitchesCPP(void) { *pFIO_INEN = 0; ssync( ); } The editor gave warning messages about ssync( ) not linked but it linked (using a definition in <blackfin.h> perhaps, but still a possible defect lerking in my code

FYI -- NOT PART OF THE LAB

We will be having further discussions in the class about the C++ language extensions called PRAGMAsThis particular #pragma is very commonly used anywhere somebody needs to speed up C++ code

Suppose I had typed void My_DisableSwitchesCPP(void) { *pFIO_INEN = 0; Ssync( ); } then the project would not be able link as Ssync( ) does not exist

If I added the following code to Lab1.h all the problems disappear – no editor or linker error message Explain why the project would now link and what the code means. In particular how are you allowed (or in this case must put) a CPP function in an include file – normally a very VERY bad programming

practice #pragma always_inline // This code “MUST” be placed in the Lab1.h file inline void Ssync(void) { asm("ssync;"); }

TASK 3.3: Control the Blackfin GPIO registers – control the FIO_POLAR (input polarity) register in ASM Add My_AdjustSwitchPolarityASM( ) ASM stub to Lab1Library Project – This modifies the GPIO FIO_POLAR register.

Very similar to My_ReadSwitchesASM( ) in its structure but needs a little more code (2 lines) – check class noteso This modifies the switch polarity so that ON becomes OFF and OFF become ON

I have used this expression in class “switches from active high to active low”. This polarity switch capability can be very useful in many embedded system situations

o This means you set the switches as b 1 1 0 0 (active high, active high, off, off) and the system reads the switches b 0 0 1 1 (active low, active low, off, off)

TDD – Copy and modify Lab1Test TEST(Do_My_SwitchRoutines_Work) to become TEST(AdjustSwitchPolarity) Place this define #define SWITCHMASK 0XF just outside the new test Modify the code to become

uTTCOS_InitSwitches( ); My_AdjustSwitchPolarityASM( );

Modify the CHECKs to become

unsigned int expected = (~numbers [count]) & SWITCHMASK; // Invert the expected pattern CHECK(expected = = switchValue); // I think the TEST logic is correct CHECK_EQUAL(expected, switchValue); // If not, fix my logical defect

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 9

Run the test -- There is no valid My_AdjustSwitchPolarityASM( ) code so the tests should fail – test of the test Now add sufficient code to My_AdjustSwitchPolarityASM( ) to pass the tests (see class notes and manual).

o Code will be very similar to My_ReadSwitchesASM( ) except I want you to (safely) use the non-volatile registers R5 – R7 and P4 – P5 in your routine. (Safely means – don’t crash “C++” when using non-volatile registers)

Check that the tests pass

TASK 3.4: Control the Blackfin GPIO registers – control the FIO_INEN (input enable) register in ASM Add My_DisableSwitchesASM( ) and My_EnableSwitchesASM( ) ASM stubs to Lab1Library Project Modify your tests for My_DisableSwitchesCPP( ) and My_EnableSwitchesCPP( ) so you can test My_DisableSwitchesASM(

) and My_EnableSwitchesASM( )

Check that tests fail if no valid code present in the stubs Develop the code for My_DisableSwitchesASM( ) and My_EnableSwitchesASM( )

Record screen shots for your Lab 1 report

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 10

Task 4.0 New test file Test_InitSwitches.cpp in Lab1Test project

Task 4.1 Check whether uTTCOS_InitSwitches( ) works as expected. We can then use the test to develop a My_InitSwitchesASM( ) routine

Make a copy of Test(Do_My_DisableEnableWork) and call it Test(Test_uTTCOSInitCPP) o This will not the greatest test – but better than nothing as we have all the code already developed

Build the Test Check that the new test Test(Test_uTTCOSInitCPP) works The code looks like this

uTTCOS_InitSwitches( ); .. Code to test Works

My_DisableSwitchesCPP( ); .. Code to test XF_Works

My_EnableSwitchesCPP( ); .. Code to test Works Changing the My_EnableSwitchesCPP( ) to a second uTTCOS_InitSwitches( ) should also pass the test (check)

Now add an ASM stub void My_InitSwitchesASM(void) to the Lab1 library and Lab1.h file Change both uTTCOS_InitSwitches( ) to My_InitSwitches( ) in the test. There should be a lot of failures in the test as there is no valid code

in void My_InitSwitchesASM(void) Record screen shots for your Lab 1 report

Task 4.2 Use test for uTTCOS_InitSwitches( ) to develop a My_InitSwitchesASM( ) routine

Task 4.3 Develop a My_InitSwitchesASM( ) routine We have the following pseudo code for My_InitSwitchesASM( ); You will need to translate into assembly code. Note that the ASM routine calls both other ASM routines and other C++ routines. Read the class notes about how to write assembly code that calls other function

void My_InitSwitchesASM(void ) { // C++ like pseudo code to assist development of ASM code My_SetSwitchPolarityASM( ); // Very similar code to My_AdjustSwitchPolarityASM( ) // except you set switches PF8 to PF11 to active high My_SetSwitchDirectionASM( ); // Very similar code to My_AdjustSwitchPolarityASM( ) // except you set switches PF8 to PF11 to be inputs

My_SetSwitch_MASKA_and MASKB_InteruptsOffCPP( ); // Very similar code to My_EnableSwitchesCPP( ) except you set switches PF8 to PF11 // so that the MASK_A interrupts and MASK_B interrupts are off (Check BF533 hardware manual). // We tackle interrupts in Assignment 2 (Before Quiz 3 which is on interrupts)

My_SetSwitchSensitivityASM( ); // Very similar code to My_SetSwitchDirectionASM( ); // except you set switches PF8 to PF11 to be level sensitive inputs (Check BF533 hardware manual). // Also important for interrupt handling (Before Quiz 3)

My_EnableSwitchesCPP( ); // Enable last is a good idea so we don’t get unexpected input signals coming in }

With My_InitSwitchesASM( ) code developed – the Test(Test_MyInitSwitchesASM) should work againRecord screen shots for your Lab 1 report

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 11

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 12

Task 5: We have been working so hard -- Here is a video game based on a previous test .

No – perhaps not a good idea, I think we should leave the video game test for another day as I am sure that you will not be able to win – most of the time

#include <stdlib.h> // If this is the wrong include for rand( ) then use CCES help to find the correct includeTEST(VideoGame_Pretending to be test) { // Needs a lot of fixing char dummyRead[250]; // Buffer uTTCOS_InitLEDS( ); My_InitSwitches( );

char PrimeNumbers[ ] = {0, 1, 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 39, 51}; // Correct primes as needed

unsigned int waitPeriod = 2 * 0x42; // Adjust to be twice your age (in hex) to keep the playing field even

int numLives = 2; printf(“\n\n\nPatterns will appear in the LEDs then disappear\n”): printf(“You then have a short time to match the switches to the original LED patterns\n”); printf(“You have two lives to start with\n Press enter to start\n”) ; gets(dummyRead); #define LEDMASK_6SEGMENTS 0x3F; // This may have to be outside the function on CCES for (int count = 0; count < 10, numLives > 0; count++) { int LEDvalue = rand( ) & LEDMASK_6SEGMENTS ; // Only a 6-bit random number will work as we have only 6 LED segments WaitAWhile(waitPeriod); uTTCOS_WriteLED(LEDvalue); // Display number WaitAWhile(2 *waitPeriod); uTTCOS_WriteLED(LEDvalue); // Number off

WaitAWhile(waitPeriod); int switchValue = My_ReadSwitchesASM( ); // Read switches

CHECK(LEDvalue == switchValue); // Check accuracy if (LEDvalue != switchValue) { numLives--; printf(“Life lost\n”); }

if (numLives > 0) printf(“Well done – You deserve %d P.O.B.s\n”, numLives); else { printf(“Try again\n”); printf(“his time use the switches on the Blackfin front panel\n”); printf(“They’re faster to press and release than the ones on the LLS\n”);}

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 13

Task 6: Making use of Lab0_LEDLibrary to demonstrate a Super Loop operating system during Lab1

The MPG group makes use of a super-loop operating system to control things. So in the rest of Lab1 we will to.

Task 6.1: Lab1SuperLoop project Preparation In Lab0_LEDLibrary project make a copy of LED3_Flash( ) called void LED6_Flash(void ) – change the code to flash

LED6. You find an error with

enum LED6_State {JUST_STARTED, IS_OFF, IS_ON};

Change to enum LED6_State {JUST_STARTED_ LED6, IS_OFF_ LED6, IS_ON_ LED6};

You might want to work out why this is needed For the last time this lab report, I will remind you to

(A) Add the prototype void LED6_Flash(void) to Lab0_LEDLibrary project(B) Build Lab0_LEDLibrary project(C) PSP -- Do a code review for my typos and for your typos.(D) PSP -- Build the file often to keep typos under control (E) Look out for questions about your PSP during quizzes and exams

In Lab1Library project – add a function to TIC every 1/12th of a second and build. Every O-S needs a tic method. We will use this code and improve this TIC in Assignment 2 // You will need to adjust the value “100” later in the lab. // to get the TIC time closer (+-10% in Lab. 1) to 1/2th second #define ADJUST_ME_LATER 100 void TIC_OneTwelvethSecond(void) { WaitAWhile(ADJUST_ME_LATER); }

Build a Lab1SuperLoop project -- DO NOT CONVERT TO uTTCOS project -- This is a super loop projecto Add a src folder o Add an stub Lab1_mainCPP.cpp file – a Helloworld- like main( ) and nothing elseo Using Project Properties | C++ Build | Settings | Linker |General

Add a link to LAB0_LEDLibrary, to Lab1Library, uTTCOS library (and you might need Assignment1Library later) -- okay if your names slightly different – might you can still include the .dlb

o Using Project Properties | C++ Build | Settings | Compiler | Preprocessor Change the include path to add LAB0_LEDLibrary/src, to add Lab1Library/src and AssignmentLibrary/src

(okay if your names slightly different)o Check the SuperLoop project builds and rund

Task 6.2: Develop a Super Loop OS nameWe can’t go any further without a name and an acronym for the new OS

Executive decision. The name will be -- The Automatic Regulation of Demonstrations Operating Systems or TARD-OS :-)

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 14

Task 6.3: Initial TARD-OS development Inside Lab1SuperLoop.h which is part of the Lab1SuperLoop project

o add #include to Lab1Library.h, and Lab0LEDLibrary.h – and the standard <MockDevices> and <uTTCOS> headers

o add a structure definition typedef struct TARD_OS_TASK_CONTROL { unsigned long int delay_TARD_OS; unsigned long int period_TARD_OS} TARD_OS;

// This, as one student indicated to me during Assignment, demonstrated that I did get the COFFEEPOT_DEVICE struct described incorrectly (big defect) but the code workedI will have to go back and use the correct definition typedef struct COFFEEPOT_DEVICE_REGISTER_STRUCTURE; { ... } COFFEEPOT_DEVICE and see what breaks (legacy code issue) when I rebuilt

Then check the project builds and links. Fix all error messages and warnings

Task 6.4: Making the Lab1Superloop Project Heart Beat using LED_Flash code from Lab0_LEDLibrary

Pseudo code

int main(void) { SetupSuperLoop( ); // What ever it takes – this line expresses an idea – may be code, may be a function bool keepGoing_TASK1 = true;

while (keepGoing_TASK1 == true) { TIC_OneTwelvethSecond( ); // Need to have a clock ticking 1 / 12 second is fast enough Every 1/4 SECOND { DO LED6_Flash( ); } // In Lab. 10 – develop a low power mode to make the project green – environmentally friendly Every SECOND { DO LED5_Flash( ); } Every 1/2 SECOND { DO keepGoing_LOOP1 = ! Is_SW4_Pressed( ); } // Read if sw4 is pressed – stop if pressed } // End while Wait till SW4 released ( );

return 0; // Ignore compiler complaint – never gets here}

Task 6.5: More details of the Lab1Superloop Project Heart Beat Modify start of Lab 1 main Check for your typos and mine

// Remember include files

#define TARDOS_NO_DELAY 0x00 #define TARDOS_ONE_SECOND 0x0A #define SW4_BITMASK 0x08

int main(void) { // SetupSuperLoop( ); // What ever it takes – an idea – may be code, may be a function TARD_OS everyQuarterSecond = { TARDOS_NO_DELAY, TARDOS_ONE_SECOND / 4}; TARD_OS everyHalfSecond = { TARDOS_NO_DELAY, TARDOS_ONE_SECOND / 2}; TARD_OS everySecond= { TARDOS_NO_DELAY, TARDOS_ONE_SECOND }; unsigned int keepGoing_TASK1 = ~SW4_BITMASK ; // Design change – will not use direct “Boolean” control of the loop // And then I mis-coded the change and did not put the “int’ in – More than 10 minutes later I still looking for problem

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 15

Build Lab 1 main to check for typos. Want to find them now before they make a real mess of things later. I build roughly every 10 lines (incremental coding)

Task 6.6: Add in the Super-loop timing control for the tasks

while ( (keepGoing_TASK1 & SW4_BITMASK != SW4_BITMASK)) { // Looking for SW4 to become high TIC_OneTwelvethSecond( ); // Wait in (pseudo) low power mode for 1/12 second

// Every 1/4 SECOND { DO LED6_Flash( ); } if (everyQuarterSecond.delay_TARD_OS == 0 ) { // Time to run the task LED6_Flash( ); everyQuarterSecond.delay_TARD_OS = everyQuarterSecond.period_TARD_OS; // Reset delay to make it start again in 3 TICS // or should it be everyQuarterSecond. delay_TARD_OS = everyQuarterSecond. period_TARD_OS - 1; // to get the LED6_Flash to go Every 1/4 SECOND // Work out the time diagram on square-lined paper and hand-in with Lab 1 report // See my Circuit Cellar article TTCOS explained part 1 on ENCM511 web page for examples } // end if (everyQuarterSecond. delay_TARD_OS == 0 )

// Strange syntax error on this next line after I cut and pasted to CCES // My normal fix was applied – Quickest to just delete the line and retype it – not worry about why the problem occurred

everyQuarterSecond.delay_TARD_OS = everyQuarterSecond.delay_TARD_OS – 1; // Remove some delay

// You complete the code -- Every SECOND { DO Flash_LED5( ); } // Every 1/2 SECOND{ DO keepGoing_LOOP1 = ! Is_SW4_Pressed( ); } if (everyHalfSecond. delay_TARD_OS == 0 ) { // Time to run the task keepGoing_ TASK1 = My_ReadSwitchesASM( ) & SW4_BITMASK ; // Make sure you have enough brackets to ensure operator precedence

everyHalfSecond. delay_TARD_OS = everyHalfSecond. period_TARD_OS;

} // end if (everyHalfSecond. delay_TARD_OS == 0 ) everyHalfSecond. delay_TARD_OS = everyHalfSecond. delay_TARD_OS – 1; // Remove some delay – Nasty syntax error here

} // end while (keepGoing_ TASK1 == SW4_BITMASK ) printf(“Loop 1 finished\n”); while (( My_ReadSwitches( ) & SW4_BITMASK ) == SW4_BITMASK) /* Wait for SW4 to be released */

Do a design and code review. o My code review revealed the same design defect as I made in Lab0 about the LEDs and the same error as in Lab1 Part 1 about the switches o The problem was something I recommended that you avoid at the start of all tests in Lab0.

Task 6.7: Add a new super loop TARD-OS task into LOOP1 to ECHO_SWITCHES_TO_LEDs

Add the code // Every 5 TICS { Do uTTCOS_WriteLED(My_ReadSwitches( ) }; Build and the TARD-OS code should run – Flashing LEDS 5 and 6, and copying SW1 to SW3 to LED1 to LED3 until SW4 is pressed and released

Get completion signed off by another lab. group

You will be submitting a lot of code in your report – Make sure that your C++ and ASM code is formatted for readability. CCES (via Eclipse) has key-strokes to make this happen automatically. Look-up “Pretty Formatting” commands.

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 16

Task 6.8: Dr. Smith’s “Special Programming Tricks” CornerEvery E-UNIT Test is actually a complex macro (try hovering over the word Test in a Lab1 Test)

So I tried to find macros to allow me to code TARD_OS Tasks more easily

OLD 1920 StoryA “recently rich” person goes into a car sales-room looking for an expensive car. The person says to the

salesman “How much does it cost?” The salesman replies “If you have to ask about the cost, then you can’t afford it”

2014 StoryA “very busy” C++ developer goes on line to find out about C++ Macros. The person tweets “How long will take

me to learn enough to be able use C++ macros in a useful way”. The answers go viral -- “If you have to ask about how much time – then you don’t have enough”

These macros can’t be used during 511 Exams where I am testing that you understand the ideas of constructing superloops – However, they would make perfect “documentation” of pseudo-your code when designing

The macro definition code is at the end of the Lab report if you want more details

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 17

Task 7: Driving the virtual car (Shown on Blackfin LEDs)

Task7.1: A new TARD-OS Task to automatically drive a “virtual car” (Shown on LEDs)

Get masking tape and label last 4 LEDs as DONE, LEFT, FORWARD, RIGHT to indicate the direction the virtual car is moving

Here is the pseudo-code for the next controlled super loop– place after previous TARD-OS Task

#define CAR_FORWARD 0x02 // LED 2 #define CAR_RIGHT ?? // LED 1 #define CAR_LEFT ?? // LED 3 #define CAR_COAST 0x00 // No LEDs ON // Make the virtual car move forward and then turn right in 1 second steps unsigned int carMovement[9] = { CAR_FORWARD, CAR_FORWARD, CAR_FORWARD, CAR_RIGHT , COAST, CAR_RIGHT , CAR_FORWARD, COAST, CAR_FORWARD, CAR_FORWARD}; #define MAXCARMOVEMENTS 9 int carMovements= 0;

keepGoing_TASK2 = ~SW4_BITMASK while ( ((keepGoing_TASK2 & SW4_BITMASK ) != SW4_BITMASK ) && (carMovements< MAXCARMOVEMENT) // Every 1/4 SECOND { DO LED6_Flash( ); } // Every SECOND { DO LED5_Flash( ); } // Every 1/2 SECOND{ DO keepGoing_TASK2 = Is_SW4_Pressed( ); } // Every SECOND{ DO WriteLED(carMovement[carMovements ++]); } } Wait till SW4 not pressed printf(“** LOOP 2 has finished **\n”);

Get completion signed off by another lab. group

Task7.2: TARD-OS Task to record your “commands” to drive a “virtual car” (Shown on LEDs)REQUIREMENT – Record commands to make the car go LEFT for 5 seconds then forward for 4 seconds (9 commands)

NOTICE -- In TARD-OS Task 3 SW4 is being used as an “accept” drive-command-and-put-into-array operation rather than a “stop” command. -- In TARD-OS Task 4 SW4 goes back to being a stop command

Remember to read the code and look out for code and design defects, which may (will) be there. This is described as part of CAEB accreditation for your P.Eng as a heavy design course – so expect to have to solve issues keepGoing_TASK3 = true; See discussion on next page before starting to code int numberCommandsRecorded = 0; while ( keepGoing_TASK3) { // Every 1/4 SECOND { DO LED6_Flash( ); } // Every SECOND { DO LED5_Flash( ); }

// Every SECOND{ DO while (SW4 is not pressed) { carMovement[carMovementsDone] = My_ReadSwitches( ) ); // SW4 has now been pressed so we can accept the new drive command carMovementsRecorded++ // Every 1 TIC -- Check if we should keep the recording going and update car movements recorded // DO { keepGoingTask3 =KeepCarGoing_Update CarMovementsRecorded (carMovement, carMovementsRecorded); } }

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 18

printf(“** LOOP 3 has finished **\n”); Task 7.3: TARD-OS Task to “play back your commands” to drive a “virtual car” (Shown on LEDs)

// Make a new version (copy) of TASK2 to play back the recorded tasks

int carMovements= 0;

keepGoing_TASK4 == ~SW4_BITMASK while ( (keepGoing_TASK4== ~SW4_BITMASK ) && (carMovements< numberCommandsRecorded) // Every 1/4 SECOND { DO LED6_Flash( ); } // Every SECOND { DO LED5_Flash( ); } // Every 1/2 SECOND{ DO keepGoing_TASK2 = Is_SW4_Pressed( ); } // Every SECOND{ DO WriteLED(carMovement[carMovements ++]); } } printf(“** LOOP 4 has finished **\n”);

Task 7. 4: Possible solution to design problem associated with Task 7.2 to allow Task 7.3 to work.How do we decide that we should keep-recording car commands or stop recording car commands? We have only 4 hardware switches and they are all in use (Forward, left, right and accept)

o As discussed in the articles TTCOS2 and TTCOS3 on the ENCM511 website we can use software switches

Design decision – If the operator enters 3 COAST commands (one after the other) then stop the recording) as the software switch is considered ON.

If 2 or less COAST commands and other commands – then software switch is considered OFF

bool KeepCarGoing_Update CarMovementsRecorded (unsigned int carMovement[ ] , int carMovementsRecorded) { bool keepGoing = true; if (carMovementsRecorded < 6) keepGoing = true; // Too little carMovement data to make a decision else if (carMovement[carMovementsRecorded -2] == COAST) // If last three commands are COAST then stop recording if (carMovement[carMovementsRecorded -1] == COAST) if (carMovement[carMovementsRecorded] == COAST) keepGoing = false; return keepGoing; }

80% of Lab. 1 is now completed (Mark B+ / A- / A)

RECOMMENDATION – time consideration. You might want to consider reading the rest of the lab but not doing any more coding if you are struggling with the C++ coding levelNOTE: You can’t get any more marks for the LAB 1. report by handing in a modified Lab. 1 report. HOWEVER you can get more marks if you show an improved LAB. 1 demo later in the term when you have gained more experience

Once you have got the 4 TARD-OS Tasks working Adjust the code to record a maximum of 30 car movement so you can demonstrate to the TA that you can make the car - go forward for 3 seconds – go forward and left for 3 seconds – go forward for 3 seconds – go forward and right for 3 seconds – go forward for 3 seconds -- go forward and right for 3 seconds – then coast (power off) until stopped.

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 19

Remember to hand your code, screen dumps and in

Last 20% towards A+ on Labs. Lots of work that reuse the original ideas. Possibly four times as long debugging for a quarter extra marks. You make the decision how far to go

Task 8: Controlling a “real” radio controlled (RC) car

Task 8.1: First steps to driving the real car and virtual car at the same timeWe need to work these ideas out using the Test Project and not inside TARD-OS

BIG WARNING – ENTERING POSSIBLE SMOKE THE PROCESSOR CODE REGION – DO CODE REVIEW CAREFULLY

Add Lab1Library stubs for void My_AllowGPIOOutput_CPP(void) which changes the direction of PF1, PF5, PF6 and PF7 GPIO pins to output and My_WriteGPIO_ASM(unsigned char outGPIOValue) which outputs values on PF1, PF5, PF6 and PF7 pins

Power down Blackfin and LLS boards Connect LLS PF7 GPIO to LLS LED 15 (Most significant bit) Connect LLS PF6 GPIO to LLS LED 14 Connect LLS PF5 GPIO to LLS LED 13 Connect LLS PF1 GPIO to LLS LED 12 (Least significant bit)

Once working we can then hook PF lines to the forward, left, right command lines of the radio controlled car and drive the real car

You are allowed a maximum of 2 attempts to borrow the RC car and demo for the Drive real car bonus

Quick example of having Blackfin write to PF lines connected to LLS LEDs (Virtual car 2).

Call this routine from your test #include <blackfin.h> #define BITMASK1_5_6_7 0x00E2

void TurnOn_LLS_LED15and12(void) { unsigned char oldDirectionRegister = *pFIO_DIR; // Change input to output control for PF1, PF5, PF6 and PF7 pins unsigned char newDirectionRegister = oldDirectionRegister | BITMASK1_5_6_7 ; *pFIO_DIR = newDirectionRegister; ssync( ); // Flush the write into Blackfin memory

// Zero PF1, PF5, PF6 and PF7 and keep other bits unsigned char oldDataValue = *pFIO_FLAG_D & (~BITMASK1_5_6_7 ); // Turn on PF1 and PF7 which are connected to LLS_LEDS 15 and 12 unsigned char newDataValue = oldDataValue | 0x0080 | 0x0002; *pFIO_FLAG_D = newDataValue; ssync( ); }

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 20

The rest of the coding is up to you for void My_AllowGPIOOutput_CPP(void) and My_WriteGPIO_ASM(unsigned char outGPIOValue)

Task 8.2: Driven the second virtual car is worth 10% Task 8.3: Driving the real car is worth 10% (and 10% bonus – because it is hard to drive the real car correctly)

HINTS – First 10% of final 20% of the mark TARD_OS Task 4 becomes

My_InitSwitches( ); My_AllowGPIOOutput_CPP ( );

keepGoing_TASK4 == ~SW4_BITMASK while ( (keepGoing_TASK4== ~SW4_BITMASK ) && (carMovements< numberCommandsRecorded)

// Every 1/4 SECOND { DO LED6_Flash( ); } // Every SECOND { DO LED5_Flash( ); } // Every 1/2 SECOND{ DO keepGoing_TASK2 = Is_SW4_Pressed( ); } // Every SECOND{ DO WriteLED(carMovement[carMovements]; My_WriteGPIO_ASM(carMovement[carMovements]; carMovements++ } } Wait till SW4 not pressed

HINTS – Second 10% of final 20% of the mark (with bonus) The modified TARD-OS Task 4 will work for the real car – but one real-life problem is revealed

The car works correctly for LEFT and RIGHT commands but not FOWARD The FORWARD command adds so much power that the car will destroy itself against wall This can be solved by making the FORWARD command a PWM (power width modulated) command Change every where TIC_OneTwelvethSecond( ) to TIC_OneHundrethSecond( ) with #define

TARDOS_ONE_SECOND 100 Check that all tasks work as before

This task is the one that destroys the car

// Every SECOND{ DO WriteLED(carMovement[carMovements]; My_WriteGPIO_ASM(carMovement[carMovements]; carMovements++ }

We need to turn on the FORWARD power on and off – on for 1/8 second – off for 3/ 8 second

So we rewrite the tasks as follows – Explain in yout Lab. 1 report why order is important

// Every SECOND{ DO My_WriteGPIO_ASM(carMovement[carMovements]; }// Every SECOND{ DO WriteLED(carMovement[carMovements]; carMovements++ }

L a b o r a t o r y 1 : P r o g r a m m i n g a n d U s i n g t h e G P I O L i n e s P a g e | 21

And then change the code of the last task to be

// FIRST 1/ 8 second { DO My_WriteGPIO_ASM(carMovement[carMovements] ; }// NEXT 3/ 8 second { DO My_WriteGPIO_ASM(carMovement[carMovements] & ~0x0040; } // Turn off forward bit// NEXT 1/ 8 second { DO My_WriteGPIO_ASM(carMovement[carMovements] ; }// NEXT 3/ 8 second { DO My_WriteGPIO_ASM(carMovement[carMovements] & ~0x0040; } // Turn off forward bit

That looks hard to tackle, but is straight forward to do with a state machine as in FlashLED3( ) or FlashLED5( ) from Lab. 0

// EVERY 1/ 8 second { DO CarPWM_Power_StateMachine (carMovement[carMovements] ; } where

void CarPWM_Power_StateMachine( int carMovementControl]) { static int CarState = 0; switch (carState) { case 0: My_WriteGPIO_ASM(carMovementControl); break; // Forward power is on case 1: case 2: case 3: My_WriteGPIO_ASM(carMovementControl) & ~(0x0040) break; // Forward power is off

case 4: My_WriteGPIO_ASM(carMovementControl); break; // Forward power is on case 5: case 6: case 7: My_WriteGPIO_ASM(carMovementControl) & ~(0x0040) break; // Forward power is off } carState++; if (carState > 7) carState = 0; }

Have fun – remember 90% is still A+ -- and there are other courses to d0 :-)

Task 6.8.1: Dr. Smith’s “Special Programming Tricks” Corner

Those macros I promised you – These can’t be used durinfg ENCM511 exams when I am testing you on Superloop ideas