9 bit addressable USART

[barkerben]

Hi,

Sorry - me again :-(

I've been looking through the data sheet for my PIC about 9 bit addressable USART. Since I'm using two pics, this sounds useful - especially as it gives me a sensible place to pause afer the address byte to ensure I'm in the service outine and prevent overflow, if this becomes a problem.

The description of how the system works is on pg. 121 of the PIC16F87XA datasheet. (www.srcf.ucam.org/~dbrb2/pages/pic.pdf)

The description makes sense - however, I had a question about how to implement this in PICBasic. For instance, to read from RCREG register (the serial receive register) presumably I just use the HSERIN command? Or can I just read the register directly - so have : my_variable=RCREG

If the latter is possible, then what is the advantage of the HSERIN command under any circumstances ...?

Cheers,

Ben

[barkerben]

Oh - and one final thing - very trivial ...

If I receive a serial byte, then it will be stored as binary. Can I however manipulate it in PICBasic in decimal - for instance if a serial 3 is sent and stored in a byte variable 'input' then the binary stored will be:

00000011

However, if I want to manipulate this value, I can treat it as decimal and say:

input2 = input*2

and expect input2 to store the value 6 ...?

Ben

[mister_e]

If I receive a serial byte, then it will be stored as binary. Can I however manipulate it in PICBasic in decimal - for instance if a serial 3 is sent and stored in a byte variable 'input' then the binary stored will be:

00000011

Be sure that the sended "3" is the ASCII 3 and not the character 3 (ASCII $33). In this case you'll be able to do anykind of math you want.

The description makes sense - however, I had a question about how to implement this in PICBasic. For instance, to read from RCREG register (the serial receive register) presumably I just use the HSERIN command? Or can I just read the register directly - so have : my_variable=RCREG

HSERIN will do more than read from the RCREG, it will also set the USART register to get the serial data. Some other will prefer to set manually register setting as when using ADCIN from PBP.

[barkerben]

Ah - Ok, so If I sent binary 00000011 I would be ok, but If I sent 00110011 (51 - the ASCII code for 3 - in binary) then I would not be ok.

However, If I received a character and wanted to check what it was, would I have to check its value or could I check it directly. For instance, the ASCII code for '+' is 43. If I wanted to check if a received character was '+' or not, could I use:

IF variable = '+', or would I have to have IF variable =43 ...


Thanks, and sorry for all the posts,


Ben

[barkerben]

...For example, in the manual, the manual states that:


3)A numeric value preceded by BIN will send the ASCII representation of its binary value. For example, if B0 = 8, thenBIN B0 (or BIN 8) will send “1000".



This seems to be a contradiction - the ASCII representation of the character 8 is decimal value 56 (00111000)

However, the binary representation of the character 8 is
1000. The latter seems more useful, and is I believe what happens ...

Ben

[barkerben]

My basic question then seems to be this, after a bit of thought...


All that can be transmitted over the serial link are binary bytes. Whether these bytes are interpereted as ascii character codes or as raw values depends on how they are interpreted at the receive end.

For instance, the MICRostudio program bundled with the compiler has a serial coms window. You can type text to be sent over the link into the console.

If you type "hello world" I would assume you are sending 11 bytes, one for the ASCII code of each character in the string. If however you type "32" what are you sending? The string '32' - i.e two bytes representing the character 3 and the character 2, or the value '32' in one binary byte ...

[mister_e]

If however you type "32" what are you sending? The string '32' - i.e two bytes representing the character 3 and the character 2, or the value '32' in one binary byte ...

MicroCode studio always send ASCII. So if you type 32, you'll send 2 bytes, 1 for 3 and 1 for 2. If you want to send 32 you must press and hold ALT and type 32 on your numeric keypad and release ALT. now you will send ASCII 32 in one shot.

the result in your receiver/transmitter will be different depending of wich modifier you'll use in the SERIN/SEROUT statement. The best way to get good idea, try within MicroCode Studio serial comm windows. HyperTerminal or between 2 PIC and LCDs if you have in stock...PORT pin can be also use with LEDs to see results.

[barkerben]

Thanks - that's really helpful.

In PBP, if I put:

forward CON "+"

Then presumably this has defined a byte whose binary value is equal to the ASCII code for the character "+"?

If I then say

hserin[direction]

IF direction = forward THEN


Then to get this to succeed I would have had to ensure that the byte received and stored in the variable 'direction' had a value equal to the ascii code for the "+" character...?


Thanks - Ben

[barkerben]

...This issue of how variables are stored is illustrated in the manual by the modifiers for the HSEIN command including BIN and DEC.

BIN --> receive binary numbers
DEC -->receive decimal numbers


but snce all data is received in binary, this is slightly confusing. Des this mean that BIN receives the value of a byte directly, wheras DEC interprets the value of each byte as an ASCIIcode and then converts to a single binary value (i.e receives ASCII code for 3 and 2, then stores 32 in a byte) .... If the latter, how does the compiler 'know' how many bytes make up the number (i.e how many characters in the number ...)

Sorry If I'm talking rubbish ...

[mister_e]

but snce all data is received in binary, this is slightly confusing. Des this mean that BIN receives the value of a byte directly, wheras DEC interprets the value of each byte as an ASCIIcode and then converts to a single binary value (i.e receives ASCII code for 3 and 2, then stores 32 in a byte)

yes! All modifier explanation in the SERIN2 section in the PBP manual (p134-135)