C Programming: pointers

[Ian Rogers]

Of course I don't mind.... The only thing I don't want to see is mud slinging... If everyone is happy with the thread.. ( Of which The OP is probably happy his original question has been answered ).


Lets continue..

 

[killivolt]

Of course I don't mind.... The only thing I don't want to see is mud slinging... If everyone is happy with the thread.. ( Of which The OP is probably happy his original question has been answered ).


Lets continue..

Is there anyway we can go back and clean up the "Thread" remove non-relavant posts? I just think it would be cleaner.

 

[Ian Rogers]

Some of the threads that appear "Off topic" still have quotes to others that are on topic... I was looking to clean it up but I don't want to disrupt the flow...

I'll keep it as is for the time being!!

As far as C is concerned, I like C. Not because its any better than any other language, but because I've grown with it.. I still use ASM to code parts that don't warrant using C, so I'll use it even for the small Projects and the big projects alike.

One thing we should concern ourselves with when using C on micro's is how to declare variables... This is a subject that does need a debate!!! All the members learning, or indeed, have learn't C need to know the pitfalls of pointers and different qualifiers that need to be in place...

 

[misterT]

One thing we should concern ourselves with when using C on micro's is how to declare variables... This is a subject that does need a debate!!! All the members learning, or indeed, have learn't C need to know the pitfalls of pointers and different qualifiers that need to be in place...

I agree 100%. There are no good books for this.. or even good websites.

I suggested adding a programming section, or something where we could collect articles about programming. https://www.electro-tech-online.com/threads/adding-programming-section.134408/

Then you (Ian) suggested that a good place to start is to write articles in the "code repository". So, I wrote couple of articles, but didn't get much feedback and nobody else didn't write anything.. so I haven't written any beginner stuff since. I'm not an excellent writer, especially for beginners. Also one problem is that beginners do not find these articles. I don't think many even uses the forum search before posting.

This is the article I wrote for beginners: https://www.electro-tech-online.com/threads/variables-101-char.134416/

EDIT: I see that the article has quite many views.. maybe people do find it. I just don't know if the article is useful or not.

 

[Ian Rogers]

EDIT: I see that the article has quite many views.. maybe people do find it. I just don't know if the article is useful or not.

All your code is good! I also browse through them.. It's good to see how others program..

I was testing some code at the weekend... Didn't go well, if fact!! If I didn't use ISIS it would have been a struggle to find the issue..

All variables in C have "Qualifiers".... There are several to look into..

Auto... This is the norm if a qualifier isn't specified then assume auto.
Static.. This is for maintaining variable scope outside of the function / module it was declared.
Volatile.. This is the one you need to learn about, can save major heartache..
Const.. Also know as "code" or "rom", This specifies data that does not change..
Register.. This is to speed up looping structures.

These are a few of the ones I regularly use...
All compilers use "Optimization" at one level or another, using the correct qualifier determines what will be compiled and how..

 

[nsaspook]

Some of the older articles from "Embedded Systems Programming" might be useful in the programming section.

Efficient C Code for 8-bit Microcontrollers
https://www.barrgroup.com/Embedded-Systems/How-To/Efficient-C-Code

 

[nsaspook]

Const.. Also know as "code" or "rom", This specifies data that does not change..

This really means 'read-only' as you can have a 'const' read-only hardware status register with changing bits. The embedded world has lumped the 'code', 'rom' modifiers on to the original meaning in some compilers to specify the type of memory used.

Per my previous link:

C's const keyword
The keyword const, which is by the way the most badly named keyword in the C language, does not mean "constant"! Rather, it means "read only". In embedded systems, there is a huge difference, which will become clear.

 

[misterT]

I found this from one of my books. I thought it is funny because last night we were talking about heap memory:

"The manual type involves malloc and free, and is where most of your segfaults
happen. This memory model is why Jesus weeps when he has to code in C. Also,
this is the only type of memory where arrays can be resized after declaration."
- From book: 21st Century C

 

[NorthGuy]

I've just figured out that I was indeed ignorant of where I am and didn't see that this is a forum section for specific processors. I came to this post through the "New Posts" link, and I thought this was a general discussion not attached to any particular architecture. So, I need to withdraw most of my argument. Using Assembler on 8-bit processor would require a lot of tedious coding job which would overweight all the benefits. I had 16-bit PICs in mind, and this make Assembler programming much easier, and it would be easier still with 32-bit processor. I apologize for the confusion.

