Passing Macros to other c files with no extra files

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm used to make a c file for things i use a lot in my code like a c file for timer0  , adc etc

Now to the main subject

when trying to make a c file to deal with the 8 bit shift register 74HC595 (I'm using two linked together ) i had some problems 

here is my main code (most of it) : 


#define F_CPU 8000000UL
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>

#include "AVR_Hc595.c"



// note : ds , sh , st are pins from the hc595 ic
// 595 Micros !!!!!!!!!!!!!!!!
#define Ds_Port PORTB
#define sh_Port PORTB
#define st_Port PORTB

#define Ds_pin PB2
#define sh_pin PB3 
#define st_pin PB4

int main(void)
{
    //Basic IO init stuff here  
    
 	Shift595(0,255);
	Latch;
	_delay_ms(100);   
}

my "AVR_Hc595.c" :

#define Ds_pin_H Ds_Port|= (1<<Ds_pin);
#define Ds_pin_L Ds_Port&=~ (1<<Ds_pin);// I'm using the macros that i defined in main.c

#define sh_pin_H sh_Port|= (1<<sh_pin);
#define sh_pin_L sh_Port&=~ (1<<sh_pin);

#define st_pin_H st_Port|= (1<<st_pin);
#define st_pin_L st_Port&=~ (1<<st_pin);

#define Latch st_pin_H;st_pin_L;







void Shift595(unsigned char _shift_High_Byte,unsigned char _shift_Low_Byte)
{
	char i=8;
	while(i!=0)
	{
		if((_shift_High_Byte&128))Ds_pin_H
		else Ds_pin_L;
		
		sh_pin_H;
		sh_pin_L;
		_shift_High_Byte=_shift_High_Byte<<1;
		i--;
	}
	
	i=8;
	while(i!=0)
	{
		if((_shift_Low_Byte&128))Ds_pin_H
		else Ds_pin_L;
		
		sh_pin_H;
		sh_pin_L;
		_shift_Low_Byte=_shift_Low_Byte<<1;
		i--;
	}
}

 

i want  the pins and ports definition macros(from main.c) to be passed (shared) to the other c file but without adding other files if possible  (like header files and such) 

any idea ? 

Thanks a lot for your time

This topic has a solution.

A Beam of Light out of the War

Last Edited: Fri. Nov 29, 2019 - 03:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

AbDoO_ wrote:

#include "AVR_Hc595.c"

Don't include the .c file, instead make a header file .h that has your defines and function prototype and include that.

Then add the .c file to your project in your ide.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Why would you say you don't want to add header files? The whole point of .h files in C is for sharing info that 2 or more .c files need to know.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Just put the macros *before* the include.

/Jakob Selbing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

In your .h file, do not forget the "guard" statements. Foe example, in "AVR_HC595_PORTS.h", do

 

#ifndef AVR_HC595_PORTS
#define AVR_HC595_PORTS
// note : ds , sh , st are pins from the hc595 ic
// 595 Micros !!!!!!!!!!!!!!!!
#define Ds_Port PORTB
#define sh_Port PORTB
#define st_Port PORTB

#define Ds_pin PB2
#define sh_pin PB3
#define st_pin PB4

#endif

 

By #including "AVR_HC595_PORTS.h", every c file that needs these definitions have the definitions. That is the way C is designed to work! The "guards" prevent conflicts from possible multiple definitions.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Wed. Nov 27, 2019 - 10:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think OP's objection to header files is header files #included from his #included .c file.

 

@OP: The term for some of what  you have been told is "refactoring".

You have been told to factor AVR_Hc595.c into shared and unshared parts.

The shared part is a header file and therefore gets the .h suffix.

Since it is a header file, giving it another suffix would be counterproductive.

The only time you should #include a .c file is if you

are somehow constrained by external requirements.

The .c suffix should be reserved for C language files

that appear top-level inputs on the compile line.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First of all please excuse me for late reply , power shortage .

Thank you all for the great answers .

I have created the .h file and moved the macros to it and it worked perfectly fine .

But i will stick with 

jaksel wrote:
jaksel
Answer for the sake of simplicity .

 

jaksel wrote:

Just put the macros *before* the include.

 

that was exactly what i was searching for .

I appreciate your time everybody, thanks . 

 

A Beam of Light out of the War

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My Last Edit :

I Actually Combined the two solution (Adding a .h file to the project , defining the macros before including c files) in a very unprofessional way XD 

Now My code look like this (And it's working just fine ):

 

main.c


#define F_CPU 8000000UL
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>

//My Virtual .h File : 
  // {
	  
	  // AVR_Hc595
	  #define Ds_Port PORTB
	  #define sh_Port PORTB
	  #define st_Port PORTB

	  #define Ds_pin PB2
	  #define sh_pin PB3
	  #define st_pin PB4
	  
	  #define Latch st_pin_H;st_pin_L;

	  void Shift595(unsigned char _shift_High_Byte,unsigned char _shift_Low_Byte); 

	  // AVR_Usart
	  
	  #define Discard_Receiving_Finishing _upos=0;Finished_Receiving_Text=0;

	  void Usart_Init(unsigned long USART_BAUDRATE);
	  void Usart_Write(char Data2Write);
	  void Usart_Write_Text(char *text_);
	  unsigned char Usart_Read();

	  void int2str(unsigned int d, char* str);
	  void LtrimZeros(char* str);
	  
	  #define Receiver_Array_Length 10 
	  #define _Terminator_Character '/'
	  volatile char  _Receive_Array_[Receiver_Array_Length];
	  volatile unsigned char _upos=0;
	  volatile char Finished_Receiving_Text=0;
	

  // }
		  

// included C files :
#include "AVR_USART.c"
#include "AVR_Hc595.c"

int main(void)
{
	//Usart Init :
	Usart_Init(9600);

	UCSRB |= (1<<RXCIE) ;  // Set Receive complete interrupt enable bit  USART
	
	sei();
	// IO Init
    DDRB=0xff;
	PORTB|=3; _delay_ms(100);
	PORTB&=0; _delay_ms(100);
	
	//Hello word
	Usart_Write('#');
	Usart_Write('\r');
	Usart_Write_Text("AT8 Here !");
	Usart_Write(0x0d);

	Shift595(0,255);
	Latch;
	_delay_ms(100);

}

/* Here are the ISR(USART_RXC_vect){..} Function but i prefer not to post it */

 

 

 

 

My AVR_Hc595.c :


// Important :

// Add Those to your general .h file :
/****************************************
// AVR_Hc595
#define Ds_Port PORTB
#define sh_Port PORTB
#define st_Port PORTB

#define Ds_pin PB2
#define sh_pin PB3
#define st_pin PB4
	  
#define Latch st_pin_H;st_pin_L;

void Shift595(unsigned char _shift_High_Byte,unsigned char _shift_Low_Byte);

*******************************************/
#define Ds_pin_H Ds_Port|= (1<<Ds_pin);
#define Ds_pin_L Ds_Port&=~ (1<<Ds_pin);

#define sh_pin_H sh_Port|= (1<<sh_pin);
#define sh_pin_L sh_Port&=~ (1<<sh_pin);

#define st_pin_H st_Port|= (1<<st_pin);
#define st_pin_L st_Port&=~ (1<<st_pin);


void Shift595(unsigned char _shift_High_Byte,unsigned char _shift_Low_Byte)
{
	char i=8;
	while(i!=0)
	{
		if((_shift_High_Byte&128))Ds_pin_H
		else Ds_pin_L;
		
		sh_pin_H;
		sh_pin_L;
		_shift_High_Byte=_shift_High_Byte<<1;
		i--;
	}
	
	i=8;
	while(i!=0)
	{
		if((_shift_Low_Byte&128))Ds_pin_H
		else Ds_pin_L;
		
		sh_pin_H;
		sh_pin_L;
		_shift_Low_Byte=_shift_Low_Byte<<1;
		i--;
	}
}

and there is my AVR_USART.c  but i prefer not to post it (Because it is written for a specific project (not general ) ).

 

Just wanted to share it with you guys 

thanks.

A Beam of Light out of the War

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AbDoO_ wrote:

#include "AVR_USART.c"
#include "AVR_Hc595.c"

Nyet.

If they are suitable for #include-ing,

they should not have .c suffixes.

AVR_Hc595.c is NOT suitable for #include-ing.

It contains a complete non-static function.

It may not be #include-ed in more than one file per program.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
It contains a complete non-static function.

 

skeeve wrote:
It may not be #include-ed in more than one file per program.

the codes in AVR_Hc595.c are only used in my main.c  (and i don't think my project will go any further than that )

I don't see the problem , I can't completely get you (Sorry, Newbie) 

What errors including .c <s> in my main.c will cause now or in future   ?

thanks

A Beam of Light out of the War

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AbDoO_ wrote:
I don't see the problem
Because you aren't using the C compiler as the author's of C intended. You may want to get a copy of Kerninghan & Ritchie and learn how to program in C as designed.

 

Personally I don't understand your aversion to .h files. The idea is you split your program into multiple .c files to make things "modular" then you use .h files so one .c can know what another .c has to offer. Sometimes it makes sense to have TWO .h files per module - one that documents its "public" interface and one for it's private definitions. It is then even more obvious to the reader what the module is offering to other potential callers.

 

If you just try gluing everything into a single .c file then when you want to re-use this 595 supporting stuff in another project you are going to end up doing a lot of copy/pasting (which could get real complicated if some parts of the 595 code are within sections of the other code!). It you put all that is to do with 595 in a single avr595.c with an avr595.h to show what it offers then main.c (or any other .c) just has to #include the .h file and call the functions that are publically available to it.

 

When you later trade up to C++ then this splitting is more heavily policed and encouraged as you really do group everything involved in the support of a single item into a completely separate module (so separate that try as they might ,some parts of the code cannot "see" or access the "private:" bits of the support code).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

You may want to get a copy of Kerninghan & Ritchie and learn how to program in C as designed.

I will consider that

clawson wrote:

When you later

I totally understand,
I should say that everything i have done is only for simple projects.

Thanks for Early warning
I appreciate your time

A Beam of Light out of the War

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are four issues:

Will it work for the current case?

Will it work for obvious extensions?

Will it confuse other readers, possibly including yourself later?

Will it make K&R roll over in their graves?

 

You have failed on the middle two.

 

 

Edit: mispeling

Iluvatar is the better part of Valar.

Last Edited: Fri. Nov 29, 2019 - 06:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
Will it make K&R roll over in there graves?
Speak kindly of the "dead" and don't piss off a professor.

Brian Kernighan | Electronic Design | Electronic Design

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
skeeve wrote:
Will it make K&R roll over in there graves?
Speak kindly of the "dead" and don't piss off a professor.

Brian Kernighan | Electronic Design | Electronic Design

Oops.  I'd thought they were both still alive.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I really do not understand the aversion to a simple .h file that is #include'd where it is needed.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If Kernighan & Ritchie were alive today, they'd be spinning in their graves!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I guess sometimes you have to let people learn stuff the hard way... 

 

BTW I think you might find some use in this comment I wrote a while ago:  https://www.avrfreaks.net/comment/2649831#comment-2649831

 

"One trick I use quite often is to have the module include a "myModule_config.h" file. That file is not kept in the shared project. Instead it must be defined by the application in order to define the various details of that specific implementation (I/O pins, number of "things", external functions, etc). "

/Jakob Selbing