More advanced microcontroller learning resources?

Kuba Raczkowski said:

I'm guessing on a bit higher level of abstraction

Right. You definitely shall look for books which are not aimed at any particular embedded chip, those happen to be either marketing materials or just too generic. Sure there are many books that possibly match your requirements, but you have to somehow find the one. Just one I see in bookshelfs often: ISBN-13: 978-1449302146. Try searching amazon for "Embedded C programming", "Embedded Software", check contents and see which one is for you

Yes, I've seen the book you propose, it indeed seems to go the right way.

The reason I ask here is because there are really pleeeenty of books about embedded programming now, so a hint from an expert is in fact worth browsing through 1000 tables of contents. Using the queries you propose, sure brings a lot of stuff, but 99% of the references end at blinking a led...

Thanks again!

Kuba Raczkowski said:

browsing through 1000 tables of contents

Well, I did not say it will be easy :) Sometimes you need to read foreword too.

Kuba Raczkowski said:

99% of the references end at blinking a led...

Widen your search then. Go outside embedded topic, look for books aimed at higher complexity computer systems too

Good point, thanks a lot!

Kuba Raczkowski said:

Any help? Thanks in advance!

Well, if you know how to blink the LEDs etc, then the part starts where a book can’t help you much.
It’s like panting a picture. You can take calluses and learn how to mix colors, which type of pain is to be used for which project ton on which type of canvas etc.
You can learn how to compose a picture. There are quite good books about how to draw manga figures. However, every author has its own way of doing things, and of course this is ‘the way’ for him. But when you’ve assimilated all this knowledge, you need the ‘spark’ of an artist to create a picture that is more than a child’s paint.

After (or better: before) you learned how to program a microcontroller or an embedded system, you need the ‘spark’ of an Engineer. The imagination to plot a project in your mind, plan the concept, ‘see’ possible pitfalls and then use the acquired skills in programming the microcontroller to turn this image into a program.

Sure, there are books containing hints and spoilers about what to avoid and how to approach certain problems. However, usually, this information must be extracted (and often read between the lines) from descriptions of already done projects.
Also, many books provide theoretical concepts which might be good ideas but are not the only way to go or even contradict (not saying that one is wrong and one is right). Like procedural programming (like C) in opposition to object-oriented programming. Both have their field where they are superior. Preferring one because it is ‘the way’ won’t get you far. Picking it because it is the most efficient way to solve a problem is usually the better approach.

I must admit, I did never read a book. I did read specifications and datasheets, but never a ‘howto’ book or such. Not even when I started figuring out how assembly programming works on my old C64 so many years ago.

Curiosity, imagination and knowledge of facts are the base for successful embedded programming. And experience comes with time.

You got the facts, and I think you showed the curiosity. Now if you have the imagination, you don’t need books. If you don’t have it, the books won’t help. Talk with others about your idea, and use the feedback to gain experience.

Jens-Michael Gross said:

You got the facts, and I think you showed the curiosity. Now if you have the imagination, you don’t need books.

I doubt that rediscovering of everything through trial and error approach is productive way of getting knowledge as such.

Jens-Michael Gross said:

Example: You know how to blink an LED. So you know how to blink 8 LEDs

Well if we look at the problem of "need books" this way then yes - perhaps you don't need to look for book in this case :D

However if you learned how to light LED and now you are going to make much more complex embedded system having peripheral drivers and so on, you better read some book first - at least to get the idea/knowledge, not necessarily solution.

One book that I have found extremely helpful over the past 20 years has been "Engineering Problem Solving wtih C" by Delores M. Etter. It has had several editions...

An architecture that allow for multitasking is the way to go, while it still do deep-sleep in between.

Set up aclk/8 32K crystal, Set up a timerA to run at /4 aclk,
(you could flip the /8 and /4 if needed)

You now get a timer that ticks away close to 1mS and have max range of 64 seconds.
so you can now get pause & intervals that  range from 1ms to 1minute.

You get 3+1 overflow independent counters, you could use the over-flow for a 64second RTC.
Now make each part of code-flow a "stage", each stage normally goes to the next stage after the timerA pause tells it so.
Use Switch/case for a jump table for each stage.
You can go to a new stage due to a test etc, right away or when timerA initiate next stage.
Each stage can add a different CCRx value, if they should not have same mS length between them.

