 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Friday
Guest
|
| opinions about my PIC to PIC Code |
 Posted: Fri Oct 31, 2008 2:28 am |
 |
|
Hi all,
Comipler:4.057
PICS:16F877
I made a program to send data from a PIC to another, I use this protocol (STX_Code_Data_ETX) , so that according to the code, the receiver PIC has a kind of data to receive and treatement to do:
I was largely inspired by MarcosAmbrose code (in page 2 (vittorio topic))
I just like to have your opinions about my code which do not work fine.
any remarks, suggestions or question is welcome
thank you in advance dears.
Sender PIC:
| Code: |
#if defined(__PCM__)
#include <16F877.h>
#fuses HS,NOWDT,NOPROTECT,NOLVP
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7) // Jumpers: 8 to 11, 7 to 12
#include "flex_lcd.c"
#define T_BUFFER_SIZE 64
byte t_buffer[T_BUFFER_SIZE];
byte t_next_in = 0;
byte t_next_out = 0;
//=========Variables=======
#define STX '$'
int1 ED,HF;
unsigned int code;
unsigned long freq_ms; //ms: mother board_to_stepper
#int_tbe
void serial_isr() {
if(t_next_in!=t_next_out)
{
putc(t_buffer[t_next_out]);
t_next_out=(t_next_out+1) % T_BUFFER_SIZE;
}
else
disable_interrupts(int_tbe);
}
void bputc(char c) {
short restart;
int ni;
restart=t_next_in==t_next_out;
t_buffer[t_next_in]=c;
ni=(t_next_in+1) % T_BUFFER_SIZE;
while(ni==t_next_out);
t_next_in=ni;
if(restart)
enable_interrupts(int_tbe);
}
//=============Send Procedure=============
void Load_Buffer_MB_to_SM(int8 code,unsigned long freq_ms,int1 HF,int1 ED)
{
//----Load_Buffer Mother Board_to_Stepper Motor
//Codes:
// 0:Enable/Disable Stepper motor Controller (L297) (+ Data=1 bit)
// 1:Half/Full (+ Data=1 bit)
// 2:Send Frequency (+ Data=int16)
// 3:Get Frequency (sans Data)
// 4:Emergency Stop (sans Data)
unsigned int i,length;
int8 SXBuffer[];
int1 l;
SXBuffer[0]=(int8)code;
switch(code)
{
case 0:SXBuffer[1]=(int8)ED;length=1;l=1;break;
case 1:SXBuffer[1]=(int8)HF;length=1;l=1;break;
case 2:SXBuffer[1]=(int8)(freq_ms&0x00FF);
SXBuffer[2]=(int8)(freq_ms>>8);
length=2;l=1;break;
default: break;
}
//Sending
bputc(STX);//send the Start of transmission character
bputc(SXBuffer[0]);
if(l)
{
for(i=1;i<=Length;i++)
{bputc(SXBuffer[i]);}
l=0;
}
bputc('€');
// bputc("\n\r"); //CRLF:Carriage Return (retour chariot) Line Feed ( saut de ligne)
}
void main() {
enable_interrupts(global);
lcd_init();
lcd_putc("Running...");
delay_ms(5000);
do{
Load_Buffer_MB_to_SM(0,0,0,1);
delay_ms(5000);
Load_Buffer_MB_to_SM(1,0,0,0);
delay_ms(5000);
Load_Buffer_MB_to_SM(2,45,0,0);
delay_ms(5000);
Load_Buffer_MB_to_SM(3,0,0,0);
delay_ms(5000);
Load_Buffer_MB_to_SM(4,0,0,0);
delay_ms(5000);
}
while(TRUE);
}
|
Receiver PIC:
| Code: |
#if defined(__PCM__)
#include <16F877.h>
#fuses HS,NOWDT,NOPROTECT,NOLVP
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
#include "flex_lcd2.c"
#define BUFFER_SIZE 32
BYTE buffer[BUFFER_SIZE];
BYTE next_in = 0;
BYTE next_out = 0;
//=======================Variables=================
#define STX '$'
int8 Code,RXBuffer[];
unsigned int BufferIndex,BufferSize;
int16 Freq;
int1 ED,E,HF=1,H,F,GF,ES,YOU_HAVE_DATA,YOU_READ_DATA;
#int_rda
void serial_isr() {
int t;
buffer[next_in]=getc();
t=next_in;
next_in=(next_in+1) % BUFFER_SIZE;
if(next_in==next_out)
next_in=t; // Buffer full !!
}
#define bkbhit (next_in!=next_out)
BYTE bgetc() {
BYTE c;
while(!bkbhit) ;
c=buffer[next_out];
next_out=(next_out+1) % BUFFER_SIZE;
return(c);
}
//===================================
void Get_Buffer_from_MB()
{
while(bkbhit)
{
int8 RXbyte,code ;
RXbyte=bgetc();
if(RXbyte==STX)
{
BufferIndex=0; //bufferSize = ???
}
else
{ if ( BufferIndex==0)
{
RXBuffer[0]=RXbyte;
Code=RXBuffer[0];
BufferIndex++;
Switch (code)
{
case 0: BufferSize=1;break;
case 1: BufferSize=1;break;
case 2: BufferSize=2;break;
default: BufferSize=0;break;
}
}
else
{ if (BufferSize>=1)
{
while (BufferIndex<=BufferSize)
{
RXBuffer[BufferIndex]=RXbyte;
BufferIndex++;
}
}
}
}
YOU_HAVE_DATA=1;
}
}
//===================================
void Read_Buffer_from_MB(int8 RXBuffer[])
{
int8 code,HF,LF;
if (YOU_HAVE_DATA)
{
code=RXBuffer[0];
switch(code)
{
case 0: {
ED=(int1)RXBuffer[1];
E=1;
break;
}
case 1: {
HF=(int1)RXBuffer[1];
H=1;
break;
}
case 2: {
LF=RXBuffer[1];
HF=RXBuffer[1];
Freq=make16(HF,LF);
F=1;
break;
}
case 3: GF=1; break;
case 4: ES=1; break;
default: break;
}
YOU_HAVE_DATA=0;
YOU_READ_DATA=1;
}
}
//===================================
void Excute_MB_Buffered_commands()
{
if(YOU_READ_DATA)
{
if(E)
{
if(ED)
{
lcd_putc("\fENABLE STEPPER");
delay_ms(1000);
lcd_putc("\f");
}
else
{
lcd_putc("\fDISABLE STEPPER");
delay_ms(1000);
lcd_putc("\f");
}
E=0;
}
if(H)
{
if(HF)
{
lcd_putc("\nHALF STEP ENABLED");
delay_ms(1000);
lcd_putc("\f");
}
else
{
lcd_putc("\nFULL STEP ENABLED");
delay_ms(1000);
lcd_putc("\f");
}
H=0;
}
if(F)
{
printf(lcd_putc,"Sent freq:%Lu",Freq);
F=0;
}
if(GF)
{
lcd_putc("MB WANTS FREQ");
GF=0;
}
if(ES)
{
lcd_putc("EMERGENCY STOP");
ES=0;
}
YOU_READ_DATA=0;
}
}
void main() {
enable_interrupts(int_rda);
enable_interrupts(global);
lcd_init();
lcd_putc("Running...");
do {
Get_Buffer_from_MB();
Read_Buffer_from_MB(RXBuffer[BufferSize]);
Excute_MB_Buffered_commands();
} while (TRUE);
}
|
|
|
 |