I'll still post the example of structured programming for 16-bit PICs tonight.

BTW: How come there's no forum section for PICs?

 

[misterT]

BTW: How come there's no forum section for PICs?

The "root" of microcontroller-forum is kind of assumed to be for PICs and general questions (I think). And then there are sub-forums for other architectures.

When we talked yesterday, I assumed any microcontroller in general. It does not matter if it is 8, 16 or 32 bit microcontroller.

 

[3v0]

Structured code starts with technique. If you understand what structuring is you can write structured code in most languages. Structured code in asm should not be a problem.

The same applies to OOP.

But it is sure a lot nice writing structured code and OOP in languages properly designed to use them.

 

[misterT]

But it is sure a lot nice writing structured code and OOP in languages properly designed to use them.

Cant resist showing an example of a good C module, which is kind of OOP (looks like it at least). (it is completely possible to code OOP with C, but lets not go that far).

Header file:

/* example.h */
/* This is a silly module that has two functions and one private variable.*/
/* Calculate two integers together and return the result (a+b)*/
int sum(int a, int b);
/* Return the last result that was calculated */
int last_sum();

Implementation (.c-file)

#include "example.h"
/* Variables global to this module only a.k.a. private variables */
static int previous_sum; // declaring this static makes it impossible to access outside this file.

/* Calculate two integers together and return the result */
int sum(int a, int b){
    previous_sum = a+b; // save the sum in our modules private variable
    return previous_sum;
}
/* Return the last result that was calculated */
int last_sum(){
     return previous_sum;
}

Now the variable "previous_sum" can not be accessed from any other code outside the module. Not even using the "extern" keyword.

Well.. it is not a class quite yet, because you can't instantiate many copies of them.

 

[Ian Rogers]

I was given ( some time back ) a piece of code on x86 assembler (MASM) implementing OOP... The author gave the reasons as... C++ is compiled "eventually" to assembler... So you must be able to do the same structured programming as C++ in assembler... Yes or no?

The Pic 32 still only comes with a relatively small amount of RAM.

 

[Ian Rogers]

This really means 'read-only' as you can have a 'const' read-only hardware status register with changing bits. The embedded world has lumped the 'code', 'rom' modifiers on to the original meaning in some compilers to specify the type of memory used.

Notice my careful wording... Data that doesn't change...

 

[misterT]

Notice my careful wording... Data that doesn't change...

I think you can take the address of a const variable and the change the value of the content.

const int i = 20;
int *x;
x = (int*)&i;
*x = 10;
// Now the i has value 10. No compiler errors, or even warnings.

I have a a book that dedicates 6 pages for the const keyword only.

 

[3v0]

A const is an interesting thing. I would like to see the six pages. If you please what is the title and author or ISBN?

Isn't C++ itself is verification that you can write OOP in c.

 

[misterT]

Isn't C++ itself is verification that you can write OOP in c.

Yes, you can say that I think. OOP is a programming technique (or pattern), not a language feature itself.

This is the book.
https://shop.oreilly.com/product/0636920025108.do

 

[nsaspook]

I wanted to be clear that the 'const' qualifier is used by the compiler IMO as a 'type checking/access' token. The source program can't *directly* modify the value at that const identifier at compile time and will generate (maybe better) code with that qualifier added but provides no run-time protection to the value of that identifier. You can modify it indirectly but what will happen will be undefined in the C language and is a implementation detail of that system.

 

[NorthGuy]

Here's the example of an organized Assembler program that I promised. I'll try to explain how things are organized.

