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

  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.

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.