New Programming Resource

econjack

Well-known member
All:

Most of you are seasoned programmers, but there's a significant knot of people here who are not. I am a retired professor from Purdue University's College of Technology and author of 20 programming books. I recently finished Beginning C for Microcontrollers, which replaces my Beginning C for Arduino book, both of which may be seen on Amazon. (The older book has more reviews.) The book is designed for those who have no prior programming experience and contains code for the T4 and T4.1 microcontrollers.

If you know of someone who is having problems learning C in the microcontroller environment, perhaps I can help.

Thanks!

Jack Purdum, Ph.D
 
I'm curious about your thoughts on teaching C vs starting with C++. IMO, better not to have to unlearn bad habits.
 
It really depends upon your goals. If you're looking for a programming job, a good C++ book is probably the way to go. For those who intend to be "Project-oriented" programmers, I think C is a great place to start. Also, Chapter 12 in the C book is titled "A Gentle Introduction to C++ and Object Oriented Programming". I don't have enough hubris to think I can cover either topic in one chapter...that's not the goal. The goal of the chapter is to convey enough about both topics to help the reader to appreciate, understand, and read the source code for the IDE's libraries, most of which are written in C++. While there aren't many reviews of the new book yet, my style hasn't changed much, so read the reviews for the older beginning C book to see if it might be helpful.
 
I think something like MISRA C++ would be best for beginning embedded programmers. Not just for a job, but for better (more reliable, easier to maintain, etc) programs.
 
I looked on their site and saw style guidelines, but not an introduction to the language, which is what my book is.
 
C++ is a very powerful language; but it has 35 years of baggage which translate into overly complex syntax, bizarre rules, and error messages that sometimes seem deliberately unhelpful. In high-level contexts (C++ and header files) you have to be directly aware of low-level implementation details. For example, you have to keep templates in header files because of Reasons. It can seem quite punitive before you climb the learning curve, which is steep.

C already has enough concepts that take time and persistence to master (pointers, casting, arrays and structs, and various combinations thereof) that I would recommend learning that first. That is how it was for me in college, and I think it was a huge benefit. If someone does start with C++ with no previous C experience, they would be well-advised to keep the "OOP" stuff as simple as possible, especially early on.
 
@econjack welcome home.

The Teensy is an outstanding MCU and this forum is the best. I'm sure you will be called on.

At the risk of speaking for Paul, perhaps a book branded for the Teensy?
 
Welcome. I'm no newcomer but I am interested in your book. If I am asking, is it then appropriate for you to post a link to your book?
 
The book is available on Amazon and I'm using my web site, SoftwareControlledHamRadio, as a repository for related files (e.g., answers to the Exercises). The cover has a Look Inside banner so you can see the TOC and read a little. My Beginning C for Arduino has more reviews but the newer book is significantly better. (I may be biased.) However, the reviews on the older book still reflect my teaching/writing style. It's available in printed and eBook form.

I actually wrote to Paul before I wrote the first Intro book, because I really liked the Teensy family. However, Paul was probably too busy on the T4 to get back to me. All of the examples in the new book will run on the T4, but don't really show off what it's capable of.
 
A book on how to write on oscillator or envelope generator for the teensy might be great. I can think of several functions I'd like to add. I already contributed one that was modified in subtle but significant fashion that I no longer really understand the code for the function I originally wrote. How about a comparator function with two signal inputs and a third input to set the output level on an A>B event? that would be all kinds of great for music and radio, but I dunno how to write it.

There's a bazillion books for Arduino. But a book specifically about Teensy - especially focused on the 4.x and later - would be grand.
 
I do spend a complete chapter on good function design, with special emphasis on writing cohesive and non-coupled functions. You should ask yourself: What could I have done back then to make it easier to understand what I wrote today? There are a number of things that can done from consistent function headers to embedded support references and URL's. That kind writing is not unique to the Teensy.
 
I haven't seen your book, but...
Some thing I've learned over the many, many years as a bumbling programmer is...

In C++ unless it's a Boolean, it's probably a pointer, not an actual object. That doesn't stop anyone from using a pointer to a pointer to a boolean, though. It's pointers all the way.
(I ran into C++ on Windows 3.0 back in 1992, after learning ADA on VAX... WHAM! )

Any book about Arduinos is bound to spend the first half doing the same 'light up that LED' example or other, 'Read that Button' and the classic How much is that Resistor in the window'... Then they change gear completely...
They're generally completely useless for explaining language structure, or even explaining how all the commands work properly.