I do not use linker to assemble modules. Rather I use include files (let's call them units). This way, most things get resolved during compile time.

Before units get included, I define different variables, which then get used by units to shape the code. For example, in this program, the first four variables get defined to alter behaviour of the init unit. POWERSAVE tells it that PIC should go to slip/idle when it's nothing to do. Without it, it would do simply loop through NOP commands. CLOCKSOURCE tells that there's a watch crystal on SOSCI/SOSCO pins and it is to be used to generate regular interrupts. TUNE_8MHZ tells it to use built-in RC oscillator to clock the processor, and PLL=2 tells it to run it 2 times faster than the oscillator. Frequency will be 16MHz or 8 MIPS, but it is sure irrelevant for this particular program.

Next 4 definition are for the display unit and they tell where the LCD lines are connected.

Then, units get included.

p24HInit.inc plays the same role as libc for C, with much less capabilities, of course. It does a lot of stuff - sets the clock for the CPU, defines TCY to the duration of single instruction in ns, sets up timer interrupts to create periodically-called functions. It also defines some system macros, such as alloc_dma to fetch the next available DMA module number, alloc_flag to create a bit flag and lots of other small stuff. It maintains time in a varible called sec_count. It also defines the code sections used later.

NHD0420DZW.inc is an LCD unit. It works with one particular kind of LCD. If I get a different one, I will simply replace this with a different unit. It uses the definitions of LCD pin connections from above to create functions to control LCD. It also uses TCY definition from the init unit to set the speed at wich PIC is going to talk to the LCD.

strings.inc is not used in this program, but it is required for RTCC.inc. It has macros such as strcpy or memcpy.

RTCC.inc is a real-time clock, which uses sec_count from the init unit to display time. It needs two things to work properly - offset between sec_count and real time and time zone shift. These are not set here, so the time displayed will be bogus.

Then we see .val section, which is allocated in program memory to represent constants, such as "Hello, World!" here.

The .nbss section hosts all data. Here it only contains a buffer for string manipulations.

The .text section contains code. __Init is called from within the init unit once all the PIC initialization is done. Here it initializes display and rtc units and then clears the "no sleep" flag which tells that it is ok to completely shut down CPU clock when there's nothing to do. Then it puts the "Hello, World!" on LCD.

__Loop is also called from the init unit. It is a "lazy loop" which is called approximately once a second. Since nothing going on in this particular program, it will be called exactly every second, but if CPU was busy this could be delayed. I could also use fast lazy loop, which would be called every time CPU wants to go idle.

The code in __Loop loads local time into the rtc buffer, then parses it into days, hours etc., then converts these things into a text string and puts it on the third line of the LCD. Sine __Loop is called every second, you get a running clock on the third line of LCD while the first line will still hold the "Hello, World!" phrase.

Note that all the functions from the display unit are prefixed with display_, and all the functions from the rtc unit are preficed with rtc_. This is an important aspect of program organization.

Of course, Assembler programs can be organized in a number of ways. This is just one of them.

  .include "p24HJ64GP502.inc"

  .equ POWERSAVE, 1
  .equ CLOCKSOURCE, 1
  .equ PLL, 2
  .equ TUNE_8MHZ, 1
 
  .equ DISPLAY_PORT, PORTB
  .equ DISPLAY_SCL, 11
  .equ DISPLAY_CS, 13
  .equ DISPLAY_SDO, 12

  .include "p24HInit.inc"
  .include "NHD0420DZW.inc"
  .include "strings.inc"
  .include "RTCC.inc"

;----------------------------------------
  .section .val

hello:
  .asciz "   Hello, World!"

  .section .nbss

buffer:
  .space 16

;----------------------------------------
  .text

__init:

  rcall display_init
  rcall rtc_init

  flag clr, #FLAG_NOSLEEP

  mov #psvoffset(hello), w0
  call display_write_text

  return

;----------------------------------------
__loop:

  rcall rtc_load_official
  rcall rtc_parse

  mov #3, w0
  clr w1
  rcall display_go_to

  mov #buffer, w0
  rcall rtc_datestring

  mov #buffer, w0
  rcall display_write_text

  mov #buffer, w0
  mov ' ',w1
  mov.b w1,[w0++]
  rcall rtc_timestring

  mov #buffer, w0
  rcall display_write_text
 
  return

.end

 

[3v0]

One of the major things structured code did was to do a way with spaghetti code. Using jumps or GOTOs rather then calls or GOSUBs. Also important and more tedious to implement in ASM is the structured decision making constructs. If..then..else, while..do, do..until, for.

These things are all doable in asm. If you think about it doesn't a structured language compiler produce structured ASM code or machine if it does not do the translation to ASM.