Showing posts with label Hardware. Show all posts
Showing posts with label Hardware. Show all posts

Tuesday, 22 September 2015

Acting the Part - A lesson in processor architecture

Part of the syllabus for my A-level computing group (OCR A Level) is to learn about and understand the make up of a CPU. This goes beyond the basic "this is the brains of a computer" and starts to look at how the CPU does it's job and which parts of the CPU do each part of the job.

To do this I could have done a 'chalk and talk' lesson telling the students all about the functions but I felt they would learn better if i could get them more involved. I also wanted to get them interacting and working together.

I did a lesson before with my Home Education group based on a CS unplugged activity - class simulation of a computer. I had adapted the ideas on the page to make a human calculator program using children to move the information around the parts of the computer. this was a little basic but it seemed like a good basis to expand on for my lesson.

As this was an A-Level group I wanted to get the students to do the thinking. So i came up with a plan based on a simple introduction to the parts and functions then set the students the task of designing activities to explain the working of the CPU to their classmates.

For the introduction we did a revision of the fetch-execute cycle and then went smaller to look at the parts of the CPU and what part they play in the process. The students were also given access to a YouTube playlist of videos about processor architecture to help them research the topic.

The students were split into small groups then set the task to design an activity to explain the process to their peers.

The Groups came up with a variety of ways of delivering the idea. All of the groups had an activity which showed they understood the process. The best group came up with an activity that involved the other students to take the role of each of the components and memory.

Their activity is detailed below (with a little editing):

Equipment:
Pens
Plain paper
Whiteboard pens
Mini Whiteboards
Labels for each of the components (can be written on the boards)

Set up:
1) Write a simple program to be used by the simulated computer the students used the following program:

     1 Load 70
     2 Add 71
     3 Store 72
     (at location 70 they had 712, at location 71 they had 73)

2) Select students to take the following roles -

     Registers:
     Program control - PC
     Memory Address Register - MAR
     Memory Data Register - MDR
     Current Instruction Register - CIR

     Arithmetic Logic Unit - ALU
     Control Unit - CU
     Accumulator - AC

     Cache Memory

     Address Bus
     Data Bus
     Control Bus

3) Hand each student the correct label, a whiteboard whiteboard pen, paper, and pen then position them around the classroom. Ensure the registers are together and the other components are spaced out around the room.

4) Hand Memory the Program and data loaded into memory


Activity

The students then act the parts of the CPU to carry out the program. To pass data / instructions / control around they write the information on to paper screw it into a ball and throw it to the next part in the process.

So for this example program the following happens:

1) PC is set at 1. This is transferred to the MAR (by throwing paper).
2) CU requests contents of address 1 from memory. (throwing paper via the address bus)
3) The data in the memory (LOAD 71) at address 1 is transferred to the MDR (via the data bus)
4) Contents of MDR loaded into the CIR
5) Contents of CIR sent to CU to be decoded (Data bus)
6) CU decodes the instruction and sends the required address to the MDR and increments the PC. (control bus)
7) Control signal sent (control bus) to fetch the data at the new address (70) (address bus)
8) Data from memory address 70  (712 ) loaded into the MDR (via the data bus)
9) Data from MDR (712) sent to the AC as required by the Load command


10......

this continues carrying out each instruction from the program so for this program PC 2 loads the Add 72 command which fetches the data from location 72 (73) and adds it to the AC. To add the two numbers the ALU is used. The total is added to the AC then the next instruction followed which in this case stores the result at memory location 72.



This could also be extended to show the extra time required to fetch data / instruction from RAM if they are not in cache memory. To do this the RAM should be positioned further away than cache memory. The cache is checked first then the RAM queried if it is not there.

Friday, 24 July 2015

The PiCycle an amazing student project



I have had the pleasure this year to have been a supervisor for one of our sixth form students doing an Extended Project Qualification (EPQ).

The EPQ is a level 3 qualification (similar to A-level) for students to do something that they are interested in. This can be an essay or an artifact and can take a myriad of forms. In this case my student chose to do a Raspberry Pi based project which was how I became involved.

Dan had no previous experience of the Raspberry Pi or Python before starting the project. He had done some web development but wanted to try something new. He spent a large portion of the project time mastering the basics of Python and the basic hardware before moving on to getting the project up and running.


The result is the PiCycle a Raspberry Pi based cycle computer that takes the position of the rider an plots it on a map on a website. The idea was to use the device to prove the designer had completed a planned charity cycle ride across France but could be used for all sorts of tracking applications. As well as getting the device working he spent some time getting it to look good too with branded interfaces on the device and the web tracking page.





The student developed the program to collect the GPS position and store this in a file on the Raspberry Pi and then upload the data to the web to display the position(s). The design means that whilst the cyclist is in areas of poor phone reception they can still log the GPS position (assuming GPS signal) and then upload the data when the phone signal is regained.

This project was a great achievement especially considering that Dan had no prior knowledge of the Raspberry Pi or Python before he started the EPQ.

Some more information about the project can be found in his project presentation. He can be found on twitter: @DJWOOLFALL.

Wednesday, 25 March 2015

Raspberry PI Set up and Hello World

Having introduced the basics of computing this week the plan was to get the children setting up the Raspberry Pi and starting to program.

There was a little setup confusion with the venue meaning that there was a delay getting everything out and a much less ordered start to the session as kit was quickly located and brought out to us. We also discovered that the table arrangement we were using did not allow for enough power outlets to be available. A swift rearrangement of table and we had everyone near enough to a plug or extension to get running.

This was a completely new experience for me as I am used to arriving in my classroom that has all of the kit stuck on tables ready for me when I arrive and just moving cables around between the desktop and the Raspberry Pi. With the help of Jeremy (one of the other parents with an IT background) and Hamish from the University of Sheffield (who had come to see the Pi Bank kits in action) the children were all eventually up and running.

After the kit arrived we had to tackle the normal issue of setup with failed memory cards and trying to sort out which display option would work best. This was where the Pi Bank kits really helped. The range of connection options included meant that even with a collection of different monitors of differing ages we were able to get all the children connected and logging in.

It was at some point during the effort to help all of the children that I was shown the possible horror of teaching my own children. As a Home Educator I spend a large amount of time teaching my own children but not normally in a large room with other children to share the attention.

I think the sharing of my attention is something that will remain a challenge for my children to get used to and for me to work around, I need to find a way to channel my children's natural desire for my attention in a way that does not affect the groups progress.

Despite these distractions and the issues with the equipment we did manage to get everyone logged in to the Raspberry Pi. In fact we managed to move on and get the children started with looking at the file system and starting to create basic programs. The children used `ls` to look at the files and folders then `mkdir` to make their own folders. We then had a go at the traditional "Hello World" program in python using nano. Some even managed get the program prompting for user input.

Overall we managed to achieve the objectives even if it was not as calm and organised as I would have liked. However comparing this with the setup lessons I have taught in school is a favorable comparison,  We normally teach this in Y8 (12/13 year olds) and I find that normally I can expect to only get the class as far as making their own folders then needing to pack up the kit. This is with all the extra parts all setup on desks. With our mixed ability and age group we have been able to progress to making a simple program. With some tweaks to the organisation and a reduction in distractions i am expecting the group to progress fairly quickly.

To this end I have changed the setup plan for next week and the tables should be arranged near to the power outlet and the venue have promised to have the monitors, keyboards and mice setup and waiting for us. This should allow us to get started more quickly and move on to the physical computing experiments I have planned. I have also purchased and burned a fresh set of SD cards that I will be assigning to the children to use and save their work on each week.