Re: Pi Forums

"I think element14 owes a lot to RasPi and its Foundation".

As a very rare contributer I also think the RasPi and it´s Foundation owes a lot to Element 14 and the excellent after sales service.  Over the last 14 months I have purchased three Raspberry Pi. a self assembly Gertboard Kit, a PiFace Digital and most recently a BBB.  Every time Element 14 have done what they said they would do with very propmpt replies to any questions.  In particular Rachel has been very efficient and helpful.

Colin Gearon.

Colin Gearon wrote:

 

I also think the RasPi and it´s Foundation owes a lot to Element 14

Very true.  E14/Farnell hasn't really put a foot wrong throughout the whole Pi saga, not significantly.

Their site collapsed during launch for a few days, but that was caused by RPF's entirely ridiculous concept of opening the floodgates to pre-orders at a single instant of time and requiring customers to compete.  This is not just the power of hindsight.  Every web service on the planet with the exception of Google and Facebook is likely to collapse when 100k+ people hit it within a few seconds, and subsequent recovery is prevented because of the retries.  I blame the collapse squarely on RPF's faulty planning.  The fact that  RS collapsed at the same time offers proof of that.  At worst, Farnell and RS were guilty of not telling RPF that such an approach was not feasible given their server capabilities, although competition between them may have prevented either party saying "We can't do that".  It was obvious though.  Even RPF's forum sysadmin could have told them that.  It was even checkable in advance with a load test script.

Once Pi became available, my only significant criticisms of E14/Farnell are that the export site provides substandard Farnell service (compared to Farnell UK), and that they haven't been fast enough at putting Pi on a regular product footing now that it is ex-stock.  This still hasn't happened, and that's a fault because substandard service should never be considered "business as usual" for Farnell.  Also, they could have volunteered a bit more information when people were asking for it, but none of these things are epic disasters.

So on the whole, almost full marks.

And in case anyone suspects that this is just being nice to our hosts here, I think we've made our feelings quite plain and unambiguous when we've criticised the dreadful handling of knode discussions for BBB, so we don't hesitate to highlight things that are are broken when they are.  This problem is still present, but the fault was acknowledged rapidly and an update is in progress for end of Q3 so we live with it, unhappily but patiently.

Well done E14 on Pi.

Don't forget:

"What we are lacking (and the Raspberry Pi Foundation cannot provide) is

getting a coherent set of materials we can use with it to teach Computational

Thinking and principled ideas from Computer Science."

http://www.cl.cam.ac.uk/~am21/slides/CAS12.pdf   (page 22)

"But it meant we were faced with a dilemma. How could we enable hacking while preventing cloning?"

http://www.wired.com/opinion/2012/09/raspberry-pi-insider-exclusive-sellout-to-sell-out/

Raspbery Pi 2020:

   "8 cores, improved GPU, 8GB main memory"

  (with mention of ~$50 productivity PC, but no mention of improved educational materials)

http://www.cl.cam.ac.uk/~rdm34/raspi-talk.pdf  (page 10)

selsinork wrote:

 

I like the idea of being able to build a cheap board like the Pi or BBB into something else and getting the benefits of not needing to do it all from scratch myself like I might with a microcontroller, while having some useful IO that PC's usually lack.

Indeed, but don't forget that there is yet another alternative which provides some of the flexibility of the Linux-on-embedded-ARM approach, not requiring an external PC for cross-development and yet achieved at a third of the cost of the Pi or BBB.

That's the old and now rather out-of-vogue approach of building a high-level language interpreter like eLua or Forth or even our old friend BASIC into a microcontroller board, with appropriate bindings for controlling GPIOs and other low-level resources.  You can fit a really impressive RTOS and language interpreter into the 192KB program flash of an STM32 Discovery board for example.  Depending on the board, you may still need a computer as an RS232 terminal or an LCD, but then even an embedded Linux board needs some kind of HCI.

selsinork wrote:

coder27 wrote:

 

it seems their #1 goal is to shift as many boards as possible,

doesn't make sense unless it's only about the money

There are other motivations besides money.  There's fame -- they seem to enjoy that a lot chez RasPi.  Look at Linus Torvalds -- he didn't get rich off Linux like Bill Gates, but he gets to to call the shots and has the priceless satisfaction of freeing the world from Microsoft dominance.

John Beetem wrote:

 

Look at Linus Torvalds -- he didn't get rich off Linux like Bill Gates, but he gets to to call the shots and has the priceless satisfaction of freeing the world from Microsoft dominance.

While that might work for Linus, in my view it has a slightly sinister overtone when it's the RPF chaining people to a black box GPU.