Ttelmah
Guest
|
|
| Posted: Fri Oct 31, 2008 3:45 am |
|
|
Haven't looked at it all, but one big problem leaps out.
If you are using STX/ETX transmission codes, for the start and stop, you must _not_ send binary values in the packet. You must send numbers as their ASCII versions. The binary code for '2', is your 'start' marker, and the code for '3' is your 'end' marker. You then send a 16bit value directly. If (for instance), this value is '2', you will end up sending another STX. If instead it is '3', you will end up sending another ETX. When using STX/ETX markers, you need to either send the number as decimal text, or as hex. Takes more space, but ensures that your slave can look for STX/ETX, and these won't arrive anywhere they shouldn't.
Best Wishes |
|
|
Friday
Guest
|
|
| Posted: Fri Oct 31, 2008 8:14 am |
|
|
| Ttelmah wrote: | Haven't looked at it all, but one big problem leaps out.
If you are using STX/ETX transmission codes, for the start and stop, you must _not_ send binary values in the packet. You must send numbers as their ASCII versions. The binary code for '2', is your 'start' marker, and the code for '3' is your 'end' marker. You then send a 16bit value directly. If (for instance), this value is '2', you will end up sending another STX. If instead it is '3', you will end up sending another ETX. When using STX/ETX markers, you need to either send the number as decimal text, or as hex. Takes more space, but ensures that your slave can look for STX/ETX, and these won't arrive anywhere they shouldn't.
Best Wishes |
Hi Ttelmah,
thank you very much for being interested in my topic,
I made the changements below:
| Code: | #define STX 0xAA
#define ETX 0xBB |
and in the Reading Buffer by the reciver PIC procedure:
| Code: |
void Get_Buffer_from_MB()
{
int8 RXbyte,code ;
while(bkbhit)
{
RXbyte=bgetc();
if(RXbyte==STX)
{
BufferIndex=0;
}
else
{ if ( BufferIndex==0)
{
RXBuffer[0]=RXbyte;
Code=RXBuffer[0];
BufferIndex++;
Switch (code)
{
case 0: BufferSize=1;break;
case 1: BufferSize=1;break;
case 2: BufferSize=2;break;
default: BufferSize=0;break;
}
}
else
{ if (BufferSize>=1)
{
while (BufferIndex<=BufferSize)
{
RXBuffer[BufferIndex]=RXbyte;
BufferIndex++;
}
}
}
}
[b] if(RXbyte==ETX) //Check to see if end of frame has arrived.
{
YOU_HAVE_DATA=1; //You now have a complete packet of data in the RX buffer.
}[/b]
}
}
|
I´ll try to make other corrections in my code (cause it still not work)and I´ll post it again.
thank you again. |
|
|
Wayne_
Joined: 10 Oct 2007
Posts: 681
|
|
| Posted: Fri Oct 31, 2008 9:35 am |
|
|
There are quite a few problems with your code. The first as Ttelmah pointed out you tried to fix, unfortunately your fix will not work as it is still possible that your data will consit of an 0xAA or 0xBB value!
the second thing I can see is
| Code: |
while (BufferIndex<=BufferSize)
{
RXBuffer[BufferIndex]=RXbyte;
BufferIndex++;
}
|
This just stores the same value, you need to retrieve the next value from your recieve buffer. I think you just need to remove the while loop around your code and it will re-enter this routine and work correctly.
| Code: |
case 2: {
LF=RXBuffer[1];
HF=RXBuffer[1];
Freq=make16(HF,LF);
|
HF needs to be loaded with the next value RXBuffer[2];
But mainly you do not say what is wrong, show actual values you are displaying, etc.
I think you have overcomplicated things a little but as far as I can see your code should work if you fix the problems. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Fri Oct 31, 2008 10:02 am |
|
|
| Quote: | | I think you have overcomplicated things a little |
That's a good summary.
I don't know, if there's a particular reason for using a binary protocol in this case (may be speed/througput considerations), otherwise I would prefer an ASCII protocol, for human readability and ease of debugging.
Basically, you only need an unequivocal frame start to resync the transmission, ETX e. g. is unused in your receiver and has no actual purpose with frames of known length.
As said, the STX isn't unique in your protocol, thus it can be simply omitted. You may use a one or two character idle period as frame separator instead, as in MODBUS RTU. Other simple frame marks are 9th bit (as in MIDI); different parity (as in S-BUS parity mode) or a break (as in DMX512). |
|
|
Friday
Guest
|
|
| Posted: Fri Oct 31, 2008 1:52 pm |
|
|
| Wayne_ wrote: |
the second thing I can see is
| Code: |
while (BufferIndex<=BufferSize)
{
RXBuffer[BufferIndex]=RXbyte;
BufferIndex++;
}
|
This just stores the same value, you need to retrieve the next value from your recieve buffer. I think you just need to remove the while loop around your code and it will re-enter this routine and work correctly.
| Code: |
case 2: {
LF=RXBuffer[1];
HF=RXBuffer[1];
Freq=make16(HF,LF);
|
HF needs to be loaded with the next value RXBuffer[2];
But mainly you do not say what is wrong, show actual values you are displaying, etc.
I think you have overcomplicated things a little but as far as I can see your code should work if you fix the problems. |
Hi Wayne_
This is what we call "careless mistakes" 
Instead of while, I have to put if.
Thank you for correcting them to me. 
| Wayne_ wrote: | | There are quite a few problems with your code. The first as Ttelmah pointed out you tried to fix, unfortunately your fix will not work as it is still possible that your data will consit of an 0xAA or 0xBB value! |
You're right, I´ll have to code differently. |
|
|
Friday
Guest
|
|
| Posted: Fri Oct 31, 2008 2:04 pm |
|
|
Hi FvM,
thank you for answering me.
| FvM wrote: | | Quote: | | I think you have overcomplicated things a little |
That's a good summary.
I don't know, if there's a particular reason for using a binary protocol in this case (may be speed/througput considerations), otherwise I would prefer an ASCII protocol, for human readability and ease of debugging.
|
what do you ean by ASCII one protocol ?, how is it better than mine in human readability ?
[quote="FvM"] | Quote: |
Basically, you only need an unequivocal frame start to resync the transmission, ETX e. g. is unused in your receiver and has no actual purpose with frames of known length.
|
yes , you´re right but it´s still a way to be sure that the entire frame is received . 
[quote="FvM"] | Quote: |
As said, the STX isn't unique in your protocol, thus it can be simply omitted. You may use a one or two character idle period as frame separator instead, as in MODBUS RTU. Other simple frame marks are 9th bit (as in MIDI); different parity (as in S-BUS parity mode) or a break (as in DMX512). |
I´ll do some google research to understand betterly this. |
|
|
Friday
Guest
|
|
| Posted: Fri Oct 31, 2008 2:07 pm |
|
|
| Wayne_ wrote: |
But mainly you do not say what is wrong, show actual values you are displaying, etc.
|
problem of displaying, the message "DISABLE STEPPER" is displayed all time in the LCD2 , apart from the sent frame. |
|
|
Friday
Guest
|
|
| Posted: Sat Nov 01, 2008 2:25 pm |
|
|
Hi there,
just to get around the possibilty that my data would consit of an 0xAA or 0xBB value I made changes in my PIC1 code as following (I know that this will change my data, but it´s just to test).
| Code: |
void Load_Buffer_MB_to_SM(int8 code,unsigned long freq_ms,int1 HF,int1 ED)
{
bputc(STX);//send the Start of frame
bputc(SXBuffer[0]);
if(l)
{
for(i=1;i<=Length;i++)
{
if((SXBuffer[i]==STX) || (SXBuffer[i]==ETX))
{
SXBuffer[i]+=0x10;
bputc(SXBuffer[i]);
}
else
bputc(SXBuffer[i]);
}
l=0;
}
bputc(ETX); // send end of frame.
// bputc("\n\r"); //CRLF
}
|
in the main() (below),I´m trying to send all kind of data one by one, every 5 seconds.
| Code: | void main() {
enable_interrupts(global);
lcd_init();
lcd_putc("Running...");
delay_ms(2000);
do{
Load_Buffer_MB_to_SM(1,0,0,0);
lcd_putc("\nSET STEPS H/F");
delay_ms(2000);
lcd_putc("\f");
Load_Buffer_MB_to_SM(2,45,0,0);
lcd_putc("\nSEND FREQUENCY");
delay_ms(2000);
lcd_putc("\f");
Load_Buffer_MB_to_SM(3,0,0,0);
lcd_putc("\nGETTING FREQUENCY...");
delay_ms(2000);
lcd_putc("\f");
Load_Buffer_MB_to_SM(4,0,0,0);
lcd_putc("\nSEND EMERGENCY STOP");
delay_ms(2000);
lcd_putc("\f");
Load_Buffer_MB_to_SM(0,0,0,1);
lcd_putc("\nSET ENABLE/DISABLE");
delay_ms(2000);
lcd_putc("\f");
}
while(TRUE);
}
|
in the second PIC, I made some correction in the reception buffer procedure :
| Code: |
void Get_Buffer_from_MB()
{
int1 GET_STX,RECEIVING_DATA;
while(bkbhit)
{
int8 RXbyte,code ;
RXbyte=bgetc();
if(RXbyte==STX)
{
BufferIndex=0;
GET_STX=1;
}
else
{ if (GET_STX)
{
RXBuffer[0]=RXbyte;
Code=RXBuffer[0];
BufferIndex++;
GET_STX=0;
RECEIVING_DATA=1;
Switch (code)
{
case 0: BufferSize=1;break;
case 1: BufferSize=1;break;
case 2: BufferSize=2;break;
default: BufferSize=0;break;
}
}
else
{ if ((RECEIVING_DATA==1) & (BufferSize>=1) & (BufferIndex<=BufferSize))
{
RXBuffer[BufferIndex]=RXbyte;
BufferIndex++;
}
}
}
if(RXbyte==ETX) //Check to see if end of frame has arrived.
{
//You now have a complete packet of data in the RX buffer.
YOU_HAVE_DATA=1;
RECEIVING_DATA=0;
}
}
}
|
the main() and other procedures remain the same.
| Code: |
//===================================
void Read_Buffer_from_MB(int8 RXBuffer[])
{
int8 code,HF,LF;
if (YOU_HAVE_DATA)
{
code=RXBuffer[0];
printf(lcd_putc,"\f%i ",code);
switch(code)
{
case 0: {
ED=(int1)RXBuffer[1];
E=1;
break;
}
case 1: {
HF=(int1)RXBuffer[1];
H=1;
break;
}
case 2: {
LF=RXBuffer[1];
HF=RXBuffer[2];
Freq=make16(HF,LF);
F=1;
break;
}
case 3: GF=1; break;
case 4: ES=1; break;
default: break;
}
YOU_HAVE_DATA=0;
YOU_READ_DATA=1;
}
}
|
| Code: |
//===================================
void Excute_MB_Buffered_commands()
{
if(YOU_READ_DATA)
{
if(E)
{
if(ED)
{
lcd_putc("\fENABLE STEPPER");
delay_ms(1000);
lcd_putc("\f");
}
if(ED==0)
{
lcd_putc("\fDISABLE STEPPER");
delay_ms(1000);
lcd_putc("\f");
}
E=0;
}
if(H)
{
if(HF)
{
lcd_putc("\nHALF STEP ENABLED");
delay_ms(1000);
lcd_putc("\f");
}
if(HF==0)
{
lcd_putc("\nFULL STEP ENABLED");
delay_ms(1000);
lcd_putc("\f");
}
H=0;
}
if(F)
{
printf(lcd_putc,"Sent freq:%Lu",Freq);
F=0;
}
if(GF)
{
lcd_putc("MB WANTS FREQ");
GF=0;
}
if(ES)
{
lcd_putc("EMERGENCY STOP");
ES=0;
}
YOU_READ_DATA=0;
}
}
|
| Code: |
void main() {
enable_interrupts(int_rda);
enable_interrupts(global);
lcd_init();
lcd_putc("Running...");
do {
Get_Buffer_from_MB();
Read_Buffer_from_MB(RXBuffer[BufferSize]);
Excute_MB_Buffered_commands();
} while (TRUE);
} |
in spite of this corrections, I have every 5 seconds the message "DISABLE
STEPPER" displayed in the LCD of the PIC2, this means that I this PIC is only receiving the '0' as code (first byte after the ETX) even I change it every 5 seconds.
what´s still wrong with my code in your opinions sirs ? (apart from the ETX/STX Protocol wich is not so good yet)
thanks in advance. |
|
|
Friday
Guest
|
|
| Posted: Sun Nov 02, 2008 9:23 am |
|
|
| Hi, any remark ? |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Sun Nov 02, 2008 1:13 pm |
|
|
| Friday wrote: | ...what do you mean by ASCII one protocol ?, how is it better than mine in human readability ?
|
An ASCII protocol is one where all the data is sent using ASCII characters ('A'-'z', '0'-'9', various special characters) having values from 0 to 127. The protocol is human readable because you can place a serial port terminal on the lines and see the characters on the terminal (like Hyperterminal running on a Windows computer). This is useful for debugging. But you are sending arbitrary binary values 0-255 in the data. So no matter what value you assign to STX and ETX, they will not be reliable for finding the beginning of a frame or ensuring that the whole frame has been received.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
Friday
Guest
|
|
| Posted: Sun Nov 02, 2008 2:06 pm |
|
|
| RLScott wrote: | | Friday wrote: | ...what do you mean by ASCII one protocol ?, how is it better than mine in human readability ?
|
An ASCII protocol is one where all the data is sent using ASCII characters ('A'-'z', '0'-'9', various special characters) having values from 0 to 127. The protocol is human readable because you can place a serial port terminal on the lines and see the characters on the terminal (like Hyperterminal running on a Windows computer). This is useful for debugging. But you are sending arbitrary binary values 0-255 in the data. So no matter what value you assign to STX and ETX, they will not be reliable for finding the beginning of a frame or ensuring that the whole frame has been received. |
Hi Mr Scott,
thank you for taking time to explain it to me.
I think that the ASCII protocol is not also reliable for finding the begining/last of a frame as a byte of sent data can also have a value between 0 and 127 (=ASCII of STX or ETX).
or am I wrong ?
a way to be sure that you fet the ETX or STX (and of course the data between) is to use a protocol like this one:
| Quote: | A packet always starts with an 0x02 (STX) and ends with an 0x03 (ETX) and you pack your data in between. This however raises the problem of what to do if you want to transmit 0x02 or 0x03 as data. To get around this problem, I send an ESC character 0x10 before the data (ie 0x02 or 0x03) then add 0x10 to the data before sending it. Likewise, if you send 0x10 as data, you send the ESC character first then add 0x10 to the data.
So for example if you had a buffer that contained the following data to be transmitted
| Code: | | int8 buffer[6]={0xAA,0x02, 0x55, 0x10, 0x13,0x03); |
The data transmitted would be
| Code: | | 0x02 0xAA 0x10 0x12 0x55 0x10 0x20 0x13 0x10 0x13 0x03 |
In your receiver code:
:-When you receive an 0x02, you know it's the start of a packet frame.
:-When you receive an 0x10, you discard it and subtract 0x10 from the next byte received.
:-When you receive an 0x03, you know you've received the last byte in the packet frame. |
Writer: MarcosAmbrose,the whole protocol is available in a thread in this forum. |
|
|
Friday
Guest
|
|
| Posted: Sun Nov 02, 2008 2:39 pm |
|
|
| Ttelmah wrote: | Haven't looked at it all, but one big problem leaps out.
If you are using STX/ETX transmission codes, for the start and stop, you must _not_ send binary values in the packet. You must send numbers as their ASCII versions. The binary code for '2', is your 'start' marker, and the code for '3' is your 'end' marker. You then send a 16bit value directly. If (for instance), this value is '2', you will end up sending another STX. If instead it is '3', you will end up sending another ETX. When using STX/ETX markers, you need to either send the number as decimal text, or as hex. Takes more space, but ensures that your slave can look for STX/ETX, and these won't arrive anywhere they shouldn't.
Best Wishes |
Oh,excuse me, think I did not read very well your post in the first time,
so, assuming that my data (packet) is a serie of integers, how would I send them as ASCII´s ?,or hex, decimal ? Aren´t they received there in their original format ??
I'm totally confused now. |
|
|
Ttelmah
Guest
|
|
| Posted: Sun Nov 02, 2008 2:59 pm |
|
|
STX/ETX, is designed for transmission of _text_. This way you can guarantee that the codes won't occur accidentally. It is entirely up to you, whether to send in decimal, or Hex. The advantage of hex, is that it only takes four characters to send a 16bit value, versus five for decimal. The compiler has routines available, to convert from raw values to hex or decimal (printf), and convert back (atoi, or look in input.c). Conversion to/from Hex, is also faster than decimal.
Best Wishes |
|
|
Friday
Guest
|
|
| Posted: Mon Nov 03, 2008 1:26 am |
|
|
| Ttelmah wrote: | STX/ETX, is designed for transmission of _text_. This way you can guarantee that the codes won't occur accidentally. It is entirely up to you, whether to send in decimal, or Hex. The advantage of hex, is that it only takes four characters to send a 16bit value, versus five for decimal. The compiler has routines available, to convert from raw values to hex or decimal (printf), and convert back (atoi, or look in input.c). Conversion to/from Hex, is also faster than decimal.
Best Wishes |
Hi Ttlemah,thank you again for this information.
I have further question and I would be really pleased if you will be patient with the newbie that I am.
| Quote: | | The advantage of hex, is that it only takes four characters to send a 16bit value, versus five for decimal. |
in my code above, I´m using bputc() to send data (serie of integers) and bgetc() to receive it, even if I´ll have to send a 16bit value I´ll divide it into two int and send each one then assemble them when received.
-as their names mean, they are used to send/receive a byte once.
if (for instance) I send a byte in hex format:
in the other side:
a will take the value of 0x5A,
assuming that I send a 16bits value with printf() , will I have to extend the receiver buffer to get the whole packet of data ? 
thanks in advance. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