Use IRQ for everything, newer use while() as your code has to be like a state-machine.

When the pause had to be 50uS as it's so small it was not worth setting that as a separate stage, I did do a delay()

Ilmars said:

I doubt that rediscovering of everything through trial and error approach is productive way of getting knowledge as such.

Not rediscovering. If it is about trying more complex examples, well, the TI website is full of example code that can be looked at.

However, no child ever learned how to walk by reading a book.
Or, a more ‘educated’ example: one of my teachers lost one of his legs during WW2. He told me (and I for sure believe him) that after his leg has been removed, he perfectly knew by looking at it (or rather at where it once was) and listening to the doctors, that he has only one leg left. But the first time he tried to fasten the shoestring on his remaining foot, he fell down. As if he never knew before that he has no second leg to stand on while doing so.
After reading books, you might be better in explaining your mistakes after you did them, but you will do them with or without books.

And designing drivers (where at least some documentation is required) is way behind the ‘what books to read next’ point.

Finally, by repeating what others have written, there will be no innovation. Some kickstarting with the basics is helpful, but beyond that point, reading books won’t take you further than anyone else has already been. And maybe prevent you from taking a new direction that might have lead to some breakthrough.

Jens-Michael Gross said:

reading books won’t take you further than anyone else has already been

Engineering is not an art. Even artist who received knowledge from books or master, have more chances to be successful compared to one that uses "1000000 monkeys approach".

We talk about discrete electronics/computing systems which are built to be used certain way. When you know rules- then you can try to bend them, not opposite.

Ilmars said:

Engineering is not an art.

Quite the opposite, engineering is an art.

Hi Kuba Raczkowski,

Very good question. Thanks for opening a very good chance to discuss about a wonderful topic.

If still you're trying to get into some real applications of MCUs, a small suggestion:

Just look around within your house, note down what electrical equipments you find. Fan, light, water pump, etc.,

Try to control some of them by some sort of automated logic. By detecting the motions, with lux level of sunlight, etc.,

I would recommend a simple application here:

Try to make a dimmer for your room-light (don't try with fluorescent, try with incandescent lights), which should always maintain a constant lux level throughout the day (It's a real-time application used in intelligent lighting control system as a part of energy saving system). Remember, there could be sunlight coming to your room through the glass windows and it can vary throughout the day. You should still be able to maintain the lux level.

So you will require a light level sensor, a dimmer and an interface to connect these two (Here that interface is the MCU). Try to make leading-edge dimmer with an acceptable input of 0~10VDC (It's an industrial standard). Here, 0V=>0%, 1V=>10%, ... 10V=>100%. You may observe that the dimmer unit (normally made with triac) will become very hot after sometime. It has to shut down if it goes beyond a threshold (eg:- 85*C.). So you should use a temp sensor to sense it and it should be forwarded to MCU.Also try to use a fan with adjustable speed with respect to the changes in the temperature sensor as to keep the dimmer "cool".

Just continue this way to create a real-time application. It's such a simple thing to see, but requires a lot of work with the MCU. Don't try to copy paste any code from already existing project, even if you find anything.

If you try to make your own application to perform this, I'm pretty sure you've started to understand how to link your experience with MCU with the real-time world. And the beauty is that, you'll gradually be able to sort your codes in an organized way, since you're doing it in different stages. It includes many different peripherals and different procedures(what we call drivers) to control it.

I've used a lot of different things here, for which I've not given any details, expecting that you would spend time to explore it.

Please let me know if this is of any help to you

Regards,

Binoy Raphael.

Thank you for all the answers, however controversial they might be :)

Being an analog designer myself I can't really decide whether I am also an artist or not. 

I do understand the idea of going from small projects to bigger ones, that's the general idea of learning of course. However, in the world filled with ARM and its high level libraries (instead of assembler + 8051) you are often facing API-level troubles - without proper understanding of how to organize software it gets a mess. I like MSP430 because it is still rather low level - let's you learn about the actual hardware, controlling it, etc. 

I wonder if it was not a bit easier (please, just a speculation) for people who started with these things in the eighties. You got a simple processor with an assembler - had to figure out every little piece of it to get it running. Then came nineties, more options, only then ARM and the pretty huge microcontrollers, etc. Wasn't it flowing a bit more hm.. organically? You got a C64 to program because there was not much else. Now we're offered all kinds of toys with all the "it's just one click!" marketing. Making a decision on which platform to start is already a mess :/