Sometimes I just want to go back to a Parallax Basic stamp(2p... or 2px... I have them somewhere. ) because the user manual for those are properly brilliant.
(and it's downloadable for free)
But they don't make a 600MHz BS2...
And their Propeller (8core 32bit mcu. No Stack, no PUSH or POP, but hey, self-modifying assembly code) just makes my head SPIN.

I'm going to take a look at your book.
 
The book really is a beginning C book. While I do have a chapter on C++ and introduce the reader to the OOP Trilogy, I do it to show that parts of the Trilogy (e.g., Encapsulation) can be done within a pure C framework. To think I could even discuss C++ in one chapter in a meaningful way is impossible...not going to happen. Instead, the intro to C++ is done so the reader can look at some of the library code for the IDE and at least have an idea of what they are looking at. I do this very simplistically by having the reader view an object as a black box and the dot operator is the key that lets them access the properties and methods therein.

Some of the teaching tools are quite old (e.g., my Left-Right Rule was published in my first C book over 35 years ago: http://jdurrett.ba.ttu.edu/3345/handouts/RL-rule.html). Still, those tools are geared to the rank beginner and work for most readers. I would be very interested in hearing your comments on the book, especially since you are already a C/C++ programmer.
 
I'm NOT a C/C++ programmer.

I've programmed in C++ once, and even have Watcom C++(v11 or something, lots of diskettes... ) somewhere.
I never really got over the first hill,and really decided that I didn't want to be a full-time programmer after that.
(I work as server admin, netowrk tinkerer, PC fixer and ser support in a large organisation now. And I'm good at it... I did some Visual Basic stuff a while ago, but as I always scrubbed my hands thoroughly afterwards, it doesn't really count )

I have puttered in Basic(on Sinclair ZX Spectrum. Timex Sinclair 2000something in the USA), then went on to try Assembly on the Z80 and 6502, tried Turbo Pascal on both CP/M and DOS even Assembler on 8086. Then the ADA stuff(I kind of liked ADA. Multitasking was a bit awkward, but then again it was in the early 90s. Never tried ADA95, though) I also did an assembler project with a 8052mcu (Timer with 4 relays, 8 independent programs that could overlap, and a countdown timer. )

Then came the C++ bit where I was porting a program someone else had written from some Unix system to Windows 3.0...
After that I didn't do any programming until 95 whenI got myself a Psion S3a PDA. The OPL programming language(reasonably similar to Pascal) makes it EASY to make simple apps with dialog windows and drop-down menus. OPL on the S5 (16MHz ARM chip) supercharged the experience.
I even made a few Shareware programs.
I got intrested in microcontrollers...
Got myself a Parallax BasicStamp II and began hacking together some BASIC programs. And with a BS2p I put together a car locking system using Dallas Semiconductor iButtons.(but got a newer car with central locking before it was finalized) Serial comms and LCD was easy.
I did some decent REXX scripting on OS/2 (DB front-end for one of my collections, but this was later rewritten in OPL since it does proper SQL)
Got hold of an 1986 Psion Organiser II (6301 cpu.) and built an interface with a magnetic sensor nicked from a bike speedo, and combined Assembler and OPL to create a slightly more capable speedo(average speed last minute is nice when dealing with loooooong uphills, and we have many of those here in Norway) Unfortunatel, I didn't use Low Power or CMOS chips, so it drained the 9volt battery in minutes...

I got into the Parallax Propeller when it was introduced, and who wouldn't?
32bit 8core mcu... Only 512 LWord(32bit) memory locations for each core, but it can still do some really awesome stuff.
(One guy designed a game console with VGA graphics, and approximate Super NES performance)
But the SPIN high-level programming language was a bit too OOP for me. And I struggled with handling assembly when you don't have PUSH/POP or even Return...
(They took the rulebook and launched it to outer space when they designed the chip)
They've also opensourced the design of the Propeller.

The P2 is now in rev 33 or something, and is open source. Want to emulate it? download the Verilog files...
(Or try to grab an engineering sample)
If Pascal gets ported to it, I will definitely get hold of a 16cog version...
(People have ported C, Forth and Pascal to the first Propeller, also)


I'm really one of those who can't properly learn a language without having a task I want to accomplish. Just doing exercises tends to bore me too much.
And I've never really had a task that I wanted to solve on a platform that uses C.
 
There's absolutely nothing wrong with only doing programming when there's a task to be solved. Indeed, I also have another new book titled Microcontroller Projects for Amateur Radio (http://www.arrl.org/shop/Microcontroller-Projects-for-Amateur-Radio/) that is very task-oriented and uses the T4 for its DSP projects. As to the Exercises, not everyone even reads them, let alone tries to answer them. Still, they can at least provide some feedback as to how well they are absorbing the material. I do have an unusual way of teaching (e.g., discussions of lvalues, rvalues, symbol tables, etc.) and it worked pretty well when I was teaching. Truth be told, someone with your experience and background likely would not benefit from my beginning C book.
 
The book really is a beginning C book. While I do have a chapter on C++ and introduce the reader to the OOP Trilogy, I do it to show that parts of the Trilogy (e.g., Encapsulation) can be done within a pure C framework.
One of the interesting things I've learned from watching Robert C. Martin videos is that C already had perfect encapsulation (structs) and visibility (static functions, if I recall), and C++ actually made encapsulation worse!

I was looking at some stats yesterday, and it seems that according to some reports C is still the world's most popular language. The Linux kernel, git, and PHP are all written almost entirely in it, with some assembly here and there. There is no plan to port any of these to C++. It turns out that C++ brings with it certain things (like vtables) that make it harder to debug, and Boost introduces portability issues.

But the SPIN high-level programming language was a bit too OOP for me. And I struggled with handling assembly when you don't have PUSH/POP or even Return...
Assembly language without a stack seems bizarre. What do you do, allocate memory for everything? At the end of a routine, do you just jump somewhere?
 
I don't think C has "perfect" encapsulation in that function definitions still lay outside the structure. Static functions help, but only at the file level. Someone once said that C gives you the power to shoot yourself in the foot, while C++ gives you the power to blow your whole leg off. In most cases, I find C sufficiently robust to do just about anything I want it to do, and that's good enough for me.
 
Assembly language without a stack seems bizarre. What do you do, allocate memory for everything? At the end of a routine, do you just jump somewhere?

Self-modifying code...
When it 'calls' a subroutine, it also modifies the 'Return' instruction from it with the correct return point.
It's something that's possible when you only have a few instructions, and a 32bit word.
(It's a very RISC architecture)
It's something you can get away with when all cores(called COGs) all have their own exclusive memory space.


There's absolutely nothing wrong with only doing programming when there's a task to be solved. Indeed, I also have another new book titled Microcontroller Projects for Amateur Radio (http://www.arrl.org/shop/Microcontroller-Projects-for-Amateur-Radio/) that is very task-oriented and uses the T4 for its DSP projects. As to the Exercises, not everyone even reads them, let alone tries to answer them. Still, they can at least provide some feedback as to how well they are absorbing the material. I do have an unusual way of teaching (e.g., discussions of lvalues, rvalues, symbol tables, etc.) and it worked pretty well when I was teaching. Truth be told, someone with your experience and background likely would not benefit from my beginning C book.

Nothing wrong with examples and exercises, but everyone does the exact same ones, all nicked from the arduino documentation...
Then there's usually a big leap from 'spoon feeding' and directly to the advanced level.
It's that leap I tend to stumble on every time I try to up my skills.
 
Nothing wrong with examples and exercises, but everyone does the exact same ones, all nicked from the arduino documentation...
Then there's usually a big leap from 'spoon feeding' and directly to the advanced level.
It's that leap I tend to stumble on every time I try to up my skills.

Then you sir are a good candidate for Jacks book. It does not do the same ole same old thing as all others. If you read it AND do the exercises, it WILL teach you C. It will up your skills. I have read both and they are worth their weight in gold.
 
Then you sir are a good candidate for Jacks book. It does not do the same ole same old thing as all others. If you read it AND do the exercises, it WILL teach you C. It will up your skills. I have read both and they are worth their weight in gold.

Thanks for the kind words...they are appreciated!

Jack, W8TEE
 
I think something like MISRA C++ would be best for beginning embedded programmers. Not just for a job, but for better (more reliable, easier to maintain, etc) programs.

Last time I've seen MISRA C++, it was ancient and obsolete for C++11. For example single exit point results into nasty and long code, one or more variables over whole procedure and so on. As RAII paradigm doesn't exists in C++.
 
I still have my original K&R book...paid $8.95 for it! Indeed, I became a convert to C because of that book and tried my best to "sell" it to others in the late 1970's. Honestly, I was not formally trained in programming and found K&R tough sledding, as did many of the other programmers I was trying to convince to switch to C. As a result, I wrote the C Programming Guide in 1983 which did quite well and went through three editions and 10 foreign languages. While I was "forced" to use Pascal, Visual Basic, Java, and C++, C has remained my favorite programming language. It might not be the best programming language, but for me, it's way out in front of whatever is in second place.
 
Different tools for different purposes - C is not suited for programming in the large or for high-level coding.
The lack of array-bounds checking in C and C++ is partly responsible for the huge blight of viruses and trojans
over the years as most vulnerabilities are due to this one rough-edge.
 
A good friend of mine worked in a Java shop and preferred C over Java, but didn't have a choice. He complained "Java doesn't use pointers and wastes time doing boundary checks. It's like C with training wheels!" I do, however, appreciate what you're saying about vulnerabilities. If one language could do it all, we'd only have one language.
 
Back
Top