The MagPi Magazine - Aimed at learners - Printed edition Kickstarter

I hate to be so negative, but the writing in this magazine seems to be getting worse. I have read every one so far, but in the most recent one there seems to be a number of things that just leave the user hanging or have obviously been written by someone who is an expert in what they are doing, but can't convey that information properly to a beginner.

I did look at the Kickstarter on this, but couldn't justify it on the grounds that better information is either available freely on the web, or via one of the many books popping up recently that are cheaper than the bound set of these magazines.

I was however happy to see the Ciseco Eve Kickstarter get funded and I have my board from them already :-)

Steve

I hate to be so negative

Yea it's not like you have a history of that in Rapberri Pi forums or anything. Oh, wait a minute.

John Beetem wrote: You can have upper NPN drivers provided that you can get the base voltage higher than the emitter voltage.  The L298 diagram doesn't show the details of the AND gates that drive the upper NPNs.  I suspect they convert TTL input levels to "Vs".

You're right. I found a data sheet for the L293 and the first stage transistors on the motor drivers are tied to the motor supply.

I haven't read MagPi Magazine myself, but I've read good reviews of it.  Its audience is new RasPi users who don't have strong technical backgrounds and don't know where to start.  Old timers like yours truly are excited by RasPi because of its ridiculously low cost for a GNU/Linux "box" and we know what can be done with such a board: basically the same things we did with $295 boards five years ago, but now the penalty for smoking a board is the cost of a good dinner.  But we're not the official RPF target audience.  The target audience is young pups who don't know what they're doing but have boundless enthusiasm and "Insatiable Curiosity, which means they ask ever so many questions" [Kipling].

 

MagPi is a way to get them started.  Like all magazines and wikis that depend on unpaid contributors, quality varies and at some point a magazine needs to decide if it should follow a strict periodic publication schedule or only publish when they have something worth saying.  Personally, I find most printed matter becomes obsolete pretty quickly and a well-edited wiki with an enthusiastic community behind it is a much better use of 21st Century resources.

 

Googling things is problematic.  If you know exactly what you're looking for and have enough knowledge to filter out the high noise content it can be very effective.  If you're a newbie, it's hit and miss -- mostly miss.  I generally start tech searches with Wikipedia, which often has excellent technical information though not always -- quality depends on whether there's someone (preferably plural) fanatically interesting in the topic who takes the time to polish the article.  I go to Wikipedia to fill in gaps in my knowledge, not to learn something big like logic design or circuit theory from scratch.

Hello John,

I don't think we're too far apart on this :-) I think the Pi is a great catalyst for those of an inquisitive nature and has a great number of possibilities. But those with that sort of mind normally like something to get their teeth into straight away. Whilst I'm all for delayed gratification in most cases, I just think that £25 spent on one of the current Pi books and a starter book on electronics would be £25 better spent, with more immediate rewards, even for a newbie.

If the magazine continues as a free enterprise, then more power to their elbow, time is precious for everyone and they are giving up their own time for the benefit of others. If it does become more of a commercial enterprise though, I think they need to up their game a bit to ensure success.

Steve

Hi

