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.

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 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 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!

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.

coder27 wrote:

 

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.

My opinion is that if you code your application properly, your "later phases of the software lifecycle, including testing, debugging, maintenance, and enhancements" require a lot less effort.  You didn't mention documentation.  IMO you should always try to do that first, because once your problem and software architecture and major data structures are documented well the coding and other phases are smoother.  Why?  Because design problems become obvious when you start writing about them, but when you just start coding you run into roadblocks and have to kludge-upon-kludge your way around them.

Coding an application properly includes using a language that's well suited to your application so it's clear that your code is solving the correct problem.  If no language is suitable, use a language that you can extend towards your application.  You don't want "coding" to be synonymous with "encryption".

Jonathan Garrish wrote:

 

... 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.

I did most of my early programming with punched cards on a shared computer (sometimes batch, sometimes sign-up-for-an-hour-a-day minicomputer).  I am extremely grateful that I had to go through this Purgatory because it taught me a lot of discipline that makes me a more accurate programmer with a non-shared interactive environment.  When you have limited access to a computer, you spend the off-line time flow-charting, thinking, and reviewing your code, often finding problems and corner cases you would have missed in a hacking environment.  Punched cards also had the huge advantage of forcing you to keep your programs as small as possible, since there were only 2000 SLOC per box of cards and you could only "comfortably" carry two boxes.  So I was always thinking about small, elegant ways to do things instead of copy-and-pasting code found "whereever" and trying somehow to hack it together.

I don't get your comment about languages intentionally mystifying.  I think most languages, and particularly the ones that are surviving, really try to provide clean, efficient ways for programmers to express their ideas.  I don't think C++, SmallTalk, or even APL are intentionally trying to mystify -- I think it's just that their creators find those notations good for what they wanted to express, and perhaps others just don't think about things that way.

The principle that I always tried to instill in my ElecEng students each year was that programming languages are just tools in a toolkit, and you need to pick the right one for the job.  The common metaphor of banging in screws with a hammer is much more than just a funny image.  It's absolute reality that you will not do a good job if you adopt that approach.

That's why we exposed them not only to the lingua franca of C but also to machine and assembly code, and to Smalltalk, and to Ada, and to LISP and Occam and other specialist languages of various kinds, each one better than the others in some particular domain of application.  It might have blown a few narrow minds, but minds are resilient and they will have been expanded by the experience and become better engineers.

"But I only know language X" is the epitaph of the poor engineer without any actual understanding of what languages do in the grand scheme of things, and without the ability to recognize when their single tool is failing them because they lack a basis for comparison.  The answer is always "Go learn more".  They don't bite, and each one you learn makes the next one even easier to pick up.

And if you know several languages and hence are able to recognize that language Y would be better but you're not an expert in it, then great, you now know who to hire to do a good job for you.  You still win.

Morgaine.

Addendum.  It may be worth pointing out that if the only languages sought out are those that feel comfortable and familiar, then very little that is new will be learned.  It would be tantamount to sabotage of the motive behind the advice to learn more languages, since it would deliberately narrow the breadth of experience gained.  Not only would that be a bad move for learning, but also a waste of one's time.  Seek out the new and different.

Hi

It all depends what you want to do. Is the RPi a learning tool or a doing tool? If you want to learn then go the roundabout way, learn the good and bad bits of each route. If you want to do something today go the familiar quickest route.

So is MagPi primarily an educational tool? I think it is.  Problem is that a bad examples can be good learning experiences in the right environment and a complete put-off in the wrong place. I don't know anything like enough about different languages - insufficient education I am afraid - but I do know a bit about hardware. I get bogged down in all the new software stuff, which to me seems insufficently explained,  just as I see others getting bogged down in what seems the absolute simplest hardware - but its not really so simple. If you are operating anywhere near the limits (and how do you know that?) you need to be able to read a datasheet, you need to understand what hFE is, why it is quoted as x, but is likely to be less depending on VCE, what VCESAT is, hell even what saturation is, why PTOT assumes TCASE=25C, and so on.

I have suggested elsewhere that MagPi do a language comparision on the RPi  - just the "Hello World" example in as many languages as possible - always starting from the same point - a freshly made SD card.

It is so easy to say 'PRINT "HELLO" ' without mentioning the need to download the package, install, setup, make, get the missing jScript, oh did I mention this dependency and you didn't realise you needed Apache or HTTTP (and you dont what they are - ny fuwl now that), what you have both? and Python and PHP? you can't do that!

One great advantage of the RPi over a PC is that you can very easily go back to square one. You can have as many setups as you have SD cards. If only my various RPi's would boot more than about one time in 3 and didn't need coaxing each time (and yes my power supply is good, and my Polyfuses  bipassed (all of them - I like to live dangerously)).

And later consider how the starting points can or can't be expanded to cover GPIO, web access, whatever. How particular add-on package might provide the GPIO accesss to any language (except that one of course) and so on.

End of ill-considered steam of conciousness rant.