IAR C - how to declare binary numbers

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

in AVR assembly we are declare binary numbers like this:
.equ BinaryNumber = 0b10101010

How can I declare binary numbers in IAR C?

#define BinaryNumber ???????

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

Did you think of trying it the same way as in assembler?

(don't use IAR C, but GCC understands 0b10101010 just fine...

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

Zarkadoulas wrote:
How can I declare binary numbers in IAR C?
Most people use hexadecimal for binary numbers in C. (GCC and some other compilers have an non-standard 0b####### extension.

If you some reason you are averse to hexadecimal, you could create (with a very simple program) a definition file with contents like:

#define B00000000 0x00
#define B00000001 0x01
...
#define B11111111 0xFF

Alternately, you could use a macro to assemble a binary number at compil-time.

#define MAKE_BINARY(a,b,c,d,e,f,g,h) (((a)<<7)|(b)<<6)|((c)<<5)|((d)<4)|((e)<<3|((f)<<2)|((g<<1)|h)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You only need to remember 16 things:

0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8
1001 = 9
1010 = A
1011 = B
1100 = C
1101 = D
1110 = E
1111 = F

then you know hexdecimal and you can use 0xNN in C

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

I use binary declaration declaring IO portbits but I think is better to get used with hexadecimal declaration.

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

Better yet is to used named IO bits:

DDRB = (1<<PD4) | (1<<PD1);

(for example)

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

I will try it.

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

Levenkay wrote:
Did you think of trying it the same way as in assembler?

(don't use IAR C, but GCC understands 0b10101010 just fine...

Binary notation is not part of the C standard, and as such, most C compilers don't support it. it is a nice addition to GCC, and hopefully other compiler vendors will follow suit, or better yet, being included in the next revolution of the standard.

Using named bits is the best way, as it is somewhat clearer as to the function of each bit. Though it is more cumbersome to write.

Alternatively one could use a macro to do it, or a series of defines

option 1: (named bits)

PORTD = (1<<PD7) | (1<<PD3);

option 2: (single macro)

#define bin(a,b,c,d,e,f,g,h) \ 
(a<<7)|(b<<6)|(c<<5)|(d<<4)| \
(e<<3)|(f<<2)|(g<<1)|(h<<0)



PORTD = bin(1,0,0,0,1,0,0,0);

option 3: (multiple defines)

#define b00000000 0x00
#define b00000001 0x01
.
.
.
#define b10001000 0x88
.
.
.
#define b11111111 0xff



PORTD = b10001000;

All 3 versions will compile to the exact same code.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

glitch wrote:
Using named bits is the best way, as it is somewhat clearer as to the function of each bit. Though it is more cumbersome to write.

Alternatively one could use a macro to do it, or a series of defines

option 1: (named bits)

PORTD = (1<<PD7) | (1<<PD3);

I've got to go with the named bits idea as the best. I would go a step further and say that you should define your registers and bit as something meaningful to the program:

#define LED_PORT PORTD
#define LED1 3 //This is the pin number (PD3)
#define LED2 7 //This is the pin number (PD7)

LED_PORT = (1<<LED1) | (1<<LED2); //Turn both LEDs on

This way you will have a very easy time if you need to change the pin/port you use because it makes physical layout of a board easier.

Plus I think it's more readable, especially if you do a good job with comments in the #define commands.

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

barney_1 wrote:

I've got to go with the named bits idea as the best. I would go a step further and say that you should define your registers and bit as something meaningful to the program:

#define LED_PORT PORTD
#define LED1 3 //This is the pin number (PD3)
#define LED2 7 //This is the pin number (PD7)

LED_PORT = (1<<LED1) | (1<<LED2); //Turn both LEDs on

This way you will have a very easy time if you need to change the pin/port you use because it makes physical layout of a board easier.

Plus I think it's more readable, especially if you do a good job with comments in the #define commands.

I absolutely agree, and that is how I do it. I just used existing names for the example. the names used should be context specific in order to make the most sense, resulting in self-documenting code.

Though I use the existing names, instead of numbers.

#define LED_PORT PORTD
#define LED1 PD3 //This is the pin number (PD3)
#define LED2 PD7 //This is the pin number (PD7)

LED_PORT = (1<<LED1) | (1<<LED2); //Turn both LEDs on

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

5 years too late spartan :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I also find the named bits is the best approach.

It's relative easily readable and the other advantage is that (to my knowledge) it's the most common way to set a bit.
So if you are using this .. it will easier to read others code.

#define LED_PORT PORTD
#define LED1 PD3 //This is the pin number (PD3)
#define LED2 PD7 //This is the pin number (PD7)

LED_PORT = (1<<LED1) | (1<<LED2); //Turn both LEDs on 

Okey I admit I'm a bit lazy now ....

How do you professionals do when you have the same "type" of inputs/outputs over several ports.

#define LED_PORT PORTD
#define LED1 PB3 //This is the pin number (PB3)
#define LED2 PD7 //This is the pin number (PD7)

In this case you have to remember what LEDx goes to what port ..

#define LED_PORT PORTD
#define LED1 PB3 //This is the pin number (PB3)
#define LED2 PD7 //This is the pin number (PD7)

LED_PORT |= (1<<LED2); //Turn one LED on 
PORTB |= (1<<LED1); //Turn the other LED on 

What I want to say it's that is easier to read LED_PORT instead of PORTB... when you are tired you could easily read PORTB when it's actually written PORTD when you are scrolling throw your code scratching you head .. why doesn't that led get lit.

It wouldn't get any clearer if you are naming both of the ports ..

#define LED_PORT1 PORTD
#define LED_PORT2 PORTB
#define LED1 PB3 //This is the pin number (PB3)
#define LED2 PD7 //This is the pin number (PD7)

LED_PORT1 |= (1<<LED2); //Turn one LED on 
LED_PORT2 |= (1<<LED1); //Turn the other LED on 

When you come back after some weeks .. you are asking your self what is LED_PORT1 and LED_PORT2 ? Also it's easily to read 1 instead of 2 and vice verse.

In wiring you have the pins naming from 1...xx. So you don't have to remember what port the pin belongs to.

Is there a way to make the define statement to decide which PORT it will use based on your naming for the pin.(hmm nobody gonna understand that).

So if someone understand what I mean please share your solution..
(I have certen been answered several times before on other treads but i think it would be good to be repeated in this thread)

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

Quote:

So if someone understand what I mean please share your solution..

Read the Bit Manipulation 101 thread in Tutorial Forum. On about page 5 you will find an attachment of sbit.h from "danni". Use that and you can just:

#include "sbit.h"
#define LED1 PORT_B3
#define LED2 PORT_D7

Then later turn on/off the LEDs with:

LED1 = 1;
LED2 = 0;

In fact you could go further and:

#define OFF 0
#define ON 1

then:

LED1 = ON;
LED2 = OFF;

No need for any (1<<n) nonsense with this solution.