Either way... I just finished the book proposed in the second post, it is quite what I was looking for, though I would like more ;) The idea of the book is - don't reinvent the wheel, do learn what people are already using for years and start building on that. That was also the purpose of the original post. We don't all need to invent new ways of doing (circular) buffers, a nice way to organize logging or how to deal with this or that peripherial, do we ? 

 Thanks for suggestions for projects, indeed a POV bicycle display is one of my favourites ideas ever :)

I agree that those of us who were forced to learn things from bottom up at the good old times of C64, have it easier just because we once got used to it.
Today, things are modular. Nobody knows how to repair something – a whole module or even the whole device is simply replaced and thrown away. Nobody knows how to locate a problem and fix it. The old TV at my parents’ home was replaced two years ago after 25 years of duty. It has been repaired two or three times. The new TV already died and was not repaired but rather replaced. I fear if the existing factories break down in a few years, nobody will be able to rebuild them because they are all so ‘high-level’ specialists that nobody is there who still knows the basics.

Programs written for the C64 did run. When released, few of them did have bugs. Games did work out-of-the-box. Today, most games can only be played after the third or fourth update, if at all. Point-and-click-IDEs like VisualX (replace ‘x’ by C, C#, basic, whatever) make every child feel like a big software engineer, but so many programs I’ve seen from this source are full of bugs and quirks – and are uninspired, ineffective and barely doing the job. Sure, things are more complex, which increases the likelihood of problems, but often even the simples functions do not work as described. As long as the UI looks colorful, makes nice sound and has some animations, who cares whether it is usable. Same for the firmware of consumer devices and almost everything else.
The MSP is a good chance to really get into it and make things from scratch. And make them right.

 You’re right that there is no need to re-invent the wheel. But simply using a wheel from a library without knowing how and why it works, makes you using the wrong wheel for your purpose. Having it done yourself once, allows you to use existing (and often, but not necessarily) more refined solutions more effectively. As one has expressed it some time ago: “if you know your Shakespeare, you’ll always have an answer for every situation in your life”

 BTW: if you look at Adafruit.com, you’ll find a POV device for bicycles. However, it is single-color, and not MSP-driven. :)

Dear Jens-Micheal,

I am relieved to see you did not misunderstood my point about "it was easier back then". Of course it is much easier now since everything is available, but it is more difficult because things got too high level! It's a bit like comparing a VW Golf Mk1 with Mk7 - of course the new one is nicer, easier to drive, more comfortable - but to know how it works you need a set of engineers with laptops...

In the last part of your message you got quite close to what I am looking for - a book that tells you: these are the wheels, they work like this and this and this, try it out yourself and know it for ever. Precisely so that you don't use a wheel from a "magic library", but without reinventing it. The Shakespeare of MCUs! :) I'll continue looking.

Actually the book I mentioned earlier has a tip you will like - take old datasheets, old books from the 80s - they are "simpler" and much more thorough, because there were no "magic libraries". A digression, but it reminds me when a 1965 General Radio slotted line on a forgotten shelve at university (a picture: picture). The manuals for this were a piece of art! They covered every little aspect of operating the thing, all theory, examples, there were even nomograms to help you calculate. Piece of art that never comes back I'm afraid.

Kuba Raczkowski said:

a book that tells you: these are the wheels, they work like this and this and this, try it out yourself and know it for ever.

This is exactly the type of book I’m currently writing. (Well, I didn’t make any progress for about a year now, too many other things to do) A guide to the MSP, its features and how they work on low level (and work together). Three chapters done, ~97 to go. :(

 I can remember the German manual for GEOS 2.0 (a preemptive OS that was competing with Windoze 3 and lost due to really bad marketing decisions). The manual part for the spreadsheet did explain even the financial functions and why you should use them. The online help of the current Excel versions is no match (after reading it, you are often dumber than before)

Oh, a book like that and from you would be my next purchase! Do keep on writing!

I will - if I find the time along all the forum work. But please, don’t wait with your next book purchase until I’m done. You could end up being bored to death due to lack of entertainment :)