but yes, fame might be a viable substitute. simply shifting lots of boards doesn't guarantee fame though.

Morgaine Dinova wrote:

 

but then even an embedded Linux board needs some kind of HCI.

I should have probably mentioned that bit's called ethernet

selsinork wrote:

 

I should have probably mentioned that bit's called ethernet

Real engineers use butterflies.  Only NSA spooks poke bits as they fly past on the wire.

simply shifting lots of boards doesn't guarantee fame though.

Maybe shifting lots of boards is for fame, maybe it's for money, maybe

it's for business credibility, maybe it's to bring down the unit costs,

maybe it's to sell lots of Broadcom chips, who knows. 

But it's pretty clear, even from the title of Pete Lomas's piece referenced above:

Raspberry Pi’s Secret: ‘Sell Out a Little to Sell a Lot’

that "selling a lot" is of critical importance, even at the cost of "selling out".

Similarly, the article's conclusion reinforces the point:

Raspberry Pi has been a project seven years in the making. It’s often felt like the closer we got to our goals, the further away they seemed. But we’re having the time of our lives. We’ve only been selling for six months, and we’ve sold around half a million units already.   ...

This is really a reply to coder27, morgaine and selsinork.

Thanks for your sympathy & offers of support. History: In the 1980s I wrote a course based on the ZX81 with simple interface to control LEDs, motors and buzzers and to accept inputs from switches. It taught simple programming in BASIC (a doddle compared to what I'm having to learn now) and simple electronics, giving The Beasties options in robotics (turtle). One project was a 1-bed flat, made from chipboard, with LEDs to represent lights, TV, cooker, etc., which could be switched to make it seem inhabited (I read of a Roedean pupil doing something similar with the RPi in some competition.) and monitoring door switches as a burglar detector with buzzer as alarm. Another was model railway control driving locos., signals and point motors.

I thought something similar would appeal and be relatively easy to concoct with the RPi. "Dad; I got it wrong again," as a *** Emery character said. When I said "Yes" to helping, I had no idea what I was letting myself in for.

I want to keep it simple to start with, partly because I'm 70 and am having difficulty learning and retaining new stuff, but I hope that, once started, the young teachers who've asked for help will steam away and The Beasties will follow.

We hope to get funding for 10 RPi Bs and interface boards, if we can show a good enough course.

I'd really counted on having the promised education pack by now, but I think it's either at the end of the rainbow or a mirage.

There are two parts to your problem.

The first is that people who have not been involved in large and complex problems have no conception of the hypergeometric growth rate of difficulty in writing longer and larger systems that have serious requirements for testing and correctness. I don't know how many times I have heard "Well, it only took me an afternoon to write a 100 line program in BASIC, I don't see why you, as a supposed professional, can't write a thousand line program in a week." Of course they don't even think of the pad they keep next to the PC as a means of dealing with exceptions they didn't want to code for, because "They never happen." At least not more than once every two days.

The second is that people have gotten used to computers, and their doing things which were beyond the conception of most thirty odd years ago. My then two year old son shocked and amused our hostess when he asked where their computer was, as we had an Apple ][ since he was born, and he thought everyone would have one. Even physical computing has become somewhat blase in a world where a friend on vacation can give you a call while standing on the Great Wall of China. So I think it is natural for many students, faculty and especially administration members to have expectations of a course that are completely unrealistic.

Being in your age group, I know what you mean by having difficulty absorbing and retaining new things. But over the years I have found that the greatest difficulty is in the begining. I tend to forget new words until I have heard them a number of times, and new paradigms can be difficult. For example, parsing complicated data flows using RegEx isn't easy for many people, nevermind someone whose experience was in scientific programing, statistics, epidemiology and data acquisition. But having acquired the basics of quite a few new systems, I now know that I have solved the type of problems I am facing before, or at least something like them. I pretty much need to only acquire the primary structures and memes of the new language/system to be able to apply my prior knowledge. That fear and ego will do more damage to my problem solving capacity than the newness of the situation.

Best wishes for your course.

This is for Frank and apologies to stepping in.

I applaude what you are doing, in that you are trying something new, and trying to pass on your knowledge to give some students the lift they need to carry on.

I also sympathise with the trying to learn new processes and language, etc.

I have a similar steep learning curve with RPi, but there are many resources around the web which with a good idea of where you want to go, can help put it together.

(You also have some very talented people here who can point you quickly to the resources)

There is a very good review of the PiFace Digital by Gough Lui http://www.element14.com/community/roadTestReviews/1468

There is also some very good tutorials at Adafruit http://learn.adafruit.com/category/raspberry-pi and the temperature sensor lends itself to integrating with the interface to combine two different uses of RPi.

If your budget doesn't cover the interface then LED's, buzzers and pushbuttons will achieve similar results.

Last year I put together an Arduino Introduction course for a group of 8 (year 6-7) students at our local school. (I'm not a teacher)

I thought it would be easy, just grab some tutorials off the web, and away you go.

I ended up writing it myself, which meant I knew the material, and was able to modify the delivery as the class dictated.

So my advice is to nut out what you want to achieve, break it down to reasonable size sessions, with lots of hands on and instant feedback (leds, buzzers, display) so they can see their changes happening.

Each session should add onto the other, and possibly pick up from where you left off.

You'll also need to allow for some slower and some faster students, and some that wont get it until the end.

Good luck

Mark

This is for Frank and apologies to stepping in.

I applaude what you are doing, in that you are trying something new, and trying to pass on your knowledge to give some students the lift they need to carry on.

I also sympathise with the trying to learn new processes and language, etc.

I have a similar steep learning curve with RPi, but there are many resources around the web which with a good idea of where you want to go, can help put it together.

(You also have some very talented people here who can point you quickly to the resources)

There is a very good review of the PiFace Digital by Gough Lui http://www.element14.com/community/roadTestReviews/1468

There is also some very good tutorials at Adafruit http://learn.adafruit.com/category/raspberry-pi and the temperature sensor lends itself to integrating with the interface to combine two different uses of RPi.

If your budget doesn't cover the interface then LED's, buzzers and pushbuttons will achieve similar results.

Last year I put together an Arduino Introduction course for a group of 8 (year 6-7) students at our local school. (I'm not a teacher)

I thought it would be easy, just grab some tutorials off the web, and away you go.

I ended up writing it myself, which meant I knew the material, and was able to modify the delivery as the class dictated.

So my advice is to nut out what you want to achieve, break it down to reasonable size sessions, with lots of hands on and instant feedback (leds, buzzers, display) so they can see their changes happening.

Each session should add onto the other, and possibly pick up from where you left off.

You'll also need to allow for some slower and some faster students, and some that wont get it until the end.

Good luck

Mark

Frank,

   You've gotten some good advice.  He're my 2 cents:

Teach what you know.  If you know Basic, teach that.  Don't try to learn

Python or whatever just because someone else thinks it's the perfect

teaching language.  There is no perfect teaching language, and any language

you pick, or topics you pick, will likely be considered a bad choice by someone.

The students will be able to tell right away whether you know and are enthusiastic

about what you're teaching, and that's what matters most.

Michael wrote:

There are two parts to your problem.

I think there are a lot of parts in general to the problem of how to introduce

students to computers and/or computer science.  For example, a very small

percentage of students like programming.   I don't think there's any magic

solution, such as "physical computing" that will make the subject universally

appealing. 

Secondly, you can't advertise computing as a secure career path.  Programming

is relatively easy to outsource to low-wage countries, and the field changes

so rapidly that employers are often looking primarily for young programmers who

don't need to be trained on the latest technologies, and who are willing to work

long hours.

Thirdly, the field of computing is so vast that anything you teach will just be

an "exposure" to one or more aspect of the subject, so there is no point trying to

teach the "right" lessons.

Fourthly, the field is young enough that there is very little consensus on

standard technologies or even terminologies.  One of the most fundamental

concepts of programming is the subprogram, but in various languages it is

called a procedure, or a function, or a method.  There is also no consensus

in programming on how or even whether to declare variables.   Some languages

are good for efficiency, some for safety, some for productivity, some for

client-side web applications, some for server-side web applications, etc.

So the students will likely soon be re-learning anything you teach.

coder27 wrote:

 

Thirdly, the field of computing is so vast that anything you teach will just be

an "exposure" to one or more aspect of the subject, so there is no point trying to

teach the "right" lessons.

Very well said.  Even those who have been in the discipline for many decades, including academia and industry, know only a very tiny fraction of its full extent.  It's a bit disconcerting to face that reality, but not a reason for depression.  We just have to pick and choose from the vast mountain and find one or two narrow areas where we can accomplish something.

This is also one very good reason to highlight the difference between education and vocational training.  Education is that aspect of our learning that is so general that it provides us with a base or foundation for everything we do in the future, but on its own is of very limited direct applicability.  In contrast, vocational training is directly applicable, but may be useful only briefly and our experience of it may not translate to future endeavours at all.  (All learning usually involves both, but the percentage of each may vary almost 0-100%.)

Giving youngsters strong vocational training makes little sense, since the number that will be able to apply it is likely to be low or even zero if it's in an area of change like so many are in practical computing.  This makes coder27's remark about no point trying to teach the "right" lessons spot on.  Instead, focus on educating them about widely applicable concepts, because those will stand them in good stead forever, even outside of the discipline.

Morgaine.

Morgaine Dinova wrote:

 

Education is that aspect of our learning that is so general that it provides us with a base or foundation for everything we do in the future, but on its own is of very limited direct applicability.

Taken to its extreme, this statement brings up a wonderful quote from the depths of my memory:

The principle is so perfectly general that no particular application can be made of it.

I have found in practice that computing has a nice balance between theory and practice, with far more emphasis on practice AKA "the bag of tricks".  This is particularly true if computing is taught by engineers.

Oh, it's very easy to find examples of pure 100% education accompanied by no vocational training material whatsoever in this field, and very useful it is too.

For example, you can teach people iteration using only a PDL and sequence diagrams, and they won't be able to apply it directly at all unless they've grasped the concept well and can translate it into a real program written in a language that has a real implementation on a machine to which they have access and learn to run.  These practical hurdles seem like nothing to us, but in many parts of the world they would be vast compared to the relative ease of obtaining written educational material.

I have found in practice that computing has a nice balance between theory and practice, with far more emphasis on practice AKA "the bag of tricks".  This is particularly true if computing is taught by engineers.

Computer science, when not taught by engineers, is all about putting away "the bag of tricks."

The monster we are trying to tame is complexity, not efficiency.

The bag of tricks may help efficiency, but it makes code fragile.

The next time the underlying hardware is upgraded, the trick will likely

either not work correctly, or not be more efficient.  In any case, the trick

will impede maintenance.

For example, there is a really clever way to compute absolute value

of a 2's-complement number in three machine-code instructions without

a conditional instruction that may cause the pipeline to stall.  But someone

reading the code will have absolutely no idea what it does, unless well documented.

And the next hardware upgrade may eliminate the overhead of pipeline stalls

in such cases, or may have a single instruction that computes absolute value

in one cycle.

http://stackoverflow.com/questions/664852/which-is-the-fastest-way-to-get-the-absolute-value-of-a-number

(see reply by vicatcu)

Edited to add:  that's the wrong link, as noted below!

Frank,

  Here's a practical suggestion.  Computer systems are complex devices.

Most complex devices are best explained in a hierarchical fashion, rather than

jumping randomly between levels in the hierarchy.  This notion leaps out at you

if you look at the RPF's first few educational videos, compared say with MIT's

first computer science course.  Clive jumps randomly within a few minutes between

all sorts of concepts presumably unfamiliar to the viewer, such as programming languages,

IDEs, GUI's, shells, flowcharts, pseudocode, algorithms, functions, variables,

debugger break-points, text files, translators, USB ports, network ports, RAM/ROM,

BIOS, and fetch/decode/execute cycles.

For example, a galaxy such as the Milky Way is a complex object.  Viewed as a galaxy,

it can be seen to have properties such as spiral arms made of fuzzy dots of light.

Zooming in on a fuzzy dot, such as our sun, you see a solar system with orbiting

planets.  The planets are important at this level of abstraction, but they are unimportant

at the galaxy level.  Zooming in on a planet, such as Earth, you see it has a moon orbiting it,

and has blue oceans, clouds, and land masses.  Again, such features are important at

this level of detail, but not at higher levels.  You can zoom in on a particular continent,

and you will see mountains, plains, rivers, cities, etc.  You can zoom in on a particular city,

and see streets, buildings, people, etc.  You can zoom in on a particular person,

and see a face, torso, limbs, etc.  You can zoom in on the torso, and find various

internal organs and blood vessels, etc.  You can zoom in on the heart and find

its chambers and valves, and zoom further and find cells. You can zoom in on cells,

and find a cell membrane, and a nucleus, etc.  In the nucleus you will find chromosomes,

and you can keep zooming to find genes, atoms, protons/electrons/neutrons, quarks, etc.

The key feature is that what is important at one level is unimportant at other levels,

and you can begin your study at any level by ignoring higher and lower levels.

A computer system can be explained at the level of a programming language,

or it can be explained at the level of its instruction-set architecture, or other

levels, both higher and lower. But if you randomly jump around between levels,

you will probably just confuse your audience.

coder27 wrote:

 

For example, there is a really clever way to compute absolute value

of a 2's-complement number in three machine-code instructions without

a conditional instruction that may cause the pipeline to stall.  But someone

reading the code will have absolutely no idea what it does, unless well documented.

And the next hardware upgrade may eliminate the overhead of pipeline stalls

in such cases, or may have a single instruction that computes absolute value

in one cycle.

http://stackoverflow.com/questions/664852/which-is-the-fastest-way-to-get-the-absolute-value-of-a-number

(see reply by vicatcu)

Ooh, that is a cute way to do it.  Yes, it needs to be well documented, just like any trick.  But I would see that exactly as something that should be taught since it helps students master 2's complement arithmetic.

uint32_t temp = value >> 31;     // make a mask of the sign bit
value ^= temp;                   // toggle the bits if value is negative
value += temp & 1;               // add one if value was negative 

Hmm, that looks more like 4 machine instructions since the last one does two operations, AND followed by ADD.  The ARM instruction set has a condition code field for most instructions which allows you to do it in two very straightforward instructions, one to test the value of X and one to conditionally replace it with -X.  You might be able to combine the test of X with a previous operation and get by with just one instruction.  Thumb2 requires an additional IF instruction.  Other instruction sets have conditional register-to-register moves.

Of course, getting the compiler to notice that it can use conditional instuctions can be problematic, particularly if you use vicatcu's trick.  This gives another important lesson since it requires students to understand computers at the machine-language level, and the whole idea of avoiding conditional branches is because of pipelining, which is another thing students of computing should understand.  Amazing how something as simple as finding absolute value opens multiple cans of worms

oh eeek !!!!!!

uint32_t temp = value >> 31;

is implementation dependent behaviour in C.

I'm assuming that value is int32_t so this applies:

The (1999) ISO standard for the C programming language defines the C language's right shift operator in terms of divisions by powers of 2.^[5] Because of the aforementioned non-equivalence, the standard explicitly excludes from that definition the right shifts of signed numbers that have negative values. It doesn't specify the behaviour of the right shift operator in such circumstances, but instead requires each individual C compiler to specify the behaviour of shifting negative values right.^{[note 6]}

note 6 says:

^ The C standard was intended to not restrict the C language to either ones' complement or two's complement architectures. In cases where the behaviours of ones' complement and two's complement representations differ, such as this, the standard requires individual C compilers to document the actual behaviour of their target architectures. The documentation for GCC, for example, documents its behaviour as employing sign-extension

(from http://en.wikipedia.org/wiki/Arithmetic_shift)

@John,

I know you didn't actually say it was C but I felt I should warn the unwary - of course in assembler there is no dificulty in specifying logical or artimetic shifts - and in VHDL we can do anything.

MK

Hmm, that looks more like 4 machine instructions since the last one does two operations, AND followed by ADD.

Oops, you're right.  That wasn't the clever 3-instruction way I was thinking of.  This is:

http://www.geeksforgeeks.org/compute-the-integer-absolute-value-abs-without-branching/

Michael Kellett wrote:

 

oh eeek !!!!!!

 

uint32_t temp = value >> 31;

 

is implementation dependent behaviour in C.

 

I'm assuming that value is int32_t so this applies:

 

The (1999) ISO standard for the C programming language defines the C language's right shift operator in terms of divisions by powers of 2.^[5] Because of the aforementioned non-equivalence, the standard explicitly excludes from that definition the right shifts of signed numbers that have negative values. It doesn't specify the behaviour of the right shift operator in such circumstances, but instead requires each individual C compiler to specify the behaviour of shifting negative values right.^{[note 6]}

 

note 6 says:

 

 

^ The C standard was intended to not restrict the C language to either ones' complement or two's complement architectures. In cases where the behaviours of ones' complement and two's complement representations differ, such as this, the standard requires individual C compilers to document the actual behaviour of their target architectures. The documentation for GCC, for example, documents its behaviour as employing sign-extension

 

(from http://en.wikipedia.org/wiki/Arithmetic_shift)

 

@John,

 

I know you didn't actually say it was C but I felt I should warn the unwary - of course in assembler there is no dificulty in specifying logical or artimetic shifts - and in VHDL we can do anything.

 

MK

The last one's complement machine I used was a Univac 1110.  Negative zeros could sometime do nasty things.

OTOH, one's complement arithmetic is a nice way to implement floating-point addition and subtraction.  Who's ready for a carry look-ahead end-around carry?

I'm afraid that I do make heavy use of the fact that all the machines I run on are two's complement.  For example, I represent angles using Binary Angular Measurement, where two's complement and unsigned numbers represent exactly the same angle.