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! :D

[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! :D
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. :eek:

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. :eek:

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!