Electronics > Beginners

Microcontroller programming tutorial

<< < (3/3)

rstofer:

--- Quote from: Rdx on January 12, 2020, 05:00:27 pm ---/Edit
As for that volatile junk, I have no clue why that is.

--- End quote ---

Fair enough! 

Volatile comes up from time to time and the code won't run without it.  Here's the issue:  You will note that 'junk' isn't returned by the function nor does it appear on the right-hand-side of an expression later on.  In other words, it is never used.  The friendly C compiler realizes this and optimizes the entire statement away (twice).  As a result, the registers are never read and the hardware flags never cleared.

By declaring the variable 'volatile', we're telling the compiler to quit thinking and do what it is told; all in support of a hardware design factor.

FWIW, variables shared with interrupt routines must also be declared volatile so that the compiler knows that the value can change at any time.  This comes up in code loops where the value is used over and over but could change between iterations if an interrupt were involved.  If you set a flag in an interrupt routine and test it in mainline code, it must be declared volatile.  Just something to remember.

This is an example of C code which is very likely unique to embedded programming.  In a more general purpose program the issue is unlikely to occur so it isn't talked about very much.

There's C and then there's C.  Note that C, as a language, has the facilities for dealing with these kinds of things.  That's why most, if not all, low level code is written in C.

Rdx:
Yes, that makes a lot of sense!
I guess C is from a time when programming on a PC also still meant to stick close to the hardware. (Which I am not exactly used to in php or javascript, both being interpreted)

Those small details are one reason for my question in here: Does it make sense to dive deep into a "regular" C course that will most likely focus more on PC operating system dependent calls and not really at those microcontroller specific stuff?

rstofer:

--- Quote from: Rdx on January 12, 2020, 05:59:17 pm ---Yes, that makes a lot of sense!
I guess C is from a time when programming on a PC also still meant to stick close to the hardware. (Which I am not exactly used to in php or javascript, both being interpreted)

Those small details are one reason for my question in here: Does it make sense to dive deep into a "regular" C course that will most likely focus more on PC operating system dependent calls and not really at those microcontroller specific stuff?

--- End quote ---

Yes it does!  All of those -> operators are pointing to a field in a structure defined in a header somewhere.  A lot of the code dealing with hardware registers will be dealing with structs and typedefs.  These don't tend to come up as often in general purpose programming but they're all over the place in embedded programming.

The thing is, these constructs aren't unique to embedded and can be explored at the PC level as well.  You would usually see a struct used as a Pascal 'record'.  The various fields within an 'employee' record would be reached using the -> operators.  As well, it is likely that you won't deal with a struct directly but rather as a struct reached by a pointer.  A linked list of structs would actually be a linked list of pointers to structs allocated with 'malloc()' when the item is added.  This is exactly the same in C++ using new().

I tend to avoid dynamic allocation in embedded code because I worry about the collision when the heap, growing upward in memory, collides with the stack growing downward.  To this end, I avoid string.h at every opportunity.  printf() also uses the string library so I avoid that as well.  If I see sbrk() as undefined, or worse, defined, in a linker map, I get very nervous.  sbrk() is the code that does the actual allocation.  This is often left as a function for the writer to create based on how they want to implement dynamic allocation and there will be a linker error if it isn't defined.  OTOH, if it is defined in some library somewhere, it is probably incorrect for your environment so even when defined, there is still a problem.

Where C gets unique to embedded is at the point where you need to dig out a datasheet.

rstofer:
If we consider 1981 as the introduction of the PC then C, introduced in 1972, is a lot older.  It was used on minicomputers and mainframes long before it came to the PC universe.  In fact, it was probably running on my Altair 8800 in the late '70s.  I don't recall the exact date or the variant.

FORTRAN and COBOL are even older.  FORTRAN was introduced in 1957 and COBOL was introduced in 1959.  Both are still in use.  It is said that every ATM transaction, at one point or another, is dealt with in COBOL.  Banks are actually hurting for COBOL programmers because the universities don't teach it and the oldtimers are dying off.  FORTRAN (now Fortran) is still in common use in the scientific community.  I still use it for various math demos and I've been using it since 1970.

Fun fact, the language PL/M, created for Intel and their new 8080 uCs was written in Fortran.

tggzzz:

--- Quote from: rstofer on January 12, 2020, 05:41:41 pm ---This is an example of C code which is very likely unique to embedded programming.  In a more general purpose program the issue is unlikely to occur so it isn't talked about very much.

There's C and then there's C.  Note that C, as a language, has the facilities for dealing with these kinds of things.  That's why most, if not all, low level code is written in C.

--- End quote ---

As an example of how many people incorrectly think they understand C, consider that as late as 2004 it was beneficial for this paper to be written "Threads cannot be implemented as a library", Boehm. http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf Evan a decade later many people didn't understand!

I believe the latest standards do finally (i.e. after 40 tears!) provide the necessary guarantees, but you have to be allowed to use them and I'll bet many compilers don't avoid "unpleasant surprises" in the generated code.

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod