C vs PBP

[Archangel]

Hello Everyone,
I was looking at a C program from nuts & volts and it contained a lookup table, in it were bytes laid out like this 0b0000000, or 0b1100000 . . . and apparently these seem to be oposite of the PBP way of writing them, whereas 0b1100000 is equiv. to %00000011. Is this correct ?
Thank You
JS

[Archangel]

Ok I found my answer, it's about Big Endians and Little Endians, in other words C uses both according to who's C it is and some will use either! Which is to say some list binary MSB first and others list LSB first, what I would like to know now is how to tell them apart, I notice some list 0x00000000 and some list 0b00000000, does anyone know, is that how to identify them?

[Bruce]

For single byte data types, 0b11000000 should be the equiv. of %11000000 in PBP. As far
as "I" know, most C compilers will store byte values as entered. If would really get to be
confusing if you had LSB/MSB of single byte values swapped around in words, longs, unions,
etc.

Endianess normally comes into play when you're dealing with multi-byte data types like longs,
words, etc. Then you may, or may not, need to know how these are stored in data memory.

With PBP MyVar VAR WORD, MyVar =$AABB would be stored little-endian. I.E. if the address
of MyVar starts at 30h, then $BB will be stored at 30h followed by $AA at 31h. C18, HiTech,
and CCS compilers work the same. Some have a compile-time switch you can use to change
byte ordering to big-endian.

In C, when you start dealing with unions, you'll definitely want to know the ordering of bytes
in multi-byte values. The compiler manual should have all that neat stuff.

[Archangel]

Here is the code I was eyeballing, From Nuts and Volts Aug 2007, a water heater controller, display section,

////////////////// Display.c //// for PIC16F684 using MPLAB IDE 7.51
//       PICC Compiler with PICSTART Plus programmer
//       by Dick Aidt  7 Mar 07   //
//       Program displays the digits sent by the Thermal program
#include <pic.h>
#include <math.h>
__CONFIG(INTIO & WDTDIS & PWRTEN & MCLRDIS & UNPROTECT &\
UNPROTECT & BORDIS & IESODIS & FCMDIS);

const char LEDDigit[ ] = 
 { 0b0000001,                  //  "0"
    0b1001111,                  //  "1"
    0b0010010,                  //  "2"
    0b0000110,                  //  "3"
    0b1001100,                  //  "4"
    0b0100100,                  //  "5"
    0b0100000,                  //  "6"
    0b0001111,                  //  "7"
    0b0000000,                  //  "8"
    0b0001100,                  //  "9"
    0b0001000,                  //  "A"
    0b1100000,                  //  "B"
    0b0110001,                  //  "C"
    0b1000010,                  //  "D"
    0b0110000,                  //  "E"
    0b0111000  };              //  "F"

int  Value=0;
int Dig [ 4 ];
int i=0,t=0, x = 0, y = 0, z = 0;
int in = 0;	// built up inputed data Temp
int s = 0;	// recieved bit
const j[ ]={0,1,0,1};
const k[ ]={0,0,1,1};

main(void)
{
	CMCON0 = 7;			//  Turn off comparators
	ANSEL = 0;			//  disable  analog
	PORTA = 0b00001100;
	TRISA = 0b00001100;		//  RA2 & RA3 are inputs
	PORTC = 0;
	TRISC = 0b00000000;		//  PORTC is all outputs	
	
	


ADC:	if (!RA3) 
	{
		in = 0;
		for ( i = 0; i < 12; i ++)
		{ 	
			while ( ! RA3) //wait for HI sync pluse
				{NOP();}
			{ s = RA2; in = (in | ( s << i));} // get the bit
			while (RA3) //wait for LO sync pluse
				{NOP();}
		} // get next bit
		while ( ! RA3) // wait for HI sync pluse
		NOP();		
		Value = 0;				
		Value =  in;	// make display numbers array	
		if (Value < 1000)
			{	z = 1;
				Dig [ 0 ] = 0;
				goto JUMP1;
			}
		else z = 0;
			NOP();	
		Dig [ 0 ] = Value/1000;
JUMP1:	Dig [ 1 ] = Value / 100 - (Dig[0] * 10);
		Dig [ 2 ] = Value / 10- (( Dig[0] * 100 )+ ( Dig[1] * 10 ));
		Dig [ 3 ] = Value  - (( Dig[0] * 1000 )+ ( Dig[1] * 100 ) +( Dig[2]*10));
	}
	for (y=0; y < 4; y++) // Display the digits
	{	
		if ( y == 0 & z == 1 ) 
			 y = 1;// if F < 100 skip first digit	
		PORTC = LEDDigit [ Dig [ y ] ];
		RA5 = LEDDigit [ Dig [ y ] ] >> 6;
		RA0 = j [ y ];		//select which digit
		RA1 = k[ y ];
		if  (y == 2)
			RA4=0; // turn on decimal point
		else RA4=1;						
		NOP();
		for (t=0; t<327; t++);// display delay
		NOP();		
	} // end for
	PORTC = 0b11111111;
	RA5 = 1;
	goto ADC;
} // End

Notice the lookup table for the digits.

[Bruce]

It's tough to say what he's doing without a schematic. Do you have a link to one?

Definitely appears to be Hi-Tech C compiler.

[Archangel]

Hi Bruce, I emailed the link to the pdf to tech at rentron dot com. Thanks for looking.
I would have PM ed but . . .
JS

[Bruce]

Hi Joe,

Could you send me that link again? For some reason I didn't get the first one.

[Archangel]

I have done so. Thank You
EDIT:
I think I am beginning to see, he has switched up the segments to ports in reverse order and taken 2 of them to another port altogether. RC5 = B, RC4 = C, RC3 = D . . . so Why does the C language list binary in 2 different formats, I. E. 0x00000000, and 0b00000000 ?