This is Meltwater, one of the MagPi members, after spotting this thread, I thought I would pop my head over the parapet and see if we can get to the bottom of it (I just hope I don't regret doing so).

If we've over looked something (which is more than possible - there is not a vast amount of time available split between the team, while every effort is made where we can to check things) then I would like to ensure that suitable corrections are made.  The magazine is community based, and we accept that we can't get everything right on our own.

Firstly, the circuit is aimed to provide a direct link to the manual switches for the readers understanding, and also to aid with the basics of transistor selection.  While I am aware there is a question around the min gain value for the transistor used (RS quoted it as 210, but I've seen that as the typical value in other places, so RS may have this wrong and caused that problem).  Also, the calculation for the base resistor may incorrectly ignore the 0.7voltage drop, although I believe this results is less current drawn by the GPIO than expected.

I know there are people who do such electronics every-day, and probably can do stuff like this in their sleep, so I would welcome clear answers about this specific circuit.  I am well aware there are better options out there, but as mentioned, it was selected to allow a clear parallel between the circuits.

Right, I'm off to hide!

PS. The price of the printed edition is purely at cost price and to ensure we don't make loss on printing more than we sell.  The magazine will remain free online, just as it always has.  Printed versions were what people asked us to provide too, and we hope that allows more people to see it and hopefully become interested in the RPi and engineering (as per the foundations own goals).

Thanks meltwater.

Hi meltwater, I'd just like to say that minor mishtakes crop up in publications all the time - even after the most vigorous of applications of the blue pencil... At least with an online publication any issues can be caught within hours, rather than having perhaps a month's turnaround on corrections / clarifications.

That said I can appreciate the value of the option of hardcopy - squinting at a pdf is a soul destroying task for an old giffer like me and I find that the remoteness of said document distracts me from it's actual content.

Anyway, keep up the good work, I think that the mag addresses topics that would be of interest to the average Pi owner very well. My only tiny quibble with the publication is that I'm not a huge fan of the handwritten font, but that's just my personal taste. Good luck with the hardcopy launch!

@ melt water,

Congrats re. raising your head over the E14 parapet !

I'll try to be nice (or at least helpful).

I've read the article a bit more carefully now and it contains so many errors that I hardly know where to start !

The transistor chosen is not suitable, RS don't publish a proper data sheet but you can find one on the web. To get the transistor to turn on hard enough to meet the published saturation CE voltage you need 60mA of base current (which they say is pulsed). It's usual that Vcesat is measured with much larger base current than you might expect from Hfe calculations because the Hfe approximation doesn't hold in saturation. Even with the massive 60mA base current the typical Vcesat will be about 250mV at 2.5A resulting in a power of 625mW in the transistor which is perilously close to the spec maximum of 700mW.

If you drive the transistor with 3.3V through 270R you can expect a base current of about (3.3 - 0.9)/270 = 8.8mA and Vce of at least 3V (yes 3V) at 2.5A, which will give you 6.25W into the transistor which will fail almost instantly.

As a rough and very general guide you should only ever expect to get about 50% of the published headline performance out of a transistor (except for voltage ratings where you can expect them not to fail at rated voltage but should only work at  a max of 80%).

The RPI outputs are so dammed feeble that MOSFETS or motor drive chips are your only hope - I suggest a motor driver chip because you get the full H bridge an dsome protection in one easy to use DIP package.

Michael Kellett

Hi

@MK

I tried to suggest on the RPi forum that there might be a few things wrong with the circuit. I regret I got a bit carried away but, as you says " it contains so many errors that I hardly know where to start" and I lost it. 

Anyway the rejoinder was that there is nothing at all wrong with the circuit - it works perfectly and that's that.

All electronic theory thrown to the wind. Shame really.

Hi again

@MK Sorry I don't understand the 6W25. If the bottom transistor is in saturation at 2A OK a big IF) then the power dissipated would be approx 0V4 x 2A5 = 1W, which is too much but not 6W5.  If power rail is 4V5 (I understand the modern BT uses 3 x 1V5) the top transistor would seem to be dissipating  (4V5 - 2V76 x 2A5 = 4W5- way, way too much but still not 6W5.

As I read the datasheet the hFE(min)  is quoted as 140 at Ic=2A. It is pulsed to avoid the thing over dissipating. AFAIK the value of hFE is not affected by pulsing (except in as much as the transistor does not go up in smoke).

Unless anyone can tell me I am wrong the top transitor has its collector at supply voltage and its emitter is never above 3V3 - 0V7.

Hi Graham,

I didn't do the math (btw this transistor seems very obscure), but from a mental simulation! : the top transistor will have a few volts across it, so

even if the motor only takes a few hundred mA, the to92 package will be dissipating way more than it is designed for.

At 2.5A, the dissipation will be of the order of watts, so even other physically very large BJTs would be running hot. The bottom one would be hot too.

@Graham,

Not sure if we have the same data sheet but mine shows that the transistor will not saturate at 2.5A with the 8.8mA base current it will get - that's why you'll get 2.5V across it. I was assuming the power rail issue was fixed since the article talks about putting 2.5A into the motor. (We're back to the "so many things wrong" issue again )

I'm attempting to attach the data sheet I found.

(attempt failed !)

Google for BCU81 Magnatec

Michael Kellett

Steve,

You wrote:

> Also, i'm not sure what the point is of doing two articles on programming languages (Cecil and ADA) that are hardly in the sphere that the Pi is aimed at.

I disagree with this.  I think teaching kids of all ages to program is squarely within

"the sphere that the Pi is aimed at", and doing articles on programming languages

is squarely within the sphere of teaching programming.  Certainly a Computer Science

degree at any reputable school requires a class surveying multiple programming

languages.

There seem to be hardware engineers that would like to see more emphasis on

hardware topics, and software engineers that would like to see more emphasis

on software topics, but that's to be expected.  Byte Magazine used to have a

popular column by Steve Ciarcia on hardware, and Jerry Pournelle on software

(including surveys of programming languages such as Ada), which worked well.

It is generally accepted that knowing at least the highlights of several programming

languages, even obscure ones, makes you a better programmer in whatever language

you end up using.

Hi coder,

Yes, didn't explain myself well there. Completely agree that programming is very squarely in the market that the pi is aimed at, but not sure that two fairly unusual languages would serve that purpose well, at least for people starting out with the pi and programming.

Mind you,I remember playing around with Prolog on my Spectrum many years ago, so what do I know :-)

You mention Jerry Pournelle - love it when he is a guest on Leo Laporte's podcasts. He is such an amazing person.

Steve

Hi coder,

Yes, didn't explain myself well there. Completely agree that programming is very squarely in the market that the pi is aimed at, but not sure that two fairly unusual languages would serve that purpose well, at least for people starting out with the pi and programming.

Mind you,I remember playing around with Prolog on my Spectrum many years ago, so what do I know :-)

You mention Jerry Pournelle - love it when he is a guest on Leo Laporte's podcasts. He is such an amazing person.

Steve

Hi Steve,

I still disagree, even with your clarification.

If the MagPi editors were pushing Ada and Cecil as "the one true way"

to program your RPi, then sure, those languages are too obscure to be

pushed that hard.  But it seems clear that they are promoting Python,

Scratch, C++, etc as mainstream languages, with Ada and Cecil

touted as just interesting languages you can use on your RPi.  So the

obscurity doesn't bother me at all.  Pretty much any language has

interesting features that are worthwhile for student programmers to

learn about.

By the way, Ada isn't nearly as uncommon as you might think. 

Its application domain of large-scale embedded systems, primarily

in aerospace and defense hasn't grown nearly as fast as other

domains such as smart phones and web programming, but is

still quite large, and compiler support is quite good.  Ada is also

relevant historically as the basis for VHDL, and has had significant

influence on other languages such as C++ and Java.

Hi Coder,

Having thought about it, I guess I'm coming round to your way of thinking. It's hardly like they are pushing Ada or Cecil as the languages at the forefront of Pi programming and it is always good to learn about new ways of doing things.

Perhaps I should look at the Cecil article again and give it a bash !

Steve

Steve,

> and it is always good to learn about new ways of doing things

exactly!  Here are some concrete examples.

In Fortran 66, like in assembly language, the only control structures

available are the goto, conditional goto, and subroutine call.  Later,

languages such as C and Pascal popularized "structured programming" with

higher level control structures such as if/then/else and do-while/repeat-until

loops.  The main advantage of these control structures is that when

reading a particular line of code, it's always clear how you must have

gotten to that line, because "spaghetti code" with arbitrary forward and

backward jumps isn't allowed.

Fortran users didn't need to switch to C or Pascal to take advantage of

this concept.  They could continue to use Fortran, but with preprocessors

such as Ratfor, or even without using a preprocessor, they could

simply make disciplined use of goto's.

In the 80's, modular languages became popular, with separation of

interface from implementation, for much the same reason.  When

you are reading code in a module, you want to know that you could

only have entered the module through one of the subroutines in the

module's interface.  This discipline can be practiced in any language,

even if the language does not enforce it.

With the popularity of object-oriented concepts such as inheritance

and dynamic dispatching, it is possible to use those concepts in

languages such as C that don't provide any direct support, but do

allow indirect subroutine calls.

coder27 wrote:

 

Steve,

> and it is always good to learn about new ways of doing things

 

exactly!  Here are some concrete examples.

 

In Fortran 66, like in assembly language, the only control structures

available are the goto, conditional goto, and subroutine call.

        DO 10 I=1,100

10    WRITE(6,20)

20    FORMAT(27HYOU FORGOT THE DO STATEMENT)

        STOP

I should also pick on you for not mentioning computed GOTO and assigned GOTO

coder27 wrote:

 

Later, languages such as C and Pascal popularized "structured programming" with

higher level control structures such as if/then/else and do-while/repeat-until

loops.  The main advantage of these control structures is that when

reading a particular line of code, it's always clear how you must have

gotten to that line, because "spagetti code" with arbitrary forward and

backward jumps isn't allowed.

Structured programming constructs were already popular from the time of Algol 60, but primarily among computer scientists.  Fortran programmers viewed them with suspicion and claimed they optimized poorly.

C and Pascal frown on using gotos, but provide them in the language so it's still possible to write spaghetti code.  It's also possible to move spaghetti logic to the conditional flags of the the form "while not found and not error do begin {bunch of nested hard-to-follow logic} end".  Handling error conditions is often much easier to follow using a goto as an exception.

It's also worth mentioning that at the time of Fortran 66 and Algol 60 it was common practice to flowchart your program before coding it, so the structure was clear despite gotos.  Much easier to tell if there's spaghetti logic or other wooly thinking with a flowchart.  It was also standard practice to hand-check programs before submitting card decks since turn-around was too slow to permit hacking.

JMO/YMMV

John Beetem wrote:

 

It's also worth mentioning that at the time of Fortran 66 and Algol 60 it was common practice to flowchart your program before coding it, so the structure was clear despite gotos.  Much easier to tell if there's spaghetti logic or other wooly thinking with a flowchart.

 

JMO/YMMV

Flowchart use is still very much standard practice here - possibly because I have a head like a sieve! The influence of BASIC can still be felt here 30-odd years on...

Perhaps modular programming will really come of age when all we have to do is draw a flowchart and our friendly compiler will burp out the code for us. Heresy perhaps, but I'm not a subscriber to the "it's supposed to be hard, dummy" whatnot. We'll still need a few smart folks to write the compilers, after all. Life's too short to learn proper code and be creative!

John,

  Good points.  I was really sloppy forgetting to mention Fortran's Do loops,

which were there from the beginning.  But Fortran, along with Cobol and Basic

took a long time to adopt the if/then/else and while-loop constructs that are now

considered fundamental, although enlightened and disciplined programmers can

avoid writing spaghetti code in any language.

Fortran creator John Backus is quoted as saying: "we did not regard language

design as a difficult problem, but merely a prelude to the real problem: designing

a compiler which could produce efficient programs."

Of course, now the tables have turned, and efficiency is no longer a major concern

for most programming languages, but language design is considered a difficult problem.

Jonathan,

You wrote:

> Life's too short to learn proper code and be creative!

I'm not sure exactly what you meant.  Some people think there is a conflict

between creative programming and disciplined programming, but I don't.

Some people think time spent coding is important, but usually it is far

outweighed by later phases of the software lifecycle, including testing,

debugging, maintenance, and enhancements.  Taking an enlightened

and disciplined approach to code writing can more than pay for itself in

the later phases.

Ludwig Wittgenstein wrote: "The limits of my language means the limits

of my world."  I think that's applicable to programming languages too.

coder27 wrote:

 

Jonathan,

You wrote:

> Life's too short to learn proper code and be creative!

 

I'm not sure exactly what you meant.  Some people think there is a conflict

between creative programming and disciplined programming, but I don't.

 

Some people think time spent coding is important, but usually it is far

outweighed by later phases of the software lifecycle, including testing,

debugging, maintenance, and enhancements.  Taking an enlightened

and disciplined approach to code writing can more than pay for itself in

the later phases.

 

Ludwig Wittgenstein wrote: "The limits of my language means the limits

of my world."  I think that's applicable to programming languages too.

Well... You're absolutely right in that the actual coding is only a small part of the whole conceive -> write -> tweak iterative thinger, but:

some people are just plain better at dreaming up an effective original concept and others may be better at the discipline of turning it into code. Another person still may be better suited to testing every possible combination of user situations in order to shake out bugs in a repeatable manner, document them clearly and suggest ways in which workflow could be improved with regard to the ordinary mortals who will be the end users (coders are by no means ordinary mortals).

I don't think that this concept is anything new. It possibly started around the time when two cavemen (one of whom was good at knapping arrow heads but couldn't run very fast, while the other was a talented hunter who hated spending his evenings chipping away at lumps of flint) decided to cut a deal regarding the division of labour and mammoth steaks. Perhaps Open Source v2.0 will be more collaboration / barter friendly - because we can't all excel in every discipline and so there's a lot of talent going to waste out there. But if Open Source can't figure out a way to get people with complementary skills together (and given that the bits of the web dedicated to Open Source seem to be stuck forever in the 1990's) then programming will have to become more intuitive. It'll be the same unambiguous language(s) underneath, but wirapped in a smarter interpretation shell. Why teach a million people to think like machines when you can build one machine that can think for itself, just a little?

It'll never catch on, of course. Nobody wants to knock down the Tower of Babel.

> Nobody wants to knock down the Tower of Babel.

Really??  I think everyone is disgusted by the folly of

umpteen different ways to say the same basic thing, such as

http://brianary.blogspot.com/2011/02/then-what-elif-elsif-elseif-or-else-if.html

I'm minded of Esperanto:

"Wouldn't it be great if everyone in the world spoke the same language!"

"Awesome, except we'll have to invent a completely new language - 'cos all of the old ones are pish..."

http://en.wikipedia.org/wiki/Esperanto

It's tricky. Language is a living thing - it evolves due to the influence of it's environment. Easyish for humans, but hard for a computer lingo. Therefore you will always have issues with future proofing and backwards compatibility (or both!). My point being that the stuff that happens under the hood (if, for, else, elseif, panic...) could be completely invisible to a user, given a smart interface that could say "I can't let you do that Dave" when you're drawing an illegal loop, or whatever.

I stand by my "Babel" assertion - there are an awful lot of people out there who are of the attitude that "back in the day I had to put up with  wobbly RAM packs / punch cards / dekatrons etc. so I don't see why the young 'uns should have it easy."

One of the less savoury functions of language is to intentionally mystify, unfortunately.