[Bruce]

I couldn't download the schematic, but that does look like what he's doing by just looking
at the source code. This would be a lot easier with all 7-bits on a single port.

Why does the C language list binary in 2 different formats, I. E. 0x00000000, and 0b00000000 ?

It varies from one compiler to the other. C18, CCS and Hi-Tech use the 0b00000000 format.
0x is normally for HEX numbers. CCX5 uses 0b.0000.0000 format for binary.

[skimask]

I think this translates over to PBP. I could be completely wrong.

'config statements to be fixed up
leddigit var byte[15]:value var byte:dig var byte[4]:i var byte:t var byte
x var byte:y var byte:z var byte:in var byte:s var byte:j var byte[4]
k var byte[4]:j[1]=1:j[3]=1:k[2]=1:k[3]=1:for i=0 to 15
lookup i,[1,59,18,6,72,36,32,15,0,12,8,96,49,66,48,56],leddigit[i]:next i
main: cmcon0=7:ansel=0:porta=12:trisa=12:portc=0:trisc=0
ADC:
if porta.3 = 0 then
     in = 0:for i=0 to 12:while porta.3=0:wend:s=porta.2:in=in|(s<<i)
     while porta.3=1:wend:next i:while porta.3=0:wend:value=in:z=0
     if value < 1000 then z=1:dig[0]=0:goto jump1
     dig[0] = value / 1000
JUMP1: dig[1]=value dig 3:dig[2]=value dig 2:dig[3]=value dig 1:dig[4]=value dig 0
endif
for y = 0 to 4
     if y = 0 and z = 1 then
          y=1:portc=leddigit[dig(y)]:porta.5=leddigit[dig(y)]>>6:porta.0=j[y]
          ra1=k[y]:porta.4 = y.1:for t = 0 to 327 : next t
     endif
next y:portc=$ff:porta.5=1:goto adc
END

Oh...and it's been colonized!

[Archangel]

Thanks Bruce,
I did manage to remember how to make a copy of the schematic, you answered most of my question. I did visit 1 web site dedicated to C programming which stated that some C compilers could use both Endians styles, so that was some of my confusion.

[Archangel]

I think this translates over to PBP. I could be completely wrong.

'config statements to be fixed up
leddigit var byte[15]:value var byte:dig var byte[4]:i var byte:t var byte
x var byte:y var byte:z var byte:in var byte:s var byte:j var byte[4]
k var byte[4]:j[1]=1:j[3]=1:k[2]=1:k[3]=1:for i=0 to 15
lookup i,[1,59,18,6,72,36,32,15,0,12,8,96,49,66,48,56],leddigit[i]:next i
main: cmcon0=7:ansel=0:porta=12:trisa=12:portc=0:trisc=0
ADC:
if porta.3 = 0 then
     in = 0:for i=0 to 12:while porta.3=0:wend:s=porta.2:in=in|(s<<i)
     while porta.3=1:wend:next i:while porta.3=0:wend:value=in:z=0
     if value < 1000 then z=1:dig[0]=0:goto jump1
     dig[0] = value / 1000
JUMP1: dig[1]=value dig 3:dig[2]=value dig 2:dig[3]=value dig 1:dig[4]=value dig 0
endif
for y = 0 to 4
     if y = 0 and z = 1 then
          y=1:portc=leddigit[dig(y)]:porta.5=leddigit[dig(y)]>>6:porta.0=j[y]
          ra1=k[y]:porta.4 = y.1:for t = 0 to 327 : next t
     endif
next y:portc=$ff:porta.5=1:goto adc
END

Oh...and it's been colonized!

Hi Jeremy,
I wasn't trying to translate this, but thanks! I was trying to figure out the unusual way the lookup table was set up. Seems the author was "thinkin' outside the box" So I learned something, which is my objective here. Seems I ticked off Darrel, so whatever he had to show me is history, I didn't expect him to sit and write me a program, but he did, . . . so if your reading this Darrel, I apologize . . . anyway Thanks Jeremy, and Bruce, I got a grip on why this piece of code is written this way. <br> I will play with this "colony" to extract what I might learn from it. I think what bugs people about the colons is it makes it hard to distinguish colons following a LABEL vs colons denoting a new line of code.

[skimask]

Hi Jeremy,......I wasn't trying to translate this, but thanks!
........................
I think what bugs people about the colons is it makes it hard to distinguish colons following a LABEL vs colons denoting a new line of code.

I was just playin' around a bit, translation and all. I've got no idea if it's correct or not.
And like I've said before, the only reason I like the colons is because it keeps more info on one page. As far as LABELs vs. multiple statements...kinda easy to tell the difference because a LABEL isn't a statement at the beginning of a line, can't be, otherwise it'd kick out an error.

[Darrel Taylor]

. . . so if your reading this Darrel, I apologize . . .

Stop that.

No, I'm sorry Joe. ... Sort of.
When it became apparent you would be using a different program. I kept what I had, improved it, and sold it.

Should make bunches, I hope.

No bad blood here!

.

[Archangel]

Stop that.

No, I'm sorry Joe. ... Sort of.
When it became apparent you would be using a different program. I kept what I had, improved it, and sold it.

Should make bunches, I hope.

No bad blood here!

.

I hope you did ! Nothing would make me happier than to see you prosper, Damn well you deserve to ! Happy Independence Day ! And to everyone who responds to my posts, Thank You!

[Archangel]

As far as LABELs vs. multiple statements...kinda easy to tell the difference because a LABEL isn't a statement at the beginning of a line, can't be, otherwise it'd kick out an error.

Nothing is obvious when you are confused!